On a une fuite d'information, c'est cela qu'on va utiliser pour patcher le programme. On autorise ou pas la duplucation de secrets?

 

Est-ce qu'on peut faire confiance au compilateur?
On est obligé, on les utilise tous... Que pourrait-il nous donner comme garanties?

La préservation sémantique
Si le comportement est déterministe: même comportement de la cible et du source.
Mais sans optimisation, puis optimisations, le programme ne marche plus: bug dans le compilateur?

 

Si mon compilateur n'a pas de bug (LLVM) et si mon programme n'a pas de comportement indéfini, dans ce cas là, j'ai ma correction fonctionnelle, et si le source est correct, la cible sera correcte.

Niveau sécurité du cible?

On peut utiliser le compilateur pour augmenter la sécurité. MAIS ça peut casser les contre mesures. Exemple, lorsque l'on sécurise un compte crypto, il ne faut pas avoir de branches, autrement le code crypto est cassé. Techniques du masking: executer sur du code crypté et rajouter des XOR, avec un secret. Si le compilateur est assez malin pour utiliser les propriétés du XOR, il va pouvoir sécuriser.

Benjamin Gregoire, à Sofia, s'est rendu compte que GCC retirait ces propritétés du masking.

Certains cryptographes ne font pas confiance au compilateur et écrivent en très bas niveau, assembleur, pour être sûr que le programme s'execute bien et que le résultat est là.

Donc, à long terme, on voudrait un compilateur sécurisé.

Je définsi un modèle d'attaquant: s'il s'interesse à la cible, qu'il n'ait pas un avantage niveau source.

En terme de recherche, on définit différentes classes d'attaquants.

Effacer les données sensibles? Ne pas les laisser en mémoire

On fait un XOR et on efface la clé ensuite. Le compilateur considère que c'est du code mort et il le retire.

Dupliquer les informations sensibles n'est pas recommandé. Quand il n'y a plus assez de registres, il y a réplication.

Pour continuer à formaliser ce que connait l'attaquant dans la mémoire initiale, au fur et à mesure de l'execution?

Plus l'information est grosse, moins on connait de choses, moins on a d'informations sur ce qui s'est passé sur l'execution.

Petite technique de la thèse: la formule! A expliquer :)

Montrer qu'une transformation es tsure.

Soruce: CP1, cible CP2. On quantifie sur toutes les mémoires initiales.

A partir de 2 traces, on mappe les informations du cible vers l'information du source, via la fonction omega.

Impact de la transformation sur l'organisation de la mémoire

Dès qu'on a une mémoire rouge, la fonction explique comment relier les mémoires. Le registre machin correspond à la variable truc

 

 

Structure de l'algorithme: on prend le source, on execute un validateur, on regarde ce qui arrive à la sortie, et si le programme est rejeté, on peut analyser le résultat et patcher en rajoutant des instructions pour effacer les secrets qui seraient toujours en mémoire.

Les 2 premiers travaux étaient capables de montrer que si un programme avait une petite fuite, à la compilation il pouvait y avoir une grosse fuite. "Preservation of side-channel" de Barthe et al en 2018 Le futur: il faut améliorer la performance du patching. On a cette notion de propriété, on a décidé de mettre des points en début de fonction. On pourrait se demander, mais votre modèle d'attaquant n'est pas très représentatif: si on attaque votre device, on va tout récupérer. Hamming Weight model: est-ce qu'on peut écrire un compilateur qui préserve la sécurité dans ce modele là? This email address is being protected from spambots. You need JavaScript enabled to view it.

  

Cet article reflète exclusivement l'opinion de ses auteurs et n’engage en aucune façon Consultingit. J'espère que ça vous a plu. Vos commentaires/remarques sont les bienvenus: