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.
A sample image of a digital driver’s license accessed through the LA Wallet app. Source: Envoc
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 Wilden, 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 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.
Thanks to XDA Recognized Developer luca020400 for the tip!
0 comments:
Post a Comment