Core Data Encryption

Question

J'ai une question à propos du cryptage des données de base. Je stocke des données utilisateur sensibles dans une base de données Core Data SQLite. Les valeurs critiques sont toutes transformables et j'utilise AES256 pour les crypter et les décrypter «à la volée», y compris un IV individuel pour chaque valeur. La clé de cryptage est le hachage SHA512 du mot de passe choisi par l'utilisateur. Cela fonctionne très bien jusqu'à présent.

Maintenant sur le mot de passe de l'utilisateur. Lorsque l'utilisateur lance l'application, il lui est demandé son mot de passe. Le mot de passe est en cours de hachage avec SHA512 et stocké dans le trousseau iOS. Pour chaque opération d'écriture ou de lecture, NSValueTransformer obtiendra le mot de passe du trousseau. Si l'application est fermée, je supprime le hash du mot de passe du trousseau.

Dans ma base de données de base de données j'ai une entité spéciale qui a un nombre aléatoire! = 0 car c'est seulement la valeur. Pour tester si l'utilisateur a entré le bon mot de passe, je récupère cette entité et lit le numéro. Si c'est =! 0, je sais que le mot de passe était correct parce que lorsque le déchiffrement échoue le NSValueTransformer retourne toujours 0.

Maintenant mes questions actuelles: Considérez-vous cela une bonne approche sur le cryptage? Sinon, comment testeriez-vous si le mot de passe entré est correct? Je suis un peu préoccupé par le fait que stocker le hachage de mot de passe dans le trousseau pendant que l'application est en cours rend tout plus lent, car le NSValueTransformer doit accéder au trousseau tout le temps. Serait-il suffisamment sécurisé pour garder le mot de passe en mémoire, il sera donc supprimé lorsque l'application sera fermée?

Answer 1

Vous ne devriez pas utiliser le hash du mot de passe, les hachages sont conçus pour être rapides, donc il est (relativement) facile de faire une attaque en force. Utilisez un key derivation function comme PBKDF2.

N'utilisez pas une clé directement dérivée du mot de passe comme clé de cryptage. Si l'utilisateur change le mot de passe, vous devez rechiffrer toutes les données et les sauvegardes deviennent inutiles. Utilisez une clé de chiffrement générée aléatoirement que vous chiffrez avec une clé de chiffrement basée sur le mot de passe.

Je ne suis pas si sûr de stocker le hachage dans le trousseau au lieu de simplement le garder en mémoire. La dernière fois que j'ai examiné cela, il était relativement facile de déchiffrer le trousseau. Et chaque attaquant qui peut lire la mémoire de votre application en cours d'exécution sera probablement en mesure d'espionner l'accès au trousseau ou les données décryptées. Gardez-le en mémoire et assurez-vous d'effacer la mémoire si l'application se bloque en arrière-plan, etc. Cela est évidemment vrai aussi pour chaque donnée déchiffrée.

[EDIT: @JeffLockhart pour clarifier la procédure d'une clé de chiffrement principale] vous générer une clé aléatoire pour chiffrer vos données, nous allons l'appeler la touche A. Vous pouvez utiliser SecRandomCopyBytes pour générer la clé A, voir Apple's CryptoExcercise pour un usage Exemple. Vous utilisez la clé A pour crypter les données utilisateur. Pour enregistrer la clé A, vous devez chiffrer la clé A avec une deuxième clé B. Vous ne devez pas utiliser directement le mot de passe comme clé B, à cause d'attaques par force brute ou par dictionnaire. Donc, vous dérivez une clé du mot de passe avec un PBKDF, comme dans this réponse stackoverflow. Vous cryptez ensuite la clé A avec la clé B, par ex. en utilisant CCCrypt. Vous enregistrez la clé cryptée A et le sel utilisé pour dériver la clé B it. Pour déchiffrer, l'utilisateur entre le mot de passe, vous dérivez la clé B en utilisant le mot de passe et le sel. Vous décryptez la clé A en utilisant la clé dérivée B. Espérons que cela clarifie.

Answer 2

Vous pouvez jeter un oeil à ceci:

Secure Incremental Store

Ils ont mis en place une sous-classe NSIncrementalStore qui utilise une base de données SQLite cryptée. Ceci est un remplacement pour le magasin SQLite d'Apple. Livré avec une étiquette de prix aussi bien.