Did you miss a session from the Future of Work Summit? Head over to our Future of Work Summit on-demand library to stream.
The last day of Google’s developer conference tends not to have any news, but this year was a little overloaded. Google announced today that it’s working on bringing Electronic IDs to Android. Separately, the company also confirmed that all new Android Q devices will be required to encrypt user data.
Replacing ID cards, such as driver’s licenses and club memberships, has been the last major piece of the digital wallet puzzle. We’re not talking about securely logging into web pages — this is for identifying yourself in “physical world transactions.” Wallet apps can replace plane tickets, loyalty cards, and credit cards, but they still can’t pass for valid ID. Google is looking to add Electronic ID support so developers can build mobile apps that can be securely used as an ID.
This isn’t as simple as it sounds. Google wants to make sure its implementation follows cryptography practices and standardization procedures. That means getting the Android Security and Privacy team involved.
“We will be providing APIs and a reference implementation of HALs for Android devices in order to ensure the platform provides the building blocks for similar security and privacy sensitive applications,” said Rene Mayrhofer, head of Android Platform Security. Google wants to build an Identity Credential API into Android, Mayrhofer told VentureBeat. Identity credentials will come with a credential store that supports apps provisioning their attributes and measures their transparency.
Encryption IDs and the mDL ISO standard
Will this functionality make it to Android Q? Not exactly.
“The mobile driving license (mDL) ISO standard hasn’t locked down yet to a sufficient extent [for us] to drop the API already into the Q platform,” Mayrhofer noted. “It’s the one standard that is the farthest ahead among all those electronic ID initiatives worldwide. As far as I can see the ISO discussions going, the future passports discussions will probably wait for mDL to first finish, and then adopt quite a bit of data. This is exactly why we want to make sure that the API that we drop into the Android framework is spot on to implement all of what mobile driving license needs, plus more generic behavior to be open to other types of ID.”
The mDL has been in the works for nearly three years, and Google is contributing to the standard. But the Android team isn’t willing to play the waiting game any more.
“Instead, very, very soon, we will launch another Jetpack compatibility library that app developers can use immediately to write such apps for various DMVs or whatever cards — in the future, maybe even travel documents, although that kind of standardization for international travel is even further out.”
“It’s got to be a library,” Mayrhofer explained. “But we expect that the API will stay pretty much unchanged for the API that will land in a future version of Android in the framework itself. Then the credential store will become a system service, a system daemon that is shared among all the apps and can interface through a new HAL directly with OEM-specific secure hardware. You might have seen that the code changes are already in the AOSP changelog. They haven’t been merged with the official Q master yet, but everybody can already see what the HAL specification will probably look like in a future API drop.”
Eventually, the goal is to have Android securely store identification cards, including passports, that can be accessed even when the device doesn’t have enough power to boot.
“It’s hard to predict when that will lock down,” Mayrhofer lamented. “But as soon as it does, or probably even sooner, we may merge the support into the framework. And we’re already talking to OEMs about partner support for what we call direct access. And this is what the compatibility library cannot do — we need to depend on the HAL being in there, the hardware changes being in there. Where you can use your electronic ID even when your phone battery is too low to power the main CPU. Just NFC tap, and you would still be able to access it because it would then be stored on a secure element that’s directly wired up.”
Google would likely launch this functionality with Pixel devices first and then convince other Android makers to play ball. We’re easily a few years away from people using their Android devices as IDs.
Android Q encryption
In nearer security news, Google already shared earlier this week that Android Q Beta 3 introduces improvements to biometrics and network traffic encryption. But the data at rest encryption requirement for Android Q is new.
Chances are that user data on your Android device is encrypted. In fact, since Android Marshmallow, Google has required device makers to enable storage encryption by default. But not all devices — those with poor Advanced Encryption Standard (AES) performance (50 MiB/s and below) were exempt.
In February, Google launched Adiantum, a new form of encryption designed to secure data stored on lower-end smartphones and other devices with insufficient processing power. At the time, the company hinted that it would update the Compatibility Definition Document (CDD) to require that all new Android devices be encrypted. Today, the company has delivered. The encryption requirement includes Android Q phones, tablets, televisions, and automotive devices. “No exceptions,” Mayrhofer said.