Ils font quand même l'hypothèse assez forte qu'il y a un processus malveillant sur le même ordinateur, qui fonctionne en même temps que le programme de chiffrement.
Je ne trouve pas l'hypothèse si forte: tu peux retrouver la clé de chiffrement d'un disque dur pour une machine sur laquelle tu as un simple accès car dans ce cas tu peux forcer le programme de chiffrement à fonctionner en écrivant sur le disque dur. Ça a été fait en pratique, et c'est très efficace—bien sûr, ça ne marche plus aujourd'hui.
J'avais été voir une présentation de Shamir au collège de France. Il y avait présenté une attaque basée sur les variations de la tension sur les ports USB ou du bruit émis par la machine: le stepping du processeur, qui change suivant la charge demandée, provoque ces variations, au point que statistiquement tu arrives à différencier les multiplications des additions (et donc le bit de poids faible en cours d'inspection) lors du chiffrement RSA. A l'époque, c'était encore un peu fumeux, mais l'attaque s'améliore:
Par rapport à mon propos, oui et non. Oui, l'instruction Intel est là pour protéger AES contre ces attaques sans avoir une dégradation catastrophique des performances. Mais non, quitter l'assembleur ne va pas régler le problème des canaux cachés. J'aurais tendance à dire: au contraire même. Et l'analyse de ces implémentations va, avec l'état de l'art courant, être bien difficile aussi: il n'y a pas de modèle du JIT, il n'y a pas de modèle du GC. Ça ne veut pas dire que ça ne va pas arriver... et dans ce cas, avoir un langage de haut niveau permettra de mieux analyser le protocole en lui-même. Car TLS (même en 1.2) est très limite niveau crypto, et la RFC laisse certaine partie à interprétation.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Burps . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 5.
Je ne trouve pas l'hypothèse si forte: tu peux retrouver la clé de chiffrement d'un disque dur pour une machine sur laquelle tu as un simple accès car dans ce cas tu peux forcer le programme de chiffrement à fonctionner en écrivant sur le disque dur. Ça a été fait en pratique, et c'est très efficace—bien sûr, ça ne marche plus aujourd'hui.
J'avais été voir une présentation de Shamir au collège de France. Il y avait présenté une attaque basée sur les variations de la tension sur les ports USB ou du bruit émis par la machine: le stepping du processeur, qui change suivant la charge demandée, provoque ces variations, au point que statistiquement tu arrives à différencier les multiplications des additions (et donc le bit de poids faible en cours d'inspection) lors du chiffrement RSA. A l'époque, c'était encore un peu fumeux, mais l'attaque s'améliore:
https://eprint.iacr.org/2013/857
Par rapport à mon propos, oui et non. Oui, l'instruction Intel est là pour protéger AES contre ces attaques sans avoir une dégradation catastrophique des performances. Mais non, quitter l'assembleur ne va pas régler le problème des canaux cachés. J'aurais tendance à dire: au contraire même. Et l'analyse de ces implémentations va, avec l'état de l'art courant, être bien difficile aussi: il n'y a pas de modèle du JIT, il n'y a pas de modèle du GC. Ça ne veut pas dire que ça ne va pas arriver... et dans ce cas, avoir un langage de haut niveau permettra de mieux analyser le protocole en lui-même. Car TLS (même en 1.2) est très limite niveau crypto, et la RFC laisse certaine partie à interprétation.