FR 2965381 A1 20120330 FR 1003811 A 20100927 1 Procédé de démarrage d'un terminal avec vérification d'authenticité du système d'exploitation du terminal Domaine technique de l'invention L'invention est relative à un procédé de démarrage d'un système d'exploitation d'un terminal comportant les étapes suivantes au démarrage 10 du terminal: démarrer un micrologiciel d'entrées/sorties, donner la main par le micrologiciel d'entrées/sorties à un module de démarrage d'un système d'exploitation. 15 État de la technique Les terminaux communicants proposent des plateformes de services à destinations d'utilisateurs ou de machines. Classiquement, un terminal 20 repose sur une architecture matérielle au-dessus de laquelle vient se greffer un système d'exploitation du terminal muni d'applications spécifiques. Les opérateurs de réseau proposent dans les terminaux des systèmes d'exploitations et des applications, pouvant tous deux être développés par des tiers, afin de former une plateforme associée aux services à fournir. Les 25 services à fournir peuvent comporter des services de téléphonie, des services de données, des services d'applications bancaires, ou d'autre types d'applications pouvant être soumises à un abonnement payant ou non, etc. Les terminaux peuvent être proposés à la location, ou vendus et être liés à un contrat limitant leurs fonctions et leurs utilisations, cette limitation peut elle 30 même être limitée dans le temps.5 2 Les opérateurs voulant fournir une plateforme opérationnelle et maîtrisée se heurtent à des modifications non autorisées de leurs plateformes, allant souvent au-delà des conditions d'utilisation prévues par les contrats passés entre l'utilisateur et l'opérateur. Ces modifications peuvent se présenter sous la forme de mises à jour du système d'exploitation, d'applications, ou d'ajouts d'applications modifiant le fonctionnement global de la plateforme de services. Les mises à jour ou ajouts peuvent être réalisés par les concepteurs du système d'exploitation, des applications, ou encore par des utilisateurs ou tierces-parties souhaitant modifier le comportement de la plateforme à l'insu des opérateurs. Les solutions actuelles ne permettent pas d'assurer à un opérateur que sa plateforme sera toujours fonctionnelle de manière optimale car les systèmes d'exploitation peuvent être modifiés par les utilisateurs afin de leur apporter de nouvelles fonctionnalités. Ces nouvelles fonctionnalités peuvent être mises en concurrence avec des services de l'opérateur, et entraîner la modification de fichiers systèmes rendant non fonctionnels certains services fournis par l'opérateur. Objet de l'invention L'objet de l'invention consiste à réaliser un procédé de démarrage d'un système d'exploitation d'un terminal associé à un opérateur, et à s'assurer de l'authenticité de ce système. On tend vers ce but en ce que le procédé comporte les étapes suivantes : lire par le module une première clé publique dans une carte à puce, vérifier l'authenticité d'un fichier représentatif du système d'exploitation par le module avec la première clé publique, 3 initier par le module le démarrage du système d'exploitation si l'authenticité du fichier est valable. Selon un développement, l'étape de lecture de la première clé publique 5 utilise un lien de communication de protocole de bus série universel. Selon un perfectionnement, le fichier représentatif du système d'exploitation est un fichier choisi parmi un noyau système, un chargeur d'amorçage ou un fichier de couche de virtualisation. Selon une variante, l'authenticité de la première clé publique est vérifiée par le module en utilisant une deuxième clé publique stockée dans le module ou dans une mémoire ROM associée au module. 15 Selon un perfectionnement, l'étape de lecture de la première clé publique comporte la lecture d'un objet logiciel comprenant la première clé publique et un lien vers le fichier représentatif du système d'exploitation à démarrer. Selon un mode de réalisation, le procédé comporte, après la vérification de 20 l'authenticité du fichier représentatif du système d'exploitation, une étape d'envoi d'un message par le module à la carte à puce pour l'informer du résultat de la vérification de l'authenticité. Après réception du message par la carte à puce, le procédé peut comporter une étape de blocage du terminal par la carte à puce si le résultat de la vérification d'authenticité est négatif. 25 Selon une variante, les échanges entre le module et la carte à puce sont réalisés avec un mécanisme assurant l'intégrité des échanges. 10 30 4 Description sommaire des dessins D'autres avantages et caractéristiques ressortiront plus clairement de la description qui va suivre de modes particuliers de réalisation de l'invention donnés à titre d'exemples non limitatifs et représentés aux dessins annexés, dans lesquels : La figure 1 illustre un mode de réalisation particulier d'un terminal pouvant être utilisé dans le cadre de l'invention. La figure 2 illustre un diagramme des tâches effectuées lors du démarrage du terminal. Description de modes préférentiels de réalisation Le présent procédé diffère des procédés de démarrage de terminaux selon l'art antérieur en ce que le micrologiciel d'entrées/sorties (« firmware » en anglais) par exemple de type BIOS (pour « Basic Input Output System » en anglais), donne la main à un module lançant lui-même le système d'exploitation en vérifiant l'authenticité de ce dernier par l'utilisation d'une clé publique accessible via une carte à puce. La carte à puce, ou une partie de la carte à puce pouvant être la propriété d'un opérateur fournissant, par exemple des services de type réseau de données ou de téléphonie. La clé publique permet de s'assurer de l'authenticité du système d'exploitation. Comme illustré aux figures 1 et 2, le procédé de démarrage d'un système d'exploitation d'un terminal 1 comporte au démarrage du terminal une étape de démarrage d'un micrologiciel d'entrées/sorties 2 (étape E1). De manière classique, un micrologiciel d'entrées/sorties 2 peut par exemple passer en revue les composants connus du terminal 1 comme par exemple un processeur 3, un élément de communication 4, de la mémoire, un clavier, un écran, etc. Le micrologiciel d'entrées/sorties 2 peut alors comporter un ensemble de fonctions contenues par exemple dans une mémoire morte (ROM pour « read Only Memory » en anglais) d'une carte mère du terminal sur laquelle sont reliés, ou intégrés comme périphériques, les composants du 5 terminal 1. Le micrologiciel est en fait une couche basse interagissant avec le matériel (« hardware » en anglais), et qui sert de base à l'établissement du démarrage du terminal Le micrologiciel d'entrées/sorties 2 peut ensuite donner la main à un module 5 de démarrage d'un système d'exploitation, ledit module 5 pouvant être interne au micrologiciel d'entrées/sorties 2 ou annexe au micrologiciel 2, et par exemple être stocké dans une ROM de la carte mère, ou déporté sur une carte périphérique reliée à la carte mère mais contenant des instructions de type micrologiciel à exécuter au démarrage du terminal 1. De préférence, le module 5 est interne au micrologiciel 2 de sorte à améliorer l'intégration du terminal et limiter les composants du terminal. De plus, l'intégrité du module 5 est de fait assurée quand le module fait partie 5 du micrologiciel 2. Le module 5 qu'il soit interne ou annexe peut comporter des instructions exécutables permettant de mettre en place un environnement et initier le démarrage d'un système d'exploitation certifié par un opérateur. Dans le cas présent, le module 5 aura pour rôle de lancer un système d'exploitation, et de s'assurer d'un début d'une chaîne de confiance pour le lancement de ce dernier. Par module interne, on entend une partie du micrologiciel d'entrées/sorties. Par module annexe, on entend par exemple une ROM d'une carte annexe. Un fois que le module 5 a la main (étape E2), ce dernier va lire une première clé publique dans une carte à puce 6 (étape E3). La clé publique est en fait 6 une clé publique d'authenticité permettant d'authentifier une entité, par exemple par signature électronique de l'entité. Dans le cas présent, l'entité est un fichier représentatif du système d'exploitation à démarrer. Ainsi, si le fichier est authentique, le module 5 de démarrage peut décider d'initier le démarrage du système d'exploitation en considérant que la chaîne de confiance est établie. Pour vérifier l'authenticité du fichier (étape E4), en général un condensat (fichier supplémentaire de taille inférieure au fichier à condenser) de ce fichier est signé en fonction d'une clé publique et d'une clé privée, et le processus de vérification peut être le suivant : pour le fichier F représentatif du système d'exploitation, une signature S(F) est associée audit fichier avec S(F)=signl (clé_privée, (H(F)) où H est une fonction de hachage générant un condensat du fichier F, avec signl la fonction prenant le hachage du fichier F et l'encodant avec la clé_privée, la fonction de vérification d'authenticité peut alors prendre en paramètre le fichier F à vérifier, sa signature S(F), calcule H(F) et vérifie que H(F) est égal à sign2(clé_publique, S(F)) avec sign2 la fonction prenant la signature S(F) du fichier F à vérifier et la décodant avec la clé_publique. Si on a égalité, on considère que le fichier est authentique. Le fichier à vérifier étant signé, sa signature S(F) est en général attachée avec ledit fichier. Le fichier représentatif du système d'exploitation à démarrer peut, par exemple, comporter un entête qui contient S(F). La fonction de hachage est une fonction particulière qui, à partir d'une donnée fournie en entrée, calcule une empreinte servant à identifier rapidement, bien qu'incomplètement, la donnée initiale.30 Bien entendu, à la place du hachage du fichier, le fichier entier pourrait être signé, cependant cela augmenterait le temps nécessaire à la vérification. Si le fichier est authentique, le module 5 peut décider d'initier le démarrage 5 du système d'exploitation associé au fichier (étape E6 après avoir emprunté la sortie oui de l'étape E5). La vérification de l'authenticité du fichier représentatif du système d'exploitation est réalisée par le module 5. Ainsi, le module 5 peut comporter 10 des moyens de vérification aptes à exploiter la première clé publique. De tels moyens peuvent, par exemple, comporter des instructions de déchiffrage et éventuellement de chiffrage. Dans ce cas, le module 5 forme l'autorité de vérification. Le module 5 peut alors lire le fichier, par exemple dans une mémoire de stockage du terminal afin de le récupérer pour en vérifier 15 l'authenticité avec la première clé publique. Le fichier représentatif du système d'exploitation à démarrer peut être un noyau système, l'authenticité du noyau système, ou de son condensat, est vérifiée par le module 5 en utilisant la première clé publique. Dans ce cas, 20 après la vérification de l'authenticité du fichier, si le fichier est authentique, le module 5 peut décider de le lancer pour initier le démarrage du système d'exploitation (sortie oui de l'étape E5). Le fichier représentatif du système d'exploitation peut aussi être un fichier de 25 démarrage de système d'exploitation par exemple de type chargeur d'amorçage (« BootLoader » en anglais). Dans le cas où le fichier est un chargeur d'amorçage, l'authenticité du chargeur d'amorçage, ou de son condensat, est vérifiée par le module 5 en utilisant la première clé publique. Si l'authenticité du chargeur d'amorçage est correcte, le module 5 décide 30 d'initier le démarrage du système d'exploitation en donnant la main au chargeur d'amorçage qui constitue alors la suite de la chaîne de confiance 8 du démarrage. Le chargeur d'amorçage peut alors comporter une configuration statique d'un nom de noyau de système d'exploitation et d'une autre clé publique pour vérifier l'authenticité du noyau, stockée de préférence, au sein du chargeur d'amorçage pour continuer ainsi la chaîne de confiance. Dans une variante, le chargeur d'amorçage peut pointer vers un système de couche de virtualisation capable de lancer plusieurs systèmes d'exploitation. II est ainsi possible de démarrer plusieurs systèmes d'exploitation dont l'un est certifié par l'opérateur, et pourra par exemple être le seul à s'interfacer avec la carte à puce 6 pour se connecter au réseau opérateur. Le fichier représentatif du système d'exploitation peut aussi directement être un fichier de couche de virtualisation permettant de lancer plusieurs systèmes d'exploitation. Ce fichier ou son condensat étant alors vérifié par le module 5 en utilisant la première clé publique 5. La carte à puce 6 peut être de type carte sur circuit intégré universel UICC (pour « Universal Integrated Circuit Card » en anglais). Une telle carte à puce 6 est basée typiquement sur un microprocesseur et une mémoire. Cette carte à puce 6 peut comporter une application SIM (pour « Subscriber Identity Module » en anglais), USIM (pour « Universal Subscriber Identity Module » en anglais), ou autre application permettant à un opérateur, par exemple de téléphonie/données mobiles, de gérer l'authentification de l'abonné au réseau de l'opérateur et les droits d'utilisation du réseau. En outre, la carte à puce 6 peut comporter d'autres applications par exemple de type JavaCard. Ces applications peuvent être la propriété de l'opérateur qui, en utilisant les mécanismes de sécurité de la carte à puce 6, est le seul à pouvoir les modifier. 9 La première clé publique peut être stockée dans un champ opérateur de la carte à puce, tel que le champ EFoRPK (Operator Root Public Key) défini dans le standard 3GPP TS 11.11. La première clé publique et, le cas échéant le fichier représentatif du système d'exploitation ou son lien, peuvent aussi être stockés dans une application JavaCard associée à un domaine de sécurité tel que défini par le standard GlobalPlatform Card Specification v2.2. En fait, un domaine de sécurité est une application spécifique de type applet, permettant de stocker une ou un ensemble de clés de chiffrage et/ou de déchiffrage (clé publique dans notre cas). Dans une application JavaCard, l'application est associée à un domaine de sécurité et cette association est réalisée au moment de l'installation et ne peut être détruite. Autrement dit, la carte à puce peut être au préalable initialisée en associant la première clé publique à un domaine de sécurité de la carte à puce 6. Ainsi, de préférence, la première clé publique sera stockée dans un domaine de sécurité de la carte à puce 6. Le fichier représentatif du système d'exploitation peut aussi être stocké sur un support de mémoire du terminal, par exemple un disque dur, une mémoire flash, une mémoire publique libre d'accès de la carte à puce (accessible en lecture/écriture ou écriture seule), etc. 25 En fait, les opérateurs ont le contrôle des cartes à puces qui leur fournissent un environnement verrouillé et sécurisé. Une application de la carte à puce 6 peut alors former une sorte de serveur, permettant à des services d'exécuter des fonctions sur la carte à puce 6, comme par exemple la lecture d'une clé 30 publique permettant la vérification de l'authenticité d'un fichier. Les applications de la carte à puce 6, notamment les applications JavaCard,20 10 permettent à des opérateurs de fournir des services totalement sécurisés en définissant au sein de la carte à puce 6 des domaines de sécurité sous le contrôle unique de ces opérateurs. Ainsi, dans le présent mode de réalisation, la première clé publique située dans la carte à puce 6 pourra être stockée dans un domaine de sécurité associé à l'opérateur, par exemple de téléphonie et/ou de données mobiles. Ce domaine de sécurité sous l'autorité de l'opérateur ne peut être modifié par un tiers pour changer la logique de démarrage du terminal. Le fichier, ou un lien vers le fichier, représentatif du système d'exploitation peut aussi être fourni par la carte à puce 6 avant ou après l'étape de lecture de la première clé publique (étape E3). De préférence, ledit fichier ou le lien pointant vers ce fichier sera fourni par la carte à puce 6 en même temps que la première clé publique. Pour des raisons de sécurité, il est préférable d'envoyer la première clé publique et le fichier, ou le lien pointant vers le fichier, en utilisant un seul envoi. Ceci peut être mis en oeuvre par l'utilisation d'un objet logiciel. Dès lors, l'étape de lecture de la première clé publique peut comporter la lecture d'un objet logiciel comprenant la première clé publique, et un lien vers le fichier représentatif du système d'exploitation à démarrer ou le fichier lui-même. Le lien peut correspondre à un nom de fichier plus un chemin d'accès au fichier, la taille du fichier, la partition sur laquelle est stocké le fichier, etc. Toujours pour améliorer la sécurité, l'authenticité de la première clé publique peut être vérifiée par le module 5 en utilisant une deuxième clé publique par exemple stockée dans le module 5 ou dans une mémoire ROM associée au module 5. Une telle vérification peut imposer que la première clé publique, ou un condensat de la première clé publique, soit au préalable signé par une clé secrète (aussi appelée clé privée) associée à la seconde clé publique. Cette vérification permet d'éviter un détournement du démarrage du terminal par Il un tiers interceptant la première clé publique et la remplaçant par une clé publique modifiée signant un fichier représentatif d'un système d'exploitation modifié de son choix. En effet, dans ce cas le tiers pourrait faire croire au module 5 qu'il démarre bien le système d'exploitation certifié par l'opérateur de la carte à puce 6 alors que cela n'est pas le cas. Selon la variante utilisant un objet logiciel, l'objet lui-même peut être signé et l'authenticité de sa signature peut être vérifiée par la seconde clé publique. À ce moment précis, le module 5 sait que la première clé publique, et le cas io échéant le fichier, ou le lien vers le fichier, fait partie du cercle de confiance de l'opérateur, et la base de la chaîne de confiance est établie de manière plus sûre en utilisant un double contrôle. Dans l'expectative de s'apercevoir de tout détournement du démarrage du 15 terminal, la carte à puce 6 peut comporter des moyens aptes à générer à différentes étapes du démarrage du terminal une image instantanée de ce démarrage. Ainsi, après la vérification de l'authenticité du fichier représentatif du système 20 d'exploitation, le procédé de démarrage du terminal peut comporter une étape d'envoi d'un message par le module 5 à la carte à puce 6 pour l'informer du résultat de la vérification de l'authenticité. À la réception de ce message, la carte à puce 6 peut générer une image instantanée du démarrage en associant le message à une action réalisée par le module 5 25 (dans le cas présent le résultat de la vérification de l'authenticité). Le message peut aussi être formé par un objet logiciel comprenant une valeur représentative d'une action et une valeur représentative du résultat de l'action. 30 Selon les cas, le module 5, même si l'authenticité du fichier représentatif du démarrage du terminal n'est pas valable, pourra quand même décider 12 d'initier le démarrage du système d'exploitation appelé ci-après système d'exploitation modifié (étape E7 selon la sortie non de l'étape E5 de la figure 2). Dès lors, si le message reçu par la carte à puce 6 est négatif (authenticité non valable), c'est-à-dire que le fichier n'est pas celui de l'opérateur mais un fichier lançant le système d'exploitation modifié, la carte à puce 6 pourra en informer l'opérateur (propriétaire ou administrateur de la carte à puce 6) en utilisant les moyens de communication du terminal, typiquement un élément de communication, par exemple de type 3G+. La carte à puce pourra aussi remonter le message si la vérification est valable pour des raisons statistiques. L'opérateur pourra alors, selon les cas et notamment lorsque l'authenticité du fichier n'est pas valable, prendre la décision de limiter les accès à son réseau de téléphonie et/ou de données, par exemple en n'autorisant que les appels d'urgence dans le cas où le terminal est un téléphone mobile. L'opérateur pourra aussi renvoyer un message à la carte à puce 6 pour l'informer d'une action à effectuer sur le terminal, par exemple un blocage ou un arrêt de ce dernier. Selon une variante la carte à puce 6 pourra à la réception d'un message négatif de la vérification de l'authenticité du système d'exploitation déclencher une étape de blocage du terminal par la carte à puce 6. Ainsi, de manière générale, le procédé comporte, après réception du message par la carte à puce 6, une étape de blocage du terminal par la carte à puce 6 si le résultat de la vérification d'authenticité est négatif. Un tel blocage peut être réalisé en donnant un ordre d'arrêt à un modem, correspondant à un processeur dans le terminal gérant les communications. Un arrêt de l'appareil peut par exemple être réalisé si un processeur principal de la carte mère, par exemple le processeur 3 de la figure 1, du terminal supporte une fonction de blocage à distance, à titre d'exemple, on pourra utiliser la technologie Intel® vPro' 13 Pour améliorer la sécurité, les échanges, par exemple des messages, de la première clé publique, etc., entre le module 5 et la carte à puce 6 peuvent être réalisés en utilisant un mécanisme assurant l'intégrité des échanges, par exemple en utilisant des messages signés ou chiffrés. En effet, dans un cas particulier le message envoyé du module 5 à la carte à puce 6 pourrait être intercepté puis modifié pour faire croire à la carte à puce 6 que l'authenticité est valable alors que cela n'est pas le cas. Le chiffrement peut être mis en ceuvre de manière symétrique, ou asymétrique par un couple de clé publique et privé du module 5 et un couple de clé privée et publique de la carte à puce 6. Dès lors, le module 5 peut par exemple au moment où il prend la main (étape E2) initier un échange pour envoyer sa clé publique à la carte à puce 6 et récupérer la clé publique de la carte à puce 6 afin d'initier une transmission sécurisée de la première clé publique qui sera utilisée pour la vérification d'authenticité (les clés publique/privée du module 5 peuvent aussi être allouées dynamiquement par le module 5). II est aussi possible de disposer, lors de la fabrication du terminal et de la carte à puce 6, la clé publique de la carte à puce 6 et la clé privée du module 5 dans une ROM du module 5 (ou dans un autre élément de sécurité du terminal, par exemple un module TPM, composant matériel additionnel de confiance du terminal) et la clé publique du module 5 et la clé privée de la carte à puce 6 dans la carte à puce 6, de préférence dans un domaine de sécurité de la carte à puce 6. Selon un exemple particulier de mise en oeuvre, le module 5 peut, après avoir pris la main (étape E2), détecter la présence d'un élément de communication 4 (exemple du modem de communication intégré ou non à la carte mère du terminal), par exemple de type 3G+, ou de la carte à puce 6. Dans le cas d'un élément de communication 4 comprenant une carte à puce 6, le module 5 peut se connecter au modem de l'élément de communication 4 qui forme alors la passerelle entre le module 5 et la carte à puce 6. À ce 14 jour, il est, par exemple, possible de se connecter à un modem d'une carte de communication 4 en utilisant une connexion USB (Bus Série Universel) série ou USB CDC (pour « Communication Device Class » en anglais). Bien entendu, l'homme du métier pourra adapter tous les types de communication permettant au module 5 de dialoguer avec la carte à puce 6 par l'intermédiaire de la carte de communication 4. Dans le cas d'une carte à puce 6 seule, le module 5 peut directement se connecter à la carte à puce 6 par USB (bus série universel) par exemple de type USB PC/SD (pour « Personal Computer / Smart Card ») ou par USB UICC-Terminal USB telle que définie dans le standard ETSI TS 102.600. Dans le cas où le fichier représentatif du système d'exploitation peut être stocké dans un espace mémoire, par exemple flash, de la carte de communication, si cet espace mémoire est public, le module 5 peut s'y connecter par USB, par exemple USB stockage de masse (« Mass Storage » en anglais). Dès lors, l'étape de lecture de la première clé publique utilise un lien de communication de protocole de bus série universel (USB), et en fonction des liaisons utilise des variantes de l'USB telles que décrites ci-dessus. Selon une variante, la liaison USB peut aussi être remplacée par un bus PCI, un bus interne à un chipset multi-processeur. La présente invention permet à une entité contrôlant la carte à puce 6, par exemple un opérateur mobile, de maîtriser, contrôler complètement le système d'exploitation et les éléments logiciels du terminal pour, par exemple, offrir une configuration graphique du terminal et forcer, par exemple, l'affichage de son logo, l'installation de logiciels spécifiques à son offre qui ne peuvent être supprimés par l'utilisateur. L'opérateur peut aussi fournir un client de téléchargement d'applications validées par l'opérateur, 15 ainsi seul le client de téléchargement de l'opérateur pourra être démarré et utilisé. Une fois que la chaîne de confiance a été initiée par le module 5, le démarrage peut comporter d'autres vérifications au niveau du système d'exploitation. Ces vérifications peuvent comporter des étapes de vérification de l'authenticité par exemple lors du lancement d'une application du système d'exploitation. Le résultat de chaque étape de vérification d'authenticité peut alors être envoyé à la carte à puce 6 qui peut alors décider, en passant ou non par l'opérateur, d'effectuer une action de blocage du terminal. Le système d'exploitation peut être un système brut ou un système personnalisé avec des composants logiciels tels qu'une plateforme d'exécution logicielle, un client de boutique en ligne d'applications, des logiciels applicatifs. Un des avantages de la présente solution permet de combiner un mécanisme de contrôle de démarrage du système d'exploitation aux mécanismes de sécurité de la carte à puce 6. Les méthodes de contournement de ce mécanisme de contrôle correspondant à retirer la carte à puce et la substituer par une autre, même si ces méthodes peuvent fonctionner, elles n'ont pas d'intérêt car le terminal n'aura plus les moyens de se connecter au réseau de l'opérateur, le terminal perdant alors tout son attrait communicatif. La présente solution permet aussi un contrôle d'authenticité avant le lancement du système d'exploitation, limitant les failles permettant de passer outre la vérification d'authenticité, grâce à l'utilisation d'une chaîne de confiance établie par la deuxième clé publique associée au module 5. Selon un développement, l'étape consistant à donner la main par le micrologiciel d'entrées/sortie 2 au module est une étape obligatoire qui n'est 16 pas désactivable par paramétrage du micrologiciel d'entrées/sorties. Autrement dit, c'est une étape qui sera toujours réalisée lors du démarrage. À titre d'exemple, le terminal peut être un téléphone mobile, un ordinateur 5 portable, ou une tablette tactile. REVENDICATIONS1. Procédé de démarrage d'un système d'exploitation d'un terminal (1) comportant les étapes suivantes au démarrage du terminal: démarrer (E1) un micrologiciel d'entrées/sortie (2), donner la main (E2) par le micrologiciel d'entrées/sortie (2) à un module (5) de démarrage d'un système d'exploitation, caractérisé en ce qu'il comporte les étapes suivantes : io lire (E3) par le module (5) une première clé publique dans une carte à puce (6), vérifier l'authenticité (E4, E5) d'un fichier représentatif du système d'exploitation par le module (5) avec la première clé publique, initier (E6) par le module (5) le démarrage du système d'exploitation si 15 l'authenticité du fichier est valable. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de lecture de la première clé publique utilise un lien de communication de protocole de bus série universel. 3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le fichier représentatif du système d'exploitation est un fichier choisi parmi un noyau système, un chargeur d'amorçage, ou un fichier de couche de virtualisation. 25 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'authenticité de la première clé publique est vérifiée par le module (5) en utilisant une deuxième clé publique stockée dans le module (5) ou dans une mémoire ROM associée au module (5). 17 20 30 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape de lecture (E3) de la première clé publique comporte la lecture d'un objet logiciel comprenant la première clé publique et un lien vers le fichier représentatif du système d'exploitation à démarrer. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte, après la vérification de l'authenticité du fichier représentatif du système d'exploitation, une étape d'envoi d'un message par le module (5) à la carte à puce (6) pour l'informer du résultat de i o la vérification de l'authenticité. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les échanges entre le module (5) et la carte à puce (6) sont réalisés avec un mécanisme assurant l'intégrité des échanges. 8. Procédé selon la revendication 6, caractérisé en ce que après réception du message par la carte à puce (6), le procédé comporte une étape de blocage du terminal par la carte à puce (6) si le résultat de la vérification d'authenticité est négatif. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la première clé publique est stockée dans un domaine de sécurité ou dans un champ opérateur de la carte à puce (6). 15 20