Physically at the door

In this case the registration desk comes to the user. Specially trained and equipped personnel of dedicated companies visit the user at home and determine his identity face to face. Companies that offer such services include amongst others AMP Group¹³, Dynalogic¹⁴, and PostNL¹⁵.

Alternatively, the RA of the institution could visit the user at the door and do the identification. This solution, however, creates a lot of overhead for the RA (i.e. it is very time consuming) and does not work for institutions that do not have an RA.

Figure 5: front door identity check (from PostNL promo video).

How could it work:

1. The user logs in at SCSA service, selects a strong authentication token and uses it, enters his address information, and receives an activation code via e-mail.

2. The SCSA service communicates the user’s registration information (name, address) to the company doing the identification at the door and requests for an identification.

3. An employee of the company goes to the user and checks his identity, i.e. the user has to show his identity document (e.g. passport or driving license).

4. The employee asks the user’s activation code and six last digits of the identity document. Both are registered.

5. The employee returns the outcome of the identification (OK/Not OK) and the activation code and six digits to the RA of the SCSA service.

6. The RA enters the activation code in the management portal of the SCSA service and

activates the token. The user is informed via an email. If the identification is negative the token will not be activated and the user will be informed about this. This process step could be executed manually or automatically.

Compared to trustworthiness of the current process, this remote vetting process only lacks a proof of possession check of the token (step 7 of the current process, see section 2.1). The added value of this check is that it provides extra certainty about the binding between the user and his token. However, its implementation in the ‘physical at the door’ solution, is rather complicated as it requires the employee of the identification company to have access to SCSA’s management portal, i.e. it requires the employee of the identification company to become an RA in SCSA and to have credentials to log in at the management portal. Furthermore, the user will have to type in a one-time password (Tiqr, SMS) or insert his token (Yubikey) in a terminal from the employee of the identification company, which can be considered as facilitating phishing or may be perceived as such by the user.

13 https://ampgroep.nl/identificeren/face-to-face-identificeren/.

14 http://www.dynalogic.eu/nl/safeandsecure/id-verification-authentication/.

15 https://www.postnl.nl/ontvangen/pakket-ontvangen/bezorging-pakketten/id-check-aan-de-deur/.

Omitting the extra proof of possession check will reduce the assurance level of the vetting process. An identity fraud scenario exists that exploits a vulnerability that is created by the omission. This scenario consists of a man-in-the-browser (MitB) of the user that tries to register a YubiKey token at the SCSA service. When the user has registered the YubiKey and is asked to do an authentication with it, the MitB replaces the user’s YubiKey output with the output of his own YubiKey to the SCSA service. This attack vector is mitigated by the proof of ownership requirement at the physical RA-desk. However, without this requirement, the attacker could successfully link his own YubiKey to the identity account of the user (that, being a MitB, he has hacked too). Consequently, the MitB is able to login to

critical/sensitive services that require a strong authentication token.

Particularly the YubiKey token solution is adversely affected by this possible MitB exploit as it is rated with LoA 3 assurance. But will the omission of the second proof-of-possession check reduce the YubiKey LoA from 3 to 2? The answer to this question is not trivial as the existing frameworks for LoA assessment are not very specific about MitB threats. Most concrete is the European eIDAS assurance framework. This framework states for assurance level Substantial (which is more or less equivalent to SCSA LoA3) that “The authentication mechanism implements security controls for the verification of the electronic identification means, so that it is highly unlikely that activities such as guessing,

eavesdropping, replay or manipulation of communication by an attacker with moderate attack potential can subvert the authentication mechanisms.” (for level Low/LoA2 protection against an enhanced attack potential is required).

For this requirement, eIDAS reuses terminology from ISO/IEC 15408 “Information technology – Security techniques – Evaluation criteria for IT security” and ISO/IEC 18045 “Information technology – Security techniques – Methodology for IT security evaluation”.¹⁶ ISO/IEC 15408-1 defines “attack potential – measure of the effort to be expended in attacking a [mechanism], expressed in terms of an attacker's expertise, resources and motivation”. For a moderate attack potential this translates to professional attackers (i.e. hackers with sufficient skills, time, expertise and capabilities). From these attackers, it is to be expected that they can successfully execute a MitB- attack. Consequently, the LoA of the proposed at the door vetting scenario drops from 3 to 2 for YubiKey as no MitB control

measures are in place.

With compensating controls it is possible to increase the LoA to 3 again for YubiKey. Possible controls are:

• Notification: the user is notified, via a separate channel, about each login with the token. For each authentication he receives an email or SMS telling him he has logged in at a certain service provider. This allows the user to take action in case something is wrong. The drawback of the control is that it is very invasive for the user and costly for SCSA (costs of SMS-es for each login). For LoA4 solutions this notification requirement is mandatory in some frameworks (e.g. eHerkenning).

• Separate channels/platforms: force the user to make use of multiple separate out of band channels/platforms such as desktop and mobile phone. This way it is harder for the MitB attacker to compromise the registration and vetting process.

• Fraud detection: that monitors abnormal user behaviour. Monitoring strange authentication behaviour is challenging as it provides far less information than e.g. financial transactions that banks use to detect abnormal behaviour. One could for instance monitor IP-addresses.

• Passport scan: Ask the user to scan his passport with a Near Field Communication reader; the output contains personal identifiable information and will be communicated to the SCSA management portal for verification of the user’s identity. A MitB must have access to the user’s passport to successfully register and activate a token.

16 The text of the standards is also freely available at www.commoncriteriaportal.org/cc, (CCPART1-3 being equivalent to ISO/IEC 15408 and CEM equivalent to ISO/IEC 18045).

Similar to asking the user to do an authentication at the door, implementing these compensating controls obviously is not trivial.

Note that also SMS authentication is affected by the MitB attack. The user has to enter his mobile phone number in the browser, this number may be adjusted by the attacker. The Tiqr solution requires more effort from the MitB attacker and seems less vulnerable. For LoA 2 solutions, however, the security measures against MitB are little, so these two solutions will keep their LoA 2 rating.

The assessment of the solution against the identified criteria is as follows:

Criteria Assessment Score

Easy to use by user Very easy. It does not require any traveling and may even be possible outside working hours (e.g. in the evening or during weekend).

Easy for the user.

Easy to organize by institution Institutions do not need to setup an RA. No hassle for the institution.

Limited impact on SCSA The impact on the SCSA service is large.

Name and address of the user are required and need to be processed by SCSA.

A company doing the identification at the door needs to be contracted and provisioned with the right information. The employee of the identification company needs to be instructed on what to do (check name, identity, get activation code, register last six digits identity document, etc.).

Furthermore, the outcome of the identification needs be communicated to a central RA for further automated or manual processing.

Large

Straight-through processing The RA needs to process the outcome of the identification at the door prior to activating the token. Initially, this will typically be a manual process as automating will require

adjustments of the management portal of SCSA.

Penetration rate / coverage Only works nationally. Does not work for users that live abroad (use case 2) as it requires with a contract with a company that does identification at the door on an international scale. These companies do not exist.

Alternatively, separate contracts with national companies have to be closed; this does not scale.

Does not work internationally.

Assurance level Assurance levels 2/Low can be achieved with this solution. Level 3 / Substantial cannot be achieved for YubiKey without implementing additional security measures.

Costs About 12-18 Euro per identification¹⁷. For a small user-base this is doable; if the user-base becomes too large these costs may become a showstopper.

Significantly higher than currently, but not insurmountable.

Controllability/auditability The company doing the identification at the door needs to be audited regularly. This can be arranged contractually (i.e. the right to audit). The output of the vetting at the door must be archived by the RA for accountability purposes.

Future proof Identification at the door services are offered by several private companies. Authentication service providers in Idensys and eHerkenning make use of these services for the issuance of their tokens.