The german eID🔗

One does not simply explain the 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🔗

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🔗

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🔗

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🔗

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🔗

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🔗

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.

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🔗

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 !

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: The user wants to log in. Bank XYZ acts as the eService and redirects the user to the AusweisApp (the eID Client). The eID Server provides the specific parameters for Bank XYZ.
Consent: The AusweisApp parses what Bank XYZ is asking for and explicitly asks for the user's consent. The user provides the 6-digit PIN.
The eID Dance (PACE & EAC):
- First, the PACE protocol ensures the PIN is correct and establishes a secure local channel.
- Next, Terminal Authentication (TA) proves to the card that Bank XYZ is authorized.
- Finally, Passive and Chip Authentication (CA) prove to the server that your card is genuine.
Secure Data Exchange: Once the dance finishes successfully, your requested data is transmitted securely to the server, and you get logged in.

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🔗

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

So the card itself enforces that no data is being read unless the user physically holds the card to the reader and enters the correct 6-digit PIN so their are the legitimate card holder ba dum tss.

This is the very first gate the system checks no valid PIN, no communication with the card.

( yes there are exception 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

2. Card → Server trust ("Are you allowed to ask?")🔗

With a secure local channel established, the card still won't release personal data. During the EAC flow the eID Client receives a certificate chain from the eID Server. This chain must be signed by the CVCA root key that is stored in the card's chip. The AusweisApp checks this chain for validity and forwards this chain to the card.(It also does some other checks but we get to them later) The card walks the terminal's certificate chain up to the known CVCA root key, checks the validity dates, and verifies the CHAT bitmask is present and signed. No valid government-issued permission slip → 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.

3. Server → Card trust ("Is this card real?")🔗

The server has no reason to trust that it's talking to a genuine chip, since it could in theory be a software emulator feeding fake data.

The individual data fields on the card's eID application are not directly signed, so the server cannot verify them in isolation. Instead, it needs to verify that the physical chip itself is genuine and possesses the private key corresponding to the public key that the government signed at manufacture time.

The card must prove possession of that private key via a cryptographic key agreement that a software clone without the secure hardware cannot fake.

In simple terms:

Passive Authentication (PA) checks the documents integrity and genuinity. The server verifies a government signature over the card's EF.CardSecurity (which holds the chip's public key) to confirm the data was issued by a real authority and was not modified.

Chip Authentication (CA) checks the physical chip. The server and the card perform a Diffie-Hellman key exchange. Only a genuine chip with the correct private key can successfully complete the math to derive the final encryption keys and return a valid Authentication Token.

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. Even if the AusweisApp is compromised, it cannot read or modify the traffic between the card and the server.

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

eID Dance summary🔗

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.

Step	Protocol	Trust established	In plain English
1	PACE	Card trusts the PIN holder (you)	"Prove you know the PIN → get a secure channel between card and client"
2	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"
3	PA	Server trusts the card's data	"Card, show your government digital stamp!"
4	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...

Enjoy its full glory

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 - Securing the First Hop🔗

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 Magic: The card generates a random nonce, encrypts it with a key derived from the PIN (using Advanced Encryption Standard (AES)), 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 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) - "Are you allowed to ask?"🔗

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

As discussed earlier, 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, it then issues a challenge for the server 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)?🔗

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

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 the 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) - "Is this card real?"🔗

Now the Card trusts the Server. But the Server doesn't trust the Card yet! An attacker could have built a software emulator 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, the eID Client is completely locked out of the communication and acts as a blind relay. 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🔗

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🔗

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 triangle of trust. 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 ;)

The eID security stack in all its glory

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