This page contains complementary material related to the following paper:

• Title: A Framework for Security and Risk Analysis of Enrollment Procedures: Application to Fully-Remote Solutions Based on eDocuments
• Authors: Marco Pernpruner, Giada Sciarretta, Silvio Ranise
• DOI: 10.5220/0010554502220233

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 specific 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 specification 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.

Complementary Material

In this page, we provide further information about the values that have been considered for a Malicious Application (MA) during the risk analysis (Tables 5 and 6 of the paper).

Without Mitigations

The following values are assigned to MA in case no mitigation is adopted (Table 6):

Scenario	Attacker	Likelihood							Impact				Risk
		TD	O	AV	UI	SA	Overall		AS	AD	Overall
MRTD	{MA}	6	9	7	7	6	7.00	High	9	8	8.50	High	Critical
IAS ECC	{MA}	3	2	7	1	4	3.40	Medium	8	6	7.00	High	High

With the following motivations:

Scenario	Factor			Value	Motivation
MRTD	Likelihood	Technical Difficulty	TD	6	The attacker only needs some technical skills (such as using a proxy) to intercept the communications between the official application and the server, then replicating such communications with tampered data.
		Opportunity	O	9	MA can successfully compromise the protocol by sending information belonging to other people or even completely fake, due to the lack of proper checks performed server-side. Therefore, the Opportunity is maximum since there are no limitations hindering the attacker.
		Attack Vector	AV	7	The attack can be performed remotely, by distributing the malicious application through the network.
		User Interaction needed	UI	7	The user interaction is not required, since the attacker could send any personal information without any need for interacting with the user.
		Spread of Attack	SA	6	Intercepting the original behaviour of official applications and trying to replicate or alter them may be pretty common.
	Impact	Attack Scale	AS	9	The number of people that could potentially be affected by this attack is maximum, i.e., everyone (even fictional people).
		Attack Detection	AD	8	This attack is significantly difficult to detect, given the lack of server-side checks on the personal information submitted.
IAS ECC	Likelihood	Technical Difficulty	TD	3	To develop a malicious application, the attacker is required to have advanced programming skills.
		Opportunity	O	2	To reach users, malicious applications can either be published on official marketplaces or distributed via APKs sent through links or attachments. In both cases, the opportunity of success is extremely low: in the former case, applications need to bypass the security checks performed by the marketplaces; in the latter case, users need to explicitly enable the “Install from Unknown Sources” setting on their device before they can install such unofficial applications.
		Attack Vector	AV	7	Same as the MRTD scenario.
		User Interaction needed	UI	1	The user interaction is required, since the user needs to provide the PIN and place the eID card for NFC reading. Moreover, the interaction is required in a precise moment as the attacker needs the user’s eID card to sign the challenge before it expires.
		Spread of Attack	SA	4	According to official statistics [1], the number of mobile users attacked in 2020 has significantly decreased (a quarter lower than in 2019), reaching 0.69 million in December. Therefore, we assign a medium value to this factor.
	Impact	Attack Scale	AS	8	The number of people that could potentially be affected by this attack is considerably high, i.e., whoever installs the malicious application and owns an eDocument.
		Attack Detection	AD	6	This attack is difficult to detect, but less than in the MRTD scenario. In fact, while in the MRTD scenario even fictional information could be used, in this scenario the attacker strictly needs to use real people’s information, thus making the detection slightly more likely (due to the misuse of personal data).

With Mitigations

The following values are assigned to MA in case all the proposed mitigations are adopted (Table 5):

Scenario	Attacker	Likelihood							Impact				Risk
		TD	O	AV	UI	SA	Overall		AS	AD	Overall
MRTD	{MA}	3	1	7	1	2	2.80	Low	8	7	7.50	High	Medium
IAS ECC	{MA}	2	1	7	1	2	2.60	Low	8	5	6.50	High	Medium

Specifically, mitigations affect the following factors (whose values are highlighted in bold in the table):

• MRTD Scenario
  • Likelihood
    • Technical Difficulty (TD): 6 → 3 | In this case, only intercepting and replicating the communications between the official application and the server is no longer enough since fictional data cannot be used due to M4. Therefore, the attacker needs to develop a malicious application as in the IAS ECC scenario.
    • Opportunity (O): 9 → 1 | As the attacker cannot rely on fictional personal information (due to M4), he needs to make the user install the malicious application to interact with her eID card. The considerations about installing malicious applications are the same as the IAS ECC without mitigations, thus leading to decrease the Opportunity value to 2. Moreover, this value is further reduced to 1 since M9 strictly restricts the attacker’s success: in fact, given the fresh data inserted in the selfie, the attacker must complete the attack within the lifetime of the session.
    • User Interaction needed (UI): 7 → 1 | As the attacker cannot rely on fictional personal information (due to M4), he needs a user interaction in a precise moment, as in the IAS ECC scenario.
    • Spread of Attack (SA): 6 → 2 | Since the attacker can no longer use fictional information (due to M4) and has to deal with advanced security countermeasures such as obfuscation of the official application (M2) and fresh information in the selfie (M9), the spread of the attack considerably decreases and has to be aligned with the value assigned to SA in the IAS ECC scenario with mitigations.
  • Impact
    • Attack Scale (AS): 9 → 8 | The implementation of server-side checks on the correctness of the SOD (M4) prevents the attacker from being able to send fictional information. Therefore, as in the IAS ECC scenario, the number of people that could potentially be affected by this attack is high (i.e., whoever installs the malicious application and owns an eDocument) but not maximum (fictional people’s information are no longer allowed).
    • Attack Detection (AD): 8 → 7 | In case the malicious application manages to gain root access on the user’s smartphone, M1 allows a user opening the official application to be informed about the rooting of her mobile device and realise that an attack could have happened.
• IAS ECC Scenario
  • Likelihood
    • Technical Difficulty (TD): 3 → 2 | Mitigations M2 and M3 make the attack more difficult to be carried out from a technical perspective. In fact, the malicious application should be able to replicate the key generation procedure (M3) without really understanding the original code, which is obfuscated due to M2.
    • Opportunity (O): 2 → 1 | M9 strictly restricts the attacker’s success: in fact, given the fresh data inserted in the selfie, the attacker must complete the attack within the lifetime of the session.
    • Spread of Attack (SA): 4 → 2 | Since the attacker has to deal with advanced security countermeasures such as obfuscation of the official application (M2), token binding (M3) and fresh information in the selfie (M9), the spread of the attack considerably decreases.
  • Impact
    • Attack Detection (AD): 6 → 5 | In case the malicious application manages to gain root access on the user’s smartphone, M1 allows a user opening the official application to be informed about the rooting of her mobile device and realise that an attack could have happened.

References

[1] Kaspersky, “Mobile malware evolution 2020”