Re: On why revocation is important...

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/

Received on Wednesday, 25 May 2022 21:59:21 UTC