[Q] sur Diffie-Hellman

Francois Grieu

19/07/2004 à 15:10

(Emmanuel Dreyfus) wrote:

Bob contacte Alice et ils font un DH authentifié. Mais Trudy connait la
clé privée de Bob. Que reste-t-il de la sécurité de la communication
entre Bob et Alice?

A vue de nez, je dirais que
- Bob est certain de parler avec Alice, que
- les communications entre Bob et Alice sont confidentielles
dans les deux sens,
- mais que Alice ne peut pas être certaine de bien parler avec Bob.

Pas à ma vue de nez. Si Trudy connait la clé privée de Bob, AMHA
Trudy (par une attaque active) peut se faire passer pour Bob aux
yeux d'Alice, et donc la confidentialité de tout ce qu'émet Alice
en croyant l'adresser à Bob est compromise.

François Grieu

manu

19/07/2004 à 15:31

Francois Grieu wrote:

Bob contacte Alice et ils font un DH authentifié. Mais Trudy connait la
clé privée de Bob. Que reste-t-il de la sécurité de la communication
entre Bob et Alice?

A vue de nez, je dirais que
- Bob est certain de parler avec Alice, que
- les communications entre Bob et Alice sont confidentielles
dans les deux sens,
- mais que Alice ne peut pas être certaine de bien parler avec Bob.

Pas à ma vue de nez. Si Trudy connait la clé privée de Bob, AMHA
Trudy (par une attaque active) peut se faire passer pour Bob aux
yeux d'Alice, et donc la confidentialité de tout ce qu'émet Alice
en croyant l'adresser à Bob est compromise.

Mais si la supposition "Trudy doit connaitre les deux clés privées pour
faire un MiM sur l'echange DH authentifié" est exacte, alors Trudy dotée
de la clé privée de Bob ne pourra pas pour autant obtenir le secret
choisi au cours de l'echange DH par Bob et Alice, et c'est ce secret qui
va leur servir pour communiquer ensuite.

La seule attaque possible (de ce que je comprend) serait que Trudy se
fasse passer pour Bob et communique avec Alice. Mais elle ne peut pas
faire de MiM et intercepter leurs communication. Si?

--
Emmanuel Dreyfus

Francois Grieu

19/07/2004 à 17:06

(Emmanuel Dreyfus) dit:

Francois Grieu wrote:

Bob contacte Alice et ils font un DH authentifié. Mais Trudy connait la
clé privée de Bob. Que reste-t-il de la sécurité de la communication
entre Bob et Alice?

A vue de nez, je dirais que
- Bob est certain de parler avec Alice, que
- les communications entre Bob et Alice sont confidentielles
dans les deux sens,
- mais que Alice ne peut pas être certaine de bien parler avec Bob.

Pas à ma vue de nez. Si Trudy connait la clé privée de Bob, AMHA
Trudy (par une attaque active) peut se faire passer pour Bob aux
yeux d'Alice, et donc la confidentialité de tout ce qu'émet Alice
en croyant l'adresser à Bob est compromise.

Mais si la supposition "Trudy doit connaitre les deux clés privées pour
faire un MiM sur l'echange DH authentifié" est exacte, alors Trudy dotée
de la clé privée de Bob ne pourra pas pour autant obtenir le secret
choisi au cours de l'echange DH par Bob et Alice, et c'est ce secret qui
va leur servir pour communiquer ensuite.

Habituellement, le terme "clé privée de X" désigne une information
normalement connue seulement de X. Appliquée à X=Alice, et puisque Bob
peut exécuter le protocole, il n'a pas besoin pour ce faire de la
clé privée d'Alice. Donc Trudy, s'il a la clé privée de Bob (et les
autres éléments réputés publics), peut sans connaitre la clé privée
d'Alice faire aussi bien que Bob en matière d'authentification après
d'Alice, et de déchiffrement de ce qu'elle émet.

La seule attaque possible (de ce que je comprend) serait que Trudy se
fasse passer pour Bob et communique avec Alice. Mais elle ne peut pas
faire de MiM et intercepter leurs communication. Si?

Mon assertion est que Trudy, avec la clé privée de Bob (et les
éléments publics), peut obtenir l'information que Alice crois envoyer
à Bob, mais envoi en fait dans une communication établie avec Trudy,
c'est à dire chiffrée avec une clé commune connue seulement de
Alice et Trudy.

La proposition "Trudy doit connaitre les deux clés privées pour
faire un MiM sur l'echange DH authentifié" s'applique AMHA au cas
où Trudy doit se greffer à l'insu de Bob et d'Alice sur une
communication réelle sans que son forfait ne soit jamais
détecté par Alice et Bob comparant l'historique de leurs échanges
par un canal intègre; ou que Alice et Bob s'échangent alternativement
une série de secrets, et que ceux de Bob sont vérifiables par Alice.

Si par contre on est dans la situation où Alice doit transmettre
un secret à Bob, mais que Bob n'a rien de secret à dire, genre:
Bob: c'est quoi le secret aujourd'hui ?
Alice: "chemin valparaiso"
Bob: merci, a demain
alors Trudy (avec la clé privée de Bob) peut obtenir le secret,
au moins le premier jour, en se faisant passer pour Bob.
Trudy peut même essayer de parvenir à ce que cela dure en envoyant
un fax à Bob, semblant provenir de Alice, sur le thème: mon PC est en
panne, temporairement je t'envoi le secret par fax, aujourd'hui
c'est "chemin valparaiso".
Complément: Trudy intercepte tous les fax/couriers/email de Bob
à Alice sur le thème "impossible de te joindre" ou "c'est pas
sur cette procédure, arrête !" (note: où l'on voit l'avantage
concret du téléphone pour ce genre de message)
Variante: peut-être bien que Alice ne serait guère surprise de devoir
redonner le secret si Trudy, se faisant passer pour Bob quelques
minutes après que celui-ci ait obtenu le secret, demandait:
Bob: me suis gouré, c'est quoi le secret aujourd'hui ?
Alice: "chemin valparaiso"; moins fort sur la prune !
Bob: oui bon, merci, a demain.

François Grieu

manu@netbsd.org (Emmanuel Dreyfus) dit:

Francois Grieu <fgrieu@francenet.fr> wrote:

Bob contacte Alice et ils font un DH authentifié. Mais Trudy connait la
clé privée de Bob. Que reste-t-il de la sécurité de la communication
entre Bob et Alice?

A vue de nez, je dirais que
- Bob est certain de parler avec Alice, que
- les communications entre Bob et Alice sont confidentielles
dans les deux sens,
- mais que Alice ne peut pas être certaine de bien parler avec Bob.

Pas à ma vue de nez. Si Trudy connait la clé privée de Bob, AMHA
Trudy (par une attaque active) peut se faire passer pour Bob aux
yeux d'Alice, et donc la confidentialité de tout ce qu'émet Alice
en croyant l'adresser à Bob est compromise.

Mais si la supposition "Trudy doit connaitre les deux clés privées pour
faire un MiM sur l'echange DH authentifié" est exacte, alors Trudy dotée
de la clé privée de Bob ne pourra pas pour autant obtenir le secret
choisi au cours de l'echange DH par Bob et Alice, et c'est ce secret qui
va leur servir pour communiquer ensuite.

Habituellement, le terme "clé privée de X" désigne une information
normalement connue seulement de X. Appliquée à X=Alice, et puisque Bob
peut exécuter le protocole, il n'a pas besoin pour ce faire de la
clé privée d'Alice. Donc Trudy, s'il a la clé privée de Bob (et les
autres éléments réputés publics), peut sans connaitre la clé privée
d'Alice faire aussi bien que Bob en matière d'authentification après
d'Alice, et de déchiffrement de ce qu'elle émet.

La seule attaque possible (de ce que je comprend) serait que Trudy se
fasse passer pour Bob et communique avec Alice. Mais elle ne peut pas
faire de MiM et intercepter leurs communication. Si?

Mon assertion est que Trudy, avec la clé privée de Bob (et les
éléments publics), peut obtenir l'information que Alice crois envoyer
à Bob, mais envoi en fait dans une communication établie avec Trudy,
c'est à dire chiffrée avec une clé commune connue seulement de
Alice et Trudy.

La proposition "Trudy doit connaitre les deux clés privées pour
faire un MiM sur l'echange DH authentifié" s'applique AMHA au cas
où Trudy doit se greffer à l'insu de Bob et d'Alice sur une
communication réelle sans que son forfait ne soit jamais
détecté par Alice et Bob comparant l'historique de leurs échanges
par un canal intègre; ou que Alice et Bob s'échangent alternativement
une série de secrets, et que ceux de Bob sont vérifiables par Alice.

Si par contre on est dans la situation où Alice doit transmettre
un secret à Bob, mais que Bob n'a rien de secret à dire, genre:
Bob: c'est quoi le secret aujourd'hui ?
Alice: "chemin valparaiso"
Bob: merci, a demain
alors Trudy (avec la clé privée de Bob) peut obtenir le secret,
au moins le premier jour, en se faisant passer pour Bob.
Trudy peut même essayer de parvenir à ce que cela dure en envoyant
un fax à Bob, semblant provenir de Alice, sur le thème: mon PC est en
panne, temporairement je t'envoi le secret par fax, aujourd'hui
c'est "chemin valparaiso".
Complément: Trudy intercepte tous les fax/couriers/email de Bob
à Alice sur le thème "impossible de te joindre" ou "c'est pas
sur cette procédure, arrête !" (note: où l'on voit l'avantage
concret du téléphone pour ce genre de message)
Variante: peut-être bien que Alice ne serait guère surprise de devoir
redonner le secret si Trudy, se faisant passer pour Bob quelques
minutes après que celui-ci ait obtenu le secret, demandait:
Bob: me suis gouré, c'est quoi le secret aujourd'hui ?
Alice: "chemin valparaiso"; moins fort sur la prune !
Bob: oui bon, merci, a demain.

François Grieu

Vous avez filtré cet utilisateur ! Consultez son message

(Emmanuel Dreyfus) dit:

Francois Grieu wrote:

Bob contacte Alice et ils font un DH authentifié. Mais Trudy connait la
clé privée de Bob. Que reste-t-il de la sécurité de la communication
entre Bob et Alice?

A vue de nez, je dirais que
- Bob est certain de parler avec Alice, que
- les communications entre Bob et Alice sont confidentielles
dans les deux sens,
- mais que Alice ne peut pas être certaine de bien parler avec Bob.

Pas à ma vue de nez. Si Trudy connait la clé privée de Bob, AMHA
Trudy (par une attaque active) peut se faire passer pour Bob aux
yeux d'Alice, et donc la confidentialité de tout ce qu'émet Alice
en croyant l'adresser à Bob est compromise.

Mais si la supposition "Trudy doit connaitre les deux clés privées pour
faire un MiM sur l'echange DH authentifié" est exacte, alors Trudy dotée
de la clé privée de Bob ne pourra pas pour autant obtenir le secret
choisi au cours de l'echange DH par Bob et Alice, et c'est ce secret qui
va leur servir pour communiquer ensuite.

Habituellement, le terme "clé privée de X" désigne une information
normalement connue seulement de X. Appliquée à X=Alice, et puisque Bob
peut exécuter le protocole, il n'a pas besoin pour ce faire de la
clé privée d'Alice. Donc Trudy, s'il a la clé privée de Bob (et les
autres éléments réputés publics), peut sans connaitre la clé privée
d'Alice faire aussi bien que Bob en matière d'authentification après
d'Alice, et de déchiffrement de ce qu'elle émet.

La seule attaque possible (de ce que je comprend) serait que Trudy se
fasse passer pour Bob et communique avec Alice. Mais elle ne peut pas
faire de MiM et intercepter leurs communication. Si?

Mon assertion est que Trudy, avec la clé privée de Bob (et les
éléments publics), peut obtenir l'information que Alice crois envoyer
à Bob, mais envoi en fait dans une communication établie avec Trudy,
c'est à dire chiffrée avec une clé commune connue seulement de
Alice et Trudy.

La proposition "Trudy doit connaitre les deux clés privées pour
faire un MiM sur l'echange DH authentifié" s'applique AMHA au cas
où Trudy doit se greffer à l'insu de Bob et d'Alice sur une
communication réelle sans que son forfait ne soit jamais
détecté par Alice et Bob comparant l'historique de leurs échanges
par un canal intègre; ou que Alice et Bob s'échangent alternativement
une série de secrets, et que ceux de Bob sont vérifiables par Alice.

Si par contre on est dans la situation où Alice doit transmettre
un secret à Bob, mais que Bob n'a rien de secret à dire, genre:
Bob: c'est quoi le secret aujourd'hui ?
Alice: "chemin valparaiso"
Bob: merci, a demain
alors Trudy (avec la clé privée de Bob) peut obtenir le secret,
au moins le premier jour, en se faisant passer pour Bob.
Trudy peut même essayer de parvenir à ce que cela dure en envoyant
un fax à Bob, semblant provenir de Alice, sur le thème: mon PC est en
panne, temporairement je t'envoi le secret par fax, aujourd'hui
c'est "chemin valparaiso".
Complément: Trudy intercepte tous les fax/couriers/email de Bob
à Alice sur le thème "impossible de te joindre" ou "c'est pas
sur cette procédure, arrête !" (note: où l'on voit l'avantage
concret du téléphone pour ce genre de message)
Variante: peut-être bien que Alice ne serait guère surprise de devoir
redonner le secret si Trudy, se faisant passer pour Bob quelques
minutes après que celui-ci ait obtenu le secret, demandait:
Bob: me suis gouré, c'est quoi le secret aujourd'hui ?
Alice: "chemin valparaiso"; moins fort sur la prune !
Bob: oui bon, merci, a demain.

François Grieu

manu

19/07/2004 à 17:27

Francois Grieu wrote:

Habituellement, le terme "clé privée de X" désigne une information
normalement connue seulement de X.

Ok, mais là cette clé rivée n'est pas la donnée DH privée, (qui est de
toute façon tirée au hasard), on est bien d'accrod?

Appliquée à X=Alice, et puisque Bob
peut exécuter le protocole, il n'a pas besoin pour ce faire de la
clé privée d'Alice. Donc Trudy, s'il a la clé privée de Bob (et les
autres éléments réputés publics), peut sans connaitre la clé privée
d'Alice faire aussi bien que Bob en matière d'authentification après
d'Alice,

Ca d'accord.

et de déchiffrement de ce qu'elle émet.

Est-ce bien exact? Tel que je comprends le DH authentifié, la clé privée
de Bob ne sert pas pendant l'echange DH, il sert à la fin pour envoyer à
Alice une hash signée du secret déduit de l'echange DH. Ca permet
d'authentifier Bob.

Donc Trudy munie de la seule clé privée de Bob ne pourrait pas
intercepter le secret déduit de l'échange DH. Pas plus qu'elle ne
pourrait faire un MiM pendant le DH authentifié, puisque Bob s'apercevra
qu'il ne parle pas avec Alice, quand Trudy enverra sa hash du secret
signée avec une clé privée qui n'est pas celle d'Alice.

J'en reviens à mon impression: Trudy peut etablir une communication avec
Alice en se faisant passer pour Bob. Mais par contre, quand Bob obtient
une communication avec Alice, il est sur que Trudy ne paut pas
l'espionner.

Non?

--
Emmanuel Dreyfus

Francois Grieu

19/07/2004 à 18:47

(Emmanuel Dreyfus) dit:

Tel que je comprends le DH authentifié, la clé privée
de Bob ne sert pas pendant l'echange DH, il sert à la fin pour
envoyer à Alice une hash signée du secret déduit de l'echange DH.
Ca permet d'authentifier Bob.

Oui. Mais s'il est muni de la clé privée de Bob, Trudy va pouvoir
faire un échange DH avec Alice, puis établir la signature
qui l'authentifie auprès d'Alice, et Alice (ayant faussement
authentifié Bob), va ensuitetransmettre à Trudy des informations
destinées au seul Bob, informations dont la confidentialité se trouve
compromise.

J'en reviens à mon impression: Trudy peut etablir une communication
avec Alice en se faisant passer pour Bob. Mais par contre, quand Bob
obtient une communication avec Alice, il est sur que Trudy ne peut
pas l'espionner.

Tout à fait d'accord.

Pour autant, peut-on dire que "les communications entre Bob et Alice
sont confidentielles dans les deux sens" ? Non, puisque Alice risque
de communiquer avec Trudy en croyant communiquer avec Bob, et donc
de révéler à Trudy ce que seuls Alice et Bob devraient savoir.

François Grieu

manu

19/07/2004 à 21:36

Francois Grieu wrote:

Tel que je comprends le DH authentifié, la clé privée
de Bob ne sert pas pendant l'echange DH, il sert à la fin pour
envoyer à Alice une hash signée du secret déduit de l'echange DH.
Ca permet d'authentifier Bob.

Oui. Mais s'il est muni de la clé privée de Bob, Trudy va pouvoir
faire un échange DH avec Alice, puis établir la signature
qui l'authentifie auprès d'Alice, et Alice (ayant faussement
authentifié Bob), va ensuitetransmettre à Trudy des informations
destinées au seul Bob, informations dont la confidentialité se trouve
compromise.

Parfait.

Passons maintenant au cas pratique d'un VPN de type accès distant en
Xauth/IPsec ou L2TP/IPsec: il y a un echange IKE avec des certificats,
suivi d'une authentification par login/mot de passe.

Bob est un utilisateur qui se connecte à distance. Alice se transforme
en concentrateur d'accès VPN.

Si on immagine que Bob ait la clé privée de son certificat compromise,
alors il peut quand même contacter le concentrateur d'accès, verifier
son identité, et s'y authentifier, sans pour cela que l'on puisse
capturer ses crédits d'authentification, donc?

J'en arrive donc à la conclusion que le niveau de sécurité de ce type de
VPN avec un client dont la clé privée a été compromise est exactement le
même que dans le cas d'une authentification par mot de passe via SSH
(alors qu'on connait déjà la clé publique du serveur) ou par SSL. Exact?

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php

Francois Grieu

20/07/2004 à 07:04

(Emmanuel Dreyfus) dit:

Passons maintenant au cas pratique d'un VPN de type accès distant en
Xauth/IPsec ou L2TP/IPsec: il y a un echange IKE avec des certificats,
suivi d'une authentification par login/mot de passe.

On se perd un peu dans IKE, il y a tant de modes et d'options..
<http://www.faqs.org/rfcs/rfc2409.html>
Je suppose que l'on fonctionne avec authentification par signature,
et j'ignore les détails genre mode "Main" ou "Aggressive".

Bob est un utilisateur qui se connecte à distance. Alice se transforme
en concentrateur d'accès VPN.

Si on immagine que Bob ait la clé privée de son certificat compromise,
alors il peut quand même contacter le concentrateur d'accès, verifier
son identité, et s'y authentifier, sans pour cela que l'on puisse
capturer ses crédits d'authentification, donc?

Il me semble que oui, dans le principe. En fait, Bob a perdu seulement
une partie de ses secrets (sa clé privée) mais pas la totalité
(login/mot de passe), et dès l'instant où il ne communique ce qu'il
lui reste de secret qu'après avoir authentifié Alice, et qu'Alice
ne "baisse sa garde" qu'après avoir vérifié ce secret de Bob, alors
oui la confidentialité des échanges ultérieurs Alice->Bob semble
assurée [note: nous n'avons jamais douté de la confidentialité
des échanges Bob->Alice]

J'en arrive donc à la conclusion que le niveau de sécurité de ce
type de VPN avec un client dont la clé privée a été compromise est
exactement le même que dans le cas d'une authentification par mot
de passe via SSH (alors qu'on connait déjà la clé publique du serveur)
ou par SSL. Exact?

Moui, peut-être. En pratique, le diable est dans les détails.

En particulier: si le login/mot de passe n'est pas géré par le VPN
mais par un système ditinct, Trudy, avec la clé privée de Bob, peut
- se connecter au VPN d'Alice et envoyer des requètes autres que de
login au système derrière le VPN, pour essayer d'y trouver une
vulnérabilité exploitable.
- et/ou attendre que Bob soit connecté et ait tapé son login/mot de
passe; couper la liaison Bob/VPN-Alice; se connecter au VPN-Alice,
en se faisant passer pour Bob; et espérer que le système derrière
le VPN n'a pas encore détecté la coupure.

Aussi: le VPN de Bob doit être configuré pour effectivement
authentifier le VPN-Alice, et non Trudy. Si les VPNs sont
configurés en goupe fermé avec une structure non hérarchique
dont fait partie le VPN-Trudy, Trudy peut dérouter un appel
de Bob vers Alice, faire se connecter Bob à son VPN-Trudy, jouer
le rôle du système d'Alice pendant la phase login/mot de passe,
et récupérer ainsi le login/mot de passe de Bob; couper; puis se
connecter à Alice en se faisant passr pour Bob:
- au niveau VPN, grâce à la clé privée de Bob supposée compromise
- au niveau login/mot de passe, grâce à la capture effectuée.

Enfin: habituellement, les VPNs tentent de défendre aussi bien
le secret de leur clé privée que l'intégrité des certificats,
clés publiques, et autres paramètres. Le scénario "compromission
de la seule confidentialité de la clé privée" n'est souvent pas
le plus à craindre.

François Grieu

manu@netbsd.org (Emmanuel Dreyfus) dit:

Passons maintenant au cas pratique d'un VPN de type accès distant en
Xauth/IPsec ou L2TP/IPsec: il y a un echange IKE avec des certificats,
suivi d'une authentification par login/mot de passe.

On se perd un peu dans IKE, il y a tant de modes et d'options..
<http://www.faqs.org/rfcs/rfc2409.html>
Je suppose que l'on fonctionne avec authentification par signature,
et j'ignore les détails genre mode "Main" ou "Aggressive".

Bob est un utilisateur qui se connecte à distance. Alice se transforme
en concentrateur d'accès VPN.

Si on immagine que Bob ait la clé privée de son certificat compromise,
alors il peut quand même contacter le concentrateur d'accès, verifier
son identité, et s'y authentifier, sans pour cela que l'on puisse
capturer ses crédits d'authentification, donc?

Il me semble que oui, dans le principe. En fait, Bob a perdu seulement
une partie de ses secrets (sa clé privée) mais pas la totalité
(login/mot de passe), et dès l'instant où il ne communique ce qu'il
lui reste de secret qu'après avoir authentifié Alice, et qu'Alice
ne "baisse sa garde" qu'après avoir vérifié ce secret de Bob, alors
oui la confidentialité des échanges ultérieurs Alice->Bob semble
assurée [note: nous n'avons jamais douté de la confidentialité
des échanges Bob->Alice]

J'en arrive donc à la conclusion que le niveau de sécurité de ce
type de VPN avec un client dont la clé privée a été compromise est
exactement le même que dans le cas d'une authentification par mot
de passe via SSH (alors qu'on connait déjà la clé publique du serveur)
ou par SSL. Exact?

Moui, peut-être. En pratique, le diable est dans les détails.

En particulier: si le login/mot de passe n'est pas géré par le VPN
mais par un système ditinct, Trudy, avec la clé privée de Bob, peut
- se connecter au VPN d'Alice et envoyer des requètes autres que de
login au système derrière le VPN, pour essayer d'y trouver une
vulnérabilité exploitable.
- et/ou attendre que Bob soit connecté et ait tapé son login/mot de
passe; couper la liaison Bob/VPN-Alice; se connecter au VPN-Alice,
en se faisant passer pour Bob; et espérer que le système derrière
le VPN n'a pas encore détecté la coupure.

Aussi: le VPN de Bob doit être configuré pour effectivement
authentifier le VPN-Alice, et non Trudy. Si les VPNs sont
configurés en goupe fermé avec une structure non hérarchique
dont fait partie le VPN-Trudy, Trudy peut dérouter un appel
de Bob vers Alice, faire se connecter Bob à son VPN-Trudy, jouer
le rôle du système d'Alice pendant la phase login/mot de passe,
et récupérer ainsi le login/mot de passe de Bob; couper; puis se
connecter à Alice en se faisant passr pour Bob:
- au niveau VPN, grâce à la clé privée de Bob supposée compromise
- au niveau login/mot de passe, grâce à la capture effectuée.

Enfin: habituellement, les VPNs tentent de défendre aussi bien
le secret de leur clé privée que l'intégrité des certificats,
clés publiques, et autres paramètres. Le scénario "compromission
de la seule confidentialité de la clé privée" n'est souvent pas
le plus à craindre.

François Grieu

Vous avez filtré cet utilisateur ! Consultez son message

(Emmanuel Dreyfus) dit:

Passons maintenant au cas pratique d'un VPN de type accès distant en
Xauth/IPsec ou L2TP/IPsec: il y a un echange IKE avec des certificats,
suivi d'une authentification par login/mot de passe.

On se perd un peu dans IKE, il y a tant de modes et d'options..
<http://www.faqs.org/rfcs/rfc2409.html>
Je suppose que l'on fonctionne avec authentification par signature,
et j'ignore les détails genre mode "Main" ou "Aggressive".

Bob est un utilisateur qui se connecte à distance. Alice se transforme
en concentrateur d'accès VPN.

Si on immagine que Bob ait la clé privée de son certificat compromise,
alors il peut quand même contacter le concentrateur d'accès, verifier
son identité, et s'y authentifier, sans pour cela que l'on puisse
capturer ses crédits d'authentification, donc?

Il me semble que oui, dans le principe. En fait, Bob a perdu seulement
une partie de ses secrets (sa clé privée) mais pas la totalité
(login/mot de passe), et dès l'instant où il ne communique ce qu'il
lui reste de secret qu'après avoir authentifié Alice, et qu'Alice
ne "baisse sa garde" qu'après avoir vérifié ce secret de Bob, alors
oui la confidentialité des échanges ultérieurs Alice->Bob semble
assurée [note: nous n'avons jamais douté de la confidentialité
des échanges Bob->Alice]

J'en arrive donc à la conclusion que le niveau de sécurité de ce
type de VPN avec un client dont la clé privée a été compromise est
exactement le même que dans le cas d'une authentification par mot
de passe via SSH (alors qu'on connait déjà la clé publique du serveur)
ou par SSL. Exact?

Moui, peut-être. En pratique, le diable est dans les détails.

En particulier: si le login/mot de passe n'est pas géré par le VPN
mais par un système ditinct, Trudy, avec la clé privée de Bob, peut
- se connecter au VPN d'Alice et envoyer des requètes autres que de
login au système derrière le VPN, pour essayer d'y trouver une
vulnérabilité exploitable.
- et/ou attendre que Bob soit connecté et ait tapé son login/mot de
passe; couper la liaison Bob/VPN-Alice; se connecter au VPN-Alice,
en se faisant passer pour Bob; et espérer que le système derrière
le VPN n'a pas encore détecté la coupure.

Aussi: le VPN de Bob doit être configuré pour effectivement
authentifier le VPN-Alice, et non Trudy. Si les VPNs sont
configurés en goupe fermé avec une structure non hérarchique
dont fait partie le VPN-Trudy, Trudy peut dérouter un appel
de Bob vers Alice, faire se connecter Bob à son VPN-Trudy, jouer
le rôle du système d'Alice pendant la phase login/mot de passe,
et récupérer ainsi le login/mot de passe de Bob; couper; puis se
connecter à Alice en se faisant passr pour Bob:
- au niveau VPN, grâce à la clé privée de Bob supposée compromise
- au niveau login/mot de passe, grâce à la capture effectuée.

Enfin: habituellement, les VPNs tentent de défendre aussi bien
le secret de leur clé privée que l'intégrité des certificats,
clés publiques, et autres paramètres. Le scénario "compromission
de la seule confidentialité de la clé privée" n'est souvent pas
le plus à craindre.

François Grieu

manu

20/07/2004 à 08:40

Francois Grieu wrote:

J'en arrive donc à la conclusion que le niveau de sécurité de ce
type de VPN avec un client dont la clé privée a été compromise est
exactement le même que dans le cas d'une authentification par mot
de passe via SSH (alors qu'on connait déjà la clé publique du serveur)
ou par SSL. Exact?

Moui, peut-être. En pratique, le diable est dans les détails.

Ben c'est justement pour ca que je viend demander :)

- et/ou attendre que Bob soit connecté et ait tapé son login/mot de
passe; couper la liaison Bob/VPN-Alice; se connecter au VPN-Alice,
en se faisant passer pour Bob; et espérer que le système derrière
le VPN n'a pas encore détecté la coupure.

Ah là il y a peut être quelque chose.
L'authentification des communications entree Bob et Alice se fait par le
AH IPsec, dont la clé est produite pendant la (les) phase(s) 2 de IKE.
Puisque la confidentialité de ces echanges en phase 2 est assuré par
l'echange DH de la phase 1, alors je dirais qu'il est impossible à Trudy
de fournir un AH lui permettant de se faire passer pour Bob à ce stade.

Mais je peux me tromper. Faut que je creuse ce scenario.

Aussi: le VPN de Bob doit être configuré pour effectivement
authentifier le VPN-Alice, et non Trudy.

Oui, ca c'est clair: si Bob ne fait pas la verification du certificat
d'Alice, tout tombe.

Enfin: habituellement, les VPNs tentent de défendre aussi bien
le secret de leur clé privée que l'intégrité des certificats,
clés publiques, et autres paramètres. Le scénario "compromission
de la seule confidentialité de la clé privée" n'est souvent pas
le plus à craindre.

En fait le fond de la question, c'est de savoir si il est envisageable
de déployer un "certificat de groupe" sur les clients VPN (pour des
raisons de simplicité: ca evite d'avoir à gérer les certificats des
clients: procédure de signature, revocation, etc...), sans pour autant
sacrifier la sécurité. Si on tombe au niveau de sécurité du mot de passe
dans une session SSH, ca reste satisfaisant puisque les usagers font
déjà cela actuellement: à défaut de progresser, au moins on ne regresse
pas.

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php

Francois Grieu <fgrieu@francenet.fr> wrote:

J'en arrive donc à la conclusion que le niveau de sécurité de ce
type de VPN avec un client dont la clé privée a été compromise est
exactement le même que dans le cas d'une authentification par mot
de passe via SSH (alors qu'on connait déjà la clé publique du serveur)
ou par SSL. Exact?

Moui, peut-être. En pratique, le diable est dans les détails.

Ben c'est justement pour ca que je viend demander :)

- et/ou attendre que Bob soit connecté et ait tapé son login/mot de
passe; couper la liaison Bob/VPN-Alice; se connecter au VPN-Alice,
en se faisant passer pour Bob; et espérer que le système derrière
le VPN n'a pas encore détecté la coupure.

Ah là il y a peut être quelque chose.
L'authentification des communications entree Bob et Alice se fait par le
AH IPsec, dont la clé est produite pendant la (les) phase(s) 2 de IKE.
Puisque la confidentialité de ces echanges en phase 2 est assuré par
l'echange DH de la phase 1, alors je dirais qu'il est impossible à Trudy
de fournir un AH lui permettant de se faire passer pour Bob à ce stade.

Mais je peux me tromper. Faut que je creuse ce scenario.

Aussi: le VPN de Bob doit être configuré pour effectivement
authentifier le VPN-Alice, et non Trudy.

Oui, ca c'est clair: si Bob ne fait pas la verification du certificat
d'Alice, tout tombe.

Enfin: habituellement, les VPNs tentent de défendre aussi bien
le secret de leur clé privée que l'intégrité des certificats,
clés publiques, et autres paramètres. Le scénario "compromission
de la seule confidentialité de la clé privée" n'est souvent pas
le plus à craindre.

En fait le fond de la question, c'est de savoir si il est envisageable
de déployer un "certificat de groupe" sur les clients VPN (pour des
raisons de simplicité: ca evite d'avoir à gérer les certificats des
clients: procédure de signature, revocation, etc...), sans pour autant
sacrifier la sécurité. Si on tombe au niveau de sécurité du mot de passe
dans une session SSH, ca reste satisfaisant puisque les usagers font
déjà cela actuellement: à défaut de progresser, au moins on ne regresse
pas.

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org

Vous avez filtré cet utilisateur ! Consultez son message

Francois Grieu wrote:

J'en arrive donc à la conclusion que le niveau de sécurité de ce
type de VPN avec un client dont la clé privée a été compromise est
exactement le même que dans le cas d'une authentification par mot
de passe via SSH (alors qu'on connait déjà la clé publique du serveur)
ou par SSL. Exact?

Moui, peut-être. En pratique, le diable est dans les détails.

Ben c'est justement pour ca que je viend demander :)

- et/ou attendre que Bob soit connecté et ait tapé son login/mot de
passe; couper la liaison Bob/VPN-Alice; se connecter au VPN-Alice,
en se faisant passer pour Bob; et espérer que le système derrière
le VPN n'a pas encore détecté la coupure.

Ah là il y a peut être quelque chose.
L'authentification des communications entree Bob et Alice se fait par le
AH IPsec, dont la clé est produite pendant la (les) phase(s) 2 de IKE.
Puisque la confidentialité de ces echanges en phase 2 est assuré par
l'echange DH de la phase 1, alors je dirais qu'il est impossible à Trudy
de fournir un AH lui permettant de se faire passer pour Bob à ce stade.

Mais je peux me tromper. Faut que je creuse ce scenario.

Aussi: le VPN de Bob doit être configuré pour effectivement
authentifier le VPN-Alice, et non Trudy.

Oui, ca c'est clair: si Bob ne fait pas la verification du certificat
d'Alice, tout tombe.

Enfin: habituellement, les VPNs tentent de défendre aussi bien
le secret de leur clé privée que l'intégrité des certificats,
clés publiques, et autres paramètres. Le scénario "compromission
de la seule confidentialité de la clé privée" n'est souvent pas
le plus à craindre.

En fait le fond de la question, c'est de savoir si il est envisageable
de déployer un "certificat de groupe" sur les clients VPN (pour des
raisons de simplicité: ca evite d'avoir à gérer les certificats des
clients: procédure de signature, revocation, etc...), sans pour autant
sacrifier la sécurité. Si on tombe au niveau de sécurité du mot de passe
dans une session SSH, ca reste satisfaisant puisque les usagers font
déjà cela actuellement: à défaut de progresser, au moins on ne regresse
pas.

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php

[Q] sur Diffie-Hellman

8 réponses

Veuillez sélectionner un problème