Android R zou ondersteuning kunnen bieden voor het veilig opslaan van mobiele rijbewijzen op apparaten zoals de Google Pixel 2, Google Pixel 3 of Google Pixel 4.
Update 1 (6-3-19 om 20:44 ET): Meer details over de plannen van Google voor de IdentityCredential API zijn gedeeld door Shawn Willden, hoofd van het door Android hardware ondersteunde beveiligingsteam. Het artikel is aan het einde bijgewerkt met deze details. Het originele artikel volgt.
Het dragen van een portemonnee is voor mij minder noodzakelijk geworden sinds ik hem begon te gebruiken Google Pay om mijn creditcards te beheren, maar ik kan nog steeds nergens heen reizen zonder mijn rijbewijs. Ik ken een paar mensen die portemonnee-etuis gebruiken om de weinige kaarten in te bewaren moeten ga door met hun persoon, maar ik wacht op de dag waarop ik legaal naar Walmart kan rijden met alleen mijn telefoon bij me. Een digitaal rijbewijs biedt meerdere voordelen ten opzichte van de traditionele identiteitskaart. Je kunt hem niet kwijtraken, je kunt hem op afstand bijwerken zodat je niet in de rij hoeft te staan bij de RDW, je kunt hem op afstand wissen als je telefoon wordt gestolen, je hebt minder kans om je identiteit te achterhalen gestolen omdat u geen portemonnee met gemakkelijk toegankelijke informatie bij u hoeft te hebben, de kans kleiner is dat u uw telefoon thuis laat en u hem gemakkelijker ter sprake kunt brengen verzoek. Autoriteiten in de VS erkennen langzaamaan de voordelen van een mobiel rijbewijs. Daarom horen we elk jaar meer Amerikaanse staten de acceptatie ervan testen.
Inwoners van Louisiana kunnen bijvoorbeeld het Envoc-ontwikkeld LA-portemonnee app die is goedgekeurd door de wetshandhaving van LA voor licentieverificatie en LA's ATC voor alcohol- en tabakstransacties. Leeftijdsverificatie is vooral interessant omdat gebruikers de mobiele app kunnen beperken zodat alleen de noodzakelijke informatie wordt weergegeven aan een verkoper van alcohol of tabak. Elders, digitaal beveiligingsbedrijf Gemalto werkt samen met Colorado, Idaho, Maryland, Washington D.C. en Wyoming om proefprogramma's uit te voeren voordat ze hun digitale rijbewijsoplossing uitrollen. Tegelijkertijd is de Amerikaanse vereniging van beheerders van motorvoertuigen werkt aan het standaardiseren van deze nieuwe vorm van elektronische identificatie.
Er zijn echter ook nadelen aan het digitale rijbewijs. U heeft veel controle over wie uw fysieke ID te zien krijgt, maar u heeft minder controle over wie of wie Wat toegang heeft tot de gedigitaliseerde vorm ervan. U kunt uw telefoon of de app waarmee uw mobiele licentie wordt opgehaald, beveiligen met een wachtwoord of pincode, maar er bestaat altijd een kans dat uw telefoon en al zijn gegevens in gevaar komen. Bovendien moet u ervoor zorgen dat uw telefoon voldoende capaciteit heeft om Android te laten werken, zodat u de licentie kunt verkrijgen. Met de IdentityCredential-APIGoogle werkt eraan om beide problemen op te lossen. In een toekomstige versie van Android, wellicht Android R, zullen apparaten met de juiste hardware veilig kunnen worden opgeslagen identiteitskaarten, vooral digitale rijbewijzen, en u kunt er zelfs toegang toe krijgen als het apparaat niet voldoende stroom heeft Android opstarten.
IdentityCredential-API
Op het eerste gezicht lijkt de commit, ingediend door Shawn Willden, hoofd van Android's Hardware-backed Keystore Team, niet erg interessant. Als u echter de IdentityCredential- en IdentityCredentialStore-bestanden bekijkt, vindt u meerdere verwijzingen naar de soorten 'identiteitsgegevens' waarnaar Google verwijst. IdentityCredential maakt bijvoorbeeld gebruik van een protocol voor sleuteluitwisseling dat wordt gebruikt door de ISO18013-5 standaard voor mobiele rijbewijzen.” Bovendien wordt dit protocol gebruikt als “de basis voor het lopende ISO-werk andere gestandaardiseerde identiteitsreferentiesHoewel het onwaarschijnlijk is dat we binnenkort mobiele paspoorten zullen zien, is het duidelijk dat deze API bedoeld is voor meer dan alleen mobiele rijbewijzen.
Google gaat dieper in op de soorten ondertekeningssleutels die worden ondersteund door de IdentityCredential API. Er zijn twee soorten gegevensauthenticatie: statisch en dynamisch. Bij statische authenticatie gaat het om sleutels die zijn gemaakt door een uitgevende autoriteit, terwijl bij dynamische authenticatie om sleutels gaat die zijn gemaakt door de beveiligingshardware van het apparaat (zoals de Titaan M in de Pixel 3 en Pixel 3 XL.) Het voordeel van dynamische authenticatie is dat het voor een aanvaller moeilijker is om de beveiligde hardware in gevaar te brengen om de inloggegevens naar een ander apparaat te kopiëren. Bovendien maakt dynamische authenticatie het moeilijker om een bepaalde identificatie te koppelen aan de gegevens van een gebruiker.
Een Android-app kan een IdentityCredential aan een lezer presenteren door de gebruiker te vragen een draadloze verbinding via NFC te initiëren. Apps worden aanbevolen om deze transacties te bewaken door gebruikerstoestemming te vragen in de vorm van een dialoogvenster en/of wachtwoordbeveiliging.
Als een apparaat over de ondersteunde hardware beschikt, is de modus 'directe toegang' beschikbaar, zodat een IdentityCredential kan worden gepresenteerd, zelfs als er niet genoeg stroom is om Android draaiende te houden. Dit is alleen mogelijk als het apparaat discrete, beveiligde hardware heeft en voldoende stroom om die hardware te bedienen en de inloggegevens via NFC te delen. Apparaten zoals de Google Pixel 2 en Google Pixel 3 zouden in aanmerking moeten komen, aangezien beide apparaten dat hebben fraudebestendige beveiligingsmodules die gescheiden zijn van de hoofd-SoC.
Als het apparaat geen afzonderlijke, beveiligde CPU heeft, kan het nog steeds de IdentityCredential API ondersteunen, zij het zonder ondersteuning voor directe toegang. Als de referentieopslag alleen in software is geïmplementeerd, kan deze worden aangetast door een aanval op de kernel. Als de referentieopslag in de TEE is geïmplementeerd, kan deze worden aangetast door zijkanaalaanvallen op de CPU, zoals Meltdown en Spectre. Als het referentiearchief is geïmplementeerd in een afzonderlijke CPU, ingebed in hetzelfde pakket als het hoofdpakket CPU, het is bestand tegen fysieke hardwareaanvallen, maar kan niet van stroom worden voorzien zonder ook de hoofdstroom van stroom te voorzien CPU.
De gevoeligheid van het document zal bepalen of een of meer van deze implementaties van identiteitsreferentiesarchief zullen worden ondersteund. Ontwikkelaars kunnen de beveiligingscertificering van de implementatie van het identiteitsreferentiearchief controleren. Implementaties van identiteitsgegevensopslag kunnen niet-gecertificeerd zijn of een evaluatieborgingsniveau van 4 of hoger hebben. De EAL vertelt app-ontwikkelaars hoe veilig de implementatie is tegen mogelijke aanvallen.
Zoals ik al eerder zei, is het de bedoeling van Google dat deze API voor elk gestandaardiseerd documenttype wordt gebruikt, hoewel ze als voorbeeld ISO 18013 mobiele rijbewijzen vermelden. Het documenttype is nodig zodat de beveiligingshardware weet om welk type legitimatie het gaat de directe toegangsmodus moet worden ondersteund en apps moeten weten welk type document een lezer is verzoeken.
Dat is alle informatie die we tot nu toe hebben over deze nieuwe API. Omdat we zo dicht bij de release van de eerste Android Q Developer Preview zijn, denk ik niet dat het waarschijnlijk is dat we ondersteuning zullen zien voor het veilig opslaan van mobiele rijbewijzen in Android Q. Deze API zou echter klaar kunnen zijn tegen de tijd dat Android R in 2020 wordt uitgerold. De Google Pixel 2, Google Pixel 3 en de aankomende Google Pixel 4 zouden deze API moeten ondersteunen met directe toegangsmodus in Android R, dankzij de noodzakelijke discrete, veilige CPU. We laten het u weten als we meer informatie krijgen over wat Google van plan is met deze API te doen.
Update 1: Meer details over de IdentityCredential API
Shawn Willden, de auteur van de IdentityCredential API-commit, heeft aanvullende details over de API gedeeld in de opmerkingensecties. Hij beantwoordde een paar opmerkingen van gebruikers, die we hieronder zullen weergeven:
Gebruiker Munnimi verklaarde:
"En als de politie je telefoon pakt en naar de politieauto gaat, kunnen ze controleren wat er in de telefoon zit."
De heer Willden antwoordde:
"Dat is iets waar ik specifiek aan werk om het onmogelijk te maken. Het is de bedoeling om de stroom zo te structureren dat de agent uw telefoon niet nuttig kan afpakken. Het idee is dat je de NFC-tap uitvoert met de telefoon van de agent, vervolgens ontgrendelt met een vingerafdruk/wachtwoord, waarna je telefoon in de lockdown-modus gaat terwijl de gegevens worden overgedragen via Bluetooth/Wifi. De vergrendelingsmodus betekent dat vingerafdrukverificatie het apparaat niet ontgrendelt; er is een wachtwoord vereist. Dit is specifiek bedoeld om een beroep te doen op de bescherming van het vijfde amendement tegen zelfincriminatie, wat volgens sommige rechtbanken niet het geval is voorkomen dat de politie u dwingt om te ontgrendelen met biometrie, maar iedereen is het erover eens dat dit voorkomt dat ze u dwingen uw wachtwoord op te geven (althans in de VS).
Houd er rekening mee dat dit een ambitie is en geen verplichting. De manieren waarop we de stroom aan ontwikkelaars van identiteitsapps kunnen opdringen zijn beperkt, want als we te ver gaan, kunnen ze dat wel kies er gewoon voor om onze API's niet te gebruiken. Maar wat we wel kunnen doen, is het voor hen gemakkelijker maken om de juiste, privacygevoelige, ding."
Gebruiker RobboW verklaarde:
‘Dit is nutteloos in Australië. Wij zijn verplicht om tijdens het rijden ons fysieke, officiële rijbewijs bij ons te hebben. Een digitale kopie is gewoon rijp voor identiteitsdiefstal."
De heer Willden antwoordde:
"Australië neemt actief deel aan de ISO 18013-5-commissie en is zeer geïnteresseerd in het ondersteunen van mobiele rijbewijzen. Wat identiteitsdiefstal betreft, er zijn veel ingebouwde beveiligingen tegen identiteitsdiefstal. Het artikel noemt er enkele."
Gebruiker solitarios.lupus verklaarde:
‘Als je bedenkt wat deze site doet, denk ik dat iedereen hier weet dat dit niet zal werken en een groot veiligheidsprobleem is voor de rechtshandhaving. Om gemakkelijk te vervalsen, te vervalsen en te manipuleren."
De heer Willden antwoordde:
“Volledige vervalsing zal vrijwel onmogelijk zijn, omdat de gegevens allemaal digitaal ondertekend zijn. Het vervalsen van een legitimatiebewijs zou het vervalsen van de digitale handtekening vereisen, wat ofwel een radicale breuk met het relevante vereist cryptografie (die TLS en vrijwel al het andere zou breken) of anders de ondertekening van de uitgevende autoriteit zou stelen sleutels. Zelfs wijziging, door enkele ondertekende gegevenselementen uit de ene DL te halen (bijvoorbeeld een geboortedatum waaruit blijkt dat u ouder bent dan 21) en enkele uit een andere (bijvoorbeeld uw echte foto) zal onmogelijk zijn, omdat de ondertekening het hele document bestrijkt en alle elementen samenbindt."
Gebruikersmerk vermeld:
"Als een fotokopie nooit geldig was als identiteitsbewijs, waarom maakt het dan een verschil om aan de telefoon te zijn? Zelfs als Google belooft het veilig te maken, hoe kan dat dan voorkomen dat iemand een nep-applicatie laat zien?
Maar zelfs als daar geen antwoorden op zijn, denk ik nog steeds dat het een goede zaak is om de redenen die in dit artikel worden gegeven. Ik zou het leuk vinden voor paspoorten - niet noodzakelijkerwijs voor reizen, maar voor andere gelegenheden waarbij een identiteitsbewijs nodig is (ik rijd niet, dus mijn paspoort is mijn enige identiteitsbewijs).
Natuurlijk zou ik ook liever hebben dat Groot-Brittannië niet zou veranderen in een ‘papieren alstublieft’-maatschappij, waar je in sommige gevallen zelfs alleen maar een paspoort moet laten scannen om naar een pub te gaan...’
De heer Willden antwoordde:
‘Digitale handtekeningen zullen het veilig maken. U kunt een nepapplicatie hebben, maar deze kan geen correct ondertekende gegevens produceren.
Paspoorten zijn trouwens ook zeer belangrijk voor dit werk. Rijbewijzen vormen het uitgangspunt, maar de protocollen en infrastructuur worden zorgvuldig ontworpen om een breed scala aan identiteitsgegevens te ondersteunen, met name paspoorten. Natuurlijk zullen we de ICAO moeten overtuigen om deze aanpak te volgen, maar ik denk dat dat zeer waarschijnlijk is."
Met dank aan XDA erkende ontwikkelaar luca020400 voor de fooi!