title | subtitle | paper | people | |||
---|---|---|---|---|---|---|
A Framework for Security and Risk Analysis of Enrollment Procedures |
Application to Fully-Remote Solutions Based on eDocuments |
SECRYPT2021 |
|
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).
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:
<tr>
<td rowspan="7" class="border-thick-right"><span class="rotate">IAS ECC</span></td>
<td rowspan="5"><span class="rotate">Likelihood</span></td>
<td>Technical Difficulty</td>
<td>TD</td>
<td class="border-thick-left border-thick-right">3</td>
<td class="text-left">To develop a malicious application, the attacker is required to have advanced programming skills.</td>
</tr>
<tr>
<td>Opportunity</td>
<td>O</td>
<td class="border-thick-left border-thick-right">2</td>
<td class="text-left">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.</td>
</tr>
<tr>
<td>Attack Vector</td>
<td>AV</td>
<td class="border-thick-left border-thick-right">7</td>
<td class="text-left"><i>Same as the MRTD scenario.</i></td>
</tr>
<tr>
<td>User Interaction needed</td>
<td>UI</td>
<td class="border-thick-left border-thick-right">1</td>
<td class="text-left">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.</td>
</tr>
<tr>
<td>Spread of Attack</td>
<td>SA</td>
<td class="border-thick-left border-thick-right">4</td>
<td class="text-left">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.</td>
</tr>
<tr>
<td rowspan="2"><span class="rotate">Impact</span></td>
<td>Attack Scale</td>
<td>AS</td>
<td class="border-thick-left border-thick-right">8</td>
<td class="text-left">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.</td>
</tr>
<tr>
<td>Attack Detection</td>
<td>AD</td>
<td class="border-thick-left border-thick-right">6</td>
<td class="text-left">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).</td>
</tr>
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. |
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.
-
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.
<li> Impact <ul> <li><b>Attack Detection (AD): 6 → 5</b> | 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.</li> </ul> </li> </ul>
[1] Kaspersky, "Mobile malware evolution 2020"
<style> .rotate { -moz-transform: rotate(-90.0deg); -o-transform: rotate(-90.0deg); -webkit-transform: rotate(-90.0deg); filter: progid: DXImageTransform.Microsoft.BasicImage(rotation=0.083); -ms-filter: "progid:DXImageTransform.Microsoft.BasicImage(rotation=0.083)"; transform: rotate(-90.0deg); } table { margin-bottom: 1em; border: 2px solid #dbdbdb !important; } table tr { border: 1px solid #dbdbdb !important; } table th { border-width: 2px 1px !important; } table td { border-width: 1px !important; } table th, table td { text-align: center !important; vertical-align: middle !important; } table th.text-left, table td.text-left { text-align: left !important; } table .border-thick-left { border-left-width: 2px !important; } table .border-thick-right { border-right-width: 2px !important; } </style> -
Likelihood
<li> Impact <ul> <li><b>Attack Scale (AS): 9 → 8</b> | 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).</li> <li><b>Attack Detection (AD): 8 → 7</b> | 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.</li> </ul> </li> </ul>
-
Likelihood