Mobile-ID and smart cards by the example of Estonian ID-card

Sisukord

Estonian ID-card
Mobile-ID
- Mobile-ID authentication protocol
Smart-ID
Further reading
Moodle forum and feedback form

Estonian ID-card

Estonian ID-card is an identification card that can also be used in the digital world. The most important part of the ID-card is the chip which contains a microprocessor and some memory. The chip's memory contains two secret keys, the key which is used for authentication and a key that is used for giving digital signatures.

From the latter, it becomes obvious that the ID-card uses public-key encryption (also known as asymmetric encryption). A reminder: in public-key cryptography, the key pair is generated together, and it consists of a private key and a public key. The private key has to be protected, and it can be used to issue signatures and to decrypt messages that were encrypted to the corresponding public key. The corresponding public key is public, and it can be used for encryption and for verifying the digital signatures issued with the corresponding private key from the same keypair.

The first ID-cards contained 1024-bit RSA keys, but since 2011 2048-bit RSA keys were issued. Starting from 2017/2018, 384-bit ECC keys are used.

All private key operations are done in the card's microprocessor. This means that the private keys never leave the chip. It is not known how the private keys could be extracted from the chip. Thus, in order to use the ID-card, the computer needs software to communicate with the chip. Therefore, one has to install the ID-card software before the card can be used.

ID-cards issued between 2011-2019 have a chip on the back side. The older version is shown on the left and the newer one that was issued since 2011 on the right.

Starting from 2019, ID-cards have a new design and support for near field communication technology (NFC).

Digi-ID

Digi-ID is a smart card that is similar to an ID-card, but it can only be used in a digital environment. Digi-ID does not contain a photo of the owner, and therefore it can not be used as an identification document.

ID-card software

To use the ID-card in a digital environment, one needs to use a smart card reader. In addition, special software is needed which can interact with the ID-card chip. It is important that the ID-card software would be installed from an authentic source. Thus, always use the id.ee website for downloading ID-card software.

Why is it relevant to download the installation software from that site? If the software is downloaded and installed from an unknown source, then the user can not be sure that it is not malicious. We know that the identity of the website id.ee is verified by the https certificate, and therefore we can be quite sure that the software that comes from that site is authentic.

ID-card software contains:

Digidoc client (since 2018, it is named DigiDoc4):
- allows creating digital signatures
- allows verifying digital signatures
- allows to open / save files that are in a DigiDoc container
- allows to encrypt and decrypt files
TeRa client
- Time-stamps old DDOC files and places them inside newer BDOC format containers. This is necessary to avoid future disputes as DDOC used the SHA-1 hash function that is now considered unsuitable for that use.
on why this tool is needed: Frequently asked questions about TeRa
instructions: Timestamping application TeRa
Browser extensions
- allow the browsers to interact with the ID-card and therefore allow to authenticate and give digital signatures through the browser. Without the browser extensions, it would be impossible to do online banking with the ID-card.
ID-card utility (since 2018, this has been integrated into the new DigiDoc4):
- reading information about the card owner
- registering the certificates
- saving the certificates to a file
- changing the PIN and PUK codes
- unlocking a locked PIN code
- viewing the card usage statistics

Image source: id.ee

Updating certificates remotely

Starting from March 2016, it is possible to update ID-card certificates remotely from the ID-card utility. Whether the certificates need to be updated can be seen from the ID-card utility itself. During the update, a stable internet connection is required.

The remote update functionality was added due to the fact that older certificates didn't conform to conventional format (a non-standard interpretation of a single bit in the public key) and thus would have been rejected by future versions of Google Chrome. This non-standard format didn't have any effect on security, but Google Chrome (and later also other browsers) started to validate certificates very strictly.

The second wave of remote updates was in 2017 when older SHA-1 based certificates were replaced with certificated signed using stronger SHA-256 hash. The reason was that at the beginning of 2017, the collision resistance of SHA-1 was broken, and the hash function was deemed insecure for future use in digital signatures. The SHA-1 based certificates had to be replaced before July 1, 2017. After that deadline, they were automatically revoked, and one would have had to get a new ID-card.

The third wave of remote updates was caused by the vulnerability found in the ID-card chip. It was possible to update the vulnerable cards until the 31st of March 2018. More information about the vulnerability can be found from the corresponding section.

The ID-card browser extensions

Firefox

To view installed extension navigate to: "Tools -> Add-ons -> Extensions". The ID-card extension is named "Token signing". You can disable the extension with the "Disable" button, but then you cannot use the functionalities of the ID-card with Firefox.

Google Chrome

To view the installed extension on Google Chrome, you will have to write: chrome://extensions to the address bar. The older version of the ID-card software was distributed as a Google Chrome plugin, but the new one is distributed as a browser extension. Browser vendors have ended the support of native plugins in order to increase to overall security level. The name of the ID-card extension is "Token signing", just like in Firefox.

How to choose the smart card reader

The software for the Estonian ID-card supports tens of different smart card readers. The list of supported smart card readers can be seen from the following webpage: Useful information about smartcard readers.

How to choose the best smart card reader?

A smart card reader (source)

The main difference between the smart card readers can be seen visually. Most of the smart card readers do not have PIN-pads, i.e., they do not contain buttons that can be used to enter the PIN code. The cheaper smart card readers do not have the PIN-pad, and actually, this is a major security issue as then the PIN code has to be entered from the keyboard. However, if the PIN code is entered on the keyboard, then the operating system has access to the PIN code, and therefore, if the operating system has been infected with malware, then also the malware has access to the PIN code. A malware that is able to follow and copy the information that is entered on the keyboard is called a keylogger. An overview of such software can be found from: Keystroke logging. Thus, the simple smart card readers get the PIN codes from the keyboard, and the software transfers the information to the card reader driver, and that makes them vulnerable to keyloggers.

A smart card reader that contains a PIN-pad (source)

The smart card reader, which contains a PIN-pad, is more secure as the PIN code is entered directly on the reader, and therefore the PIN goes directly to the chip. Thus, an infected operating system is not able to read the PIN codes, and if the malware can not access the PIN codes, then it also can not use the smart card. Therefore, the Estonian Information System Authority suggests using smart card readers which contain PIN-pads. Some of the smart card readers that are integrated into keyboards work as the readers with the PIN-pads, i.e., the PIN goes directly into the chip.

Authentication with the ID-card

The Estonian ID-card allows to identify or authenticate the card owner in the digital world. For the identification of the user, a secret key, an authentication certificate, and PIN1 are used. The PIN1 is a numeric code that gives indirect access to the authentication key (secret key of the first key pair) that is located in the ID-card chip.

To authenticate himself/herself, the card owner has to prove that he/she is able to perform operations with the authentication key. A server can request client-side authentication and then begin by sending the client (browser) a random number. The client's browser now requests the PIN1 so that the authentication key can be used to sign the random number that was sent by the server. Now the signed value is sent back as proof that the user has access to the authentication key. The server can use the public key of the client to verify the signature and thus complete the authentication. By using such a method, the server assumes that the smart card with the PIN codes is usable only by the client.

It is important to remember that all operations are done inside the chip, and the secret keys never leave the chip. Mutual authentication of TLS (or SSL) is used to authenticate an ID-card owner. In that case, the authentication private key is stored inside the ID-card chip. However, the mutual authentication offered by TLS can also be used without hardware-based keys, for example, by loading the keys into the browser's key storage. The latter requires the user to generate keys by themselves, manage the keys and also to configure the browser. Due to technical difficulty, this is very rare.

Digital signatures and the Estonian ID-card

Digital signatures used to be regulated in Estonia with the Digitaalallkirja seadusega (Digital Signature Act). However, now it is replaced with the Electronic Identification and Trust Services for Electronic Transactions Act. In legal terms, the digital signature is similar to a handwritten signature. However, it is important to understand that a digital signature is valid only when it is issued with a valid certificate.

To issue digital signatures, one needs access to: the signing key that is inside the ID-card chip, signing certificate, and PIN2. PIN2 gives indirect access to the signing key, i.e., it allows the key to be used for some operations. It is important to note that there are two secret keys on the ID-card chip; one is used for authentication and the other for signing.

The certificate binds the public key of the card owner with the card owner's identity. The certificates of the ID-card holders are signed by the Estonian root certificate authority SK ID Solutions AS (previously known as AS Sertifitseermiskeskus). The signing certificate contains the public key that is associated with the secret key that is used for signing. The certificate is publicly available, as others should get access to the public key in order to verify the digital signatures.

It was previously mentioned that a digital signature is valid only if the signature was given with a valid certificate. So, why are the digital signatures that are given with an invalid certificate considered invalid? One of the reasons is that the ID-card might have been stolen. In that case, it is recommended to invalidate the certificates in order to prevent damage. But how can one check if the certificate was valid while the signature was given? Actually, this is done each time when a digital signature is given. An automatic request is made to the certificate authority's server in order to check the validity of the certificate, and the corresponding signed proof is added to the digital signature file.

Digital signatures can be given with:

DigiDoc4 software
Estonian State Portal
Dokobit portal: https://www.dokobit.com/et

The screenshot is taken from an .asice container that is shared as an example on the id.ee website.

A theoretical overview of digital signatures

We already know that public-key cryptography is used to create digital signatures. During digital signing the data that is going to be signed is processed by using a private key.

One of the properties of the smart cards and also of the Estonian ID-card is the fact that the private key never leaves the chip, and it is not possible to copy the private key. Therefore, in order to process the data with the private key, one has to send the data into the ID-card chip. Now you might notice a problem - the document that has to be signed might be very large, and the ID-card chip contains only a small microprocessor. Therefore, it is not wise or possible to send the document directly to the ID-card chip. Instead, a hash is computed from the document, and the hash is sent to the ID-card chip. The value of the hash is quite small, and the ID-card chip is able to process it with the signing key. Therefore, it is important to know which cryptographic hash function was used to create the hash, as this information is required when one wants to verify the signature. Thus, the name of the used hash function is added to the container that contains the digital signature. Of course, the container also has to contain the original document.

To verification of the digital signature actually consists of three steps. First, the signed hash value has to be processed with the corresponding public key. Then the cryptographic hash function is used to create a new hash of the initial document that was packed inside of the digital signature container. Finally, the hash gotten from the signature with the help of a public key and the newly created hash are compared, and when they are equal, then the signature has not been tampered with, and the verification is successful, i.e., we know that the given document was signed. However, there is one more step that has to be done in order to make sure that the signature legally holds. It is necessary to check that the corresponding certificate was valid when the signature was given.

An overview of digital signing (source).

The confirmation of certificate validity

According to the Electronic Identification and Trust Services for Electronic Transactions Act only these digital signatures are valid which are given with a valid certificate.

 § 17.  Suspension of certificates 
 (5) E-signatures or e-seals given during the period when a certificate is suspended are invalid.

More specifically, the signing certificate had to be valid during the time when the signature was issued. Therefore, every time the signature is given, the validity of the certificate has to be checked. This check is done in real-time with the help of Online Certificate Status Protocol (OCSP) which is described in (RFC 2560). When OCSP is used, then the client asks the server if a given certificate is valid, and the server responds with a signed answer which contains the information about the validity of the certificate (is valid, is not valid, no information) and the date/time when the confirmation was given.

The validity confirmation service. The left side of the picture describes that a document is signed, in the middle is the OCSP service that confirms that the certificate is valid and on the right are the timestamp, certificate repository, security log. (source).

SK ID Solutions AS keeps a security log for all validity confirmations. Thus, every time a new signature is given, a new entry is added to the security log. The security log also contains all changes regarding the certificates (invalidations, suspensions, etc.). The entries of the security log are cryptographically linked so that each new log will depend on the previous logs, and therefore the security log can be seen as a linear chain. Such a chain can not be faked, not even by SK ID Solutions itself. This means that it is not possible to insert a log somewhere into the chain. The current state of the security log is represented by a hash value, and this is periodically published. SK ID Solutions publishes the hash value of the security log in the Estonian daily newspaper Postimees. Therefore, everyone can check the hash values, and it is not possible to modify the security log as otherwise someone would notice it.

Trusted timestamping
More information about the security log can be found from (unfortunately it is only in Estonian)
- Overview of MyID portal
- MyID portal

Issue with the timestamp

In 2019 researchers from the University of Tartu published a paper, which showed that the timestamps included in the digital signature containers could be updated. This was possible as the timestamp itself was not included in the signature; it was additional information in the container. However, the finding can lead to interesting legal outcomes. For example, let's consider a signature that is given while the corresponding signing certificate is suspended. Such a signature would not be legally valid. However, in case the timestamp of that signature can be updated, it may happen that the certificate is no longer suspended. For the verification software, it would now appear that the signature is legally valid.

More information about the found issue can be read from: Q&A: Time of signing in the Estonian digital signature scheme. The scientific paper can be read from: Time of signing in the Estonian digital signature scheme.

How to use the encryption functionality provided by the ID-card?

The Estonian ID-card together with DigiDoc4 provides an encryption functionality. Instructions for using the encryption functionality can be found from: Encryption and decryption of documents

The screenshots are taken from the id.ee website.

The encryption functionality uses the keys from the first key pair, i.e., the key pair that is used mostly for authentication. What happens when some information is encrypted with the ID-card, and the chip is damaged, or the card is stolen / lost? When the chip is damaged or when the card is lost, then the encrypted data can never be decrypted, and this is the main reason why the Estonian ID-card should not be used to create encrypted data that should be stored for longer periods. The encryption functionality is useful for sending encrypted emails to other ID-card owners. However, in case the information inside the encrypted CDOC container needs to be stored, it has to be extracted from that container and saved somewhere else.

A more technical overview of the encryption provided by the ID-card

The public key of the recipient is used to send encrypted emails. We know that the data that is encrypted with the public key can only be decrypted with the corresponding secret key. However, we also know that the microprocessor inside the ID-card is not very powerful, and it is also not possible to copy the secret keys from the chip.

The solution is provided by symmetric encryption. First, a new random key is generated for the symmetric encryption algorithm. Then the symmetric encryption algorithm and the newly generated key are used to encrypt the data. Finally, the symmetric key is encrypted with the recipient's public key. Therefore, when sending an encrypted email, actually the data is encrypted with a symmetric encryption algorithm and the public key is used to protect the key used by the symmetric encryption algorithm.

Security of the ID-card

The chip on the Estonian ID-card is built in a manner that should prevent the leakage of secret keys. It should not be possible to access the part of the chip where the keys are stored, and therefore an attacker should not be able to copy the secret keys from the chip. Therefore, it should not be possible to make a copy of the ID-card. Previously there have been guesses that in theory it might be possible to read the secret keys of the chip in a specific laboratory, but this has never been tried.

Possible attacks:

Practical attacks:
- Using a lost ID-card - What could an attacker do if he finds an ID-card.
- Padding oracle attack (from 2012, not relevant anymore)
  - ID-card must stay in the card reader for hours or days
  - the attacker will have to know the PIN
  - not applicable to cards that were issued after October 2014
- Using the vulnerabilities in the DigiDoc software
  http://www.id.ee/?lang=en&id=34283#3_7_2
  “Fixed one critical bug in the DDOC parsing routines. By persuading a victim to open a specially-crafted DDOC file, a remote attacker could exploit this vulnerability to overwrite arbitrary files on the system with the privileges of the victim.”
More theoretical attacks (i.e., attacks that are possible but have not been used):
- It is possible to create fake ID-card software that is under the control of the attacker but which looks and behaves exactly like the authentic software. This attack is only possible if the computer is already infected. This kind of an attack could be useful when a public computer that is used by many people is infected.
- It is possible to create a malicious browser plugin that could modify the interaction between the user and the web server. The malicious browser extension could change the details of an online bank transfer. This attack is possible if the computer is already infected or if the attacker is able to get access to the computer. It is important to understand that when issuing a signature via the browser extension, the data that is going to be signed is not displayed to the user. For example, when confirming a bank transaction, the website of the bank shows information regarding the transaction and asks the user to issue a legally binding signature. However, the data (more specifically, the hash of the data) that is going to be signed is not displayed, and thus the user has to trust that the bank would not replace the transaction data with something else. In some cases, you may be able to download the signed container later, but this option is not always provided. When trying this out, check that your signature would also be on the transaction, not only the bank's signature.
- It is possible to create malicious software that copies the user's PIN codes and then uses them to sign documents or to do online bank transfers. This attack also requires that the attacker is able to infect the computer. So, how difficult is it to infect computers with malware? We will talk about malware in the last few lectures, but just as an exercise, you can think about the following situation:
  - An attacker is able to use a vulnerability in a widely used software product, let's say a browser, and then is able to infect all computers that run the software. If the vulnerability is known only to the attacker, then the users may not even know that they are infected. Now, the attacker might wait until the ID-card is used to collect the PIN codes and then do whatever he / she wants with the ID-card if the card is connected with the smart card reader that does not contain a PIN-pad.

Some ID-card keys were generated outside of the card

A recent publication by Arnis Paršovs describes how he found out that for some ID-cards, the keys were generated outside of the card by the card manufacturer. This violated the agreement that the card manufacturer Gemalto had with the Estonian state. Thus, the Estonian state sued Gemalto and demanded 152 million as a penalty. In 2021, the court case ended with a settlement, in which Gemalto agreed to pay 2.2 million euros in compensation. The research paper, along with the slides, can be found from https://www.usenix.org/conference/usenixsecurity20/presentation/parsovs. In case you with to get a broader overview of the issues related with the Estonian ID-card ecosystem, we recommend to read the PhD thesis of Arnis Paršovs.

Security risk from September 2017

On the 5th of September it was publicly announced that the Estonian ID-cards might be vulnerable to a new kind of an attack. The issue was found and reported by Czech scientists who later published a paper at ACM CCS 2017: The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli.

The problem was in the card chip that was manufactured by Infineon and provided to Estonia by Gemalto. The same problematic chips were also in use in other countries and corporations. Estonian ID-card started to use this chip in October 2014. Therefore, older ID-cards that were issued before October 2014 are not affected by the vulnerability. Still, there are about 750 000 cards that have been issued with the new chip.

The issue is related with the way how random numbers are generated. As you know by now, it is important that cryptographic keys would be generated randomly and for that random numbers have to be generated. The problematic chip tried to speed up the key generation process but implemented it in an insecure way that yielded a smaller distribution of possible RSA public keys. The Czech scientists found that since generated RSA keys are from a narrower distribution, it is possible to deduce private keys from vulnerable public keys. For correctly generated RSA keys, this should be computationally impossible. Other scientists found that to break a vulnerable 2048-bit key, it would cost on average $20,000 and at maximum $40,000. Interestingly, most of the cost is associated with renting enough cloud computing power. Therefore, organisations that already own supercomputers could break vulnerable keys for much less.

At this time, the Estonian government decided to temporarily close the public LDAP database that allows querying certificates by their owner's ID code. This by itself did not protect the vulnerable keys but made it more difficult for attackers to generate a database of possibly vulnerable keys to crack. Certificates with vulnerable public keys were suspended on November 3, 2017. These cards had to be remotely updated with new certificates before March 31, 2018, to continue using them.

The remote update replaced part of the card's firmware, generated new key pair and requested a signature for the newly generated public key from the Certificate Authority (AS Sertifitseerimiskeskus). The new card firmware uses elliptic curve cryptography (ECC) instead of RSA for cryptographic operations as this encryption scheme was not affected by the insecure implementation.

More information on the vulnerability and its mitigations can be found from the RIA's Cryptographic Algorithms Lifecycle Report 2017, chapter 3.

What is the probability of guessing the PIN code?

Length of the PIN	Probability of a right guess	Number of possible PIN codes
4	0.0003	ten thousand
5	0.00003	hundred thousand
6	0.000003	million
7	0.0000003	ten million
8	0.00000003	hundred million
9	0.000000003	billion
10	0.0000000003	ten billion
11	0.00000000003	hundred billion
12	0.000000000003	trillion

Thus, the theoretical probability of guessing the PIN1 is 0,0000000000027000000027 (2,7000000027e-12), but this would be the correct probability only if the PIN1 codes would be uniformly distributed. Actually, PIN1 codes are not uniformly distributed; a large majority of users have the default PIN1 that is 4 digits long. The users do not want to remember long and complex PIN codes and therefore, there is a high probability that a randomly chosen ID-card has a four or five-digit PIN1.

But what are the most commonly used PIN codes? Such information can be found from people who have analyzed leaked PIN codes. For example, the following blog post analyzes the frequencies of PIN codes: http://www.datagenetics.com/blog/september32012/.

ID-cards in other EU countries

Several EU member states have given out ID-cards, but they are not compulsory in most of the member states, and therefore only a fraction of the citizens own one. All of the ID-cards are machine-readable (look at the back side of the Estonian ID-card), but only a few contain a chip that allows them to be used in the digital environment. In addition to Estonia, chip-based ID-cards are also in Austria, Belgium, Czech Republic, Finland, Germany, Italy, Liechtenstein, Lithuania, Portugal and Spain (Source).

The chip-based ID-cards can be very different depending on the manufacturer and of the design. Even when the hardware is the same, then it does not mean that the software is similar. Each country has their own root certificate authority with which the software may have to interact. Therefore, a universal ID-card software would have to be aware of the technical solutions of each supported country, and in addition, it should be able to interact with the corresponding certificate authorities.

STORK and its successor STORK 2.0 were projects funded by the EU. It was aimed to create a system where different European ID-cards and digital identification systems could interoperate without problems. Estonia was participating in both of these projects.

In addition, countries are slowly moving towards cooperation regarding digital signatures. Recently Estonia moved from the Estonian specific digital signature format DDOC to the BDOC format, which follows the ASiC signature container standard that was given out by ETSI (European Telecommunication Standards Institute). More information about the switch from DDOC to BDOC can be found from the following link: BDOC file format, what is it, when will it replace DDOC format and what's needed for transition?. The encryption format used by the Estonian ID-card software is already using the international XML-ENC standard. Examples of container files are available on the id.ee website.

eIDAS

According to EU eIDAS regulation, starting from July 2016, all EU member states must accept digital signatures from other states that correspond to or exceed the signature level used in their own state. eIDAS has four signature levels (starting from the lowest quality):

Other - Just some sort of signature, e.g. using a self-signed certificate or even drawing on a touch screen. It's still better than nothing. For example, if a person has used the same key pair for years, then we can at least say that with high probability, it is the same person.
Advanced electronic signature (AdES) - same as other, but using some standardised signature format accepted by ETSI.
Advanced electronic signature with qualified certificates (AdES/QC) - Like ES, but the certificate is signed by a registered certificate authority (CA). The certificate subject has been identified by the CA. The private key is available as a file or put on a non-certified smart card.
Qualified electronic signature (QES) - Like AdES/QC, but in addition, the private key is on a certified hardware token (smart card). This type of signature is equal to a handwritten one according to the eIDAS regulation. Estonian ID-card provides QES.

Mobile-ID

Mobile-ID is a service provided in Estonia that allows both to identify yourself in the digital environment and to give digital signatures. As the name says, the service is provided with the help of a mobile device, but it is important that the mobile device uses a special SIM card. The SIM card of the Mobile-ID contains the private keys, and the corresponding public keys are tied with the certificates that are signed by the Estonian root certificate authority (SK ID Solutions AS). When compared with the ID-card, the Mobile-ID does not have the functionality that allows encrypting documents.

Mobile-ID that have been issued since 01.02.2011 can be legally used for digital identification. Mobile-ID is issued according to the Identity Documents Act. The Mobile-ID certificates that have been issued after 01.02.2011 are valid for three years. Starting from 01.01.2015, it was extended to five years. Therefore, after the five year period has ended, it might be necessary to sign a new Mobile-ID contract with the mobile network operator in order to get a new SIM card.

If you would like to get a Mobile-ID, then read the following: Application of Mobile-ID. It is important that before signing the contract, one has to identify himself/herself for the mobile network operator. After the contract is signed, the mobile network operator will provide the client with a suitable SIM card. However, in order to start using the Mobile-ID, one has to apply for the certificates. This can be done on the Police and Border Guard website by using a valid ID-card or a valid digital identity card.

Benefits of Mobile-ID:

no need for the smart-card reader
no special software is needed
allows authenticating without using a code card, ID-cards, PIN calculator
works on all modern mobile devices (both old mobile devices and smart mobile devices)

In order to safely use Mobile-ID one has to check:

When authenticating with Mobile ID: the name of the service displayed on the mobile device has to correspond to the e-service or website.
The verification codes have to match on the mobile device and on the website
For authentication, only PIN1 is asked
For digital signing, PIN2 is asked
PIN and PUK codes must not be kept in the mobile device or near the mobile device.

If you will receive an unknown SMS that asks to enter the PIN code of the Mobile-ID and you haven't requested to authenticate using the Mobile-ID, then the PIN code should not be entered as someone might be trying to steal your identity.

If the PIN codes of the Mobile-ID have been lost or stolen, then one has to contact the mobile network provider in order to close the Mobile-ID service. If a mobile device with an activated Mobile-ID SIM card is lost / stolen / or gotten into the wrong hands, then one should call the customer service of the mobile network provider as soon as possible in order to close the Mobile-ID service. Here are the customer service numbers of the most common mobile network providers in Estonia:

Elisa customer service: +372 6600 600
EMT customer service: +372 6397 130
Tele2 customer service: +372 686 6866

Mobile-ID authentication protocol

Next, we provide a brief overview of the user authentication protocol used in the Estonian mobile-ID system. More details can be found from a research paper by Laud and Roos, which was published in 2009.

However, the protocol was somewhat changed in 2020. More specifically, the DigiDocService was replaced by a REST API. The change simplified the authentication protocol. For example, previously the hash that was going to be signed was generated by two different parties, but now the hash is generated solely by the service provider that requests the signature from the Mobile-ID user.

In general, the Mobile-ID protocol works in the following way. First, the user selects Mobile-ID for authentication or signing. Next, the service provider creates a random value / hash of the document to be signed. That value along with other relevant information is sent to the mobile operator via the Mobile-ID REST API. The mobile operator uses a special SMS to relay the information to the end-users device. The special OTA SMS is automatically recognised and processed by the SIM card software, which means that the user does not see these SMS messages. The Mobile-ID application calculates a four digit control code from the hash found from the OTA SMS. The control code is displayed to the end user. Now, the user has to check whether the code shown by the service provider (for example on a web page where you want to authenticate) matches the code that is displayed on the phone. In case the codes match the user is asked to sign the message by entering a PIN code (PIN1 for authentication and PIN2 for legally binding digital signatures). If a correct PIN is inserted the corresponding private key operation is done inside the Mobile ID SIM card, i.e., the hash value is signed with a private key. The resulting value is sent back to the service provider via a SMS. It is important to note that the exchanged information is encrypted so that the mobile operator can not see the contents of the SMS message. Once the signed value reaches the service provider, the service provider verifies the signature. If a valid signature was given, the user is authenticated or the signature process is approved by the service provider.

The security of Mobile-ID

The security level of using the Mobile-ID can be compared with the security level of using the ID-card with the smart card reader that has a PIN-pad. If an ID-card is used with a card reader that does not have the PIN-pad, then a keylogger might save the PIN codes and use the functionalities provided by the ID-card. However, if Mobile-ID is used with two independent devices, a keylogger on the computer can not get access to the SIM card where the secret keys are located. Unfortunately, it is nowadays common to use the Mobile-ID from the same device, which contains the Mobile-ID SIM. In that context, advanced malware may become a problem.

However, by using Mobile-ID, more parties are involved, e.g., the mobile network provider and Mobile-ID REST service provider, who have to be somewhat trusted. It is important to note that the communication between the involved parties is encrypted.

Since 2015 new Mobile-IDs are using elliptic curve cryptography and also 2048-bit RSA.

Smart-ID

Smart-ID is a service that provides both authentication and signing functionalities. In Estonia, the service is offered by SK ID Solution, but the underlying technology is provided by Cybernetica AS. The technology is named SplitKey.

The technology differs from ID-card and Mobile-ID by the way the client-side is built. Namely, the client does not rely on special hardware to store the cryptographic keys. Instead, the client-side cryptographic keys (actually key shares) are stored in software, but they alone are not sufficient to authenticate or issue signatures. In addition, every Smart-ID user has server-side keys (actually key shares), which are stored in an HSM (hardware security module). In order to issue signatures, both the client key shares and server-side key shares are needed. You can find detailed information about the technology from the links below.

Since 2018 the signatures issued with Smart-ID are legally equivalent to the ID-card and Mobile-ID signatures. In February 2020, the Smart-ID signing functionality was also added to the official DigiDoc4 software. The corresponding news is linked here: The ID software of the Information System Authority (RIA) now allows digital signing with Smart-ID.

The technical details regarding Smart-ID and SplitKey are not in the scope of this course. However, in case you are interested, links to the detailed information can be found below.

Infoturve 2021/22 sügis