Compilation pour la sécurité matérielle : au-delà de la sémantique

Compilation beyond semantics for hardware security

• Auteur / Autrice : Sébastien Michelland
• Direction : Laure Gonnord
• Type : Projet de thèse
• Discipline(s) : Informatique
• Date : Inscription en doctorat le ; Soutenance le 24/10/2025
• Etablissement(s) : Université Grenoble Alpes
• Ecole(s) doctorale(s) : École doctorale mathématiques, sciences et technologies de l'information, informatique
• Partenaire(s) de recherche : Laboratoire : Laboratoire de conception et d'intégration des systèmes
• Partenaire(s) de recherche : Equipe de recherche : CTSYS
• Jury : Président / Présidente : Isabelle Puaut
• Jury : Examinateurs / Examinatrices : Laure Gonnord, Karine Heydemann, Jens Gustedt, Marie-laure Potet, Albert Cohen, Daniel Gruss
• Jury : Rapporteurs / Rapporteuses : Karine Heydemann, Jens Gustedt

Mots clés

Mots clés libres

Llvm

Propriétés de sécurité

Compilation sécurisée

Injection de fautes

Analyse statique

Llvm

Security properties

Secure compilation

Fault injection

Static analysis

Résumé

Les systèmes informatiques sont construits par couches pour limiter leur complexité. Par exemple, le logiciel et le matériel sont principalement indépendants l'un de l'autre et communiquent via une interface très contrôlée, un type de langage de programmation appelé assembleur. Une fois accordés sur l'assembleur, le logiciel et le matériel peuvent chacun ignorer, ou s'abstraire, des détails internes de l'autre. Cette construction est omniprésente en informatique ; il y a probablement une dizaine de telles couches d'abstraction entre le logiciel utilisé pour visualiser ce document et les lois fondamentales de la physique. Une limitation de ce système est que les interfaces entre les couches n'isolent que les fonctionnalités. Pour tous les autres aspects, comme la performance ou la sécurité, on est obligés de considérer le système dans toute sa complexité. Par exemple, les attaques par injection de faute produisent des comportements anormaux dans le matériel en interférant volontairement avec le circuit (signaux, alimentation, émissions électromagnétiques, etc.—tous les coups sont permis). Le langage assembleur n'a pas de mécanisme pour abstraire les fautes au niveau logiciel ; par conséquent, pour construire une protection logicielle il ne suffit plus de comprendre le langage assembleur, il faut comprendre l'effet des fautes sur tous les détails internes du matériel, une tâche hautement plus complexe. Ce problème se pose aussi à l'intérieur du logiciel. Les applications sont généralement codées dans un langage haut-niveau comme le C, et un compilateur se charge de produire un programme assembleur équivalent. Il est connu que ce processus de compilation peut détruire les protections. Par exemple, pour sécuriser on peut refaire les calculs sensibles en double pour vérifier qu'il n'y a pas eu d'erreur causée par une faute. Le compilateur, ignorant de la menace de sécurité, supprime le doublon, jugé inutile, pour optimiser les performances du programme. Pour produire un programme assembleur satisfaisant, les programmeurs sont donc forcés de comprendre les détails du compilateur. Cette tâche également complexe est fréquemment esquivée en désactivant les optimisations, une solution inélégante mais généralement efficace. L'argument central de cette thèse est que la complexité du compilateur cache d'autres menaces que juste les optimisations. En effet, la compilation se fait en plusieurs étapes dans lesquelles le programme est réécrit dans multiples langages intermédiaires, ce qui représente une descente à travers plusieurs couches d'abstraction logicielles. Contrairement aux optimisations, cette descente n'est pas optionnelle, et présente des menaces subtiles que les programmeurs doivent pouvoir anticiper. Ainsi, cette thèse s'intéresse à la relation entre les contremesures de sécurité contre les attaques matérielles (principalement les attaques en faute) et le processus de descente en abstraction durant la compilation. J'y caractérise les mécanismes de compilation qui menacent les contremesures et démontre qu'ils sont profondément incrustés dans le fonctionnement du compilateur. Je propose ensuite divers outils pour y remédier, notamment une méthode de « tracé » (nouveau dans cette thèse) pour maintenir des liens entre les programmes source et intermédiaires utiles à l'insertion des contremesures. La production centrale de la thèse est Tracing LLVM, une surcouche open-source légère pour LLVM (un compilateur de production) qui enrichit l'interface entre le code et le compilateur pour faciliter l'implémentation de contremesures de sécurité. Tracing LLVM élimine un certain nombre de problèmes courants liés aux optimisations et fournit au programmeur davantage de contrôle sur la compilation pour faciliter l'insertion et la préservation des contremesures. Cela constitue une étape importante dans le développement de compilateurs attentifs à la sécurité et la consolidation des défenses contre les attaques matérielles.

Computer systems are built in layers to contain their complexity. For instance, software and hardware are mostly independent from each other; they communicate only through a tightly controlled interface, a kind of programming language called assembler. Once they agree on assembler, software and hardware can ignore, or abstract away, each other's internal details. This structure is ubiquitous in computer science; there is probably a dozen such abstraction layers between the program used to visualize this document and the fundamental laws of physics. One limitation of this system is that the interfaces between layers only isolate functionality. For every other aspect, such as performance or security, one has to consider the system in all its glorious complexity. For instance, fault injection attacks induce abnormal behaviors in hardware by purposefully interfering with the circuit (signals, power, electromagnetic emissions, etc.—anything goes). The assembler language has no mechanisms for abstracting faults to the software level; as a result, designing a software countermeasures requires understanding not just of assembler but of the effects of faults on all of the hardware's internal details, which is significantly more challenging. This problem also arises within software itself. Applications are generally coded in a high-level programming language such as C, and a compiler is used to produce a functionally-equivalent assembler program. It is well understood that this process can destroy security countermeasures. For instance, as a security precaution one might perform sensitive computations twice to check for errors induced by faults. The compiler, unaware of the security threat, will proudly delete the duplicate, which it deems redundant, to improve the program's performance. To produce a satisfying assembler program, programmers must thus understand the compiler's internal details. This task, also complex, is frequently dodged by disabling optimizations, an inelegant but generally effective solution. The central argument of this thesis is that the compiler's complexity hides other threats than optimizations. Indeed, compilation occurs in several steps in which the program is rewritten in multiple intermediate languages, in effect descending through multiple layers of software abstractions. Unlike optimizations, this descent isn't optional, and raises subtle threats that programmers need to anticipate. Thus, this thesis is concerned with the relationship between security countermeasures against hardware attacks (mostly fault injection attacks) and the abstraction descent from the compilation process. I characterize the compiler mechanisms that threaten countermeasures and show that they are deeply embedded in the compiler's design. I then propose multiple tools to remedy these threats, including a ''tracing'' system (new in this thesis) to maintain a connection between the source and intermediate programs that's useful to the insertion of countermeasures. The central production of the thesis is Tracing LLVM, a lightweight open-source extension of LLVM (a widely-used production compiler) which enriches the interface between program and compiler to facilitate the implementation of security countermeasures. Tracing LLVM deals with a number of common optimization-related issues and provides programmers with increased control over compilation to facilitate the insertion and preservation of countermeasures. This is a significant step towards building security-aware compilers and improving the reliability of defense mechanisms against tricky hardware attacks.