Selective Disclosure

Overview of ISO/IEC 18013-5: Innovations and Vulnerabilities in the mDL Standard

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.

Using an Omission-Tolerant Checksum for Selective Disclosure of Attributes Asserted by a Public Key Certificate

This is part 2 of a series on omission-tolerant integrity protection and related topics. A technical report on the topic is available on this site and in the IACR ePrint Archive.

The first post of this series introduced a new technical report that describes the concept of an omission-tolerant checksum in a broader context than the rich credentials paper and includes a formal proof of security in an asymptotic security setting. In this post I give an example showing how an omission-tolerant checksum implemented using a typed hash tree can provide selective disclosure of attributes asserted by a public key certificate.

Typed hash trees vs. Merkle trees

A typed hash tree is a hash tree where every node has a type in addition to a label, and the label of an internal node is a cryptographic hash of an encoding of the types and labels of its children. A distinguished type is assigned to all the internal nodes, and may also be assigned to some of the leaf nodes.

Hash trees were first proposed by Merkle. In a Merkle tree, each internal node is labeled by a hash of the concatenation of the labels of its children, and each leaf node is labeled by a hash of a data block. In both a typed hash tree and a Merkle tree, a subtree can be pruned without modifying the root label of the tree. (By “pruning a subtree” we mean removing the descendants of an internal node.) But in the case of a Merkle tree this is a “bug” to be mitigated if the tree is to provide integrity protection, while in the case of a typed hash tree it is a “feature” that allows the root label of the tree to be used as an omission-tolerant checksum.

An Omission-Tolerant Cryptographic Checksum

This is part 1 of a series on omission-tolerant integrity protection and related topics. A technical report on the topic is available on this site and in the IACR ePrint Archive.

Broadly speaking, an omission-tolerant cryptographic checksum is a checksum on data that does not change when items are removed from the data but makes it infeasible for an adversary to modify the data in other ways without invalidating the checksum.

We discovered the concept of omission-tolerant integrity protection while working on rich credentials. A rich credential includes subject attributes and verification data stored in a typed hash tree. We noted in an interim report that the root label of the tree could be viewed as an “omission-tolerant cryptographic checksum”. Prof. Phil Windley, who read the report, told us that he had not seen the concept before, and asked if we had invented it. We then added a section on typed hash trees and omission-tolerant integrity protection to the final report.

We’ve now written a new technical report that discusses omission-tolerant checksums and omission-tolerant integrity protection in a broader context than rich credentials. The main contributions of the new paper are a formal definition of omission-tolerant integrity protection, a method of computing an omission-tolerant checksum on a bit-string encoding of a set of key-value pairs, and a formal proof of security in an asymptotic security setting that uses the system parameterization concept introduced by Boneh and Shoup in their online book.

I have not said much in this blog about omission-tolerant integrity protection, and there is a lot to say: how an omission-tolerant checksum can be used to implement selective disclosure of subject attributes in public key certificates; how public key certificates with selective disclosure could easily provide security and privacy for client authentication in TLS; what’s special about Boneh and Shoup’s system parameterization concept and how we use it in our definitions and proofs; how can a typed hash tree provide omission-tolerant integrity protection whereas a Merkle tree cannot; and a number of narrower but no less interesting topics. This is the first of a series of posts on these topics.