Les crypto-processeurs et l informatique de confiance Guillaume Duc Encadrant : Ronan Keryell 19 décembre 2003
Table des matières Introduction 3 1 Les crypto-processeurs 4 1.1 Principes......................................... 4 1.1.1 Architecture classique pour l exécution de programmes chiffrés....... 4 1.1.2 Aegis....................................... 5 1.2 TCG - Trusted Computing Group........................... 6 1.3 Applications........................................ 6 1.3.1 Exécution certifiée................................ 6 1.3.2 Gestion Numérique des Droits......................... 7 2 La vérification mémoire 8 2.1 Les différents types d attaques............................. 8 2.1.1 L injection..................................... 8 2.1.2 La permutation physique............................ 9 2.1.3 Le rejeu...................................... 9 2.2 Les arbres de Merkle................................... 9 2.2.1 Principes..................................... 9 2.2.2 Optimisations................................... 10 2.3 Un vérificateur hors-ligne................................ 10 2.4 Problèmes......................................... 10 3 Les aspects logiciels 11 3.1 La mise en œuvre logiciel Exemple de CryptoPage............... 11 3.2 NGSCB / Palladium................................... 12 3.2.1 Isolation forte des processus........................... 12 3.2.2 Stockage sécurisé................................. 13 3.2.3 Attestation cryptographique........................... 13 3.2.4 Chemins sécurisés vers l utilisateur....................... 13 4 Les simulateurs de machines virtuelles 14 4.1 SimpleScalar....................................... 14 4.2 Bochs........................................... 14 Conclusion 16 Bibliographie 17 2
Introduction Le problème de la sécurité informatique est relativement ancien. De très nombreux protocoles, algorithmes, etc. ont été développés pour augmenter la sécurité dans de nombreux domaines mais tous sont vulnérables à des attaques physique où l attaquant a accès au support d exécution de ces programmes. En effet, quelqu un disposant de connaissances techniques et de moyens appropriés peut par exemple instrumentaliser le bus du processeur et ainsi récupérer d éventuelles données sensibles. De même, un système d exploitation ou un administrateur malveillant peut avoir accès au contenu de la mémoire. Il est donc nécessaire de disposer de fonctions matérielles afin de contrer ce type d attaques. Dans un premier temps réservés aux seules applications sensibles (armée, banques, etc.), les crypto-processeurs commencent à pénétrer le marché des consoles de jeux et des ordinateurs personnels à cause de la très forte augmentation du piratage informatique. En disposant d un environnement matériel sécurisé, on peut concevoir des systèmes anti-copie fiables pour des programmes ou des œuvres numériques, ce qui était auparavant impossible avec des moyens purement logiciels. Nous allons tout d abord étudier les principes de fonctionnement des crypto-processeurs, puis les algorithmes qu ils mettent en œuvre afin de sécuriser les échanges avec la mémoire centrale de l ordinateur, les modifications nécessaires au niveau logiciel (système d exploitation et programmes) afin de pouvoir les utiliser et enfin des outils permettant de simuler leur fonctionnement et de mesurer leurs performances. 3
Chapitre 1 Les crypto-processeurs 1.1 Principes Le principe de base d un crypto-processeur est d intégrer des fonctions de cryptographie (chiffrement, signature numérique, gestion des clés) directement à l intérieur d un microprocesseur classique. Son but est de résister à toute attaque physique ou logicielle, par exemple sur les bus de données et d adresses, sur la mémoire (modification du programme ou de ses données) ou sur le processeur lui-même. Les crypto-processeurs peuvent être séparés en deux grandes catégories : ceux qui permettent l exécution fiable d un programme en clair (le processeur va certifier qu il n y a pas eu d attaque durant l exécution de celui-ci dont le code est en clair) et ceux qui permettent l exécution fiable d un programme chiffré (le code exécutable du programme est chiffré pour un processeur en particulier et un adversaire ne peut pas le déchiffrer ni le copier sur une autre machine). Certains crypto-processeurs comme Aegis [8] permettent l exécution de programmes dans les deux modes. La seconde approche est celle qui a été la plus privilégiée dans le passé et avait pour objectif d empêcher la copie ou l analyse du fonctionnement du programme. Nous allons donc tout d abord voir l architecture classique d un crypto-processeur réalisant cette fonction puis étudier Aegis qui permet également la première approche. Enfin, nous verrons le système proposé par le TCG (Trusted Computing Group). 1.1.1 Architecture classique pour l exécution de programmes chiffrés Chaque crypto-processeur va disposer d une paire de clés (une clé publique et une clé privée) qui lui est propre. Le producteur du logiciel va chiffrer le code exécutable à l aide de la clé publique du processeur afin qu une fois chiffré, il ne puisse être déchiffré qu avec la clé secrète correspondante et donc que par le processeur pour lequel il est destiné. La copie du programme devient donc inutile (sauf pour des raisons de sauvegarde privée) puisqu aucun autre processeur ne pourra le déchiffrer et donc l exécuter. Comme les algorithmes de chiffrement asymétriques sont lents, les crypto-processeurs utilisent des algorithmes mixtes : le producteur génère une clé de session symétrique, chiffre son programme avec cette clé puis chiffre la clé avec la clé publique du processeur. Ce dernier récupère la clé de session à l aide de sa clé privée puis déchiffre le programme. Comme la mémoire interne au processeur est généralement trop faible pour stocker les données du programme, celles-ci sont envoyées en mémoire. La mémoire étant supposée accessible par un adversaire, les données sont chiffrées avec une clé de session spécifique au programme avant d être stockées en mémoire et déchiffrées lors de la lecture. Comme la clé utilisée pour chiffrer les données est différente d un programme à un autre, seul le processus 4
propriétaire des données peut les lire. Il est également nécessaire de mettre en place des algorithmes pour prévenir les modifications du contenu de la mémoire par un adversaire (cf. chapitre 2). Un crypto-processeur va donc gérer en interne une table contenant la liste des processus chiffrés qu il est en train d exécuter avec leur clé de session correspondante. Lors d une interruption, le processeur sauvegarde son état interne comme normalement mais en plus, il le chiffre avec sa clé privée afin que le système d exploitation n y ait pas accès. De plus, il efface les valeurs des registres pour ne pas divulguer d informations sensibles. 1.1.2 Aegis Dans [8] est présenté une architecture pour un crypto-processeur capable d effectuer des opérations résistantes aux attaques et de le prouver. Il fournit deux environnements d exécution pour les programmes : un mode sécurisé non chiffré et un mode sécurisé et chiffré. L environnement d exécution non chiffrée a pour but de garantir l intégrité de l exécution du programme. L environnement d exécution chiffrée apporte en plus la garantie que personne ne peut avoir accès au code exécutable du programme ni à ses données. Le processeur dispose d une clé publique (P K p ) et d une clé privée (SK p ). Aegis n ayant pas besoin d un système d exploitation spécial, il a besoin de garder la trace des processus qui s exécutent en mode sécurisé. Il dispose donc d un gestionnaire de contexte sécurisé (Secure Context Manager, SCM ) implémenté au niveau matériel. Ce SCM maintient une table contenant un certain nombre d informations sur chaque processus qui s exécute en mode sécurisé : un identifiant (SPID), un résumé cryptographique du programme (H(P rog)), des registres (H(Regs)) et un dernier utilisé pour la vérification de la mémoire. Une nouvelle entrée est créée lorsqu un programme exécute l instruction enter tee (pour entrer en mode d exécution sécurisé) et est détruite lors de l appel de exit tee (pour sortir du mode d exécution sécurisé). Cette table peut être stockée dans le processeur mais pour qu elle soit plus extensible, elle peut être stockée en mémoire moyennant un chiffrement et une vérification de son contenu. Lors de l entrée en mode sécurisé, le SCM calcul un résumé cryptographique du programme et de ses données qu il stocke dans sa table afin de permettre ultérieurement de s assurer que le programme n a pas été altéré avant son exécution. Lors d un changement de contexte, le SCM sauvegarde les valeurs des registres du processus en cours dans sa table pour pouvoir ensuite les restaurer. Il empêche également le système d exploitation d avoir accès à ces valeurs. Un programme peut envoyer un message à un utilisateur à l aide de l instruction sign msg qui retourne {H(P rog), M} SKp, c est-à-dire l ensemble message et résumé cryptographique du programme signé avec la clé privée du processeur. Ainsi l utilisateur peut savoir quel processeur exécutant quel programme lui a envoyé le message. Dans le mode chiffré, deux instructions sont ajoutées, set key et store private qui permette respectivement de spécifier avec quelle clé est chiffré le code machine du programme et de sauvegarder une valeur chiffrée en mémoire. Pour partager un secret avec un programme, l utilisateur envoie un message chiffré au processeur E P Kp (H(P rog), M). Pour déchiffrer le message, le programme exécute une instruction particulière qui déchiffre le message avec la clé privée du processeur et renvoie M si et seulement si H(P rog) correspond bien au programme en cours d exécution. Le processeur utilise également des algorithmes de vérification mémoire (cf. chapitre 2) afin de s assurer que la mémoire externe se comporte normalement. 5
1.2 TCG - Trusted Computing Group Le Trusted Computing Group, formé de grandes entreprises du monde de l informatique, a également réfléchi sur comment obtenir une informatique de confiance, c est-à-dire comment garantir qu un programme va s exécuter de façon fiable en dépit des attaques, un peu à la manière du mode sécurisé mais non chiffré de Aegis. Les spécifications [9] de cette plate-forme de confiance sont basées sur une puce (baptisée TPM Trusted Platform Module), indépendante du processeur, résistante à l investigation et qui est chargée d un certain nombre de fonctions. Tout d abord, cette puce contient une paire de clé publique/privée qui lui est propre et qui est signée par son fabriquant. Elles lui permettent de prouver son identité et d assurer des fonctions cryptographiques de base. Lors du démarrage, cette puce va collecter des données sur l état de la machine et va calculer un résumé cryptographique des programmes utilisés lors de la séquence de démarrage (BIOS, boot-loader, etc.). La puce utilisera ensuite ces informations afin de déterminer si la machine a bien été démarrée dans un état jugé digne de confiance. Cette méthode de vérification du démarrage est basé sur [10]. Elle offre aussi la possibilité à une application de chiffrer des messages qui ne pourront être déchiffrés que dans une configuration matérielle et logicielle particulière. Par exemple, un programme peut demander à cette puce de chiffrer des informations qui ne pourront être déchiffrées que dans la configuration actuelle. Tout changement de système d exploitation ou autre rendra les données indéchiffrables. La spécification décrit un certain nombre d autres fonctionnalités. Cependant, [11] fait remarquer que le TPM n a pas été conçu pour résister à des attaques matérielles, les participants au TCG ayant jugé que celles-ci sont hors de portée de particuliers. Par contre, la compromission d un module TPM est limitée et n affecte pas les autres modules vendus. Cette architecture en elle-même n est pas très utile. Associée à un système d exploitation ad-hoc (par exemple Palladium, cf. section 3.2) elle permet une informatique de confiance mais peut avoir de très nombreux effets pervers sur la libre concurrence dans ce domaine (cf. [12]). 1.3 Applications Nous allons maintenant voir quelques applications qui peuvent bénéficier de l utilisation de crypto-processeurs. 1.3.1 Exécution certifiée L exécution certifiée consiste à s assurer qu un programme s est exécuté sur une machine sans modification extérieure du programme en lui-même, de ses résultats, ou de ses états intermédiaires. Cette propriété est importante par exemple dans les grilles de calcul. Les applications actuelles qui utilisent la puissance inutilisée de milliers d ordinateurs connectés à Internet, comme SETI@home 1 ou distributed.net 2, n ont aucun moyen de s assurer que les résultats reçus n ont pas été altérés d une façon ou d une autre. Elles sont donc obligées d effectuer les calculs de façon redondante afin de tenter de détecter les résultats anormaux, ce qui entraîne une perte d efficacité et n est pas totalement fiable (par exemple si le nombre de noeuds byzantins est important). [8] présente comment il est possible d utiliser le crypto-processeur Aegis afin de répondre à ce problème. Le concepteur de l application calcule un résumé cryptographique de son programme et le distribue aux différents noeuds. Le programme rentre en mode d exécution 1 http://setiathome.ssl.berkeley.edu 2 http://www.distributed.net 6
sécurisé dans Aegis 3 qui calcule alors le résumé cryptographique du programme. Il s exécute et produit un résultat qui est alors concaténé avec le résumé cryptographique du programme et signé par le crypto-processeur. Ce dernier retourne ce résultat signé avec un certificat numérique de son fabriquant certifiant la clé publique du processeur. L application qui centralise les résultats récupère le tout, vérifie la signature numérique et le résumé cryptographique du programme avant d accepter le résultat. À l aide de la signature numérique, elle sait quel processeur a exécuté le programme. Avec le résumé cryptographique, elle est assurée que le programme et ses données initiales n ont pas été altérés avant l exécution, et comme le programme s exécute en mode sécurisé dans le processeur, elle sait que ce dernier ni ses données n ont été modifiés pendant l exécution. Ainsi au lieu de devoir faire confiance à tous les participants de la grille, le concepteur de l application n a plus qu à faire confiance qu au fabriquant des crypto-processeurs. 1.3.2 Gestion Numérique des Droits La gestion des droits (Digital Rights Management, DRM ) est un sujet d actualité. Il s agit de limiter ce qu un utilisateur peut faire avec une œuvre numérique (musique, film, etc.). Par exemple, celui-ci peut ne pas être autorisé à copier l œuvre en question, peut n être autorisé qu à regarder une seule fois l œuvre, etc. Afin de permettre ces différentes politiques, le contenu de l œuvre est chiffrée et un lecteur particulier tente de faire respecter les droits qui sont associés avec celle-ci. Malheureusement, cette technique est vulnérable à une personne mal intentionnée qui utiliserait des outils de déverminage, voire même des attaques de plus bas niveau (comme l interception des données transitant par le bus de l ordinateur) pour récupérer la version non chiffrée de l œuvre et qui pourrait ainsi la recopier sans contraintes. Dans [8] est décrit une architecture permettant d imposer le DRM à l aide du cryptoprocesseur Aegis. Ils envisagent le cas où l utilisateur n a le droit de lire l œuvre qu une seule fois. Le concepteur du programme de lecture distribue celui-ci, qui fonctionne en mode sécurisé dans le processeur. Le programme demande à l utilisateur de choisir une œuvre particulière. Il envoie alors un message au fournisseur de contenu avec le choix de l utilisateur, une donnée aléatoire, le tout étant signé par le processeur afin que le fournisseur puisse vérifier son intégrité ainsi que celle du programme de lecture. Il chiffre alors l œuvre et la donnée aléatoire avec une clé aléatoire qu il chiffre avec la clé publique du processeur. Le crypto-processeur déchiffre alors la clé de session utilisée. Le programme vérifie la donnée aléatoire afin d empêcher un adversaire de rejouer un message, déchiffre le contenu de l œuvre et la joue. Cependant, malgré ces précautions, le contenu de l œuvre est encore vulnérable lorsqu il transite sur des canaux analogiques. Un adversaire peut très bien reconvertir le signal analogique en signal numérique, moyennant certes une perte de qualité. 3 Avec l instruction enter tee 7
Chapitre 2 La vérification mémoire 2.1 Les différents types d attaques Lors de l utilisation de crypto-processeurs, on suppose que le comportement de tout ce qui est à l extérieur de celui-ci peut être entièrement sous le contrôle d un adversaire. Cette hypothèse est en particulier vraie pour un composant important : la mémoire. Pour que l exécution d un programme par le crypto-processeur soit correcte, il est nécessaire que ce dernier détecte tout comportement anormal de la mémoire où est stockée le programme et les données temporaires qu il manipule. Le crypto-processeur doit s assurer que la valeur qu il lit à une adresse mémoire particulière est la valeur la plus récente qu il a stockée à cette adresse. La mémoire peut faire l objet de trois type d attaques : l injection ; la permutation physique ; le rejeu. Les crypto-processeurs doivent mettre en place des algorithmes afin de détecter ces attaques et de ne pas révéler de données sensibles. Nous allons voir quelques uns de ces algorithmes. 2.1.1 L injection Dans ce type d attaque, l adversaire génère une valeur et essaye de la faire passer pour une donnée valide. Il peut aussi bien affecter le code que les données du programme. Si le crypto-processeur accepte sans vérifier ces données, il peut révéler des informations sensibles. C est à l aide d une attaque ressemblant à celle-ci que le DS5002FP (de Dallas Semiconductor) a été cassé [15]. La solution couramment adoptée est d utiliser un Message Authentication Code (MAC) (par exemple dans [3, 1]). Un MAC est une fonction de hachage cryptographique utilisant une clé. En possédant la clé, il est facile de recalculer le résumé cryptographique pour vérifier l authenticité de la valeur lue mais il est difficile de trouver une autre valeur produisant le même résumé. La clé est utilisée pour empêcher l adversaire d utiliser cette fonction pour générer un résumé correct pour la valeur qu il essaie d injecter. Lorsque le crypto-processeur sauvegarde une valeur en mémoire, il calcule le MAC correspondant à celle-ci qu il stocke également en mémoire. Lorsqu il lit une valeur, il lit également le MAC correspondant et le vérifie. Si le MAC n est pas identique, la valeur en mémoire a été modifiée et donc le crypto-processeur doit s arrêter. 8
2.1.2 La permutation physique Dans ce type d attaque, l adversaire prend une valeur valide (c est-à-dire la valeur et le MAC calculé par le crypto-processeur) et l enregistre à un autre endroit de la mémoire. Lorsque le crypto-processeur essaye d accéder à cette adresse, il lit la valeur et vérifie le MAC et ne détecte aucune erreur car le MAC correspond bien à la valeur lue. Ici aussi, une solution largement répandue consiste à utiliser, pour générer le MAC, une fonction qui dépend de l adresse mémoire de la valeur à stocker. Ainsi, lorsque le processeur va lire la valeur permutée, il va détecter que le MAC ne correspond pas puisque celui-ci aura été calculé pour une autre adresse mémoire. 2.1.3 Le rejeu Le rejeu consiste à remplacer la valeur située à une adresse mémoire par une valeur que cette adresse a déjà prise dans le passé. Comme la valeur remplaçante a été prise à la même adresse mémoire, les deux protections vues précédemment sont inefficaces. la grande majorité des crypto-processeurs est vulnérable à cette attaque, comme par exemple CryptoPage 1 ([1]). Voici un exemple d utilisation de ce type d attaque. Si le programme contient par exemple : for(i=0; i < TAILLE; i++) affiche(*p++); et si l adversaire arrive à localiser l adresse de i et qu il rejoue toujours une même valeur, le programme est amené à afficher des données potentiellement confidentielles. Pour contrer ce type d attaque, on doit disposer d un vérificateur global de la mémoire. Deux types de vérificateurs ont été développés : les vérificateurs hors-ligne et les vérificateur en-ligne. Un vérificateur hors-ligne permet de vérifier régulièrement l intégrité de la mémoire mais il reste des risques de piratage entre les passages du vérificateur. On peut néanmoins l utiliser dans des portions de codes qui, si jamais la mémoire est corrompue, ne risquent pas de révéler de informations sensibles et appeler la fonction de vérification quand des données doivent être transmises à l utilisateur pour voir si les calculs précédents n ont pas été affectés par une modification de la mémoire. Les vérificateurs en-ligne vérifient la mémoire à chaque accès à celle-ci. Ils sont donc sûrs (ils détectent les attaques avant qu une valeur puisse être utilisée) mais ils sont nécessairement plus lents car ils ajoutent un surcoût à chaque accès mémoire. Nous allons voir dans les sections suivantes plusieurs vérificateurs mémoire utilisés dans différents crypto-processeur afin de contrer les attaques par rejeu. 2.2 Les arbres de Merkle [5, 4] proposent d utiliser des variantes des arbres de Merkle afin d effectuer des vérifications sur les mémoires. Cette technique est utilisée par exemple dans CryptoPage-2 [2]. 2.2.1 Principes Les feuilles de l arbre sont constituées des données à protéger et les noeuds contiennent un résumé cryptographique des noeuds ou des feuilles situées en dessous d eux. Le résumé cryptographique de la racine de l arbre est stocké dans une mémoire sécurisée, par exemple à l intérieur même du crypto-processeur. Pour vérifier qu une feuille ou un noeud n a pas été altéré, on compare son résumé avec celui stocké dans le noeud parent et on vérifie que ce dernier n a pas été altéré. On répète 9
l opération jusqu à arriver au résumé du noeud racine stocké dans la mémoire inaltérable. Pour écrire une valeur en mémoire, on doit mettre à jour tous les noeuds au dessus de la modification jusqu au résumé racine. 2.2.2 Optimisations Dans [6] est décrit une méthode pour optimiser les algorithmes de lecture et d écriture vérifiées en utilisant le cache du crypto-processeur. L idée est que si le contenu d un noeud ancêtre est stocké dans le cache, supposé résistant aux attaques, il n est alors pas nécessaire de parcourir toute une branche et de remonter au noeud racine car on peut s arrêter à ce noeud contenu en cache puisque la branche située entre ce noeud et le noeud racine aura déjà été vérifiée lors du chargement dans le cache. Avec cette optimisation, la pénalité au niveau des performances est d environ 20% et 12,5 à 25% de la mémoire externe est utilisée pour le stockage des noeuds de l arbre. 2.3 Un vérificateur hors-ligne [7] présente un vérificateur de mémoire hors-ligne. Il est basé sur des fonctions de hachage incrémentales. Lors d un accès mémoire (en lecture ou en écriture), il met à jour un résumé cryptographique stocké dans une mémoire sécurisée. Lorsque le processeur à besoin de vérifier que les données qu il a utilisé jusqu à présent n ont pas été altérées, il appel une fonction du vérificateur qui va lire le contenu entier de la mémoire et vérifier à l aide du résumé l intégrité de la mémoire. Avec un vérificateur hors-ligne, il est important que le crypto-processeur appelle la fonction de vérification dès qu il a besoin d envoyer un résultat sous forme non chiffrée à l utilisateur. 2.4 Problèmes Jusqu à présent, on a considéré que l ensemble de la mémoire était vérifiée et que seul le crypto-processeur (ou un adversaire) y accède. Or, des périphériques peuvent accéder à la mémoire en utilisant le DMA. Pour résoudre ce problème, [6] propose d utiliser une portion de mémoire non vérifiée pour les transferts DMA. Le programme devra ensuite copier le contenu de cette zone vers la mémoire protégée. Cette solution nécessite néanmoins une copie supplémentaire des données transférées. 10
Chapitre 3 Les aspects logiciels 3.1 La mise en œuvre logiciel Exemple de Crypto- Page Les modifications à apporter à la couche logicielle (programmes et système d exploitation) dépendent du crypto-processeur considéré. Dans tous les cas, de nouvelles instructions sont ajoutées afin d utiliser les fonctionnalités particulières de ces processeurs. Selon ses concepteurs, le processeur Aegis [8] n a pas besoin de modifications au niveau système d exploitation pour pouvoir fonctionner. Au contraire, pour pouvoir exploiter la puce TPM [9], des modifications du système sont nécessaires (cf. section 3.2). Dans [1] est décrite la mise en œuvre logicielle du processeur CryptoPage dans un environnement de type Unix permettant l exécution coexistante de processus utilisateurs ou superviseurs, chacun pouvant être crypté ou non. Aucun processus, même superviseur, ne peut surveiller ce qui se passe à l intérieur d un processus chiffré. Par contre, un processus chiffré peut partager des données avec un autre processus chiffré avec la même clé. Appels au système Afin de pouvoir faire des appels systèmes, un processus chiffré doit tout d abord déchiffrer les arguments passés au noyau pour que celui-ci les comprenne lors du trap. Certains appels systèmes doivent également supporter un mode chiffré et un mode non chiffré comme par exemple write() qui permettra d enregistrer des informations chiffrées dans un fichier et qui devra avoir un complémentaire write nc() qui lui écrira des informations non chiffrées. Les fonctions d allocation mémoire comme malloc() devront réserver de la mémoire en plus afin de permettre le stockage des signatures utilisées pour vérifier l intégrité des données. Création de processus chiffrés La création d un nouveau processus en Unix se fait par appel à la fonction fork(). Si le processus qui l appelle est chiffré, le processus créé sera lui aussi chiffré. Lors de l appel à exec() qui permet de lancer un nouveau programme, si le système rencontre un exécutable chiffré, il fera appel à la primitive d initialisation de processus chiffré du crypto-processeur en lui passant comme paramètre le contexte matériel chiffré présent dans l exécutable. Signaux Les signaux en Unix sont des interruptions logicielles qui se traduisent par des appels de fonctions par le noyau lorsque le processus reçoit un signal. Or il y a un problème si 11
Fig. 3.1 Interactions entre applications et matériel sur un ordinateur NGSCB le noyau s exécute en mode non chiffré et qu il doit appeler une fonction d un processus chiffré. Il faut donc ajouter une couche qui permettra de chiffrer les paramètres à passer à la fonction. Compilation Le format exécutable produit par le compilateur doit être étendu pour supporter les exécutables chiffrés. Il doit notamment comporter un entête pour indiquer qu on a affaire à un exécutable chiffré, un descripteur chiffré avec la clé publique du processeur et qui contient la clé symétrique de chiffrement de l exécutable, une zone text comportant le code exécutable chiffré et une zone initialized data contenant les données initialisées du programme sous forme chiffrée. 3.2 NGSCB / Palladium NGSCB (Next-Generation Secure Computing Base, anciennement Palladium) est un projet d extension proposé par Microsoft pour son système d exploitation Windows. Il est décrit assez superficiellement dans [13, 14]. Ce modèle se base sur un noyau sécurisé appelé Nexus et sur des primitives matérielles comme celles offertes par TCG (cf. section 1.2). Le nexus s intercale entre le processeur et le système d exploitation (cf. figure 3.1), considéré comme non sécurisé. Cependant, il n effectue que les opérations jugées sensibles, délégant les autres au système. Il offre quatre fonctions de base qui sont l isolation forte des processus, le stockage sécurisé, l attestation cryptographique et les chemins sécurisés. 3.2.1 Isolation forte des processus Le nexus, par un dispositif de marquage des adresses, va empêcher les applications et le système d exploitation d accéder à certaines parties de la mémoire utilisées par luimême ou par des NCA (Nexus Computing Agent) qui sont des portions de programmes qui 12
nécessitent un environnement protégé particulier. Il interdit également les transferts DMA en direction ou en provenance de ces pages mémoire. La mémoire sera donc découpée entre les applications sécurisées (les NCA) et le nexus, et les applications normales et le système d exploitation. 3.2.2 Stockage sécurisé Le nexus utilise les fonctions proposées par le TPM pour assurer un stockage sécurisé sur le disque aux NCA. Ces derniers peuvent demander au nexus que les informations qui sont ainsi chiffrées ne soient accessibles qu à lui-même ou à d autres applications. Par exemple, les informations ne peuvent être lues que par l application qui les a sauvegardées et seulement sur une machine donnée. Ainsi, en cas de vol du disque, les informations ne pourront pas être déchiffrées. NGSCB propose également une méthode pour permettre la sauvegarde sécurisée des données sur d autres machines. 3.2.3 Attestation cryptographique Cette fonctionnalité permet à un logiciel d attester qu une donnée a été produite à l aide d une configuration logicielle cryptographiquement identifiable. Si elle est utilisée avec une infrastructure de certification, ce mécanisme permet à l utilisateur de prouver que le matériel et la couche logicielle sont légitimes. 3.2.4 Chemins sécurisés vers l utilisateur Le nexus s assure que lorsqu un NCA a besoin d effectuer des opérations d entrées/sorties, les données qui transitent ne peuvent pas être interceptées par d autres applications ou par le système d exploitation. 13
Chapitre 4 Les simulateurs de machines virtuelles Afin d évaluer les performances de divers crypto-processeurs ainsi que des éventuelles modifications à apporter au système d exploitation et/ou aux logiciels, on peut avoir recours à des simulateurs. 4.1 SimpleScalar SimpleScalar 1 est une suite d outils permettant de simuler le fonctionnement de plusieurs processeurs actuels (Alpha, ARM, i386, etc.) et d évaluer précisément leurs performances. Les modèles de processeurs qu il intègre peuvent simuler des fonctions avancées présentes dans certains processeurs comme l exécution spéculative, la prédiction de branchement. On peut également par exemple, modéliser finement le fonctionnement des différents niveaux et politiques de gestion des caches. SimpleScalar a été crée par Todd Austin. Il est maintenant commercialisé par la société SimpleScalar LLC mais il est possible de l utiliser et de le modifier dans un but non commercial. De plus, il est très portable, flexible (il permet par exemple de simuler des architectures little-endian sur une machine big-endian par exemple) et très populaire 2. Les auteurs de [8] l utilisent notamment afin de mesurer l impact en terme de performance des algorithmes choisis pour l implantation du crypto-processeur Aegis. Cependant, il ne simule que le processeur ainsi que la hiérarchie mémoire. Il transfère tous les appels systèmes au système hôte. Il ne permet donc pas de simuler l exécution d un système d exploitation complet sur le processeur virtuel mais uniquement l exécution d applications compilées pour celui-ci (via une adaptation spéciale de gcc pour SimpleScalar), contrairement à Bochs (cf. section 4.2). 4.2 Bochs Bochs 3 est un émulateur portable open-source de PC. Il permet d émuler sur un grand nombre de plate-forme un PC standard avec tous ses composants : processeur (x86), BIOS, carte graphique, disque dur, mémoire, etc. et ainsi de faire tourner sans modification pratiquement tous les systèmes d exploitation et logiciels destinés aux PC. 1 http://www.simplescalar.com 2 D après le site web, en l an 2000, près d un tiers des articles publiés dans les plus grandes conférences sur l architecture des ordinateurs l utilisaient. 3 http://bochs.sourceforge.net 14
En modifiant le modèle de processeur utilisé pour l émulation, il devient alors possible de simuler l ajout de fonctions cryptographiques à un processeur de type i386 et donc de simuler le comportement des applications lors de l utilisation d un crypto-processeur. Cependant, Bochs ne dispose pas d outils permettant la réalisation de tests de performance. Si l on veut disposer de mesures sur l impact du crypto-processeur, il faudra soit rajouter des sondes à l intérieur du code source de Bochs, soit utiliser un autre outil plus adapté à la simulation d un processeur (cf. SimpleScalar, section 4.1). 15
Conclusion Nous venons donc de voir qu il existe un certain nombre de travaux sur les cryptoprocesseurs et leur environnement (vérification de la mémoire et aspects système d exploitation) visant à disposer d une architecture matérielle sécurisée afin de permettre l exécution fiable de programmes. À partir de ces systèmes, on peut développer par exemple des solutions de protection contre le piratage d œuvres numériques ou permettre l exécution sécurisée d applications dans les grilles de calcul. Il reste à évaluer précisément les ajouts à effectuer dans un système d exploitation particulier et dans un compilateur et d évaluer les impacts de ceux-ci en terme de performance dans le cadre du crypto-processeur Crypto- Page, ce qui fait l objet de ce stage. 16
Bibliographie [1] Ronan Keryell. «CryptoPage-1 : vers la fin du piratage informatique?». Dans Symposium d Architecture (SympA 6), pages 35 44, Besançon, juin 2000. http://www.lit. enstb.org/~keryell/publications/enstbr_info_2000-001. [2] Cédric Lauradoux et Ronan Keryell. «CryptoPage-2 : un processeur sécurisé contre le rejeu». RENPAR 15/CFSE 3/SympAAA 2003, La Colle sur Loup, octobre 2003. http://www.lit.enstb.org/~keryell/publications/conf/2003/sympaaa. [3] David Lie, Chandramohan Thekkath, Mark Mitchell, Patrick Lincoln, Dan Boneh, John Mitchell et Mark Horowitz. «Architectural Support for Copy and Tamper Resistant Software». Dans Architectural Support for Programming Languages and Operating Systems, pages 168 177, 2000. [4] Manuel Blum, William S. Evans, Peter Gemmell, Sampath Kannan et Moni Naor. «Checking the Correctness of Memories». Dans IEEE Symposium on Foundations of Computer Science, pages 90 99, 1991. [5] Manuel Blum et Sampath Kannan. «Designing programs that check their work». Dans STOC89, pages 86 97, 1989. [6] Blaise Gassend, G. Edward Suh, Dwaine Clarke, Marten van Dijk et Srinivas Devadas. «Caches and Markle Trees for Efficient Memory Authentication», 2002. [7] Dwaine Clarke, Blaise Gassend, G. Edward Suh, Marten van Dijk, Srinivas Devadas. «Offline Integrity Checking of Untrusted Storage». Dans Technical Report MIT-LCS-TR-871, Massachusetts Institute of Technology, novembre 2002. Disponible sur http://www.lcs.mit.edu/publications/pubs/pdf/mit-lcs-tr-871.pdf. [8] G. Edward Suh, Dwaine Clarke, Blaise Gassend, Marten van Dijk et Srinivas Devadas. «The Aegis Processor Architecture for Tamper-Evident and Tamper- Resistant Processing». Dans Technical Report MIT-LCS-TM-461, Massachusetts Institute of Technology, février 2003. Disponible sur http://csg.lcs.mit.edu/pubs/ memos/memo-461/memo-461.pdf. [9] Trusted Computing Group. «TCG Main Specification». Disponible sur http://www. trustedcomputinggroup.org, septembre 2001. [10] William A. Arbaugh, David J. Farber et Jonathan M. Smith. «A Secure and Reliable Bootstrap Architecture». Dans IEEE Symposium on Security and Privacy, pages 65 71, 1997. [11] Andrew Huang. «The Trusted PC : Skin-Deep Security». Dans Computer, pages 103 105, octobre 2002. [12] Bill Arbaugh. «Improving the TCPA Specification». Dans Computer, pages 77 79, août 2002. [13] Windows Platform Design Notes. «Security Model for the Next-Generation Secure Computing Base». Disponible sur http://www.microsoft.com/resources/ngscb, 2003. 17
[14] Windows Platform Design Notes. «NGSCB : Trusted Computing Base and Software Authentication». Disponible sur http://www.microsoft.com/resources/ngscb, 2003. [15] Markus G. Kuhn. «Cipher Instruction Search Attack on the Bus-Encryption Security Microcontroller DS5002FP». Dans IEEE Transactions on Computers, 47(10) :1153 1157, octobre 1998. 18