3 votes

Ajouter un cryptage basé sur RSA au service WCF sans certificats

Je cherche un moyen de crypter les messages entre le client et le serveur en utilisant WCF. WCF offre de nombreux mécanismes de sécurité intégrés pour crypter le trafic entre le client et le serveur, mais il semble qu'il n'y ait rien qui corresponde à mes besoins.

Je ne veux pas utiliser de certificats car ils sont trop compliqués, alors ne me suggérez pas d'utiliser des certificats, s'il vous plaît. Je n'ai pas besoin de confidentialité, alors j'ai pensé que je ferais mieux d'utiliser le RSA simple.

Je veux une vraie sécurité Il n'y a pas de clé codée ou quelque chose comme ça. Je pensais avoir une paire de clés publique/privée générée à chaque fois que le serveur démarre. Les deux clés ne seront stockées que dans la RAM. Ensuite, lorsqu'un client se connecte, cela devrait se passer exactement comme pour SSL. Comme décrit aquí .

1. échanger une certaine forme de paire de clés privée/publique ; le serveur génère une paire de clés, garde la clé privée pour lui et partage la clé publique avec le client (par exemple, par l'intermédiaire d'un message WCF).

2. à l'aide de cette paire de clés privée/publique, échanger un secret commun partagé, par exemple une "clé de cryptage" qui crypte symétriquement vos messages (et puisque c'est symétrique, le serveur peut utiliser la même clé pour décrypter les messages).

3. mettre en place une infrastructure sur votre client (par exemple une extension WCF appelée comportement) pour inspecter le message avant qu'il ne soit envoyé et le crypter avec votre secret partagé.

Ce serait sûr, n'est-ce pas ?

Existe-t-il une solution pour archiver ce que je viens de décrire ? Si ce n'est pas le cas, je vais la créer moi-même. Par où dois-je commencer ? Quel type de comportement WCF personnalisé est le meilleur à mettre en œuvre ?


EDIT : Comme ce n'est PAS sécurisé, j'adopterai l'approche suivante :

Lors de l'installation du composant serveur, un nouveau certificat X509 sera généré et automatiquement ajouté au magasin de certificats (du serveur). La partie publique de ce certificat généré sera dynamiquement incluse dans l'installation du client. Lors de l'exécution de l'installation du client sur la machine cliente, le certificat sera installé dans le magasin de certificats Windows de confiance du client.

Il n'y a donc pas de travail supplémentaire lors de l'installation du produit et tout devrait être sécurisé, comme nous le souhaitons.

4voto

Morten Frederiksen Points 2518

4voto

Shawn D. Points 1881

Vous avez dit que vous ne vouliez pas utiliser de certificats. Je ne vous imposerai pas l'utilisation de certificats, mais il y a une chose que vous ne comprenez pas, c'est que les certificats servent à quelque chose.

Un certificat prouve que la clé avec laquelle vous négociez une connexion SSL appartient à l'entité à laquelle vous pensez qu'elle appartient. Si vous disposez d'un moyen de vous assurer que c'est le cas sans utiliser de certificats, utilisez les clés brutes.

Le problème est qu'à l'étape 1 :

1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)

Comment le client peut-il savoir que la clé publique qu'il a reçue du serveur n'a pas été interceptée par un homme du milieu et remplacée par la clé de l'homme du milieu ?

C'est la raison d'être des certificats. Si vous ne voulez pas les utiliser, vous devez trouver un autre moyen de résoudre ce problème.

Avez-vous un petit groupe de clients bien connus ? Est-il possible de préconfigurer la clé publique du serveur sur le client ?

2voto

GameScripting Points 2922

Non, ce ne serait pas sûr !

Comme il n'y a pas de confidentialité, un pirate peut effectuer une attaque de type "men in the middle", et toute la sécurité disparaît.

Le seul moyen réellement sûr de crypter les messages entre le serveur et le client IS d'utiliser des certificats numériques.

1voto

John Wu Points 2633

Je suis désolé, les deux seules méthodes permettant de fournir des communications sécurisées sont les suivantes :

  1. Utiliser une infrastructure à clé publique qui comprend une chaîne de confiance, c'est-à-dire des certificats.

ou

  1. Utiliser un secret partagé, c'est-à-dire une clé codée en dur.

Rien d'autre n'aborde tous les vecteurs d'attaque courants connus, tels que les attaques de type "man-in-the-middle", les attaques par rejeu, etc. Telle est la dure réalité.

D'autre part, je peux vous proposer une alternative qui pourrait atténuer quelque peu votre problème : Utilisez à la fois .

  1. Écrire un service web très, très simple dont la seule tâche est de générer des clés symétriques. Publier ce service via SSL. Exiger l'authentification de l'utilisateur final pour obtenir une clé symétrique.

  2. Rédigez le reste de vos services sans SSL mais en utilisant les clés symétriques publiées par le premier service.

De cette façon, votre application principale n'a pas à s'occuper des certificats.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X