Two weeks ago I gave a talk about the mobile driver’s license standard at IIW XXXVII, the 37th meeting of the Internet Identity Workshop, which took place as usual at the Computer History Museum in Mountain View.
One of the great things about IIW is that the agenda is created each day. That makes it possible for people interested in the same topic to merge their sessions. When I announced the session that I wanted to convene, Andrew Hughes “hijacked my session”, as he said, to present a progress update on the series of ISO driving license standards, which was a perfect introduction to the details of part 5 of the series that I discussed in the second half of the session. Andrew is a member of the committee that wrote ISO/IEC 18013-5, and other committee members came to the combined session. The notes of the session, taken by Dan Bachenheimer, will eventually be in the Book of Proceedings, and can now be found here. My slides were based in part on an early draft of a chapter of a book on Foundations of Cryptographic Authentication that I am coauthoring with Sukhi Chuhan and Veronica Wojnas.
The mDL standard has many interesting innovations and privacy features.
One innovation, explained in slide 26, is the inclusion of self-asserted (device-signed) and certified (issuer-signed) data elements in the same credential. One wouldn’t expect to find self-asserted claims in a driver’s license, and Section 8.3.2.1.2.2 explicitly says that the structure containing the device-signed elements may be empty. But the mDL standard is in fact a general purpose standard for mobile credentials, which competes with verifiable credentials as discussed in this UL white paper.
Both kinds of data elements are retrieved in an encrypted session established by an ECDH key agreement where both parties use ephemeral key pairs and therefore neither party is authenticated. After the session has been established, the mobile device that carries the credential authenticates as a side-effect of signing the list of self-asserted data elements requested by the reader, whether or not it is empty!
Another innovation, explained in slide 28, is a clever use of an asymmetric key pair to produce a repudiable symmetric signature (an “ECDH-agreed MAC”), and a third innovation, explained in slide 29, is a clever adaptation of OpenID Connect to a use case where it would not seem to be applicable.
Privacy features include declaration by the relying party of the intent to retain some of the data elements, data minimization using selective disclosure, and proof of age without revealing the birthdate by means of age attestations.
Selective disclosure is implemented by means of cryptographic hashing, as explained in slide 11. Full unlinkability (protection against tracking by collusion of the issuer and the relying parties) is not provided, but selective disclosure based on hashing combined with age attestations provides the key benefits of data minimization and proof of age in a simpler way than anonymous credentials. Alternative implementations of selective disclosure, based on hash functions or proofs of knowledge, are described in slides 12-23.
On the other hand, the mDL standard also has privacy drawbacks and vulnerabilities to unauthorized access and man-in-the-middle attacks. The vulnerabilities are discussed in slides 30-39, with an example of a man-in-the-middle attack shown in slide 37. They are also discussed in Section 13.1.9 of the book chapter, along with proposed mitigations in the current or future versions of the standard. Privacy is discussed in slides 40-42 and in Section 13.1.10 of the book chapter.
The vulnerabilities and the privacy drawbacks have two independent root causes.
The first root cause is the belief that proximity implies trustworthiness and warrants permission, hinted at in Section 6.3.3: “The public key of the mDL is shared only through short-range device engagement. This ensures data is only transferred between the mDL and a particular mDL reader”. That the particular reader is trustworthy because of the short range is left unsaid.
This belief is mistaken for two reasons: (i) a nearby verifier is not necessarily trustworthy (would you disclose all your identity information to the bouncer who asks for proof of age in a bar?); and (ii) it is possible to eavesdrop on short-range device engagement, as documented in the slides and the book chapter.
The first root cause by itself leads to the surprising prohibition of reader authentication stated in Section 7.2.1: “An mDL shall not require mdoc reader authentication as a precondition for the release of any of the mandatory data elements”. (See slide 10 for an explanation of the terms “mdoc” and “mdoc reader”.) Lack of reader authentication prevents informed consent and negates the privacy benefit of selective disclosure.
The second root cause is a server retrieval path for retrieving data elements over the internet from a server made available by the issuing authority, instead of retrieving them from the mobile credential over one of the proximity channels (BLE, NFC, or WiFi Aware). Use of this path negates the privacy benefit of unobservability of the authentication transactions by the identity provider. As acknowledged in Section 8.3.2.2, when this flow is used: “The issuing authority infrastructure is involved in each server retrieval-based transaction; therefore, the issuing authority knows when an mdoc is used and what data is shared.” This statement is followed by: “If tracking is a concern, the issuing authority can implement mitigating strategies to ensure the mdoc and the mdoc holder are not tracked”. But there is no explanation of what those strategies might be.
To use the server retrieval path, the reader needs to get a server retrieval token from the mobile device. The token can be obtained as a data element in the encrypted session set up for data retrieval from the mobile device. But it can also be retrieved in the clear during device engagement, because device engagement is short-range, and proximity is mistakenly believed to imply trustworthiness. Thus, the combination of both root causes leads to a flow that circumvents the encrypted session and where the mobile device does not authenticate.
This flow is what creates the vulnerabilities to unauthorized access and man-in-the-middle attacks discussed in slides 30-39 and in Section 13.1.9 of the book chapter.