Okay. Okay. So we are very glad to be here to present our work on threat modeling for the Audi wallet ecosystem. So let's start, start with a brief introduction ourselves. We are researchers of the Center for Cybersecurity of Bruno Ke FBK in TR to Italy. Our center has expertise in several domains like applied cryptography, cloud and iot security threat and anomaly detection. And Amir and I, we mainly focus on digital identity. In this context, we were and are involved in several research and innovation projects.
For example, we were involved in the IIDA notification of one of the Italian national lady scheme, and now we are involved in the large scale pilot potential with a focus on the security of the European Digital entity Wallet. So before going the detail of our contributions, I want to give you some context and motivation of our work. So with introduction of the European Digital Entry wallet, we are facing a shift in the authentication paring to understand, let's consider typical interaction in ADAS one.
So we have a user like Alice who wants to access a service provided by our line party to know who, who the user is. The line party is going to request this information to an identity provider that then will authenticate the user and give this information back to their line party. With this information, then the line party is able to take a decision whether to allow the s to access the service or not. We are with the ADAS two.
Instead, we have two different phases. In a first phase call issuance phase, the order through the wallet is going to conduct an anti issue to obtain a credential. And then in a second phase airline party is going to request some data to the user. And the user has the ability to select the most suitable credential to them present to the relying party. And in addition, in some cases, the user has also the possibility to select a subset of claims contained in a credential.
So together with this property, that is called selective disclosure.
Another important aspect is that the issuer and the identity provider are not involved anymore in this second phase. So they are not able anymore to track the activity of the user in the different line parties.
So two, to, to allow and to permit his new paradigm. The European Commission introduces new roles in the digital identity ecosystem. The central one is the Audi wallet assistance that is provided by the Audi wallet provider. And then we have a list of attestation providers that are going to issue the credential that then are store manager in the wallet. Together with the new roles, we have also the need to identify how the different entities interact to each other to exchange the data in these different phases.
And here you can find a subset of standards that are identified in the architectural reference framework.
What I want to highlight here is that all these standards are going to introduce new assets that must be taken into account in the security assessment. So given all these changes, what we are asking ourself is which are the differences in term of security compared to traditional identity management ecosystem? So can we reuse existing security assessment or we need something more? So to answer to these questions, what we are currently doing is a, a threat model for the Avol ecosystem.
Our final goal is to provide a comprehensive threat model that together with the threat is going to specify the, the vulnerability that that threat is exploiting. Example of attack techniques that an attack can use to carry out a threat, the corresponding risk, and also a set of security controls that are able to mitigate that threat.
So this is our final goal and later on in the second part of the presentation, on Mirror is going to provide some examples. What I want to highlight is that is a work in progress. So so far we have focused on four entities.
Issuer wallet provide the wallet stands and verifier. And we have identified around 50 threats and security controls and around 30 vulnerabilities and requirements. Even if it's still a work in progress, we decided to publish our work. You can find it following the link or scanning the QR code. And the idea is to receive some feedback on both the methodologies that we are following and the content itself. This work has, has been done in collaboration with the Italian Printing office and Mint and with our researchers Daniel PO of the University of Mhe. So this is the introductory part.
I, I'll leave the floor to Amir for a deep dive.
Thank you Joda for the, for the introduction. So as Joda mentioned, so we started with identifying a set of requirements, security, privacy and technical requirements. And in the next couple of slides I'm going to provide you with some examples of this identified requirements. What I want to highlight it is that at the time that we did this analysis, we do the analysis based on the RFA version 1.3 and we are going to extend our set of identify requirements with the new a f.
So considering the security requirements, let's take a look to what we call issuer identification. And what we mean is that the credential must contain information that is required to identify the insurer in order to ensure that the insurers can be recognized and verified by the entities that are involved in the ecosystem. And we have the phase, which means in the, in this requirement, it's related to the which, which phase of the the UD vault ecosystem.
It's related to the issuance phase or it's related to the presentation.
So for the privacy requirements, let's consider the selective disclosure mechanism. I think everyone is familiar with that. So selective disclosure as as, as a be considered as a requirement that is needed to be satisfied both by the credential format and the wallet itself in order to support the selective disclosure mechanism. And the idea of with the selective disclosure mechanism is that to allow the holder to provide only the necessary only subset of claims that are necessary to, to access a service and avoid unnecessary exposure of personal information.
And it is relevant to both issuance and presentation phase. And to give you an example of the technical requirement that is coming from the rf, let's consider the usage of the national EID infrastructure, which is needed in order to perform the holder authentication process during the issuance phase. So now let's move on to what we have done on the threat model. So as Jada mentioned, it is a preliminary analysis and we try to identify a set of threat.
And for each threat or idea was that to define what is the threat category, what are the potential attack techniques, the relevant vulnerabilities that could be exploited, what that, why that attack technique and instead of con countermeasures, security and privacy measures to avoid this potential threat.
So for the third category, we are following the standards. So for the security one, we are following the stride, which is the framework provided by Microsoft.
And it provides categories such as spoofing, taming reputation, information disclosure, the need of service and elevation of innovation of privilege. So I think everyone knows what the need of service means and it's a threat action that attempting to deny access to the valid users such as by making the server temporarily unavailable in the context of wallet, it can be applicable for all the entities. So for example, you can send lots of requests to an issuer in order to avoid its services. And for the privacy we are using the Lindon.
And Lindon provides categories, third categories such as linking, identifying non reputation and so on. And another thing that I want to highlight before going to the example is related to the assets that we identify and hematology that we, and as I, as it is mentioned is this work in progress.
So what we tried is that not to take only consider the entity as a soul but consider its interfaces as well in order to identify all the services and interactions that it can have during the, the volume during the issuance are presented during the issuance phase in this case as it is issuer.
So just as you can see on the left hand side table, so we try to provide some coding that you will see this code in the analysis table that we have provided. And for example, as an issuer data, we consider the issue private keys, the confi files. And as we cons, we are focused on the open ID for VCs tech. So we consider related data to the protocol like such as the code and access to and so on. So now let's consider some examples that to give you some idea that what you will see in the results table that we are sharing.
So let's consider entity impersonation.
Entity impersonation is a trait that involves a malicious actor playing the role of a legitimate entity. And the third category that we consider for this thread is the spoofing information disclosure and identifying. And the attacker can use a simple attack technique like creating a lip, a replica of legitimate issuer verify or the wallet and then using social engineer technique to save the user to interact with the, with the fake entertaining state of the legit one.
So the vulnerabilities that it could exploit would be simply human weakness or having lack of a secure entity registration process. And the control that you can have in order to avoid this threat could be either the entity training or having a secure entity notification during the registration phase for the for onboarding, the issuer verifier involved.
So the second threat that I would like to speak about it is the use of a stolen credential that an attacker can steal the credential somehow and then tries to inject it in this session with the verifier in order to legitimately access some service of the verifier.
And the vulnerabilities that it can exploit here would be lack of other binding or lack of having a proper mechanism to avoid the injection attacks. And what would be the control here would be simply the use of FMR credentials or having the holder binding or providing S for the holders to revoke the credentials.
And the last one, so the previous two was like general that could be applicable for all the protocols. And this one is very specific to the open I four VCI because we try to to separate the threat analysis that we have. So one part is like all the general threats that could be applicable to all the protocols. And then we have a specific part that is related to the open I four VCS tech.
So considering that that's considered access token tiff that an attacker can use, can for example use an attack technique like man the middle attack to intercept the messages between the issuer and wallet in order to install sensitive data such as tokens and then it can exchange it to obtain the credentials. And this can be happen by exploiting lack of secure communication or the use of barrier tokens. So in order to avoid this, you should have the secure communication implemented using TLS or you have to use the standard constraint access token.
So just to say that what are the ongoing work and what are the future steps? So we are trying to refine the protocol related threats and we started to define a set of specific threats regarding to the secure storage considering the different options like if it is on device like regarding T securing clay or if it is a cloud solution like considering the HSM and try to define the specific threats that could be applicable for each of these secure storage components. And we want to complement our third model by performing a risk assessment.
And as a future worker we are trying to add some new roles that are not, that we are not considered so far in our third model. So like considering the authentic source, the qualified service provider and so on. And then we are want to profile, refine some threats related to a trust model. And after that we would like to take a look to the wallet implementations to see if they have some, we have like two, two idea regarding data first check if they are compliance with the regulation and secondly if the trace that we have identified has been addressed by them or not.
And to conclude, so we start from a concrete problem that is I think is obvious to everyone that's ensuring the security of wallet and warm is crucial for, for citizens data. And the motivation beyond the work was that the current draft and recommendation for example are the architecture reference framework. It doesn't detail implementation guidelines for securing the wallet.
So as a considering solution, we start with the threat model and we think that the result of the threat model can be served as reference tool for stakeholders because we have like a kind of classification based on different stakeholders. So if I'm an issuer, I can just take a look what are the threats that are applicable to me and to be sure that I'm not exposed to them. And I think that's all and we are looking forward for feedback. Yeah. And collaborations and the nce.
Thank you guys.
We, we could take a couple of questions if anybody Yes please. For for both of you obviously. Yeah. Yeah.
Hey, so on the slide where we showed the IDAs two authentication model where without an IDP interaction, you showed that the information went from the wallet directly to the relying party. Is that data copied verbatim from the wallet or is that derived from the data in the wallet?
So
Do you want to reckon
You can
Start?
So, so it depends that if when the presentation request is coming from theier to the wallet, so if I have a credential that could satisfy the request of the, the verifier, so it goes directly from the verify, sorry, from the wallet, one of the credential that is already asserting the wallet and going to the verifier. If I don't have a credential that could satisfy that, then you can go to the issuer, you obtain it and then you can share it with the,
Okay. Thank you. You're
Welcome. Thank you. One more question just in the second row. Yes please.
Just a quick question is if you compare it to E one, does this have more already more security threats that you have found or or?
So the, the general ones, so it's like a mixture that could be apply for the, any identity management solution. But then we have some specific threats that are related to either some new terms like wallet instance, attest station, that that could be like related to the fact that if the wallet is genius or not and how you are obtaining.
And then another thing that is like make some difference is like you have some new entity like wallet provider, then we are considering some threats between the interaction between wallet and wallet provided that is specific to a EI does two, but yeah, we have a, a set of threats that could be applicable to all the audience management solutions. And then there are a subset that are specific to the EI does two.
Okay, thanks. And was the question here right at the front pieces?
He
Yeah, thanks I, one question, you showed an example where you identified the threat based on lack of the usage of TLS in the flow. Okay, so my, my question is, because as far as I know the ultimate for VCI specification prescribes the usage of TLS almost everywhere.
Yes. But if somebody is using TLS 1.2 for example, then they are, I mean okay, having something in this specification is one thing and if you're implementing right or correctly is another thing. Okay.
So it would be still some possibility if you are using the old version of TLS for example, that is still
Okay be because my great question would be, would've been how many threats would you have identified, which are not based on the leg of usage of TLS, which is it like half of it or
I have to take a look. Okay.
Yeah, nevermind.
Yeah, because what's, you can, if you already take, take a screenshot of the, so I mean US scan the, the table scan, the QR code for the table. So I think you can simply filter it based on the attack techniques that are based on man the needle attack. Then you can see all the ones that are, that could be exploited by, by lack of the TLS.
Thanks a lot. You're welcome.
