How does the solution work?
Below we provide a simplified step-by-step explanation of how the SALT-solution works in practice. The explanation outlines a scenario where an end-user consents to use the SALT-solution to gain access to an online service provided by a bank.
A step-by-step description of the solution
The process consists of two phases: an onboarding phase and a verification phase.
There is also a final phase, where personal information undergoes processing for secondary purposes, including improving the fraud detection module and the machine learning algorithms. We will explore secondary purposes more closely in the next chapter.
The onboarding phase:
- Initiation: The onboarding phase is initiated when the user submits a “reference image”. The reference image is the face image extracted from a nationally issued ID-document, such as a national ID-card or a passport. Specifically, the image is retrieved from the Radio Frequency Identification (RFID) chip in the document.
- Template Creation: A template creation module converts the reference image into a “plaintext template”.
- Key Generation: A key management server will generate a unique “transformation key” which is specific to each user. It will also generate a “homomorphic encryption key”, which is specific to each eID provider.
- Secure processing: The plaintext template is secured by a transformation process using the transformation key, followed by an encryption process using the homomorphic encryption key. This process results in the generation of a protected template. The protected template is then sealed using the sealing key. This ensures the integrity of the protected template.
- Storage: The sealed protected template is stored in a storage server. This protected template is the reference template, and it is used for the face comparison in the verification phase.
- Verification: To ensure that the onboarding is performed by the holder of the national ID-document, the user must verify his/her identity following the steps in the “verification phase”, described below. If the verification decision is positive, the user has been onboarded for further use (i.e., ongoing verifications).
Verification phase
To gain access to a service provider’s/merchant’s services, the user must undergo a verification phase, detailed below:
- Image capture: The user captures a live image of himself/herself (a “selfie”) on their mobile device and uploads this image to the SALT-solution.
- Fraud Detection Module: A fraud detection module (see info box) analyses the image to assess if it was captured live from a present person without any image manipulation or fabrication.
- Generation of plaintext template: If the fraud detection module concludes that the image is authentic, the template creation module generates a plaintext template.
- Generation of protected template: A protected template will be generated from this plaintext template using the same procedure as described earlier, using the same transformation key and homomorphic encryption key used for the creation of the user’s reference template. The protected template is then sealed using the sealing key.
- Face verification and comparison: The sealed protected template is sent to the face verification module where it will be compared with the user’s protected reference template.
- Score comparison: The comparison generates a similarity score and then make a verification decision based on whether or not the score meets a pre-defined threshold. The output from the process is the verification decision, which is accessible to the vendor.
- Authorization: If the verification decision is positive, the user will be authorized to use the online service.
What are the components of the facial verification system?
This system involves the following modules:
- Capture module: This module runs in mobile applications on the users’ smartphones and communicates with the camera application and the user during the selfie capturing sequence. The mobile application will typically be provided by a bank or BankID. The capture module is a software component in these mobile applications.
- Face verification module: This module compares a reference image (derived from an ID-document during the onboarding phase), and a live image of the face that the user takes of him/herself during the verification phase. This module generates a similarity score that indicates the probability of the images coming from the same person.
- Fraud detection module: This module analyses live images to assess whether they were captured live from a present person, or if there is an impersonation or manipulation. Fraud detection includes the following sub-modules
- Face presentation attack detection: This module can detect if the live image is real, or if it is a digital surface or a mask. This module prevents fraudsters from presenting digital images of other users to gain remote access.
- Face deepfake detection: This module detects if the live image is a deepfake, i.e., a synthetic image that is generated through machine learning or that has been swapped.
- Face morphing attack detection: This module detects if the reference image is intentionally «morphed». A morphing attack consist of two or more facial identities that are digitally combined to create a single facial image that represents multiple identities. In a successful morphing attack, an ID-document can be used by multiple identities.
All these modules contain pre-trained models that uses artificial intelligence.
What personal data will be processed?
As outlined in the step-by-step description, personal information about the user will be gathered and processed. This personal information includes:
- Facial images captured with the end-user's device.
- Plaintext templates that are generated from the reference image (i.e., a nationally issued ID-document).
- Protected templates, which encompass plaintext templates that is protected by homomorphic encryption.
- Face image extracted from the Radio Frequency Identification (RFID) chip of the end-user’s ID-document (for example passport or national issued ID card)
- Digital readable data from the machine-readable section of nationally issued IDs, as per the electronic machine-readable travel document standard (ICAO 9303)
- Data from the machine-readable zone (“MRZ”) on the ID-document, necessary to gain access to the information on the RFID chip
- Information about the user device
As related to the step-by-step description above, Mobai will use this information for the purpose of the enrolment to a service and following verifications.
Who are the most relevant stakeholders?
In the SALT-solution, there are four main stakeholders who play distinct roles. These are:
- eID provider: This actor issues the eID (such as BankID, Buypass, Commfides and MinID,) to the end-user and provides the eID services to a merchant.
- Mobai: Sub-vendor to the eID provider, where Mobai provides specific components to the eID services. SALT augments these services by providing an extra security layer for services offered by the eID provider. These components include services like 1) remote onboarding to issue an eID, 2) re-issuing an eID, 3) resetting password or 4) confirming “liveliness” (i.e., that the correct person has access).
- Merchant (such as SpareBank 1 Østlandet): This third-party act as a merchant and relies on the eID provider, and consequentially Mobai’s components as an extra security layer, in order to ensure that they are giving access to their services to the correct end-user.
- The end-user: The motivation for the end-user to use the solution is to remotely verify their identity to a service without the risk of “fraudsters” using their eID with or without their knowledge.