Background informationBackground Information

Welcome to the world of the citizen card: Full of magical numbers and strict data protection provisions. Here are the details:

Contents:

The Mathematical Magic Behind Signatures

On the technical side, every citizen card action is a signature process - whether it's used with electronic banking or an online form. However, the citizen card never signs the entire text. The part that is actually being signed is a "hash value(?)", which is a number generated from the entire text. A primitive hash function works something like this: Each letter is replaced by its position in the alphabet. These numbers are then added together.

Letter S C H M E T T E R L I N G Total
Position in Alphabet 19 3 8 13 5 20 20 5 18 12 9 14 7 153

In reality, much more complex algorithms are used for the citizen card (SHA-1(?), SHA-256(?) or RIPEMD-160 – depending on the application). SHA-256 would create a hash value with a 256 Bit length that is normally written as a 64-digit hexadecimal number. The hash value for Schmetterling would be
d7e3dabc2c95c4c440ee57fb2883188e7f46a9cf51e94674f0e80f7d6db092c4 (calculated with the online hash generator)

Afterwards, this hash value is encrypted symmetrically.

The Magic of Asymmetric Encryption

Asymmetric encryption(?) works a little bit like magic: A different key is used to encrypt a text than is used to decrypt. The other method (symmetric encryption) is still relatively easy to understand: E.g., in order to encrypt the number 5 , the sender multiplies it by 3 (=key) and gets 15. The recipient divides 15 by the key and gets the number 5 again. Done.
In asymmetric encryption on the other hand, there is a keypair, which consists of two parts: the public key(?) (that everyone knows) and the private key(?) (which stays secret). In this case:

  • Information that is encrypted with the private key can only be decrypted again with the respective public key.

And here's the real mystery to it -- it even works in the other direction:

  • Information that is encrypted with the public key can only be decrypted again with the respective private key.

This algorithm is harder to understand because it's like nothing else you usually see in everyday life. This system is probably most comparable to a padlock: The padlock is the public key, since everyone can see and use it. If the padlock is locked, it can only be unlocked again with the right (private) key.

The asymmetric encryption algorithms used by the citizen card are ECDSA(?) (for qualified signatures(?)) and RSA(?) (for advanced signatures(?)). The RSA algorithm is better for explaining how it functions (for ECDSA see Wikipedia):

Computers can take hundreds of years to crack RSA algorithms

The level of secureness with RSA is based on the fact that it is much easier to multiply two numbers together than the opposite: breaking down large numbers into two "parts". Example: Choose two prime numbers, such as 5 and 23 and multiply them together. The result is easy to calculate. 115.
Now try it in the opposite direction. Break down e.g., 143 into both its prime numbers! That is much harder - the only thing you can do is try all the possibilities (btw, the answer is 11 times 13).
There is actually no more efficient method known for cracking the RSA algorithm than trying out all the possibilities one by one. Fast computers are able to find out the answer with smaller numbers, but with really large numbers they would need hundreds of years to work through all the possibilities.

Complete calculation exampleShow detailed calculation example

Here is a detailed example using the prime numbers 3 and 7. We multiply them together and get 21 (this is referred to as the "RSA module"). It would be nice if we could use the key pair (3, 21) as the public key and (7, 21) as the private key. However, this would be too easy because everyone can calculate 7 from the key pair 3 and 21. In doing so, they would already have cracked the private key. So we will need to "hide" the 3 and 7. If we subtract 1 from both numbers, we get 2 and 6. Multiply them together and get 12. Now we choose any number smaller than 12 (and also prime) Let's take e.g. 5. The public key would then be (5, 21). The variable x of the private key is calculated according to the following equation: 5x + 12k = 1; this gives us x=17 as the solution (if k=–7). The private key is the (17, 21). We can forget the numbers 3, 7 and 12 in the meantime.

Now we want to encrypt a hash value, e.g. the value 4. (The hash value must be smaller than the RSA module 21.) We use the private key (17, 21) and calculate 417. This gives us 17,179,869,184. Now we divide this number by 21. This returns 818,089,008 -- but we are only interested in the remainder, which is 16. That is our result.

The recipient receives the value 16 and the public key (5, 21). First, he calculates 165, which gives him 1,048,576. This number is then divided by 21. This returns 49,932 (not needed), with a remainder of 4. Bingo!

Backwards but Still Correct: The Signature

Back to the citizen card. It uses asymmetric encryption, so it has a private and public key. With signatures, this principle is used in the other direction: Although the public key is used for encryption, the private key is used for the signature.
This seems backwards at first glance: anything that had been locked with the private key could be unlocked with the public key again. However, with signatures, the goal is not secrecy, but rather the authenticity (or integrity): If the text can be decrypted with the public key, this proves that the text was encrypted with the respective private key.

What happens at the recipient's end

The recipient receives the actual text, a signed hash value and the sender's certificate. First, the authenticity of the certificate is determined by verifying the signature. Then the recipient decrypts the hash value using the public key. Next, the hash value is calculated from the text again. If both hash values match, then this proves that:

  • the sender is real and
  • the text was not tampered with.

FinanzOnline Login: What Goes On in the Background

Using the e-card

  1. In order to identify you, FinanzOnline requests the identity link(?) from the citizen card software(?). The e-card prompts the user for the card PIN(?).
  2. FinanzOnline verifies the signature of the identity link.
  3. FinanzOnline calculates the sector specific personal identifier(?) from the source PIN.
  4. FinanzOnline also requires you to sign and send a short text (content: "I am applying for access to the secure application with my electronic signature") to the citizen card software.
  5. The citizen card software calculates the hash value from the text (using SHA-1).
  6. The citizen card software sends the hash value to the e-card along with a request to sign the value. The e-card prompts the user for the signature PIN - otherwise it does not have access to the private key.
  7. The e-card encrypts the hash value using the private key and sends the result (=signed hash value) via the citizen card software to FinanzOnline.
  8. FinanzOnline checks the signed text by....
    1. using the public key to decrypt the encrypted hash value,
    2. calculating the hash value from the text and comparing it to the hash value which was sent,
    3. comparing the certificate in the identity link with the certificate sent in the message.
    4. In addition, FinanzOnline checks if your certificate shows up in the list of revoced certficates(?).
  9. You are now logged on to FinanzOnline.

Using the mobile phone

  1. You enter your mobile phone number and the corresponding signature password in a frame on FinanzOnline directly at A-Trust.
  2. A-Trust sends the identity link(?) to FinanzOnline.
  3. FinanzOnline checks the signature of the identity link.
  4. FinanzOnline calculates the sector specific personal identifier(?) from the source PIN.
  5. FinanzOnline also requires you to sign and send a short text (content: "I am applying for access to the secure application with my electronic signature") to A-Trust.
  6. A-Trust calculates the hash value from the text (using SHA-1).
  7. In order to get access to your private key (to sign the hash value), A-Trust sends an SMS with a TAN to your mobile phone.
  8. You enter the TAN (in the FinanzOnline frame) at A-Trust.
  9. A-Trust encrypts the hash value using the private key and sends the result (=signed hash value) to FinanzOnline.
  10. FinanzOnline checks the signed text by....
    1. using the public key to decrypt the encrypted hash value,
    2. calculating the hash value from the text and comparing it to the hash value which was sent,
    3. comparing the certificate in the identity link with the certificate sent in the message.
    4. In addition, FinanzOnline checks if your certificate shows up in the list of revoced certficates(?).
  11. You are now logged on to FinanzOnline.

What Happens During Activation of the Citizen Card?

Before the e-card is activated, it has by default:

  • a key pair from social insurance (for health insurance functions)
  • an ECSDA key pair (for a certificate) - not used anymore at the moment
  • an ECDSA key pair (for a qualified certificate)

Upon activation, the following happens:

  1. FinanzOnline (as identity provider) transmits a signed confirmation to the certification service provider A-Trust, which consists of your name and your social insurance number. FinanzOnline thereby guarantees that you really are who you say you are (you had to present your identification to FinanzOnline when registering).
  2. Using the citizen card software, A-Trust reads your name and social insurance number from the e-card and compares it to the confirmation from FinanzOnline. The most important comparison is carried out on the social insurance number (that is why it doesn't matter if there are small differences between how your name is written on the e-card and how it's registered with FinanzOnline).
  3. A-Trust reads the public key for the qualified certificate from the e-card using the citizen card software. The respective key pair was created when the card was manufactured. The private key never leaves the e-card and it is not even known to A-Trust.
  4. A-Trust then sends your name and date of birth (also read from the e-card) together with the public key to the Central Register of Residents in order to query your CRR(?) entry. The problem is: Your social insurance number is not saved in the CRR. For this step, the way your name is entered on the e-card must exactly match with the way it is entered in the CRR. In case there are several people with the same name and date of birth, A-Trust would have prompted you for your postal code.
  5. A-Trust receives your identity link back from its CRR query (i.e. your CRR number(?) is not given to A-Trust).
  6. A-Trust sends the identity link to the e-card using the citizen card software where it is then saved (protected by the card PIN).
  7. A-Trust creates the qualified certificate (=a file signed with A-Trust's private key) using the public key and enters it in the Directory Service.
  8. The citizen card software writes the qualified certificate to the e-card.
  9. The e-card protects unauthorized access to the private key with the signature PIN.
  10. A-Trust creates an RSA key pair for the non-qualified certificate.
  11. A-Trust creates the non-qualified certificate from the public key and enters it in the Directory Service.
  12. The citizen card software writes the non-qualified certficate and the private key to the e-card (protected by the card PIN).
  13. A-Trust saves the private key of the non-qualified certificate.

The Heart of the Citizen Card: The Identity Link

The most important thing in order for the citizen card to really be accepted and used as personal electronic identification is the ability to verify the user's identity beyond all doubt. Nothing would be worse than a mix-up (e.g. due to people having the same name). The identity link was invented in order to prevent this from happening. It is based on the CRR number(?), which is calculated into a source PIN.

An example of how this calculation worksShow source PIN example

Take the following CRR number(?) as an example: 000247681888. First, this number is converted to hexadecimal format. 000EC35360 (40 Bit). In order to encrypt the number using Triple-DES(?), it needs to be expanded to 128 Bit. To do this, a "seed" value is used as a "filler" (as follows: number seed number number).
The seed value must be 8 Bits long. It is secretly chosen by the SourcePIN Register Authority(?). (Deep in detail: for security reasons, the seed should be as short as possible. That's why 24 Bit seeds are not expanded to 64 Bit, but to 128 Bit instead.)
In our example, we choose FF as the seed and get back: 000EC35360 FF 000EC35360 000EC35360.
This value is then encrypted using Triple-DES (in CBC mode) (using the secret key from the SourcePIN Register Authority); the result is: 42 AD 37 74 FA E0 70 7B 31 DC 6D 25 29 21 FA 49. In order to save memory space, this number is coded as Base64(?): Qq03dPrgcHsx3G0lKSH6SQ==. This is the source PIN.

It is not possible to calculate the CRR number from the source PIN.

The source PIN is written together with the name, date of birth and public key of the qualified certificate in an XML file. The XML file is signed by the SourcePIN Register Authority, and the result is the actual identity link. This is saved directly on the e-card, or with mobile phones, on a high-security data server at A-Trust.

Legal Basis: Electronic Signature

The Electronic Signature Act (SigG) defines an advanced electronic signature as follows:

  As stated directly in the SigG: an electronic signature as used with the citizen card To fulfill requirements of the citizen card
§ 2. 3. a) is uniquely linked to the signatory, The certificate is only issued to one person
§ 2. 3. b) capable of identifying the signatory, The name of the person is written in the certificate.
§ 2. 3. c)

is created using means that the signatory can maintain under his sole control;

  • With the citizen card on the e-card: the card
  • With the citizen card on the mobile phone: the high-security data centre at A-Trust (access is protected by the mobile phone signature password)
§ 2. 3. d)

is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable and

 The hash value.

and a qualified electronic signature:

  As stated directly in the SigG: To fulfill requirements of the citizen card
§ 2. 3a. is based on a qualified certificate and is created using technical components and procedures which comply with the security requirements of the present federal law and the orders issued on the basis thereof.
  • "technical components": the card (or with citizen on the mobile phone: the high-security data centre at A-Trust)
  • "secure technical components": the signature creation device is doubly protected – every application requires:
    • knowledge: PIN codes or signature password
    • possession: card or mobile phone (checked by the TAN in the SMS)

Specifications for the Citizen Card