attaque stupéfiante contre AES
Le
cgonzale
http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
Poser une question
cela signifie qu'il y a un cheval de troie sur le pc qui crypte.
Ce cheval de troie "serait" capable de mesurer les différentes phases du
cryptage --> donc le pgm crypteur est compilé avec les infos de
déboggages, et le cheval de troie à accès à un debogger/profileur -->
autant dire que meme avec un algo a temps constant ce cheval de troie
pourrait avoir accès à toutes les données présentes sur le PC donc à la
clé sans même trop se casser la tete (lecture du clavier, lecture des
ports usb, ...)
Le pb ne vient pas de l'algo !
Ce n'est pas aussi simple. L'article vaut en tout cas la peine d'être lu
(ce que je viens de faire) et étudié (ce que je n'ai pas encore fait).
On Thu, 21 Apr 2005 wrote:
Comme pour n'importe quel autre algo. Les timing attacks, ça marche à peu
près partout.
Et contrairement à ce qu'affirme Thierry Nivon, il n'y a pas de binaire
étranger tournant sur le serveur. C'est réellement une attaque entre un
serveur possédant et mettant en oeuvre une clé et un client mesurant le
temps mis pour effectuer les opérations de chiffrement.
La conclusion n'est pas aussi franche. Bernstein propose des pistes, tant
pour les implémenteurs d'AES que pour les fondeurs de microprocesseurs. Le
plus gros du travail en revient aux fondeurs, puisqu'écrire une
implémentation d'AES fonctionnant en temps constant (avec des opérations
logiques, et sans lookup) rendrait cette implémentation beaucoup trop
lente.
A part ça, l'article mérite en effet d'être lu, et ceux qui ont lu la
première version (20041111 je crois, je l'ai effacé) trouveront des
ajouts intéressants, sur d'autres causes menant à ces problèmes de cache
timing. On voit clairement que la complexité des microprocesseurs actuels
est difficilement maîtrisable à la main.
--
Erwann ABALEA -----
Salut,Je m'appele sed.je suis etudiant en communication, j'ai lu votre
message.je viens vous dire un petiit bonjour,et vous laisser mon adresse
mél: vous pouvez me repondre maintenant si vous étez conecter.
-+-Guide du Neuneu d'Usenet - La com', elle ne passera pas par moi -+-
notamment, DJB met directement en cause le design plutôt que
l'implémentation de AES
(le message ci-dessous vient de sci.crypt). Dans son article, il y a aussi
un chapitre dédié au NIST: "7 Errors in the AES standardization process".
Olivier Gay
Pas d'accord.
Primo, l'attaque a vraiment été menée contre un serveur depuis
un client distant (il est vrai vraissemblablement connectés
par un lien réseau très direct): "the only way I had accessed the key
was by talking to the server through the network".
Secondo, un modèle d'attaque où l'adversaire peut exécuter du code
sur le même CPU que le système attaqué n'est nullement irréaliste;
penser à un système unix avec un compte invité; dans ce cas,
un programme sur un compte invité peut envoyer des requètes à un
serveur local sans la latence liée à un réseau; et même, il
peut éventuellement déterminer, indépendemment d'une mesure
de temps d'exécution, quelles lignes de cache ont été invalidées par
un autre process.
Je trouve tout à fait justifiée l'observation de DJB que sur un CPU
moderne il faut craindre les "side channel attacks" liées aux
consultatons de table, et que c'est un problème non négligeable lié
au design d'AES.
François Grieu