• Introduction
  • Terms and concepts
  • Feedback
• Threats and attacks
  • User mistakes
  • Harassment and coercion attacks
  • Data leaks
  • Phishing attacks
• Security measures for RPs
  • Effectiveness of proposed security measures
  • Defence: implement ID-card authentication securely
  • Defence: use distinguishing and well-known serviceName and displayText
  • Defence: ask users to select correct verification code with Smart-ID app
  • Defence: display information about last authentication to users
  • Defence: display generic error messages
  • Defence: show history of operations on the website
  • Defence: show details of transactions in the displayText with Smart-ID
  • Defence: ask for multiple or non-public user identifiers
  • Defence: keep track of trusted and unknown browsers
  • Defence: keep track of suspicious and malicious IP-addresses
  • Defence: carefully monitor website usage
  • Defence: respond swiftly and decisively to security incidents
• Personal data processing

Although ID-card, Mobile-ID and Smart-ID are all secure technologies for authentication and digital signing, e-service providers (Relying Parties, RPs) need to consider 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, there might be a malicious phishing website controlled by attacker between user's browser and the RP's website.

This document lists attacks that can be launched against RP's website or RP's app, when the RP is using ID-card, Mobile-ID or Smart-ID for authentication and digital signatures. Both user interface options (browser and app) are considered and when it is not specifically stated, attacks and proposed countermeasures are relevant for both cases.

Effective security measures for mitigating attacks are described in the following sections. Some security conscious RPs have already deployed them. Others should also consider implementing and deploying these measures and defences to prevent cybercriminals from being 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 their behalf. It is the relying party's opportunity and responsibility to carefully assess these risks and select appropriate countermeasures.

• Relying Party (RP, e-service provider) -- Organisation developing and managing the website and providing some service to its users. The organisation may bear financial losses in case cybercriminals are successful with their attacks.

• Website (e-service) -- Information system built by RP and uses Mobile-ID or Smart-ID service to authenticate users and to create digital signatures. The website is integrated with the Mobile-ID RP API (https://github.com/SK-EID/MID) or the Smart-ID RP API (https://github.com/SK-EID/smart-id-documentation).

• App -- RP's mobile application running on a user's device. The app is used to interact with the RP's e-service and in the background, the app is communicating to the RP's backend or website.

• Users -- Natural persons with registered Mobile-ID/Smart-ID accounts. Users authenticate to the RP's e-service and create digital signatures with the browser or the RP's app.

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

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

Attacks are described in a generic way and don't differentiate between browser, app, ID-cards, Mobile-ID and Smart-ID.

User starts the login process on the RP's website or app. They enter national identity code, but sometimes make a small error in the code. By random chance the entered incorrect 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 for the wrong user and the phone of another user wakes up and displays the authentication consent screen.

It has occurred in the past the other user accepted the foreign consent dialog without verifying it and without having second thoughts confirmed it by entering PIN1, behaving almost like on auto-pilot. The session of the original user was then authenticated by the RP's website, although 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.

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

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

Not only does this cause inconvenience to users, but also, this kind of attack could result in a large number of complaints to 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 in the outage of the RP's website or app, because other users cannot login either. Attacker could ask for a ransom to cease the attack or simply cause damage as a revenge.

An 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 the malicious authentication attempts by themselves.

An attacker is trying to extract and deduce information about Mobile-ID/Smart-ID users through the RP's website or other information systems or software. For example, the attacker initiates a Smart-ID authentication session on the RP's website with a generated national identity code. If no error message is returned, the attacker can deduce that this particular user has a Smart-ID account and it may be worthwhile to try some further attacks against that particular user.

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

Phishing attacks are intended to confuse users and to gain access to the RP's e-service under the user's name. Usually, these attacks are automated and distributed in large quantities via spam e-mails. The attacker hopes some percentage of users, who are not aware of risks and are not careful, will "take the bait" and 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, the attacker tries to further confuse the user and will try to get the user to enter PIN2 for the signing request as well.

Previously, phishing has been attempted in a manual (non-automated) ways and with simple (static) counterfeit websites. However, with advances in attack tools, more powerful attackers must be considered. Nowadays, they are able to build authentic looking and well-functioning dynamic websites, which proxy authentic HTML pages and images from the original website of the RP.

General steps of such kind of phishing attacks are following:

1. An attacker sends users a phishing e-mail with an URL to the proxy website and waits until the user connects to the attacker's website. Automatic tools then connect from the proxy website to the original website of the RP.

2. The user enters all the required information (username, national identity code, ...) and starts authenticating on the attacker's website.

3. The proxy website sends the same information to the original website and starts the same kind of authentication session there as well and mediates back the correct Mobile-ID/Smart-ID verification code and any other displayed information.

4. The user sees the authentication dialog on the mobile device, with correct serviceName, correct displayText and correct verification code. The user will consent to the authentication dialog and enters PIN1, although the attacker's proxy will be logged in to the user's account at the RP's website.

5. After logging in, the attacker's proxy waits until the user initiates the operation or transaction and changes details of the transaction on the fly (for example, change the destination bank account number of the transfer order) and starts the changed transaction on the original website.

6. The user enters the PIN2 to confirm the transaction, but it will be the attacker's changed transaction that will be executed.

An attacker makes a phone call to a user, posing as an employee of the RP (or some other authoritative person, for example, police officer) and persuades the user that they need to perform a Mobile-ID/Smart-ID authentication in order to confirm something fictional.

General steps of such kind of phishing attacks are following:

1. An attacker gathers the required information (username, national identity code, ...) from the user or has already them at hand before the phone call.

2. The attacker navigates with the browser to the RP's original website and starts the authentication session under the name of the user. Website initiates the Mobile-ID/Smart-ID authentication and displays the verification code to the attacker. (Instead of the website, the attacker could use the RP's app as well.)

3. The attacker informs the user that Mobile-ID/Smart-ID authentication needs to be performed and tells them the verification code and asks to complete the authentication on the mobile device.

4. The user verifies the authentication dialog on the device, consents and enters PIN1.

5. The Browser of the attacker is logged into the RP's website under the user's identity.

6. The attacker starts an operation (for example, a transfer order) on the RP's website. The website initiates the Mobile-ID/Smart-ID digital signature operation and displays the verification code to the attacker.

7. The attacker informs the user, still on the phone call, that Mobile-ID/Smart-ID digital signature needs to be created as well, and tells them the verification code and asks to complete the signing operation on the mobile device.

8. The user verifies the digital signature dialog on the mobile device, consents and enters PIN2.

9. The operation on the website of the RP is executed.

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

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

1. In case the proposed security measure is considered mandatory for customers of SK ID Solutions, it is marked as "MUST". In case it is recommended, it is marked as "SHOULD".

2. Information whether the security measure can be applied to websites and/or apps. Most of the measures are universal, but there are specific measures, such as "keeping track of trusted browsers" that apply only in certain situations.

3. Information whether the security measure can be applied in case of ID-card, Mobile-ID and/or Smart-ID integration.

This table gives an overview of security measure relations to the described threats.

1. In case there's a direct mitigation effect and the measure helps to prevent the attack, the cell has "yes".

2. In case the effect is not as strong or in case the security measure only helps to detect the attack, the cell has "some".

3. In case there's no relation, the cell has "no".

If RP uses TLS Client Certificate Authentication (TLS-CCA) with smart-cards, issued by Estonian government as identity cards, it is important to implement the authentication securely.

RP must implement the following checks and controls.

Using simple means just to include a number of CA certificates in the TLS server configuation is not enough. SK ID Solutions uses many CAs and TLS server needs information about them all in order to build trust chains. However, not all of the CAs are used to issue ID-card certificates and this information needs to be manually added. It is important to explicitly specify, which CA-s are trusted to issue the certificates for the CCA authentication and which CAs are not trusted to do that.

For example the OpenSSL utility can be used for that:

cd /path/to/trusted_certificates_directory/
wget https://c.sk.ee/EE-GovCA2018.pem.crt
wget https://www.sk.ee/upload/files/EE_Certification_Centre_Root_CA.pem.crt
wget https://c.sk.ee/esteid2018.pem.crt
...
openssl x509 -addreject clientAuth -trustout -in EE-GovCA2018.pem.crt -out EE-GovCA2018_trusted.pem.crt
openssl x509 -addreject clientAuth -trustout -in EE_Certification_Centre_Root_CA.pem.crt -out EE_Certification_Centre_Root_CA_trusted.pem.crt
openssl x509 -addtrust clientAuth -trustout -in esteid2018.pem.crt -out esteid2018_trusted.pem.crt
...
rm EE-GovCA2018.pem.crt
rm EE_Certification_Centre_Root_CA.pem.crt
rm esteid2018.pem.crt

Note that it is important to include the certificate of root CAs and implicitly configure clientAuth reject for them.

When configuring Apache in this way, it is also neccessary to use the SSLCADNRequestPath directive, which specifies the list of acceptable CA-s, which are sent to the client over the TLS handshake.

cd /path/to/client_request_CAs_directory/
wget https://c.sk.ee/esteid2018.pem.crt
openssl rehash /path/to/client_request_CAs_directory/

After specifying trust settings for individual certificates, allow TLS server to only trust these CAs and to request specific certificates from clients (configuration example is given for Apache mod_ssl):

...
SSLEngine on
SSLCertificateFile ...
SSLCertificateKeyFile ...
SSLCACertificatePath /path/to/trusted_certificates_directory/
SSLCADNRequestPath /path/to/client_request_CAs_directory/
...

SK Identity Solutions provides OCSP service to check for the validity of issued certificates. More details are available at https://www.skidsolutions.eu/en/services/validity-confirmation-services/

Configuration example is given for Apache mod_ssl:

...
SSLEngine on
SSLOCSPEnable leaf
SSLOCSPDefaultResponder "http://responder.example.com:8888/responder"
SSLOCSPOverrideResponder on
...

It is important to only accept these certificates, which correspond to production ID-cards, Digi-ID and other identity documents. An attacker could present other certificates as well and in some cases this might lead to a vulnerability.

Issuance policy is recorded in the certificate extension X509v3 Certificate Policies and contains an OID identifier. Identifier values of issuance policies are listed at the page https://www.skidsolutions.eu/en/repository/CP/ and https://www.skidsolutions.eu/upload/files/SK-CPR-ESTEID2018-EN-v1_2_20200630.pdf.

Following table compiles a helpful list of policies relevant to accept in the TLS-CCA authentication sessions.

Unfortunately, filtering is not possible with only a TLS-server configuration. RP would need to export the full client certificate from the TLS session to the application server and then apply filtering with PHP or other applications.

Configuration example with Apache mod_ssl:

...
SSLEngine on
...
SSLOptions +ExportCertData
...

and source code example with PHP:

$cert = getenv('SSL_CLIENT_CERT');
$x509 = openssl_x509_parse($cert);
$certificatePolicies = 'Policy: 1.3.6.1.4.1.51361.1.1.1';
if(preg_match("/$certificatePolicies$/m", $x509['extensions']['certificatePolicies']) == 0) {
    echo "OK\n";
}

Note that demo code examples only use a single OID value. Production systems would have to use the whole table.

It is important to only accept these certificates, which have the "TLS Web Client Authentication" extension and are issued by trusted CAs.

Partial configuration example for Apache:

...
<Location "/">
Require expr "TLS Web Client Authentication, E-mail Protection" in PeerExtList('extendedKeyUsage')
</Location>
...

and partial configuration example for F5 BIG-IP loadbalancer:

when CLIENTSSL_CLIENTCERT {
    HTTP::release
    if { [SSL::cert count] < 1 } {
        reject
    }
    set client_cert [SSL::cert 0]
    set clientCA [X509::cert_fields $client_cert [SSL::verify_result] issuer ]
    #If issuer contains "-SK 20" assume it is a SK certificate and process further
    if {($clientCA contains "-SK 20") } {
            if {($clientCA contains "ESTEID-SK 20") } {
            #If issued by ESTEID check if it is mobile-id or not, mobile-ID profile doesn't have TLS web auth enabled
            if { !([X509::extensions $client_cert] contains "TLS Web Client Authentication") } {
                log local0. "Invalid certificate used for authentication, IP: [IP::client_addr], Issued by: $clientCA"
                reject
            }
        } else {
            #Not issued by ESTEID, shouldn't allow TLS auth
            log local0. "Invalid certificate used for authentication, IP: [IP::client_addr], Issued by: $clientCA"
            reject
        }
    }
}

serviceName is a short text string, displayed to the user in the Mobile-ID/Smart-ID authentication or digital signature consent dialog. It helps user to verify that the request is coming from a trusted source. serviceName will be displayed on the top of the consent screen, in bold letters.

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

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

Generic serviceName, which does 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 the user in the Mobile-ID or Smart-ID authentication or digital signature consent dialog. It helps the user understand the context of the operation. displayText will be displayed on the authentication or signing consent screen, under the verification code number.

The RP can use this to distinguish between the different information systems or different services within the RP, when requesting the authentication. When requesting a digital signature, the RP can use this to give information about the nature of signature, such as the name of the document to be signed or information about the transfer order to be executed.

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, these authentication requests must use different displayText than requests sent by the RP's website. This way the user has greater confidence, that the person on the phone (a helpdesk agent, who might be out-sourced from an 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 and descriptive displayText. For more details, see section Defence: show details of transactions in the displayText.

At the basic security level, Smart-ID is using a 4-digit verification code, which is displayed to a user on the RP's website and on the Smart-ID app. The user is expected to match these and thus verify they consent to the correct authentication or signature request.

At more advanced security level, the RP can request the Smart-ID app should display three verification codes (one correct code and two 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 request.

This can be requested in the Smart-ID RP API call using the verificationCodeChoice interaction type. More information in the API documentation: https://github.com/SK-EID/smart-id-documentation/tree/v2

In case the RP is using an app it is recommended to include a small delay after showing the verification code to user and before starting the transaction on the RP-API. This way, the user has additional time to look at the verification code on the RP's app, before the screen of the Smart-ID app is displayed.

In order to increase trust and confidence in users, it is useful to show details of the last successful session. The 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 their confidence that nobody else has accessed their account after their last login. If they don't recognise the last session, the user can contact the RP's user support and raise the alarm.

With password-based authentication systems, it was a good practice (https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-responses) to show same error message for two cases:

• username was incorrect and the account didn't exist, and
• username was correct, but the password was incorrect.

This helps to prevent the user account enumeration (WSTG-IDNT-04). With Mobile-ID and Smart-ID services, following the same principle helps to prevent data mining for attack preparation. It also makes some phishing attacks more difficult.

Mobile-ID RP API and Smart-ID RP API return different error codes to help debuging:

• Mobile-ID RP API, HTTP 200, "result": "NOT_MID_CLIENT" -- "Given user has no active certificates and is not MID client"
• Smart-ID RP API, HTTP 404 -- "object described in URL was not found, essentially meaning that the user does not have an account in Smart-ID system"
• Smart-ID RP API, HTTP 471 -- "No suitable account of requested type found, but user has some other accounts"

However, it is the reponsibility of the RP not to show different UI messages for those cases, but to follow generic, uniform pattern:

1. Request new authentication session from the Mobile-ID or Smart-ID API with the user identifier.
2. In case the API responded with the new authentication session:
   1. Display the text "Authentication session started, verification code 1234" with the value of the verification code given by Mobile-ID or Smart-ID API
   2. In case the authentication is successful, continue with the login
   3. In case the authentication session is timed out after 120 seconds, show the error message "User account not found or user didn't responded in time"
3. In case the API responded with "NOT_MID_CLIENT" or "HTTP 404" or "HTTP 471":
   1. Generate random verification code value
   2. Display the text "Authentication session started, verification code 1234"
   3. Wait for 120 seconds and then show the error message "User account not found or user didn't responded in time"

Good design of the website should include a way for a user to see the history of their actions. For example when the user logged in, what operations the user has executed, what orders the user has placed and so on. This provides the user visibility and transparency about what is happening on the user's account. It also provides an opportunity to see actions or operations the user doesn't recognise and that could point to security incidents. On the other hand, when the user does recognise all the history, it will increase the trust in the website and services of the RP.

Also, the RP must allow the user to download digitally signed documents that were created after entering PIN2. This applies to any operation that uses PIN2 for additional consent. For example, after signing the terms and conditions for the e-service or when signing a transfer order on the RP's website the user must be allowed to download the signed document.

This allows the signer to verify contents of the signed document.

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

1. short displayText string can be up to 60 characters and it will be displayed as a single line below the verification code, on the same screen as the keypad for entering PIN2.

2. longer displayText string can be up to 200 characters and it will be displayed on a separate screen to gain the user's attention.

In case there's an advanced phishing attack in progress and an attacker is presenting a modified website to the user, with the modified operation details, such as destination account number of the transfer order, the user cannot detect the attack solely with the user's browser. However, the string of the displayText is coming directly from the RP and the attacker cannot modify it to deceive the user. This way, the RP can use a secondary authentic channel to allow the user to verify and confirm the operation.

A common way to start the Mobile-ID or Smart-ID authentication is to ask for a user identifier, either the 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 authenticating on their behalf. It is also possible for the attacker to create automated scripts to simply generate a list of numbers and try them all to start many authentication sessions under the name of multiple users.

A better approach is to ask for an additional identifier. With Mobile-ID, a 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, a 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, the account contract number or something else only the user knows and is convenient for them to remember and type.

A useful security measure is to keep track of trusted browser instances for each user. This allows the RP to take different actions whether the user is connecting from their usual (trusted) browser or attempting to login from a previously unseen, unknown browser. In case of the latter an attacker may be attempting a phishing attack and the RP could ask for more information or alert the user.

The tracking should be done with the HTTP cookie (or with similar client-side storage feature supported by modern browsers) with the content of randomly generated identifier. The status of each browser instance for the user is then tracked in the RP's website database.

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

The browser cookie has to be set with Secure and HttpOnly flags. The scope of the cookie has to be the URL of the RP's website. In case of a phishing attack, the proxied website will be setup on a different URL and the browser will not send the value of that cookie to the attacker's website. Therefore, the attacker cannot pose to the RP's website as the trusted browser.

In order to manage the data associated with the 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 description of the browser, like "Chrome on Windows" or "Safari on my work Mac", etc. Simple names with tolerable errors could be generated automatically from the browser's User-Agent header with the help of software libraries and toolkits. The RP could also allow the user to edit this field, so that the user can provide their own meaningful names.
• lastSeen -- Timestamp, when that browser was last used by the user to connect to the RP's website.
• hashedTrackingID -- Hashed value of the randomly generated identifier. Length of the identifier should be at least 32 bytes. The Base64 encoded clear-text value of the identifier is placed in the browser's cookie and the hashed value is stored in the database. Storing only hashed values makes the database leak less dangerous. Salting hashes, a common practice when when storing passwords, is not required, because trackingID is already long enough with random bytes and additional protection against brute-forcing is not essential.
• trustLevel -- Information about whether that browser instance could be considered trusted or not. Proposed algorithm uses values "seenOnce", "seenTwice" and "trusted". The RP could use more levels if required.

Note that in case multiple users are using the same browser instance then the same hashedTrackingID value will be stored for multiple user accounts. Care must be taken to lookup the correct record, based on the user account, which is starting the authentication.

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

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

1. If the connecting browser's trustLevel is not known (i.e. the browser didn't send the cookie value or the cookie value doesn't match any value of hashedTrackingID 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, the RP should update the browser's trustLevel as "seenOnce".

2. If the connecting browser's trustLevel is not known and the user already has at least one other browser as "trusted", then the situation indicates a possible phishing attack. The RP should perform additional checks and controls.

3. If the connecting browser's trustLevel is "trusted", then the RP should proceed with the authentication. The situation indicates somewhat lower risk and the RP could decide not to execute some security measures, which are required otherwise, for example, asking the user to enter multiple identifiers. After successful authentication, the RP should update the lastSeen timestamp.

4. If the connecting browser's trustLevel is "seenOnce", then the 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".

5. If the connecting browser's trustLevel is "seenTwice", then the 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 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" classification. In the next phase, additional security measures could be put into place and when the new connection is being made from an unknown browser, additional security measures will kick in and protect users.

The following sections describe such additional security measures.

When the RP detects that a user has started authenticating from a known browser, the RP could withhold the requirement to ask for multiple user identifiers. Good simplification is to only require one identifier, such as the username of the user. After the username is entered on the RP's website, the RP can lookup the user's account information from the internal database and then initiate the Smart-ID authentication with the national identity number.

However, when the RP detects the user has started an authentication session from an unknown browser, while he usually connects to the website from a different browser, the RP can ask for additional details from the user, to verify that it is indeed 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.

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

The RP could use a message, such as:

• "Authentication started from an unknown browser. Are you using a new computer?", or

• "It seems that you are not using your regular browser. Are you using a new computer and are you sure that you are on the correct website www.example-rp.com?\"

• or something similar.

The message will be displayed on a separate screen from the usual PIN1 entry dialog and the user will be asked to either confirm or cancel. In case the user is really connecting from a new computer and is aware of this, they can press "Confirm". The authentication then proceeds, the 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 the user is actually using their regular computer, the user can press "Cancel" and investigate further.

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

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

1. Sending spam messages, which may indicate the user connecting from such an IP-address might be using a compromised computer.

2. Is known to be an open HTTP proxy host, which may indicate the user connecting from such an IP-address might be using a compromised computer or that the attacker is using this host to proxy their connection to the RP's website.

3. Is known to be used as a TOR exit node or an anonymising VPN service, which may indicate that the attacker could be using this to hide their connection to the RP's website.

4. Is known to be an IP-address of a hosting provider, data-centre or content delivery network. This may indicate that the requests coming from such IP-addresses are used to perform denial of service or data mining attack.

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

The following sections describe possible actions to take when there's suspicion of an attack.

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

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

• or something similar.

The message will be displayed on a separate screen from the usual PIN1 entry and the user will be asked to either confirm or cancel. There could be legitimate reasons why the user is using such IP-address or VPN service and if the user is aware of this, they can press "Confirm". However, if this comes to the user as a surprise, the user can press "Cancel" and investigate further.

In case the source IP-address is used to send many authentication requests and there's suspicion that a denial of service attack is in progress, RP can perform additional verification on the browser with a CAPTCHA. This can slow down the attackers and forces them to change their scripts and tactics.

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

The RP must first record enough information about connections and operations users regularly attempt on the RP's website. It is then possible to apply log analysis and other security intelligence to the available information (and cross-reference with other data sources) to deduce with some certainty:

1. there is an ongoing attack;

2. some source (IP-address, browser, phone number, e-mail address) behaves in a weird way and perhaps should be more closely monitored or added to the list of suspicious IP-addresses or malicious IP-addresses;

3. some logs might indicate that there's an unknown vulnerability in the RP's website.

Procedures to respond to fraud and security incidents must be developed and communicated and practiced within the RP organization. When it is known that the RP responds quickly to attacks and attackers are caught by the law enforcement it also acts as a deterrent to future attackers.

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

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

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

For processing personal data the RP must make sure that they have a lawful basis for doing so (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 a data protection impact assessment (DPIA) must be carried out. It is also useful to review the RP's privacy policy and update it with relevant information.