Support matériel, logiciel et cryptographique pour une exécution sécurisée de processus

Support matériel, logiciel et cryptographique pour une exécution sécurisée de processus Journée des doctorants en architecture et compilation 29 septembre 2004 Guillaume Duc <guillaume.duc@enst-bretagne.fr> Guillaume Duc <guillaume.duc@enst-bretagne.fr> 1

Plan Introduction Confidentialité Intégrité Conclusion Guillaume Duc <guillaume.duc@enst-bretagne.fr> 2

Introduction Problématique : Sécurité Informatique Nombreuses solutions au niveau logiciel : Protocoles (IPsec, Kerberos...) Algorithmes (cryptographie...) Applications (DRM...) Mais support matériel d'exécution non sécurisé Attaques matérielles : contre les bus, la mémoire ou même le processeur... Attaques logicielle : OS compromis ou admin Guillaume Duc <guillaume.duc@enst-bretagne.fr> 3

Introduction Objectif de la thèse : Concevoir une plateforme informatique sécurisée résistant à des attaques aussi bien logicielles que matérielles. Travaux précédents : Architecture CryptoPage (Ronan Keryell et Cédric Lauradoux [1,2]) Stage de DEA (mars-juin 2004 [3]) Guillaume Duc <guillaume.duc@enst-bretagne.fr> 4

Introduction Notion de processus sécurisé : Intégrité : Si le processus se termine correctement, le résultat de ce dernier est fiable (non altération du code ou des données avant et pendant son exécution) Confidentialité : Un attaquant doit pouvoir récupérer le moins d'informations possible (code, données, etc.) sur le processus Tout ce qui est à l'extérieur du processeur est considéré comme non sûr Guillaume Duc <guillaume.duc@enst-bretagne.fr> 5

Architecture CryptoPage Guillaume Duc <guillaume.duc@enst-bretagne.fr> 6

Confidentialité Chiffrement des instructions et des données d'un processus Chiffrement d'une ligne de cache lors de son écriture en mémoire et déchiffrement lors de sa lecture depuis la mémoire Deux clés symétriques (données et instructions) par processus. Elles sont stockées dans un descripteur matériel chiffré à l'aide de la clé publique du processeur Guillaume Duc <guillaume.duc@enst-bretagne.fr> 8

Exécution d'un processus chiffré Moments cruciaux : Chargement du processus Changements de contexte (Interruption / Retour d'interruption) Exemples sur une architecture Intel x86 Guillaume Duc <guillaume.duc@enst-bretagne.fr> 9

Initialisation d'un processus Contexte matériel chiffré avec la clé publique du processeur contenant : les clés du processus (données + instructions) l'adresse de la première instruction chiffrée Code de bootstrap non chiffré lançant l'instruction spéciale de chargement du contexte chiffré Code de bootstrap chiffré (chiffrement de la pile, initialisation de la zone bss à zéro, etc.) Guillaume Duc <guillaume.duc@enst-bretagne.fr> 10

Interruptions Modifications à apporter à la procédure d'interruption classique : Invalidation du cache (optimisation possible) Sauvegarde du contexte matériel signé et chiffré en mémoire (optimisation : effectuer cette opération uniquement en cas de besoin et sinon le laisser dans une zone tampon) Effacement des registres et sauvegarde de valeurs quelconques pour ss, esp, eflags, cs et eip dans la pile Guillaume Duc <guillaume.duc@enst-bretagne.fr> 11

Retour d'interruption Si réactivation d'un processus chiffré : Déchiffrement et vérification du contexte matériel situé dans la pile ou dans la zone tampon du processeur Restauration du contexte matériel complet sans tenir compte des valeurs des quelques registres stockés en pile lors de l'interruption (ss, esp, eflags, cs et eip) Guillaume Duc <guillaume.duc@enst-bretagne.fr> 12

Problèmes Appels systèmes Arguments et valeur de retour stockés dans les registres du processeur Solution : Laisser la responsabilité de l'effacement des registres au programmeur (ou à la libc) en cas d'interruption logicielle Signaux Nécessité de modifier le contexte matériel Solution : Le programme fourni lui même les contextes matériels pour les signaux voulus Guillaume Duc <guillaume.duc@enst-bretagne.fr> 13

Intégrité de la mémoire Garantir l'intégrité des données stockées en mémoire : la valeur lue à une adresse en mémoire doit être identique à celle écrite en dernier à cette même adresse par le processeur La lutte contre le rejeu implique une vérification globale de la mémoire Solution actuelle : hachage global hiérarchique de la mémoire à l'aide d'arbres de Merkle Guillaume Duc <guillaume.duc@enst-bretagne.fr> 15

Intégrité de la mémoire Arbres de Merkle Chaque nœud contient un résumé cryptographique du contenu de ses fils Racine de l'arbre stockée en mémoire sécurisée dans le processeur Algorithmes de lecture et d'écriture (optimisés en utilisant le cache) f(y1,y2) y1=f(x1,x2) y2=f(x3,x4) x1 x2 x3 x4 Guillaume Duc <guillaume.duc@enst-bretagne.fr> 16

Conclusion Applications possibles : Grilles de calcul DRM Vote en ligne Résultats actuels : Implémentation de la partie confidentialité dans le modèle de processeur de Bochs (simulateur de PC libre) Une version du noyau Linux spécialisée faisant tourner des processus chiffrés Guillaume Duc <guillaume.duc@enst-bretagne.fr> 18

CryptoPage : Références [1] Ronan Keryell. CryptoPage 1 : vers la fin du piratage informatique? In Symposium d'architecture (SympA'6), pages 35-44, Juin 2000. [2] Cédric Lauradoux et Ronan Keryell. CryptoPage-2 : un processeur sécurisé contre le rejeu. In Symposium en Architecture et Adéquation Algorithmique et Architecture (SympAAA'2003), pages 314-321, Octobre 2003. [3] Guillaume Duc. CryptoPage: An architecture to run secure processes. Rapport de DEA. Juin 2004. http://www.lit.enstb.org/~gduc/dea Autres : [4] G. Edward Suh, Dwaine Clarke, Blaise Gassend, Marten van Dijk, and Srinivas Devadas. AEGIS: Architecture for Tamper-Evident and Tamper- Resistant Processing. In Proceedings of the 17th Annual ACM International Conference on Supercomputing, Mars 2003. http://www.mit.edu/people/gassend/publications/aegis.pdf Guillaume Duc <guillaume.duc@enst-bretagne.fr> 19

Des questions? Guillaume Duc <guillaume.duc@enst-bretagne.fr> 20