Objectif:
L'objectif de ce WP est triple. Tout d'abord, les contre-mesures de pointe déjà connues seront évaluées à l'aide des modèles et des outils développés dans les autres tâches (par exemple, le flot de simulation du WP4). Le deuxième objectif de ce WP est de proposer et d'évaluer des solutions architecturales et/ou des règles de conception, plutôt que des solutions basées sur l'inclusion de capteurs dans la puce, afin d'augmenter la robustesse des circuits face aux nouvelles menaces identifiées au sein du projet. Cette tâche s'appuiera sur les résultats des WP 1 et 2 (attaques) et interagira strictement avec le WP 4 (modèles et simulation).
Tâche 3.1 : Evaluation des contre-mesures existantes
L'objectif principal est d'évaluer l'efficacité des modèles et outils développés dans les autres tâches. Pour cela, les principales contre-mesures contre l'injection de fautes existant dans la littérature seront passées en revue et décrites (livrable D3.1); ensuite, un ensemble de contre-mesures de pointe sera sélectionné et évalué sur des exemples pratiques. Les résultats obtenus par simulation seront corrélés avec les résultats expérimentaux obtenus dans les WP 1 et 2. Ce travail vise à démontrer la validité de modèles proposés, et également à évaluer l'efficacité des contre-mesures connues dans le nouveau contexte des injections RX.
Tâche 3.2 : Définition, étude et développement de contre-mesures matérielles ad-hoc
Ces contre-mesures viseront à atteindre des protections à la fois contre les injections de fautes de type RX selon le modèle défini à la tâche 4.1, mais surtout d'avoir une vision plus englobante de la sécurité et de la sûreté. Il s'agit en effet d'éviter d'empiler de nouvelles contre-mesures sur celles déjà existantes. Nous essaierons dans cette optique d'adresser conjointement les fautes et les fuites de type side-channel dans le pipeline d'un CPU. L'association aux données et/ou aux instructions de tag d'intégrité couplé à du masquage est une voie prometteuse qui sera étudiée. Les signaux de contrôle en sortie de l'étage Decode peuvent également être aussi intégrés en redondance des instructions dès la compilation pour une vérification au runtime. Ceci ouvre la voie à des approches conjointes logicielles et matérielles.
Tâche 3.3 : Validation contre-mesures matérielles par méthodes de simulation
Une série de solutions sera proposée et validée, par simulation et/ou par des expériences sur des systèmes réels. La validation sera effectuée à l'aide des outils développés dans la tâche 4.2 et avec une forte interaction avec la tâche 4.4. Des cas d'étude seront étudiés, comme par exemple des blocs fonctionnels de primitives cryptographiques (AES S-Box) ou mémoires. Les résultats permettront aussi de reboucler sur le cycle de conception afin d'adapter et optimiser les solutions proposées.
Tâche 3.4 : Définition, étude et développement de contre-mesures ad-hoc de type logiciel
Dans le cas où des contre-mesures matérielles ne soient pas envisageables (par exemple, solution legacy déjà existante), il est important de pouvoir également assurer un niveau de protection suffisant. Pour cela, des contre-mesures du type logiciel seront évaluées : parmi les solutions qui seront prises en compte, nous allons considérer la redondance temporelle et/ou d'information, techniques déjà connues dans le domaine. D'autres solutions plus avancées pourront aussi être analysées au niveau applicatif embarqué, dans le cas de code exécuté sur architectures simples.