Secure Implementation Guide

Introduction
- Terms and concepts
- Feedback
Threats and attacks
Security measures for the RPs
Personal data processing

Introduction

Although Smart-ID and Mobile-ID are both secure technologies for authentication and for digital signatures, e-service providers (Relying Parties, RPs) need to also consider the potential risks, which are associated with digital authentication solutions. It is important that RPs implement additional security mechanisms to help users to understand the context of their actions and to protect them from possible attacks. For example, consider that there might be a malicious phishing website controlled by attacker, between the user's browser and your genuine website.

This document analysis the situation, when Smart-ID or Mobile-ID is used to authenticate the users and lists the attacks, which could happen with the RP's website or RP's app. Document considers both user interface options and when it is not specifically mentioned, attacks and countermeasures are relevant for both cases.

We describe effective security measures for mitigating those attacks. Some RPs have already deployed those security measures and we invite additional RPs to consider implementing and deploying measures and defences to prevent cybercriminals to be successful in their actions.

Guidelines are written in affirmative and imperative mood, however, not all security measures are considered mandatory for all RPs. Nevertheless, there's nobody else, who can implement those defences and security measures on your behalf. It will be your opportunity and responsibility to carefully assess your risks and select your countermeasures.

Terms and concepts

Website (e-service) -- This is the information system, which is built by RP and uses Smart-ID service to authenticate the users and to create digital signatures. The website is integrated with the Smart-ID RP API (https://github.com/SK-EID/smart-id-documentation/tree/v2/README.md) or Mobile-ID RP API (https://github.com/SK-EID/MID)
App -- This is the RP's mobile application, which is installed on the user's device and will be used to interact with the RP's e-service. App is communicating to the RP's backend or website.
Relying Party (RP, e-service provider) –- This is the organisation, which is developing and managing the website and which is providing some useful service to the users. Organisation may bear financial losses in case cybercriminals are successful with their attacks.
Users - Natural persons, who have registered Mobile-ID/Smart-ID accounts and who are using those solutions to authenticate themselves to the RP website and creating digital signatures.

Feedback

All feedback to this document and proposed security measures is much appreciated. Please send it to the e-mail address [email protected].

Threats and attacks

This section describes the most common attacks, which have been tried in the past against the RPs, against their users and against SK ID Solutions. Giving a brief overview of the attacks is necessary, because it may be the case that not all RPs have thought of all possible attacks and may think that they are relatively safe. Also, not all counter measures are effective against all possible attacks. RP will need to consider, which attacks could have most devastating impact on their business and therefore, which countermeasures should be deployed as first priority.

Attacks are described in generic way and doesn't differentiate between the browser, app, Smart-ID and Mobile-ID.

User mistakes

Risk: Login by mistake

User starts the login process on the RP's website or app. They enter national identity code, but make a small error in the code. By random chance, the entered code corresponds to another real person, who also has a Smart-ID or Mobile-ID account. Smart-ID/Mobile-ID system initiates the authentication transaction with the wrong user and the phone of another user wakes up and displays the authentication consent screen.

It has been occurred in the past, when this another user accepts the foreign consent dialog without verifying it and without having second thoughts, confirms it by entering PIN1, behaving almost like on the auto-pilot. The session of the original user is then authenticated, but the original user is logged into the wrong person’s account.

There was no malicious attempt in the beginning, it was purely accidental error by both users.

Harassment and coercion attacks

Attack: User annoyance

In this case, the attacker is specifically targeting particular user. Attacker tries to irritate and annoy the user by repeatedly starting the authentication with the user's identity. This sends the nefarious Smart-ID/Mobile-ID notifications to the user's phone and disturbs the normal phone usage. Attacker could ask for ransom to cease the attack or simply cause damage as a revenge.

Attack: Denial of service attack against RP

In more advanced situation, the attacker targets the RP itself and starts many authentications with app or website of RP, using some scripted and automated tools. Attacker could use random usernames and national identity codes and this results nefarious notifications on the phones of multiple users and disturbs the normal phone usage.

Not only causing inconvenience to the users, but also, this kind of attack could result the increased complaints to the SK ID Solutions and SK could be forced to temporarily cut off the Smart-ID and/or Mobile-ID service to the RP.

This results the outage of the RP's website or app, because other users cannot login either. Attacker could ask for ransom money to cease the attack or simply cause damage as revenge.

More advanced version of this attack targets multiple RP's and in such a widespread attack, SK could be forced to temporarily cut off the Smart-ID and/or Mobile-ID service to those RPs, who are not able to filter those authentication attempts.

Data leaks

Attack: User data mining

In this case, attacker is trying to extract and deduce information about the Mobile-ID/Smart-ID users, through the RP's website or other information system. For example, when the attacker is initiating Smart-ID authentication on the RP's website and they see that error message is not displayed, the attacker can deduce that this particular user has Smart-ID account and it may be worthwhile to try some further attacks against that user.

In more advanced situation, attacker may be able to use RP's information system to even download user's signing certificate.

Phishing attacks

Phishing attacks are intended to confuse the users and gain access to the RP's e-service under the users' name. Usually, these attacks are automated and distributed in large quantities via spam e-mails. Attacker is hoping that perhaps some percentage of users, who are not aware of risks and are not careful, will "take the bait" and will be "hooked". Hence, the name phishing (fishing). However, e-mail and browsers are not the only attack vector.

In case the RP requires digital signatures in order to commit an operation or transaction on the e-service, then attacker tries to further confuse the user and will try to get the user to enter PIN2 for the signing request as well.

Attack: Phishing with a fully automated website

Previously, phishing has been attempted in a manual (non-automated) ways and with simple (static) counterfeit websites. However, with the advances of the attack tools, we must consider more powerful attackers, who are able to build dynamic website, which proxies the authentic HTML pages from website of the RP.

The attack goes on like that:

Attacker sends users a phishing e-mail with URL to the proxy website and waits until user connects to the attacker's website. Automatic tools then connect from the proxy website to the original website of the RP.
User enters all the required information (username, national identity code, ...), starts the authentication on the attacker's website.
The proxy website sends the same information to the original website and starts the same kind of authentication there as well and mediates back the correct Mobile-ID/Smart-ID verification code and any other displayed information.
User sees the authentication dialog on the mobile device, with the correct serviceName, correct displayText and correct verification code. User will consent to the authentication and enters PIN1. The attacker's proxy will be logged in to the user's account at the RP's website.
After logging in, attacker's proxy waits until the user initiates the operation or transaction and changes the transaction details on the fly (such as destination bank account) and starts the changed transaction on the original website.
User enters the PIN2 to confirm the transaction, but it will be the attacker's transaction which will be executed.

Attack: Social engineering over the phone

Attacker makes a phone call to the user, posing as the employee of RP (or some other authoritative person, for example, police officer) and persuades the user that he needs to perform the Mobile-ID/Smart-ID authentication.

The attack goes like that:

Attacker gathers the required information (username, national identity code, ...) from the user or has already them at hand before the phone call.
Attacker navigates with the browser to the original website of the RP and starts the authentication under the name of the user. Website initiates the Smart-ID authentication and displays the verification code to the attacker. (Instead of the website, the attacker could use the app of the RP as well.)
Attacker informs the user that Mobile-ID/Smart-ID authentication needs to be performed and tells him the verification code and asks to complete the authentication on the mobile device.
User verifies the authentication dialog on the device and consents and enters the PIN1.
Browser of the attacker is logged into the website of the RP under the user's identity.
Attacker starts the operation (such as transfer order) on the website of the RP. Website initiates the Mobile-ID/Smart-ID digital signature operation and displays the verification code to the attacker.
Attacker informs the user, still during the phone call, that Smart-ID digital signature needs to be created as well, and tells him the verification code and asks to complete the signing operation on the app.
User verifies the digital signature dialog on the device and consents and enters the PIN2.
The operation on the website of the RP is executed.

Security measures for the RPs

This section lists the security measures, which can be deployed by RP itself in order to protect from the threats and attacks listed in the previous section.

Effectiveness of proposed security measures

Applicability to usage scenarios

This table describes the proposed security measures. It includes the following information:

In case the proposed security measures is considered mandatory for the SK ID Solutions AS customers, it is marked as "MUST". In case it is recommended, it is marked as "SHOULD"
Information whether security measure can be applied to websites and apps. Most of the measures are universal, but there are specific measures, such as "keeping track of trusted browsers".
Information whether security measure can be applied in case of Mobile-ID usage or Smart-ID usage. A few of the security measures cannot be applied in case the Mobile-ID.

Security measure	Mandatory for all RPs	Applicable with websites	Applicable with apps	Applicable with Smart-ID	Applicable with Mobile-ID
good serviceName and displayText	MUST	yes	yes	yes	yes
select correct VC	SHOULD	yes	yes	yes	no
display last authentication details	SHOULD	yes	yes	yes	yes
display history of operations	SHOULD	yes	yes	yes	yes
include details in displayText	MUST	yes	yes	yes	no
ask for non-public id	SHOULD	yes	yes	yes	yes
track trusted browsers	SHOULD	yes	no	yes	yes
track suspicious IP-addresses	SHOULD	yes	yes	yes	yes
monitor e-service usage	MUST	yes	yes	yes	yes
respond to incidents	MUST	yes	yes	yes	yes

Mitigation of threats

This table gives the overview about which security measure is effective for mitigating which threat.

In case there's a direct mitigation effect and measure helps to prevent attacks, the cell has "yes".
In case the effect is not as strong or in case the security measure only helps to detect attacks, the cell has "some".
In case there's no relation, the cell has "no".

Security measure	Login by mistake	User annoyance	DOS against RP	User data mining	Phishing with proxy website	Social engineering over the phone
good serviceName and displayText	yes	no	no	no	some	some
select correct VC	yes	no	no	no	no	no
display last authentication details	some	no	no	no	some	some
display history of operations	some	no	no	no	some	some
include details in displayText	some	no	no	no	yes	yes
ask for non-public id	yes	yes	yes	yes	no	some
track trusted browsers	some	no	no	no	some	no
track suspicious IP-addresses	some	some	some	some	some	no
monitor e-service usage	no	some	some	some	some	some
respond to incidents	yes	yes	yes	yes	yes	yes

Defence: use distinguishing and well-known serviceName and displayText

serviceName is a short text string, displayed to user in Mobile-ID/Smart-ID authentication consent dialog and helps user to verify that authentication requests is coming from trusted source. serviceName must contain the name of the e-service you're providing to user or name of your company or trademark.

serviceName will be displayed on the top of the authentication consent screen, in bold letters.

SK ID Solutions have established basic requirements that serviceName should contain one of the following:

name of the company
DNS domain which your website is using
registered trademark, associated with the website or app, which the user is interacting
brand name, associated with the website or app, which the user is interacting

Generic serviceNames, which do not help user to distinguish between different RP-s, are not accepted (such as "login", "authentication", etc).

displayText is a short text string, displayed to user in Mobile-ID or Smart-ID authentication or signing consent dialog and it helps user to understand, what is the context of the operation. RP can use this to distinguish between the different information systems or different services within the RP.

displayText will be displayed on the authentication or signing consent screen, under the verification code number.

So, for example, in case the RP is using Mobile-ID or Smart-ID to authenticate users, who are calling the RP's helpdesk via phone, those authentication requests must use different displayText than requests sent by the RP's website. This way the user has greater confidence, that RP's employee (or helpdesk agent, who might be out-sourced from external company) is not logging into the website of the RP under the name of the user.

With signing operations, there's also possibility to use much longer displayText. For more details, see the section Defence: show details of transactions in the displayText.

Defence: ask users to select correct verification code with Smart-ID app

At the basic security level, Smart-ID is using 4-digit verification code (kontrollkood, kontrolinis kodas, ...), which is displayed to the user on the RP's website and Smart-ID app and the user is expected to match these and verify this way that he is consenting to the correct authentication request. At more advanced security level, RP can request that the Smart-ID app should display three verification codes (one is the correct code and two are random codes) and the user is required to select the correct code, which is displayed by the RP's website or app. In case the user doesn't choose the correct code, the Smart-ID app aborts the transaction.

This is done in the Smart-ID RP API calls with the property 'verificationCodeChoice'. More information in the API documentation: https://github.com/SK-EID/smart-id-documentation/tree/v2

In case RP has app, then it is recommended to include a small delay after showing the verification code to user and before starting the transaction on the RP-API.

Defence: display information about last authentication to user

In order to increase trust and confidence in the RP users, it is good to show the details of the last successful session. RP must prominently display the information about the last authentication, including such elements:

Date and time of the last successful authentication
Geographic location (country) of the last successful authentication
Short human readable description of the browser last used for successful authentication (such as "Chrome on Windows", "Safari on Mac"), deduced from the browser's user-Agent header.

This will help users to recognise the last login details and increase confidence that nobody else haven't accessed their account meanwhile. If they don't recognise them, they can contact the RP's user support and raise the alert.

Defence: show history of operations on the website

Good design of the website should include a way for the user to see the history of his actions. For example, when the user logged in, what operations the user executed, what orders the user placed and so on. This provides user the visibility and transparency, what is happening on the user's account and gives the opportunity to find out if there are such actions or operations, which the user doesn't recognise and which could point to the security incidents. On the other hand, when user does recognise all the history, it will increase the trust in the website and services of the RP.

Also, RP must allow user to download the digitally signed document, which is created after entering PIN2. This applies to any operation that uses PIN2 for additional consent. For example, when signing terms and conditions on your web site, the signer must be allowed to download the signed document after signing. This allows the signer to verify contents of the signed document.

Defence: show details of transactions in the displayText with Smart-ID

displayText is a short text string, displayed to user in Smart-ID signing consent dialog and it helps user to understand, what is the context of the operation. There are two options for the displayText string length:

short displayText string can be up to 60 characters and it will be displayed as the single line below the verification code, on the same screen as the keypad for the PIN2 entry.
longer displayText string can be up to 200 characters and it will be displayed on the separate screen to gain user's attention.

In case there's an advanced phishing attack in progress and the attacker is presenting modified website to the user, with the modified operation details, such as transaction destination, the user cannot detect the attack from the user's browser alone. However, the content of the displayText is coming directly from the RP and attacker cannot modify that. This way, RP can use secondary authentic channel to allow user to verify and confirm the operation.

Defence: ask for multiple or non-public user identifiers

Common way to start Mobile-ID or Smart-ID authentication is to ask for single user identifier in the form of phone number or national identity number. However, these numbers are not secret and even though they are not outright published, there are ways for an attacker to obtain the national identity number of the user and start authentication on the behalf of the user. Also, it is possible for attacker to create automated scripts to simply start many authentications under the name of multiple users.

Better approach is to additionally ask for another identifier. With Mobile-ID, good option is to ask for both phone number and national identity number. The Mobile-ID API verifies that those identifiers match with each other and doesn't initiate the authentication session otherwise.

With Smart-ID, good option is to ask for national identity number and some not-so-public identifier as well. It could be a username, which the users can select by themselves, it could be the account contract number, it could be something else, which the correct user knows and which is convenient for them to remember and type.

After the identifier is entered on the website of the RP, RP can lookup the user's account information from the internal database and then initiate the Smart-ID authentication with the national identity number.

Defence: keep track of trusted and unknown browsers

Description

Useful security measure is to keep track of trusted and unknown browser instances for each user. This allows RP to make decisions and take different actions based on the knowledge if the user is connecting from his regular (trusted) browser or if the user is attempting to login from the unknown browser. In case of the latter, it could be, that the attacker is attempting a phishing attack and RP could ask for more information or alert the user.

Algorithm

The tracking should be done with the HTTP cookie (or similar client-side storage features provided by browsers) with the content of randomly generated identifier. The status of the particular browser instance for particular user is then tracked in the website database.

The fact about placing such cookie in the browser of the users must be declared in the public cookie policy.

The browser cookie will be set with "Secure" and "HttpOnly" flags and scoped to the URL of the RP's website. In case of the phishing attack, the proxied website will have some other URL and the browser will not send the value of the cookie to the attacker. Therefore, attacker cannot pose as the trusted browser to the RP website.

In order to manage the data associated with browser tracking, each user account must have the following extra data for each browser which the user has connected from in the past:

displayName -- Human recognisable identifier of the browser, like "Chrome on Windows" or "Safari on my work Mac". Simpler names with tolerable error rate could be generated automatically from the browser's User-Agent header with the help of software libraries and toolkits. RP could also allow user to edit this field, so that user can provide their own text.
lastSeen -- Timestamp, when that browser has connected to the website of RP. hashedToken -- Hashed value of the random identifier, which is placed on the cookie at the browser.
trustLevel -- Information about whether that browser instance could be considered trusted or not. Proposed algorithm uses values "seenOnce", "seenTwice", "trusted".

The algorithm to keep track of the browsers and to manage the trustLevel is described below.

When the user navigates with the browser to the website of RP and requests the Smart-ID authentication, the following cases are possible:

If the browser's trustLevel is not known (i.e. the browser didn't send the cookie value or the cookie value doesn't match any hashedToken values in the user's account) and the user doesn't have any other browser's trustLevel as "trusted", proceed with the authentication as usual. After the successful authentication, RP should update the browser's trustLevel as "seenOnce".
If the browser's trustLevel is not known and the user already has at least one browser as "trusted", then the situation indicates a possible phishing attack. RP should perform additional checks and controls.
If the browser's trustLevel is "trusted", then RP should proceed with the authentication. After successful authentication, RP should update the lastSeen timestamp.
If the browser's trustLevel is "seenOnce", then RP should proceed with the authentication as usual. After the successful authentication, if the lastSeen timestamp was older than 24 hours, the browser's trustLevel will be updated as "seenTwice".
If the browser's trustLevel is "seenTwice", then RP should proceed with the authentication as usual. After the successful authentication, if the lastSeen timestamp was older than 24 hours, the browser will be set as "trusted".

The described algorithm can be implemented and silently deployed by the RP without any additional security measures or checks actually performed in the first phase. Those browsers, which are regularly used by users, will eventually move to the "trusted" trustLevel. After that, when the new connections are being made from unknown browsers, the security measures could kick in and start protecting the users.

The following sections describe the possible actions to take, when there's a suspicion of attacks.

Ask national identity number when connecting from unknown browser

When RP detects that user has started authentication from unknown browser, while he usually connects to the website from different browser, RP can ask for additional details from the user, to verify that it is the user who is starting the authentication. Such details could be to the national identity number or something else, which the user knows, but the attacker might not know.

Alert user with Smart-ID when connecting from unknown browser

When RP detects that user has started authentication from unknown browser, while he usually connects to the website from different browser, RP can use the longer displayText feature and send the alert to the user. The alert would be sent in the same authentication session request and it will be displayed to user during the authentication consent dialog.

RP could use message text, such as:

"Authentication started from unknown browser. Are you using new computer?", or
"It seems that you are not using your regular browser. Are you using new computer and are you sure that you are on the correct website www.example-rp.com?"

The message will be displayed on separate screen from the usual PIN1 entry and the user will be asked to confirm or cancel that message. So, in case the user is really connecting from new computer and is aware of this, they can press "Confirm". The authentication then proceeds, user can enter PIN1 and the user's browser will be logged in to the user's account. However, if this comes to the user as a surprise and he is actually using his regular computer, they can press "Cancel".

Defence: keep track of suspicious and malicious IP-addresses

When user connects to the RP's e-service, either via browser or with the app, it connects from the IP-address of the user's device. In case the attacker makes the connection by itself or in case attacker proxies the connect, it will be the attacker's IP-address, which will connect to the RP's e-service.

There are commercial services, which provide the information about the IP-addresses. For example, they can tell you if the IP-address is known to be used for the following:

Sending spam messages, which may indicate the user connecting from such IP-address may have their computer compromised.
Is known to be open HTTP proxy host, which may indicate the user connecting from such IP-address may have their computer compromised or that attacker is using this host to proxy his connection to the website.
Is known to be used as TOR exit node or anonymising VPN service, which may indicate that attacker could be using this to hide his connection to the website.
Is known to be IP-address of hosting provider, data-centre or content delivery network. This may indicate that the requests are used to perform denial of service or data mining attack.

In addition to commercial services, RP's own incident resolution team or security monitoring team could provide the list of IP-addresses, which are related to known suspicious or malicious activities.

The following sections describe the possible actions to take, when there's a suspicion of attacks.

Alert user with Smart-ID when connecting from suspicious IP-address

RP can use the longer displayText feature and send the alert to the user. RP could use message text, such as:

"Authentication started from IP-address with open proxy service. Are you sure that you are on the correct website www.example-rp.com?"

The message will be displayed on separate screen from the usual PIN1 entry and the user will be asked to confirm or cancel that message.

Verify human users with connections from suspicious IP-addresses

In case the source IP-address is used to send many authentication requests and there's suspicion that denial of service attack is launched from that IP-address, RP can perform additional verification on the browser with the CAPTCHA. This slows down the attacker and forces him to change his scripts and tactics.

Block connections from malicious IP-addresses.

In case the source IP-address is associated with previous fraud cases and is known to be malicious, the RP can block connections and deny the service.

Defence: carefully monitor website usage

The goal of this security measure is first to record enough information about the connections and operations, which the users attempt on the website of RP. Then it is possible to apply log analysis and other security intelligence to the available information (and cross-reference this with other data sources) and to deduce with some certainty:

if there is an ongoing attack, which should be dealt with incident response
if some source (IP-address, browsers, phone numbers, e-mail addresses) behave in a weird way and perhaps should be more closely monitored or added to the list of suspicious IP-addresses or plain right malicious IP-addresses.
if some logs might indicate that there's an unknown vulnerability in the RP's website

Defence: respond swiftly and decisively to security incidents

The procedures to respond to the fraud and security incidents must be developed and communicated in the company. When it is known that the RP responds quickly to the attacks and attackers are caught by the law enforcement, it is also a deterrence to the future attackers.

RP must be familiar with the services and guidelines from the law enforcement authorities and other bodies and establish contacts points with those organisations already before the urgent need arises. Good opportunity to do that is to participate in the sessions with your local cyber defence league unit.

Personal data processing

Some security measures described in this document require processing additional data about users (for example, which IP-addresses they have used) and place additional information on their browser cookies. This means that RP must re-evaluate their personal data processing guidelines and public policies.

For using cookies a cookie consent must be asked from data subject and the information about using such cookie must be declared in the public cookie policy.

For processing personal data you must make sure you have a lawful basis for doing that (see GDPR art 6(1)). In case the processing is likely to result in a high risk to the rights and freedoms of data subjects, the data protection impact assessment (DPIA) must be carried out. It is also useful to review your privacy policy and update it with relevant information, if necessary.