Envoi de messages entre deux clients, comment vérifier l'identité de l'expéditeur?

Question

Supposons donc que vous avez deux clients, C1 et C2, chaque client a un GUID associé. Comment, quand vous recevez un message sur C2, comment est-ce que soi-disant vient de C1 (en vérifiant le GUID et en voyant qu'il correspond au GUID de C1), mais puisque le message n'est pas garanti d'avoir provenu de C1 (C3 pourrait simplement avoir envoyé le message, en envoyant le GUID de C1 dans l'en-tête du message) il doit y avoir une certaine vérification que le message provient réellement de C1.

que je cherchais en utilisant le cryptage asymétrique (RSA) pour avoir C1 envoyer un message qui se compose de [C1.GUID; RSAEncrypt(C2.PUBLIC_KEY, C1.GUID); MESSAGE], puis laisser C2 essentiellement faire un chèque comme celui-ci (code pseudo python):

message.GUID == RSADecrypt(C2.PRIVATE_KEY, message.ENCRYPTED_GUID) 

Est-ce une approche viable? Ou y a-t-il une autre façon intelligente/plus évidente de vérifier l'expéditeur d'un message?

Answer 1

Des algorithmes asymétriques ont été inventés à de telles fins, c'est ainsi que fonctionnent les signatures numériques.

Cependant, votre approche a quelques problèmes. N'importe qui avec la clé publique du destinataire pourrait fausser la signature. De plus, la signature ne change pas du tout! Toute personne interceptant les messages peut simuler être un expéditeur valide. Le but du cryptage asymétrique est de vaincre ces problèmes avec les échanges de clés, il y a le concept de la signature numérique, qui est essentiellement un hachage asymétriquement crypté du message que vous jetez.

Pour RSA, vous devez faire un peu plus afin de créer une signature numérique à partir de l'algorithme de base, voir wikipedia pour plus de détails: http://en.wikipedia.org/wiki/RSA#Signing_messages

Je venais d'utiliser un algorithme de signature numérique à partir d'une bibliothèque. Première recherche Google tourne avec cela pour Python:

http://www.example-code.com/python/pythonrsa.asp

http://www.chilkatsoft.com/dsa-python.asp

Answer 2

Le problème avec cette méthode est que n'importe quelle machine pourrait alors capturer le guid et rsa-encrypted-guid et les passer quand même. Vous n'avez pas vraiment créé de critères de défi/réponse uniques qui ne peuvent être devinés que par le client destinataire. Ce dont vous auriez besoin serait quelque chose qui soit complètement unique et ne puisse être obtenu simplement en regardant les paramètres passés. Peut-être quelque chose comme:

[ClientName; RSA-ENCRYPTED(GUID+Timestamp); MESSAGE] 

Dans cette méthode, le chiffrement RSA serait fait avec la clé publique Client2 de sorte que seule la clé privée Client2 pourrait déverrouiller. À l'aide de ClientName, Client2 peut extraire le GUID attendu à partir d'une source de données, puis faire correspondre le GUID retourné avec celui du chiffrement. J'ai incorporé l'utilisation d'un horodatage comme un sel de sorte que la chaîne cryptée sort différemment à chaque fois. Il est considéré comme très faible d'utiliser un horodatage comme une randomisation pour un sel, mais il fait passer le point. D'autres algorithmes plus sécurisés/aléatoires pourraient être implémentés.

Answer 3

Toute messages d'espionnage entre un client et le serveur sera en mesure de créer de nouveaux messages, n'a jamais changer de client GUID, ni RSA-ENCRYPTED-GUID.

Envisagez de passer à ce modèle de message: [GUID; ENCRYPTED_CONTENT_CHECKSUM; CONTENT].

Checksum(message.CONTENT) == 
    RSADescrypt(C1.PUBLIC_KEY, message.ENCRYPTED_CONTENT_CHECKSUM) 

Cependant, tout message d'espionnage peut renvoyer des messages précédemment envoyés.

Answer 4

Les clés publiques et privées sont la voie à suivre. Je vais supposer que vous ne vous souciez pas de crypter les données, mais vous vous souciez que les données sont "autorisées".

Disons que vous avez 3 ordinateurs

Comp1 COMP2 Comp3

Disons que vous voulez aussi Comp1 envoyer un message à Comp3. vous vous en fichez si le message a été intercepté, mais vous vous souciez qu'il n'ait pas été falsifié.

Comp1 signera numériquement le message avec sa clé privée

COMP2 interceptera le message de Comp1 à Comp3, mais ne peut pas changer le message sans invalider la signature

COMP2 transmettra le message sur Comp3 Comp3 utilisera la clé publique Comp1 pour déchiffrer la signature et utiliser le hachage dans la signature pour valider le contenu.

Maintenant, si vous voulez chiffrer les données, vous devez ajouter une étape supplémentaire

Comp1 signera numériquement le message avec sa clé

privée Comp1 va générer une clé de cryptage aléatoire (généralement AES) et crypter le message.

Comp1 prendra cette clé de cryptage et chiffrer avec la clé publique de Comp3

COMP2 intercepte le message, mais ne peut le lire sans clé privée Comp3

COMP2 transmettra le message sur Comp3

Comp3 utilisera sa clé privée pour déchiffrer la clé AES

Comp3 déchiffrera le message entier en utilisant la clé AES

Comp3 validera le message en décryptant la signature avec la clé publique de Comp1. La signature contient un hachage du message, si le hachage et le hachage du message correspondent, alors les données sont intactes.

Vous pouvez inclure les GUID dans la charge utile à utiliser comme référence pour décider des clés publiques à utiliser.

post-scriptum Vous voudrez utiliser les méthodes intégrées pour signer un message. Laisser le cadre faire le hachage/etc