Stockage sécurisé de la chaîne utilisée pour générer une clé de cryptage symétrique.

Question

J'ai une application Windows forms qui stocke des fichiers cryptés sur le disque. Au moment de l'exécution, elle décrypte ces fichiers et transmet les flux de mémoire résultants aux ensembles de données. J'utilise un cryptage symétrique avec AESManaged.

Il existe des fonctions personnalisées pour générer des tableaux d'octets de clé et d'IV à partir d'une chaîne. Cependant, je suis actuellement en train de coder en dur la chaîne sécurisée que j'utilise pour générer la clé et l'IV, ce qui, à mon avis, va à l'encontre de l'objectif du cryptage. Je comprends que la meilleure solution serait de demander à l'utilisateur un mot de passe et d'utiliser cette chaîne. Existe-t-il un autre moyen de contourner ce problème sans avoir à demander un mot de passe à l'utilisateur ? Je ne peux pas non plus utiliser DPAPI car le fichier de données crypté est censé être partagé entre les utilisateurs et les ordinateurs.

Answer 1

Il n'est pas possible d'avoir le beurre et l'argent du beurre :) Vous ne pouvez pas stocker la clé de décryptage et l'utiliser sans que quelqu'un puisse la récupérer. La seule chose que vous pouvez faire est de ne pas rendre évident l'endroit où elle se trouve en obscurcissant votre code, en pré-cryptant votre clé et en la décryptant dynamiquement, peut-être à travers plusieurs tours de décryptage dispersés dans plusieurs classes. Contrairement au reste des disciplines de programmation, ici, le code désordonné est une bonne chose.

Answer 2

Je pense que vous devriez quand même envisager l'utilisation de DPAPI ; pas pour le cryptage des fichiers de données, mais pour le cryptage de la chaîne secrète.

Serait-il possible de demander à votre utilisateur de saisir une seule fois la chaîne secrète ?

• Utiliser DPAPI pour le chiffrer
• Ensuite, stockez la valeur chiffrée quelque part (fichier de configuration, fichier de paramètres, registre, où vous voulez. De préférence quelque chose de sécurisé pour l'utilisateur, pas pour le grand public).
• Puis, lorsque vous en avez besoin, utilisez l'interface DPAPI pour récupérer la chaîne secrète.
• Utilisez le reste de votre code comme vous l'avez déjà fait.

Comme vos fichiers de données seront toujours chiffrés par AES avec la même chaîne secrète, ils seront toujours interchangeables. (Entre les personnes ayant la même chaîne secrète...donc maintenant vous venez de faire en sorte que votre application puisse avoir plusieurs groupes sécurisés, avec chaque groupe définissant son propre secret...mais c'est une tangente).

L'avantage est que même si quelqu'un s'empare de votre code, aucune ingénierie inverse ne permettra de retrouver la chaîne secrète car elle n'existe pas.

Notez que cela est mieux que l'obscurcissement seul. Avec l'obfuscation, si l'attaquant obtient votre code et peut l'exécuter dans son propre environnement, il peut attacher un débogueur et s'arrêter au moment où vous passez la chaîne au code AES. Ils n'ont pas à se soucier du nombre d'astuces que vous utilisez pour le brouiller. Il suffit de la regarder une fois que vous l'avez désembrouillée. Avec DPAPI, cela ne fonctionnera pas à moins qu'ils exécutent votre code dans le contexte de l'utilisateur... dans ce cas, la partie est terminée de toute façon.

Je ne dis pas que DPAPI est parfait, mais dans ce cas, je l'envisagerais vraiment avant de recourir uniquement à l'obscurcissement. (Vous pouvez toujours faire passer votre code par un outil d'obfuscation : c'est aussi une bonne chose, mais ce n'est pas suffisant).

*Si ce n'est pas le cas, pouvez-vous le fournir au moment de l'installation/de la configuration initiale ? J'en ai vu qui s'installent avec la clé secrète en clair dans un fichier, puis le programme la crypte à la première utilisation.