Il y a quelques années, lorsque vous êtes d'abord introduit à ASP.NET et à la structure .NET, j'ai construit un système de stockage de fichiers en ligne très simple. Ce système a utilisé le cryptage de Rijndael pour stocker les fichiers cryptés sur le disque dur du serveur et un HTTPHANDLER pour décrypter et envoyer ces fichiers au client.
Étant l'un de mes premiers projets avec ASP.NET et des bases de données, ne comprenant pas beaucoup de la manière dont tout cela fonctionne (ainsi que de tomber sur le même piège décrit par Jeff Atwood sur ce sujet ), j'ai décidé de stocker des clés et des IV fraîchement générées avec chaque entrée de fichier dans la base de données.
Pour rendre les choses un peu plus claires, le cryptage était uniquement pour protéger les fichiers d'un accès direct au serveur et que les touches n'ont pas été générées par des mots de passe saisis par l'utilisateur.
Ma question est, en supposant que je ne veux pas conserver une touche pour tous les fichiers, comment devrait i stock de clé de cryptage pour la meilleure sécurité? Qu'est-ce qui est considéré comme la meilleure pratique? (C'est-à-dire: sur un autre serveur, sur un fichier texte clair, crypté).
Aussi, quel est le vecteur d'initialisation utilisé dans ce type d'algorithme de cryptage? Devrait-il être constant dans un système?
3 Réponses :
Les clés doivent être protégées et gardées secrètes, simples comme ça. La mise en œuvre n'est pas. Les systèmes de gestion clés sont vendus pour de grandes quantités d'argent par des fournisseurs de confiance, car la résolution du problème est Vous ne voulez certainement pas utiliser la même clé pour chaque utilisateur, plus une clé est utilisée "plus facile", il s'agit de le casser, ou du moins avoir des fuites d'informations. AES est un chiffre à blocs, il divise les données en blocs et alimente les résultats du dernier cryptage de bloc dans le bloc suivant. Un vecteur d'initialisation est l'alimentation initiale dans l'algorithme, car au point de départ n'a rien à voir. L'utilisation d'IVS aléatoires avec la même clé abaisse le risque de fuites d'informations - il doit être différent pour chaque morceau de données crypté.
Comment stocker les clés dépend de la manière dont votre système est architecturé. Je viens de terminer un KMS où les clés sont éloignées du système principal et des fonctions à chiffrer et à déchiffrer sont exposées via WCF. Vous envoyez un texte brut et obtenez une référence à une clé et au texte ciphérifié de la manière dont les KMS sont responsables de toute cryptographie du système. Cela peut être surchargé dans votre cas. Si l'utilisateur entre un mot de passe dans votre système, vous pouvez l'utiliser pour générer une paire de clés. Ce keyPair pourrait ensuite être utilisé pour chiffrer un magasin clé pour cet utilisateur - XML, SQL, et utilisé pour déchiffrer chaque clé utilisée pour protéger les données.
Sans en savoir plus sur la manière dont votre système est configuré, il est difficile de recommander quelque chose d'autre que «les clés doivent être protégées, les clés et les IV ne doivent pas être réutilisés.»
Observation mineure: "AES est un chiffre à blocs, il divise les données en blocs et nourrit les résultats du dernier cryptage de bloc dans le bloc suivant." Vous décrivez CBC A Méthode pour utiliser des AES en toute sécurité. Il y a d'autres solutions sécurisées - ne nécessitent pas tous un vecteur d'initialisation.
En tant que bonne solution, vous pouvez stocker votre paire de clé / IV dans une table: Lorsque vous enregistrez une valeur cryptée, enregistrez l'ID et une valeur de sel aléatoire avec elle. . Ensuite, lorsque vous devez déchiffrer la valeur, consultez la paire de touches / IV à l'aide de l'ID et du sel stocké avec les données. Vous voulez avoir un bon modèle de sécurité autour du stockage de clé. Si vous êtes allé avec SQL Server, n'accensez pas de sélection de droits à l'utilisateur qui accède à la base de données de l'application. Vous ne voudriez pas donner à quelqu'un d'accéder à toute la table.
Il s'agit d'une très bonne solution si vous définissez le serveur SQL lui-même comme étant intrinsèquement sécurisé et stockez les clés de celui-ci répond à vos besoins en matière de sécurité. Cela pourrait être pris en outre en permettant au cryptage de données transparent sur le serveur SQL d'empêcher une attaque dans laquelle une personne copie le DB désactivée du serveur ou prend physiquement les disques durs pour contourner tous les contrôles d'accès au logiciel.
Il y a un très bon article sur celui-ci à http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/CryptoCreditCard.html qui couvre les problèmes iv et salants et les problèmes avec la BCE mentionnés ci-dessus.
Il ne couvre toujours pas «Où est-ce que je stocke la clé», certes, mais après la lecture et la digestion, ce ne sera pas un énorme saut à une solution, espérons-le ...
Réponse de 2 ans et un domaine que je ne contrôle pas. Il est temps d'utiliser la machine d'archivage sur Internet ....
Pour les paresseux - Web .Archive.org / Web / 20121017062956 / http: //www.di-mgt.com.au/ ...
Pas de mal, pas de faute - espérons que le lien d'archives aide le folk extérieur :-)