Update 1 (3/6/19 @ 8:44 PM ET): More details on Google's plans for the IdentityCredential API have been shared by Shawn Willden, Android hardware-backed security team lead. The article has been updated with these details at the end. The original article follows.

Carrying a wallet has become less of a necessity for me since I started using Google Pay to manage my credit cards, but there's still no way I can travel anywhere without my driver's license. I know a few people who use wallet cases to hold what few cards they must carry on their person, but I'm waiting for the day when I can legally drive to Walmart with just my phone on me. A digital driver's license offers multiple advantages over the traditional ID card. You can't lose it, you can update it remotely so you don't have to stand in line at the DMV, you can wipe it remotely if your phone gets stolen, you're less likely to get your identity stolen since you don't need to carry a wallet with easily accessible information, you're less likely to leave your phone at home, and you'll have an easier time bringing it up on request. Authorities across the U.S. are slowly recognizing the benefits of a mobile driver's license, which is why we're hearing more U.S. states test their adoption each year.

For instance, residents of Louisiana can download the Envoc-developed LA Wallet app which has been approved by LA's law enforcement for license verification and LA's ATC for alcohol and tobacco transactions. Age verification is particularly interesting since users can limit the mobile app to only show necessary information to a vendor of alcohol or tobacco. Elsewhere, digital security company Gemalto is partnering with Colorado, Idaho, Maryland, Washington D.C., and Wyoming to run pilot programs before rolling out their digital driver's license solution. At the same time, the American Association of Motor Vehicle Administrators is working to standardize this new form of electronic identification.

There are downsides to the digital driver's license, though. You have a lot of control over who gets to see your physical ID, but you have less control over who or what has access to its digitized form. You can password or PIN-protect your phone or the app that pulls up your mobile license, but there's always a chance that your phone and all its data could become compromised. Plus, you have to make sure your phone has enough juice to keep Android running so you can pull up the license. With the IdentityCredential API, Google is working to solve both of these problems. In a future version of Android, perhaps Android R, devices with the right hardware will be able to securely store identification cards, especially digital driver's licenses, and even access them when the device doesn't have enough power to boot Android.

IdentityCredential API

At first glance, the commit, submitted by Shawn Willden, Lead of Android's Hardware-backed Keystore Team, doesn't seem very interesting. However, if you view the IdentityCredential and IdentityCredentialStore files, you'll find multiple references to what kinds of "identity credentials" Google is referring to. For instance, IdentityCredential uses a protocol of key exchanges that is "used by the ISO18013-5 standard for mobile driving licenses." Furthermore, this protocol is used as "the basis for ongoing ISO work on other standardized identity credentials." While it's unlikely we'll see mobile passports anytime soon, it's clear that this API is intended for more than just mobile driving licenses.

Digging deeper, Google elaborates on the types of signing keys supported by the IdentityCredential API. There are two kinds of data authentication: static and dynamic. Static authentication involves keys created by an issuing authority, whereas dynamic authentication involves keys created by the device's security hardware (such as the Titan M in the Pixel 3 and Pixel 3 XL.) The benefit of dynamic authentication is that its harder for an attacker to compromise the secure hardware to copy the credential to another device. Furthermore, dynamic authentication makes it harder to link a particular credential with a user's data.

An Android app can present an IdentityCredential to a reader by asking the user to initiate a wireless connection via NFC. Apps are recommended to guard these transactions by requesting user permission in the form of a dialog and/or password protection.

If a device has the supported hardware, the "direct access" mode will be available to allow an IdentityCredential to be presented even if there isn't enough power to keep Android running. This is possible only when the device has discrete secure hardware and enough power to operate that hardware to share the credential over NFC. Devices like the Google Pixel 2 and Google Pixel 3 should qualify since both devices have tamper-resistant security modules that are separate from the main SoC.

If the device doesn't have a discrete secure CPU, it can still support the IdentityCredential API albeit without direct access support. If the credential store is implemented in software only, it can be compromised by an attack on the kernel. If the credential store is implemented in the TEE, it can be compromised by side-channel attacks on the CPU such as Meltdown and Spectre. If the credential store is implemented in a separate CPU embedded in the same package as the main CPU, it is resistant to physical hardware attacks but can't be powered without also powering the main CPU.

The sensitivity of the document will determine if one or more of these identity credential store implementations will be supported. Developers can check the security certification of the identity credential store implementation. Identity credential store implementations can be uncertified or have an Evaluation Assurance Level of 4 or greater. The EAL tells app developers how secure the implementation is against potential attacks.

As I mentioned before, Google intends for this API to be used for any standardized document type, though they list ISO 18013 mobile driving licenses as an example. The document type is necessary so the security hardware knows what type of credential it is in case direct access mode should be supported, and to allow apps to know what type of document a reader is requesting.

That's all the information we have so far on this new API. Since we're so close to the release of the first Android Q Developer Preview, I don't think it's likely we'll see support for securely storing mobile driver's licenses in Android Q. However, this API could be ready by the time Android R rolls out in 2020. The Google Pixel 2, Google Pixel 3, and upcoming Google Pixel 4 should support this API with direct access mode in Android R, thanks to having the necessary discrete secure CPU. We'll let you know if we learn more information about what Google intends to do with this API.


Update 1: More details on the IdentityCredential API

Shawn Willden, the author of the IdentityCredential API commit, shared additional details about the API in the comments sections. He answered a few comments from users, which we will reproduce below:

User Munnimi stated:

"And when police take your phone and goes to police car, they can check what's in the phone."

Mr. Willden responded:

"That is something I'm specifically working to make impossible. The intention is to structure the flow so that the officer cannot usefully take your phone. The idea is that you do the NFC tap with the officer's phone, then unlock with fingerprint/password, then your phone goes into lockdown mode while the data is transferred over bluetooth/Wifi. Lockdown mode means that fingerprint authentication won't unlock it, a password is required. This is specifically to force invocation of the fifth amendment protection against self-incrimination, which some courts have found does not prevent police from forcing you to unlock with biometrics, but everyone agrees prevents them from forcing you to give your password (at least in the US).

Note that that is an aspiration, not a commitment. The ways in which we can force the flow on identity app developers are limited, because if we go too far they can just choose not to use our APIs. But what we can do is make it easier for them to do the right, privacy-sensitive, thing."

User RobboW stated:

"This is useless in Australia. We are required to have our physical, official drivers license with us whilst driving. A digital copy is just ripe for identity theft."

Mr. Willden responded:

"Australia is an active participant in the ISO 18013-5 committee, and very interested in supporting mobile driving licenses. As for identity theft, there are lots of protections against that being built in. The article mentions some of them."

User solitarios.lupus stated:

"Considering what this site does I think everyone here knows this will not work and is a huge security issue for law enforcement. To easily forged, faked and manipulated."

Mr. Willden responded:

"Outright forgery will be all but impossible, because the data is all digitally signed. Forging a credential would require forging the digital signature which either requires a radical break of the relevant cryptography (which would break TLS and pretty much everything else) or else stealing the issuing authority's signing keys. Even alteration, by taking some signed data elements from one DL (e.g. a birthdate showing you're over 21) and some from another (e.g. your real photo) will be impossible, because the signing covers the entire document, binding all of the elements together."

User mark stated:

"If a photocopy was never valid for ID, why does being on a phone make a difference? Even if Google promise to make it secure, how does that stop someone showing up a fake application?

Still, even if there aren't answers to that, I still think it's a good thing for the reasons given in this article. I'd like it for passports - not for traveling necessarily, but other occasions where ID is needed (I don't drive, so my passport is my only ID).

Of course, I'd also prefer it if the UK wasn't turning into a "papers please" society, where you need to have a passport scanned even just to go to a pub in some cases..."

Mr. Willden responded:

"Digital signatures will make it secure. You can have a fake application, but it can't produce properly-signed data.

Passports are also very much in scope for this work, BTW. Driving licenses are the starting point, but the protocols and infrastructure are being carefully designed to support a wide range of identity credentials, specifically including passports. Of course, we'll need to convince ICAO to adopt the approach, but I think that's very likely."


Thanks to XDA Recognized Developer luca020400 for the tip!