Az Android R támogathatja a mobil jogosítványok biztonságos tárolását olyan eszközökön, mint a Google Pixel 2, Google Pixel 3 vagy Google Pixel 4.
1. frissítés (2019.03.06., 20:44 ET): Shawn Willden, az Android hardverrel támogatott biztonsági csapatának vezetője osztott meg további részleteket a Google IdentityCredential API-val kapcsolatos terveiről. A cikk a végén ezekkel a részletekkel frissült. Az eredeti cikk következik.
A pénztárca cipelése kevésbé vált szükségessé számomra, mióta elkezdtem használni Google Pay hogy kezeljem a hitelkártyáimat, de továbbra sem tudok jogosítvány nélkül utazni sehova. Ismerek néhány embert, akik pénztárcatokokban tárolják azt a kevés kártyát kell vigyék tovább a személyüket, de várom a napot, amikor legálisan behajthatok a Walmartba, csak a telefonom van rajtam. A digitális jogosítvány számos előnnyel jár a hagyományos személyi igazolvánnyal szemben. Nem veszítheti el, távolról frissítheti, hogy ne kelljen sorban állnia a DMV-nél, távolról törölheti, ha ellopják a telefont, kevésbé valószínű, hogy megkapja a személyazonosságát ellopják, mivel nem kell magánál cipelnie a könnyen hozzáférhető információkat tartalmazó pénztárcát, kevésbé valószínű, hogy otthon hagyja a telefont, és könnyebben tudja előhozni kérés. Az Egyesült Államok hatóságai lassan felismerik a mobil jogosítvány előnyeit, ezért halljuk, hogy évről évre egyre több amerikai állam teszteli ennek elfogadását.
Például Louisiana lakosai letölthetik a Envoc-fejlett LA Wallet alkalmazás, amelyet Los Angeles bűnüldöző szervei jóváhagytak az engedélyek ellenőrzésére és LA ATC-je alkohol- és dohányügyletekre. Az életkor ellenőrzése különösen érdekes, mivel a felhasználók korlátozhatják a mobilalkalmazást úgy, hogy csak a szükséges információkat jelenítsék meg az alkohol- vagy dohányárusok számára. Máshol digitális biztonsági cég Gemalto partnere a Colorado, Idaho, Maryland, Washington D.C. és Wyoming, hogy kísérleti programokat futtasson a digitális jogosítvány-megoldás bevezetése előtt. Ugyanakkor a Amerikai Gépjármű-adminisztrátorok Szövetsége az elektronikus azonosítás ezen új formájának szabványosításán dolgozik.
A digitális jogosítványnak azonban vannak árnyoldalai is. Nagymértékben szabályozhatja, hogy ki láthatja személyi azonosítóját, de kevésbé van befolyása arra, hogy ki vagy mit hozzáfér a digitalizált formájához. Jelszóval vagy PIN-kóddal védheti telefonját vagy a mobillicencet lekérő alkalmazást, de mindig fennáll annak a lehetősége, hogy telefonja és annak összes adata veszélybe kerülhet. Ráadásul meg kell győződnie arról, hogy a telefonnak elegendő leve van az Android futtatásához, hogy felvehesse a licencet. A... val IdentityCredential API, a Google mindkét probléma megoldásán dolgozik. Az Android jövőbeli verziójában, talán az Android R-ben, a megfelelő hardverrel rendelkező eszközök biztonságosan tárolhatók lesznek azonosító kártyákat, különösen a digitális jogosítványokat, és még akkor is hozzáférhet hozzájuk, ha a készüléknek nincs elég áramellátása indítsa el az Androidot.
IdentityCredential API
Első pillantásra a kötelezettségvállalás, amelyet Shawn Willden, az Android hardverrel támogatott Keystore csapatának vezetője nyújtott be, nem tűnik túl érdekesnek. Ha azonban megtekinti az IdentityCredential és az IdentityCredentialStore fájlokat, akkor több hivatkozást is talál arra vonatkozóan, hogy a Google milyen típusú „azonosító hitelesítő adatokra” hivatkozik. Például az IdentityCredential a kulcscserék protokollját használja, amelyet a " ISO18013-5 szabvány a mobil vezetői engedélyekhez." Továbbá ezt a protokollt használják „alapjaként a folyamatban lévő ISO-munkának egyéb szabványosított személyazonossági hitelesítő adatokBár nem valószínű, hogy hamarosan megjelennek a mobil útlevelek, egyértelmű, hogy ezt az API-t nem csak mobil vezetői engedélyekre szánják.
Mélyebbre ásva a Google kidolgozza az IdentityCredential API által támogatott aláíró kulcsok típusait. Kétféle adathitelesítés létezik: statikus és dinamikus. A statikus hitelesítés a kibocsátó hatóság által létrehozott kulcsokat foglalja magában, míg a dinamikus hitelesítés az eszköz biztonsági hardvere által létrehozott kulcsokat (pl. Titan M a Pixel 3 és a Pixel 3 XL készülékekben.) A dinamikus hitelesítés előnye, hogy a támadónak nehezebb feltörni a biztonságos hardvert, hogy átmásolja a hitelesítő adatokat egy másik eszközre. Ezenkívül a dinamikus hitelesítés megnehezíti egy adott hitelesítő adat és a felhasználó adatainak összekapcsolását.
Az Android-alkalmazások bemutathatnak egy IdentityCredential-t az olvasónak, ha megkérik a felhasználót, hogy kezdeményezzen vezeték nélküli kapcsolatot NFC-n keresztül. Javasoljuk, hogy az alkalmazások úgy védjék ezeket a tranzakciókat, hogy felhasználói engedélyt kérnek párbeszédpanel és/vagy jelszavas védelem formájában.
Ha egy eszköz rendelkezik a támogatott hardverrel, a „közvetlen hozzáférés” mód elérhető lesz, hogy lehetővé tegye az IdentityCredential megjelenítését még akkor is, ha nincs elegendő energia az Android futtatásához. Ez csak akkor lehetséges, ha az eszköz különálló biztonságos hardverrel és elegendő energiával rendelkezik a hardver működtetéséhez a hitelesítő adatok NFC-n keresztüli megosztásához. Az olyan eszközöknek, mint a Google Pixel 2 és a Google Pixel 3 megfelelőnek kell lenniük, mivel mindkét eszköz rendelkezik hamisításbiztos biztonsági modulok amelyek elkülönülnek a fő SoC-tól.
Ha az eszköz nem rendelkezik különálló biztonságos CPU-val, akkor is támogatja az IdentityCredential API-t, bár közvetlen hozzáférési támogatás nélkül. Ha a hitelesítőadat-tárat csak szoftverben valósítják meg, akkor azt a kernel elleni támadás veszélyeztetheti. Ha a hitelesítőadat-tároló implementálva van a TEE-ben, akkor azt a CPU-t érő oldalcsatornás támadások veszélyeztethetik, mint pl. Meltdown és Spectre. Ha a hitelesítőadat-tároló egy külön CPU-ban van megvalósítva, amely ugyanabba a csomagba van beágyazva, mint a fő CPU, ellenáll a fizikai hardveres támadásoknak, de nem táplálható a fő tápellátása nélkül CPU.
A dokumentum érzékenysége határozza meg, hogy az identitás-hitelesítőadat-tároló megvalósítások közül egy vagy több támogatott lesz-e. A fejlesztők ellenőrizhetik az identitás hitelesítőadat-tároló megvalósításának biztonsági tanúsítványát. Az identitás-hitelesítőadat-tároló megvalósításai lehetnek tanúsítatlanok, vagy 4-es vagy magasabb értékelési garanciával rendelkeznek. Az EAL tájékoztatja az alkalmazásfejlesztőket, hogy mennyire biztonságos a megvalósítás a lehetséges támadásokkal szemben.
Ahogy korábban említettem, a Google ezt az API-t bármilyen szabványos dokumentumtípushoz kívánja használni, bár példaként felsorolják az ISO 18013 szerinti mobil vezetői engedélyeket. A dokumentum típusa azért szükséges, hogy a biztonsági hardver tudja, milyen típusú hitelesítő adatról van szó A közvetlen hozzáférési módot támogatni kell, és lehetővé kell tenni az alkalmazások számára, hogy tudják, milyen típusú dokumentum az olvasó kérve.
Eddig ennyi információnk van az új API-ról. Mivel nagyon közel járunk az első Android Q Developer Preview megjelenéséhez, nem tartom valószínűnek, hogy támogatást fogunk látni a mobil jogosítványok biztonságos tárolására az Android Q rendszerben. Ez az API azonban készen állhat az Android R 2020-as megjelenésére. A Google Pixel 2-nek, a Google Pixel 3-nak és a közelgő Google Pixel 4-nek támogatnia kell ezt az API-t közvetlen hozzáférési móddal az Android R-ben, köszönhetően a szükséges különálló biztonságos CPU-nak. Értesíteni fogjuk Önt, ha további információt kapunk arról, hogy a Google mit szándékozik tenni ezzel az API-val.
1. frissítés: További részletek az IdentityCredential API-ról
Shawn Willden, az IdentityCredential API véglegesítés szerzője további részleteket osztott meg az API-val kapcsolatban a megjegyzés szakaszokban. Válaszolt néhány felhasználói megjegyzésre, amelyeket az alábbiakban reprodukálunk:
Munnimi felhasználó kijelentette:
"És amikor a rendőrök elveszik a telefont, és a rendőrautóhoz mennek, ellenőrizhetik, mi van a telefonban."
Mr. Willden így válaszolt:
„Kifejezetten azon dolgozom, hogy lehetetlenné tegyem. A cél az, hogy az áramlást úgy strukturálják, hogy a tiszt ne tudja hasznosan elvenni a telefonját. Az ötlet az, hogy megcsinálod az NFC koppintást a tiszt telefonjával, majd ujjlenyomattal/jelszóval feloldod a zárolást, majd a telefonod zárolási módba lép, miközben az adatátvitel bluetooth-on/Wifi-n keresztül történik. A zárolási mód azt jelenti, hogy az ujjlenyomat-hitelesítés nem oldja fel, jelszó szükséges. Ez kifejezetten az ötödik módosítás önbíráskodás elleni védelem igénybevételének kényszerítése, amelyről egyes bíróságok megállapították, hogy nem megakadályozza, hogy a rendőrök biometrikus adatokkal kényszerítsék a zárolás feloldását, de mindenki egyetért azzal, hogy megakadályozza, hogy a jelszava megadására kényszerítsenek (legalábbis Az Egyesült Államok).
Vegye figyelembe, hogy ez egy törekvés, nem pedig elkötelezettség. Korlátozottak azok a módok, amelyekkel rákényszeríthetjük az adatfolyamot az identitásalkalmazás-fejlesztőkre, mert ha túl messzire megyünk, megtehetik csak döntse el, hogy nem használja API-jainkat. De azt tehetjük, hogy megkönnyítjük számukra a helyes, a magánéletre érzékeny, dolog."
RobboW felhasználó kijelentette:
„Ez haszontalan Ausztráliában. Fizikai, hivatalos jogosítványunknak magunkkal kell lennünk vezetés közben. A digitális másolat megérett a személyazonosság-lopásra."
Mr. Willden így válaszolt:
„Ausztrália aktív résztvevője az ISO 18013-5 bizottságnak, és nagyon érdeklődik a mobil vezetői engedélyek támogatása iránt. Ami a személyazonosság-lopást illeti, számos védelem létezik az ellen, hogy beépüljenek. A cikk megemlít néhányat."
A solitarios.lupus felhasználó kijelentette:
„Ha figyelembe vesszük, hogy mit csinál ez az oldal, azt hiszem, itt mindenki tudja, hogy ez nem fog működni, és óriási biztonsági probléma a bűnüldözés számára. Könnyen hamisított, hamisított és manipulálható."
Mr. Willden így válaszolt:
„A nyílt hamisítás szinte lehetetlen lesz, mert az adatok mind digitálisan alá vannak írva. A hitelesítő adatok meghamisításához a digitális aláírás meghamisítására lenne szükség, amihez vagy az érintett gyökeres megszakítására van szükség kriptográfia (ami megszakítaná a TLS-t és nagyjából minden mást), vagy a kibocsátó hatóság aláírásának ellopása kulcsok. Akár módosítás is, ha az egyik DL-ből veszünk alá néhány aláírt adatelemet (pl. születési dátum, amely azt mutatja, hogy elmúlt 21 éves), és néhányat egy másik DL-ből (pl. az Ön valódi fényképe) lehetetlen lesz, mert az aláírás a teljes dokumentumot lefedi, minden elemet egybeköt."
Felhasználói jelzés a következő:
"Ha a fénymásolat soha nem volt érvényes személyazonosító igazolványra, miért számít a telefonálás? Még ha a Google meg is ígéri, hogy biztonságossá teszi, ez hogyan akadályozza meg, hogy valaki hamis alkalmazást mutasson fel?
Mégis, még ha erre nincs is válasz, akkor is jó dolognak tartom, a cikkben leírt okok miatt. Útlevélhez szeretném - nem feltétlenül utazáshoz, hanem más alkalmakkor, ahol személyi igazolvány szükséges (nem vezetek, így az útlevél az egyetlen személyi igazolványom).
Természetesen azt is jobban tenném, ha az Egyesült Királyság nem válna "papírokat kérek" társadalommá, ahol bizonyos esetekben még csak azért is, hogy kocsmába menjen, útlevelet kell szkennelni..."
Mr. Willden így válaszolt:
„A digitális aláírások biztonságossá teszik. Lehet hamis alkalmazás, de nem tud megfelelően aláírt adatokat előállítani.
Az útlevelek is nagyon fontosak ehhez a munkához, BTW. A vezetői engedélyek jelentik a kiindulópontot, de a protokollokat és az infrastruktúrát gondosan úgy alakítják ki, hogy támogassák a személyazonossági hitelesítő adatok széles körét, különösen az útleveleket. Természetesen meg kell győznünk az ICAO-t a megközelítés elfogadásáról, de ezt nagyon valószínűnek tartom."
Köszönet az XDA elismert fejlesztőjének luca020400 a tippért!