Ce scénario est-il sécurisé?

Question

J'utilise RSA pour chiffrer la communication entre un serveur et un client. Disons que nous avons 2 clés asymétriques, la clé 1 et la clé2.

Le serveur a la clé1 (privée) depuis le début et le client a la clé1 (publique)

Voici donc le scénario:

1. le client génère key2
2. client se connecte au serveur
3. envoi de la clé 2 (publique) chiffrée avec clé1 (publique)
4. à partir de maintenant, le serveur enverra toutes les données chiffrées avec la clé2 (publique)
5. le client envoie des données aléatoires au serveur
6. le serveur renvoie les mêmes données hachées
7. le client vérifie que les données sont correctes

Autant que je sache, cela devrait empêcher une attaque de l'homme du milieu, ou est-ce que je manque quelque chose? Au point 7, le client doit savoir si quelqu'un essaie de donner au serveur la mauvaise clé à chiffrer, car personne d'autre que le serveur ne peut déchiffrer la clé2 (publique).

S'il y a quelque chose à faire pour améliorer la sécurité, merci de me le dire.

Answer 1

La meilleure chose à faire pour améliorer la sécurité est d'utiliser un design existant et de ne pas tenter de réinventer la roue. Je ne dis pas que ce que vous avez fait est nécessairement faux, mais juste que beaucoup de gens beaucoup plus intelligents que vous et moi avons passé beaucoup de temps à réfléchir à ce problème. Utilisez TLS à la place.

Answer 2

Tant que key1 (private) n'a pas été intercepté par un tiers, votre scénario semble sécurisé.

Je pense avoir vu cela quelque part dans un document. Dans celui-ci, Alice a remis à Bob une boîte déverrouillée (clé 1 publique), puis Bob y a mis une série de ses propres boîtes (clé 2 publique), la verrouille et la renvoie à Alice. Alice ouvre ensuite la boîte (clé 1 privée) et peut désormais sceller en toute sécurité les boîtes que Bob vient de lui donner.

Malgré l'analogie avec la boîte, c'est essentiellement ce que vous faites, alors je dirais que c'est sécurisé.

Answer 3

Je suis d'accord, utilisez simplement TLS.

En outre, quelle valeur les étapes 5 à 7 fournissent-elles? Un MITM souhaitant lancer une attaque qui fonctionnerait après les étapes 1 à 4 (par exemple, une sorte de DoS en passant n transactions puis en s’arrêtant, obligeant à réessayer à partir du début) pourrait le faire aussi bien après 5-7. Qu'ajoutent-ils?

- MarkusQ

Answer 4

Non, ce protocole n'est pas sécurisé.

Un homme au milieu peut intercepter les données envoyées par le client et envoyer ce qu'il veut au serveur, puisque vous n'avez spécifié aucun mécanisme permettant au serveur d'authentifier le client ou de vérifier l'intégrité des messages. reçoit.

Bien sûr, vous pourriez rédiger votre protocole pour résoudre ces problèmes criants, mais il y en aurait d’autres. Si vous corrigez tous ces problèmes, vous obtiendrez quelque chose qui correspond à TLS ou à SSH, alors pourquoi ne pas commencer par là?

@ Petoj - le problème sur lequel je me concentrais était celui du serveur faisant confiance aux messages qu'il recevait; votre proposition ne fournit aucune sécurité là-bas. Toutefois, si vous êtes inquiet pour la confidentialité, vous avez toujours un problème, car le MITM peut transmettre des messages sans modification jusqu’à ce qu’il voie ce qu’il souhaite trouver, car vous n’avez aucune confidentialité sur les messages du client.

Votre proposition semble viser à assurer l’intégrité des messages du client. Vous avez développé le protocole au point que le client ne peut pas faire la distinction entre une attaque et une défaillance du réseau. Plutôt que d'essayer d'aider le client à déterminer si le serveur a agi sur un message altéré, autorisez-le à vérifier l'intégrité du message avant d'y donner suite.

Answer 5

Je conviens avec Greg que vous réinventez la roue . Ce que vous décrivez essentiellement est une forme de base de échange de clé . Incidemment, afin de garantir sa sécurité contre les attaques de type "man-in-the-middle", vous devez également être certain de l'identité du serveur, c'est-à-dire que le client peut savoir avec certitude que ce qu'il croit être public (clé 1) est réellement du serveur et non de l'homme du milieu (par exemple, en utilisant une autorité de certification ou en plaçant le public du serveur (clé 1) dans un stockage sécurisé côté client.)

De plus, il existe des considérations supplémentaires à prendre en compte du point de vue des systèmes, telles que:

• Le chiffrement à clé asymétrique est plus lent que le chiffrement à clé symétrique, ce qui est l'une des raisons pour lesquelles des solutions existantes telles que TLS utilisera le cryptage à clé asymétrique uniquement pour négocier une clé symétrique temporaire, qui est ensuite utilisée pour le cryptage de canal.
• si l'analyse du trafic effectuée par un tiers parvient à déchiffrer une clé symétrique temporaire, vous n'avez pas compromis votre paire de clés asymétrique. Vous êtes encouragé à renégocier la clé temporaire assez souvent pour cette raison. Généralement, générer un nouveau key2 dans votre scénario atténuerait cet aspect.