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 ?
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 ?
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1)
Dans l'article <1164062838.476548.294070@h48g2000cwc.googlegroups.com>,
"nlevol" <nlevol@yahoo.com> écrit:
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 ?
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant
que e[i] est 0 ou 1)
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 ?
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1)
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).
Ca, ça ressemble fortement à la méthode que Bernstein a attaqué dans le cas de l'AES, en s'appuyant sur les variations de temps d'exécution d'accès à un index de tableau en fonction des alignements de données et en fonction des conflits d'accès au cache, qui se produisent quand le modulo de l'adresse dans le tableau par la taille des lignes de cache, est en collision avec celui d'autre données par ailleurs dans le cache.
nlevol wrote:
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).
Ca, ça ressemble fortement à la méthode que Bernstein a attaqué dans le
cas de l'AES, en s'appuyant sur les variations de temps d'exécution
d'accès à un index de tableau en fonction des alignements de données et
en fonction des conflits d'accès au cache, qui se produisent quand le
modulo de l'adresse dans le tableau par la taille des lignes de cache,
est en collision avec celui d'autre données par ailleurs dans le cache.
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).
Ca, ça ressemble fortement à la méthode que Bernstein a attaqué dans le cas de l'AES, en s'appuyant sur les variations de temps d'exécution d'accès à un index de tableau en fonction des alignements de données et en fonction des conflits d'accès au cache, qui se produisent quand le modulo de l'adresse dans le tableau par la taille des lignes de cache, est en collision avec celui d'autre données par ailleurs dans le cache.
nlevol
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1)
D=e[i] Beau! L'idée de le byte « swap » est cela peut être utilisé seulement sur les adresses. L'algorithme peut être optimisé si les données sont eues accès utilisant des pointers. L'algo optimisé devient :
result2=message for (i=(length of key -2); i>=0; i--) { result1 = result2 * result2 result2 = result1 * Message D= e[i]-1 //merci ptrResult1 = ptrResult1 ^ (S & D) //Swap if e[i] ==0 ptrResult2 = ptrResult2 ^ (S & D) } result = result2
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant
que e[i] est 0 ou 1)
D=e[i] Beau!
L'idée de le byte « swap » est cela peut être utilisé seulement
sur les adresses. L'algorithme peut être optimisé si les données
sont eues accès utilisant des pointers. L'algo optimisé devient :
result2=message
for (i=(length of key -2); i>=0; i--) {
result1 = result2 * result2
result2 = result1 * Message
D= e[i]-1 //merci
ptrResult1 = ptrResult1 ^ (S & D) //Swap if e[i] ==0
ptrResult2 = ptrResult2 ^ (S & D)
}
result = result2
D=e[i] Beau! L'idée de le byte « swap » est cela peut être utilisé seulement sur les adresses. L'algorithme peut être optimisé si les données sont eues accès utilisant des pointers. L'algo optimisé devient :
result2=message for (i=(length of key -2); i>=0; i--) { result1 = result2 * result2 result2 = result1 * Message D= e[i]-1 //merci ptrResult1 = ptrResult1 ^ (S & D) //Swap if e[i] ==0 ptrResult2 = ptrResult2 ^ (S & D) } result = result2
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 ?
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1)
unsigned mask = (unsigned)(e[i]) - (unsigned)1; result = mask&result | ~mask&result2; il faut faire très gaffe... les processeurs modernes sont très
intelligents, et notamment ils détectent quand un résultat n'est pas utilisé...
si on ne connais pas l'architecture du processue, le compilateur et l'algorithme, don dis plein de conneries...
un exemple c'est le mythe du double check locking en java, qui ne marche pas, et pour lequel tout les tentatives de contournement échouent... pour comprendre pourquoi il faut bien comprendre les processeurs, les carte multi-processeurs, les compilateurs hostspot de la machine virtuelle et le modèle d'exécution...
avec un processeur réel c'est encore pire...
dans l'article ils expliquaient que plein de solutions avaient été testées sans succès... un système ou on équilibrait les branche de calcul notamment...
je crois que le principe est d'utiliser la table des prédiction de branchement associée aux lignes de code... en repassant dans une ligne de code on dois pouvoir sentir le chemin du prédécesseur.
Dans l'article <1164062838.476548.294070@h48g2000cwc.googlegroups.com>,
"nlevol" <nlevol@yahoo.com> écrit:
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 ?
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant
que e[i] est 0 ou 1)
unsigned mask = (unsigned)(e[i]) - (unsigned)1;
result = mask&result | ~mask&result2;
il faut faire très gaffe... les processeurs modernes sont très
intelligents, et notamment ils détectent quand un résultat n'est pas
utilisé...
si on ne connais pas l'architecture du processue, le compilateur et
l'algorithme, don dis plein de conneries...
un exemple c'est le mythe du double check locking en java, qui ne marche
pas, et pour lequel tout les tentatives de contournement échouent...
pour comprendre pourquoi il faut bien comprendre les processeurs, les
carte multi-processeurs, les compilateurs hostspot de la machine
virtuelle et le modèle d'exécution...
avec un processeur réel c'est encore pire...
dans l'article ils expliquaient que plein de solutions avaient été
testées sans succès... un système ou on équilibrait les branche de
calcul notamment...
je crois que le principe est d'utiliser la table des prédiction de
branchement associée aux lignes de code... en repassant dans une ligne
de code on dois pouvoir sentir le chemin du prédécesseur.
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 ?
A mon avis oui. La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1)
unsigned mask = (unsigned)(e[i]) - (unsigned)1; result = mask&result | ~mask&result2; il faut faire très gaffe... les processeurs modernes sont très
intelligents, et notamment ils détectent quand un résultat n'est pas utilisé...
si on ne connais pas l'architecture du processue, le compilateur et l'algorithme, don dis plein de conneries...
un exemple c'est le mythe du double check locking en java, qui ne marche pas, et pour lequel tout les tentatives de contournement échouent... pour comprendre pourquoi il faut bien comprendre les processeurs, les carte multi-processeurs, les compilateurs hostspot de la machine virtuelle et le modèle d'exécution...
avec un processeur réel c'est encore pire...
dans l'article ils expliquaient que plein de solutions avaient été testées sans succès... un système ou on équilibrait les branche de calcul notamment...
je crois que le principe est d'utiliser la table des prédiction de branchement associée aux lignes de code... en repassant dans une ligne de code on dois pouvoir sentir le chemin du prédécesseur.
Francois Grieu
Dans l'article <45637ec1$0$27376$, Alain a écrit:
Dans l'article , La ligne if (e[i]==1) result=result2 peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1) unsigned mask = (unsigned)(e[i]) - (unsigned)1; result = mask&result | ~mask&result2;
il faut faire très gaffe... les processeurs modernes sont très intelligents, et notamment ils détectent quand un résultat n'est pas utilisé...
Je ne demande qu'à être (légèrement) supris: quel compilateur et/ou processeur existant sait ne pas évaluer result ou result2 dans le morceau de code que j'ai donné ?
Bien que j'ai parlé de C, j'admet d'autres languages, y compris Java+JIT.
François Grieu
Dans l'article <45637ec1$0$27376$ba4acef3@news.orange.fr>,
Alain <none@none.org> a écrit:
Dans l'article <1164062838.476548.294070@h48g2000cwc.googlegroups.com>,
La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant
que e[i] est 0 ou 1)
unsigned mask = (unsigned)(e[i]) - (unsigned)1;
result = mask&result | ~mask&result2;
il faut faire très gaffe... les processeurs modernes sont très
intelligents, et notamment ils détectent quand un résultat n'est
pas utilisé...
Je ne demande qu'à être (légèrement) supris: quel compilateur et/ou
processeur existant sait ne pas évaluer result ou result2 dans le
morceau de code que j'ai donné ?
Bien que j'ai parlé de C, j'admet d'autres languages, y compris
Java+JIT.
Dans l'article , La ligne if (e[i]==1) result=result2 peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1) unsigned mask = (unsigned)(e[i]) - (unsigned)1; result = mask&result | ~mask&result2;
il faut faire très gaffe... les processeurs modernes sont très intelligents, et notamment ils détectent quand un résultat n'est pas utilisé...
Je ne demande qu'à être (légèrement) supris: quel compilateur et/ou processeur existant sait ne pas évaluer result ou result2 dans le morceau de code que j'ai donné ?
Bien que j'ai parlé de C, j'admet d'autres languages, y compris Java+JIT.
François Grieu
michael.spath
Jean-Marc Desperrier wrote:
nlevol wrote:
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).
Ca, ça ressemble fortement à la méthode que Bernstein a attaqué d ans le cas de l'AES,
En stockant la (les) paire(s) d'adresses contigument et ou il faut, les 2 adresses possibles tiennent largement dans une ligne de cache, donc pas de danger. Par contre, remplacer un branchement conditionnel par un branchement indirect ne resoud pas vraiment les choses, puisque les branchements indirects sont aussi predits, et sont donc potentiellement vulnerables a la meme attaque.
A mon avis le plus facile pour se proteger sur PC est d'utiliser un OS avec ASLR (Address space layout randomization), ou de l'ajouter avec un module externe.
En tous cas puisque M.Grieu vient de se pencher sur les attaques liees au timings, j'espere qu'il va continuer sur ce nouveau probleme et publier ses resultats ;-)
regards, --spath
Jean-Marc Desperrier wrote:
nlevol wrote:
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).
Ca, ça ressemble fortement à la méthode que Bernstein a attaqué d ans le
cas de l'AES,
En stockant la (les) paire(s) d'adresses contigument et ou il faut,
les 2 adresses possibles tiennent largement dans une ligne de
cache, donc pas de danger. Par contre, remplacer un branchement
conditionnel par un branchement indirect ne resoud pas vraiment les
choses, puisque les branchements indirects sont aussi predits, et
sont donc potentiellement vulnerables a la meme attaque.
A mon avis le plus facile pour se proteger sur PC est d'utiliser un
OS avec ASLR (Address space layout randomization), ou de l'ajouter
avec un module externe.
En tous cas puisque M.Grieu vient de se pencher sur les attaques
liees au timings, j'espere qu'il va continuer sur ce nouveau probleme
et publier ses resultats ;-)
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).
Ca, ça ressemble fortement à la méthode que Bernstein a attaqué d ans le cas de l'AES,
En stockant la (les) paire(s) d'adresses contigument et ou il faut, les 2 adresses possibles tiennent largement dans une ligne de cache, donc pas de danger. Par contre, remplacer un branchement conditionnel par un branchement indirect ne resoud pas vraiment les choses, puisque les branchements indirects sont aussi predits, et sont donc potentiellement vulnerables a la meme attaque.
A mon avis le plus facile pour se proteger sur PC est d'utiliser un OS avec ASLR (Address space layout randomization), ou de l'ajouter avec un module externe.
En tous cas puisque M.Grieu vient de se pencher sur les attaques liees au timings, j'espere qu'il va continuer sur ce nouveau probleme et publier ses resultats ;-)
regards, --spath
Alain
Dans l'article <45637ec1$0$27376$, Alain a écrit:
Dans l'article , La ligne if (e[i]==1) result=result2 peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1) unsigned mask = (unsigned)(e[i]) - (unsigned)1; result = mask&result | ~mask&result2;
il faut faire très gaffe... les processeurs modernes sont très intelligents, et notamment ils détectent quand un résultat n'est pas utilisé...
Je ne demande qu'à être (légèrement) supris: quel compilateur et/ou processeur existant sait ne pas évaluer result ou result2 dans le morceau de code que j'ai donné ? je pense aussi que ca marche, mais je ne jurerais de rien
dans l'article original http://cryptome.org/sbpa/sbpa.htm qui est plus clair, on comprend mieux l'astuce...
il y a quelques années je sais que certains travaillaient sur des prédicteurs de valeur pour les résultats d'opération, histoire d'aller encore plus loin que les BPA. c'est vrai que ces cherchers étaient en avance et que les processeurs MTA et multi-coeur actuels ne sont que des versions anciennes et réduites de leurs idées...
d'autre part si le compilo détecte que e[i]=0 ou 1, il peut faire une optimisation en mettant un branch et en déroulant le calcul... il y a des compilo vraiement efficace... surtout s'il tiennent compte justement de l'exécution spéculative pour optimiser en utilisant des branch...
Bien que j'ai parlé de C, j'admet d'autres languages, y compris Java+JIT.
effectivement un JIT type hotspot pourra décider d'optimiser en faisant des tests... une optimisation en smalltalk que j'avais vu c'était le déroulement de test de classe...
le système observe les classe fréquentes et transforme un code du style
Dans l'article <45637ec1$0$27376$ba4acef3@news.orange.fr>,
Alain <none@none.org> a écrit:
Dans l'article <1164062838.476548.294070@h48g2000cwc.googlegroups.com>,
La ligne
if (e[i]==1) result=result2
peut effectivement s'écrire sans branchement (en C, en supposant
que e[i] est 0 ou 1)
unsigned mask = (unsigned)(e[i]) - (unsigned)1;
result = mask&result | ~mask&result2;
il faut faire très gaffe... les processeurs modernes sont très
intelligents, et notamment ils détectent quand un résultat n'est
pas utilisé...
Je ne demande qu'à être (légèrement) supris: quel compilateur et/ou
processeur existant sait ne pas évaluer result ou result2 dans le
morceau de code que j'ai donné ?
je pense aussi que ca marche, mais je ne jurerais de rien
dans l'article original
http://cryptome.org/sbpa/sbpa.htm
qui est plus clair, on comprend mieux l'astuce...
il y a quelques années je sais que certains travaillaient sur des
prédicteurs de valeur pour les résultats d'opération, histoire d'aller
encore plus loin que les BPA. c'est vrai que ces cherchers étaient en
avance et que les processeurs MTA et multi-coeur actuels ne sont que des
versions anciennes et réduites de leurs idées...
d'autre part si le compilo détecte que e[i]=0 ou 1, il peut faire une
optimisation en mettant un branch et en déroulant le calcul...
il y a des compilo vraiement efficace... surtout s'il tiennent compte
justement de l'exécution spéculative pour optimiser en utilisant des
branch...
Bien que j'ai parlé de C, j'admet d'autres languages, y compris
Java+JIT.
effectivement un JIT type hotspot pourra décider d'optimiser en faisant
des tests... une optimisation en smalltalk que j'avais vu c'était le
déroulement de test de classe...
le système observe les classe fréquentes et transforme un code du style
Dans l'article , La ligne if (e[i]==1) result=result2 peut effectivement s'écrire sans branchement (en C, en supposant que e[i] est 0 ou 1) unsigned mask = (unsigned)(e[i]) - (unsigned)1; result = mask&result | ~mask&result2;
il faut faire très gaffe... les processeurs modernes sont très intelligents, et notamment ils détectent quand un résultat n'est pas utilisé...
Je ne demande qu'à être (légèrement) supris: quel compilateur et/ou processeur existant sait ne pas évaluer result ou result2 dans le morceau de code que j'ai donné ? je pense aussi que ca marche, mais je ne jurerais de rien
dans l'article original http://cryptome.org/sbpa/sbpa.htm qui est plus clair, on comprend mieux l'astuce...
il y a quelques années je sais que certains travaillaient sur des prédicteurs de valeur pour les résultats d'opération, histoire d'aller encore plus loin que les BPA. c'est vrai que ces cherchers étaient en avance et que les processeurs MTA et multi-coeur actuels ne sont que des versions anciennes et réduites de leurs idées...
d'autre part si le compilo détecte que e[i]=0 ou 1, il peut faire une optimisation en mettant un branch et en déroulant le calcul... il y a des compilo vraiement efficace... surtout s'il tiennent compte justement de l'exécution spéculative pour optimiser en utilisant des branch...
Bien que j'ai parlé de C, j'admet d'autres languages, y compris Java+JIT.
effectivement un JIT type hotspot pourra décider d'optimiser en faisant des tests... une optimisation en smalltalk que j'avais vu c'était le déroulement de test de classe...
le système observe les classe fréquentes et transforme un code du style
En stockant la (les) paire(s) d'adresses contigument et ou il faut, les 2 adresses possibles tiennent largement dans une ligne de cache, donc pas de danger.
Effectivement la solution est de choisir l'adresse comme il faut, mais il faut une connaissance très poussée du processeur pour trouver tout ce qu'il faut prendre en compte (certains éléments ne sont sont pas clairement documentés) et de telles contraintes sur l'ensemble des éléments accédés commencent à rendre l'écriture du code sacrément compliquée. Je pense qu'il vaut mieux lire complètement l'article de Bernstein pour voir l'ampleur du problème : http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Note : Bien qu'il publie son résultat, et au moins une partie des idées, il n'y a pas la version finale de son code dont il déclare qu'il corrige les problèmes.
[...]
A mon avis le plus facile pour se proteger sur PC est d'utiliser un OS avec ASLR (Address space layout randomization), [...]
En fait, c'est le point qui n'est pas clair pour moi dans l'attaque, repose-t-elle ou non sur le fait de savoir exactement où se trouve dans l'espace mémoire les instruction de sauts dans l'algorithme de calcul RSA.
Il écrit un code qui sature le cache de prédiction de branchement, il regarde après qu'une exécution du code RSA se soit glissée au milieu de l'exécution de son programme quelles lignes du cache ont été vidées, mais a-t-il besoin de savoir l'adresse des instructions du RSA pour faire correspondre à chaque ligne du cache ou peut-il le déduire du résultat ? Le deuxième cas me semble possible, et alors ce n'est pas une ASLR qui va suffir à se protéger.
Un peu plus complexe, mais plus efficace je crois, serait d'avoir un OS auquel on peut dire qu'un thread est "sensible", et qu'à la fin de chaque "time slice" où le code du thread a été exécuté, avant de consacrer un "time slice" à un autre programme, il faut exécuter un code particulier destiné aujourd'hui à vider le BTB mais qui pourra être complété demain pour d'autres caches.
michael.spath@gmail.com wrote:
En stockant la (les) paire(s) d'adresses contigument et ou il faut,
les 2 adresses possibles tiennent largement dans une ligne de
cache, donc pas de danger.
Effectivement la solution est de choisir l'adresse comme il faut, mais
il faut une connaissance très poussée du processeur pour trouver tout ce
qu'il faut prendre en compte (certains éléments ne sont sont pas
clairement documentés) et de telles contraintes sur l'ensemble des
éléments accédés commencent à rendre l'écriture du code sacrément
compliquée. Je pense qu'il vaut mieux lire complètement l'article de
Bernstein pour voir l'ampleur du problème :
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Note : Bien qu'il publie son résultat, et au moins une partie des idées,
il n'y a pas la version finale de son code dont il déclare qu'il corrige
les problèmes.
[...]
A mon avis le plus facile pour se proteger sur PC est d'utiliser un
OS avec ASLR (Address space layout randomization), [...]
En fait, c'est le point qui n'est pas clair pour moi dans l'attaque,
repose-t-elle ou non sur le fait de savoir exactement où se trouve dans
l'espace mémoire les instruction de sauts dans l'algorithme de calcul RSA.
Il écrit un code qui sature le cache de prédiction de branchement, il
regarde après qu'une exécution du code RSA se soit glissée au milieu de
l'exécution de son programme quelles lignes du cache ont été vidées,
mais a-t-il besoin de savoir l'adresse des instructions du RSA pour
faire correspondre à chaque ligne du cache ou peut-il le déduire du
résultat ? Le deuxième cas me semble possible, et alors ce n'est pas une
ASLR qui va suffir à se protéger.
Un peu plus complexe, mais plus efficace je crois, serait d'avoir un OS
auquel on peut dire qu'un thread est "sensible", et qu'à la fin de
chaque "time slice" où le code du thread a été exécuté, avant de
consacrer un "time slice" à un autre programme, il faut exécuter un code
particulier destiné aujourd'hui à vider le BTB mais qui pourra être
complété demain pour d'autres caches.
En stockant la (les) paire(s) d'adresses contigument et ou il faut, les 2 adresses possibles tiennent largement dans une ligne de cache, donc pas de danger.
Effectivement la solution est de choisir l'adresse comme il faut, mais il faut une connaissance très poussée du processeur pour trouver tout ce qu'il faut prendre en compte (certains éléments ne sont sont pas clairement documentés) et de telles contraintes sur l'ensemble des éléments accédés commencent à rendre l'écriture du code sacrément compliquée. Je pense qu'il vaut mieux lire complètement l'article de Bernstein pour voir l'ampleur du problème : http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Note : Bien qu'il publie son résultat, et au moins une partie des idées, il n'y a pas la version finale de son code dont il déclare qu'il corrige les problèmes.
[...]
A mon avis le plus facile pour se proteger sur PC est d'utiliser un OS avec ASLR (Address space layout randomization), [...]
En fait, c'est le point qui n'est pas clair pour moi dans l'attaque, repose-t-elle ou non sur le fait de savoir exactement où se trouve dans l'espace mémoire les instruction de sauts dans l'algorithme de calcul RSA.
Il écrit un code qui sature le cache de prédiction de branchement, il regarde après qu'une exécution du code RSA se soit glissée au milieu de l'exécution de son programme quelles lignes du cache ont été vidées, mais a-t-il besoin de savoir l'adresse des instructions du RSA pour faire correspondre à chaque ligne du cache ou peut-il le déduire du résultat ? Le deuxième cas me semble possible, et alors ce n'est pas une ASLR qui va suffir à se protéger.
Un peu plus complexe, mais plus efficace je crois, serait d'avoir un OS auquel on peut dire qu'un thread est "sensible", et qu'à la fin de chaque "time slice" où le code du thread a été exécuté, avant de consacrer un "time slice" à un autre programme, il faut exécuter un code particulier destiné aujourd'hui à vider le BTB mais qui pourra être complété demain pour d'autres caches.
michael.spath
Jean-Marc Desperrier wrote:
Je pense qu'il vaut mieux lire complètement l'article de Bernstein pour voir l'ampleur du problème :
Je l'ai lu, et nulle part je n'ai vu qu'il pensait pouvoir detecter une difference entre les temps d'acces de deux double words dans la meme ligne de cache. Si quelqu'un sait faire ca, ca m'interesse :)
En fait, c'est le point qui n'est pas clair pour moi dans l'attaque, repose-t-elle ou non sur le fait de savoir exactement où se trouve dans l'espace mémoire les instruction de sauts dans l'algorithme de calcul RSA.
L'explication est dans le paragraphe 3 :
"Also a spy process is executed [...] in such a way that all of these branches map to the same BTB set which also stores the specific conditional branch determined by the secret key bits of the crypto process."
Comme les entrees du BTB sont indexees d'apres l'adresse de branchement, le process espion doit connaitre l'adresse de la branche de l'application cryptographique a espionner de facon a placer ses propres branches dans le meme BTB set. Sans connaitre l'adresse on ne connait pas le set a espionner, et ca devient impossible.
regards, --spath
Jean-Marc Desperrier wrote:
Je pense qu'il vaut mieux lire complètement
l'article de Bernstein pour voir l'ampleur
du problème :
Je l'ai lu, et nulle part je n'ai vu qu'il pensait
pouvoir detecter une difference entre les temps
d'acces de deux double words dans la meme ligne de
cache. Si quelqu'un sait faire ca, ca m'interesse :)
En fait, c'est le point qui n'est pas clair pour moi
dans l'attaque, repose-t-elle ou non sur le fait de
savoir exactement où se trouve dans l'espace
mémoire les instruction de sauts dans l'algorithme
de calcul RSA.
L'explication est dans le paragraphe 3 :
"Also a spy process is executed [...] in such a way
that all of these branches map to the same BTB set
which also stores the specific conditional branch
determined by the secret key bits of the crypto process."
Comme les entrees du BTB sont indexees d'apres l'adresse
de branchement, le process espion doit connaitre l'adresse
de la branche de l'application cryptographique a espionner de
facon a placer ses propres branches dans le meme BTB set.
Sans connaitre l'adresse on ne connait pas le set a espionner,
et ca devient impossible.
Je pense qu'il vaut mieux lire complètement l'article de Bernstein pour voir l'ampleur du problème :
Je l'ai lu, et nulle part je n'ai vu qu'il pensait pouvoir detecter une difference entre les temps d'acces de deux double words dans la meme ligne de cache. Si quelqu'un sait faire ca, ca m'interesse :)
En fait, c'est le point qui n'est pas clair pour moi dans l'attaque, repose-t-elle ou non sur le fait de savoir exactement où se trouve dans l'espace mémoire les instruction de sauts dans l'algorithme de calcul RSA.
L'explication est dans le paragraphe 3 :
"Also a spy process is executed [...] in such a way that all of these branches map to the same BTB set which also stores the specific conditional branch determined by the secret key bits of the crypto process."
Comme les entrees du BTB sont indexees d'apres l'adresse de branchement, le process espion doit connaitre l'adresse de la branche de l'application cryptographique a espionner de facon a placer ses propres branches dans le meme BTB set. Sans connaitre l'adresse on ne connait pas le set a espionner, et ca devient impossible.
