Figure 1: Simplified Smart-ID context diagramSmart-ID solution is the new generation electronic ID product to take advantage of the smart capabilities of the mobile devices and offering the high level of security to the users.
The solution allows end-users to utilise their existing mobile devices to register for a securely verified Smart-ID account and later use the mobile device to authenticate to RP systems (such as websites, apps and call centres) and to give electronic signatures according to the eIDAS regulation, which is recognised in EU member states. The mobile devices doesn’t need a special purpose hardware (such as smart-card readers or Trusted Platform Module chips) and special purpose SIM-cards. The Smart-ID App works with regular devices and doesn’t require extra-ordinary permissions.
Smart-ID is built from the start as the international eID scheme and therefore the Smart-ID account issued in one country can be used for authentication and digital signatures in another country as well. Smart-ID could be the user’s key to all e-services across European Union in the future.
Smart-ID combines well-known technologies and several new technical innovations to make this possible. Together, existing and new technologies provide the following features of the Smart-ID solution:
This document gives closer look to the technical underpinnings of the Smart-ID solution.
Smart-ID service is being offered on two levels.
The difference is mainly on the level of the identity proofing, which is performed during the registration process. The Smart-ID App and other system components are exactly the same.
In the following document we will use the “Smart-ID” for referring to both levels.
Smart-ID solution provides the following services:
In the following sections, we will give overview of the services.
Authentication service is provided to the RP websites and mobile apps via the RP-API component. The RP-API works with the JSON/REST style methods. The support for the OpenID Connect protocol is in the development.
High-level simplified steps of the authentication service are the following.
The digital signature service is very similar to the authentication service. Few differences are the following:
Registration service has many flavours and versions, for example, depending on which kind of identity proofing documentation User presents, how old the User is and other such details. However, there are general principles and the simplified overview of the generalised registration service steps is the following.
The high-level overview to the simplified context of the Smart-ID solution is given in the Figure 1.
Figure 1: Simplified Smart-ID context diagram
RP-API is used by the RPs for requesting authentication of the Users and digital signatures from the Users. The RP-API uses two styles of interfaces for enabling such services.
JSON/REST style interface allows RPs to simply integrate the Smart-ID solution with their custom in-house built information systems and start using the authentication and digital signature services. Also, this allows RPs to customise the authentication dialog and better integration with their web-page.
OpenID Connect compliant interface allows RPs to easily and quickly integrate the Smart-ID solution with their standards compliant software. The OpenID Connect interface uses the authentication portal, in a similar way as the Google Sign In and Facebook Login services. The OpenID Connect interface is currently in the development.
For additional details, please refer to the RP-API documentation, which is available at the https://www.smart-id.com.
The MD-API is used by the Smart-ID App instances, to communicate with the Smart-ID Core and to run the account registration, transaction management and signature computation protocols.
The MD-API is a JSON/RPC-style API. It is built on the principle that access to the MD-API is protected with the HTTP Basic authentication. Only two methods are public methods, which can be called from unknown sources and access to those are not restricted. During the device registration, new Smart-ID App instance is assigned unique identifier and random password, which is then used as transport layer security measure, to authenticate the queries to all other methods. The access control is enforced, so that only those app instances get access to the data, which is associated with this app instance.
RA-API provides interface for the RA-s to start the registration processes and transmit the verified User identity details to the Smart-ID Core.
SZ-API provides interface for the Smart-ID Core to invoke following functions.
The functions are logically invoked by the Smart-ID App Library and the function calls are relayed by the Smart-ID Core. Sensitive data, such as “Server’s part of the private key” and “App’s share of the signature” and others are encrypted by the Smart-ID App Lib to the public key of the SecureZone.
CS-API provides the self-service portals and helpdesk employees information about the status of the Smart-ID account and allow temporarily block the account and permanently close the account. Self-service portals also have a way to see the history of the transactions and events, which are registered for particular Smart-ID account.
Smart-ID solution is based on the known and proven principles of the public key cryptography, digital signature schemes and PKI (Public Key infrastructure).
Public key cryptography work on the concept of key pairs. The key pair consists of the public key and private key, where the public key is published in the X.509 certificate and bind with the verified identity of the User. Private key is confidential and usually protected inside the smart-card or equivalent device, which is under sole control of the User.
Smart-ID solution handles the protection of the User’s private key by using the results from the https://en.wikipedia.org/wiki/Threshold_cryptosystem. Threshold cryptography studies such systems, where, in order to decrypt an encrypted message (or to sign a message), several parties must co-operate in the decryption protocol (or signature computation protocol). Threshold cryptography provides the benefit that compromise of a single party (or revealing the share of a single party) doesn’t result the compromise of the whole system. Historically, this kind of techniques are used in the highly critical systems, where [https://en.wikipedia.org/wiki/Two-man_rule](two man’s rule) must be enforced. For example, the key for the decryption may be shared between independent members of the management team and executing some critical function requires that all key holders are present.
Advances in the threshold cryptography and increase of the computing power inside the mobile devices allows us to use similar techniques for securing the private key, which is used in public key encryption algorithms. In the Smart-ID solution, the separate and independent parties, which hold the shares of the private keys are following.
With the Smart-ID solution, the private key of the User is never generated or combined in a single place of location. Instead, we use the distributed generation protocol and generate the shares of the private key in the User’s mobile device and in the Smart-ID service. The shares are generated, processed, stored and protected in the separate physical locations and never combined.
The following sections describe, how the standard RSA signature scheme is modified to work with threshold cryptography.
We repeat some of the concepts from the RSA digital signature scheme. Please refer to the RFC3447 or modern cryptography textbook for additional details.
The key pairs in the RSA crypto-system have the private key and public key with the following associated terms:
Computing the RSA signature s on the message m with private key (n, d), means mathematically to compute the
s = m ^ d mod n.Generating the signature S of scheme RSASSA-PKCS1-v1_5 of the message M with RSA private key K means computing the output of the algorithm RSASSA-PKCS1-V1_5-SIGN(K, M), as defined in the section in the 8.2.1 of the RFC3447.
Verifying the RSA signature s on the message m, with public key (n, e) means mathematically to compute the
m' = s ^ e mod n,and verifying if the m’ is the same as the m.
Verifying the signature S of scheme RSASSA-PKCS1-v1_5 of message M with RSA public key (n, e) means computing the output of the algorithm RSASSA-PKCS1-V1_5-VERIFY((n, e), M, S) as defined in the section 8.2.2 of the RFC3447.
Smart-ID signature scheme extends the RSA digital signature scheme in such way, that we can generate the private key in the multiple key shares and then compute the composite signature without combining the key shares. The resulting composite signature S is a RFC3447 RSASSA-PKCS1-v1_5 compliant signature.
Smart-ID key pair consists of the public key and private key.
The private key exists in the form of the following components:
The public key exists in the form of the following components and also in the composite form:
The components of the Smart-ID key pair is generated during the registration process of the User. In this section, we describe the cryptographic details. Please refer to the section 12.12 for additional details about the registration processes.
From cryptography point of view, the key pair generation process is the following:
I2OSP (d1') with the cipher “AES/CBC/NoPadding”, with the AES key derived from the users PIN and deletes the clear-text value of the d1’.In order to compute the signature S, we need access to the all components of the Smart-ID private key and we use the shares to compute the individual signature shares.
EMSA-PKCS1-V1_5-ENCODE to the digest H (with the exception of the step 1, the RP has already applied the hash function to the message M and has sent use the digest H) and computes the encoded message EM.OS2IP (EM).RSASP1 (d1', m).EMSA-PKCS1-V1_5-ENCODE to the digest H and computes the encoded message EM.OS2IP (EM).RSASP1 (d1'', m).RSASP1 (d2, m).Note that this is a simplified version of the signature generation algorithm. We have omitted multiple implementation details and other security measures, for the clarity of this overview document. For example, the following security measures are not described in this section.
Please refer to the chapter Security for additional discussion of these and other security measures implemented in the Smart-ID solution.
The composite signature S is a RFC3447 RSASSA-PKCS1-v1_5 compliant signature. One can verify it with the standard RSA signature verification procedure.
Breakthrough cryptography is just one building block for the Smart-ID solution. To achieve availability, reliability and security, we have included additional security measures in the Smart-ID App and in the Smart-ID Core. In this section, we give the short overview of the security measures.
Smart-ID authentication and signing protocol includes the Verification Code (VC). Because Smart-ID is mostly used in the use case, where the user is accessing the RP website with a browser running on some other device, other than the Smart-ID App itself, we need a way to bind the user’s session on the browser and the authentication/signing transaction on the Smart-ID App. This allows the end-user to understand, what is the context of the authentication/signing transaction, which suddenly popped up on his mobile device. The end-user can then distinguish between the valid transaction, requested by himself on the RP website and other transactions, which might have been initiated by attacker, who is trying to perform the phishing attack.
Smart-ID has followed the good example of Estonian Mobile-ID, which includes the similar feature.
VC is computed from the data to be signed (DTBSR) by Smart-ID app and by the RP itself. The RP shows the VC to the user in the browser session and the Smart-ID App shows the VC to the user within the transaction notification.
The VC is not so useful, when the user’s browser or RP’s app is running in the same device, as the Smart-ID App, because user doesn’t usually have a good way to keep the browser window and Smart-ID App window displayed at the same time and easily compare the VC-s. For this use case, special protocol is being developed, which allows the browser or app to communicate locally with the Smart-ID App as well and this way mitigate the phishing attacks.
If the Smart-ID user would loose his mobile device, the obvious attack is to try all PINs. Because the space of the PINs is not very large, the attacker might easily try all the possible 10 000 PINs and try figure out, which is the correct one. Smart-ID solution includes several security measures against those kind of attacks.
The Smart-ID solution is built this way that the PIN itself is never stored inside the Smart-ID App. The detection of the correct PIN and wrong PIN is actually performed in the Smart-ID Core.
In case the Smart-ID Core learns that user has entered the wrong PIN to the Smart-ID App (note that the PIN is not transmitted to Smart-ID Core either, more on that later), it increases the counter stored inside the Smart-ID database. In case the counter of wrong PIN tries reaches a threshold, the user’s account is locked for the certain time period.
In case the user has entered the wrong PIN three times in a row, the user’s account is locked for 3 hours. During those 3 hours, authentication and signature transactions are not accepted and PIN tries are not allowed.
After the 3 hours time-delay lock has expired, the user’s account is unlocked and the user has 3 more tries again. In case the wrong PIN has been entered again three times in a row, the user’s account is locked for 24 hours.
After the 24 hours time-delay lock has expired, the user has 3 final tries to enter the correct PIN for new transactions. In case the wrong PIN has been entered the final three times in a row, the user’s account is closed and the certificates are revoked.
During the normal usage of the Smart-ID App, detection of the correct PIN and wrong PIN is performed by the Smart-ID server, which applies the time-delay locking, in case the attacker might try all possible PINs. The attacker may try to analyze the locally stored information as well, to deduce the share of the private key or PIN. Smart-ID solution is carefully designed in this way that the data available to the attacker, which is stored inside the Smart-ID App doesn’t give attacker any hints about the PIN or private key.
This is achieved with the special design of the cryptographic shares of the private key and specially designed protection for the “Application’s part of the private key”.
Smart-ID App stores the “Application’s part of the private key” in the private application storage space and encrypts it with the AES key, derived from the user’s PIN.
First, the “Application’s share of the private key” has the corresponding counterpart “Application’s share of the public key”. In case the Smart-ID App would store the encrypted “Application’s share of the private key” and the attacker might have got his hands on the “Application’s share of the public key”, the attacker can simply try all possible PIN-codes, derive the AES encryption key, decrypt the “Application’s share of the private key” and then verify, which of the possible keys match with the “Application’s share of the public key”.
This is prevented by further additively sharing the “Application’s share of the private key” into two parts:
1. "Application's part of the private key"
1. "Server's part of the private key"For those parts, the corresponding public keys do not exist. So, signature shares computed with the “Application’s part of the private key” cannot be verified for validity and the attacker doesn’t have a reference point to distinguish between the correct “Application’s part of the private key” and incorrect.
The validity of the signature share computed within the Smart-ID App can only be verified, once the share is combined with the signature share computed within the Smart-ID Core, with the “Server’s part of the private key”.
Therefore, even when the attacker has the encrypted copy of the “Application’s part of the private key”, attacker cannot launch the off-line brute-force attack and try out all possible PINs.
Clone detection is the feature, which tries to identify the situation, when the PIN of the user and the “Application’s part of the private key” of the user has been leaked and the attacker is actively trying to issue signatures under the name of the user. For example, the storage of the app may have been leaked from the backup copy of the mobile device. The PIN may have been eavesdropped by the attacker, when looking over the shoulder of the user. In a usual, smart-card based solution, such situation means that the user’s private key would have been totally compromised and the attacker can issue unlimited number of valid signatures.
Smart-ID solution has been designed in such a way that all MD-API methods, which operate on the shares of the private keys, require specific one-time content from the previous invocations. After the one-time material has been used, Smart-ID Core supplies a new randomly generated material to the mobile device and expects that to be returned next time, when the mobile device tries to perform an operation on the key share.
In case the Smart-ID Core receives such MD-API method invocation, which contains the otherwise correct information (app instance password, correctly computed signature share and other necessary details) but wrong one-time material, it means that the Smart-ID App instance is out-of-sync with the server or that there are more than two copies of that Smart-ID App instance and key pair. As a cautionary security measure, the user’s account will be then closed and the certificates will be revoked, to protect the user from the further damage. User is then notified of the suspected security breach.
Clone detection works on top of three nonces:
The three kind of one-time materials are required, so that the API method invocations could be safely repeated by the Smart-ID App, when connecting over the unreliable network.
The clone detection protocol is mostly intended to be used during the signature creation protocol. Additionally, the Smart-ID App registers the alarms with the mobile device operating systems and periodically performs the clone detection in the background as well, even when the user haven’t explicitly started a new authentication or signature transaction.
The Smart-ID SSCD is the logical component, which provides the same kind of features as the smart-card based Secure Signature Creation Device (SSCD). Smart-ID solution has been carefully designed from the start to fulfil all the QSCD requirements. In order to gain trust and confidence in the Smart-ID solution and to verify that the QSCD requirements have been met, the solution has been submitted to the Common Criteria evaluation.
Smart-ID SSCD consists of the following components.
Together, they provide the following functionality.
The Common Criteria evaluation is done on the level EAL4 augmented with the component AVA_VAN.4. This means that during the evaluation it is assumed that Smart-ID SSCD components are subject to deliberate attacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by the Smart-ID SSCD.