Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
Je vais peut-être (surement même, vu que tu sembles sur de toi, mais
j'ai même pas peur) dire une bêtise, mais tu peux te contenter d'avoir
une machine sur le net, si le réseau en question permet de sortir. Non ?
(pas taper).
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
Je vais peut-être (surement même, vu que tu sembles sur de toi, mais
j'ai même pas peur) dire une bêtise, mais tu peux te contenter d'avoir
une machine sur le net, si le réseau en question permet de sortir. Non ?
(pas taper).
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
Je vais peut-être (surement même, vu que tu sembles sur de toi, mais
j'ai même pas peur) dire une bêtise, mais tu peux te contenter d'avoir
une machine sur le net, si le réseau en question permet de sortir. Non ?
(pas taper).
Pour autant que je sache, le chiffrement, c'est du RC4. C'est le calcul de
la somme d'intégrité qui est à base de XOR.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en
mettant notre machine en destination) La clé est ensuite obtenue en
faisant un XOR des deux.
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
Faut voir le nombre de trames nécessaires.
Pour autant que je sache, le chiffrement, c'est du RC4. C'est le calcul de
la somme d'intégrité qui est à base de XOR.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en
mettant notre machine en destination) La clé est ensuite obtenue en
faisant un XOR des deux.
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
Faut voir le nombre de trames nécessaires.
Pour autant que je sache, le chiffrement, c'est du RC4. C'est le calcul de
la somme d'intégrité qui est à base de XOR.
On peut ainsi envoyer une trame chiffrée et récupérer le clair (en
mettant notre machine en destination) La clé est ensuite obtenue en
faisant un XOR des deux.
Oui, mais là, il faut une machine sur le réseau filaire, c'est quand
même vachement contraignant, non ?
Faut voir le nombre de trames nécessaires.
Bref, je m'orienterait plutôt vers une solution type 802.1x que supporte
aujourd'hui pas mal de points d'accès, avec une authentification PEAP par
exemple qui permet une authentification mutuelle des deux parties (forte
pour le serveur d'authentification). Il faut certes un serveur RADIUS sous
la main, mais on en trouve des très bien dans le monde du logiciel libre,
de mise en oeuvre aisée.
En outre, l'avantage de 802.1x est qu'il permet de générer des clés WEP
différentes à chaque authentification et de les renouveler
régulièrement, nuançant par là _la_ grosse faille de WEP.
Bref, je m'orienterait plutôt vers une solution type 802.1x que supporte
aujourd'hui pas mal de points d'accès, avec une authentification PEAP par
exemple qui permet une authentification mutuelle des deux parties (forte
pour le serveur d'authentification). Il faut certes un serveur RADIUS sous
la main, mais on en trouve des très bien dans le monde du logiciel libre,
de mise en oeuvre aisée.
En outre, l'avantage de 802.1x est qu'il permet de générer des clés WEP
différentes à chaque authentification et de les renouveler
régulièrement, nuançant par là _la_ grosse faille de WEP.
Bref, je m'orienterait plutôt vers une solution type 802.1x que supporte
aujourd'hui pas mal de points d'accès, avec une authentification PEAP par
exemple qui permet une authentification mutuelle des deux parties (forte
pour le serveur d'authentification). Il faut certes un serveur RADIUS sous
la main, mais on en trouve des très bien dans le monde du logiciel libre,
de mise en oeuvre aisée.
En outre, l'avantage de 802.1x est qu'il permet de générer des clés WEP
différentes à chaque authentification et de les renouveler
régulièrement, nuançant par là _la_ grosse faille de WEP.
C'est le RC4 lui-même (en personne) qui est à base de XOR (le shériff)
"WEP uses the RC4 encryption algorithm, which is known as a stream
cipher. A stream cipher operates by expanding a short key into an
infinite pseudo-random key stream. The sender XORs the key stream with
the plaintext to produce ciphertext. The receiver has a copy of the same
key, and uses it to generate identical key stream. XORing the key stream
with the ciphertext yields the original plaintext."
En fait, il suffit de prendre une trame chiffrée, de modifier l'adresse
destination (une machine sur le net par exemple, il faut effectivement
dans ce cas que les accès wifi aient accès au net) pour recevoir la
trame déchiffrée.
Effectivement, ca nécessite l'accès au net par le wifi (c'est un cas que
j'ai souvent rencontré) C'est moins contraignant que l'accès au filaire
;-)
On peut aussi trouver une façon de modifier l'adresse pour déclancher
les soupçons des impôts, histoire d'être aussi chiants que lui ?
-+- ALG in : GNU - Neuneu a recommandé son percepteur -+-
C'est le RC4 lui-même (en personne) qui est à base de XOR (le shériff)
"WEP uses the RC4 encryption algorithm, which is known as a stream
cipher. A stream cipher operates by expanding a short key into an
infinite pseudo-random key stream. The sender XORs the key stream with
the plaintext to produce ciphertext. The receiver has a copy of the same
key, and uses it to generate identical key stream. XORing the key stream
with the ciphertext yields the original plaintext."
En fait, il suffit de prendre une trame chiffrée, de modifier l'adresse
destination (une machine sur le net par exemple, il faut effectivement
dans ce cas que les accès wifi aient accès au net) pour recevoir la
trame déchiffrée.
Effectivement, ca nécessite l'accès au net par le wifi (c'est un cas que
j'ai souvent rencontré) C'est moins contraignant que l'accès au filaire
;-)
On peut aussi trouver une façon de modifier l'adresse pour déclancher
les soupçons des impôts, histoire d'être aussi chiants que lui ?
-+- ALG in : GNU - Neuneu a recommandé son percepteur -+-
C'est le RC4 lui-même (en personne) qui est à base de XOR (le shériff)
"WEP uses the RC4 encryption algorithm, which is known as a stream
cipher. A stream cipher operates by expanding a short key into an
infinite pseudo-random key stream. The sender XORs the key stream with
the plaintext to produce ciphertext. The receiver has a copy of the same
key, and uses it to generate identical key stream. XORing the key stream
with the ciphertext yields the original plaintext."
En fait, il suffit de prendre une trame chiffrée, de modifier l'adresse
destination (une machine sur le net par exemple, il faut effectivement
dans ce cas que les accès wifi aient accès au net) pour recevoir la
trame déchiffrée.
Effectivement, ca nécessite l'accès au net par le wifi (c'est un cas que
j'ai souvent rencontré) C'est moins contraignant que l'accès au filaire
;-)
On peut aussi trouver une façon de modifier l'adresse pour déclancher
les soupçons des impôts, histoire d'être aussi chiants que lui ?
-+- ALG in : GNU - Neuneu a recommandé son percepteur -+-
Cedric nous dit:
"Il faut certes un serveur RADIUS sous la main, mais on en trouve des
très bien dans le monde du logiciel libre, de mise en oeuvre aisée."
Alors là je me marre:
je viens de mettre en place (pour la première fois) un freeradius 0.90
(sur debian), et pour trouver de la doc c'est une galère incroyable (je
parle de la configuration ad-hoc du serveur radius pour mes besoins, donc
rien de spécial, sans doute une conf banale). Cela rend la mise en oeuvre
vraiment pas aisée, on trouve quelques docs sur le net qui sont trop
pointus quand on ne maitrise pas Freeradius et sinon on se retrouve avec
la mailing list de freeradius qui est une excellente source d'info mais
pas du tout orientée "howto".
Au fait, tu sais quel animal a deux neurones ?
un freebsdiste avec un rat sur l'épaule ?
Cedric nous dit:
"Il faut certes un serveur RADIUS sous la main, mais on en trouve des
très bien dans le monde du logiciel libre, de mise en oeuvre aisée."
Alors là je me marre:
je viens de mettre en place (pour la première fois) un freeradius 0.90
(sur debian), et pour trouver de la doc c'est une galère incroyable (je
parle de la configuration ad-hoc du serveur radius pour mes besoins, donc
rien de spécial, sans doute une conf banale). Cela rend la mise en oeuvre
vraiment pas aisée, on trouve quelques docs sur le net qui sont trop
pointus quand on ne maitrise pas Freeradius et sinon on se retrouve avec
la mailing list de freeradius qui est une excellente source d'info mais
pas du tout orientée "howto".
Au fait, tu sais quel animal a deux neurones ?
un freebsdiste avec un rat sur l'épaule ?
Cedric nous dit:
"Il faut certes un serveur RADIUS sous la main, mais on en trouve des
très bien dans le monde du logiciel libre, de mise en oeuvre aisée."
Alors là je me marre:
je viens de mettre en place (pour la première fois) un freeradius 0.90
(sur debian), et pour trouver de la doc c'est une galère incroyable (je
parle de la configuration ad-hoc du serveur radius pour mes besoins, donc
rien de spécial, sans doute une conf banale). Cela rend la mise en oeuvre
vraiment pas aisée, on trouve quelques docs sur le net qui sont trop
pointus quand on ne maitrise pas Freeradius et sinon on se retrouve avec
la mailing list de freeradius qui est une excellente source d'info mais
pas du tout orientée "howto".
Au fait, tu sais quel animal a deux neurones ?
un freebsdiste avec un rat sur l'épaule ?
Dans sa prose, John nous ecrivait :Cedric nous dit:
"Il faut certes un serveur RADIUS sous la main, mais on en trouve des
très bien dans le monde du logiciel libre, de mise en oeuvre aisée."
Alors là je me marre:
...
Je t'ai dit qu'il y avait des serveurs RADIUS libres sympa et simples à
mettre en oeuvre, pas qu'ils l'étaient tous ;)
Tu peux jeter un coup d'oeil du côté de GNU Radius (pas plus simple,
mais y'a de la doc), Cistron ou encore YARD Radius (sympa). Je te laisse
chercher sur Freshmeat.
Dans sa prose, John nous ecrivait :
Cedric nous dit:
"Il faut certes un serveur RADIUS sous la main, mais on en trouve des
très bien dans le monde du logiciel libre, de mise en oeuvre aisée."
Alors là je me marre:
...
Je t'ai dit qu'il y avait des serveurs RADIUS libres sympa et simples à
mettre en oeuvre, pas qu'ils l'étaient tous ;)
Tu peux jeter un coup d'oeil du côté de GNU Radius (pas plus simple,
mais y'a de la doc), Cistron ou encore YARD Radius (sympa). Je te laisse
chercher sur Freshmeat.
Dans sa prose, John nous ecrivait :Cedric nous dit:
"Il faut certes un serveur RADIUS sous la main, mais on en trouve des
très bien dans le monde du logiciel libre, de mise en oeuvre aisée."
Alors là je me marre:
...
Je t'ai dit qu'il y avait des serveurs RADIUS libres sympa et simples à
mettre en oeuvre, pas qu'ils l'étaient tous ;)
Tu peux jeter un coup d'oeil du côté de GNU Radius (pas plus simple,
mais y'a de la doc), Cistron ou encore YARD Radius (sympa). Je te laisse
chercher sur Freshmeat.
</commentaire perso on> Cedric nous dit: "Il faut certes un serveur
RADIUS sous la main, mais on en trouve des très bien dans le monde
du logiciel libre, de mise en oeuvre aisée." Alors là je me marre:
je viens de mettre en place (pour la première fois) un freeradius
0.90 (sur debian), et pour trouver de la doc c'est une galère
incroyable (je parle de la configuration ad-hoc du serveur radius
pour mes besoins, donc rien de spécial, sans doute une conf
banale). Cela rend la mise en oeuvre vraiment pas aisée, on trouve
quelques docs sur le net qui sont trop pointus quand on ne maitrise
pas Freeradius et sinon on se retrouve avec la mailing list de
freeradius qui est une excellente source d'info mais pas du tout
orientée "howto". On trouve des docs géniales sur iptables, squid,
apache, et une tonnes d'autres appli du monde libre...., mais avec
freeradius on atteint des records d'absence de doc synthétique.
D'ailleurs si quelqu'un avait une URL je suis preneur, et je serais
même pret à tenter la rédaction d'un how-to freeradius (basique) si
j'arrive à le maitriser à peu près correctement !!! (A moins que je
ne sois passé complètement à coté du site de la doc freeradius ????)
</commentaire perso off>
</commentaire perso on> Cedric nous dit: "Il faut certes un serveur
RADIUS sous la main, mais on en trouve des très bien dans le monde
du logiciel libre, de mise en oeuvre aisée." Alors là je me marre:
je viens de mettre en place (pour la première fois) un freeradius
0.90 (sur debian), et pour trouver de la doc c'est une galère
incroyable (je parle de la configuration ad-hoc du serveur radius
pour mes besoins, donc rien de spécial, sans doute une conf
banale). Cela rend la mise en oeuvre vraiment pas aisée, on trouve
quelques docs sur le net qui sont trop pointus quand on ne maitrise
pas Freeradius et sinon on se retrouve avec la mailing list de
freeradius qui est une excellente source d'info mais pas du tout
orientée "howto". On trouve des docs géniales sur iptables, squid,
apache, et une tonnes d'autres appli du monde libre...., mais avec
freeradius on atteint des records d'absence de doc synthétique.
D'ailleurs si quelqu'un avait une URL je suis preneur, et je serais
même pret à tenter la rédaction d'un how-to freeradius (basique) si
j'arrive à le maitriser à peu près correctement !!! (A moins que je
ne sois passé complètement à coté du site de la doc freeradius ????)
</commentaire perso off>
</commentaire perso on> Cedric nous dit: "Il faut certes un serveur
RADIUS sous la main, mais on en trouve des très bien dans le monde
du logiciel libre, de mise en oeuvre aisée." Alors là je me marre:
je viens de mettre en place (pour la première fois) un freeradius
0.90 (sur debian), et pour trouver de la doc c'est une galère
incroyable (je parle de la configuration ad-hoc du serveur radius
pour mes besoins, donc rien de spécial, sans doute une conf
banale). Cela rend la mise en oeuvre vraiment pas aisée, on trouve
quelques docs sur le net qui sont trop pointus quand on ne maitrise
pas Freeradius et sinon on se retrouve avec la mailing list de
freeradius qui est une excellente source d'info mais pas du tout
orientée "howto". On trouve des docs géniales sur iptables, squid,
apache, et une tonnes d'autres appli du monde libre...., mais avec
freeradius on atteint des records d'absence de doc synthétique.
D'ailleurs si quelqu'un avait une URL je suis preneur, et je serais
même pret à tenter la rédaction d'un how-to freeradius (basique) si
j'arrive à le maitriser à peu près correctement !!! (A moins que je
ne sois passé complètement à coté du site de la doc freeradius ????)
</commentaire perso off>
Oui, mais non (tm). Tu as loupé la phrase "A stream cipher operates by
expanding a short key into an infinite pseudo-random key stream". Ce qui
veut dire que pour le XOR, ce n'est pas la clé qui est utilisée, mais
une bloc de données dérivé de la clé, le keystream. C'est d'ailleurs
pourquoi, dans pas mal de papier, quand on te parle d'un chiffrement
d'un message C par RC4 avec une clé k, on note :
C = P XOR RC4(k)
Si RC4 n'était qu'un XOR, il ne s'appelerait pas RC4, mais XOR, et ne
serait pas le sheriff de l'espace (SSL utilise principalement RC4 128bits
parce que ça va vite).
Ton attaque découle donc sur une attaque par table. Tu vas stocker pour
chaque IV le keystream qui va bien, puisque tu auras été capable de le
récupérer par ton attaque en clair connu. Quand tu auras récupéré
_tous_ les IV, tu auras environ 2Go de données sous la main qui te
permettront de déchiffrer n'importe quel message sur la base de son IV.
Mais cela nécessite la même opération sur 2^24 trames, éventuellement
moins si on retire les IV faibles comme le font pas mal d'AP maintenant,
ce qui impose la transmission d'une 15e de Go de données. Selon la BP
disponible, ça peut se révéler très long devant une renégociation de
clé forcée par EAP.
Oui, mais non (tm). Tu as loupé la phrase "A stream cipher operates by
expanding a short key into an infinite pseudo-random key stream". Ce qui
veut dire que pour le XOR, ce n'est pas la clé qui est utilisée, mais
une bloc de données dérivé de la clé, le keystream. C'est d'ailleurs
pourquoi, dans pas mal de papier, quand on te parle d'un chiffrement
d'un message C par RC4 avec une clé k, on note :
C = P XOR RC4(k)
Si RC4 n'était qu'un XOR, il ne s'appelerait pas RC4, mais XOR, et ne
serait pas le sheriff de l'espace (SSL utilise principalement RC4 128bits
parce que ça va vite).
Ton attaque découle donc sur une attaque par table. Tu vas stocker pour
chaque IV le keystream qui va bien, puisque tu auras été capable de le
récupérer par ton attaque en clair connu. Quand tu auras récupéré
_tous_ les IV, tu auras environ 2Go de données sous la main qui te
permettront de déchiffrer n'importe quel message sur la base de son IV.
Mais cela nécessite la même opération sur 2^24 trames, éventuellement
moins si on retire les IV faibles comme le font pas mal d'AP maintenant,
ce qui impose la transmission d'une 15e de Go de données. Selon la BP
disponible, ça peut se révéler très long devant une renégociation de
clé forcée par EAP.
Oui, mais non (tm). Tu as loupé la phrase "A stream cipher operates by
expanding a short key into an infinite pseudo-random key stream". Ce qui
veut dire que pour le XOR, ce n'est pas la clé qui est utilisée, mais
une bloc de données dérivé de la clé, le keystream. C'est d'ailleurs
pourquoi, dans pas mal de papier, quand on te parle d'un chiffrement
d'un message C par RC4 avec une clé k, on note :
C = P XOR RC4(k)
Si RC4 n'était qu'un XOR, il ne s'appelerait pas RC4, mais XOR, et ne
serait pas le sheriff de l'espace (SSL utilise principalement RC4 128bits
parce que ça va vite).
Ton attaque découle donc sur une attaque par table. Tu vas stocker pour
chaque IV le keystream qui va bien, puisque tu auras été capable de le
récupérer par ton attaque en clair connu. Quand tu auras récupéré
_tous_ les IV, tu auras environ 2Go de données sous la main qui te
permettront de déchiffrer n'importe quel message sur la base de son IV.
Mais cela nécessite la même opération sur 2^24 trames, éventuellement
moins si on retire les IV faibles comme le font pas mal d'AP maintenant,
ce qui impose la transmission d'une 15e de Go de données. Selon la BP
disponible, ça peut se révéler très long devant une renégociation de
clé forcée par EAP.
Merci des précisions. Je commence à y voir plus clair. Par contre, j'ai
cru comprendre que l'IV passait en clair dans le message (il serait
ajouté à l'en-tête)
Donc la connaissance du keystream et de l'IV permet d'obtenir la clef, qui
permet elle même de déchiffrer le message. A chaque trame reçue, on
peut déchiffrer le message.
Ainsi, on récupère une première fois le keystream en faisant l'attaque
proprement dite, puis à chaque trame reçue, on peut directement
déchiffrer le message.
Ca semble trop simple, y a un truc que j'ai du louper :-/
Merci des précisions. Je commence à y voir plus clair. Par contre, j'ai
cru comprendre que l'IV passait en clair dans le message (il serait
ajouté à l'en-tête)
Donc la connaissance du keystream et de l'IV permet d'obtenir la clef, qui
permet elle même de déchiffrer le message. A chaque trame reçue, on
peut déchiffrer le message.
Ainsi, on récupère une première fois le keystream en faisant l'attaque
proprement dite, puis à chaque trame reçue, on peut directement
déchiffrer le message.
Ca semble trop simple, y a un truc que j'ai du louper :-/
Merci des précisions. Je commence à y voir plus clair. Par contre, j'ai
cru comprendre que l'IV passait en clair dans le message (il serait
ajouté à l'en-tête)
Donc la connaissance du keystream et de l'IV permet d'obtenir la clef, qui
permet elle même de déchiffrer le message. A chaque trame reçue, on
peut déchiffrer le message.
Ainsi, on récupère une première fois le keystream en faisant l'attaque
proprement dite, puis à chaque trame reçue, on peut directement
déchiffrer le message.
Ca semble trop simple, y a un truc que j'ai du louper :-/
Euh, franchement, je ne suis pas sûr de la réversibilité du keystream
RC4, i.e. retrouver la clé à partir du keystream. Un cryptologue dans
l'assemblée ?
Ca semble trop simple, y a un truc que j'ai du louper
La réversibilité de RC4...
Sinon, j'ai bien réfléchi à la question et j'ai quelques pistes, que je
viens de soumettre à relecture par quelqu'un de plus compétent que moi
dans le domaine, pour optimiser la récupération des trames. En
particulier sur un problème particulier que voici. Si on sait injecter
une trame modifiée sur le réseau, on doit avoir une certaine
connaissance du keystream qui a servi à la chiffrer pour pouvoir
récupérer quelquechose d'exploitable après déchiffrement de manière
efficace. Donc déjà avoir une sérieuse idée soit de la trame qu'on a
sous les yeux, soit de la partie du keystream relative à cette partie de
la trame chiffrée.
Euh, franchement, je ne suis pas sûr de la réversibilité du keystream
RC4, i.e. retrouver la clé à partir du keystream. Un cryptologue dans
l'assemblée ?
Ca semble trop simple, y a un truc que j'ai du louper
La réversibilité de RC4...
Sinon, j'ai bien réfléchi à la question et j'ai quelques pistes, que je
viens de soumettre à relecture par quelqu'un de plus compétent que moi
dans le domaine, pour optimiser la récupération des trames. En
particulier sur un problème particulier que voici. Si on sait injecter
une trame modifiée sur le réseau, on doit avoir une certaine
connaissance du keystream qui a servi à la chiffrer pour pouvoir
récupérer quelquechose d'exploitable après déchiffrement de manière
efficace. Donc déjà avoir une sérieuse idée soit de la trame qu'on a
sous les yeux, soit de la partie du keystream relative à cette partie de
la trame chiffrée.
Euh, franchement, je ne suis pas sûr de la réversibilité du keystream
RC4, i.e. retrouver la clé à partir du keystream. Un cryptologue dans
l'assemblée ?
Ca semble trop simple, y a un truc que j'ai du louper
La réversibilité de RC4...
Sinon, j'ai bien réfléchi à la question et j'ai quelques pistes, que je
viens de soumettre à relecture par quelqu'un de plus compétent que moi
dans le domaine, pour optimiser la récupération des trames. En
particulier sur un problème particulier que voici. Si on sait injecter
une trame modifiée sur le réseau, on doit avoir une certaine
connaissance du keystream qui a servi à la chiffrer pour pouvoir
récupérer quelquechose d'exploitable après déchiffrement de manière
efficace. Donc déjà avoir une sérieuse idée soit de la trame qu'on a
sous les yeux, soit de la partie du keystream relative à cette partie de
la trame chiffrée.
