Thread by @EnDirectDuLabo

Je vous raconte maintenant ma thèse : donc pour le contexte, j'étais à @TelecomPTech dans un labo de sécurité électronique numérique.
Je suis donc un informaticien entouré majoritairement d'électronicien·ne·s !

Mais c'était bien utile : l'idée de mon projet thèse c'était de faire de la protection automatique et prouvée de code contre les attaques par canaux auxiliaires.

Les attaques par canaux auxiliaires, ce sont des attaques qui utilisent des informations auxiliaires qui dépendent de l'implémentation d'un algorithme, c'est à dire de la façon dont il est mis en œuvre.

Par exemple, vous pouvez avoir un algorithme de chiffrement qui est mathématiquement très solide et qu'on arrive pas à attaquer par cryptanalyse classique (avec des maths quoi) mais qui est trivial à casser par side-channel (= canaux auxiliaires, je vais probablement dire les 2).

Imaginez par exemple que cet algorithme utilise une clef secrète pour le chiffrement. L'attaque consiste à retrouver la clef secrète. Mathématiquement, recalculer la clef secrète nécessite de résoudre des problèmes très difficile en prendrait des milliards d'années.

Admettons que notre algo parcourt un à un les bits de la clef secrète et fait pour chacun une transformation sur le message qui dépend de si le bit est 1 ou 0.

Déjà, si le temps de calcul nécessaire à la transformation est différent dans le cas où le bit est 0 et dans le cas où le bit est 1, et bien le temps total de calcul nous informe sur le nombre de bit à 1 et à 0 dans la clef secrète, mais c'est pas le pire…

Parce que la consommation de courant d'un circuit électronique dépend assez directement 1- du nombre de bits à 1 dans le circuit (poids de Hamming) et surtout 2- du nombre de bitflips (passage de 0 à 1 ou de 1 à 0) à chaque cycle (distance de Hamming).

Et donc en regardant la consommation de courant du composant sur lequel le code de l'algorithme tourne, on peut avoir encore plus d'information, et parfois même lire directement la valeur de la clef sur un oscilloscope ! #NotJamesBond #ActualScience #FxxxYeah

Ah, téléphone !

Fini ! Je reprends.

En fait, ce type d'attaque est assez récents. Ça a fait un gros boum quand c'est arrivé via un article de recherche de Paul Kocher en 1996. Il a fallut corriger rapidement beaucoup de produits dans des industries assez sensibles.

Par exemple les smartcards (carte bancaire, carte SIM, carte de décodeurs télé, etc.) sont extrêmement vulnérable à ce type d'attaque, parce qu'il n'y a quasi que la crypto qui tourne dessus, sans bruits parasites.

Et donc les premiers gros efforts pour corriger tout ça ont été majoritairement le fruit de l'industrie. Ça veut dire avec des contraintes d'ingénierie et non de recherche : budget à minimiser, délais courts, etc.

Le résultat c'est tout un tas de contre-mesures souvent développées par essais-erreurs : tant qu'on arrive à attaquer, on essaye de comprendre vaguement pourquoi, on patch et on recommence.

Et donc mon objectif initial en thèse, c'était d'essayer de nettoyer un peu tout ça : comprendre ce qui marche et comment, pour pouvoir ensuite automatiser l'insertion de protection.

Comme beaucoup de gens j'ai commencé ma thèse avec l'objectif de révolutionner le monde : en mode je vais rajouter une option dans les compilateur GCC et Clang qui demande la protection du code en réutilisant les méthodes existantes et bim y aura plus de soucis.

Bien sûr j'ai *pas du tout* fait ça, mais un ensemble de petites choses bien plus modestes. Mais stylées quand même, vous allez voir ^_^.

J'ai donc commencé à travailler sur un type de contre-mesure contre les attaques par analyse de consommation de courant : l'équilibrage.

En fait, on peut dire qu'il y a deux types de contre-mesure.
Les contre-mesures palliatives, et les contre-mesures curatives.

L'idée des contre-mesures palliatives, c'est un peu ce qu'on a envie de faire naturellement : grosso-mode rajouter du bordel aléatoire pour rendre l'attaque plus difficile.

Mais comme je vous le disais, y a des gens fort en stats qui savent faire des outils qui réduisent le bruit, et les attaques side-channel sont si puissantes qu'il est nécessaire de faire les choses plus proprement.

C'est là que viennent les contre-mesures curatives : l'idée cette fois-ci est de se baser sur un fondement théorique et un cadre formel pour tenter d'empêcher la fuite d'information.

Là aussi, on a deux grandes stratégies : le masquage, et l'équilibrage.

L'idée du masquage, c'est de mélanger (masquer) les valeurs sensibles qu'on manipule avec des nombres aléatoires, d'une façon qui va rendre la fuite décorrélée (en moyenne) des données sensibles.

L'avantage de cette méthode, c'est qu'à priori elle ne dépend pas du matériel (donc on peut changer juste le logiciel), et aussi qu'elle a été pas mal étudiée y compris du côté académique, il existe même des mécanismes de masquage prouvés corrects.

En revanche, il y a des attaques plus puissantes (et plus coûteuses), comme les attaques algébriques (me demandez pas trop de rentrer dans les détails ^^), qui voient juste les masques (les nombres aléatoires) comme des variables inconnues supplémentaires et s'en accommode bien.

Ces contre-mesures sont aussi très coûteuses en ressources, ne serait-ce que parce que générer des bons nombres aléatoires utilisables pour la cryptographie, c'est très difficile.

Et on arrive donc à l'équilibrage. Cette fois-ci le but est de rendre la fuite constante, c'est à dire complètement indépendante des données sensibles : les informations vues par canaux auxiliaires doivent être les mêmes quelques soient les données sensibles.

Au début ce type de contre-mesures a été développé au niveau matériel. L'idée et de tout faire en double. Chaque bit est représenté par une paire de bits : 0 devient (1,0) et 1 devient (0,1). Et on s'arrange pour faire les calculs de telle sorte qu'on ait toujours >>

>> le même nombre de bits (matériels, ceux dans les paires) à 1 et à 0, et aussi toujours le même nombres de bits (matériels) passant de 0 à 1 et de 1 à 0. De cette façons la consommation du système ne dépend plus du tout des données sensibles !

Eeeeeet… ça échoue. Pourquoi ? Parce que les subtiles différences de longueurs des "fils" dans les circuits électroniques font que les changements d'états des bits n'arrivent pas exactement au même moment et qu'on a des oscilloscopes suffisamment fins pour le voir.

Les systèmes sensibles type smartcards tournent au mieux à quelques centaines de millions de cycles par secondes (en MHz donc) et on a des appareils de mesures pouvant faire des milliards de relevés par secondes.

Bon il s'est passé plein de trucs, des tas de tentatives de composants électroniques de synchronisations etc. Finalement, c'est bien le masquage qui a la côte.

Mais bon, il y avait quelqu'un dans mon labo qui venait de partir à la retraite et qui avait proposé une suite d'instruction en langage assembleur qui permettait de mettre en place un protocole d'équilibrage au niveau logiciel.

La difficulté étant de toujours respecter notre invariant de sécurité : rappelez-vous, poids de Hamming et distance de Hamming complètement indépendant des données sensibles

External Tweet loading...
If nothing shows, it may have been deleted
by @EnDirectDuLabo view original on Twitter

Petite parenthèse : le langage assembleur est un langage très bas niveau dans lequel on donne une suite d'instructions directement au processeur de la machine. Ça se traduit (presque) directement en code binaire exécutable.

Ce qui est rigolo pour un informaticien dans un labo d'électronicien·ne·s, c'est que pour elleux l'assembleur c'est le "haut niveau" : logiciel et plus matériel.
Pour nous, l'assembleur c'est le plus bas niveau qu'on conçoit, en dessous c'est du matériel ça nous concerne plus :D.

Mais vous aurez compris que mon travail se situe à l'interface entre les deux, même si je reste fondamentalement informaticien. Fin de la parenthèse.

(Combien faut-il d'informaticien·ne·s pour changer une ampoule ?
Aucun·e, c'est un problème hardware.)

Donc d'une part on avait ce bout de code assembleur à tester, et d'autre part ça semblait beaucoup plus simple d'automatiser la transformation à ce niveau là, et en plus j'étais (je suis) trop à l'ouest en stats pour faire sérieusement du masquage.

Donc je m'attaque à l'automatisation d'une contremesure d'équilibrage et réutilisant l'idée de ce bout de code assembleur.
Pour ça j'ai écrit un outil, paioli (pablo.rauzy.name/sensi/paioli.h…) qui sait faire deux choses : >>

>> 1- manger du code assembleur, le transformer pour respecter le protocole d'équilibrage (on peut prouver que la transformation du code conserve bien sa sémantique, c'est à dire que le code résultat calcule bien la même chose que celui d'origine) ; et >>

>> 2- simuler l'exécution du code en vérifiant à chaque étape que l'invariant de sécurité est bien respecté partout et dans tous les cas (en faisant un genre d'interprétation abstraite, mais je vais me faire gronder par les gens qui savent ce que c'est si je dis que c'est ça).

Une fois que ça c'était fait, ben, fallait bien tester si ça marche pour de vrai !

Y a encore des gens qui suivent on je donne trop de détails et c'est reulou ? Dites moi hein si je raconte trop ma vie ^^ !

Pour tester y a pas à tortiller : on prend un algo de crypto, on le mets sur une smartcard, on l'attaque, on le passe dans ma moulinette, on le remet sur la carte, et on réattaque, et on voit combien c'était plus dur (hopefully ^^).

Le truc c'est que rappelez-vous, notre invariant de sécurité fait l'hypothèse qu'on a deux ressources (pour contenir les bits de nos paires qui représentent les bits logiques de notre calcul) qui fuit de manière identique, sinon forcément c'est déséquilibré…

Donc on regarde sur notre carte et là on s'aperçoit que les différents registres du processeurs (les cases mémoires dans le matériel où on stockerait les bits des paires pendant les calculs) ont des profils de fuites *très* différents.

Ça peut paraître surprenant mais en fait le même composant électronique placé ailleurs sur un circuit (donc avec un voisinage différent) ne va pas fuire de la même manière tellement ces choses là sont sensibles !

Mais bon, certains registres fuient de manière suffisamment peu distinctes pour que ça vaille le coup d'essayer. Et là : même à l'intérieur de chaque registres (tous de 8 bits), les différents bits fuient de façons différentes ! C'est SALE le matériel, vraiment crade :D.

Qu'à cela ne tienne, on profile chaque bits indépendamment en prenant la trace de consommation de l'exécution de l'algo en n'utilisant qu'un seul bit à chaque fois. En fait, c'est surtout le premier bit de chaque registre qui fuit bizarrement, les autres ça va tout se ressemble.

(Je dis "on", c'est toujours moi et Zak, l'ingé du labo, un gars super sympa d'à peu près mon âge qui est un genre de génie de la bidouille matérielle, sans lui j'aurais tellement *galéré* sur des centaines de trucs…)

Du coup on décide d'attaquer trois implémentations :
1- une non protégée, qui sert de "base" ;
2- une protégée mais en utilisant comme ressource les deux premiers bits (donc y compris le foireux), pour voir ce qu'apporte l'idée de la contremesure ; et >>

>> 3- une protégée qui prend en compte notre caractérisation du matériel et utilise les ressources qui maximisent les hypothèses que notre protection logicielle fait sur le matériel, pour montrer que ces hypothèses sont réalistes et apportent un vrai plus.

On prend donc des mesures : 100 000 traces de consommation de chaque implémentation, et on lance les attaques là dessus. Mine de rien, ça prend beaucoup de temps, d'énergie, de faire ce genre de campagne d'acquisition de traces.

On s'est retrouvé plusieurs fois avec Zak dans le labo jusqu'au milieu de la nuit (quand on se faisait virer par les vigiles ^^).

Nos résultats : on arrive à casser l'implémentation non protégée en utilisant seulement 400 traces, par contre on arrive pas à péter la deuxième même avec les 100000 traces :/.

Ça peut avoir l'air cool, mais en fait on a aussi envie de montrer le gain de la caractérisation du matériel, et on avait plus le labo à disposition pour refaire des acquisitions (et combien ?).

Donc on décide de faire un attaquant-tricheur, comme nous on sait déjà quelle est la bonne clef, on sélectionne une partie des traces où on voit que l'attaque mettra en avant la bonne clef.

Un vrai attaquant ne serait évidemment pas en mesure de faire ça, mais osef, on fait une contre-mesure donc on a le droit de prendre un attaquant surpuissant =).

Résultats cette fois-ci : l'implem non-protégée est cassée en moins de 140 traces, l'implem protégée mais mal équilibrées en environ 1500 traces, et l'implémentation protégée et un peu mieux équilibrée en un peu moins de 5000 traces ! Pfiou !

On avait donc une contre-mesure automatiquement insérée (avec une preuve que la transformation du code est correcte), vérifiant formellement un invariant de sécurité établi, et démontrablement efficace ! Le tout étant seulement entre 3 et 24 fois plus lent…

Ceci est à comparer avec les mécanismes de masquages prouvés, bien plus coûteux et visiblement pas toujours aussi efficace.

(Ça se voit que j'ai pris l'habitude de vendre mon travail ? :D)

Malgré tout, le masquage étant quand même largement plus à la mode, et la nécessité de preuves formelles pas encore bien vu dans la communauté, on a mis *longtemps* a publier ces résultats !
(Un de mes derniers papiers de thèse alors que c'est le premier boulot que j'ai fait !)

Entre temps j'ai bossé sur quelque chose dont je vous ai pas encore parlé, et c'est même là que j'ai fait mes contributions les plus importantes : les attaques par injections de fautes.

En fait, tout ce dont on a parlé jusqu'à présent ne correspond qu'à des attaques passives, où l'attaquant écoute / prend des mesures, mais n'agît pas sur le système.

Mais il existe aussi des attaques physiques actives !
Cette fois-ci, l'attaquant modifie le système pendant l'exécution de l'algorithme. Par exemple avec un laser on va "glitcher" un registre, ce qui va avoir pour effet de le mettre à zéro ou d'y mettre une valeur aléatoire.

Cela va avoir une influence sur le résultat final du calcul, et ce résultat va nous révéler des informations utiles pour retrouver la clef !

Ces attaques ont été découvertes par Dan Boneh, Richard DeMillo, et Richard Lipton de chez BellCoRe (Bell Communication Research) en 1997.

Là aussi c'est le séisme. Par exemple l'algorithme RSA, un des plus répandu, est complètement vulnérable : sa sécurité est basée sur la l'extrême difficulté mathématique de décomposer un très grand nombre en facteur premiers.
Il n'y a plus besoin que d'un calcul de PGCD !

En fait, pour améliorer la sécurité (sic) les implémentations de RSA sont optimisées : le gain en temps de calcul et en mémoire permet d'utiliser des clefs plus grandes.

En gros, le calcul de RSA se fait dans un ensemble de taille N = p×q, où p et q sont deux grands nombres premiers secrets. On dispose de N mais c'est très difficile à partir de là de retrouver p et q. Si on dispose de p et q on peut facilement recalculer la clef secrète.

Pour aller plus vite, on utilise le théorème des restes Chinois. C'est pas très compliqué, on voit ça en Terminale S quand on fait spé math.
L'idée c'est que ça permet de remplacer le gros calcul dans l'ensemble de taille N par deux calculs dans des ensembles de tailles p et q.

Chacun de ces deux calculs est 8 fois plus rapide que le gros, et comme on en fait deux on gagne un facteur 4 ! C'est absolument non négligeable, et RSA est implémenté comme ça partout, surtout dans l'embarqué (donc, dans votre carte bleue, par exemple).

À la fin des deux "petits" calculs, on fait une recombinaison rapide de leur résultat, et on obtient le résultat du calcul original dans l'ensemble de taille N.

Pour la suite, je vais appeler :
— Sp le résultat du calcul dans l'ensemble de taille p,
— Sq le résultat du calcul dans l'ensemble de taille q,
— S = CRT(Sp, Sq) le résultat de la recombinaison de Sp et Sq dans l'ensemble de taille N.
(CRT pour "Chinese Remainder Theorem").

Vous inquiétez pas y a pas de maths vraiment compliqués (sinon j'y aurais pas touché :-p), je donne juste des noms aux choses pour simplifier les explications :).

Il se trouve qu'en fait, avec la tailles des nombres dont on est en train de parler (p et q), les "petits" calculs prennent quand même des centaines de milliers de cycles d'horloge à s'exécuter.

Précision : quand vous lisez qu'un processeur va à 100MHz (100 mégaHertz) par exemple, ça veut dire qu'il fait 100 millions de cycles d'horloge par seconde.

Du coup, c'est extrêmement facile d'injecter une faute dans une partie du calcul (par exemple celle de Sp) mais pas dans l'autre.
Il suffit d'injecter une faute (laser ou glitch d'alimentation) n'importe quand et on est quasi sûr de ne toucher qu'une des deux parties.

On se retrouve donc avec une partie fausse (et on s'en fiche de fausse comment !) et l'autre correcte. Et du coup le résultat final est faux aussi.
Seulement voilà…

Mettons que la faute se fasse pendant le calcul de Sp, et que donc à sa place on obtient Qp (la version fautée de Sp).
Du coup on calcul non plus S = CRT(Sp, Sq),
mais plutôt Q = CRT(Qp, Sq).

On peut toujours obtenir S en refaisant le calcul sans injecter de faute.

Et il se trouve que dans ce cas S - Q va être un multiple de q…

(Ça aurait été un multiple de p si on avait fauté le calcule de Sq, et un multiple de N=p×q si on avait rien fauté).

Comme on connaît N, on peut calculer PGCD(N, S - Q).
Comme N = p×q deux nombres premiers, le résultat ne peut avoir que 4 valeurs :
– 1, si S - Q est premier avec N ;
– p, si S - Q est un multiple de p ;
– q, si S - Q est un multiple de q ;
– N, si S - Q est un multiple de p×q.

Du coup, c'est le drame : on retrouve q (ou p) avec un simple calcul de PGCD, et on peut après retrouver l'autre parce que p = N/q !
Toute la sécurité a fichu le camps !

Comme pour les attaques passives, il a fallu agir vite côté industriel, et les mêmes recettes ont été appliquées, mais cette fois de manière encore "pire".

Quand je suis arrivé la dessus au milieu de ma première année de thèse, les objectifs de sécurité n'étaient même pas clairement identifiés.

Je me suis retrouvé un peu par hasard au bon endroit au bon moment =). #LowHangingFruit

"Un peu par hasard" dans ce tweet c'est le pseudo de mon génial directeur de thèse, Sylvain Guilley, qui m'a amené voir une soutenance de thèse CIFRE sur le sujet et m'a dit "On devrait regarder ça nous aussi, y a moyen de mettre la pagaille".

C'est là que je rebondis sur une réaction d'il y a 3h :

La vérification c'est bien, mais ça ne vérifie que ce qu'on lui demande de vérifier, et pour ça il faut être capable de le modéliser…

External Tweet loading...
If nothing shows, it may have been deleted
by @Erigeish view original on Twitter

Vous êtes toujours là ? Je suis très bavard… c'est supportable ?

Je fini la thèse maintenant et on parle de choses plus légères ce soir ou j'arrête là pour la thèse et on continue demain ?

Je reprends donc :).

Dans ce contexte tous les encarteurs (les industriels fabricants de cartes à puces et autres produits de sécurité) et quelques universitaires se donnent à fond pour proposer des solutions sécurisées.

Du côté des industriels, c'est les contraintes classiques de l'ingénierie : on veut aller vite et on y va par essais-erreurs, jusqu'à ce qu'on arrive plus à attaquer, puis on brevette et on vend, même si on comprend pas pourquoi ça marche…

Et alors pour aller comprendre ce qui est raconté dans les brevets parfois je vous jure… Les articles de recherche académique c'est limpide à côté :D.

Et donc là dessus, j'ai introduit bêtement la notion de "conditions de succès d'attaque". Pas de surprise pour notre attaque BellCoRe la condition c'était que le PGCD dont je parlais plus haut soit égal à p ou q, tout simplement.

Sauf que cette idée bête m'a permis de développer un outil, finja (pablo.rauzy.name/sensi/finja.ht…) qui m'a dans un premier temps permis de prouver l'efficacité de certaines contre-mesures.

La stratégie de finja est de modéliser le calcul symboliquement, c'est à dire que plutôt que de donner des valeurs aux variables, je leur donne des propriétés "p est premier", "q est premier", "N est multiple de p et de q", etc.

Ça me permet ensuite de calculer (toujours symboliquement) les propriétés arithmétiques du résultat du calcul.
Et ça, je peux le faire aussi en simulant des injections de fautes ! :)

Par exemple si j'ai "a = b × c", je sais que a est multiple de b et de c, mais si je décide d'injecter une faute sur c, alors :
– soit c'est une faute à zéro et la nouvelle propriété de a est d'être nul,
– soit c'est une faute aléatoire et a n'est plus qu'un multiple de b.

En donnant à mon outil tous les axiomes des groupes / anneaux / corps (c'est à dire des propriétés arithmétiques comme celle que je viens de donner en exemple) + quelques théorèmes trop poilus pour être retrouvé tout seul par l'outil, je pouvais vérifier les contre-mesures !

Tout simplement de manière exhaustive (dans un modèle de faute donnée) : je faisais faire à finja les simulations de toutes les fautes possibles et chaque fois vérifier la condition de succès d'attaque.

Cette approche m'a dans un premier temps permis de valider certaines contre-mesures (et oui ! l'approche d'ingénierie bourrine cracra dont je parlais, elle marche en fait, parce que les ingés sont bon·ne·s !).

Ça m'a aussi permis assez rapidement de retrouver des attaques déjà connues sur des contre-mesures cassées, et aussi d'en trouver des nouvelles !

Et maintenant que j'avais un outil pour faire rapidement la vérification d'une contre-mesure, je pouvais assez simplement tester des optimisations de contre-mesures en me servant de finja comme test de non-régression (pour être sûr de pas casser la sécurité).

Ça m'a permis d'optimiser agressivement certaines contre-mesures existantes (beaucoup moins de calculs, et nécessité d'un seul nombre aléatoire à la place de 5, par exemple), et même d'en corriger des cassées !

Dans les labos qui font des attaques, ça commençait à devenir carrément réalistes d'injecter deux fautes bien ciblées dans la durée d'exécution d'un algo de crypto. Et donc je me suis intéressé aux contre-mesures qui disaient protéger contre deux fautes.

Avec finja, c'était trivial de lui demander de mettre plusieurs fautes, ça prenait juste plus de temps parce que y avait vite beaucoup beaucoup plus de combinaison de fautes possibles.

Mais résultat, aucune contre-mesures ne résistaient vraiment à deux fautes… Zut !

Du coup s'est posé la question de comment créer une contre-mesure résistante à plusieurs fautes ?

À son tour, cette question nous a demandé de comprendre ce qui fait effectivement marcher une contre-mesure… Donc la je me les suis toutes tapé. J'ai tout rangé selon des tas de critères ± pertinents, pour trouver leurs points communs.

Résultats des courses : j'ai compris, mais quel choc. Contrairement à ce qu'on pensait (ce "on" inclut les concepteurs de contre-mesures), les contre-mesures ne font pas des calculs alambiqués pour vérifier que l'attaque BellCoRe ne marchera pas, >>

>> elles font quelque chose de simple (une extension modulaire) pour vérifier l'intégrité du calcul.

Ça me parait ahurissant aujourd'hui de raconter ça. Ça semble absurde que ça se soit passé comme ça, mais que voulez vous, on va pas réécrire l'histoire ^^'.

Au final, on se retrouver quand même avec un tas de contre-mesures brevetées qui font en fait toutes la même chose à petite optimisation prêt :D. #Oups

Mais surtout, ces contre-mesures ne protège pas que de BellCoRe (l'attaque sur RSA que j'ai décrite plus haut) mais de toutes les attaques, puisque ce qui est vérifié c'est l'intégrité du calcul : à la moindre faute, même inoffensive pour BellCoRe on arrête tout.

Et comme la méthode pour faire ça était en fait chaque fois le même bête petit truc d'arithmétique, je me suis dit qu'on pourrait sûrement utiliser le même pour protéger n'importe quel calcul de ce type, et pas seulement RSA !

À ce moment là je suis parti en stage un mois à l'IMDEA a Madrid pour bosser sur cette idée dans l'équipe de Gilles Barthe, encore une géniale personne super sympa :).

C'était déjà pendant ma troisième année de thèse, et revenu de là bas, j'ai pris un stagiaire de M2 (enfin officiellement c'était un stagiaire mon directeur de thèse), et pendant que je rédigeais, lui il faisait l'implem de cette idée pour des calculs sur courbes elliptiques.

Les courbes elliptiques sont des objets mathématiques sur lesquels on peut faire de la crypto. En gros ça peut jouer un peu le même rôle que les ensembles dont je parlais plus haut pour RSA : c'est le support mathématique, la structure, dans laquelle on fait les calculs.

Autant moi j'étais pas chaud pour me plonger complètement là dedans tout seul, autant Martin, le stagiaire, lui il était chaud bouillant à la sortie de son master de sécurité/crypto. Du coup lui et mon directeur m'ont expliqués les bases, puis on a réfléchit ensemble.

C'était le moment de s'y mettre parce que l'année d'avant à la conf principale sur les attaques par fautes, il y avait 3 ou 4 papiers avec des attaques sur la crypto sur courbes elliptiques, mais pas de contre-mesures.

Une fois le code pondu, on a étudié théoriquement la taux de non-détection d'une attaque en fonction de la taille d'un paramètre de sécurité, puis on a fait la vérification expérimentale (le retour de Zak !).

Le jeu est de faire une campagne d'attaque par injections de fautes pour mesurer le taux de détection des attaques. Mais pour mesurer ça il faut être sûr de ne compter que les fois où l'injection à bien réussie, sinon on améliore virtuellement notre score !

Là aussi c'est rigolo : le soir la température baisse, faut refaire les réglages pour réussir à injecter des fautes. Le midi quelqu'un utilise un micro-onde à l'étage en dessous, faut refaire les réglages, … :D.

Mais on finit par avoir assez de mesures correctes, et les résultats correspondent à ce qu'on attendait, on est content !

Ah, j'ai oublié de vous dire qu'avant le stage à Madrid j'avais bien réussi à trouver un moyen de générer des contre-mesures résistantes à un nombre arbitraire (mais fixé à l'avance) de faute.

(C'est pas mon genre d'oublier de me la péter :-p, ça veut dire que je fatigue, mais ça tombe bien, c'est à peu près là que ma thèse se fini :D).

Je ne pouvais juste pas parler de ma thèse sans mentionner mon pot de thèse après la soutenance. J'ai mis tous les mois de côté pendant 3 ans pour faire un méga fat pot de thèse :D.

On a passé les deux jours d'avant ma soutenance à faire de la cuisine à fond avec des potes. C'était la folie. Rien que pour le pot et l'autorisation légale de porter des pulls en laine moches, ça vaut le coup de faire une thèse ^_^.

Au menu y avait pleeeeein de trucs végétariens en quantités astronomiques (houmous, tzatziki, aïoli, crêpes avec billig sur place, fondues de divers légumes, plateaux de fromages géants) + un barbecue open magret de canard.

Et tout ça bien bien arrosé, of course. Y avait encore quelques restes après le repas de midi à ~70 personnes + l'aprem prolongé en soirée (avec moins de gens quand même). #souvenir
(D'ailleurs j'ai faim, je vais pas tarder à bouger de la fac !).

J'ai retrouvé du livetweet :D

External Tweet loading...
If nothing shows, it may have been deleted
by @SevanEtAurelien view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @SevanEtAurelien view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @SevanEtAurelien view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @SevanEtAurelien view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @aaz19 view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @SevanEtAurelien view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @aaz19 view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @aaz19 view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @aaz19 view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @aaz19 view original on Twitter

External Tweet loading...
If nothing shows, it may have been deleted
by @aaz19 view original on Twitter