Meeting minutes
Simone: @@@
Amir: together with Zahra, we're going to talk about threats to DC API
… some background about ourself
… working for FBK, a research center in italy for cyber security with different focuses, and we're working on identity management, on different programs also with the italian government related to digital credentials issued by government, in particular on the wallet and italian technical specification
… the DC API flow, and a user would like to access a credential on a website/verifier. the verifier shows a prompt, then the browser, then the wallet, the user can select the credentials (it is credential-centered), then wallet and browser prepare and send the presentation, for the verification
… in our analysis we identified some key questions e.g., Malicious Wallet and Trust
… first question is: which are the trust relationship between Issuer/Wallet... this should established at which level of the architecture?
Lee: it depends on the meaning on wallet trust
Amir: how the issuer can be sure they are issuing the credentials to a specific wallet
Lee: it is complex
… there are multiple ways
… OID4VCI has some ways, the @@ mode the user can start from DMV and they want to issue a credential to a user, e.g., driving licence, the credentials has a token to be exchanged, and there is an interactive protocol to define. Then we have also wallet attestation, to define trusted wallets
… there is a problem with this mechanism. first mode is when the wallet don't send attestation, but if there is a non-authenticated way, this can be an issue
… in this flow there is no session
… but there is always a part of attestation also on presentation
Amir: essentialy it is possible to use wallet attestation to authenticate the wallet. one question we have is that at least in EU context, you have the information of the wallet and a way to identify. in this case to we need to identify the origin?
Lee: in general, you need it
… scenario is: first you have to install a malicious wallet, that has no way to be attested
Tim: this is similar to passkey
Lee: in this case the malicious wallet is a proxy
… a solution is passing a random challenge, secret from the wallet, and it is used by the OS
… the wallet passes to the attestation server, the origin is the package name
… matching it
<Zakim> smcgruer_[EST], you wanted to clarify that this means that no, trust for issuance is not part of the DC API itself, its part of whatever underlying protocol is being talked over the DC API?
SMC: trust is at the DC API or at the protocol level?
Lee: DC API in this case
Manu: one of the concern is that to use the wallet attestation to limit the wallets to be used in the particular user
… what it the difference? e.g., you don't have browser attestation
akc manu
… what is the difference between the browser and the wallet?
Lee: attestation is optional
… it is an additional feature
… like a passkey manager
Amir: I can add also that in the EU context, the wallet needs to trust the issuer
… and it is about trustworthiness
Lee: the scenario is having just the wallet
… compromised
Mohaned: this can be optional, and custom scheme it is worst
Lee: Google wallet is also used by gov, like Apple one. In this case standards can help solving it
Tim: any wallet can have a direct integration
<Zakim> denkeni, you wanted to comment on rate limit of attestation server
denkeni: we're thinking on a while, with a collaboration of platforms and attestation servers
… and have an integrity check with Google, with specific keys
… this can also a way to interact with different issuers and verifiers, an attestation server can work of this effort
Lee: this is something only on the issuer side
… but we don't present an integrity check
… the way in which is today is like issuance a digital credentials, an interation of it
Tim: but you cannot contain a statement by yourself
Lee: this is a pattern similar to some use cases of WebAuthn
denkeni: it is also something that is done at App Store/Play Store level
Lee: there is no integration for this aspect
denkeni: on EU level is something made on the wallet server
Lee: it is using OS integrity check, then attesting itself
1?
… the flipside is that the attestation must the done for each issuer, and we deprecated SafetyNet
… this is a reasonable compromise
Tim: a lightway way to do that
… the challenge it is to make it fomr wallet
Nina: the website is interested that you are verified
manu: it is fundamentally a bad idea
… but I understand is a gov requirement
<denkeni> personal opinions, +1 to manu
manu: i think W3C and that if we think it is bad idea, W3C can make a statement about that, as we're not using attestation
<denkeni> that really could break wallet interoperability in the future
manu: if a gov asks for a backdoor, we shound not do
Lee: this is done now at protocol level, not on the API, but this is in the EU law
… this is a similar discussion to passkey providers that we decided to not attest, made a tradeoff
… some actors are not using passkey because of that
Erick: this can hinder a new player to come in
<Zakim> manu_, you wanted to ask why no pushback if we don't do this for passkeys/browsers?
Lee: we worked on wallet certification with FIDO
… FIDO is working on the certification scheme, and anyone can be certified
Tim: this is a basic layer and anyone can be certified
… DC API is just using the protocol
Nina: for gov the wallet must respect this
<Zakim> JoeAndrieu, you wanted to ask if the attestation from a legal person
Joe: it is a bad idea but which is the legal entity involved?
… so maybe this is another level of indirection
Lee: this can be tracked down for attestation, and an attacker with an official legal entity
Methodology
Zahra: TM is the process of defining system, then threats, and how to response to them
… we used the 4 questions shostack framework
… we also used the ontology from NIST SP 800-115
[slides: https://
… for the threats we used STRIDE
… in our model, we have entitites (e.g., UA, CM, Wallet, RP, RS), data flows (same device, cross-device)
… which uses FIDO CTAP 2.2
… then we have the swimlanes
… for same and cross device
… highlighting the boundaries
… of course we have also some assumptions
… UA mediation, CM mediation, the interaction channel, and the transport security
… what can be considered in the scope?
Lee: OS and CTAP is OOS, this is good
Simone: we can also identity the bad effect if assumptions is violated
… CTAP can be a separate excerise
… we have also a formal verification of DC API And CTAP
… you can reference it
Joe: one of the way we're working in the Threat Modeling Guide, is having different "dependency threats", e.g., we have some dependancy on them
… this is the difference on something we know but we have OOS
Lee: we don't check how TLS works
<Zakim> JoeAndrieu, you wanted to name the threat
Zahra: we have also primary assets
… then we worked mainly on the presentation flow
… using different zones to locate the threats
… in the cross-device flow, we have different zones
… then we mapped the assets on the zones
… then we used threat categories, attack scenarios, affecrted assets and understanding mitigations
… we identified a side channel attack
Lee: DC API never knows about the credentials
Mohamed: but you can have faster responses
… probabilistic attacks
Elan: we should measure it
Lee: @@
… you can send different queries distinguishing
Stephen: this is an attack
… we've seen it
… but probably we can also levarage on something done for WebAuthn
… the idea was to design to avoid this threat
Zahra: API Flooding
Lee: we can add rate limiting like with WebAuthn
… and transient activation
Zahra: DC API moves threats from the UI boundaries, solving some threats but creating new one