Je travaille sur une application qui crypte les paramètres de fichier de configuration pour un serveur Web ASP.NET. La méthode de cryptage que je suis implémentée est d'envelopper des données à l'aide de AES et de RSA. Je génère une clé AES, en utilisant cette clé AES pour chiffrer mes données, puis crypter la clé AES avec la clé publique d'un certificat dans mon magasin de certificats Windows. J'ai ensuite sauvegardé les données, ainsi que la touche AES cryptée et le numéro de série de certificat utilisé pour le chiffrer, retour au fichier de configuration.
Lorsque je veux accéder à ces données, j'ai lu le numéro de série du certificat utilisé pour Cryptez la clé AES, retirez la clé privée de ce certificat et déchiffrer la clé AES, puis décrypter les données à l'aide de cette touche. Voici où je ne suis pas sûr de mon niveau de sécurité.
Pour accéder à la clé privée associée au certificat, je dois marquer la clé privée comme exportable et donner à l'utilisateur que mon application est exécutée sous accès à la clé privée. Comme il s'agit d'un serveur ASP.NET, cet utilisateur est "Services de réseau". Je suis sûr que vous pouvez voir pourquoi ce serait un problème de sécurité. Fondamentalement, si quelqu'un devait briser mon serveur ASP.NET sur le Web, peut-être par une sorte d'injection, ils auraient accès à cette clé privée, n'est-ce pas?
Est-ce que quelqu'un a des suggestions sur Comment je pourrais rendre mon modèle plus sécurisé?
Fonction Decrypt: merci.
4 Réponses :
Si vous avez un certificat avec une clé privée, il est logique d'utiliser le cryptage PKCS n ° 7 / CMS de la clé AES. Cela vous permet de déchiffrer les données avec des clés privées non exportables.
Malheureusement .NET Ne semble pas proposer des cours pour le cryptage CMS. Cryptoapi offre de telles fonctions ( CryptecryptMessage et cryptdecryptmessage ), mais ils ont besoin être appelé via p / invoke, qui peut être dans une certaine mesure non triviale. Pour C # échantillon de faire ce Voir le code source ici .
Une autre option serait d'utiliser notre Secureblackbox Composants (TelMessageCryptor, TelMessageDecryptor), bien que dans votre cas, cela pourrait être une overcilleuse.
Pouvez-vous me donner un exemple d'utilisation de ces deux composants (TelMessageCryptor, TelMessageDecryptor) pour chiffrer et déchiffrer un fichier avec le format PKCS # 7 et l'utilisation de certificats numériques? J'ai téléchargé le package complet de Secureblackbox, mais je n'ai pas pu trouver d'exemple de ces composants.
@Dkangelito a répondu à notre forum de soutien. Échantillons \ Langue \ PKIBLACKBOX \ MessagesDemo les montre.
@Eugene Mayevski 'Eldos Corp pouvez-vous donner un point de pointeur sur cette page également Stackoverflow.com/Questtions/34549899/...
juste en écrivant Cela ne signifie pas que vous attribuez la "touche" réelle. Vous pouvez rendre la clé privée non exportable et pourrions toujours effectuer un déchiffrement.
Je pense qu'il y a des conflits inhérents à votre modèle de sécurité. Vous souhaitez une application exécutée sous l'utilisateur "Services réseau" pour pouvoir déchiffrer le fichier de configuration, mais vous souhaitez que les informations cryptées soient en sécurité, même si l'utilisateur "Services réseau" est compromis. Ces deux buts sont en attente - que l'utilisateur puisse accéder aux données ou qu'il ne peut pas. Je pense que le mieux que vous puissiez faire est de se spécialiser l'accès à la sécurité, de sorte que si "Services réseau" sur une machine est compromis, il ne compromet pas la sécurité des autres utilisateurs ou d'autres machines. C'est pourquoi le modèle de sécurité Windows fournit à chaque utilisateur chaque machine avec sa propre clé privée, et c'est la clé utilisée par DPAPI pour chiffrer / déchiffrer les fichiers de configuration.
Vous dites que dans votre modèle, vous cryptez les informations de configuration avec un ensemble de clés standard. Dans ce modèle, si un utilisateur approuvé sur une machine est compromis, l'attaquant gagne la clé pour accéder à toutes les données de configuration cryptées pour tous les utilisateurs de toutes les machines. Vous dites que vous utilisez des clés gérées en cas de défaillance de la machine. Je suggérerais qu'il soit plus sûr de sauvegarder et de gérer les données cryptées, puis de sauvegarder et de gérer les clés utilisées pour accéder à ces données.
Ma suggestion utilise les méthodes intégrées .NET de chiffrer / décrypter les données de configuration, qui utilise la clé privée Windows de l'utilisateur sur la machine locale. (Il y a quelques exemples d'implémentation de la norme APRASOCH ici: http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx et ici: http://www.codeproject.com/kb/security/proteintconfigwinapps.aspx ) Si des données sont mises dans les fichiers de configuration essentielles et devraient être récupérées en cas de panne de la machine, envoyez ensuite ces données à votre base de données ou à un autre magasin de données central comme sauvegarde. Cela évite d'utiliser la même clé gérée ou des mêmes clés pour tous vos déploiements.
Quelqu'un a-t-il des suggestions sur la manière dont je pourrais rendre mon modèle plus sûr?
Vous êtes correct en ce que tout service exécutant sous Services réseau est compromis pourrait potentiellement accéder à la clé privée. En 2005, Microsoft le réalisa et de commencer à créer des comptes de service uniques pour limiter les dommages causés par un service compromis communé , tels que Services réseau . Par exemple, SQL Server a été transféré dans son propre compte de service, IIRC.
Le problème sous-jacent est un problème de conception de sécurité avec le modèle de Microsoft et que vous ne pouvez pas faire beaucoup avec cela. Microsoft le réalisa et s'est déplacé vers un modèle légèrement différent avec Cryptong, IIRC. Sous Cryptong, les opérations utilisant la clé privée sont hors processus et IPC permet de communiquer les demandes et des résultats entre le service et le processus qui effectue des opérations clés. CELI PROPRIÉTAIRE ÉTAIRE PARTICULIER LA PREMIÈRE QUE VOUS ÊTES PRÉCOIRES.
Même dans le nouveau modèle, vous aurez toujours besoin de logiciels consacrés au modèle. Vous devriez bien vouloir dire, IIS 7, mais Apache peut causer des problèmes car son modèle ne reconnaît que le système de fichiers ACLS.
Les opérations de clés mobiles hors du processus deviennent une pratique standard. Par exemple, GNUPG fait la même chose. Gnupg utilise une bibliothèque appelée Libassuan qui effectue le maréchalage des demandes et des résultats entre consommateurs et producteurs.
Je ne vous inquiéterais pas trop sur les préoccupations d'efficacité entre le client et le serveur dans le modèle hors processus. Les tuyaux Windows, les tuyaux UNIX et les prises de domaine UNIX sont écartés rapidement. Aussi, c'est beaucoup comme Dr. Jon Bentley a déclaré: s'il ne doit pas être correct, je peux le rendre aussi rapide que vous le souhaitez.
Vous prenez une mauvaise utilisation du certificat et une clé privée. Une implémentation appropriée n'a pas besoin de tirer la clé privée pour effectuer le déchiffrement. Les fonctions Cryptoapi vous permettent d'effectuer des opérations en utilisant cette clé sans l'avoir extractible. Comme vous n'avez pas spécifié ce que vous utilisez exactement vos fonctions, je ne peux pas commenter plus loin.
@Eugene, je suis instanciant d'un rsacryptoserviceProvider à partir du X509Certificate.privatekey, j'ai sorti de la boutique de certificats, puis décryptant en utilisant ça
@Eugene Mayevski 'Eldos Corp, j'ai ajouté le code à ma question, merci.
Pourquoi n'utilisez-vous pas une fonctionnalité de cryptage standard de fichier ASP.NET .Config.
@Simon Mourier, ce cryptage utilise des touches de machine générées, nous utilisons des clés gérées que nous avons sauvegardées en cas d'échec de la machine. Je construis également cette bibliothèque à utiliser avec toutes les applications .NET, mais dans ce cas, c'est un serveur APS.NET.