Google Launches 'Android Ready SE Alliance' To Drive Adoption of Digital Keys, Mobile IDs (9to5google.com) 52
An anonymous reader quotes a report from 9to5Google: Smartphones have already obviated single-purpose gadgets like point-and-shoot cameras and MP3 players. Google today announced the Android Ready SE Alliance to make sure new phones have the underlying hardware to eventually replace car/home keys and wallets. "Emerging user features" -- digital keys, mobile driver's license (mDL), national ID, ePassports, and eMoney solutions (wallets) -- require two things. The first is tamper-resistant hardware, like the Pixel's Titan M chip, which makes possible tamper-resistant key storage for Android apps (to store data) called StrongBox. "All these features need to run on tamper-resistant hardware to protect the integrity of the application executables and a user's data, keys, wallet, and more," writes Google in a blog post. "Most modern phones now include discrete tamper-resistant hardware called a Secure Element (SE)."
Google has determined that "SE offers the best path for introducing these new consumer use cases in Android." To "accelerate adoption," the company and partners (Giesecke+Devrient, Kigen, NXP, STMicroelectronics, and Thales) today announced the Android Ready SE Alliance. Besides phones, StrongBox is also available for Wear OS, Android Auto Embedded, and Android TV. Google says it's currently focusing on digital car keys, mobile driver's license, and other identity credentials, with unnamed "Android OEMs adopting Android Ready SE for their devices."
Google has determined that "SE offers the best path for introducing these new consumer use cases in Android." To "accelerate adoption," the company and partners (Giesecke+Devrient, Kigen, NXP, STMicroelectronics, and Thales) today announced the Android Ready SE Alliance. Besides phones, StrongBox is also available for Wear OS, Android Auto Embedded, and Android TV. Google says it's currently focusing on digital car keys, mobile driver's license, and other identity credentials, with unnamed "Android OEMs adopting Android Ready SE for their devices."
Hey buddy! Got a charge? (Score:2)
Great, I can see it now:
"Hey buddy, got a charger I can borrow for 5 minutes? My mobile is dead so I cant unlock my apartment door." LOL
Re: (Score:2)
"Hey buddy, got a charger I can borrow for 5 minutes? My mobile is dead so I cant unlock my apartment door." LOL
Of course. And let me assure you this is just a basic charger that doesn't do anything with the data lines.
Nope (Score:1)
When a police officer needs to see my ID I am not handing them my phone. Ever. There is really no reason ever to hand them my phone.
Re: (Score:2, Informative)
When a police officer needs to see my ID I am not handing them my phone. Ever. There is really no reason ever to hand them my phone.
More notably, it would be your *unlocked* phone in the case of a mobile driver's license -- so I agree, no.
Re:Nope (Score:5, Informative)
When a police officer needs to see my ID I am not handing them my phone. Ever. There is really no reason ever to hand them my phone.
More notably, it would be your *unlocked* phone in the case of a mobile driver's license -- so I agree, no.
Absolutely not. We don't want that either, neither the Google engineers (I lead the team doing the Android Identity Credential work), nor all the other members of the ISO committee (I'm a voting member) who defined the 18013-5 standard which specifies how this works.
The way it works is that you don't hand your phone to the police officer at all. What's more, the plan in Android is that your phone will automatically enter "lockdown mode" after you authenticate (with biometric or password) to give permission to share your identity credential information. In lockdown mode, the phone is locked and cannot be unlocked with a biometric -- your password is required. This is specifically to invoke the fifth amendment right against self-incrimination (yes, yes, I know this is still a legal gray area, but we work with what we've got).
The flow goes like this:
1. The police officer requests your ID.
2. You open your ID app, which displays a QR code, which the officer scans with his phone.
3. No actual data about you is transferred via the QR code. Instead, what your phone provides over whichever channel you choose is its preferred communication medium: Wifi (Wifi Aware [wi-fi.org], to be precise) or Bluetooth, and what parameters the officer's phone should use. Also, a public ECDH key -- the public half of an ephemeral, just-generated key pair.
4. The officer's phone opens the appropriate wireless channel to your device, and sends a list of the data elements it's requesting, as well as an ephemeral ECDH public key. The request is encrypted with a session key derived from the exchanged ECDH keys.
5. Your phone prompts you to approve the data transfer, allowing you to select which of the requested data elements you're willing to share (though with a cop, and data from your DL, you're probably legally obligated to send it all). To approve the transfer, you authenticate with your password or biometric, then your phone goes into lockdown mode.
6. Your phone sends the data to the officer's phone, along with digital signatures, including one from the issuer. There's a lot of interesting crypto in here to ensure repudiability, that the protocol does not include any data that can be used to link presentations (unless the data elements transferred are unique, of course), and that you can present any subset of data elements without giving any hints about the rest of the data.
7. The officer's phone decrypts the data, verifies the signatures and displays the results to the officer.
This is actually all pretty convenient. It takes 3-4 seconds (mostly the Wifi-aware or Bluetooth connection establishment), but your phone stays in your hand the whole time. There's also an NFC option, but I don't think that will be used much in highway stops, or similar. I think the NFC flow is more appropriate when the verification device is fixed, such as sitting on a TSA podium in airport security (yes, the TSA is very interested in this -- and in future work that we're doing that may one day allow them to eliminate the officer at the podium, using an automated turnstile instead).
Note that the flow is carefully constructed so that the officer cannot get your ID by taking your phone from you. You have to authenticate to unlock access to the data, which means if the officer did take your phone, he'd have to hand it back before he could get the info. And, of course, as soon as you do authenticate, the phone locks down so if he were to snatch it after you authenticate, it's useless to him.
I also want to point out that in other cases where ID is used, especially in age verification for entry to bars or clubs, etc., the ele
Re: (Score:2)
No actual data about you is transferred via the QR code. Instead, what your phone provides over whichever channel you choose is its preferred communication medium:
Sorry, the "whichever channel you choose" is not very clear. The device engagement can be done via either QR or NFC. I think in a traffic stop situation you'd always use QR. I started to cover both cases, then decided not to bring up NFC in this flow... but neglected to go back and edit out this bit. So "whichever channel you choose" is QR or NFC... but in a traffic stop QR is much more convenient that trying to tap your phone to the cop's phone.
Re:Nope (Score:5, Interesting)
Thanks for the information. I'd like to offer a *much* simpler procedure:
1. The police officer requests your ID.
2. I hand him/her my physical driver's license.
Re:Nope (Score:4, Interesting)
Thanks for the information. I'd like to offer a *much* simpler procedure:
1. The police officer requests your ID.
2. I hand him/her my physical driver's license.
Also noting that #2 above can be used to identify me in case of an accident and I'm dead or unconscious whereas my locked phone cannot.
Re:Nope (Score:5, Interesting)
Thanks for the information. I'd like to offer a *much* simpler procedure:
1. The police officer requests your ID. 2. I hand him/her my physical driver's license.
Also noting that #2 above can be used to identify me in case of an accident and I'm dead or unconscious whereas my locked phone cannot.
I've had several discussions with law enforcement about that scenario. We explored various solutions early on, including one where if the police officer's device has an authentication key, it can demand your data without your authorization (and we have some things in place to mitigate abuse -- really, a *lot* of thought has gone into this). But we dropped it because the cops said it doesn't matter, that they really never do that anyway. They pointed out that in the event of an accident crap gets thrown everywhere and they may not actually find your phone, or if there are multiple people around they won't know which phone goes with which person, plus the phones could be broken, etc.
Their bottom line was that they didn't care. At the site of the accident they're going to focus on getting you treatment you need, and identifying you is something that other people worry about, later.
I still think that there are use cases where a "sufficiently-trusted reader" should be able to get the data without user assistance, and the Android implementation supports that sort of thing, but it would require DMVs to establish the necessary PKI and certify reader keys, and none of the DMVs (in any US state or in any other country) has been at all interested in doing that, so I expect that functionality to go largely unused.
Re: (Score:3)
Thanks again for all the information, but until literally every police officer (and bar owner, etc...) has compatible tech, people will still have to carry their physical license (and/or other IDs) with them, negating any need for the tech. In the other uses you mentioned, like grocery-store checkout line or bar bouncer, the person has only ever looked at the birth date (I've never had anything scanned/recorded) -- obviously one's mileage varies as I've heard about bars scanning licenses and if I encounte
Re: (Score:2)
I seriously don't understand the drive toward consolidating things to your phone -- which I don't always carry and is much bulkier and not nearly as water/sand/etc proof as my license, etc
My perspective is the opposite. While I may forget my wallet and I actively try not to carry any keys (I carry one key at a time, for the vehicle I'm currently driving, and don't use key rings; my house is never locked but it were I'd use a pin pad to unlock -- or someday an RF signal from my phone), I never, ever go anywhere without my phone. I think this is true for many, and nearly universal among the younger generation (I'm 52).
Especially as not everything will be able to be relocated to your phone, requiring one to also carry a wallet.
I disagree with this as well. Credit cards and my driver's license are the o
Re: (Score:1)
Re: (Score:3)
Thanks for the information. I'd like to offer a *much* simpler procedure:
1. The police officer requests your ID. 2. I hand him/her my physical driver's license.
You should read my whole post, including the paragraphs at the end about the privacy-enhancing capabilities of an electronic solution. Those don't come into play in a traffic stop, but they're a significant improvement in other contexts. I also recommend the ACLU blog post I linked.
Re: Nope (Score:3)
If you really want to promote privacy, how about convincing Google to stop being a privacy violating behemoth.
Re: (Score:2)
The track record of the tech community on implementing secure software/hardware, particularly in consumer products, is lacking.
Yes, this is my day job, figuring out how to get thousands of Android manufacturers to build things that are actually secure. There are some fundamental limits to what is even possible in consumer products, particularly if you include nation state actors in your threat model (which I do). And even when you get all of the manufacturers to do the right thing, you then have to worry about how to secure incredibly-complex, global supply chains.
This is all really, really hard. Note, however, that adding DLs an
Re: (Score:2)
So now you must pay a corporation to have an approved identity. So what happens when the corporation says, nahh fuck off, not identity for you fucker, you unperson. What do you unperson do, you can buy nothing, you can go nowhere and you are marked as unidentified where ever you go, NO CORPORATE APPROVAL for you non-person.
Fucking hell, you become a dog having to pay for your own registration tag, sorry not pay, rent you registration tag, which can be stripped from you at any time and of course needless to
Re: (Score:1)
Open Interface on tamper-resistant key storage (Score:2)
Re: (Score:1)
Re: Nope (Score:2)
Re: (Score:2)
The police officer requests your ID.
No way would I decide to tie the reliability of my phone to whether I'm on the hook for driving without a license. Sorry officer, I just crashed and my indestructible gorilla screen is in a million pieces. My battery died, phone broken, botched OTA induced boot loop, loaned to my sister...etc.
To provide some perspective on this something on the order of 100 million phones are damaged yearly.
No actual data about you is transferred via the QR code. Instead, what your phone provides over whichever channel you choose is its preferred communication medium: Wifi (Wifi Aware, to be precise) or Bluetooth, and what parameters the officer's phone should use. Also, a public ECDH key -- the public half of an ephemeral, just-generated key pair.
4. The officer's phone opens the appropriate wireless channel to your device, and sends a list of the data elements it's requesting, as well as an ephemeral ECDH public key. The request is encrypted with a session key derived from the exchanged ECDH keys.
I assume data from QR is used in the key exchange?
6. Your phone sends the data to the officer's phone, along with digital signatures, including one from the issuer. There's a lot of interesting crypto in here to ensure repudiability, that the protocol does not include any data that can be used to link presentations (unless the data elements transferred are unique, of course), and that you can present any subset of data elements without giving any hints about the rest of the data.
Crypto is merely a means of conveyance not itself a source of anyth
Re: (Score:2)
Google wants me to use android as ID so it can track everything I do.
Fuck that.
Google hates the Four Freedoms (Score:4, Insightful)
"All these features need to run on tamper-resistant hardware to protect the integrity of the application executables
I have the right to fix my software. I will not accept a device whose hardware stops that.
Re: (Score:2, Informative)
Indeed, so you're obviously not using any kind of cellphone because somewhere on that machine is software you can't change.
Re: (Score:1)
Almost nobody has a machine that doesn't have at least some unchangable/unauditable software on it.
It can be as simple as one or more of the embedded controllers in the hard drive or in the keyboard or mouse.
Re: (Score:2)
On the one hand, the software in my Game Boy compact video game system has been fully audited. It displays a logo representing the continuity of cartridge connection, checks the integrity of the executable header, and jumps to the program's entry point. The same can be said for a lot of 8-bit and 16-bit home computers, such as the Monitor ROM, Applesoft BASIC ROM, and Disk II ROM of an Apple II computer. On the other hand, I agree with you that "almost nobody" is willing to settle for the capability of 8-bi
Re:Google hates the Four Freedoms (Score:4, Interesting)
"All these features need to run on tamper-resistant hardware to protect the integrity of the application executables
I have the right to fix my software. I will not accept a device whose hardware stops that.
Actually, Google is leading an effort [opentitan.org] to make open tamper-resistant hardware possible -- hardware and software. Of course, if you choose to install your own software rather than the official images, then automakers and identity document issuers will not trust your device, so you won't be able to use these features. As a Google engineer who works on these things and cares deeply about the right to fully own my hardware, I wish there were a way that we could verify that custom software behaves correctly and convince others to trust it, but I think this is fundamentally impossible. The problem is that we have some use cases where the owner of the device may be the attacker. The best we can do, I think, is to ensure that (a) users can install custom firmware if they want and (b) by doing so they don't lose any functionality outside of those use cases where third parties need to trust that the device is secure from the user.
Re: (Score:2)
Of course, if you choose to install your own software rather than the official images, then automakers and identity document issuers will not trust your device, so you won't be able to use these features.
Official images are universally teaming with disrespectful malware and unreasonable limitations.
The problem is that we have some use cases where the owner of the device may be the attacker.
The best we can do, I think, is to ensure that (a) users can install custom firmware if they want and (b) by doing so they don't lose any functionality outside of those use cases where third parties need to trust that the device is secure from the user.
Thus little kids are denied from Pokemon go.
One note. (Score:2)
Smartphones have already obviated single-purpose gadgets like point-and-shoot cameras and MP3 players.
Reduced, but P&S usually have a better lens, and sometime just an MP3 is good for preventing abuse of what would be a multipurpose device.
Re: (Score:1)
I can clip my iPod shuffle between two buttons of the v-neck of my t-shirt because it's so small, weights next to nothing and has a built-in clip. I can't do the same with a smartphone.
Re: (Score:1)
One would think that with newer tech, smartphones could become smaller. Instead, the 'foldable' smartphones that I have seen use the folding tech to make them even bigger.
Re: (Score:2)
Considering that most people are moving to their mobile device being their primary "computer" for a lot of things, it kind of makes sense that they'd want more usable space.
Google (Score:4, Funny)
Google is the best company to do this. They have a proven track record of supporting their products for a very long time. I don't foresee them abandoning this particular project for many decades, which is the sort of time scale you need for things that take over such a large portion of peoples lives.
(Totally not satire)
Re: (Score:1)
Re: (Score:2)
I suggest a rename of the company: Gobble. As in "GOBBLE MORE DATA!!!"
who needs Bill Gates conspiracies? (Score:2)
No and hell no. (Score:2)
No on storing my car/home keys on my phone, no on most things in my wallet, including any links to my bank accounts.
Hell No on a driver's license, national ID and/or passport -- on anything that would require me to give my (presumably) *unlocked* phone to a LEO.
I'm happy to carry extra stuff around when needed.
Re: (Score:2)
Going to have to have two devices. One for "public" data, and one for "private" data.
Re: (Score:2)
One should unfortunately assume that all and any data you enter on a computerized device connected to the internet is public.
Fuck that shit, and fuck you, Google (Score:1)
Just hand over control of everything important in your life to Google (and Amazon and Facebook and Twitter and so on)! All the cool kids are doing it!
Yeah no fuck you sideways with a rusty COVID-infected chainsaw, Google. Over-reaching assholes.
Re: (Score:1)
Voltage and clock attacks (Score:1)
Most hardware will fail hard if you give it irregular voltage, or an irregular clock signal. This can be used to get into what would ordinarily be a "secure" enclave.
Re: (Score:2)
Re: (Score:2)
What about smartwatches? Having to pull out a phone is incovenient. And no keeping it in the pocket is not a good idea, it can be hacked by relay attacks or amplified retransmission.
You mean you need a step where the person has to tap the watch or the phone to agree to the protocol?
Can you imagine (Score:2)
Re: (Score:2)
Google doesn't cancel what makes them gobble more data or make their data more accurate. This scheme will allow them to link all your online stuff to your real identity. Believe me, it's never going to be cancelled, and even after Google's eventual shutdown (no company is immortal), it will be taken on by another company, with backwards compatibility and everything.
Why is it always tamper resistant hardware? (Score:4, Insightful)
Ever since the 1990s, curtained RAM, Palladium, and every DRM scheme afterwards, the focus is always on tamper resistant hardware. However, that's where most of the attacks do not come from except "evil maid" attacks.
Why not a focus on remote attacks, better authentication, safeguards against data exfiltration, privacy safeguards, and other valid threats? The attack surface of someone stealing someone's phone is relatively small. It is remote attacks that is the issue.
In general, tamper resistant hardware doesn't benefit the end user. It benefits a company. For example, there is no consumer gain from game consoles being so locked down. That is just to line the pockets of the console maker and game makers.
If Google was interested in something other than yet another incarnation of the TPM, they need to look into building a hypervisor into Android, and doing it right. Perhaps use the secure worlds functionality in ARM chips for something useful to the user:
1: It would be nice to allow Officer Friendly access to my license, insurance records, or e-papers, but not have to give him access to the entirety of my phone.
2: It would be nice to have work, home, and such, so a compromise in the "home phone" isn't going to cause work data to be exfiltrated.
3: It would be nice to have an actual backup mechanism in Android, on the app and app data basis.
4: More people want to have a full Linux userland in Android, so that should be something to consider.
I don't understand why Google wants to reinvent the TPM and Secure Enclave yet again, without giving thought to users not really wanting to hand an unlocked phone to strangers.
Re: (Score:3)
Because the purpose of tamper-resistant hardware is to make hardware tamper-resistant - from you, the user, that is. This is the very purpose of it. And the sole purpose.
Chase the Chuck Wagon (Score:2)
there is no consumer gain from game consoles being so locked down.
You must not have read about the Atari shock of 1983 and 1984, when toy store shelves were full of poorly balanced cash-ins for Atari 2600, obtained through fly-by-night distributors that promised refunds for unsold products only to go bankrupt months later. The modicum of quality testing that console makers do on licensed releases is ostensibly intended to prevent that.
So much sweet juicy pw0nage (Score:2)
some people overestimate the capabilities of iOS (Score:1)