En dehors de la confusion entre les cartes à puces & du SSL executé
dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une
attaque efficace sur un ordinateur dans des conditions réels d'usage ?
Avec plusieurs tâches simultanées & pleins d'autres choses en même
temps ?
En dehors de la confusion entre les cartes à puces & du SSL executé dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une attaque efficace sur un ordinateur dans des conditions réels d'usage ? Avec plusieurs tâches simultanées & pleins d'autres choses en même temps ?
J'ai pas tout compris l'article, ça parle de puce et ensuite de ssl... J'aimerais bien aussi en savoir plus.
En dehors de la confusion entre les cartes à puces & du SSL executé
dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une
attaque efficace sur un ordinateur dans des conditions réels d'usage ?
Avec plusieurs tâches simultanées & pleins d'autres choses en même
temps ?
J'ai pas tout compris l'article, ça parle de puce et ensuite de ssl...
J'aimerais bien aussi en savoir plus.
En dehors de la confusion entre les cartes à puces & du SSL executé dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une attaque efficace sur un ordinateur dans des conditions réels d'usage ? Avec plusieurs tâches simultanées & pleins d'autres choses en même temps ?
J'ai pas tout compris l'article, ça parle de puce et ensuite de ssl... J'aimerais bien aussi en savoir plus.
En dehors de la confusion entre les cartes à puces & du SSL executé dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une attaque efficace sur un ordinateur dans des conditions réels d'usage ? Avec plusieurs tâches simultanées & pleins d'autres choses en même temps ? la cible c'est pas les processeurs crypto des cartes à puce ?
les attaques sur les temps d'exécution sont pas nouvelles... dans les années 70 j'avais vu des attaques contre le mot de passe basée sur le temps de comparaison des mots de passe...
En dehors de la confusion entre les cartes à puces & du SSL executé
dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une
attaque efficace sur un ordinateur dans des conditions réels d'usage ?
Avec plusieurs tâches simultanées & pleins d'autres choses en même
temps ?
la cible c'est pas les processeurs crypto des cartes à puce ?
les attaques sur les temps d'exécution sont pas nouvelles... dans les
années 70 j'avais vu des attaques contre le mot de passe basée sur le
temps de comparaison des mots de passe...
En dehors de la confusion entre les cartes à puces & du SSL executé dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une attaque efficace sur un ordinateur dans des conditions réels d'usage ? Avec plusieurs tâches simultanées & pleins d'autres choses en même temps ? la cible c'est pas les processeurs crypto des cartes à puce ?
les attaques sur les temps d'exécution sont pas nouvelles... dans les années 70 j'avais vu des attaques contre le mot de passe basée sur le temps de comparaison des mots de passe...
En dehors de la confusion entre les cartes à puces & du SSL executé dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une attaque efficace sur un ordinateur dans des conditions réels d'usage ? Avec plusieurs tâches simultanées & pleins d'autres choses en même temps ?
le début de l'article indique:
"Dans un article encore confidentiel, le chercheur et ses collègues "décrivent la façon dont ils ont pu, en une seule tentative - soit "quelques millisecondes -, récupérer la quasi-intégralité d'une clé "de cryptage de 512 bits (suite d'autant de 0 ou de 1)."
j'aime assez le "article confidentiel" donc inconnu et les kms qui viennent quand même après...
sur le fond, il est (a peu près) exact qu'avec le matériel actuel, le simple fait de faire un calcul RSA dans une carte permets de ""lire"" (en surveillant la consommation par exemple) tous les bits 1 à 1 lorsque qu'ils sont utilisés pour faire l'exponentiation modulaire interne.
BUT ceci n'est applicable qu'avec des chips complètement obsolètes et déjà connus comme tels (ie troué, laissant fuir les clés, ...); les fondeurs ont depuis un bon bout de temps mis les protections nécessaires, les OS eux-même rajoutent une couche (par exemple en faisant du bruit durant les opérations d'accès aux clés).
bref, ceci parait bidon.
Sylvain.
fabrice.pas-de-spam.bacchella@worldonline.fr wrote on 18/11/2006 17:47:
En dehors de la confusion entre les cartes à puces & du SSL executé
dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une
attaque efficace sur un ordinateur dans des conditions réels d'usage ?
Avec plusieurs tâches simultanées & pleins d'autres choses en même
temps ?
le début de l'article indique:
"Dans un article encore confidentiel, le chercheur et ses collègues
"décrivent la façon dont ils ont pu, en une seule tentative - soit
"quelques millisecondes -, récupérer la quasi-intégralité d'une clé
"de cryptage de 512 bits (suite d'autant de 0 ou de 1)."
j'aime assez le "article confidentiel" donc inconnu et les kms qui
viennent quand même après...
sur le fond, il est (a peu près) exact qu'avec le matériel actuel, le
simple fait de faire un calcul RSA dans une carte permets de ""lire""
(en surveillant la consommation par exemple) tous les bits 1 à 1 lorsque
qu'ils sont utilisés pour faire l'exponentiation modulaire interne.
BUT ceci n'est applicable qu'avec des chips complètement obsolètes et
déjà connus comme tels (ie troué, laissant fuir les clés, ...); les
fondeurs ont depuis un bon bout de temps mis les protections
nécessaires, les OS eux-même rajoutent une couche (par exemple en
faisant du bruit durant les opérations d'accès aux clés).
En dehors de la confusion entre les cartes à puces & du SSL executé dans le processeur d'un ordinateur, j'ai un doute. C'est vraiment une attaque efficace sur un ordinateur dans des conditions réels d'usage ? Avec plusieurs tâches simultanées & pleins d'autres choses en même temps ?
le début de l'article indique:
"Dans un article encore confidentiel, le chercheur et ses collègues "décrivent la façon dont ils ont pu, en une seule tentative - soit "quelques millisecondes -, récupérer la quasi-intégralité d'une clé "de cryptage de 512 bits (suite d'autant de 0 ou de 1)."
j'aime assez le "article confidentiel" donc inconnu et les kms qui viennent quand même après...
sur le fond, il est (a peu près) exact qu'avec le matériel actuel, le simple fait de faire un calcul RSA dans une carte permets de ""lire"" (en surveillant la consommation par exemple) tous les bits 1 à 1 lorsque qu'ils sont utilisés pour faire l'exponentiation modulaire interne.
BUT ceci n'est applicable qu'avec des chips complètement obsolètes et déjà connus comme tels (ie troué, laissant fuir les clés, ...); les fondeurs ont depuis un bon bout de temps mis les protections nécessaires, les OS eux-même rajoutent une couche (par exemple en faisant du bruit durant les opérations d'accès aux clés).
bref, ceci parait bidon.
Sylvain.
François Grieu
Pour lire autre chose que l'infecte régurgitation que nous sert Le Monde: http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM ne sont concernés.
François Grieu
Pour lire autre chose que l'infecte régurgitation que nous sert Le
Monde:
http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches
tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM
ne sont concernés.
Pour lire autre chose que l'infecte régurgitation que nous sert Le Monde: http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM ne sont concernés.
François Grieu
root
Le Sat, 18 Nov 2006 18:43:55 +0100, David MENTRE a écrit :
Mais le plus simple est d'attendre la publication du papier pour en savoir plus, non ? Ou de suivre les prochaines version d'OpenSSL ?
Ça me fait penser à ce document de D.J. Bernstein, décrivant entre autre le problème d'attaque par timing introduit par le fait que "Skipping an operation is faster than doing it" : - http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Le Sat, 18 Nov 2006 18:43:55 +0100, David MENTRE a écrit :
Mais le plus simple est d'attendre la publication du papier pour en
savoir plus, non ? Ou de suivre les prochaines version d'OpenSSL ?
Ça me fait penser à ce document de D.J. Bernstein, décrivant entre autre
le problème d'attaque par timing introduit par le fait que "Skipping an
operation is faster than doing it" :
- http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Le Sat, 18 Nov 2006 18:43:55 +0100, David MENTRE a écrit :
Mais le plus simple est d'attendre la publication du papier pour en savoir plus, non ? Ou de suivre les prochaines version d'OpenSSL ?
Ça me fait penser à ce document de D.J. Bernstein, décrivant entre autre le problème d'attaque par timing introduit par le fait que "Skipping an operation is faster than doing it" : - http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Sylvain
Sylvain wrote on 18/11/2006 23:26:
faire un calcul RSA dans une carte [à puce] ...
le papier utilise en fait "puce" pour processeurs de PC (Intel en ligne de mire) (merci François).
rien de neuf sous les ventilos dans ce cas, une clé soft peut de toute façon être aisément piratée.
Sylvain.
Sylvain wrote on 18/11/2006 23:26:
faire un calcul RSA dans une carte [à puce] ...
le papier utilise en fait "puce" pour processeurs de PC (Intel en ligne
de mire) (merci François).
rien de neuf sous les ventilos dans ce cas, une clé soft peut de toute
façon être aisément piratée.
le papier utilise en fait "puce" pour processeurs de PC (Intel en ligne de mire) (merci François).
rien de neuf sous les ventilos dans ce cas, une clé soft peut de toute façon être aisément piratée.
Sylvain.
fabrice.pas-de-spam.bacchella
On 18 Nov 2006 15:11:43 -0800, "François Grieu" wrote:
Pour lire autre chose que l'infecte régurgitation que nous sert Le Monde: http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM ne sont concernés.
François Grieu
L'attaque semble n'être possible que sur des processeur multi thread (style HT d'Intel, T1 de Sun), par le bias de l'observation synchrone du cache de prédiction de branchement. D'autre part : In the other case, one needs a very sophisticated OS expertise and a deep thread scheduling expertise, cf. [NS]. As the above paradigm and all its subtle implementation details heavily depend on the underlying OS, CPU type and frequency, etc. we will not deepen further those technical details here, and just assume the existence of a suited spy process and a corresponding crypto process in a hardware-assisted multi-threading environment. dit l'auteur.
Je le trouve bien léger, parce que de là à rendre l'attaque réellement effective dans la vraie vie, comme le prétend l'article du Monde, il me semble qu'il y a un grand pas à franchir. Quand au condition de l'expérience, on sait juste qu'ils ont tournés sur un Pentium 4, avec une implémentation RSA tiré de OpenSSL, mais ultra bidouillé. Pas de mention de l'OS utilisé.
On 18 Nov 2006 15:11:43 -0800, "François Grieu" <fgrieu@gmail.com>
wrote:
Pour lire autre chose que l'infecte régurgitation que nous sert Le
Monde:
http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches
tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM
ne sont concernés.
François Grieu
L'attaque semble n'être possible que sur des processeur multi thread
(style HT d'Intel, T1 de Sun), par le bias de l'observation synchrone
du cache de prédiction de branchement.
D'autre part :
In the other case, one needs a very sophisticated OS expertise and a
deep thread scheduling expertise, cf. [NS]. As the above paradigm and
all its subtle implementation details heavily depend on the underlying
OS, CPU type and frequency, etc. we will not deepen further those
technical details here, and just assume the existence of a suited spy
process and a corresponding crypto process in a hardware-assisted
multi-threading environment.
dit l'auteur.
Je le trouve bien léger, parce que de là à rendre l'attaque réellement
effective dans la vraie vie, comme le prétend l'article du Monde, il
me semble qu'il y a un grand pas à franchir. Quand au condition de
l'expérience, on sait juste qu'ils ont tournés sur un Pentium 4, avec
une implémentation RSA tiré de OpenSSL, mais ultra bidouillé. Pas de
mention de l'OS utilisé.
On 18 Nov 2006 15:11:43 -0800, "François Grieu" wrote:
Pour lire autre chose que l'infecte régurgitation que nous sert Le Monde: http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM ne sont concernés.
François Grieu
L'attaque semble n'être possible que sur des processeur multi thread (style HT d'Intel, T1 de Sun), par le bias de l'observation synchrone du cache de prédiction de branchement. D'autre part : In the other case, one needs a very sophisticated OS expertise and a deep thread scheduling expertise, cf. [NS]. As the above paradigm and all its subtle implementation details heavily depend on the underlying OS, CPU type and frequency, etc. we will not deepen further those technical details here, and just assume the existence of a suited spy process and a corresponding crypto process in a hardware-assisted multi-threading environment. dit l'auteur.
Je le trouve bien léger, parce que de là à rendre l'attaque réellement effective dans la vraie vie, comme le prétend l'article du Monde, il me semble qu'il y a un grand pas à franchir. Quand au condition de l'expérience, on sait juste qu'ils ont tournés sur un Pentium 4, avec une implémentation RSA tiré de OpenSSL, mais ultra bidouillé. Pas de mention de l'OS utilisé.
nlevol
Pour lire autre chose que l'infecte régurgitation que nous sert Le Monde: http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM ne sont concernés.
François Grieu
Est-il possible que la manière la plus facile de venir à bout cette attaque soit d'écrire le RSA sous une forme qui n'emploie pas les branches qui sont fonction de la valeur de la clef ? Par exemple si vous modifiez l'algorithme de la façon suivante :
result=message for (i=(length of key -2); i>=0; i--) { result1 = result * result result2=result1 * Message if (e[i]==1) result=result2 //Cette ligne doit être codée sans saut conditionnel else result =result1 }
Le codage les lignes « if-else» sans saut conditionnel peut être effectué d'un certain nombre de manières, ma méthode préfère (pas forcement le plus simple) doit employer un byte « swap ». Par exemple, il y a deux résultats : result1 et result2, leurs adresses sont respectivement A et B. Si vous faites un byte « swap » S=A^B (^ = XOR), alors vous pouvez employer ceci pour permuter les adresses entre elles : (A=B^S, B=A^S).
Alors, vous devrez simplement créer un byte de décision « D » selon lequel est 0xFF ou 0x00 si le bit de la clef est 1 ou 0 (ceci peut être fait avec shifting et ORing). Le byte de décision est ANDed (&) avec le byte d'échange. Le statement if-else ci-dessus devient alors :
Adresse de result = A^(S & D)
Sinon, on peut également faire une table à double entrée contenant les adresses et employer le bit de la clef comme index (mais c'est trop simple). Cependant, des variations de la première méthode sont meilleures pour certaines optimisations de l'algorithme.
Dans la plupart des cas il est possible de remplacer les sauts conditionnels avec des calculs.
Pour lire autre chose que l'infecte régurgitation que nous sert Le
Monde:
http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches
tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM
ne sont concernés.
François Grieu
Est-il possible que la manière la plus facile de venir à bout cette
attaque soit d'écrire le RSA sous une forme qui n'emploie pas les
branches qui sont fonction de la valeur de la clef ? Par exemple si
vous modifiez l'algorithme de la façon suivante :
result=message
for (i=(length of key -2); i>=0; i--) {
result1 = result * result
result2=result1 * Message
if (e[i]==1) result=result2 //Cette ligne doit être codée sans saut
conditionnel
else result =result1
}
Le codage les lignes « if-else» sans saut conditionnel peut être
effectué d'un certain nombre de manières, ma méthode préfère (pas
forcement le plus simple) doit employer un byte « swap ». Par
exemple, il y a deux résultats : result1 et result2, leurs adresses
sont respectivement A et B. Si vous faites un byte « swap » S=A^B (^
= XOR), alors vous pouvez employer ceci pour permuter les adresses
entre elles : (A=B^S, B=A^S).
Alors, vous devrez simplement créer un byte de décision « D » selon
lequel est 0xFF ou 0x00 si le bit de la clef est 1 ou 0 (ceci peut
être fait avec shifting et ORing). Le byte de décision est ANDed (&)
avec le byte d'échange. Le statement if-else ci-dessus devient alors :
Adresse de result = A^(S & D)
Sinon, on peut également faire une table à double entrée contenant
les adresses et employer le bit de la clef comme index (mais c'est
trop simple). Cependant, des variations de la première méthode sont
meilleures pour certaines optimisations de l'algorithme.
Dans la plupart des cas il est possible de remplacer les sauts
conditionnels avec des calculs.
Pour lire autre chose que l'infecte régurgitation que nous sert Le Monde: http://eprint.iacr.org/2006/351
En résumé: un nouveau canal de fuite d'information entre tâches tournant sur le *même* CPU, genre PC. Ni les cartes à puce ni les HSM ne sont concernés.
François Grieu
Est-il possible que la manière la plus facile de venir à bout cette attaque soit d'écrire le RSA sous une forme qui n'emploie pas les branches qui sont fonction de la valeur de la clef ? Par exemple si vous modifiez l'algorithme de la façon suivante :
result=message for (i=(length of key -2); i>=0; i--) { result1 = result * result result2=result1 * Message if (e[i]==1) result=result2 //Cette ligne doit être codée sans saut conditionnel else result =result1 }
Le codage les lignes « if-else» sans saut conditionnel peut être effectué d'un certain nombre de manières, ma méthode préfère (pas forcement le plus simple) doit employer un byte « swap ». Par exemple, il y a deux résultats : result1 et result2, leurs adresses sont respectivement A et B. Si vous faites un byte « swap » S=A^B (^ = XOR), alors vous pouvez employer ceci pour permuter les adresses entre elles : (A=B^S, B=A^S).
Alors, vous devrez simplement créer un byte de décision « D » selon lequel est 0xFF ou 0x00 si le bit de la clef est 1 ou 0 (ceci peut être fait avec shifting et ORing). Le byte de décision est ANDed (&) avec le byte d'échange. Le statement if-else ci-dessus devient alors :
Adresse de result = A^(S & D)
Sinon, on peut également faire une table à double entrée contenant les adresses et employer le bit de la clef comme index (mais c'est trop simple). Cependant, des variations de la première méthode sont meilleures pour certaines optimisations de l'algorithme.
Dans la plupart des cas il est possible de remplacer les sauts conditionnels avec des calculs.
Sylvain
nlevol wrote on 20/11/2006 23:47:
si vous modifiez l'algorithme de la façon suivante :
*l*'algo, quel algo ? (cette impl. vient d'où ?)
Sinon, on peut également faire une table à double entrée [...]
sinon, on peut utiliser une carte HSM non ?
Sylvain.
nlevol wrote on 20/11/2006 23:47:
si vous modifiez l'algorithme de la façon suivante :
*l*'algo, quel algo ? (cette impl. vient d'où ?)
Sinon, on peut également faire une table à double entrée [...]
