Feedback on cryptographic methods for user authentication

Thank you for sharing this documentation. I’ve added it to the overview in Exploration of wallet secure cryptographic applications, since I believe sharing design solutions in a public dialogue is the best way to develop trustworthy WSCA requirements and solutions, which are essential for a secure ecosystem.

I’ve started reviewing in particular the Cryptography page regarding the eID means to meet LoA High requirements from (EU) 2015/1502. I see several positive aspects in general, such as the use of a rWSCD and the server-side rate-limiting. My more critical feedback upon first reading follows:

#1. Consider including your threat model and assumptions. For example, can the User Device be any smartphone, or do you restrict usage to some models? Can the User Device run malware, or do you require the user to have particular system integrity protection in place?

As context to my next feedback, I’m assuming that:

• the attacker can access or modify the code and storage at rest of the app;
• the attacker can extract the runtime app state from RAM, for example by triggering a dump;
• the attacker can steal the user device;
• the user can reliably protect the local secure area-stored assets against abuse;
• the provider can be compromised, such that it becomes an attacker;
• the provider can modify the rWSCD server software;
• the provider cannot extract secrets from the rWSCD HSM;
• it is highly unlikely that an attacker compromises the provider and steals user devices.

Also, I assume that the rWSCD host is a regular server, securely deployed but not AVA_VAN.5 certified.

#2. Since wi_rwscd_pin_salt is stored in the app context, an attacker can extract it to prepare PIN verification data without access to the user device. Traditionally, secure elements always process the PIN in the same device as the possession factor. You could easily achieve this property by deriving the PIN-based key using an asset protected in the local secure area. For example, using ECDH (iOS) or HKDF with a hardware-backed HMAC key (Android). Did you prefer a purely software-based approach for specific reasons?

#3. Since wi_rwscd_pin_pubk is stored in the rWSCD server context, outside of the HSM, an attacker can extract it in order to verify PIN attempts circumventing the rate-limiting protection. Alternatively, if the attacker obtains the proof-of-possession of wi_rwscd_pin_prvk, they can abuse it to reconstruct wi_rwscd_pin_pubk using ECDSA public key recovery. This potentially renders the user unable to reliably protect their knowledge factor against abuse by others. How do you assess this risk?

#4. Since wi_rwscd_pin_pubk cannot be exposed to third parties, it is impossible for others to verify that the user PIN was entered. At least in some interpretations regarding LoA High, such ability seems to be a requirement. This can be fulfilled for example by AVA_VAN.5 certification of the PIN handling functionality they can rely on, or by having some sort of verifiable protocol. Without such verifiability, a compromised provider could change the rWSCD and circumvent the knowledge factor check, without an ability to prove what happened afterwards. Actually, without such verifiability, you might not need to bother with deriving an ECDSA key from the PIN at all, and just send the PIN over TLS to the server. How do you foresee assurance and verification on this aspect?

#5. The proofs-of-possession of wi_rwscd_pin_prvk and wi_rwscd_auth_prvk can be cryptographically bound not only to a challenge nonce, but also to more application context data. For example, to the access scope that the user is is authorising for the current session, limiting the operations that the Wallet Instance can request at the rWSCD. Also the two proofs could be bound to each other (e.g. using countersignatures or cross-signatures). Do you have concrete ideas for the messages to sign using ECDSA?

#6. Indeed I’d recommend to replace local caching of wi_rwscd_pin_prvk, since extracting this value from runtime app state would compromise the knowledge factor. Note that rWSCD-established sessions may pose new risks. Do you already have a concrete solution in mind?