Comment créer une clé de chiffrement pour des algorithmes de chiffrement?
Je souhaite utiliser l'algorithme de chiffrement disponible dans l'espace de noms .Net Security, mais j'essaie de comprendre comment générer la clé, par exemple, l'algorithme AES a besoin de 256 bits, cette clé de 16 octets et un vecteur d'initialisation, qui est également de quelques octets.
Puis-je utiliser n'importe quelle combinaison de valeurs dans ma clé et mon IV? par exemple. tous les zéros de Key et IV sont valides ou non? Je connais le détail de l'algorithme qui fait beaucoup de xors, donc zéro ne servira à rien, mais y a-t-il des restrictions par ces algorithmes?
Ou dois-je générer la clé à l'aide d'un programme et l'enregistrer définitivement quelque part?
Je veux stocker les données dans la base de données après le cryptage, les données de profil sécurisées comme le nom d'utilisateur, le mot de passe, le numéro de téléphone, etc., et la clé sera disponible uniquement pour l'utilisateur de la base de données mentionné dans la chaîne de connexion et pour l'administrateur.
Si vous utilisez le cryptage pour échanger des données, vous aurez besoin d'un protocole d'échange de clés, mais vous n'en créez pas vous-même à la place, utilisez-en un standard comme TLS ou SSL.
Si vous utilisez le chiffrement pour stocker des données, vous générez l'IV en utilisant CryptGenRandom (ou son équivalent .net RandomNumberGenerator.GetBytes ) et l'enregistrez le long du document (en clair, pas besoin pour protéger l'IV). Vous n'écrivez jamais la clé, la clé est fournie par l'utilisateur. Habituellement, vous dérivez la clé d'une phrase de mot de passe en utilisant CryptDeriveKey , ou son équivalent .Net PasswordDeriveKey.CryptDeriveKey .
Mise à jour
Pour stocker un secret dans la base de données qui n'est disponible que pour l'utilisateur et l'administrateur, vous devez utiliser 3 clés:
- un pour crypter les données avec (appelez-le la clé DK)
- une clé utilisateur pour crypter la clé DK (appelez-la UK)
- une clé administrateur pour crypter la clé DK (appelez-la AK)
En théorie, vous chiffrez les données avec DK, puis chiffrez le DK avec UK et enregistrez-le, puis chiffrez le DK avec AK et enregistrez-le. De cette façon, l'utilisateur peut utiliser à nouveau le Royaume-Uni pour décrypter le DK puis décrypter les données, et l'administrateur peut utiliser l'AK pour décrypter le DK puis décrypter les données. Le gros problème est le fait que le système est toujours automatisé, donc le système a besoin d'accéder à la clé de l'administrateur, ce qui signifie qu'il ne s'agit pas vraiment d'une clé personnelle de l'administrateur, mais plutôt d'une clé système (elle ne peut pas être utilisée à des fins de non répudiation par exemple).
En tant que tête à tête, la connaissance de ce qu'est IV ou comment utiliser AES à partir de C # et comment fonctionne l'algorithme de cryptographie vous donnera exactement 0 (zéro) traction pour résoudre ce type de problèmes. Le problème n'est jamais la IV et la clé à utiliser, le problème est toujours le provisionnement des clés. Pour les opérations de cryptographie réelles, utilisez simplement le support intégré de la base de données, voir Cryptographie dans SQL Server . Je peux facilement affirmer que l'installation uniquement dont vous avez besoin est TDE ( Transparent Data Encryption ) pour vous protéger contre la perte accidentelle de support.
Vous devez vraiment le faire correctement :)
1) Utilisez un IV aléatoire généré en toute sécurité
2) Utilisez une clé aléatoire générée en toute sécurité
3) N'utilisez pas le mode ECB - JAMAIS
AesManaged aes = new AesManaged();
aes.GenerateKey();
aes.GenerateIV();
Le code ci-dessus générera correctement et en toute sécurité une IV aléatoire et une clé aléatoire pour vous.
On dirait que vous devez lire dans la classe Rfc2898DeriveBytes.
Rfc2898DeriveBytes.GetBytes();
Il a une méthode (ci-dessus) qui vous permet de personnaliser la taille des tableaux d'octets qui sont introduits dans les propriétés .Key et .IV sur un algorithme de chiffrement symétrique, simplement en alimentant une valeur int. Le livre officiel de MS 70-536 suggère de faire cela de manière programmatique en divisant la propriété KeySize/8.
C'est-à-dire TripleDes ou AESManaged. Quoi que vous utilisiez, l'algorithme lui-même aura des pré-requis qui devront d'abord être rencontrés. C'est-à-dire répondant aux conditions de taille de clé. Le RunTime remplira automatiquement les propriétés et les champs et etc. les valeurs les meilleures et les plus fortes pour vous. Mais l'IV et la clé doivent venir de vous. Voici comment vous pouvez effectuer les opérations suivantes:
RijndaelManaged myAlg = new RiRijndaelManaged();
byte[] salt = Encoding.ASCII.GetBytes("Some salt value");
Rfc2898DeriveBytes key = new Rfc2898DeriveBytes("some password", salt);
myAlg.Key = key.GetBytes( myAlg.KeySize / 8);
myAlg.IV = key.GetBytes( myAlg.BlockSize / 8);
// myAld should now fully set-up.
Ci-dessus, vous pouvez voir ce que je veux dire en le faisant de façon programmatique, car cela devrait à peu près tout faire pour vous, sans même que vous ayez vraiment à vous couvrir les yeux pour respecter ses pré-requis.
Le livre Microsoft 70-536 indique que les propriétés .Key attendent les tableaux d'octets que vous leur fournissez en octets et non en bits. La classe RFC fonctionne en octets alors qu'en tant qu'algorithme, la propriété KeySize fonctionne en bits. 1 octet = 8 bits. Pouvez-vous voir où cela va ...? Cela devrait vous donner une idée de la raison pour laquelle l'exemple de code ci-dessus est fait comme il est! Je l'ai étudié et cela fait un sacré bon sens pour moi!
La réponse ci-dessus devrait vous permettre de créer votre objet d'algorithme avec le mot de passe fourni et une valeur de sel statique qui peut être du code dur aux deux extrémités. La seule chose que vous devez faire est de vous soucier de la façon dont vous allez vous assurer que les tableaux d'octets stockés dans .Key et .IV sont transportés en toute sécurité vers un destinataire afin de pouvoir décrypter avec succès le message que vous avez crypté. En reconstruisant en toute sécurité le même objet algorithme.
OBTW:
AESManaged a une demande de taille de clé: 128 bits = 16 octets !!! (8 * 8 = 64, 64 bits/8 bits par octet = 8 octets)
64 * 2 = 128 bits, 8 * 2, ==> taille de clé de 16 octets!
256 bits = 32 octets !!!!
Selon le livre officiel du kit de formation 70-536, Aes est limité à avoir une taille de clé de 128 bits. 256 bits, 192 et 128 clés par exemple peuvent être utilisés avec la classe Rijndael.
D'un autre côté, vous pouvez complètement oublier toutes ces conneries et utiliser simplement les méthodes .GenerateKey et GenerateIV à la place pour vous éviter d'avoir à trier un mot de passe pré-partagé et convenu et des valeurs de sel statiques. Votre seule préoccupation est de trouver un moyen de stocker et de récupérer les clés et les tableaux d'octets IV. Formateur binaire? .
Générez un code aléatoire de lettres/hexadécimal dans une longueur spécifique.
Cette fonction (tirée de ici ) retourne une clé aléatoire d'une longueur spécifique:
private static string CreateSalt(int size)
{
//Generate a cryptographic random number.
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] buff = new byte[size];
rng.GetBytes(buff);
// Return a Base64 string representation of the random number.
return Convert.ToBase64String(buff);
}
Utilisation System.Security.Cryptography.RandomNumberGenerator pour générer des octets aléatoires:
var rnd = new System.Security.Cryptography.RandomNumberGenerator.Create();
var key = new byte[50];
rnd.GetBytes(key);
Cela dépend vraiment de ce que vous devez faire avec la clé.
Si la clé doit être générée par l'ordinateur (et peut être n'importe quelle valeur aléatoire), je prends généralement un SHA256 d'un couple de GUID. C'est à peu près aussi aléatoire que vous obtiendrez sans un générateur de nombres aléatoires matériel.
Vous pouvez utiliser des clés avec tous les 0, mais ce ne sera évidemment pas très sécurisé.