Brevet FR3105484A1 — publié le 20210625

La présente invention concerne une méthode de vérification de l’intégrité d’un code binaire, comprenant une pluralité de processus destinés à être exécutés par un processeur après lancement d’un système d’exploitation. Après une procédure de boot sécurisée (210), un premier calcul (220, 260) d’un code d’authentification de référence est effectué pour chaque page mémoire de texte relative à un processus, dès que le code a été chargé dans la RAM. Ultérieurement et/ou périodiquement un second calcul (230, 270) d’un code d’authentification est effectué pour chacune de ces pages mémoire. En cas de de désaccord entre le code d’authentification d’une page et de son code d’authentification de référence, une alerte est générée (290). Figure pour l'abrégé: Fig. 2 MÉTHODE DE VÉRIFICATION DYNAMIQUE DE L’INTÉGRITÉ D’UN CODE MACHINE La présente invention concerne le domaine général de la sécurité informatique et plus particulièrement de la détection de l’injection d’un code malveillant dans un système d’exploitation en cours d’exécution. Etat de la technique antérieure Classiquement un programme informatique (ou code source) est compilé pour générer un code machine (ou code binaire) pouvant être exécuté par le processeur d’un ordinateur ou bien un bytecode pouvant être exécuté par une machine virtuelle. Un code binaire comprend un ou plusieurs processus qui sont chargés tour à tour dans une mémoire vive (ou RAM) et exécutés par le processeur. A chaque processus est alloué un espace mémoire comprenant une partie de texte, une pile d’exécution (encore dénommé plus simplement pile) et une partie de données. La partie de texte du processus contient le code machine à proprement parler, c’est-à-dire une liste d’instructions en assembleur. La pile contient les valeurs des variables locales (autrement dit, propres au processus), le contexte ainsi que les adresses de retour des différentes fonctions du processus. Par adresse de retour, on entend l’endroit où une fonction active du processus doit retourner à la fin de son exécution. Par fonction active, on entend une fonction qui a été appelée mais qui n’a pas terminé son exécution. Enfin, la partie de données contient les valeurs des variables globales, c’est-à-dire des variables qui sont partagées entre plusieurs processus. A chacune des parties de l’espace mémoire précité sont associés des droits d’accès (quelquefois désignés par le terme anglais permissions ) précisant l’utilisation qui peut en être faite. Ainsi, la partie de texte est déclarée accessible en lecture et exécutable mais non accessible en écriture, la pile et la partie de données sont déclarées accessibles en lecture et en écriture mais non exécutables. L’espace mémoire alloué à un processus est en fait un espace de mémoire virtuelle. Chaque partie de cet espace mémoire est divisée en pages mémoire physique, une page mémoire physique (dénommée ci-après plus simplement page mémoire) étant l’unité de mémoire de plus petite taille que peut générer le système d’exploitation compte tenu de l’architecture matérielle sous-jacente. Une page mémoire possède une taille fixe (généralement 4 Koctets), même si cette taille peut varier en fonction du système d’exploitation et de l’architecture matérielle utilisée. La correspondance entre l’espace de mémoire virtuelle et les pages mémoire est gérée par une unité de gestion de mémoire ou MMU ( Memory Management Unit ) à l’aide d’une table de pages. Cette table permet d’associer à chaque adresse de la mémoire virtuelle une adresse de la mémoire physique. La table de page indique également les droits d’accès de chaque page. Ainsi, les pages mémoire relatives à la partie de texte sont exécutables mais ne sont accessibles qu’en lecture, celles relatives à la pile et à la partie de données sont accessibles en lecture et écriture mais ne sont pas exécutables. Les droits d’accès attribués aux différentes pages permettent d’interdire un usage non-autorisé, par exemple d’éviter qu’une page de texte d’un processus ne soit écrasée par un autre processus ou qu’un attaquant ( hacker ) n’insère une portion de code dans une page de texte ou encore ne modifie une adresse de retour d’une fonction de manière à ce que cette adresse dépasse la limite de la pile (attaque dite de « stack smashing ») voire qu’elle pointe vers l’adresse d’un code malveillant. Les droits d’accès n’assurent toutefois qu’une protection relative contre l’injection de codes malveillants. Ainsi, par exemple, un attaquant pourrait modifier une adresse de retour d’une fonction dans la pile par une adresse valide d’appel système (attaque dite de « return to libc ») de manière à faire échouer l’exécution d’un processus, voire réaliser une attaque en utilisant la librairie standard du C ( libc ). Des procédures de démarrage sécurisées ( secure boot ) ont été proposées dans l’état de la technique pour se prémunir contre l’injection de codes. Ainsi la procédure décrite dans le brevet US-B-5 937 063 permet de s’assurer de l’intégrité de l’image du noyau ( kernel ) du système d’exploitation lors du démarrage en procédant au chiffrement des instructions par le dispositif de boot puis à leur déchiffrement au fur et à mesure qu’elles sont chargées en RAM. De manière similaire, il a été proposé dans l’article de W.A. Arbaugh et al. intitulé « A secure and reliable bootstrap architecture » publié dans Proc. of Proceedings. 1997 IEEE Symposium on Security and Privacy, de prévoir un boot de BIOS par couches successives, la couche de base étant supposée digne de confiance et contenant le matériel cryptographique, chaque couche étant responsable de vérifier l’intégrité de la couche suivante. Cette vérification permet de propager la confiance de la racine de confiance (i.e. la couche de base) vers la dernière couche validée comme intègre. Ces mesures de protection sont efficaces contre les intrusions intervenant avant ou pendant le chargement d’une image du noyau (intrusions dites hors ligne ou « off-line ») mais elles sont inopérantes ensuite lors de son exécution. Par ailleurs, des mesures de protection ont été également mises en œuvre pour s’assurer de l’intégrité du système de fichiers. Par exemple, l’architecture IMA (Linux Integrity Management Architecture) de Linux permet de contrôler si des valeurs de hachage de fichiers chargés en mémoire sont conformes à des valeurs d’authentification stockées dans une mémoire sécurisée. Le contrôle est effectué lorsque les fichiers sont ouverts. Là encore, le contrôle d’intégrité permet de détecter les injections de code hors ligne mais non celles qui sont susceptibles d’intervenir lors de l’exécution du code binaire. Un objet de la présente invention est par conséquent de proposer une méthode de vérification dynamique de l’intégrité d’un code binaire lors de son exécution par le processeur de manière à prévenir une injection d’un code malveillant après le boot. Présentation de l’invention La présente invention est définie par une méthode de vérification de l’intégrité d’un code binaire, ledit code binaire comprenant une pluralité de processus destinés à être exécutés par un processeur après lancement d’un système d’exploitation, un espace de mémoire virtuelle alloué au dit code binaire étant divisé en une partie de texte, une partie de données et une pile d’exécution, lesdites parties de texte, de données et ladite pile d’exécution étant stockées dans une RAM sous forme de pages mémoire dites respectivement pages mémoire de texte, pages mémoire de données et pages mémoire de pile, ladite méthode de vérification faisant suite à une procédure de lancement sécurisée assurant qu’au moins l’image du noyau du système d’exploitation est intègre lors de son chargement dans la RAM, ladite méthode de vérification étant originale en ce qu’elle comprend : a)un premier calcul, dans une zone sécurisée, d’un code d’authentification de référence pour chaque page mémoire de texte relative à un processus, dès que celle-ci a été chargée dans la RAM, ledit code d’authentification de référence étant stocké en relation avec un index de cette page et un identifiant de ce processus dans une table, dite table d’intégrité de pages ; b) un second calcul, dans ladite zone sécurisée, d’un code d’authentification pour chaque page mémoire de texte stockée dans la RAM relative à un processus en cours d’exécution, le code d’authentification d’une page étant comparé (240, 280) à son code d’authentification de référence, lu dans la table d’intégrité de pages à partir de son index de page et son identifiant de processus ; c) la génération d’une alerte dans le cas où le code d’authentification d’une page diffère de son code d’authentification de référence. Selon un mode privilégié de réalisation, ladite pluralité de processus comprend des processus exécutés en permanence par le processeur, dits processus permanents, l’étape (b) étant effectuée périodiquement pour les pages mémoire de texte relatives à ces processus. Avantageusement, la période avec laquelle l’étape (b) est effectuée pour un processus permanent est fonction du degré de criticité de ce processus, ladite période étant choisie d’autant plus courte que ledit processus permanent est plus critique. Typiquement, les processus permanents comprennent le chargeur et l’ordonnanceur du système d’exploitation. Ladite pluralité de processus peut aussi comprendre des processus dont le code binaire est chargé dynamiquement en mémoire pour être exécuté, dits processus non permanents, l’étape (b) étant alors effectuée à la demande lorsqu’un autre processus le requiert ou lorsqu’un timer arrive à expiration. Selon une première variante, le code d’authentification d’une page de mémoire de texte est calculé au moyen d’une fonction de hachage. Selon une seconde variante, le code d’authentification d’une page de mémoire de texte est calculé comme un code d’authentification de message à partir du contenu de cette page et d’un flux de clé dérivé d’une clé de chiffrement symétrique. Une nouvelle clé de chiffrement symétrique peut être générée à chaque boot. Selon une implémentation avantageuse, le flux de clé est généré à partir de la clé de chiffrement symétrique au moyen d’un algorithme de chiffrement léger de type Trivium ou Grain-128a. Les codes d’authentification de référence sont typiquement enregistrés dans une table stockée dans une mémoire de la zone sécurisée, ladite table comprenant pour chaque page mémoire de texte d’un processus, l’identifiant du processus dont elle dépend, un index de page mémoire et le code d’authentification de référence de ladite page. Brève description des figures D’autres caractéristiques et avantages de l’invention apparaîtront à la lecture d’un mode de réalisation préférentiel de l’invention, décrit en référence aux figures jointes parmi lesquelles : représente de manière schématique une architecture de système permettant de mettre en œuvre une méthode de vérification dynamique d’un code binaire selon un mode de réalisation de l’invention ; représente de manière schématique un ordinogramme d’une méthode de vérification dynamique d’un code binaire selon un mode de réalisation de l’invention. On considérera dans la suite un système informatique comportant un processeur (CPU) associé à une unité de gestion mémoire (MMU) comme mentionné dans la partie introductive. Le système d’exploitation (ou le noyau seulement) est stocké dans une mémoire flash, une ROM ou un disque dur et est chargé en RAM lors du boot du système. On suppose qu’une procédure de boot sécurisée est mise en place, cette procédure s’assurant que l’image binaire du système d’exploitation, ou à tout le moins de son noyau, est bien intègre au terme du chargement dans la RAM. Le contrôle d’intégrité de l’image du système d’exploitation débute aussitôt que celui-ci a été chargé en RAM. La procédure de contrôle d’intégrité est mise en œuvre dans un environnement sécurisé ou TEE ( Trusted Execution Environment ). Un environnement sécurisé est constitué de ressources matérielles (processeur dédié et/ou crypto-processeur distincts du CPU notamment) et logicielles (OS s’exécutant en parallèle avec l’OS classique, primitives cryptographiques, etc.). A titre d’exemples d’environnement sécurisé, on peut citer celui proposé par la technologie ARM TM TrustZone ou bien un module HSM ( Hardware Security Module ). Un module HSM est généralement disponible sous la forme d’une carte électronique enfichable ou d’un dispositif indépendant, connecté(e) à un ordinateur ou un serveur. Il comprend généralement un ou plusieurs crypto-processeur(s). Une architecture de système adaptée à la mise en œuvre d’une méthode de vérification dynamique selon un mode de réalisation de l’invention a été représentée en Fig. 1. Seuls ont été représentés ici les éléments du système utiles à la bonne compréhension de l’invention. L’homme du métier comprendra que le système complet comprend en pratique d’autres éléments et que d’autres implémentations matérielles sont également possibles sans sortir du cadre de la présente invention. Le système représenté est partitionné en un environnement ouvert (non-sécurisé) et un environnement sécurisé au sens précédent. L’environnement ouvert, 100, comprend le CPU, 110, une unité de gestion de mémoire MMU, 120, une RAM, 130, une ROM, 135 ainsi qu’une unité de stockage de programmes et de données utilisateur, 140. L’environnement sécurisé TEE, 150, comprend un CPU, 160 voire un crypto-processeur (non représenté), un dispositif de boot sécurisé 170 (installé par exemple dans un crypto-processeur ou un module HSM), un générateur de nombres aléatoires, 190, une ROM, 185, dans laquelle peuvent être stockés notamment des programmes de primitives cryptographiques et de fonctions de hachage, une RAM, 180, une mémoire sécurisée, 195, (par exemple un élément sécurisé SE, un disque chiffré), dans laquelle peuvent notamment être stockés les clés de systèmes cryptographiques (PKI), les paramètres de systèmes de cryptographie sur courbes elliptiques (ECC), des résultats de hachage etc. La RAM, 180, de l’environnement sécurisé est également destinée à stocker une table de codes d’intégrité de pages ou PIT ( Page Integrity Table ), comme expliqué plus loin. Lors du boot, le noyau du système d’exploitation, stocké par exemple dans une mémoire flash, un disque dur voire une ROM, au sein du système de boot sécurisé, est transféré dans la RAM, 130 pour y être exécuté. Le noyau du système d’exploitation pourra notamment comprendre le chargeur ( loader ) et l’ordonnanceur ( scheduler ). On rappelle que le chargeur est un composant du système d’exploitation dont le rôle est de charger des programmes en mémoire afin de créer des processus. L’ordonnanceur désigne un composant du système d’exploitation ayant pour fonction de déterminer l’ordre d’exécution des processus ainsi créés. Par extension, nous appellerons dans la suite processus permanents les composants du système d’exploitation qui s’exécutent en permanence, du boot à l’arrêt de l’ordinateur. Ainsi, le chargeur et l’ordonnanceur seront eux-mêmes qualifiés de processus permanents. Aussitôt après que le noyau a été chargé dans la RAM, 130, les pages mémoire de texte dans lesquelles a été stocké le noyau font l’objet d’un calcul de codes d’authentification. Les codes d’authentification calculés à ce stade sont encore dénommés codes d’authentification de référence ou codes d’intégrité. Les codes d’authentification de référence relatifs aux différentes pages de texte sont stockés dans la table d’intégrité de pages, PIT. La table PIT comporte avantageusement un premier champ contenant un identifiant du processus, qu’il soit permanent ou non, un second champ contenant un index de page mémoire de ce processus et un troisième champ contenant le code d’intégrité de la page en question, c’est-à-dire son code d’authentification de référence. Un enregistrement dans la table PIT présente par conséquent la forme générale suivante : où est l’identifiant du processus , est l’index de la page mémoire texte de ce processus et est le code d’authentification de référence. Les index des pages peuvent être des adresses de mémoire (réelles) de ces pages dans la RAM. Lorsque ces pages sont successives, elles diffèrent de la taille (fixe) d’une page par exemple 4 Koctets. De manière générale, on peut distinguer deux types de processus système, les processus permanents décrits précédemment et les processus (non permanents) appelés ponctuellement par des applications utilisateur. Les processus faisant partie du noyau du système d’exploitation sont des processus permanents. L’intégrité d’une page mémoire de texte d’un processus permanent est vérifiée périodiquement ou bien à la demande d’un autre processus système. Ainsi, par exemple les pages mémoire de texte du chargeur et de l’ordonnanceur seront avantageusement vérifiées périodiquement. La périodicité avec laquelle l’intégrité d’une telle page est vérifiée peut dépendre du degré de criticité du processus concerné. L’intégrité est vérifiée en calculant le code d’authentification de la page chargée en mémoire et en le comparant avec le code d’intégrité (code d’authentification de référence) stocké dans la table PIT. L’intégrité d’une page mémoire de texte d’un processus non permanent peut être vérifiée de différentes manières. Tout d’abord, le code d’intégrité d’une page mémoire de texte d’un processus non permanent peut être calculé lors du boot, au même titre que pour une page mémoire d’un processus permanent. Le code d’authentification d’une telle page peut être calculé ultérieurement et comparé au code d’intégrité stocké dans la table. Toutefois, cette opération peut ralentir inutilement le boot, certains processus n’étant que très rarement appelés. Selon une variante, lors de la création de l’image du système d’exploitation, un code d’authentification de référence du processus non permanent (et non plus de chaque page mémoire) est calculé dans l’environnement sécurisé puis adjoint au code binaire en question. Avant de charger ce code binaire en mémoire, le chargeur calcule son code d’authentification et le compare au code d’authentification de référence pour en vérifier l’intégrité. Le code binaire n’est pas chargé en mémoire si le code binaire n’est pas intègre. Quel que soit le type du processus, le calcul des codes d’intégrité de ses pages mémoire (de texte) est effectué par un module d’intégrité dans l’environnement sécurisé TEE. De manière similaire, lorsqu’un code binaire correspondant à un programme utilisateur est chargé en RAM pour être exécuté (dans l’environnement ouvert), les codes d’authentification des pages mémoire de texte sont calculés aussitôt après leur chargement. On dispose ainsi de codes d’intégrité servant de référence pour des vérifications ultérieures, périodiques ou ponctuelles. Que ce soit pour le code binaire de processus système ou celui issu d’un programme utilisateur, le contrôle d’intégrité peut non seulement porter sur les pages mémoire de texte du code mais aussi, de manière plus générale, sur les pages mémoire dont le contenu ne varie pas lors de l’exécution du code. Par exemple, les pages mémoire relatives aux données globales qui sont invariantes lors de l’exécution, peuvent également faire l’objet d’un contrôle d’intégrité par comparaison de leurs codes d’authentification respectifs avec leurs valeurs de référence calculées dans l’environnement sécurisé TEE lors de leur chargement en RAM. Le calcul des codes d’authentification est avantageusement effectué à partir d’une mémoire cache de l’environnement sécurisé stockant à la volée des séquences de pages de la RAM 130. Ainsi, lorsqu’une page mémoire est absente de la mémoire cache, une séquence contenant la page mémoire absente est lue de la RAM 130 pour être stockée dans la mémoire cache, autrement dit pour être transférée de l’environnement ouvert vers l’environnement sécurisé. Le calcul du code d’authentification relatif à une page mémoire peut être réalisé selon différentes variantes. Selon une première variante, le module d’intégrité calcule le code d’authentification d’une page mémoire comme une empreinte numérique obtenue à partir d’une fonction de hachage, par exemple une famille de la famille SHA-2 tel que SHA256 ou SHA521 ou de la famille SHA-3. Autrement dit, avec les notations précédentes : où est une fonction de hachage et est le contenu de la page mémoire d’indexée par . Selon une seconde variante, le module d’intégrité calcule le code d’authentification d’une page mémoire comme un code d’authentification de message ou MAC ( Message Authentication Code ). Plus précisément, le module d’intégrité calcule une signature de la page mémoire à partir d’une clé symétrique. Autrement dit, toujours en conservant les mêmes notations : où est un clé symétrique et génère la signature ( tag ) à partir de la clé et du contenu de la page mémoire, . La clé symétrique peut être générée par le générateur de nombres aléatoires, 190, à chaque boot. Cette solution nécessite de recalculer systématiquement l’intégralité de la table PIT à chaque boot mais présente l’avantage d’être plus résistante aux attaques. Alternativement, la clé symétrique peut être stockée dans la mémoire sécurisée, 195, et conservée d’un boot sur l’autre pour une pluralité de boots. Cette solution permet d’éviter de recalculer systématiquement la table PIT au prix d’une moindre résistance aux attaques. Avantageusement, le code d’authentification de messages sera calculé au moyen d’un algorithme de cryptographie léger faisant appel à un chiffrement par flux de clé. On pourra notamment utiliser à cet effet un algorithme tel que Trivium ou Grain-128a. En particulier, l’algorithme Grain-128a possède une option permettant de calculer directement un code d’authentification de message. On trouvera une description de cet algorithme dans l’article de M. Ågren et al. intitulé « Grain-128a : a new version of Grain-128 with optional authentication » publié dans Int’l Journal of Wireless and Mobile Computing, 2011, 5(1), pp. 48-59. La première partie de cet algorithme consiste à générer un flux de clé à partir d’une clé symétrique et d’un vecteur d’initialisation . Le vecteur d’initialisation pourra être incrémenté à chaque boot. Le vecteur d’initialisation initialise un premier registre à décalage et la clé symétrique initialise un second registre à décalage, les deux registres étant reliés et couplés par une fonction booléenne et l’un d’entre eux (NFSR) étant pourvu d’une rétroaction non linéaire. La seconde partie de l’algorithme Grain-128a consiste à générer le code MAC à partir du message (ici le contenu de la page mémoire) et du flux de clé. Les premiers bits ( ) du flux de clé servent à initialiser un accumulateur (de taille ) et les bits suivants ( ) initialisent un troisième registre à décalage (de même taille). Le contenu de l’accumulateur est ensuite itérativement mis à jour au moyen de : où est le contenu du troisième registre à décalage à l’itération , le contenu étant décalé vers la gauche à chaque itération, est le bit de rang de l’accumulateur à l’itération . Le contenu de l’accumulateur à la ème itération donne le code d’authentification de message. De manière similaire, on pourra générer un flux de clé avec l’algorithme Trivium et l’injecter dans le troisième registre à décalage pour obtenir un code d’authentification de message. L’homme du métier comprendra que le calcul des codes d’authentification selon les algorithmes précités est très simple tout en offrant une bonne robustesse aux attaques. La Fig. 2 représente de manière schématique un ordinogramme d’une méthode de vérification dynamique d’un code binaire selon un mode de réalisation de l’invention. La procédure de vérification dynamique suppose qu’une procédure de boot sécurisée a été préalablement effectuée à l’étape 210. Cette procédure permet d’assurer qu’au moins le noyau du système d’exploitation et de manière plus générale que les premiers exécutables du code binaire sont bien intègres. Lors du chargement en RAM ou aussitôt après, on effectue en 220, un premier calcul, dans l’environnement sécurisé, d’un code d’authentification de référence pour chaque page mémoire de texte relative à un processus du code binaire et on stocke ledit code d’authentification de référence dans la table d’intégrité des pages (PIT). Plus précisément, ledit code d’authentification de référence est stocké en relation avec l’index de la page en question et l’identifiant du processus auquel cette dernière appartient. Le cas échéant, un code d’authentification peut également être stocké pour chaque page de mémoire de données relative à des données globales, autrement dit contenant des variables globales et/ou des constantes. A l’issue de l’étape 220, la table PIT contient les codes d’intégrité des différents processus présents dans le code binaire chargé en RAM. On entre ensuite dans une boucle itérative permettant de vérifier périodiquement l’intégrité des pages mémoire de texte relatives aux processus permanents. Il convient de noter que plusieurs boucles itératives peuvent être prévues en parallèle avec des fréquences différentes, selon le degré de criticité des processus à contrôler. Alternativement, une seule boucle itérative pourra être prévue de fréquence élevée, l’intégrité des pages mémoire d’un processus étant alors contrôlée une fois sur N, N étant un facteur de décimation fonction du degré de criticité du processus en question. Par souci de simplification, une seule boucle de contrôle d’intégrité a été représentée. Celle-ci comprend tout d’abord une étape 230 pendant laquelle un second calcul de code d’authentification est effectué pour chaque page mémoire de texte relatif à un processus permanent, donc en cours d’exécution. Le calcul est effectué dans l’environnement sécurisé, le cas échéant sur des pages stockées dans une mémoire cache de cet environnement le temps du calcul du code d’authentification. Ensuite, à l’étape 240, le code d’authentification de chaque page (indexée par ) d’un processus (identifié par ), calculé à l’étape 230, est comparé à son code d’authentification de référence , stocké dans la table PIT. En cas de différence entre le code d’authentification et le code d’authentification de référence d’une page mémoire, une alerte est générée en 290. En revanche, dans le cas où les codes d’authentification sont égaux aux codes d’intégrité de la table PIT, le contrôle périodique retourne à l’étape 230. En sus de ce processus de contrôle d’intégrité périodique et systématique, un contrôle d’intégrité peut être lancé dynamiquement parce qu’un nouveau code binaire (par exemple un code d’une application utilisateur) est chargé en mémoire ou bien simplement parce qu’un nouveau processus est appelé (processus non permanent). On a représenté ce contrôle d’intégrité lancé dynamiquement, en parallèle avec le contrôle d’intégrité périodique. A l’étape 250, postérieure au boot, un nouveau code binaire est chargé en mémoire. A l’étape 260, dès que le nouveau code binaire est chargé en mémoire, on effectue, dans l’environnement sécurisé, un premier calcul d’un code d’authentification de référence pour chaque page mémoire de texte relative à un processus du code en question. Ce code d’authentification de référence (ou code d’intégrité) est stocké comme précédemment dans la table PIT, en relation avec l’index de la page en question et l’identifiant du processus auquel cette dernière appartient. Deux options sont possibles à ce stade, soit par le biais de la passerelle 265 (le ou les processus du nouveau code binaire étant alors inscrits à un contrôle périodique), auquel cas le contrôle d’intégrité des pages mémoire correspondantes se poursuit dans la première boucle comme pour les processus permanents, soit par le biais d’une étape d’attente 267, auquel cas le contrôle d’intégrité se poursuit sur requête d’un autre processus ou à l’expiration d’un timer. A l’étape 270, sur déclenchement d’un contrôle d’intégrité, les pages mémoire de texte du code binaire ayant été chargé dynamiquement, font l’objet d’un second calcul de code d’authentification. A l’étape 280, les codes d’authentification des pages en question sont comparés avec leurs codes d’intégrité correspondants. En cas de discordance, une alerte est générée en 290. En revanche, lorsqu’il y a identité, le processus de contrôle retourne à l’étape d’attente 267 pour attendre un nouveau déclenchement. Dans le cas où le contrôle d’intégrité est lancé dynamiquement après le boot, pour être effectué de manière périodique ou déclenchée, le contrôle d’intégrité pourra être délégué à un processus permanent dont l’intégrité est contrôlée périodiquement depuis le boot avec une fréquence élevée. Dans ce cas, on propage la confiance dans l’intégrité du code binaire depuis une racine installée lors du boot. Méthode de vérification de l’intégrité d’un code binaire, ledit code binaire comprenant une pluralité de processus destinés à être exécutés par un processeur après lancement d’un système d’exploitation, un espace de mémoire virtuelle alloué au dit code binaire étant divisé en une partie de texte, une partie de données et une pile d’exécution, lesdites parties de texte, de données et ladite pile d’exécution étant stockées dans une RAM sous forme de pages mémoire dites respectivement pages mémoire de texte, pages mémoire de données et pages mémoire de pile, ladite méthode de vérification faisant suite à une procédure de lancement sécurisée assurant qu’au moins l’image du noyau du système d’exploitation est intègre lors de son chargement dans la RAM, ladite méthode de vérification étant caractérisée en ce qu’elle comprend : a) un premier calcul (220, 260), dans une zone sécurisée, d’un code d’authentification de référence pour chaque page mémoire de texte relative à un processus, dès que celle-ci a été chargée dans la RAM, ledit code d’authentification de référence étant stocké en relation avec un index de cette page et un identifiant de ce processus dans une table, dite table d’intégrité de pages ; b) un second calcul (230,270), dans ladite zone sécurisée, d’un code d’authentification pour chaque page mémoire de texte stockée dans la RAM relative à un processus en cours d’exécution, le code d’authentification d’une page étant comparé (240, 280) à son code d’authentification de référence, lu dans la table d’intégrité de pages à partir de son index de page et son identifiant de processus ; c) la génération (290) d’une alerte dans le cas où le code d’authentification d’une page diffère de son code d’authentification de référence. Méthode de vérification de l’intégrité d’un code binaire selon la revendication 1, caractérisée en ce que ladite pluralité de processus comprend des processus exécutés en permanence par le processeur, dits processus permanents, l’étape (b) étant effectuée périodiquement pour les pages mémoire de texte relatives à ces processus. Méthode de vérification de l’intégrité d’un code binaire selon la revendication 2, caractérisée en ce que la période avec laquelle l’étape (b) est effectuée pour un processus permanent est fonction du degré de criticité de ce processus, ladite période étant choisie d’autant plus courte que ledit processus permanent est plus critique. Méthode de vérification de l’intégrité d’un code binaire selon la revendication 2, caractérisée en ce que les processus permanents comprennent le chargeur et l’ordonnanceur du système d’exploitation. Méthode de vérification de l’intégrité d’un code binaire selon la revendication 1, caractérisée en ce que ladite pluralité de processus comprend des processus dont le code binaire est chargé dynamiquement en mémoire pour être exécuté, dits processus non permanents, l’étape (b) étant effectuée à la demande lorsqu’un autre processus le requiert ou lorsqu’un timer arrive à expiration. Méthode de vérification de l’intégrité d’un code binaire selon l’une des revendications précédentes, caractérisée en ce que le code d’authentification d’une page de mémoire de texte est calculé au moyen d’une fonction de hachage. Méthode de vérification de l’intégrité d’un code binaire selon l’une des revendications 1 à 5, caractérisée en ce que le code d’authentification d’une page de mémoire de texte est calculé comme un code d’authentification de message à partir du contenu de cette page et d’un flux de clé dérivé d’une clé de chiffrement symétrique. Méthode de vérification de l’intégrité d’un code binaire selon la revendication 7, caractérisée en ce qu’une nouvelle clé de chiffrement symétrique est générée à chaque boot. Méthode de vérification de l’intégrité d’un code binaire selon la revendication 7, caractérisée en ce que le flux de clé est généré à partir de la clé de chiffrement symétrique au moyen d’un l’algorithme de chiffrement léger de type Trivium ou Grain-128a. Méthode de vérification de l’intégrité d’un code binaire selon l’une des revendications précédentes, caractérisée en ce que les codes d’authentification de référence sont enregistrés dans une table stockée dans une mémoire de la zone sécurisée, ladite table comprenant pour chaque page mémoire de texte d’un processus, l’identifiant du processus dont elle dépend, un index de page mémoire et le code d’authentification de référence de ladite page.