AES Cryptage et stockage des clés?

Question

Il y a quelques années, lorsque j'ai commencé à utiliser ASP.net et le .NET Framework, j'ai créé un système de stockage de fichiers en ligne très simple. Ce système utilisait le cryptage 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. Etant l'un de mes premiers projets avec ASP.net et bases de données, ne comprenant pas grand-chose sur le fonctionnement de l'ensemble (tout en tombant sur le same trap described by Jeff Atwood on this subject), j'ai décidé de stocker des clés et des IV nouvellement générés avec chaque entrée de fichier dans la base de données. Pour rendre les choses un peu plus claires, le cryptage servait uniquement à protéger les fichiers contre l'accès direct au serveur, et les clés n'étaient pas générées par les mots de passe saisis par l'utilisateur.

Ma question est, en supposant que je ne veux pas garder une clé pour tous les fichiers, comment devrait I stocker les clés de chiffrement pour une meilleure sécurité? Qu'est-ce qui est considéré comme la meilleure pratique? (i.e: Sur un serveur différent, sur un fichier en texte brut, crypté).

De plus, à quoi sert le vecteur d'initialisation dans ce type d'algorithme de chiffrement? Devrait-il être constant dans un système?

Answer 1

Les clés doivent être protégées et gardées secrètes, aussi simples que cela. La mise en œuvre ne l'est pas. Les systèmes de gestion de clés sont vendus pour de grandes quantités d'argent par des fournisseurs de confiance parce que la résolution du problème est dur.

Vous ne voulez certainement pas utiliser la même clé pour chaque utilisateur, plus une clé est utilisée "le plus facile" qu'elle vient à briser, ou au moins avoir des fuites d'informations. AES est un chiffrement par bloc, il divise les données en blocs et alimente les résultats du dernier chiffrement de bloc dans le bloc suivant. Un vecteur d'initialisation est le flux initial dans l'algorithme, car au départ il n'y a rien à commencer. L'utilisation d'IV aléatoires avec la même clé réduit le risque de fuites d'informations - il devrait être différent pour chaque donnée chiffrée.

La façon dont vous stockez les clés dépend de l'architecture de votre système. Je viens de terminer un KMS où les clés sont tenues à l'écart du système principal et les fonctions de cryptage et de décryptage sont exposées via WCF. Vous envoyez du texte en clair et obtenez une référence à une clé et le texte chiffré - de cette façon, le KMS est responsable de toute la cryptographie dans le système. Cela peut être exagéré 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. Cette paire de clés pourrait ensuite être utilisée pour crypter un magasin de clés pour cet utilisateur - XML, SQL, n'importe quoi, et utilisé pour décrypter chaque clé qui est utilisée pour protéger les données. Sans en savoir plus sur la façon dont votre système est configuré, ou son but, il est difficile de recommander autre chose que "Les clés doivent être protégées, les clés et les VIs ne doivent pas être réutilisés."

Answer 2

Comme une assez bonne soltution, vous pouvez stocker votre paire de clés/IV dans un tableau:

ID     Key   IV 
skjsh-38798-1298-hjj FHDJK398720== HFkjdf87923== 

Lorsque vous enregistrez une valeur chiffrée, enregistrer l'identifiant et une valeur de sel au hasard avec elle. Puis, lorsque vous avez besoin de déchiffrer la valeur, recherchez la paire clé/iv en utilisant l'identifiant et le sel stockés avec les données.

Vous voudriez vous assurer que vous avez un bon modèle de sécurité autour du stockage de clés. Si vous utilisez SQL Server, n'accordez pas de droits SELECT à l'utilisateur qui accède à la base de données à partir de l'application.Vous ne voudriez pas donner à quelqu'un l'accès à toute la table.

Answer 3

Il y a un très bon article sur celui-ci au http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html qui couvre à la fois les problèmes d'IV et de salage et les problèmes avec ECB mentionnés ci-dessus.

Il ne couvre toujours pas tout à fait « où dois-je stocker la clé », il est vrai, mais après avoir lu et digérer, il ne sera pas un grand pas à une solution, espérons ....