Access credential content before unlocking of the wallet

[TimoGlastra]

The Digital Credentials API is a new API that allows to invoke a wallet through native APIs or the browser. It is already supported in Chrome and Android.

For Android to make your wallet DC API compatible, you need to specify a matcher. The matcher is executed for all wallets and determines which wallet is able to handle a request. This is great for UX, as you don't have to choose the wallet yourself.

The problem however is, the matcher is ran in the background, and needs access to the credentials to perform the matching based on DIF Presentation Exchange or DCQL.

The current model we employ and recommend on mobile is to encrypt the wallet based on a key stored in biometrics protected storage, or derive it based on a PIN using a KDF.

This prevents the matcher from running as we don't have access to the credentials. From talking to some people on the Google/Android team I was informed that maybe the current model we use is not the best and we should:

• rely on native OS app level encryption, because (on android) /data is already encrypted on all recent Android versions and the OS provides mechanisms so only the specific app can see the data. Encrypting it before storing it in /data is basically just double-encryption.
  • I guess this stance makes sense from an OS provider. I think there could be value in double encryption as not all people that need to have access to my phone need access to my wallet.
• make key usage protected behind a PIN / biometrics.

With a 6-digit PIN it would take max 1.000.000 operations to unlock the wallet. Currently on a somewhat recent Android it takes around 1.4 seconds to do KDF, meaning that it would take around 16 days to crack the PIN. On a powerful machine that would be much much less.

This issue is to explore possibilities to change how we manage storage in Credo, such as:

• should we have a per-record type usage policy?
• should we store some items in the Askar database such as the keys that can't be stored / doesn't need to be stored in Secure Enclave, and anoncreds private material (link secret on mobile). Then to use a credential you need to unlock/decrypt the wallet
• and then rely on the mobile platform native encryption for all other data
• Only store some metadata outside of the Askar wallet such as:
  • doctype/vct
  • claim values
  • other needed values?
  • But what is the advantage over just storing the whole credential in the app-protected storage?

[TimoGlastra]

@swcurran curious about BC Gov's opinion on this matter

[cvarjao]

Hi @TimoGlastra ,

First, thanks for this summary!

We have has some push back from people who do not want to use device protection (PIN/Biometrics). I am not sure how much is an education piece. There are people who seem PIN/Biometrics as a block, and there are people who wrongly thinks that the government is collecting their biometrics. So, it is hard to change perception (however wrong it might be) while trying to be inclusive.

I think we might need to do a comparison on what is available on both iOS and Android. There might be some differences, but a common layer would be helpful. Sometimes I wonder if askar could simply be a sqlite (either SQL or nosql engines) database with encryption enabled/disabled. I think it would make it easier for developers as well.

Has anyone looked into how this would be available in IOS (or if at all)

[timbl-ont]

The problem with device native security is that you cannot enforce complexity rules on the device password or device managed app password. This is required by many cybersecurity groups. Unlike a company provided mobile device, policy cannot just be pushed via an mdm solution to the holders device. Without this issue, the device managed path is much cleaner.

Worked on a bunch of prototypes (a couple years back) to test the various combinations of biometrics, device password, device managed app password and app managed PIN - on IOS. At that time there was very limited flexibility (not sure if that has changed).

A model was developed that was biometrics only with a PIN as an additional control, but it could not completely eliminate the fact that mobile device security is controlled by the device password (weakest link) and not biometrics. Also "biometrics only" is likely too aggressive when accounting for the current adoption (as per @cvarjao) and the fact that it does not work for everyone (especially fingerprint).

Bifold uses a KDF (salt+pin) to derive the Askar encryption key and then also secure that key in the keychain backed by biometrics (biometrics or wallet PIN). There is a PR in progress (not raised in Bifold yet) to invalidate the keychain if biometrics are changed.

In this model, there are only limited options to secure the salt in the keychain. One option is to require user presence (planned in the same PR) which requires that the device is unlocked to access the keychain and read the salt. The problem is that by default there is no security if a device password is not configured.

If an attacker gets the database and salt then it would be trivial to get access to the encrypted DB. In tests, I was able to get access to both using FRIDA which is a popular hacking tool.

Generating the holder binding keys in the SE/TEE is a mitigation for some credential formats. I think that there are no perfect solutions without changes on the OS side.