Re: On why revocation is important...

Worth reading the source post

https://blog.dvuln.com/blogs/servicensw-digital-superbad

The issue is only the name and over 18 status is verified (via central
authority), so the Id photo can be swapped without detection (and since app
allows restore from backup and the backup can be brute force decrypted, the
data can be side loaded).

The attack relies on the fact that the photo is the data element that links
the credential to the physical person at point of physical verification,
and this is not verified and not tamper proof.


On Thu, 26 May 2022, 7:31 am Manu Sporny, <msporny@digitalbazaar.com> wrote:

> On 5/24/22 4:52 PM, Mike Prorock wrote:
> > Have any thoughts on this developing issue in NSW?
> >
> https://arstechnica.com/information-technology/2022/05/digital-drivers-license-used-by-4m-australians-is-a-snap-to-forge/
>
> Yikes!
>
> For those that didn't read the article, the TL;DR is:
>
> Tough to forge digital driver’s license is… easy to forge... 4 million
> mobile
> driver's licenses in NSW Australia compromised in an unrecoverable way.
>
> Mistakes made seem to be:
>
> * No digital signature on data.
> * Ability to brute-force encryption on driver's license
>   data.
> * Credential refresh never refreshes data.
> * A "digital hologram" that uses the phone's tilt
>   sensor!?!?
> * The QR Code is not digitally signed.
> * No verification of digital signature by verifiers, you
>   just assume the data being transmitted is valid.
> * Rolled their own everything -- didn't use vetted
>   standards.
>
> The article is an eye-opening read on how not to do digital credentialing
> infrastructure.
>
> I expect most in this community would read the article and go "No way we'd
> do
> something that misguided!"... but it feels like there is a lesson here. As
> in,
> how close are we to the same sort of compromise in the VC ecosystem. So, I
> did
> a bit of a thought experiment... how would a VC have fared in a completely
> mis-implemented digital wallet?
>
> The first issue seems to be that there are no digital signatures on any of
> the
> data transmitted by the mobile driver's license app. Verifiable Credentials
> would've prevented this first error because VCs have to be digitally
> signed to
> be trusted. At least, we hope that's what people out there are doing. The
> takeaway for us is to clearly outline this in the implementation guide --
> it's
> not a VC if it's not signed by an issuer, there is no security if it is not
> signed.
>
> https://github.com/w3c/vc-imp-guide/issues/64
>
> The second issue had to do with using 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.
>
> https://github.com/w3c/vc-imp-guide/issues/65
>
> The third issue has to do with this misguided notion that I've heard many
> times now... that the App itself has a visual watermark that let's the
> verifier visually inspect that the app is a legitimate mDL app. I've heard
> government representatives from US states as well as some sales people from
> vendors in the space say this. We all know that digital images that you
> visually inspect are NOT a trustworthy security feature... even if you use
> the
> phone's tilt sensor to turn it into a "digital hologram".
>
> https://github.com/w3c/vc-imp-guide/issues/66
>
> The fourth issue had to do with the QR Code being trusted in some way
> without
> a digital signature being used. It's unclear what, if any, protection
> mechanism was in place for the QR Code, but what is clear was that it was
> not
> a digital signature that was being verified. Or if it was, the signature
> was
> created client-side and was not being checked for validity or revocation by
> the verifier. Every QRCode in the TruAge age verification program is a
> unique,
> digitally signed VC encoded as CBOR-LD and displayed as a QR Code. The
> verifier must check that the issuer is valid and the signature is valid
> before
> processing the data. QR Codes that don't result in a digital signature
> check
> happening at some point in the process are asking for trouble.
>
> https://github.com/w3c/vc-imp-guide/issues/67
>
> But the real learning here is that we should not all laugh this moment of
> Schadenfreude off without realizing that this is going to be one of us in
> the
> next several years.
>
> Security is hard and even the best of us get it wrong, even when we know
> all
> the right things to do. Or we miscalculate the ever shifting security
> landscape around our applications. One of the reasons our company is
> involved
> in W3C and IETF is because we know there are other, smarter people than us
> operating in those venues, and if we put our designs in front of them, they
> just might catch a big mistake in our designs. That's one of the reasons
> using
> open standards is of benefit to all of us... it's not just about
> interoperability, it's about building safer systems for society.
>
> This is a learning moment... are there any other lessons we should be
> taking
> away from this and documenting?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>