Comment gérer en toute sécurité les valeurs AES «Clé» et «IV»
Si j'utilise AES (System.Security.Cryptography) pour simplement crypter et décrypter les champs blob ou mémo dans un serveur SQL, alors où dois-je stocker les valeurs "Key" et "IV" sur le serveur? (Fichier, Regkey, Dbase, ...)
Et qu'en est-il de la protection de ces valeurs "clés" et "IV" AES?
La question d'arrière-plan est plus: si "ils" piratent le serveur et obtiennent la base de données ... alors ils peuvent probablement accéder au programme qui fait aussi le chiffrement (il est sur le même serveur, ne peut pas l'aider) ... et si "ils" sont très bons, alors ils remarqueront où les valeurs "Key" et "IV" sont stockées ... (. NET 4.5 ILSPY) et tout peut être à nouveau décrypté.
S'il vous plaît des conseils? Comment gérez-vous tous les valeurs AES "Clé" et "IV"?
Ps: Il ne s'agit pas de champs pwd ... donc, il ne s'agit pas de hacher ... sa pure cryptographie de données.
Le IV a été complètement couvert par les autres réponses, donc je vais me concentrer uniquement sur le stockage de la clé.
Premier...
Je ne peux pas, sauf que cela ne pouvait pas être fait sur un seul serveur au niveau logiciel.
Tout ce qui est fait dans le logiciel peut être annulé dans le logiciel. Vous pouvez le chiffrer, le masquer et le verrouiller dans autant de coffres que vous le souhaitez, mais votre application doit toujours pouvoir accéder à la clé. Si votre application y a accès, une personne disposant du même niveau d'accès que votre application peut également y accéder.
Les développeurs traitent ce problème depuis très longtemps et il n'y a pas de solution miracle.
Tout cela est configuré dans un environnement de serveur unique (application plus base de données), donc je ne peux pas envoyer/récupérer la clé à un deuxième serveur. De plus, dans ce cas "spécial", je ne suis pas en mesure de chiffrer la clé à l'aide d'un conteneur de clés RSA au niveau de la machine ou de l'utilisateur.
Je peux penser à deux solutions possibles.
Option 1:
Stockez la clé sur le disque et, au niveau du système d'exploitation, configurez l'accès aux fichiers de sorte que seul le compte sous lequel votre application s'exécute puisse lire le fichier dans lequel se trouve la clé. Le fichier peut être un fichier plat ou un conteneur crypté protégé par un mot de passe que votre application connaît (à vous de décider, mais un conteneur chiffré est préférable).
Avantages:
- Redémarre sans intervention humaine.
Les inconvénients:
- Vous devez faire la sécurité du système d'exploitation correctement et il n'y a pas de place pour l'erreur.
- Un attaquant disposant d'un accès administrateur peut accéder à la clé.
Une autre option similaire à celle-ci serait d'utiliser DPAPI au lieu de fichiers pour stocker la clé (tant que vous êtes en mesure de le faire compte tenu de votre "cas spécial"). "). Il s'agit d'une API intégrée à Windows qui utilise le mot de passe pour le compte Windows sous lequel vous (ou votre application) utilisez pour stocker en toute sécurité les données. Seul le compte Windows qui a stocké les données est capable de les récupérer.
Une caractéristique particulièrement agréable de DPAPI est que, si un administrateur réinitialise le mot de passe d'un utilisateur (via la gestion de l'ordinateur), l'accès aux données DPAPI de cet utilisateur est perd . Un attaquant devrait compromettre le compte réel qui a été utilisé pour stocker les données en premier lieu sans réinitialiser le mot de passe.
Option 2:
Exiger qu'une phrase de passe soit entrée par une personne au démarrage de l'application et dériver une clé de chiffrement de cette phrase de passe. Une fois que vous avez la clé, jetez la phrase de passe et conservez la clé en mémoire uniquement.
Avantages:
- La clé n'est jamais sur le disque.
- Même si le serveur est enraciné, accéder à la clé n'est pas une tâche simple.
Les inconvénients:
- Les redémarrages automatisés ne sont pas possibles.
- Vous devrez probablement partager la phrase de passe avec toute personne chargée de l'assistance.
- Vous devez garder à l'esprit que les données stockées en mémoire mai peuvent être écrites de manière transparente sur le disque dans certaines situations.
Ou vous pouvez faire un compromis entre ces deux systèmes où, une phrase de passe est initialement utilisée pour dériver la clé de chiffrement qui est conservée en mémoire, et la clé est temporairement écrite sur le disque ou le conteneur chiffré chaque fois que l'application est redémarrée avec élégance. Une fois le redémarrage terminé, l'application charge la clé, puis la supprime du stockage temporaire (et, si nécessaire, veillez à remplacer l'emplacement du disque où la clé a été stockée afin qu'elle ne puisse pas être récupérée).
Les règles de base sont les suivantes:
- La clé doit être secrète en tout temps (ne doit pas se trouver à proximité de la base de données)
- IV doit être différent pour chaque enregistrement.
- IV doit être "indiscernable du hasard" et imprévisible, de préférence il doit provenir de la même source que vos clés AES; une autre option consiste à crypter une valeur (différente pour chaque enregistrement) avec une clé secrète.
- IV n'a pas besoin d'être secret
Par conséquent, un schéma que vous pouvez utiliser est:
- Créer une table avec les champs ID (unique, int), IV (unique, 16 octets), chiffré (octets variables, NULLable)
- Pour écrire un nouvel enregistrement dans la base de données, créez un nouveau IV unique et créez un nouvel enregistrement dans la base de données avec des données chiffrées vides (pour éviter les collisions)
- Chiffrez les données avec votre clé secrète et IV à partir de l'étape 2 (mode CBC ou CTR - CTR est meilleur) et mettez à jour l'enregistrement.
La deuxième étape peut être effectuée en prenant l'IV de l'enregistrement précédent et en le chiffrant avec la même clé secrète - les propriétés d'AES en feront un IV effectivement aléatoire.
Ce sera aussi sécurisé que possible avec AES - ce qui signifie sécurisé CCA/CPA. La seule chose qu'il n'empêche pas est la falsification
Le IV n'a pas besoin d'être gardé aussi secret que la clé, la seule chose qu'il sert à faire est de s'assurer que deux des mêmes blobs exactement chiffrés avec la même clé produisent deux sorties qui sont totalement différentes l'une de l'autre (vous pouvez donc ne dites pas que le même message a été envoyé deux fois). De nombreux systèmes de chiffrement font simplement de l'IV les premiers octets du message.
Les clés de chiffrement sont plus difficiles à gérer, la meilleure chose à faire est de garder la base de données elle-même et l'application séparées, donc "Si" ils "piratent le serveur et obtiennent la base de données" (disons qu'une attaque par injection SQL leur permet de faire un vidage de les tables de la base de données), ils ne peuvent toujours pas décrypter les champs eux-mêmes.
Séparer votre serveur Web et votre serveur db serait utile ici. Vous souhaitez verrouiller l'accès (en termes d'autorisations) à vos clés de chiffrement et les conserver en mémoire en tant que SecureString. Je ne peux pas faire beaucoup plus que ça. Choisissez des mots de passe forts et suivez les pratiques de sécurité mises à jour.
Voici également un bon article Où stocker les clés de chiffrement MVC Application
S'il ne s'agit pas beaucoup des informations chiffrées, mettez périodiquement à jour le mot de passe et les informations des enregistrements chiffrés, cela peut être tous les jours ou toutes les heures, par exemple.