Background Information

Welcome to the world of the Citizen Card and Mobile Phone Signature! Here you can find further details regarding relevant legal provisions and technical implementations.

Contents:

Electronic Signatures: The Basic Principles

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 Mobile Phone Signature or 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 Mobile Phone Signature or 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 the word Schmetterling would be d7e3dabc2c95c4c440ee57fb2883188e7f46a9cf51e94674f0e80f7d6db092c4 (calculated with the online hash-generator).

Afterwards, this hash value is electronically signed using asymmetric cryptographic methods.

The Asymmetric Encryption

The basic principle behind asymmetric cryptographic methods is best explained by means of asymmetric encryption. To illustrate the difference to symmetric methods, the concept of symmetric encryption is examined first. The method of symmetric encryption is relatively easy to understand: E.g., in order to encrypt the number 5 (the plain text), the sender multiplies it by 3 (the key) and gets 15 (the cipher text). The recipient divides 15 by the key and gets the number 5 again. Done. Of course, more complex keys and more sophisticated encryption methods are used in practice.

Asymmetric encryption follows a slightly different approach: it uses different keys for encrytion and decryption. In asymmetric encryption, there is hence a key pair, which consists of two parts:

  • the public key, which everyone knows. The public key is comparable to a padlock, since everyone can see and use it.
  • the private key, which stays secret. In the above-mentioned padlock example, the private key is the padlock's corresponding key. If the padlock is locked, it can only be unlocked with the private key of the key pair.

In case of asymmetric encryption, the following properties apply:

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

The Mobile Phone Signature or Citizen Card uses asymmetric cryptographic methods to compute electronic signatures. The asymmetric algorithms used are ECDSA (for qualified signatures) and RSA (for advanced signatures). The RSA algorithm is better for explaining how it functions (for ECDSA see e.g. Wikipedia):

The security of RSA is based on the fact that it is much easier to multiply two numbers than to break down large numbers into two "parts". Example: Choose two prime numbers, such as 5 and 23 and multiply them. The result is easy to calculate. It's 115.

Now try to break down e.g., 143 into its prime numbers! That is more complicated - the only way to solve this task is the try and error principal. There is actually no more efficient method known for cracking the RSA algorithm than trying out all the possibilities one by one (by the way: the answer to the above example is 11 times 13). Powerful computers are able to find out the answer with smaller numbers, but with really large numbers they would need a long period of time to work through all the possibilities.

The Signature-Creation Process

The Mobile Phone Signature and the Citizen Card use asymmetric methods to compute electronic signatures, so they have a private and public key. Hence, they rely on similar concepts as asymmetric encryption. However, it is important to point out the differences between encryption and signature creation.

  • Encryption: The public key is used for encryption, the private key is used for decryption.
  • Signature creation: The private key is used to "encrypt" the hash value. The public key is used for "decryption". This means that the validity of a signature can be verified with the public key. The reason: the goal of electronic signatures is not secrecy, but the authenticity and integrity of data: If a text can be decrypted with the public key, this proves that the text was encrypted with the respective private key. Note that the signature-creation operation does not correspond to encryption with the private key for all asymmetric cryptographic algorithms. This applies to RSA, but does not e.g. for ECDSA. Irrespective of the particular algorithm, the private key is always used to create a signature. For the sake of simplicity, we have assumed here that a signature-creation operation corresponds to an encryption operation with the private key.

Concretely, the recipient of a signed document receives the actual text, a signed hash value of the text, and the sender's certificate, which contains the sender's public key. 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 authentic and
  • the text was not tampered with.

FinanzOnline Login: What Goes On in the Background

Using the e-card as Citizen Card

  1. In order to identify you, FinanzOnline requests the identity link from the Citizen Card software. The e-card potentially (depending on the actual card generation) 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.
  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 (i.e. the 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 Signature

  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.
  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 (i.e. the 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 Functionality on your Health-Insurance 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 of the Citizen Card via FinanzOnline, the following happens:

  1. FinanzOnline (as identity provider) transmits a signed confirmation to the trust 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 (i.e. a file signed with A-Trust's private key) using the public key and enters it in the certificate database.
  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 certificate database.
  12. The Citizen Card software writes the non-qualified certificate 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 Identity Link

The most important thing in order for the Mobile Phone Signature or 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. 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 Source PIN 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.

XML Definition of the Person Identity

Legal Basis of the Electronic Signature

The regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC, OJ No L 257/73 of 28 August 2014 (“eIDAS-Regulation”), and the Signature and Trust Services Act (official title: Signatur- und Vertrauensdienstegesetz – SVG,BGBl. I Nr. 50/2016) define an advanced electronic signature as follows:

  • Art 26 lit. a eIDAS-Regulation) An advanced electronic signature is uniquely linked to the signatory. This requirement is fulfilled by the Citizen Card and Mobile Phone Signature, as the certificate is only issued to one person.
  • Art 26 lit. b eIDAS-Regulation) An advanced electronic signature is capable of identifying the signatory. This requirement is fulfilled by the Citizen Card and Mobile Phone Signature, as name of the person is written in the certificate.
  • Art 26 lit. c eIDAS-Regulation) An advanced electronic signature is created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control. This requirement is fulfilled by the Citizen Card and Mobile Phone Signature. Using the Citizen Card, the signatory is in physical possession of the card. Using the Mobile Phone Signature, access to the high-security data centre at A-Trust is protected by the signature password.
    The “sole control” of the signatory therefore does not have to consist in physical possession but can also be ensured by technical and organisational measures. Since the very same interpretation of this requirement emerged in all EU Member States in recent years, the creation of remote electronic signatures is now expressly provided in the eIDAS-Regulation (see also Annex II (3) and recital No 52 of eIDAS-Regulation).
  • Art 26. lit. d eIDAS-Regulation) An advanced electronic signature is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable. This requirement is fulfilled by the Citizen Card and Mobile Phone Signature, as any modification of the data can be detected by means of the hash value.

For qualified electronic signatures the eIDAS-Regulation defines the following requirements:

  • Art 3 (12) eIDAS-Regulation) A qualified electronic signature is based on a qualified certificate for electronic signatures and is created by a qualified electronic signature creation device. This requirement is fulfilled by the Citizen Card and Mobile Phone Signature. The "technical components" are implemented by the card (Citizen Card) or by the high-security data centre at A-Trust (Mobile Phone Signature). Both components are protected by means of multi-factor authentication (factors knowledge and possession) and fulfill the requirements for qualified electronic signature creation devices according to Art 29 eIDAS-Regulation.

Integrating the Citizen Card

The modules "MOA-ID" and "MOCCA" can be used to integrate the Citizen Card into your own web applications. They are available for free on the Joinup Open Source Platform. Find some installation tutorial videos on the website of Exthex.

UBIT of the Austrian Chamber of Commerce provides a list of companies that offer services and expertise on Mobile Phone Signature and Citizen Cards at www.experts.or.at.

Integrating the Mobile Phone Signature

The Mobile Phone Signature can be called in the same way as a local CCE or the Online-CCE.

You can find a list of certificates accepted by the Mobile Phone Signature at https://labs.a-trust.at/.

Specifications of the Citizen Card