L'envoi de messages entre deux clients, comment vérifier l'identité de l'expéditeur?
-
28-09-2019 - |
Question
Alors, supposons que vous avez deux clients, C1 et C2, chaque client a un GUID associé.
Comment comptez-vous, lorsque vous recevez un message sur le C2 que soi-disant vient de C1 (en vérifiant le GUID et voyant qu'il correspond au GUID de C1), mais étant donné que le message n'est pas garanti sont venus de C1 (C3 pourrait juste avoir envoyé le message, envoyer le GUID de C1 dans l'en-tête du message) il doit y avoir une vérification que le message provient réellement de C1.
J'ai été à la recherche 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 faire essentiellement un contrôle comme celui-ci (code pseudo python):
message.GUID == RSADecrypt(C2.PRIVATE_KEY, message.ENCRYPTED_GUID)
Est-ce une approche viable? Ou est-il une autre façon intelligente / plus évidente pour vérifier l'expéditeur d'un message?
La solution
Asymétrique Des algorithmes ont été inventées à cette fin, qui est la façon dont le travail de signatures numériques.
Cependant, votre approche a quelques problèmes. Toute personne avec la clé publique du destinataire pourrait fausse la signature. En outre, la signature ne change pas du tout! Tout le monde peut intercepter les messages faux étant un expéditeur valide. Le but de chiffrement est assymétrique pour vaincre ces problèmes avec les échanges clés, il y a le concept de la signature numérique, qui est essentiellement un hachage crypté asymétriquement du message que vous Jetant autour.
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 tours avec cela pour Python:
Autres conseils
Le problème avec cette méthode est que toute machine pourrait alors saisir la guid et rsa crypté-guid et les transmettre la même chose. Vous avez pas vraiment créé aucun critère défi / réponse unique qui ne peut être devinaient par le client de réception. Qu'est-ce que vous auriez besoin serait quelque chose qui est tout à fait unique et ne peut pas ê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 cryptage RSA serait fait avec la clé publique Client2 si la clé privée qui ne Client2 pouvait déverrouiller. Utilisation de la ClientName, Client2 pourrait récupérer le GUID attendu d'une source de données, puis correspondre au GUID retourné contre celui du cryptage. J'ai intégré l'utilisation d'un horodatage sous forme de sel de sorte que la chaîne cryptée est différemment à chaque fois. Il est considéré comme très faible d'utiliser un horodatage comme pour un sel randomisation, mais il obtient le point à travers. D'autres algorithmes plus sûrs / aléatoires pourraient être mises en œuvre.
Quelqu'un messages d'espionnage entre un client et le serveur sera en mesure de créer de nouveaux messages, a le GUID
du client ne changera jamais, ni RSA-ENCRYPTED-GUID
.
Envisager de passer à ce modèle de message:. [GUID; ENCRYPTED_CONTENT_CHECKSUM; CONTENT]
Checksum(message.CONTENT) ==
RSADescrypt(C1.PUBLIC_KEY, message.ENCRYPTED_CONTENT_CHECKSUM)
Pourtant, tout le monde messages espionnant peut renvoyer des messages précédemment envoyés.
Les clés publiques et privées sont la voie à suivre. Je considère que vous ne se soucient pas de chiffrer les données, mais vous veiller à ce 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 ne vous inquiétez pas si le message a été intercepté, mais vous faites attention qu'il n'a pas été forgé.
Comp1 signera numériquement le message avec sa clé privée
COMP2 intercepte le message de Comp1 à Comp3, mais ne peut pas changer le message sans invalider la signature
COMP2 transmet le message sur Comp3
Comp3 utilisera la clé publique de 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 chiffrer le message.
Comp1 prendra cette clé de cryptage et chiffrer avec la clé publique
de Comp3COMP2 intercepte le message, mais ne peut le lire sans clé privée Comp3
COMP2 transmet le message sur Comp3
Comp3 utilisera pour décrypter la clé AES clé privée it
Comp3 décrypte le message entier à l'aide de la touche AES
Comp3 validera le message en déchiffrant la signature avec la clé publique Comp1.
Signature contient un hachage du message, si la correspondance de hachage et hachage du message, les données sont intactes.
Vous pouvez inclure les GUIDs dans la charge utile à utiliser comme une recherche de décider qui des clés publiques à utiliser.
P.S. Vous voulez utiliser les méthodes intégrées pour signer un message. Laissez le cadre faire le hash / etc