web-dev-qa-db-fra.com

Comment est-il possible de changer le mot de passe de l'utilisateur après le cryptage du stockage? (sous OS X, Android)

Il existe des fonctionnalités intégrées pour crypter un stockage sur OS X ( FileVault ) et Android.

Sous OS X: pour activer le cryptage, l'utilisateur actuel doit avoir un compte protégé par mot de passe. Après avoir activé le chiffrement, une clé de récupération est générée (quelque chose comme HHWj-Y8DK-ODO4-BQEN-FQ4V-M4O8). Une fois le cryptage terminé (et selon toute probabilité avant cela également), l'utilisateur est en mesure de modifier son mot de passe, sans avoir à rechiffrer le stockage.

Sur Android: l'utilisateur doit définir la protection de l'écran de verrouillage sur code PIN ou mot de passe. Une fois le chiffrement du stockage effectué (encore une fois, probablement avant cela également), l'utilisateur est en mesure de changer le mot de passe, et même de passer du mot de passe au code PIN et vice versa.

Maintenant, voici ce qui m'intrigue: si je comprends bien, lorsque le stockage est crypté, cela se fait avec le mot de passe utilisateur actuel (un peu comme le cryptage d'une archive) et si le mot de passe est modifié - tout le stockage doit être recrypté. Cette compréhension (apparemment incorrecte) m'amène aux questions suivantes:

  1. Sur la base de quelle "clé" (puisqu'il ne s'agit pas du mot de passe lui-même), le cryptage est-il alors effectué?
    • Pour OS X, je suppose que c'est la clé de récupération, mais comment est-elle alors connectée au mot de passe de l'utilisateur?
  2. Si le mot de passe n'est pas la base du cryptage, pourquoi est-il nécessaire d'en définir un avant de crypter votre stockage?
  3. Comment la capacité de déchiffrer le stockage est-elle conservée (sans rechiffrement) après le changement de mot de passe?
encryptionpasswordsandroiddisk-encryptionmacos
28
Filippo Walker

À un niveau élevé, le chiffrement du disque est mis en œuvre à l'aide d'une clé de chiffrement des données (DEK) et d'une clé de chiffrement des clés (KEK). Le DEK est généré de manière aléatoire et utilisé pour crypter le lecteur, le KEK est dérivé du mot de passe de l'utilisateur à l'aide d'un KDF comme PBKDF2 ou Argon2, puis utilisé pour crypter le DEK.

Lors du changement de mot de passe, le DEK est simplement crypté avec une nouvelle KEK dérivée du nouveau mot de passe.

Le cryptage sans mot de passe est probablement interdit pour éviter un faux sentiment de sécurité. Ce serait un peu comme verrouiller votre porte mais laisser la clé dans la serrure.

Bien sûr, si vous changez votre mot de passe parce que vous pensez que quelqu'un l'a compris et que cette personne a également accès à l'appareil crypté, il est possible qu'elle ait stocké une copie du DEK. Dans ce cas, il peut être nécessaire de rechiffrer l'intégralité du lecteur, mais cela prendra probablement un certain temps.

48
AndrolGenhald

Je suis entièrement d'accord avec la réponse de haut niveau d'AndrolGenhald. Dans le cas où vous êtes intéressé par une présentation complémentaire de bas niveau de la mise en œuvre du chiffrement de stockage Android:

Android peut effectuer le chiffrement basé sur fichier (FBE) et le chiffrement complet du disque (FDE), avec "disque" faisant référence à la partition/data. Je vais me concentrer sur FDE pour illustrer le principe. La configuration est effectuée par le démon de volume (Vold), spécifiquement dans system/vold/cryptfs.cpp .

  • cryptfs_enable_internal(int crypt_type, const char* passwd, ...) démarre le chiffrement du stockage, avec crypt_type spécifiant si une broche ou un mot de passe est utilisé (pour déterminer le clavier à afficher sur l'écran de déverrouillage) et passwd donnant le code PIN/mot de passe utilisateur réel. Il créera un pied de page crypt_ftr À stocker le long de la partition chiffrée, puis il appellera create_encrypted_random_key Pour remplir le crypt_ftr.

    • create_encrypted_random_key génère une clé principale aléatoire et un sel aléatoire et les transmet à encrypt_master_key.
    • encrypt_master_key utilise une fonction de dérivation de clé (par exemple scrypt), qui prend le sel et la broche/mot de passe utilisateur comme entrée et dérive de manière déterministe une clé intermédiaire. La clé principale est ensuite chiffrée avec la clé intermédiaire à l'aide d'AES-128-CBC. La clé principale cryptée et le sel sont stockés dans crypt_ftr, Mais pas le code PIN/mot de passe de l'utilisateur.
    • De retour dans cryptfs_enable_internal, Le crypt_ftr Est écrit sur le disque. Ensuite, le chiffrement de stockage réel via Linux 'dm-crypt Est déclenché à l'aide de la clé principale déchiffrée.

  • cryptfs_check_passwd(const char* passwd) démarre le déchiffrement du stockage en effectuant un retour en arrière des étapes ci-dessus pour obtenir la clé principale déchiffrée. Le crypt_ftr Doit être lu à partir du disque, contenant la clé principale chiffrée et le sel. La broche/mot de passe fourni par l'utilisateur plus le sel sont introduits dans la fonction de dérivation de clé. Il en résulte une clé intermédiaire qui peut déchiffrer la clé principale (la plupart de cela se produit dans decrypt_master_key_aux ).

  • cryptfs_changepw(int crypt_type, const char* newpw) gère la modification du code PIN/mot de passe utilisateur. Il ne générera pas de nouvelle clé principale, il crypte simplement la clé principale existante via encrypt_master_key En utilisant le nouveau code PIN/mot de passe utilisateur.

Sur la base de ces informations, les réponses à vos questions seraient:

  1. La clé principale générée aléatoirement est utilisée pour le chiffrement de stockage réel.

  2. Nous avons besoin d'un code PIN/mot de passe utilisateur pour crypter la clé principale. Ainsi, la broche/mot de passe utilisateur est nécessaire pour récupérer ultérieurement la clé principale pour décrypter le stockage.

  3. La modification du code PIN/mot de passe de l'utilisateur ne modifiera pas la clé principale, mais uniquement le cryptage de la clé principale.

15
f9c69e9781fa194211448473495534