2017-03-24 2 views
3

Je souhaite utiliser le KeyStore avec support matériel Android, mais je suis préoccupé par la sécurité et la facilité d'utilisation. D'après ce que j'ai lu here, KeyStore est effacé lorsque l'utilisateur modifie le verrouillage du périphérique, sauf si setEncryptionRequired() est omis. Pour des raisons de convivialité, il semble que cela doive être fait, sinon toutes les clés sauvegardées par le matériel seraient effacées une fois que le verrou du périphérique est modifié. Cependant, j'ai également lu here Cependant, j'ai également lu here que les clés supportées par le matériel ne sont pas réellement stockées dans le TEE, mais stockées comme des fichiers clés dans/data/misc/keystore/user_0 /, cryptées par une clé spécifique au périphérique. est stocké dans le TEE. Étant donné qu'une modification du verrouillage de l'appareil efface le magasin de clés, il semble que la clé spécifique à l'appareil dérive du verrouillage de l'appareil. Pour des raisons de sécurité, il est logique de crypter le fichier de clé, sinon tout utilisateur root serait capable de lire les fichiers de clés et d'extraire la clé privée, puisqu'ils seraient vraisemblablement en clair.Utilisation du KeyStore Android avec support matériel

Donc je suis dans un dilemme. Pour des raisons de convivialité, je devrais omettre setEncryptionRequired(), mais pour des raisons de sécurité, je devrais définir setEncryptionRequired(). Enfin, est-il possible d'importer une clé privée dans le KeyStore supporté par le matériel en utilisant setKeyEntry()? Je suis capable de le faire sans erreur mais je ne suis pas sûr que ce soit supporté par le matériel.

Est-ce que je comprends bien?

Répondre

2

setEncryptionRequired() a été obsolète dans Android 6.0 (Marshmallow), et n'a jamais vraiment accompli beaucoup. La sécurité d'Android KeyStore dépend du TEE, pas du mot de passe.

L'article de blog auquel vous avez accédé est obsolète, au moins sur les appareils équipés d'Android 6.0 ou version ultérieure. Sur ces appareils, vous ne devez pas utiliser setEncryptionRequired() et vos clés ne seront pas supprimées tant que votre application ne sera pas désinstallée (ou si une réinitialisation d'usine est effectuée ou si votre application les supprime). Vos clés seront solidement emballées par des clés secrètes qui ne quittent jamais le TEE. En fait, vos clés ne quitteront jamais le TEE en clair. Lorsque vous utilisez vos clés, les données sont transmises dans le TEE avec la clé cryptée. Le TEE déballe la clé puis traite et renvoie les données cryptées/signées/quelconques.

Oui, vous pouvez importer des clés privées à l'aide de setKeyEntry(). Si vous voulez être sûr que votre clé est supportée par le matériel, utilisez KeyInfo.isInsideSecureHardware(). Par exemple (ce qui est de the documentation).

PrivateKey key = ...; // Android KeyStore key 

KeyFactory factory = KeyFactory.getInstance(key.getAlgorithm(), "AndroidKeyStore"); 
KeyInfo keyInfo; 
boolean isHardwareBacked = false; 
try { 
    keyInfo = factory.getKeySpec(key, KeyInfo.class); 
    isHardwareBacked = keyInfo.isInsideSecureHardware(); 
} catch (InvalidKeySpecException e) { 
    // Not an Android KeyStore key. 
} 
+0

Merci Donc, pour être sûr, ce qui se passe quand je produis une paire de clés soutenu matériel est la paire clé générée dans le TEE, ou à l'extérieur de celui-ci est privé? clé stockée dans/data/misc/keystore/user_0/mais chiffrée par une clé principale stockée dans le TEE Selon la documentation officielle, setEncryptionRequired() "indique que cette paire de clés doit être cryptée au repos. Cela signifie-t-il que la clé privée sera cryptée par une clé dans TEE, puis cryptée avec une clé dérivée d'identifiant de verrou? – user1118764

+0

@ user1118764 dans les versions récentes d'Android, elle est générée à l'intérieur du TEE Dans la plupart des cas, il est ensuite chiffré avec une clé dérivée des données qui ne quitte jamais le TEE, et la copie cryptée est exportée vers Android et stockée dans/data/misc/keystore/user_XX. setEncryptionRequired était obsolète au niveau 23 de l'API, car il n'est plus utile, et je suggère de ne pas l'utiliser lors du ciblage de niveaux d'API antérieurs car il n'était pas très fiable (les clés pouvaient être perdues). – divegeek

+0

L'article de blog lié est maintenant mis à jour :) https://doridori.github.io/android-security-the-forgetful-keystore/ – Dori