Idag är våra mobila enheter praktiskt taget en dagbok där vi lagrar allt: från intima foton till våra kreditkortsuppgifter. Det är därför vi inte kan lämna säkerheten åt slumpen. När det gäller att skydda känsliga data på Android blir Android Keystore System det viktigaste verktyget för att förhindra att illvilliga aktörer stjäl våra kryptografiska nycklar, vilket gör det till en grundläggande pelare i Android-säkerhet.
I grund och botten fungerar det här systemet som ett digitalt kassaskåp. Istället för att lagra nycklar som enkla textfiler på telefonens lagringsplats (vilket skulle vara en säkerhetskatastrof), låser det in dem i en säker behållare . Bäst av allt är att när nyckeln väl är inuti kan du använda den för att kryptera eller signera saker, men den kan aldrig extraheras från enheten, inte ens om operativsystemet har komprometterats.
Hur fungerar säkerheten i systemets hjärta?
Keystore-systemet krånglar inte och skyddar nyckeldata på två mycket tydliga sätt. För det första förhindrar det att någon utanför enheten stjäl nyckeldata, eftersom det blockerar extrahering från applikationsprocesser. För det andra säkerställer det att även om någon lyckas få åtkomst till systemet kan de inte använda nyckeln till vad de vill; appar måste definiera auktoriserade användningsområden som systemet strikt tillämpar.
För att göra detta verkligt robust förlitar sig Android på hårdvara. Nyckeldata passerar inte genom appens processer; när du behöver utföra en åtgärd skickas informationen till en specialiserad systemprocess . Dessutom, om telefonen är modern, är nycklarna länkade till Trusted Execution Environment (TEE) eller Secure Element (SE). Om du har en enhet med StrongBox tas säkerheten till nästa nivå, eftersom den här modulen har sin egen CPU, säker lagring och en riktig slumptalsgenerator, vilket gör den motståndskraftig även mot fysiska attacker.
För att avgöra om en nyckel verkligen är skyddad av hårdvara kan utvecklare använda `getSecurityLevel()` i Android 10 och senare. Om resultatet är `TRUSTED_ENVIRONMENT` eller `STRONGBOX` kan vi vara säkra på att nyckeln finns i ett område isolerat från huvudprocessorn.
Åtkomstkontroll och användningsbehörigheter
En av de bästa funktionerna i det här systemet är att du kan tilldela "regler" till varje nyckel när du skapar den. Dessa regler är oföränderliga; när de väl är inställda kan de inte ändras . Du kan till exempel begränsa en nyckel till att endast fungera med specifika algoritmer , som AES eller RSA, eller definiera en exakt tidsram under vilken nyckeln är giltig.
Men det mäktigaste är användarautentiseringDu kan konfigurera nyckeln så att den bara fungerar om användaren nyligen har autentiserat sig med sin PIN-kod, sitt mönster eller biometri (fingeravtryck eller ansikte)), med tanke på att 2D vs 3D ansiktsupplåsning Den erbjuder olika skyddsnivåer. Det finns två lägen: ett som auktoriserar alla nycklar under en viss tid efter autentisering, och ett annat som är mer strikt där varje kryptooperation måste auktoriseras individuellt genom en BiometricPrompt.
Nyckelring kontra Android Keystore-leverantör
Ibland kanske man undrar vilken man ska välja. KeyChain API är det perfekta alternativet när man behöver systemomfattande inloggningsuppgifter. Här väljer användaren, via ett systemgränssnitt, vilka inloggningsuppgifter de vill dela med appen. Detta är mycket användbart för inloggningsuppgifter som delas mellan flera applikationer med uttryckligt samtycke från ägaren av mobilenheten.
Dessutom Android Keystore-leverantör Den är utformad så att varje applikation hanterar sina egna nycklar privat. Det är det bästa alternativet när du vill bara din app ha tillgång till sina hemligheter utan att användaren behöver manuellt välja nycklar från en lista. För att implementera detta används standard Java-klasser, till exempel KeyStore, KeyPairGenerator o KeyGenerator.
Teknisk implementering: Kryptering och signaturer
För symmetrisk datakryptering är AES-GCM den mest rekommenderade metoden . Denna metod upprätthåller inte bara sekretessen utan garanterar även dataintegriteten genom att detektera om de krypterade byten har manipulerats. Det är viktigt att komma ihåg att varje operation genererar en unik initialiseringsvektor (IV) som måste lagras tillsammans med den krypterade informationen för att kunna reversera operationen.
Om du behöver en digital signatur är det bästa sättet att använda RSA . Ett nyckelpar (offentlig och privat) genereras i nyckellagret. Den privata nyckeln förblir låst i säker hårdvara för att signera informationen , medan den offentliga nyckeln kan distribueras för att verifiera att meddelandet inte har ändrats och att det kommer från den ursprungliga källan.
Intern arkitektur och systemets utveckling
Under huven är systemet en komplex maskin. AndroidKeyStore Det är appens synliga ansikte, men den kommunicerar med nyckelbutiksdaemon genom Binder. Denna daemon hanterar keyblobs (krypterade nycklar) och förlitar sig på HAL av KeyMint (tidigare Keymaster) för att utföra tunga lyft i den säkra världen.
Vägen har varit lång: från Android 6.0, som introducerade åtkomstkontroll och AES/HMAC-primitiver, via Android 7.0 med nyckelcertifiering och versionslänkning (för att förhindra att en angripare nedgraderar operativsystemet till en sårbar version), till Android 12. I den senaste versionen skrevs daemonen om i Rust för att öka säkerheten och KeyMints HAL introducerades, vilket stöder ECDH- nyckelavtal och nyckelanvändningsgränser.
Forensiskt perspektiv och utvinningsrisker
Även om nyckellagret är mycket robust finns det inom datorforensikens värld metoder för att försöka utvinna informationen. Nycklarna lagras krypterade i /misc/keystore/ (eller i en SQLite-databas sedan Android 12). För att skydda dem, en Krypteringsnyckel (KEK) härledda från fasta värden för den säkra hårdvaran.
Vissa experter på digital forensik försöker sig på offline-dekryptering genom att extrahera hårdvaruvärden via processorspecifika sårbarheter (som MTK eller Qualcomm). Om de lyckas få tag på KEK (Keystore Key) kan de dekryptera nycklarna i nyckellagret och därefter få åtkomst till krypterade databaser från applikationer som Signal eller Element , som vanligtvis använder nyckellagret för att skydda huvudnyckeln till sina Realm-databaser.
