The german eID🔗

Intro🔗

The German electronic ID card (short: eID, or Neuer Personalausweis / NPA) is one of those rare government IT projects where someone actually thought about the architecture and cryptography before building the system.

It is a decentralized, user-controlled digital identity system using a secure chip inside a physical ID card communicating contactlessly with a smartphone or Near Field Communication (NFC) reader only if the user consents using two factor authentication.

It was designed so that no central authority can track when or where people use their eID online thus full data sovereignty and privacy by design are built into it.

There are surprisingly few comprehensive resources out there about what the German eID system is actually capable of aside from the official "Technische Richtlinien" documents.

So I decided to write this kind of "primer" for people interested in learning the ins and outs of the eID system without having to wade through hundreds of pages of BSI(Bundesamt für Sicherheit in der Informationstechnik) technical guidelines.

I'll try to cover it in digestible chunks for progressively more technical audiences and create follow-up posts about specific topics when needed.

...explained in 1 Minute: "Managers digest"🔗

The citizens perspective🔗

Wait, what does this actually look like for me, the citizen?

Let's do a very simplified example from the citizens perspective first.

Imagine you want to identify yourself on a website say "Bank XYZ". You don't care how it works in detail you just want to login or create an account.

You get prompted to identify yourself by "Bank XYZ"
You click on "Identify via eID"
The AusweisApp opens
It shows you who wants to read your eID Card for what reason and which data specifically
You are asked to enter the card's Personal Identification Number (PIN) and hold it against the reader (most likely your smartphone nowadays)
The magic "eID Dance" happens
"Bank XYZ" has your verified identity and lets you proceed

Or for the visual learners as sequence diagram:

(Note: I introduce an eID Server here which is a certified backend server that does the actual cryptographic work and eID Card communication on behalf of the website. What the eID server does will be explained in a bit.)

All done. Nothing more to concern from the citizens perspective.

What Data Can Be Read?🔗

The chip stores different data depending on which card it lives in a Personalausweis (German national ID card) holds different fields than a Unionsbürgerkarte (EU citizen card) or an elektronischer Aufenthaltstitel (electronic residence permit).

But they all share the same basic structure called Datagroups(DG). The DGs defined in BSI-TR-03127

Data Groups defined in TR-03127

You can think of the card having a mini filesystem on it with files for capabilities (what algorithms do I support), for verification (here is my official seal) or the actual attributes of the card holder like the citizens birthdate, lastname etc.

Each of the card holders fields can only be read if the servers certificate explicitly permits it via its Certificate Holder Authorization Template(CHAT) bitmask (more on that below).

Special Functions - Privacy Without Revealing Data🔗

What if a website just needs to know I'm over 18, but I don't want to tell it how old I am?

Beyond raw data fields, the eID chip supports three special functions that are the real stars of "Privacy by Design". They let a service verify a fact about you without ever learning the underlying data.

Data Minimalism: Sending booleans instead of birthdays

Age Verification🔗

Instead of handing over your date of birth (DG 8), the eID Server sends the reference age (e.g., "18 years") inside an encrypted Application Protocol Data Unit (APDU) command directly to the chip. The card computes the answer internally against DG 8 and returns only a boolean "yes" or "no". The service never sees your birthday. A website verifying you are old enough to look at certain content gets exactly one bit of information nothing more.

Community ID Verification (Ortskennung)🔗

Similar to Age Verification, instead of handing over your full address (DG 17), the eID server sends the target Amtlicher Gemeindeschlüssel (AGS) code in an encrypted command to ask:

"Does the holder live in the municipality with AGS code 027600...?"

The card returns only "yes" or "no". The service learns whether you live in a specific community but not your street, house number, or exact location.

Useful for public transport apps, local government portals, or regional services that only need to know which district you belong to.

Restricted Identification (RI) - the Pseudonym function🔗

This one is the most elegant. Every service gets a unique, stable, pseudonymous identifier for you but no two services can link their identifiers together.

Think of it like mixing paint colors:

Your card has one fixed secret color yellow baked into the chip at manufacture time. It never changes.
Bank XYZ has its own sector color blue issued by the DVCA, unique to that service.
Insurance XYZ has a different sector color red also issued by the DVCA, different from Bank XYZ's.

When you use your card with a service, the chip mixes your color with their color:

Card + Bank XYZ → yellow + blue = green → your pseudonym at Bank XYZ
Card + Insurance XYZ → yellow + red = orange → your pseudonym at Insurance XYZ

The result is:

Always the same color when you mix your secret with that service's color → stable identifier, so the service can re-recognize you next time.
Always different when a different service mixes in because their color is different → Bank XYZ cannot compare green with Insurance XYZ's orange to figure out they belong to the same person.
Impossible to reverse seeing the mixed color tells you nothing about the yellow that went into it.

(The actual cryptography behind this elliptic curve point multiplication with sector-specific domain parameters is in the 15-minute section.)

1-Minute Summary: Design Principles🔗

Okay, cool tech, but why should I use this instead of a video call or a normal password?

But why should you actually want to use this over traditional logins or a video Ident system? Well first of all it basically a free Two-Factor-Authentication (2FA) login with a hardware token that is already in your pocket. Second its core design principles guarantee some very nice privacy features:

Mutual Authentication🔗

The service reading your data must prove to the card that it is authorized to do so. Only services with a valid government-issued Berechtigungszertifikat (terminal certificate) can request your data.

no phishing or impersonation possible

No cross-service tracking🔗

The system generates a unique identifier per service calles pseudonym. "Bank XYZ" and "Insurance XYZ" each see a different pseudonym for you they cannot collude to build a tracking profile. ( there is an example and details later in the article )

no tracking across services

Self Sovereign Identity🔗

You have control over your data at all times. The data lives on your card's chip and only there. You must explicitly consent via PIN to let anyone read it. There is no central registry that could leak.

no data leak possible

Data minimalism🔗

The card only transmits the fields you approved for a specific service and the service has the permission to read. Beyond the data groups, it supports special functions: age verification, community verification, and a pseudonym per service. "Bank XYZ" only needs to know you are over 18? It gets a yes/no never your actual birthday. Same for the question "is there a human on the other end, okay give me a pseudonym nothing more" So online age verification could simply be done by asking "Is the person over 18 yes/no and give me a pseudonym for the user. I don't care about his name, address or any other attribute"

no personal data needs to be shared at all if it is not needed

Two-Factor Authentication🔗

Something you have (the physical card) + something you know (your PIN). Both are required no remote-only attack can succeed. Think of someone trying to use your ID card with some strong remore NFC reader. Or someone stole your ID card but not your pin. ( The only thing not solved is a duress situation but thats out of the picture here )

no remote-only attacks possible

Single-use identification🔗

Unlike digital signature schemes, the service receives no cryptographic proof it could hand over to third parties. So if I identify at Bank XYZ they could not act as me and go over to Insurance ABC posing as me. The identification is ephemeral like showing your physical ID card in person.

no replay attacks since there is no signed proof

So it's able to do legally binding transactions online and is at the highest cryptographic standards for digital identity systems with no feasable attack vectors.

All you need as a citizen is the PIN, your Card and an eID Client.

Back in the days this was complicated with card readers, installing drivers and maybe using this "I can use a remote cardreader" feature of the AusweisApp which always was blocked due to Wifi-Client segregation.

But luckily we live in the future and your smartphone can do NFC and run the AusweisApp.

( I know it's not NFC and actually is ISO-14443 but let's not get into that level of detail here )

Sounds intresting ? Ok then let me give you a bit more detail.

...explained in 10 Minutes: The "eID Dance"🔗

Overview ?!🔗

You've seen the big picture from the citizen's perspective. But there is obviously more going on behind the scenes to make everything work and uphold the big claims.

You could read all the BSI technical guidelines regarding eID... but lucky you... I did it so you don't have to.

The BSI TR Stack - eID Technical Guidelines

The three roles🔗

Who is actually involved in this whole process?

Now let's look at who the participants actually are, which role they play and how they interact with each other.

The Document Issuer
The Document Verifier
The Document Holder

In practice the roles are called sometimes differently depending on the context, but this is the most intuitive way to call them right now. All are connected via two Public Key Infrastructures (PKI) chains, one for the issuer and one for the verifier of the eID Cards. The root of trust is at the government level with the BSI.

PKI diagram🔗

Trying to figure out the difference between the CSCA, CVCA, and DVCA

I know this sounds complicated, but it's actually quite simple once you break it down and look at the interactions between these roles in the diagram below. But for now just keep in mind the government runs two PKIs one to issue the cards and one to verify them.

Background processes🔗

Since a PKI is only useful if its used lets walk down each leg of the PKI from the BSI down to the card to get a better grasp of the situation.

How a Card Gets Issued🔗

Where do these cards even come from?

How does the government issue an eID card to a citizen?

BSI runs the root signer CA (CSCA). The Bundesdruckerei is mandated by the government to issue the eID card. Bundesdruckerei could be translated to "Federal Printing Office" and they... well print all kinds of official documents including the eID card. They get a signing certificate from the BSI, generate a unique key pair directly on the chip and sign the key pair's public key with their certificate. That signed key becomes part of a special file in on the card the EF.CardSecurity. Think of it as "the bundesdruckerei's digital stamp on the card" that proves the card is genuine and was issued by them a trusted authority. The Bundesdruckerei then personalizes the card with the citizen's data and writes the CVCA's public key as a first "known good root certificate" onto the chip (so the card can later verify any terminal certificate without phoning home to the BSI). Then it ships the card to you.

The Bundesdruckerei issuing the card and signing its public key

(We skip details like Transport-PIN, in-field updates, and the Sperrliste for now.)

Now that we have a card, let's look at how a service gets permission to read it.

How a Service Gets Permission🔗

Can any random startup just start reading ID cards?

Services go through a parallel PKI chain on the verifier side. The BSI runs the CVCA root, which issues certs to a certified DVCA (also the Bundesdruckerei in Germany). eID server operators have to apply at the Bundesverwaltungsamt (BVA) to get a permission to hold a terminal certificate. The BVA actually makes sure you have the organizational and technical requirements to run a secure eID server before granting you the permission. eID Server operators then apply at the DVCA with the permission slip from the BVA in hand and get back a terminal certificate with a (CHAT) bitmask baked in the certificate that defines exactly which data fields they're allowed to read. No more, no less. These permissions match with the ones the Bundesverwaltungsamt granted in the first place. Lets say a company needs to verify a customer is over 18 to do that they need the fields firstname, lastname and age verification > 18. In this case the BVA will write these datagroups as read-permission in the permission slip. The company could not ask the DVCA for the "place of residence" permission since its not part of the companies business and thus not included from the BVA.

Funny enough there is an official flowchart how to get the permission slip. So I'll spare you the details and just show you the official flowchart from the BVA:

[original PDF](https://www.personalausweisportal.de/SharedDocs/downloads/Webs/PA/DE/Wirtschaft/BMI_Anbindungsprozess_BerCA_Juli2024.pdf?__blob=publicationFile&v=3).

How a citizen Citizen interacts with the system🔗

Ok so now we have a card and a service that is technically equipped and allowed to read it. But what about the card holder AKA citizen ?

As I mentioned earlier there are a lot of steps happening under the hood which I call the "eID Dance". And the director of the Dance is the card holder. The card holder is the only one who can authorize the card to release its data by holding it against a reader and entering the correct PIN.

To understand the eID Dance fully we need to first understand what trust problem we face and try to solve and then how they solve it.

So let's do it! :)

Establishing Trust Between Three Strangers🔗

How can three strangers (a chip, an app, and a server) trust each other over the internet?

Card: Who are you? Server: No, who are you? Client: I'm just here to relay bytes.

The internet is full of scams, phishing attempts, data brokers and just plain incompetent companies handling your data. Don't make me list all the data breaches and leaks that happened in the last 10 years.

So why in the everloving name of the assembly instructions that are holy would you hand over your ID card to a website ?!

How can you trust the website asking for your data or the server that wants to read your data or even the AusweisApp that is handling the communication to your card?

Well good thing we have our PKIs and roles in place so we can combine them now! Before we dive into the deep end, let's keep track of our goals. To make this work securely, we need to complete four major checks:

⬜ PACE: The card needs to trust that you are the legitimate owner.
⬜ TA: The card needs to trust that the server is allowed to ask for data.
⬜ PA: The server needs to trust that the card's data is authentic.
⬜ CA: The server needs to trust that the card's chip is not a software clone.

The eID Dance == PACE + EAC Protocol🔗

Yay even more acronyms! The eID Dance is actually a combination of two protocols that run in sequence:

PACE (Password Authenticated Connection Establishment)
EAC (Extended Access Control)

PACE handles the PIN verification and establishes a secure local channel between the card and the eID Client (AusweisApp) while EAC handles the Terminal Authentication (TA), Passive Authentication (PA) and Chip Authentication (CA) between the card and the eID Server.

I just coined it "eID Dance" since I so often had to explain it to people and during the explanation I moved from the position of the eID card to the eID client to the eID server and back while roleplaying as each of them. This resulted in me dancing around the room while explaining it to my colleagues so the name stuck.

Cue another flowchart:

Let's walk through the steps of this diagram:

Initialization: You knock on the door of Bank XYZ. Bank XYZ tells the AusweisApp to get ready.
Consent: The AusweisApp asks you if you're cool with Bank XYZ looking at your data. You type in your PIN.
The eID Dance (PACE & EAC): The magic happens. The card, the app, and the server do a complex cryptographic handshake to establish trust.
Secure Data Exchange: Once trust is established, the data flows safely from the card to the server.

The eID Client (AusweisApp) merely acts as a dumb relay for these encrypted messages and cannot read your data.

Attacker trying to intercept communication after TA is completed

How trust is built step-by-step🔗

1. PACE: "Are you the real card holder?"🔗

Even a perfectly legitimate server cannot make sure the person holding the card is the actual owner of the card.

You (the Citizen) have hired a vigilant Lawyer (the AusweisApp) to mediate for you at a high-security bank. Think of the PACE protocol as the process of securely activating the intercom to talk to the bank.

You securely hand your 6-digit PIN to your lawyer (giving your explicit consent). The lawyer uses it on the outer keypad because the robotic teller inside the steel vault (the eID applet running on the chip) won't even activate the intercom without it. Once the correct PIN is provided, an encrypted and authenticated intercom connects the lawyer to the vault (a secure local channel). Now the vault and the lawyer can communicate without anyone eavesdropping. And only now does a pneumatic tube terminal open up next to the intercom for your lawyer to shuttle messages.

This is the very first gate. No valid PIN, no communication.

( yes there are exceptions for Card Access Number (CAN) and Machine Readable Zone (MRZ) but let's ignore those for now)

PACE Protocol

The AusweisApp acting as a dumb relay for the E2E encrypted channel

✅ PACE: The card needs to trust that you are the legitimate owner.
⬜ TA: The card needs to trust that the server is allowed to ask for data.
⬜ PA: The server needs to trust that the card's data is authentic.
⬜ CA: The server needs to trust that the card's chip is not a software clone.

2. Terminal Authentication (TA): "Are you allowed to ask?"🔗

With a secure local channel established, the card still won't release personal data.

Imagine a detective (the eID Server) walks up to your lawyer and demands to get a copy of the contents of a safety deposit box through the pneumatic tube. Your lawyer doesn't just blindly pass this request along.

The eID Server must present its "Digitally Signed Warrant" AKA Terminal Certificate. They pre-read the detective's terminal certificate to make sure it's not an obvious fake and that the detective's identity matches the warrant. The lawyer checks the signature, the validity dates, the exact boxes the warrant allows them to open (the CHAT bitmask) and why he wants to open them. While also checking if the terminal certificate is actually issued by the DVCA and chains up to the known CVCA root key which the lawyer has in his briefcase. Only if it all looks legitimate does the lawyer pass it into the tube, where the robotic teller (the eID applet) thoroughly verifies it. Since the capsule for the tube is small, the lawyer can only pass along the warrant and the pre-validated certificate chain. But the teller cannot check for example if the TLS certificate of the server matches the one in the terminal certificate's description. That's the lawyer's job to check that before passing it along.

The card walks the terminal's certificate chain up to the known CVCA root key and checks the validity dates. If the signatures check out, the card looks at the CHAT bitmask (the exact boxes the warrant allows them to open). No valid Digitally Signed Warrant → no data.

The CHAT bitmask is part of the Terminal Certificate and loaded during TA. It encodes exactly what the terminal may ever ask for to read from the card.

Since a change in the bitmask would result in the DVCA's signature becoming invalid, the card can trust that the terminal is only allowed to read the data fields that are encoded in the bitmask.

A certificate that permits only reading Data Group (DG) 5 (Family Name) cannot read DG17 (Address) the card will simply refuse it.

This constraint is active for every subsequent command in the session.

✅ PACE: The card needs to trust that you are the legitimate owner.
✅ TA: The card needs to trust that the server is allowed to ask for data.
⬜ PA: The server needs to trust that the card's data is authentic.
⬜ CA: The server needs to trust that the card's chip is not a software clone.

3. Passive & Chip Authentication (PA/CA): "Is this card real?"🔗

Now the card trusts the server. But why should the server trust the card? An attacker could have built a fake "robotic teller" out of software that accepts any warrant and hands out fake identity data.

The server needs to verify that the physical chip is genuine.

Passive Authentication (PA): The server asks to see the chip's unforgeable government stamp (EF.CardSecurity).
Chip Authentication (CA): The server gives the chip a complex mathematical puzzle (a Diffie-Hellman challenge).

Only a genuine chip with the correct secret key physically baked into the silicon can solve this puzzle. If the chip solves it the server and the chip derive a new Diffie-Hellman encryption key for any further communication. This key is mathematically impossible for the AusweisApp to derive.

At this point, the AusweisApp is mathematically kicked out of the conversation. It becomes a blind relay, only passing encrypted bytes back and forth.

If you need a refresher on Diffie-Hellman key exchange, check out this video by Mike from Computerphile.

So now you can see that after the CA step, the server and card share a secret key that is mathematically impossible for the AusweisApp to derive.

Think of this like the robotic teller and the detective sealing all their subsequent communication in encrypted pneumatic tube capsules. From this moment on, your lawyer (the AusweisApp) is effectively blinded. They are just the courier carrying the sealed and locked capsules back and forth over the internet. The lawyer can feel the weight of the capsule (they can read the APDU bytes) and see it exists, but they absolutely cannot decipher the encrypted messages inside. Even if your lawyer turns out to be crooked (a compromised AusweisApp), they cannot read or modify the actual identity data flowing between the vault and the detective.

You can actually read all steps the AusweisApp does in its logs with full transparency.

✅ PACE: The card needs to trust that you are the legitimate owner.
✅ TA: The card needs to trust that the server is allowed to ask for data.
✅ PA: The server needs to trust that the card's data is authentic.
✅ CA: The server needs to trust that the card's chip is not a software clone.

The eID Dance Checklist🔗

The "eID Dance" you saw above is formally called the PACE + EAC protocol. Which is a suite of four protocols that run in sequence.

Each step or "dance move" :P solves a specific trust problem.

Protocol	Trust established	In plain English
PACE	Card trusts the PIN holder (you)	"Prove you know the PIN → get a secure channel between card and client"
TA	Card trusts the eID Server CHAT bitmask sets permission scope	"Terminal, show your government-issued permission slip and exactly what you're allowed to read"
PA	Server trusts the card's data	"Card, show your government digital stamp!"
CA	Server trusts the card's chip	"Card, solve this challenge to prove you're the real chip and didn't just steal someone else's digital stamp"

So remember our PKIs and roles from above? Now we can finally see how they all fit together and how the trust is established between three strangers: the card, the server, and the client.

The full eID Dance in detail🔗

But behold...

Now you may understand why I held back so far with all the details.

Notice how the communication flows: the blue blocks represent messages between the Server and the Client (over the internet), while the red blocks represent low-level APDU commands between the Client and the Card (over NFC/USB).

Crucially: The data flows directly from the Card to the eID Server through an end-to-end encrypted channel established during the CA phase.

10-Minute Summary: Trust Without Intermediaries🔗

The German eID was built on the assumption that every intermediary is potentially hostile. Rather than hoping your phone, the website, and the server are all trustworthy, it uses cryptography to make trust irrelevant for the parties that don't need it. Your data flows directly from a tamper-resistant chip to a government-certified server everything in between is deliberately kept blind.

In short, the EAC protocol guarantees:

The server is authorized: The card verified the terminal certificate chain up to the government root.
The card is genuine: The server verified the card's data signature and won the chip's mathematical challenge.
The citizen consented: The process cannot start without the physical card and the correct PIN.
The middleman is blind: The eID Client (AusweisApp) only relays ciphertext and cannot read the E2E encrypted channel.
No phishing is possible: The TLS certificate of the server is cryptographically bound to the terminal certificate.
Stolen cards do limited damage: Short-lived terminal certs (~1 day) + CHAT limits scope + 116 116 revocation hotline.

...explained in 15 Minutes: "Why are you still reading?"🔗

Before the Protocols Start: Bootstrap Files🔗

Now that you understand the architectural flow, let's look at the actual bytes on the wire. How are the session keys derived? What do the certificates look like? What are the APDU commands?

The security relies on the EAC protocol suite you saw earlier. Here is how its cryptography is implemented in practice.

Before any crypto can happen, the terminal needs to know how to talk to the card. Two files on the chip handle this and they're the very first things read when you tap your card:

EF.CardAccess (File ID: 0x011C) - The "Hello"

Freely readable, no authentication needed
Contains PACE SecurityInfos (which curves, which ciphers)
Example: "I support PACE with ECDH, AES-CBC-CMAC-128, Brainpool P-256r1"

EF.CardSecurity (File ID: 0x011D) - The "Proof of Legitimacy"

Signed by the Document Signer (government)
Contains the Chip Authentication public key
The server validates this signature during PA before trusting the key

Think of EF.CardAccess as the card announcing its capabilities, and EF.CardSecurity as the government's signed stamp of approval on the chip's identity. Now on to the protocols.

✅ Step 1: PACE - The Vault's Intercom🔗

How do we protect a 6-digit PIN from being brute-forced by a bored teenager with a laptop?

The Problem: Your PIN has only 6 digits (10⁶, roughly 20 bits of entropy). If data were encrypted directly with the PIN, an attacker could brute-force it in seconds.

The Solution: We use the PIN only to authenticate an elliptic curve Diffie-Hellman (ECDH) key exchange. The PIN never touches the actual session encryption.

The card (the teller inside the vault) generates a random nonce, encrypts it with a key derived from the PIN your lawyer just provided, and sends it to the terminal. Both sides then use this nonce to tweak the ECDH domain parameters specifically the base point via Generic Mapping (GM) or Integrated Mapping (IM). This means every PACE run uses a different effective elliptic curve, even with the same PIN. The result is a high-entropy session key (the secure intercom channel) that bears no mathematical relationship to the 6-digit PIN.

This provides Forward Secrecy yesterday's traffic stays encrypted even if today's PIN leaks, because the session key was derived from an ephemeral ECDH exchange, not from the PIN directly.

The supported curves are not set in stone. They are defined as of the BSI-TRs right now but given the outlook of PQC and other upcoming challenges the curves may change and they can be updated on the fly in the field.

One more thing: the card enforces a retry counter on PIN attempts. After two incorrect tries, the card is suspended and requires the 6-digit CAN (printed on the front of the physical ID card) to authorize the third and final attempt and make sure you are not a remote attacker. Three wrong tries and the PIN is blocked entirely, requiring the Personal Unblocking Key (PUK) to reset. This behavior is chip-enforced, not software on the eID Client. There's no way to bypass it. You would have to flash a new firmware on the chip which is not possible.

✅ Step 2: Terminal Authentication (TA) - Checking the Warrant🔗

But how does the card know the server isn't just three raccoons in a trenchcoat pretending to be a bank?

Once PACE establishes the local channel (the secure intercom), the Card (the vault) still won't release personal data. First, the eID Server (the detective) must prove its authorization to the Card via a challenge-response protocol over the PACE channel.

As discussed earlier, your lawyer (the AusweisApp) pre-checks this "warrant". Then the card walks the certificate chain from its baked-in CVCA root down to the eID Server's terminal certificate. If every signature checks out, the teller issues a challenge for the detective to sign with its terminal private key.

(For details about certificate validity periods see the Certificate Policy CVCA eID.)

What's actually inside a terminal certificate (CVC)?🔗

Wait, if it's not a standard X.509 certificate, what is it?

Terminal certificates are Card Verifiable Certificates (CVC) a compact ASN.1 format, not X.509. Much smaller, designed to be easily parsed by a tiny chip with limited memory.

The full spec is in ISO-7816-4 but for our usecase this will suffice.

Field	What it contains
CAR (Certification Authority Reference)	Identifies who signed this cert the card uses it to find the right trust anchor
CHR (Certificate Holder Reference)	Identifies the terminal holding this cert
Public Key	The terminal's ECDH/ECDSA public key
Validity dates	Effective date + expiry date terminal certs are valid for ~1 day
Signature	Signed by the issuer

So basic information from any PKI system but the BSI made a few extensions.

Like for example the CHAT bitmask.

Demo CV Certificate

If you look closely you can see at the OID 0.4.0.127.0.7.3.1.2.2 is a application specific tag with the value 000713FF07 if we convert it using cyberchef to binary and reverse the order we get 40 bits 00000000 00000111 00010011 11111111 00000111

Now we can overlay this bitmask

CHAT bitmask TR-03110-4

And as we can see the certificate has at the lowest three bits set.

So its allowed to use the special functions "Age Verification","Municipality ID Verification" and "Restricted Identification"

Bit	Value	Capability
0	1	Age Verifiction
1	1	Municipality Verification
2	1	Restricted Identification
3	0	CAN Allowed
...	...	...
8	1	Read datagroup 1
9	1	Read datagroup 2

and so on.

Since it is a signed object if any of these bits above changet the signature would break and thus the verification chain would break.

✅ Step 3: Passive & Chip Authentication (PA/CA) - The Teller's Puzzle🔗

Okay, the server proved it's a bank. Now it's the card's turn to prove it's not just a software emulator.

Now the Card (the vault) trusts the Server (the detective). But the Server doesn't trust the Card yet! An attacker could have built a software emulator (a fake teller) that accepts any TA and sends back fake identity data.

To prove it is a genuine, government-issued document, the card undergoes Passive Authentication (PA) and Chip Authentication (CA) based on the CSCA root.

PA (Passive Authentication): The Server reads the chip's Card Security Object (EF.CardSecurity), which is signed by a Document Signer (DS) authorized by the CSCA. This value is unchangeable on the card and uniquely identifies it.
CA (Chip Authentication): The Server executes another ECDH exchange using this static public key. The Card's private key never leaves the chip.

In the diagram above, you can see how the server verifies the chip:

Passive Authentication (PA): The server has already read EF.CardSecurity and validated the government signature over the static public key.
Chip Authentication (CA): The server sends its own ephemeral Diffie-Hellman public key to the card.
The secure chip uses its baked-in private key to perform elliptic curve scalar multiplication, computing the shared secret.
The card derives the E2E session keys and sends back an authentication token (a MAC over the session keys) to prove it successfully completed the calculation.
The server derives the same keys and verifies the MAC.

This is the brilliant part: The result of CA replaces the previous PACE session key with a new End-to-End (E2E) session key directly between the eID Server and the eID Card.

The eID Client (AusweisApp) does not have this key. From this moment on, your lawyer is effectively blinded and acts as a dumb relay (pushing those encrypted pneumatic capsules!). Only now does the card actually transmit your personal data (Encrypted with the E2E CA key).

Why can't this be cloned? The chip's public key is verified via Passive Authentication. But knowing the public key doesn't help an attacker they need the private key to complete the DH exchange. And that key is buried in tamper-resistant silicon.

The key derivation in detail🔗

After the ECDH exchange in CA, both sides have the same shared secret a point on the elliptic curve. From that point, two session keys are derived using a Key Derivation Function (KDF):

KEnc the encryption key for all subsequent APDU payloads (AES-CBC)
KMac the MAC key for integrity protection on every command and response (AES-CMAC)

Both keys are completely independent of the PACE session keys from step 1. The PACE channel is effectively torn down and replaced. From this point every APDU is wrapped in Secure Messaging encrypted, MACed, and sequenced. The AusweisApp sees only ciphertext it can't read.

Restricted Identification (RI) - The Cryptography Behind the Paint Analogy🔗

Wait, if I use the same card everywhere, can't the services just team up and track me?

Remember the paint analogy from the 5-minute section? Here's what's actually happening under the hood.

The card has a static private key d_card baked into it at manufacture time. It never changes, never leaves the chip. Each service provider is issued a sector-specific domain parameter by the DVCA. Instead of letting the service choose this parameter directly, the protocol derives it by hashing the service's unique Sector ID into a base point on the elliptic curve: H(SectorID).

When you use RI with a service, the chip computes: pseudonym = d_card × H(SectorID)

That's elliptic curve scalar multiplication. The result is a point on the curve unique per service (because the hashed SectorID differs), stable per card (because d_card never changes), and computationally impossible to reverse (discrete logarithm problem).

Two services cannot link their pseudonyms because:

d_card × H(SectorID_bank) ≠ d_card × H(SectorID_insurance) different base points result in different pseudonyms.
Neither service knows d_card they only see their own output point.
Even colluding, they'd need to solve Elliptic Curve Discrete Logarithm Problem (ECDLP) to recover d_card not happening.

The hashing mechanism ensures that SectorID base points are genuinely different per service and that a malicious server cannot pick specific mathematical values to correlate identities. That's the government's role in making the unlinkability guarantee stick.

The APDU Sequence for RI🔗

Under the hood, Restricted Identification is executed over the established E2E encrypted channel using two specific ISO 7816 APDU commands:

MSE:Set AT (Manage Security Environment Set Authentication Template): The eID Server configures the authentication template by sending the cryptographic Object Identifier (OID) for Restricted Identification along with the service's Sector Public Key (Sector ID).
GENERAL AUTHENTICATE: The eID Server triggers the operation. The chip internally maps the Sector ID to a curve point via the hash function, performs the scalar multiplication with its private key, and returns the computed pseudonym as dynamic authentication data.

Because the chip executes the math internally, the card's private key is perfectly isolated.

Terminal Certificate Lifetime & Theft Resistance🔗

What happens if the bank's servers get hacked and their private key is stolen?

Terminal certificates have a validity of only ~1 day. This eliminates the need for complex Certificate Revocation Lists (CRLs). If a company loses their private key, the damage window is minimal the certificate expires before most attackers can weaponize it. Keep in mind an attacker would need to steal the private key, the domain and the TLS certificate to attempt a phishing attack.
Oh and they would also need a working eID server implementation to even talk to the card. Good luck spinning that up in und 24 hours.

Even if a certificate is abused within its short validity window, the CHAT bitmask limits the attacker to exactly the data fields the legitimate service was authorized to read they cannot escalate to read additional fields.

Certificate Binding: Preventing Phishing🔗

A valid terminal certificate cannot be used on a phishing website the system prevents this with cryptographic binding through hashes:

This diagram illustrates the chain of trust to the eService. The AusweisApp explicitly maps and locks the terminal certificate to the TLS connection by performing these checks before asking for your PIN:

Link 1: Terminal Cert → Certificate Description
The terminal certificate contains an extension (OID 1.3.6.1.4.1.7924.1.1) with the SHA-256 hash of the Certificate Description. The app hashes the received description and compares.
Link 2: Certificate Description → Transport Layer Security (TLS) Cert
The description contains a commCertificates field with the hash of the website's TLS certificate. The app hashes the actual TLS cert of the current connection and compares.

Result: A valid terminal certificate cannot be used on a fake website the hashes won't match.

Privacy-Preserving Revocation🔗

What if your card gets stolen? You can revoke it via the hotline 116 116 (24/7). But here's the clever part:

The system does not maintain a global list of revoked card serial numbers that would be a tracking vector. Instead, each service provider gets their own service-specific revocation list. The card generates a unique revocation token per service. Service providers can only check if a card is revoked for their specific service, not globally.

15-Minute Summary: Cryptographic Architecture🔗

And there you have it the full german eID cryptographic architecture hopefully broken down in a nutshell... somewhat.

Background PKI: The CSCA signs the DSCA, which signs the EF.CardSecurity on the card. The CVCA signs the DVCA, which signs the Terminal Certificate. This establishes a chain of trust from the government to the card and server.
PACE establishes a secure local channel and prevents offline brute-forcing via a low-entropy PIN using ephemeral ECDH.
Terminal Authentication (TA) ensures the server is authorized by validating compact Card Verifiable Certificates (CVC) against the CVCA root, preventing phishing via TLS binding.
Passive & Chip Authentication (PA/CA) guarantee the hardware is genuine by verifying government signatures and computing a shared secret with the card's static private key, establishing the final End-to-End session.
The eID Client (AusweisApp) is excluded from the E2E channel, acting only as a blind relay and guardian.
Restricted Identification (RI) mixes the card's secret base point with the service's domain parameter to generate stable, unlinkable pseudonyms per service.

Conclusion🔗

Congratulations on making it to the end! as the germans would say: "Danke fürs Zuhören!"

The German eID system is complex, but it is also a masterclass in privacy-preserving design. Every step is carefully engineered to minimize trust assumptions, protect user data, and prevent abuse.

Yes, the underlying stack of SOAP, PAOS, WSDL, and ASN.1 CVC certificates is notoriously complex. Building a compliant eID Server feels like fighting the final boss of bureaucracy and cryptography simultaneously. But the end result is arguably the most secure, privacy- respecting digital identity system in the world.

It assumes every intermediary is hostile, trusts no one but the math, and still manages to give you, the citizen, complete sovereign control over your own data.

So the next time the AusweisApp pops up on your phone, you know exactly what kind of cryptographic gymnastics are happening in just a few seconds. And the longest part is remembering your PIN ;)

P.S.🔗

If you really want to go deeper into the dungeons of eID I would recommend the following reading order

Or just read the official BSI documents directly: over at the BSI or in markdown over on github here

THE GERMAN EID EXPLAINED