A Framework for Security and Risk Analysis of Enrollment Procedures:

Application to Fully-remote Solutions based on eDocuments

Marco Pernpruner

1,2 a

, Giada Sciarretta

1 b

and Silvio Ranise

1,3 c

Security & Trust Research Unit, Fondazione Bruno Kessler, Trento, Italy

Department of Informatics, Bioengineering, Robotics and System Engineering, University of Genoa, Genoa, Italy

Department of Mathematics, University of Trento, Trento, Italy

Keywords:

eDocuments, Enrollment, Onboarding, Risk Analysis, Security Analysis, Security Framework.

Abstract:

More and more online services are characterised by the need for strongly verifying the real-world identity of

end users, especially when sensitive operations have to be carried out: just imagine a fully-remote signature

of a contract, and what could happen whether someone managed to perform it by using another person’s

name. For this reason, the identity management lifecycle contains speciﬁc procedures – called enrollment or

onboarding – providing a certain level of assurance on digital users’ real identities. These procedures must be

as secure as possible to prevent frauds and identity thefts. In this paper, we present a framework composed

of a speciﬁcation language, a security analysis methodology and a risk analysis methodology for enrollment

solutions. For concreteness, we apply our framework to a real use case (i.e., fully-remote solutions relying on

electronic documents as identity evidence) in the context of a collaboration with an Italian FinTech startup.

Beyond validating the framework, we analyse and highlight the essential role of mitigations on the overall

security of enrollment procedures.

1 INTRODUCTION

Verifying a person’s real identity has always been a

risky operation, considering that paper-based iden-

tity documents could be counterfeited with little or

even no possibility of detection. This is one of the

main reasons why electronic documents (also called

eDocuments) have been created: these documents

are equipped with contactless chips that can be read

wirelessly, and in some cases they are also capable

of performing cryptographic operations. In addition,

eDocuments are tamper-resistant and provide a high

level of assurance on the attested data. As a result,

many companies that previously required customers

to physically visit a branch to perform some sensi-

tive operations (such as opening a new bank account

or signing a contract) can now leverage the intrin-

sic security assured by eDocuments to provide fully-

remote procedures and thus improve the usability on

their clients’ side. Although NIST deﬁnes these pro-

cedures as enrollment (Grassi and Fenton, 2017), they

https://orcid.org/0000-0001-8936-2726

https://orcid.org/0000-0001-7567-4526

https://orcid.org/0000-0001-7269-9285

are commonly referred to as onboarding, especially

when they lead to customer acquisitions.

However, simply relying on eDocuments’ security

is not enough: enrollment procedures must be sturdily

designed and adopt suitable security mechanisms to

prevent impersonation attacks. Moreover, such pro-

cedures – as well as physical ones – are subject to

many guidelines and regulations that have been inter-

nationally issued to prevent frauds and identity thefts

(e.g., Anti Money-Laundering in the ﬁnancial sector).

In this paper, we present a framework for secu-

rity and risk analysis of enrollment procedures, that is

based on the following components:

• Speciﬁcation Language: starting from the anal-

ysis of on-the-market solutions, we have derived

a list of basic actions that are commonly involved

in enrollment procedures. In order to allow an

easy description and analysis of the procedures,

we describe them by means of a simple speciﬁca-

tion language with precise semantics;

• Security Analysis Methodology: we describe a

security analysis methodology for enrollment pro-

cedures by deﬁning the concept of identiﬁcation

factors (that we have borrowed and adapted from

222

Pernpruner, M., Sciarretta, G. and Ranise, S.

A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-remote Solutions based on eDocuments.

DOI: 10.5220/0010554502220233

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 222-233

ISBN: 978-989-758-524-1

the authentication context), threat model and se-

curity goal;

• Risk Analysis Methodology: we describe a risk

analysis methodology to provide a prioritization

of the attackers detected during the security anal-

ysis according to their severity.

Our framework can be generally adopted to de-

scribe and analyse any enrollment procedure, by sim-

ply adjusting – if needed – the set of actions in-

volved (i.e., the speciﬁcation language) and the capa-

bilities of the attackers on these actions (i.e., the threat

model). For concreteness, we have applied the frame-

work in the context of a realistic use case (i.e., fully-

remote solutions relying on eDocuments), where we

have also analysed the role of security mitigations on

the overall security of enrollment procedures.

Structure of the Paper Section 2 provides some

essential concepts to understand what follows; Sec-

tion 3 identiﬁes our requirements; Section 4 deﬁnes

our framework and its components; Section 5 dis-

cusses some security mitigations that we have iden-

tiﬁed; Section 6 shows the application of the frame-

work to a real use case and highlights the essential

role of security mitigations; Section 7 discusses some

state-of-the-art solutions considered throughout this

work and Section 8 ﬁnally draws conclusions.

2 BACKGROUND

Enrollment. The National Institute of Standards

and Technology (NIST) has recently released the Spe-

cial Publication 800-63 suite (NIST, 2017) dealing

with digital identity. According to the deﬁnitions in

(Grassi et al., 2017b; Grassi and Fenton, 2017), the

enrollment can be considered as the procedure allow-

ing users to obtain a credential from a speciﬁc ser-

vice, after the veriﬁcation of their identity. An enroll-

ment ﬂow is composed of three main parts: (i) Res-

olution: the service collects the personal information

of the applicant and some identity evidence (e.g., a

digital copy of an identity document through a cam-

era or a scanner); (ii) Validation: the service veri-

ﬁes the genuineness of the identity evidence provided

(e.g., by querying authoritative sources or visually

checking the documents), thus obtaining guarantees

on the identity information; (iii) Veriﬁcation: the ser-

vice checks that the identity evidence belongs to the

applicant (e.g., by collecting a picture of her and com-

paring it with the one embedded in the document). All

these parts are extremely sensitive and potentially ex-

posed to many security issues: in case Validation and

Veriﬁcation were not properly secured, users could

provide wrong or ﬁctional personal information, al-

tered identity evidence or even identity evidence be-

longing to someone else. Therefore, enrollment pro-

cedures must be properly designed to rely on cutting-

edge techniques and assure that the user is really who

she claims.

Electronic Documents. When dealing with paper-

based identity documents, the detection of tampered

or misused identity evidence is not trivial, since crimi-

nals have always found new ways to counterfeit them.

For these reasons, electronic versions of identity doc-

uments have recently been produced: passports be-

came electronic passports (ePassports), while elec-

tronic identity cards (eID cards) replaced paper-based

identity cards. These eDocuments are equipped with

a contactless chip that can be read wirelessly and con-

tains the citizen’s personal data; in this way, criminals

would need to forge not only the printed data, but also

those contained within the chip (that is much more

difﬁcult, as they are digitally signed).

As for ePassports, to allow only authorized people

to access the personal data, the identity page contains

a machine-readable zone (MRZ) that must be scanned

by the reader to derive the key needed to mutually au-

thenticate with the ePassport’s chip; the reader can

then interact with the ePassport in order to get the

personal data. These data can be validated by check-

ing the Document Security Object (SOD), a speciﬁc

ﬁle containing the signature of all the personal data’s

hashes: the reader can thus verify the authenticity and

integrity of the data. This procedure, currently used

by customs and immigration ofﬁces at borders, is pro-

vided by the MRTD application (ICAO, 2015).

The MRTD application is also contained in eID

cards, which – in addition – provide another mod-

ule for online authentication and, indirectly, for iden-

tiﬁcation: the IAS ECC application (GIXEL, 2009).

In fact, given the key pair and the X509 certiﬁ-

cate (Cooper et al., 2008) they are equipped with,

eID cards can be used in a challenge-response pro-

tocol: an application willing to authenticate the user

can send a challenge (i.e., a piece of information asso-

ciated with the ongoing operation) to the reader, and

thus to the eID card. By signing the challenge through

its private key, the eID card generates the response;

this operation can be performed only once the user

has inserted the PIN of the speciﬁc document. Since

the eID card’s public key is known, the application

can verify the proper signature of the original chal-

lenge, ﬁnally authenticating the user.

A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-remote Solutions based on eDocuments

223

Table 1: OWASP risk computation.

— Likelihood →

Low Medium High

| Low Note Low Medium

Impact Medium Low Medium High

↓ High Medium High Critical

OWASP Risk Rating Methodology. The Open

Web Application Security Project (OWASP) has

developed the Risk Rating Methodology (OWASP,

2018), an approach to estimate the severity of spe-

ciﬁc risks. The risk is deﬁned as likelihood × impact,

where the likelihood rates the probability of exploit-

ing a speciﬁc vulnerability, while the impact measures

the consequences of an attacker successfully leverag-

ing a vulnerability.

Computing the likelihood and the impact requires

the identiﬁcation of some suitable factors, which can

be dependent on the considered scenario and have to

be given a score ranging from 0 to 9; lower scores for

likelihood factors mean less likely, while when deal-

ing with the impact they denote less serious conse-

quences in case the considered vulnerability was ex-

ploited. The ofﬁcial OWASP documentation provides

some examples regarding factors, although they can

be fully customised: for instance, Ease of Discovery

may be a likelihood factor representing how easy the

considered vulnerability can be discovered (where 1

= practically impossible, 3 = difﬁcult, 7 = easy, 9 =

automated tools are available for this purpose).

Once these factors have been identiﬁed and rated,

the overall likelihood and impact result from the aver-

age of such scores, which are then assigned a qualita-

tive label according to their value: Low if value < 3,

Medium if 3 ≤ value < 6, High if value ≥ 6.

Finally, the overall risk can be found by combin-

ing the likelihood and impact labels as in Table 1.

3 REQUIREMENTS

Enrollment procedures are now playing a key role in

many sensitive contexts. In addition, the current situ-

ation connected with COVID-19 – preventing people

from physically visiting public ofﬁces and company

branches – further requires a way to be securely and

easily identiﬁed from home, possibly by using already

owned devices. One of the easier and less complex

remote identiﬁcation methods consists of a video call

between a service operator and the person who has to

be identiﬁed, with the former asking the latter for any

document needed to ﬁnalise the operation. However,

since human operators have to be physically involved

in the call, this method may slow down the enroll-

ment process, especially when a considerable amount

of people needs to be identiﬁed in the same period.

Moreover, as online services should be accessible by

everyone, the enrollment procedure should be carried

out as simply as possible (e.g., without requiring peo-

ple to perform complex operations or to install soft-

ware). From all these considerations, we can infer the

following requirements that an enrollment procedure

should meet. The procedure must:

R1. be carried out remotely and automatically,

without human operators for identiﬁcation;

R2. rely on devices that people already own;

R3. provide an adequate level of usability, thus

allowing everyone to ﬁnalise it.

4 FRAMEWORK

In this section, we describe the framework that we

have developed, composed of a speciﬁcation language

to model enrollment protocols (Section 4.1), a secu-

rity analysis procedure (Section 4.2) and a risk anal-

ysis procedure (Section 4.3). Finally, we discuss the

usefulness of the framework (Section 4.4).

4.1 Speciﬁcation Language

The speciﬁcation language aims at providing a sim-

ple and graphical way to model enrollment proce-

dures. In this work, for the sake of concreteness, we

have decided to instantiate the requirements deﬁned

in Section 3 by focusing on eDocuments, which allow

secure remote identiﬁcations (satisfying R1). More-

over, the automatic data extraction from eDocuments

enhances the overall level of usability and prevents

mistakes (satisfying R3). However, to beneﬁt from

all these capabilities, people would need to own NFC

readers enabling the interaction with the eDocuments.

Instead of forcing people to buy a reader to plug into

their personal computers, we require a mobile appli-

cation (hereafter app) that can be used with smart-

phones or tablets equipped with NFC (satisfying R2).

Consequently, by focusing on eDocuments, we

have identiﬁed a list of basic actions that are com-

monly involved in enrollment procedures based on

such means, thus deﬁning the speciﬁcation language

displayed in Table 2. When modelling an enrollment

procedure, the involved actions are depicted in se-

quence separated by a semicolon; this is the visual

representation of an enrollment ﬂow, which can be de-

ﬁned as a ﬁnite set of actions from those in Table 2.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

224

Some actions may require a basic entity as argument,

which is represented between parenthesis.

Example 1. An enrollment procedure requiring

users to insert the eID card’s PIN (÷(PIN)), read the

document through NFC ( (æ)) and ﬁnally conﬁrm the

correctness of the extracted data (¡) can be mod-

elled as follows:

÷(PIN); (æ); ¡

Although for concreteness we focus on enrollment

procedures based on eDocuments, the speciﬁcation

language can be used with any enrollment procedure

by properly extending – if needed – the set of involved

basic actions.

4.2 Security Analysis

In order to perform a security analysis, we refer to

the idea of factors. While authentication factors have

been deﬁned by NIST (Grassi et al., 2017a) for au-

thentication, we are not aware of a similar notion for

enrollment. To ﬁll this gap, in this work we intro-

duce identiﬁcation factors. These factors are associ-

ated with the actions that the user is required to per-

form, though not all actions are necessarily associated

with an identiﬁcation factor. For instance, ¯ is not

related to any identiﬁcation factor, while ÷(PIN) is as-

sociated with

{

}

We deﬁne as security goal (SG) the set of identiﬁ-

cation factors that should not be compromised for the

enrollment procedure to be considered secure.

Example 2. Considering the ﬂow in Example 1, the

identiﬁcation factors involved are the eID card and

the related PIN. Therefore:

SG =

{

æ, PIN

}

A threat model (T M ) over the identiﬁcation fac-

tors is a pair (AT T , C ), where AT T is the set of con-

sidered attackers (detailed below) and C represents

their capabilities. More precisely, C is a collection

of mappings corresponding to each attacker in AT T :

given an attacker and an identiﬁcation factor, C re-

turns a padlock representing the attackers’ effects on

that identiﬁcation factor: the green padlock () de-

notes a non-compromised factor, while compromised

factors are represented by a red padlock (). More-

over, we use an asterisk (

∗

) to depict a factor that is

compromised indirectly (e.g., in case an attacker de-

ceives the victim into interacting with her eDocument

instead of physically stealing it).

Example 3. Following Example 2:

• a person standing behind the user could look at

the PIN while the user is typing (PIN → ), but

he has no effect on the eID card (æ → );

• a malicious application on the user’s mobile de-

vice could directly intercept the PIN while the user

is typing (PIN → ) and deceive the user into

placing the eID card near the device, thus indi-

rectly compromising it (æ → 

∗

To avoid missing some attacks, C should be de-

ﬁned through a worst-case approach, unless some se-

curity mitigations are implemented in the protocol; in

this case, their effects must be taken into considera-

tion when deﬁning the capabilities in C. For instance,

a malicious application running on the user’s mobile

device should be considered able to escalate the de-

vice’s privileges and obtain root access, unless some

mitigations prevent this behavior or warn the user.

To identify the set of attackers for our analysis,

we take inspiration from the Enrollment and Identity

Prooﬁng Threats deﬁned by NIST (Grassi and Fen-

ton, 2017): among these, we do not consider attackers

belonging to the falsiﬁed identity prooﬁng evidence

category, as they cannot be effective due to eDocu-

ments’ tamper-resistance, nor enrollment repudiation

that for the moment is out of the scope of this work (it

deals with an already enrolled user that denies having

performed an enrollment). Instead, we focus on the

fraudulent use of another’s identity category, whose

attackers aim to use identity documents belonging to a

different individual to complete an enrollment. There-

fore, in our analyses, AT T is the set of the following

attackers:

• Identity Document Thief (IDT): steals an iden-

tity document from its legitimate owner;

• Eavesdropping Software (ES): intercepts the

data typed on the device (e.g., keylogger);

• Shoulder Surfer (SS): obtains secrets by looking

at the user inserting sensitive information;

• Social Engineer (SE): exploits human gullibil-

ity and conﬁdence in others, thus deceiving peo-

ple into revealing secret information or perform-

ing actions to their advantage;

• Malicious Application (MA): runs on the at-

tacker’s or the victim’s mobile device. In the for-

mer case, the app can fake or alter the communi-

cation between the legitimate app and the server;

in the latter case, instead, the app can both inter-

act with the victim to obtain her personal data or

pictures, and access the device’s internal storage

to get the needed information autonomously.

An enrollment ﬂow violates the security goal S G

under the threat model T M = (AT T , C) iff there is

an attacker (or a combination of them) in AT T that –

given its capabilities deﬁned in C – compromises (di-

rectly or indirectly) all the identiﬁcation factors con-

tained in the SG associated to the ﬂow.

A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-remote Solutions based on eDocuments

225

Table 2: Speciﬁcation language for the description of the ﬂows.

Basic entities

æ The eID card m The ePassport

ç An additional personal document PIN The PIN of the eID card

; The MRZ printed on the eDocuments  The selﬁe captured by a user

Actions

The user may be required to...

¯ agree with the app’s privacy policy and terms 

choose the type of eDocument she wishes to use

and the interaction mode

provide some extra information that is not included

in the eDocument

check and conﬁrm the correctness of her personal

data, as extracted from her eDocument

insert her email address and to verify it

(e.g., through a link or an OTP sent by email)



insert her phone number and to verify it

(e.g., through an OTP sent by SMS)





capture a photo selﬁe. In case the selﬁe also needs

to contain an additional element, this will be speci-

ﬁed as argument

(•)

place the element speciﬁed as argument near the

device, so that the app can interact with it through

NFC



capture a video selﬁe ê(•)

scan the element speciﬁed as argument through the

device’s camera

(•) take a picture of the argument ÷(•) insert the information speciﬁed as argument

Example 4. Following Example 3, the malicious

application (now deﬁned as MA) violates the security

goal SG since it manages to compromise all the iden-

tiﬁcation factors involved (i.e., all these identiﬁcation

factors are marked with a red padlock:  or 

∗

Deﬁnition 1. The security analysis problem for an

enrollment ﬂow under a threat model T M is to ﬁnd

all (if any) minimal subsets AT T ⊆ AT T so that ATT

violates SG.

Speciﬁcally, a subset AT T ⊆ AT T is minimal iff

AT T violates S G and, for each ATT

( AT T , ATT

does not violate SG.

Example 5. Given Example 4, the considered

ﬂow can be violated by

{

}

; moreover, any fur-

ther combination involving MA (e.g.,

{

MA, IDT

}

{

MA, ES

}

) is obviously successful, since MA’s capa-

bilities are unchanged or even enriched. However,

only

{

}

will be considered since the other attack-

ers do not represent minimal subsets.

4.3 Risk Analysis

The risk analysis that we perform is based on the

OWASP Risk Rating Methodology described in Sec-

tion 2. By taking inspiration from (Pernpruner et al.,

2020), in our analysis we consider the following like-

lihood factors

The OWASP Risk Rating Methodology uses the term

factors to identify the elements that are considered to com-

pute the likelihood and impact (cf. Section 2). It is highly

important to be aware that such factors have a completely

different meaning than identiﬁcation factors.

• Technical Difﬁculty (TD): rates the technical

difﬁculty of an attack to be successfully per-

formed. More difﬁcult attacks are connected with

a lower likelihood;

• Opportunity (O): provides a measure of the at-

tacker’s opportunity to perform the attack. This

opportunity can be restricted by limitations affect-

ing the chance of successfully completing an at-

tack; for instance, a device protected with a screen

lock would be more difﬁcult (and thus less likely)

to be used than unprotected ones;

• Attack Vector (AV): considers the means through

which the attack must be performed. An attack

requiring a physical intervention would be less

likely than a fully remote one;

• User Interaction needed (UI): measures

whether an attack requires an interaction with

the victim to be successful. Attacks requiring a

precise operation by the user would be less likely

than others not requiring any interaction;

• Spread of Attack (SA): deals with the spread of

the considered attack, according to trusted statis-

tics. Popular attacks increase the probability.

Instead, the impact factors are the following:

• Attack Scale (AS): considers how many people

would be affected by the attack. More involved

users result in a higher impact;

• Attack Detection (AD): deals with the possibil-

ity of detecting a successful attack. When an at-

tack is discovered, it can be hindered, thus making

easy-to-detect attacks have a lower impact.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

226

In case some security mitigations are implemented

in the protocol, their effects must be taken into con-

sideration when assigning values to the factors above.

Deﬁnition 2. The risk analysis problem for an en-

rollment ﬂow under a threat model T M = (AT T , C )

is to ﬁnd the risk associated with all the minimal sub-

sets of attackers violating SG.

Example 6. The risk of a single attacker (e.g., MA

from Example 5) is determined as follows. First, we

need to assign a justiﬁed value to each likelihood and

impact factor; for instance, considering that MA can

operate remotely, its Attack Vector is 7. By repeating

this operation for each factor, we obtain all the val-

ues, which for MA can be the following: for the like-

lihood TD = 3, O = 1, AV = 7, UI = 1, SA = 2; for

the impact AS = 8, AD = 7. Then, after computing

the overall likelihood (2.80) and impact (7.50) by the

average of the corresponding factors, we can assign

them the corresponding labels (see Section 2): Low

to the likelihood, High to the impact. The combina-

tion of these values, according to Table 1, results in a

Medium risk.

When dealing with a combination of attackers,

ﬁnding a unique value for each factor is not trivial: in

fact, every attacker that is part of the combination has

his own values for all the factors. Therefore, we need

to combine attackers’ values as if we were consider-

ing a single attacker. Given the factors’ meanings, we

use the following logic:

• for TD, AV, UI, AS and AD the combined value

should be the minimum of all the attackers’ values

for the considered factor;

• for O and SA the aggregated value should be

less than the minimum of all the attackers’ values

for the considered factor.

Example 7. Considering the combination

{

IDT , ES

}

, the thief (IDT) requires physical in-

tervention (AV = 1) while the keylogger (ES) can act

remotely (AV = 7); therefore, even the combination

of such attacks must be performed (at least partially)

through a physical intervention, thus the combined

Attack Vector will be 1. On the other hand, consider-

ing that the thief (IDT) has O = 3 while the keylogger

(ES) has O = 4, their combined Opportunity is

further reduced to 2 (less than the minimum) since

the two single attackers must collude in order to be

effective.

Once a single value for every factor has been com-

puted, the procedure can continue as when consider-

ing a single attacker.

4.4 Usefulness of the Framework

Once the analyses have been performed, the outputs

of the framework can help properly tune the secu-

rity level of enrollment procedures: in many con-

texts, such as the ﬁnancial one, different categories

of customers may have different needs to address; the

framework can help determine which solutions are

worth adopting depending on the risk level one is will-

ing to accept. Moreover, the possibility to analyse a

protocol by changing the set of security mitigations

implemented allows a what-if analysis, thus helping

designers understand the risks and analyse the effects

of mitigations on their protocols.

The framework can be used to model and anal-

yse the security and risk of any enrollment procedure,

since the set of actions involved (i.e., the speciﬁca-

tion language) and the capabilities of the attackers

on the associated identiﬁcation factors (i.e., the threat

model) can be fully customised and adapted (if nec-

essary) to the considered scenario.

In addition, the security and risk analysis prob-

lems that we have deﬁned in Deﬁnitions 1 and 2 are

decidable. In the former case, the security analysis

problem considers ﬁnite sets, thus it is always possi-

ble to analyse all the involved attackers and combi-

nations of them to identify those violating the secu-

rity goal (if any). As for the latter case, instead, the

risk analysis problem takes in input the list of suc-

cessful attackers from the security analysis and eval-

uates the risk for each of them, thus working on ﬁnite

sets again. These considerations make the framework

suitable for implementation in an automated tool (cur-

rently an ongoing activity) to automatically assess the

security of enrollment procedures.

5 MITIGATIONS

By both analysing state-of-the-art solutions and elab-

orating some ideas ourselves, we have identiﬁed a list

of security mitigations that can be applied to enroll-

ment procedures involving eDocuments (as per Sec-

tion 3); these mitigations are displayed in Table 3

together with the effects they have on the attackers

belonging to AT T (and thus on their capabilities in

C). To better understand them, it is important to no-

tice that – depending on how the interaction with the

eDocument happens – we can distinguish two scenar-

ios:

• MRTD scenario: the applicant uses its eID card

and allows the app to interact with it by scanning

the MRZ (see Section 2);

A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-remote Solutions based on eDocuments

227

Table 3: List of the identiﬁed mitigations and their effects.

# Mitigations Effects on attackers Source

Provide the app with a root detection library, in

order to prevent the use of the app on rooted de-

vices.

ES, MA  (makes the detection easier in case this

attacker forces a root of the device)

From (OWASP, 2020)

(§ 8.1).

Leverage code obfuscation methodologies to pre-

vent attackers from fully understanding the source

code of the app (at least the most sensitive func-

tions).

MA  (decrease the chance of understanding the

code, and thus to alter the app)

From (OWASP, 2020)

(§ 8.9).

Implement, in the IAS ECC scenario, a binding

between the challenge and the certiﬁcate used to

establish a mutual TLS channel.

MA  (only in the IAS ECC scenario: prevent the at-

tacker from injecting a stolen response in the legitimate

app)

Originally used in

OAuth 2.0 to bind ac-

cess tokens (Campbell

et al., 2020).

Implement, in the MRTD scenario, a set of checks

on the authenticity of the provided data.

MA  (only in the MRTD scenario: prevent the at-

tacker from sending fake information)

Require users to capture a selﬁe at that moment,

preventing the upload of existent ﬁles.

SE £ (cannot reuse ﬁles that have been deceivingly

obtained by the user)

From many state-of-

the-art solutions (see

Section 7).

Force the user to capture the selﬁe from the front

camera.

SS £ (cannot capture pictures or video of people in

the proximity)

From many state-of-

the-art solutions (see

Section 7).

Request users to capture the selﬁe also in the IAS

ECC scenario.

IDT, ES £ (cannot obtain the selﬁe of the user)

SS, SE  (have less probability of obtaining the selﬁe

of the user)

Implement liveness detection libraries to detect

the misuse of static or modiﬁed pictures.

SE £ (cannot inject fake pictures on the legitimate

app)

SS  (decrease the chance of obtaining pictures or

video of people in the proximity)

NB: MA is not affected as they can bypass the liveness

checks

From most state-of-

the-art solutions (Ju-

mio, 2020a; iDenfy,

2020b).

Implement techniques to link the selﬁe captured

during the procedure to the ongoing session, thus

requiring the users to insert some fresh informa-

tion.

MA  (cannot misuse already existent pictures or self-

ies that have already been used in other enrollment op-

erations)

From some state-of-

the-art solutions (Cas-

sidy, 2018).

£ = attacker made ineffective  = attacker’s risk decreased

• IAS ECC scenario: the applicant uses its eID

card and allows the app to interact with it by pro-

viding the PIN.

The proposed mitigations are fully compliant with

the requirements in Section 3, with particular re-

gard to R1: even those that are performed server-

side (e.g., M8 and M9) can indeed be implemented

through fully automated machine-learning algorithms

that require human intervention only when certain se-

curity thresholds cannot be achieved.

Security designers do not necessarily need to im-

plement all the proposed mitigations, as they can se-

lect those ﬁtting best in their use cases. Of course, im-

plementing only a subset of the proposed mitigations

could affect the security and risk level of the proce-

dure.

In addition to the description in Table 3, it is worth

providing further details on some less-trivial mitiga-

tions, so as to better understand and thus manage to

implement them in a proper way.

M3. To prevent the use of a stolen response by

unauthorized parties, we suggest implementing a pro-

cedure similar to the one described for OAuth in RFC

8705 (Campbell et al., 2020). The mutual TLS chan-

nel that gets established does not aim to perform

client authentication (self-signed certiﬁcates do not

provide any guarantee), yet the binding of the app’s

self-signed certiﬁcate to the authentication challenge.

This way, as only the app knows the private key cor-

responding to its self-signed certiﬁcate, the server can

be sure that the response presented by a client con-

tains a challenge that was previously issued to the

same client, and thus that it has not been stolen or

tampered with. This procedure involves the following

additional steps:

1. before starting the enrollment procedure with the

eID card, the app must generate a key pair with a

self-signed certiﬁcate on the user’s mobile device;

2. the app establishes a mutual TLS channel with the

server using the generated key pair and certiﬁcate;

3. the server generates a challenge, associates the

SECRYPT 2021 - 18th International Conference on Security and Cryptography

228

client certiﬁcate with it and sends the certiﬁcate-

bound challenge to the app;

4. the app interacts with the eID card to sign the chal-

lenge. The response is sent to the server after es-

tablishing a mutual TLS channel;

5. the server veriﬁes the response and checks that the

certiﬁcate used to establish the mutual TLS chan-

nel is the same that is bound to the challenge.

M4. In Section 2, we described how people’s per-

sonal data can be veriﬁed server-side in the IAS

ECC scenario through a challenge-response protocol.

Moreover, we stated that the MRTD scenario pro-

vides guarantees on the extracted information only

for in-person procedures, with physical readers ver-

ifying the Document Security Object (SOD, detailed

in (ICAO, 2015)). However, as brieﬂy explained in

M4, we would need a way to trust the information ex-

tracted even during remote identiﬁcation operations.

To this end, we could rely on the SOD in a different

way: since this object provides a digital signature of

all the eDocument’s data groups, the app could send

it along with the extracted data, so to allow the server

to perform the proper veriﬁcations on the authenticity

and integrity of the received data. In this way, MA at-

tackers trying to violate SG by sending fake informa-

tion – without even interacting with a real eDocument

– are prevented, since they would need a SOD that they

cannot provide since those personal data are ﬁctional

and not extracted from an existing eDocument.

On the other hand, MA attackers that interact with

an eDocument through MRTD can also read the SOD:

for this reason, although the server can check the au-

thenticity of the data (i.e., the Validation part of the

enrollment ﬂow, as detailed in Section 2), it cannot

verify that they really belong to the applicant (i.e., the

Veriﬁcation part).

M7. As the picture contained in the eID card is

not included in the X509 certiﬁcate, M7 requires the

reader to access both the IAS ECC and MRTD ap-

plications (to retrieve the X509 certiﬁcate and the

owner’s picture, respectively). To do this, the MRZ

value must be inferred by following a speciﬁc proce-

dure (ICAO, 2015). Once this value has been derived,

the reader can mutually authenticate with the eID card

and access the picture as in the MRTD scenario.

M9. The most promising techniques to implement

this mitigation are the following:

S1. Require the user to write an alphanumeric

code suggested by the app on a piece of paper,

and take a selﬁe with it; the code aims to enable

the server to perform some veriﬁcations on the

link with the ongoing operation. Speciﬁcally, the

server should verify that: the user’s face from the

selﬁe matches the one from the eDocument’s pic-

ture, the code written on the paper is correct, and

the selﬁe has been sent within a certain interval.

S2. Require the user to capture a video of her-

self while reading some words aloud; these words

would be suggested by the app to enable the server

to perform some veriﬁcations on the link between

the words and the ongoing operation. Speciﬁcally,

the server should verify that: the user’s face from

the video-selﬁe matches the one from the eDocu-

ment’s picture, the words read aloud are correct,

and the video-selﬁe has been sent within a certain

interval.

6 FRAMEWORK APPLICATION

In this section, we apply the framework described in

the previous sections to a concrete enrollment pro-

cedure satisfying the requirements in Section 3 and

speciﬁcally based on eDocuments. We have per-

formed this work in collaboration with the Italian Fin-

Tech startup CherryChain

, by focusing on a realistic

use case inspired to their research and innovation ac-

tivities: one of the main projects they are developing

aims at realising a unique platform to connect service

providers (e.g., energy suppliers) and consumers, thus

handling the whole contracting lifecycle; the ﬁrst step

of this project is represented by the enrollment.

After describing the enrollment procedure that we

have designed for this use case (Section 6.1), we per-

form the security and risk analysis on the designed

procedure (Sections 6.2 and 6.3).

6.1 Speciﬁcation Language

In Section 5, we have identiﬁed the two possible sce-

narios when dealing with eDocuments; each of them

can be associated with an enrollment ﬂow that we now

describe by detailing all the actions involved. Regard-

less of the scenario, each ﬂow begins with some com-

mon actions: ﬁrst, the user is requested to agree with

the privacy policy and terms of service (¯). Then,

she has to choose the type of document she would like

to use (in this case, eID card) and whether she wants

to provide the PIN or not (), thus being redirected

to the IAS ECC or MRTD scenario, respectively. The

next actions, instead, are strictly connected with the

considered ﬂow:

https://www.cherrychain.it/

A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-remote Solutions based on eDocuments

229

MRT D : ¯; ; ê(;); (æ); ¡; @; ; 



IAS ECC : ¯; ; ÷(PIN); (æ); ¥; ¡; @; ; 



6.1.1 Flow for the MRTD Scenario

After the common actions, the user is required to scan

the MRZ of her eID card through the device’s camera

(ê(;)) and read this document through the device’s

NFC capabilities ( (æ)). The residence address can

be extracted from the eID card, so the user only has to

conﬁrm the correctness of all the data or modify them

in case, e.g., the residence address has changed (¡).

After providing and verifying both the email address

(@) and the phone number (), the user is required

to capture a selﬁe (



); the ﬂow is then completed.

6.1.2 Flow for the IAS ECC Scenario

After the common actions, the user is required to in-

sert the PIN (÷(PIN)) and read her eID card through

her mobile device’s NFC capabilities ( (æ)). She is

then asked to manually insert the residence address

(¥) – not present in the X509 certiﬁcate, thus can-

not be extracted from the eID card in this scenario –

and conﬁrm the correctness of all the data (¡). Once

provided and veriﬁed both the email address (@) and

the phone number (), the user is required to capture

a selﬁe (



); the ﬂow is then completed.

6.2 Security Analysis

In this section, we perform a security analysis of the

enrollment procedure described in Section 6.1. Ac-

cording to the considered ﬂow, we can identify a list

of identiﬁcation factors involved:

• MRTD: the eID card (æ) and the selﬁe ()

that is later compared to the eID card’s picture

→ SG

MRT D

{

æ, 

}

• IAS ECC: the eID card (æ), its PIN and the

selﬁe () that is later compared to the eID card’s

picture → SG

IAS_ECC

{

æ, PIN, 

}

To perform the security analysis, we have to un-

derstand how each attacker in AT T affects the iden-

tiﬁcation factors; such capabilities (represented by C)

are displayed in Table 4 through the padlock notation

described in Section 4.2.

6.2.1 Analysis for the MRTD Scenario

The ﬂow belonging to this scenario relies on the eID

card (

æ) and the selﬁe () as identiﬁcation factors,

thus we have to focus only on these two columns in

Table 4; according to them, the only minimal subset

that manages to compromise the protocol is

{

}

. In

Table 4: Attackers’ capabilities.

Attackers

Identiﬁcation Factors

æ PIN



IDT



 

















∗

 

 = safe  = compromised 

∗

= indirectly compromised

fact, although M4 and M9 considerably affect this at-

tacker (by enabling the server to verify the integrity

of the received data and the connection between the

selﬁe and the ongoing enrollment operation, respec-

tively), MA still manages to bypass them: in the for-

mer case, by getting the victim’s personal data and

SOD by interacting with her eID card through the ma-

licious app on her device, then reusing these data on

his own device; in the latter case, by maliciously in-

teracting with the victim and deceiving her into pro-

viding the fresh selﬁe as required. Moreover, MA also

manages to bypass M8 by pretending to be sending a

fresh selﬁe.

Instead, some mitigations are completely effective

against some other attackers: by preventing the reuse

of selﬁes obtained through user’s deception, M5 and

M8 make SE ineffective; therefore, these mitigations

thwart the combination

{

IDT , SE

}

that would other-

wise be able to obtain both the eID card and the selﬁe.

Similarly, M6 and M8 defeat SS by preventing it from

taking pictures or videos of users in proximity; there-

fore, also the combination

{

IDT , SS

}

– which would

be otherwise able to obtain the eID card and capture

an unauthorized picture of the user as if it was a user’s

selﬁe – is not effective.

6.2.2 Analysis for the IAS ECC Scenario

The ﬂow belonging to this scenario relies on the eID

card (æ), the PIN and the selﬁe () as identiﬁcation

factors, thus we have to focus on all the columns in

Table 4; according to them, even this scenario can

be violated only by the minimal subset composed of

{

}

. Regarding the mitigations, M3 prevents

{

}

from injecting a stolen signed challenge in legitimate

apps, since the TLS binding requires the app that gets

the challenge to be the same as the app that sends

the response back. However, MA could be success-

ful anyway when a signed challenge is captured by a

malicious app in the user’s smartphone and then in-

jected into another malicious app under the control of

the attacker. In this case, being both apps in control of

the attacker, MA could use the same key pair to estab-

lish the mutual TLS channel, thus managing to enroll

SECRYPT 2021 - 18th International Conference on Security and Cryptography

230

using information belonging to the victim. In the ﬂow

connected with this scenario, MA can also bypass M8

by pretending to be sending a fresh selﬁe.

Instead, M7 – in combination with M5, M6 and

M8 – meets our expectations and makes

{

IDT , ES

}

{

IDT , SS

}

and

{

IDT , SE

}

ineffective. In fact, while

obtaining the eID card and its PIN was generally

enough, M7 also requires a user’s selﬁe.

It is important to notice that the selﬁe would not

be mandatory in this scenario: in fact, we could lever-

age the deﬁnition of derived credential (Grassi et al.,

2017b), which is a credential issued on the basis of an

already available credential that had previously been

issued after identity prooﬁng, in order not to dupli-

cate this process. In this case, the possession of an

eID card and the knowledge of the related PIN would

prove the control of an authenticator (i.e., the eID card

itself) that has been previously issued by a trusted en-

tity (a Government ofﬁce). Therefore, the Veriﬁca-

tion phase described as part (iii) in Section 2 could

be fulﬁlled by simply inserting the eID card’s PIN in-

stead of providing additional elements such as a selﬁe.

Nevertheless, the considerations above prove that the

request for a user’s selﬁe has indeed relevant conse-

quences and signiﬁcantly helps improve security.

6.3 Risk Analysis

The results of the risk analysis (in Table 5) highlight

that MA is connected with a Medium risk in both sce-

narios. By comparing the risk values to those of MA

with no mitigation implemented (Table 6), we can

notice the considerable effectiveness of the proposed

mitigations: beyond making most of the successful at-

tackers ineffective (see Section 6.2) they even reduce

the risk of MA, though without completely thwarting

it. For the sake of clarity, the risk values positively af-

fected by the implemented mitigations are highlighted

in bold in Table 5. Further details on the values as-

signed to the likelihood and impact factors in Tables 5

and 6 are detailed on the complementary website

As for M9, additional considerations are worthy:

during the risk analysis, no difference has been de-

tected between the effects of S1 and S2 on the overall

risk, since in both cases MA manages to interact with

the victim to obtain everything he needs. Speciﬁcally:

in case of S1, MA has to deceive the victim into pro-

viding the attacker with a selﬁe of her, together with

the code connected with the attacker’s malicious en-

rollment attempt written on a piece of paper; in case

of S2, MA has to deceive the victim into providing the

attacker with a video-selﬁe of her, in which she also

reads the words connected with the attacker’s mali-

https://st.fbk.eu/complementary/SECRYPT2021

cious enrollment attempt. Therefore, the choice above

can be made depending on other factors such as us-

ability, technical difﬁculty and/or server load. Nev-

ertheless, no matter which of the above techniques is

adopted, the overall risk is Medium in both scenarios.

In general, all the proposed mitigations signiﬁcantly

reﬂect on the attackers’ likelihood, while having little

effect on the impact. Since the likelihood is already

Low, affecting the impact (which would be a quite

complex operation) would be the only way to further

decrease the overall risk.

7 STATE-OF-THE-ART

SOLUTIONS

Many works dealing with security methodologies ap-

plied to authentication protocols can be found in the

academic literature, either from a formal (Jacomme

and Kremer, 2021; Fett et al., 2016; Feng et al., 2021)

or an implementation perspective (Sudhodanan et al.,

2016; Yang et al., 2016). However, the same cannot

be said for enrollment: to the best of our knowledge,

no previous security methodology for such protocols

has been developed so far. Therefore, our state-of-the-

art review has focused on governmental (Section 7.1)

and commercial (Section 7.2) enrollment solutions,

which we have taken into consideration during both

the design of the ﬂows and the identiﬁcation of the

mitigations.

7.1 Governmental Solution: SPID

SPID (Sistema Pubblico di Identità Digitale, Public

Digital Identity System) (AgID, 2020) is the Italian

digital identity to access Public Administration’s on-

line services in a frictionless and secure way. Due

to its sensitiveness, SPID can be released only by

accredited Identity Providers; each of them may set

up their own procedures to properly identify users

(e.g., physical identiﬁcation, remote identiﬁcation

through webcam or digital signature). Given the focus

of this work, to extract basic actions and mitigations

to consider we have further studied the procedures re-

lying on eDocuments as identiﬁcation means (e.g., the

Poste Italiane solution (Poste Italiane, 2020)).

7.2 Commercial Solutions

Many companies provide commercial solutions to

perform fully-remote identity veriﬁcation, such as

(Authenteq, 2020), (HooYu, 2020), (iDenfy, 2020a),

(Jumio, 2020b), (Onﬁdo, 2020), (Thales Group,

2020), (Veriff, 2020), and many other. Unfortunately,

A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-remote Solutions based on eDocuments

231

Table 5: Risk analysis of the enrollment procedure with all the mitigations implemented.

Scenario Attackers Likelihood Impact Risk

TD O AV UI SA Overall AS AD Overall

MRTD

{

}

3 1 7 1 2 2.80 Low 8 7 7.50 High Medium

IAS ECC

{

}

2 1 7 1 2 2.60 Low 8 5 6.50 High Medium

Table 6: Risk analysis of the enrollment procedure without mitigations, considering only MA.

Scenario Attackers Likelihood Impact Risk

TD O AV UI SA Overall AS AD Overall

MRTD

{

}

6 9 7 7 6 7.00 High 9 8 8.50 High Critical

IAS ECC

{

}

3 2 7 1 4 3.40 Medium 8 6 7.00 High High

companies rarely release details about their proce-

dures, considering the commercial nature of their

business. For these reasons, since we are not their

customers, we can only refer to the available docu-

mentation that can be found online. The basic pro-

cedure shared between the various solutions (with

slight changes) usually requires the applicant to take

a picture of her document (either electronic or non-

electronic) and then a selﬁe, so that the photo ex-

tracted from the former can be compared to the lat-

ter. After collecting the needed information, some

checks are performed server-side; among these, the

most common is the liveness check that we have im-

plemented in our procedure as well.

Besides a basic procedure, some solutions also al-

low full customisation according to the customers’

needs: in case of (Veriff, 2020), for instance, by

adding or removing steps that the applicant must

perform (e.g., video-selﬁe or selﬁe with the eDocu-

ment) and by enabling or disabling checks to perform

(e.g., device veriﬁcation, biometric comparison, live-

ness check and automated data extraction).

7.2.1 FinTech Solutions

To comply with Know Your Customer (KYC) guide-

lines, online banks have to identify prospective cus-

tomers with a high degree of assurance before let

them open a bank account. According to (Built for

Mars, 2020), some institutes still perform veriﬁca-

tions manually, hence increasing the customers’ wait-

ing before their account is activated. Anyway, the

majority of the analysed banks leverage enrollment

procedures that are mostly performed in an automatic

way; manual intervention can still be needed, but only

in some cases (exceptions or over-threshold risks). To

this end, some institutes implement commercial solu-

tions (e.g., (Monzo, 2020) relies on Jumio and (Rev-

olut, 2020) on Onﬁdo), while some other implement

custom enrollment procedures.

8 CONCLUSIONS

This paper has focused on enrollment procedures, that

are gaining more and more popularity since they al-

low a solid identiﬁcation of the applicants. Given

the sensitive contexts in which these operations are

placed, they must provide a high level of assurance

on the applicants’ identities. Therefore, we have pre-

sented a framework for security and risk analysis of

any enrollment procedure; this framework is com-

posed of: (i) a speciﬁcation language to provide a

clear and graphical description of enrollment proto-

cols; (ii) a security analysis methodology to obtain a

list of the attackers that are able to compromise the

protocols; (iii) a risk analysis methodology to sort the

successful attackers according to their severity, thus

enabling a prioritization of them. The outputs of the

framework can be used to adjust the security level

of enrollment procedures, also allowing to perform

what-if analyses by changing the set of mitigations

to consider and verifying the effects on security.

In the context of a collaboration with the Italian

FinTech startup CherryChain, we have applied the

proposed framework to fully-remote solutions rely-

ing on eDocuments as identity evidence. The collabo-

ration with CherryChain was extremely important to

both parties: on the one hand, it contextualized our

work in a practical use case; on the other hand, our

framework allowed CherryChain to verify the secu-

rity of the protocols they were designing, also iden-

tifying the mitigations to implement after discussing

their beneﬁts in terms of security and feasibility.

Starting from this work, we plan to enrich the

speciﬁcation language that has been used in this pa-

per to support a wider range of enrollment proce-

dures, even based on different requirements. More-

over, to simplify and automatize the analysis process,

we are currently formalising the proposed framework

through formal deﬁnitions and pseudocodes that can

be easily implemented within an automatic tool. Fi-

SECRYPT 2021 - 18th International Conference on Security and Cryptography

232

nally, it would be interesting to extend our work by

taking inspiration from some of the considerations

presented in a report (ENISA, 2021) released by the

European Union Agency for Cybersecurity (ENISA)

after this work was already completed.

ACKNOWLEDGEMENTS

The research has been partly supported by Cher-

ryChain S.r.l. in the context of a research and inno-

vation project funded by the Autonomous Province of

Trento, and by IPZS (Poligraﬁco e Zecca dello Stato

Italiano, the Italian Government Printing Ofﬁce and

Mint) within the joint laboratory DigiMat Lab.

REFERENCES

AgID (2020). SPID. https://www.spid.gov.it/.

Authenteq (2020). Identity Veriﬁcation Without Compro-

mise. https://authenteq.com/.

Built for Mars (2020). Opening an account. https://

builtformars.co.uk/banks/opening/.

Campbell, B., Bradley, J., Sakimura, N., and Lodderstedt, T.

(2020). RFC 8705. https://tools.ietf.org/html/rfc8705.

Cassidy, N. (2018). Onﬁdo launches the market’s

most robust video liveness detection. https:

//onﬁdo.com/resources/blog/news-onﬁdo-launches-

the-market-s-most-robust-liveness-detection.

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,

R., and Polk, W. (2008). RFC 5280. https://tools.ietf.

org/html/rfc5280.html.

ENISA (2021). Remote ID Prooﬁng. https:

//www.enisa.europa.eu/publications/enisa-report-

remote-id-prooﬁng.

Feng, H., Li, H., Pan, X., and Zhao, Z. (2021). A For-

mal Analysis of the FIDO UAF Protocol. In Network

and Distributed System Security Symposium, NDSS

2021. https://www.ndss-symposium.org/ndss-paper/

a-formal-analysis-of-the-ﬁdo-uaf-protocol/.

Fett, D., Küsters, R., and Schmitz, G. (2016). A Compre-

hensive Formal Security Analysis of OAuth 2.0. In

Proceedings of the 2016 ACM SIGSAC Conference

on Computer and Communications Security, CCS ’16.

https://doi.org/10.1145/2976749.2978385.

GIXEL (2009). European Card for e-Services and National

e-ID Applications: Identiﬁcation Authentication Sig-

nature European Citizen Card (IAS ECC).

Grassi, P. A. and Fenton, J. L. (2017). Digital Identity

Guidelines: Enrollment and Identity Prooﬁng. SP

800-63A. https://doi.org/10.6028/NIST.SP.800-63a.

Grassi, P. A., Fenton, J. L., Newton, E. M., Perlner, R. A.,

Regenscheid, A. R., Burr, W. E., and Richer, J. P.

(2017a). Digital Identity Guidelines: Authentication

and Lifecycle Management. NIST Special Publication

800-63B. https://doi.org/10.6028/NIST.SP.800-63b.

Grassi, P. A., Garcia, M. E., and Fenton, J. L. (2017b).

Digital Identity Guidelines. SP 800-63-3. https:

//doi.org/10.6028/NIST.SP.800-63-3.

HooYu (2020). Identify. https://www.hooyu.com/h/hooyu-

identify/.

ICAO (2015). MRTD. Doc 9303. https://www.icao.int/

publications/pages/publication.aspx?docnum=9303.

iDenfy (2020a). Identity Veriﬁcation Service. https://www.

idenfy.com/.

iDenfy (2020b). Liveness Detection to prevent Spooﬁng At-

tack. https://www.idenfy.com/blog/spooﬁng-attack-

prevention/.

Jacomme, C. and Kremer, S. (2021). An Extensive For-

mal Analysis of Multi-Factor Authentication Proto-

cols. ACM Trans. Priv. Secur., 24(2). https://doi.org/

10.1145/3440712.

Jumio (2020a). Certiﬁed Liveness Detection. https://www.

jumio.com/technology/live-detection/.

Jumio (2020b). Jumio. https://www.jumio.com/.

Monzo (2020). Monzo. https://monzo.com/.

NIST (2017). Digital Identity Guidelines document suite.

SP 800-63. https://pages.nist.gov/800-63-3/.

Onﬁdo (2020). User onboarding. https://onﬁdo.com/use-

cases/user-onboarding/.

OWASP (2018). OWASP Risk Rating Methodol-

ogy. https://owasp.org/www-community/OWASP_

Risk_Rating_Methodology.

OWASP (2020). Mobile Application Secu-

rity Veriﬁcation Standard. Version 1.2.

https://github.com/OWASP/owasp-masvs/releases/

download/v1.2/OWASP_MASVS-v1.2-en.pdf.

Pernpruner, M., Carbone, R., Ranise, S., and Sciarretta, G.

(2020). The Good, the Bad and the (Not So) Ugly of

Out-of-Band Authentication with eID Cards and Push

Notiﬁcations: Design, Formal and Risk Analysis. In

Proceedings of the Tenth ACM Conference on Data

and Application Security and Privacy, CODASPY

’20. https://doi.org/10.1145/3374664.3375727.

Poste Italiane (2020). PosteID abilitato a SPID. https://

posteid.poste.it/.

Revolut (2020). Get more from your money. https://www.

revolut.com/.

Sudhodanan, A., Armando, A., Carbone, R., and Com-

pagna, L. (2016). Attack Patterns for Black-Box

Security Testing of Multi-Party Web Applications. In

Network and Distributed System Security Symposium,

NDSS 2016. https://www.ndss-symposium.org/wp-

content/uploads/2017/09/attack-patterns-black-box-

security-testing-multi-party-web-applications.pdf.

Thales Group (2020). ID Veriﬁcation Suite. https:

//www.thalesgroup.com/en/markets/digital-identity-

and-security/government/identity-veriﬁcation.

Veriff (2020). Veriff. https://www.veriff.com/.

Yang, R., Lau, W. C., and Liu, T. (2016). Sign-

ing Into One Billion Mobile App Accounts

Effortlessly with OAuth2.0. In Black Hat Eu-

rope 2016. https://www.blackhat.com/docs/eu-

16/materials/eu-16-Yang-Signing-Into-Billion-

Mobile-Apps-Effortlessly-With-OAuth20-wp.pdf.

A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-remote Solutions based on eDocuments

233