Android 13 Requires Hardware Support for Mobile Driver's Licenses for Some New Devices

Mishaal Rahman
Try Esper for Free
Learn about Esper mobile device management software for Android and iOS

Governments around the world are exploring the use of digital ID as a valid form of identity. One form of digital ID, the mobile driver’s license (mDL), is gaining traction in at least 30 U.S. states, according to the Secure Technology Alliance. Mobile driver’s licenses offer multiple benefits over physical cards, as they’re one less item to carry, offer more control over what information can be shared and how, and are readily verifiable by issuing authorities. With the recent publication of the ISO 18013-5 standard, we expect more issuing authorities to back the development of mDL applications.

To support the development of ISO-compliant mDL applications, Google introduced the Identity Credential API in Android 11. This API provides an interface to a secure store for user identity documents, and it can be implemented with or without hardware support. An Android Jetpack library implements the Identity Credential API on Android 7.0+ or later, and if the device lacks hardware support, then an Android Keystore-backed implementation will be used instead.

According to Google, the Android Keystore-backed implementation is “perfectly adequate for both holders and issuers [of mobile driver’s licenses] in cases where all data is issuer-signed.” However, the Keystore-backed implementation “does not provide the same level of security and privacy” as a hardware-backed implementation, so device makers are encouraged to implement hardware support.

Enabling hardware support for the Identity Credential API requires implementing a Hardware Abstraction Layer (HAL). Implementing the IC HAL enables the ability to store identity documents in the device’s “secure hardware.” Section 9.11.3 of the Compatibility Definition Document (CDD) defines the requirements for said “secure hardware,” which on most devices is met by a Trusted Execution Environment (TEE), a dedicated area of the main applications processor (AP) that executes code in an isolated environment. Only a handful of Android devices have implemented the IC HAL even though TEE implementations are ubiquitous thanks to CDD requirements, but this is set to change with Android 13.

According to a recent code change, chipsets launching with Android 13 must support the Identity Credential HAL at feature version 202201 or later*. This is enforced through a new test in the Vendor Test Suite (VTS), the automated test suite that validates that the device’s vendor implementation is compliant with Google’s requirements. VTS is one test of many that Google requires device makers run before they can ship Google Mobile Services (GMS) on their devices. However, because of the Google Requirements Freeze (GRF) program, Google cannot mandate that devices upgrading to Android 13 support the IC HAL, which is why the requirement is limited to new chipsets launching with Android 13. Thus, the Vendor Software Requirements (VSR) for Android 13 will likely exempt devices upgrading to Android 13 from having to implement the IC HAL.

Android AOSP documentation
Code change implementing the VTS test to check that the Identity Credential HAL is implemented

Implementing the IC Direct Access HAL, on the other hand, won’t be required of any device maker or silicon vendor. This HAL provides support for direct access to the device’s secure hardware via NFC, which makes it possible to retrieve credentials even when the device’s battery is too low to boot the Android OS. However, this is only possible if the secure hardware features a CPU and storage device that’s separated from the main AP. Very few devices meet this criteria, so it may take years for devices with support for the IC Direct Access HAL to come to market.

Android device catalog
The list of devices that currently implement the Identity Credential HAL only includes Google Pixel devices. No device has implemented support for the Identity Credential Direct Access HAL.

Google is pushing for issuing authorities to use Android’s Identity Credential API when developing mDL applications. Once more devices are released with hardware support for the IC API, Google will have an easier time convincing issuing authorities to develop their applications using the API. By using the IC API, Google says that “the trusted computing base of mDL applications does not include the application or even Android itself,” which will be important in the future “where the [mDL] verifier must trust the device to identify and authenticate the user.”

In the future, we expect digital documents other than mobile driver’s licenses to be stored and retrieved via the IC API. This is because the IC API was designed to be generic, so other types of documents, such as motor vehicle registration (mVR) or a vaccination passport (micov), are technically supported. Google’s open source reference applications demonstrate the use of the IC API to store and retrieve multiple types of documents, and are a great way to demo the holder and verifier flow.

For more information on the state of mobile driver’s licenses on Android, their benefits over traditional licenses, and images demonstrating how they work, please refer to this article from my Android Dessert Bites column.

*Feature version 202201 of the Identity Credential HAL introduces support for presenting multiple documents during a single transaction (eg. simultaneously sharing one’s driver’s license and motor vehicle registration).

Android Device Management

Hero image source: New Africa/


No items found.
No items found.

Keep Exploring

No items found.
Mishaal Rahman
Mishaal Rahman

Mishaal Rahman is a Technical Editor at Esper. He has been an Android user for over a decade and has been at the forefront of Android news coverage for half a decade. His in-depth breakdowns of new Android versions have been referenced across the Internet.

Mishaal Rahman
Learn about Esper mobile device management software for Android and iOS
Featured resource
Read more
Featured resource
Considerations for Building Android Apps for Company-Owned Devices
Your app delivers your customer (or employee) experience, making it a crucial piece of your overall solution. Use this guide to understand the considerations of designing and building your perfect app for dedicated device use cases on Android hardware.
Download the Guide

Esper is Modern Device Management

For tablets, smartphones, kiosks, point of sale, IoT, and other business-critical edge devices.
MDM Software
Kiosk mode icon as a feature in mobile device management software

Kiosk mode

Hardened device lockdown for all devices (not just kiosks)
App management icon as a feature in mobile device management software

App management

Google Play, Apple App Store, private apps, or a mix of all three
Devices groups icon as a feature in mobile device management software

Device groups

Manage devices individually, in user-defined groups, or all at once
Remote tools icon as a feature in mobile device management software

Remote tools

Monitor, troubleshoot, and update devices without leaving your desk
Touchless provisioning as a feature in mobile device management software

Touchless provisioning

Turn it on and walk away — let your devices provision themselves
Reporting and alerts as a feature in mobile device management software

Reporting and alerts

Custom reports and granular device alerts for managing by exception