Tänapäeval on meie mobiilseadmed praktiliselt päevik, kuhu salvestame kõike: intiimsetest fotodest kuni krediitkaardiandmeteni. Seetõttu ei saa me turvalisust juhuse hooleks jätta. Tundlike andmete kaitsmisel Androidis on Android Keystore Systemist saanud peamine tööriist pahatahtlike isikute krüptograafiliste võtmete varastamise takistamiseks, muutes selle Androidi turvalisuse alustalaks.
Põhimõtteliselt toimib see süsteem nagu digitaalne seif. Selle asemel, et võtmeid telefoni salvestusruumis lihtsate tekstifailidena salvestada (mis oleks turvakatastroof), lukustab see need turvalisse konteinerisse . Mis kõige parem, kui võti on sees, saab seda kasutada asjade krüpteerimiseks või allkirjastamiseks, kuid seda ei saa seadmest kunagi kätte , isegi mitte siis, kui operatsioonisüsteem on rikutud.
Kuidas turvalisus süsteemi keskmes töötab?
Võtmehoidla ei sega asju ja kaitseb võtmeandmeid kahel väga selgel viisil. Esiteks takistab see seadmevälistel isikutel võtmeandmeid varastada, kuna see blokeerib nende väljavõtmise rakendusprotsessidest. Teiseks tagab see, et isegi kui kellelgi õnnestub süsteemile juurde pääseda, ei saa ta võtit kasutada milleks iganes soovib; rakendused peavad määratlema volitatud kasutusviisid , mida süsteem rangelt jõustab.
Selle tõeliselt töökindlaks muutmiseks tugineb Android riistvarale. Põhiandmed ei läbi rakenduse protsesse; kui teil on vaja toimingut teha, saadetakse andmed spetsiaalsele süsteemiprotsessile . Lisaks, kui telefon on kaasaegne, on võtmed lingitud usaldusväärse täitmiskeskkonnaga (TEE) või turvalise elemendiga (SE). Kui teil on StrongBoxiga seade , viiakse turvalisus järgmisele tasemele, kuna sellel moodulil on oma protsessor, turvaline salvestusruum ja reaalne juhuslike arvude generaator, mis muudab selle vastupidavaks isegi füüsilistele rünnakutele.
Selleks, et teha kindlaks, kas võti on riistvaraliselt kaitstud, saavad arendajad Android 10-s ja uuemates versioonides kasutada funktsiooni `getSecurityLevel()` . Kui tulemuseks on `TRUSTED_ENVIRONMENT` või `STRONGBOX` , võime olla kindlad, et võti asub põhiprotsessorist eraldatud piirkonnas.
Juurdepääsu kontroll ja kasutusload
Selle süsteemi üks parimaid omadusi on see, et saate igale võtmele loomisel määrata "reeglid". Need reeglid on muutumatud; kui need on määratud, ei saa neid enam muuta . Näiteks saate piirata võtme toimimist ainult teatud algoritmidega , näiteks AES või RSA, või määrata täpse ajaraami, mille jooksul võti kehtib.
Aga kõige võimsam asi on see, kasutaja autentimineSaate võtme konfigureerida nii, et see töötaks ainult siis, kui kasutaja on hiljuti oma PIN-koodi, mustri või muu abil autentinud. biomeetria (sõrmejälg või näojälg)), arvestades, et 2D vs 3D näo avamine See pakub erinevaid kaitsetasemeid. Saadaval on kaks režiimi: üks, mis autoriseerib kõik võtmed teatud ajaks pärast autentimist, ja teine, rangem, kus iga krüptooperatsioon peab olema individuaalselt volitatud BiometricPrompt.
Võtmehoidja vs Androidi võtmehoidja pakkuja
Mõnikord võite mõelda, millist valida. KeyChain API on ideaalne valik, kui vajate süsteemiüleseid volitusi. Siin valib kasutaja süsteemiliidese kaudu, milliseid volitusi ta soovib rakendusega jagada. See on väga kasulik volituste puhul, mida jagatakse mitme rakenduse vahel mobiilseadme omaniku selgesõnalisel nõusolekul.
Teiselt poolt Androidi võtmehoidla pakkuja See on loodud nii, et iga rakendus haldab oma võtmeid privaatselt. See on eelistatud valik, kui soovite lihtsalt sinu rakendus pääsevad ligi oma saladustele ilma, et kasutaja peaks käsitsi võtmeid loendist valima. Selle rakendamiseks kasutatakse standardseid Java klasse, näiteks KeyStore, KeyPairGenerator o KeyGenerator.
Tehniline teostus: krüpteerimine ja allkirjad
Sümmeetrilise andmekrüptimise puhul on kõige soovitatavam meetod AES-GCM . See meetod mitte ainult ei säilita salajasust, vaid tagab ka andmete terviklikkuse, tuvastades, kas krüptitud baite on muudetud. Oluline on meeles pidada, et iga toiming genereerib unikaalse initsialiseerimisvektori (IV) , mis tuleb koos krüptitud andmetega salvestada, et toiming tagasi pöörata.
Kui vajate digitaalallkirja, on parim viis kasutada RSA-d . Võtmehoidlas genereeritakse võtmepaar (avalik ja privaatne). Privaatvõti jääb teabe allkirjastamiseks turvalisse riistvarasse lukustatuks , samas kui avalikku võtit saab levitada, et kontrollida sõnumi muutmata jätmist ja selle päritolu algallikast.
Süsteemi sisemine arhitektuur ja areng
Kapoti all on süsteem keeruline masin. AndroidKeyStore See on rakenduse nähtav külg, aga suhtleb ka võtmehoidla deemon Binderi kaudu. See deemon haldab keyblobs (krüpteeritud võtmed) ja tugineb KeyMinti HAL (endine Keymaster) raskete tööde tegemiseks turvalises maailmas.
Tee on olnud pikk: Android 6.0-st, mis tutvustas juurdepääsukontrolli ja AES/HMAC primitiivid, läbi Android 7.0 koos võtmesertifitseerimise ja versiooni linkimisega (et takistada ründajal operatsioonisüsteemi haavatavale versioonile alandamist), kuni Android 12-ni. Selles uusimas versioonis kirjutati deemon Rustis turvalisuse suurendamiseks ümber ja tutvustati KeyMinti HAL-i, mis toetab ECDH võtmelepinguid ja võtmekasutuse piiranguid.
Kohtuekspertiisi perspektiiv ja ekstraheerimise riskid
Kuigi võtmehoidla on väga töökindel, on arvutikriminalistika maailmas olemas meetodid teabe hankimiseks. Võtmeid hoitakse krüpteeritult /misc/keystore/ (või alates Android 12-st SQLite'i andmebaasis). Nende kaitsmiseks on Võtme krüpteerimisvõti (KEK) tuletatud turvalise riistvara fikseeritud väärtustest.
Mõned digitaalse kohtuekspertiisi eksperdid üritavad võrguühenduseta dekrüpteerida, ammutades riistvara väärtusi protsessoripõhiste haavatavuste (nt MTK või Qualcomm) kaudu. Kui neil õnnestub hankida KEK (võtmesalvestusvõti), saavad nad võtmesalvestuses olevad võtmed dekrüpteerida ja seejärel juurde pääseda selliste rakenduste nagu Signal või Element krüptitud andmebaasidele , mis tavaliselt kasutavad võtmesalvestust oma Realmi andmebaaside peavõtme kaitsmiseks.
