Ce scénario est-il sûr ?

Question

J'utilise RSA pour crypter la communication entre un serveur et un client. Disons que nous avons 2 clés asymétriques, clé 1 et 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 la clé2
2. le client se connecte au serveur
3. envoi de la clé2(publique) cryptée avec la clé1(publique)
4. à partir de maintenant, le serveur enverra toutes les données crypté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

D'après ce que je vois, cela devrait empêcher une attaque de type "man-in-the-middle", ou est-ce que j'ai raté quelque chose ? Au point 7, le client devrait savoir si quelqu'un essaie de donner au serveur la mauvaise clé pour chiffrer, car personne d'autre que le serveur ne peut déchiffrer key2(public).

S'il y a quelque chose à faire pour améliorer la sécurité, dites-le moi.

Answer 1

La meilleure chose que vous puissiez faire pour améliorer la sécurité est d'utiliser une conception existante et de ne pas essayer de réinventer la roue. Je ne dis pas que ce que vous avez fait est nécessairement mauvais, mais simplement que de nombreuses personnes beaucoup plus intelligentes que vous et moi ont passé beaucoup de temps à réfléchir à ce problème. Utilisez plutôt TLS.

Answer 2

Tant que la clé1 (privée) n'a pas été interceptée d'une manière ou d'une autre par un tiers, votre scénario semble sûr.

Je crois que j'ai vu ça quelque part dans un article en fait. Dans cet article, Alice donne à Bob une boîte non verrouillée (clé 1 publique), puis Bob y met plusieurs de ses propres boîtes (clé 2 publique), la verrouille et la renvoie à Alice. Alice ouvre alors la boîte (clé 1 privée) et peut maintenant 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, donc je dirais que c'est sûr.

Answer 3

Non, ce protocole n'est pas sûr.

Un homme du 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 qu'il reçoit.

Bien sûr, vous pourriez améliorer votre protocole pour résoudre ces problèmes flagrants, mais il y en aurait d'autres. Si vous les résolvez tous, vous aurez quelque chose qui correspondra à 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 reçoit ; votre proposition ne fournit aucune sécurité à ce niveau. Cependant, si vous êtes préoccupé par la confidentialité, vous avez toujours un problème, parce que le MITM pourrait faire passer des messages dans les deux sens sans les modifier jusqu'à ce qu'il voit ce qu'il veut trouver, parce que vous n'avez aucune confidentialité sur les messages du client.

Votre proposition semble viser à garantir 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 falsifié, permettez au serveur de vérifier l'intégrité du message avant d'y donner suite.

Answer 4

Je suis d'accord, utilisez simplement TLS.

De même, quelle valeur les étapes 5 à 7 apportent-elles ? Un MITM souhaitant réaliser une attaque qui fonctionnerait après les étapes 1 à 4 (par exemple, une sorte de DoS en faisant passer n transactions puis en s'arrêtant, ce qui oblige à recommencer depuis le début) pourrait le faire tout aussi bien après les étapes 5 à 7. Qu'ajoutent-ils ?

-- MarkusQ

Answer 5

Je suis d'accord avec Greg pour dire que vous réinventez la roue . Ce que vous décrivez essentiellement est une forme basique de échange de clés . Par ailleurs, pour garantir la sécurité contre les attaques de l'homme du milieu, il faut également être certain de l'identité du serveur, c'est-à-dire s'assurer que le client peut savoir avec certitude que ce qu'il croit être public(key1) est réellement celui du serveur et non celui de l'homme du milieu (par exemple en utilisant une AC ou en ayant la public(key1) du serveur dans un stockage sécurisé du côté client).

En outre, il existe considérations supplémentaires vous devez être conscient du point de vue des systèmes, tels que :

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