One of the security failures above was that the app used a 4-digit PIN to encrypt the driver's license. I would hope that those doing client-side encryption for digital wallets would use an encryption key from a proper entropy source. Granted, if the credential was digitally signed in the first place, it couldn't be tampered with, but we should be treating all data in a digital wallet as something you don't want falling into the hands of anyone that has access to the data on your phone (like your backup provider). There is also the question around proper protection of private key material. I know that some of the digital wallets in our space don't protect their private keys at all, and that's a problem that's going to come back and bite our community.
Credential storage should be encrypted using strong keys from cryptographically safe entropy sources. Private keys should be hardware-backed if at all possible, and if not, encrypted when not in use (using strong keys from cryptographically safe entropy sources).
The issue was discussed in a meeting on 2023-02-07
no resolutions were taken
View the transcript
#### 2.3. Ensure that credential storage should be encrypted using strong entropy sources (issue vc-imp-guide#65)
_See github issue [vc-imp-guide#65](https://github.com/w3c/vc-imp-guide/issues/65)._
**Kristina Yasuda:** related to another issue, make sure credential storage is encrypted using entropy from strong sources..
> *Kristina Yasuda:* +1 to "security implications" term.
**Manu Sporny:** one of the reasons compromise of the Australian DL was possible, they were just using a 4 digit pin to encrypt the data in the app. decryption was easy so modification was easy. they legitimate app could be made to show whatever the attackers wanted..
… this would be implementation guidance for wallet vendors to not do that..
… 256 bit key vs 4 digit pin.
… apps need to be protected in legit ways.
**Steve McCown:** I have a lot of background in this area. Manu, you mention something. I wonder what the solution is. We shouldn't train people to look for indicators inside the app..
… form an ordinary user perspective, what should they look for. they open their app and open a credential fro the government. Everything that displays on the screen can be forged, what can they do instead?.
**Manu Sporny:** we don't have a complete answer. It depends on the use. If the individual is working for an organisation and their job is to receive credentials, they need to always use the proper app. In a retail environment, trust the PoS system, not the thing the customer has. In theory your app is trusted..
… the other question is harder, how can you know the app itself can be trusted? Ifs the app store trustable? Is there some supply chain integrity controls?.
> *Dave Longley:* +1 ... you have to use your own trusted apps and devices -- never rely on someone else's ... establishing trust in your own apps and devices is a harder problem..
**Manu Sporny:** that is a much harder problem..
… we are depending on the people checking the credentials to determine legitimacy.
… not the users.
**Steve McCown:** I volunteer to help write those things up.
… This issue is going to get bigger. the EU has sued apple to allow alternative app stores..
… all of the goodness of android may be coming to apple..
… I can also hold private keys outside of an enclave. We are moving into a world where it is fairly reasonable to download the government app for the vetted app store, but that might be harder moving forward..
… what is the average user to do. what can we tell them?.
**Kristina Yasuda:** we are a bit over time. This is what is happening in Use cases and Implementation Guide. Please go through these before the face to face..
… please review the holder binding PRs..
… see everyone tomorrow tomorrow at this same time..
---
From this article:
https://arstechnica.com/information-technology/2022/05/digital-drivers-license-used-by-4m-australians-is-a-snap-to-forge/
One of the security failures above was that the app used a 4-digit PIN to encrypt the driver's license. I would hope that those doing client-side encryption for digital wallets would use an encryption key from a proper entropy source. Granted, if the credential was digitally signed in the first place, it couldn't be tampered with, but we should be treating all data in a digital wallet as something you don't want falling into the hands of anyone that has access to the data on your phone (like your backup provider). There is also the question around proper protection of private key material. I know that some of the digital wallets in our space don't protect their private keys at all, and that's a problem that's going to come back and bite our community.
Credential storage should be encrypted using strong keys from cryptographically safe entropy sources. Private keys should be hardware-backed if at all possible, and if not, encrypted when not in use (using strong keys from cryptographically safe entropy sources).