Android R voisi tukea mobiiliajokorttien turvallista tallentamista laitteisiin, kuten Google Pixel 2, Google Pixel 3 tai Google Pixel 4.
Päivitys 1 (6.3.2019 klo 20.44 ET): Shawn Willden, Android-laitteiston tukeman tietoturvatiimin johtaja, on jakanut lisätietoja Googlen IdentityCredential API: n suunnitelmista. Artikkeli on päivitetty näillä tiedoilla lopussa. Alkuperäinen artikkeli seuraa.
Lompakon kantamisesta on tullut minulle vähemmän tarpeellista käytön aloittamisen jälkeen Google Pay hallita luottokorttejani, mutta en silti voi matkustaa minnekään ilman ajokorttiani. Tunnen muutamia ihmisiä, jotka käyttävät lompakkokoteloita pitämään niitä muutamia kortteja on pakko jatkaa heidän henkilöllisyyttään, mutta odotan päivää, jolloin voin laillisesti ajaa Walmartiin puhelimeni päällä. Digitaalinen ajokortti tarjoaa monia etuja perinteiseen henkilökorttiin verrattuna. Et voi kadottaa sitä, voit päivittää sen etänä, jotta sinun ei tarvitse seistä jonossa DMV: ssä, voit pyyhkiä sen etänä, jos puhelimesi varastetaan, et todennäköisesti saa henkilöllisyyttäsi varastetaan, koska sinun ei tarvitse kantaa lompakkoa, jossa on helposti saatavilla olevia tietoja, et todennäköisesti jätä puhelinta kotiin ja sinun on helpompi tuoda se esille pyyntö. Viranomaiset kaikkialla Yhdysvalloissa ovat vähitellen ymmärtämässä mobiiliajokortin edut, minkä vuoksi kuulemme yhä useamman Yhdysvaltain osavaltion testaavan niiden hyväksymistä joka vuosi.
Esimerkiksi Louisianan asukkaat voivat ladata Envoc-kehitetty LA lompakko sovellus, jonka LA: n lainvalvontaviranomaiset ovat hyväksyneet lisenssin tarkistamista varten ja LA: n ATC alkoholi- ja tupakkakaupoissa. Iän vahvistaminen on erityisen kiinnostavaa, koska käyttäjät voivat rajoittaa mobiilisovelluksen näyttämään vain tarpeelliset tiedot alkoholin tai tupakan myyjälle. Muualla digitaalisen turvallisuuden yritys Gemalto tekee yhteistyötä Coloradon, Idahon, Marylandin, Washington D.C: n ja Wyomingin kanssa pilottiohjelmien toteuttamiseksi ennen digitaalisen ajokorttiratkaisun käyttöönottoa. Samaan aikaan, American Association of Motor Vehicle Administrators työskentelee standardoidakseen tämän uuden sähköisen tunnistamisen muodon.
Digitaalisessa ajokortissa on kuitenkin huonoja puolia. Voit hallita paljon sitä, kuka näkee fyysisen tunnuksesi, mutta sinulla on vähemmän hallintaa siihen, kuka tai kuka mitä on pääsy digitoituun muotoonsa. Voit suojata puhelimesi tai mobiililisenssin nostavan sovelluksen salasanalla tai PIN-koodilla, mutta aina on olemassa mahdollisuus, että puhelimesi ja kaikki sen tiedot voivat vaarantua. Lisäksi sinun on varmistettava, että puhelimessasi on tarpeeksi mehua Androidin pitämiseen käynnissä, jotta voit nostaa lisenssin. Kanssa IdentityCredential API, Google pyrkii ratkaisemaan nämä molemmat ongelmat. Androidin tulevassa versiossa, ehkä Android R: ssä, oikealla laitteistolla varustetut laitteet voidaan tallentaa turvallisesti henkilökortit, erityisesti digitaaliset ajokortit, ja jopa käyttää niitä, kun laitteessa ei ole tarpeeksi virtaa käynnistä Android.
IdentityCredential API
Ensi silmäyksellä Androidin hardware-tuetun Keystore Teamin johtajan Shawn Willdenin lähettämä sitoumus ei vaikuta kovin mielenkiintoiselta. Jos kuitenkin tarkastelet IdentityCredential- ja IdentityCredentialStore-tiedostoja, löydät useita viittauksia siihen, minkä tyyppisiin "identiteettitunnistetietoihin" Google viittaa. Esimerkiksi IdentityCredential käyttää avainten vaihtoprotokollaa, jota "käyttää ISO18013-5 standardi liikkuville ajokorteille." Lisäksi tätä protokollaa käytetään "perustana jatkuvalle ISO-työlle muut standardoidut henkilöllisyystodistukset." Vaikka on epätodennäköistä, että näemme mobiilipassit pian, on selvää, että tämä API on tarkoitettu muuhunkin kuin vain mobiiliajokorteihin.
Google tutkii tarkemmin IdentityCredential API: n tukemia allekirjoitusavaimia. Tietojen todennusta on kahdenlaisia: staattinen ja dynaaminen. Staattinen todennus sisältää avaimia, jotka on luonut myöntävä viranomainen, kun taas dynaaminen todennus sisältää avaimia, jotka ovat luoneet laitteen suojauslaitteisto (esim. Titan M Pixel 3:ssa ja Pixel 3 XL: ssä.) Dynaamisen todennuksen etuna on, että hyökkääjän on vaikeampi vaarantaa suojattua laitteistoa kopioidakseen tunnistetiedot toiseen laitteeseen. Lisäksi dynaaminen todennus vaikeuttaa tietyn tunnistetietojen yhdistämistä käyttäjän tietoihin.
Android-sovellus voi esittää IdentityCredential-tunnuksen lukijalle pyytämällä käyttäjää muodostamaan langattoman yhteyden NFC: n kautta. Sovelluksia suositellaan suojaamaan nämä tapahtumat pyytämällä käyttäjältä lupa valintaikkunan ja/tai salasanasuojauksen muodossa.
Jos laitteessa on tuettu laitteisto, "suora pääsy" -tila on käytettävissä, jotta IdentityCredential voidaan esittää, vaikka virta ei riittäisi pitämään Androidin käynnissä. Tämä on mahdollista vain, jos laitteessa on erillinen suojattu laitteisto ja tarpeeksi tehoa käyttääkseen kyseistä laitteistoa valtuustietojen jakamiseen NFC: n kautta. Google Pixel 2:n ja Google Pixel 3:n kaltaisten laitteiden pitäisi täyttää ehdot, koska molemmat laitteet ovat peukaloinnin kestävät turvamoduulit jotka ovat erillään pääjärjestelmästä.
Jos laitteessa ei ole erillistä suojattua suoritinta, se voi silti tukea IdentityCredential API: ta, vaikkakin ilman suoran pääsyn tukea. Jos valtuustietosäilö on toteutettu vain ohjelmistossa, se voi vaarantua ytimen vastaisella hyökkäyksellä. Jos tunnistetietosäilö on toteutettu TEE: ssä, se voi vaarantua suorittimen sivukanavahyökkäyksillä, kuten esim. Meltdown ja Spectre. Jos tunnistetietovarasto on toteutettu erillisessä CPU: ssa, joka on upotettu samaan pakettiin kuin pää CPU, se kestää fyysisiä laitteistohyökkäyksiä, mutta sitä ei voi käyttää ilman myös päävirtalähdettä PROSESSORI.
Asiakirjan herkkyys määrittää, tuetaanko yhtä tai useampaa näistä tunnistetietojen säilytystoteutuksista. Kehittäjät voivat tarkistaa tunnistetietosäilön toteutuksen suojaussertifikaatin. Tunnistetietosäilön toteutukset voivat olla sertifioimattomia tai niillä voi olla arvioinnin varmuustaso 4 tai korkeampi. EAL kertoo sovellusten kehittäjille, kuinka suojattu toteutus on mahdollisia hyökkäyksiä vastaan.
Kuten aiemmin mainitsin, Google aikoo käyttää tätä sovellusliittymää mille tahansa standardoidulle asiakirjatyypille, vaikka he listaavatkin esimerkkinä ISO 18013 -mobiiliajokortit. Asiakirjan tyyppi on välttämätön, jotta suojauslaitteisto tietää, minkä tyyppisestä tunnistetiedosta on kyse suorakäyttötilaa tulisi tukea, ja jotta sovellukset voivat tietää, minkä tyyppinen asiakirja lukija on pyytää.
Siinä on kaikki tiedot, jotka meillä on tähän mennessä tästä uudesta API: sta. Koska olemme niin lähellä ensimmäisen Android Q Developer Preview -version julkaisua, en usko, että tulemme näkemään tukea mobiiliajokorttien turvalliselle tallentamiselle Android Q: ssa. Tämä API saattaa kuitenkin olla valmis Android R: n julkaisuun mennessä vuonna 2020. Google Pixel 2:n, Google Pixel 3:n ja tulevan Google Pixel 4:n pitäisi tukea tätä sovellusliittymää suorakäyttötilassa Android R: ssä, koska niillä on tarvittava erillinen suojattu prosessori. Ilmoitamme sinulle, jos saamme lisätietoja siitä, mitä Google aikoo tehdä tällä sovellusliittymällä.
Päivitys 1: Lisätietoja IdentityCredential API: sta
Shawn Willden, IdentityCredential API -sitoumuksen kirjoittaja, jakoi lisätietoja API: sta kommenttiosioissa. Hän vastasi muutamiin käyttäjien kommentteihin, jotka toistetaan alla:
Käyttäjä Munnimi sanoi:
"Ja kun poliisi ottaa puhelimesi ja menee poliisiautoon, he voivat tarkistaa, mitä puhelimessa on."
Mr. Willden vastasi:
"Se on asia, jonka teen nimenomaan tehdäkseni mahdottomaksi. Tarkoituksena on jäsentää kulku niin, että virkailija ei voi ottaa puhelintasi hyödyllisesti. Ajatuksena on, että teet NFC-napautuksen poliisin puhelimella, avaat lukituksen sormenjäljellä/salasanalla, sitten puhelimesi menee lukitustilaan, kun tietoja siirretään Bluetoothin/Wifin kautta. Lukitustila tarkoittaa, että sormenjälkitunnistus ei avaa lukitusta, vaan salasana vaaditaan. Tämä on nimenomaan pakottaa vetoamaan viidennen tarkistuksen suojaan itsesyytökseltä, jonka jotkut tuomioistuimet ovat havainneet estää poliisia pakottamasta sinua avaamaan lukitusta biometrisilla tiedoilla, mutta kaikki ovat samaa mieltä estää heitä pakottamasta sinua antamaan salasanaasi (ainakin Yhdysvallat).
Huomaa, että se on toive, ei sitoutuminen. Tapa, jolla voimme pakottaa virtauksen identiteettisovellusten kehittäjiin, on rajallinen, koska jos menemme liian pitkälle, he voivat vain päätä olla käyttämättä sovellusliittymiämme. Mutta se, mitä voimme tehdä, on helpottaa heidän toimiaan oikein, yksityisyyttä kunnioittaen, asia."
Käyttäjä RobboW sanoi:
"Tämä on turhaa Australiassa. Meillä on oltava fyysinen, virallinen ajokortti mukana ajon aikana. Digitaalinen kopio on juuri kypsä identiteettivarkauksille."
Mr. Willden vastasi:
"Australia on aktiivinen osallistuja ISO 18013-5 -komiteaan ja on erittäin kiinnostunut tukemaan liikkuvia ajokortteja. Mitä tulee identiteettivarkauksiin, sitä vastaan on olemassa monia suojauksia. Artikkelissa mainitaan joitakin niistä."
Käyttäjä solitarios.lupus sanoi:
"Kun otetaan huomioon, mitä tämä sivusto tekee, uskon, että kaikki täällä tietävät, että tämä ei toimi, ja se on valtava turvallisuusongelma lainvalvontaviranomaisille. Helposti väärennetty, väärennetty ja manipuloitava."
Mr. Willden vastasi:
"Suora väärentäminen tulee olemaan täysin mahdotonta, koska kaikki tiedot on digitaalisesti allekirjoitettu. Valtuustietojen väärentäminen vaatisi digitaalisen allekirjoituksen väärentämistä, mikä joko edellyttää asiaankuuluvan radikaalin katkaisun salaus (joka rikkoisi TLS: n ja melkein kaiken muun) tai muuten varastaisi myöntävän viranomaisen allekirjoituksen avaimet. Jopa muutos ottamalla jotkin allekirjoitetut tietoelementit yhdestä DL: stä (esim. syntymäaika, joka osoittaa, että olet yli 21-vuotias) ja osa toisesta (esim. oikea valokuvasi) on mahdotonta, koska allekirjoitus kattaa koko asiakirjan ja sitoo kaikki elementit yhteen."
Käyttäjämerkki totesi:
"Jos valokopio ei koskaan kelvannut henkilöllisyystodistuksessa, miksi puhelimessa oleminen vaikuttaa? Vaikka Google lupaa tehdä sen turvalliseksi, kuinka se estää ketään näyttämästä väärennettyä sovellusta?
Silti, vaikka siihen ei olisikaan vastauksia, mielestäni se on silti hyvä asia tässä artikkelissa esitetyistä syistä. Haluaisin sen passeihin - ei välttämättä matkustamiseen, vaan muihin tilanteisiin, joissa tarvitaan henkilöllisyystodistus (en aja autoa, joten passini on ainoa henkilöllisyystodistus).
Tietysti olisin myös mieluummin, jos Iso-Britannia ei muuttuisi "papers please" -yhteiskunnaksi, jossa joudut skannaamaan passin jopa pubissa käymiseen joissain tapauksissa..."
Mr. Willden vastasi:
"Digitaalinen allekirjoitus tekee siitä turvallisen. Sinulla voi olla väärennetty sovellus, mutta se ei voi tuottaa kunnolla allekirjoitettuja tietoja.
Passit ovat myös erittäin soveltuvia tähän työhön, BTW. Ajokortit ovat lähtökohta, mutta protokollat ja infrastruktuuri suunnitellaan huolellisesti tukemaan monenlaisia henkilöllisyystodistuksia, erityisesti passeja. Tietenkin meidän on saatava ICAO omaksumaan lähestymistapa, mutta mielestäni se on hyvin todennäköistä."
Kiitos XDA Recognized Developer luca020400 vinkkiä varten!