Brevet FR2849233A1 — publié le 20040625

La présente invention concerne la sécurisation des systèmes informatiques par confinement logique de données. Elle a plus particulièrement pour objet la sécurisation des systèmes informatiques offrant la possibilité d'exécution de codes manipulant des 15 données qui doivent être traitées séparément Cette séparation est généralement dictée par des besoins de sécurité A titre d'exemple, les données du système d'exploitation qui conditionnent le bon fonctionnement de la plate-forme ne doivent pas pouvoir être modifiées par une application quelconque De même, dans les systèmes permettant l'exécution 20 d'applications multiples, les données d'une application doivent généralement être protégées des autres applications. Ces besoins prennent dans certains cas un caractère critique; on peut penser par exemple, et de manière non limitative, aux systèmes embarqués multi25 applicatifs du type cartes à puce, terminaux de paiement, assistants digitaux, ou téléphones portatifs, surtout lorsque ces systèmes embarqués permettent le télé-chargement d'applications En effet, ces applications téléchargées peuvent provenir de sites multiples, qui offrent des garanties de confiance très variées. -2 D'une façon générale, on sait que la plupart des solutions généralement adoptées pour répondre à ce besoin de séparation desdites données de systèmes d'exploitation et d'applications repose sur l'utilisation de mécanismes proposés par le matériel Typiquement, des unités (physiques) 5 de gestion de mémoire ("MMU, ou Memory Management Unit") associent des espaces physiques à des applications et les protègent contre des accès provenant d'autres applications Cependant, cette solution, quand elle est disponible, n'est pas très souple et s'associe difficilement aux systèmes d'allocation dynamique de données (le nombre d'espaces physiques étant 10 fixe), spécialement dans le cas des systèmes embarqués disposant de peu de ressources et soumis à de fortes contraintes de sécurité. La présente invention a donc plus particulièrement pour but de palier à ces inconvénients. Elle propose, à cet effet, de rendre plus flexible la sécurisation des données et de l'étendre au cas d'allocation dynamique de mémoire. Elle fait essentiellement intervenir au moins un gestionnaire de mémoire gérant des unités d'allocation mémoire qui peuvent être typiquement une page de taille fixe ou un bloc de taille variable, au moins des possesseurs et des demandeurs d'allocation mémoire pouvant être typiquement des applications de l'utilisateur du système 25 d'exploitation du système informatique ou le système d'exploitation luimême. Selon l'invention, le procédé de sécurisation d'un système informatique par confinement logique de données comprend la séparation desdites données 30 par possesseur et leur chiffrement avec une clé dédiée; ce processus de -3 séparation et de chiffrement s'effectue grâce à un mode opératoire comprenant les étapes suivantes: une allocation de mémoire réalisée par un gestionnaire de mémoire à la demande d'un autre composant du système d'exploitation qui transmet 5 audit gestionnaire de mémoire l'identité du demandeur Ce demandeur deviendra le possesseur de la mémoire allouée La transmission de l'identité du demandeur peut se faire soit par la gestion d'un contexte courant, soit par le passage de paramètres aux fonctions du gestionnaire de mémoire; un contrôle par le susdit gestionnaire de mémoire de l'ensemble des unités d'allocation mémoire, chacune étant associée à un possesseur de l'unité d'allocation mémoire Chaque unité d'allocation mémoire ne peut avoir qu'un et un seul possesseur; néanmoins plusieurs unités d'allocation mémoire peuvent avoir le même possesseur; une utilisation par le gestionnaire de mémoire d'un secret associé à chaque possesseur Ce secret peut typiquement être fourni au gestionnaire de mémoire par le système d'exploitation au moment de l'introduction du possesseur dans le système ou à chaque accès à une unité d'allocation mémoire; une utilisation par le gestionnaire de mémoire d'une clé pour chaque possesseur Cette clé peut par exemple être dérivée d'un secret associé au possesseur et une clé dite "maître" à laquelle seul le gestionnaire de mémoire a accès; une vérification par le gestionnaire de mémoire, pour chaque demande 25 d'accès à une unité d'allocation mémoire, de l'identité du demandeur; si cette identité n'est pas identique à celle du possesseur de ladite unité d'allocation mémoire, alors l'accès à l'unité d'allocation mémoire est refusé par le gestionnaire de mémoire; une réalisation par le gestionnaire de mémoire du chiffrement (dans le cas 30 d'une demande d'écriture) ou du déchiffrement (dans le cas d'une demande -4 de lecture) des données concernées avec la clé associée au possesseur, cette clé pouvant être recalculée par le gestionnaire de mémoire. Ainsi, les données des différents possesseurs étant chiffrées de manière 5 automatique, par un secret que seul le gestionnaire de mémoire connaît, il est impossible pour une application d'avoir accès aux données d'un autre possesseur. Deux situations peuvent se présenter lorsqu'un tiers tente d'accéder à une 10 unité d'allocation mémoire qui ne lui appartient pas: cette tentative peut être déclenchée par l'intermédiaire du gestionnaire de mémoire: dans ce cas, le contrôle effectué par le gestionnaire de mémoire conduit automatiquement au rejet de la demande; cette tentative peut être déclenchée de manière illicite, sans passer par 15 l'intermédiaire du gestionnaire de mémoire, par accès direct à la mémoire physique, dans le cas o les vérifications effectuées par le matériel ne suffisent pas à écarter cette possibilité : le tiers pourra alors effectuer une lecture, mais, ne disposant pas de la clé de déchiffrement, il obtiendra des données inutilisables. A partir du moment o la clé maître est mémorisée dans une zone protégée, la confidentialité des données est donc préservée dans les deux cas. Avantageusement, le procédé selon l'invention ne dépend pas du fait que 25 l'unité d'allocation mémoire soit une page logique de taille fixe ou un bloc de taille variable Dans le cas o l'unité d'allocation est la page, le procédé se raffinera de la façon suivante: lorsque le gestionnaire de mémoire reçoit une demande d'allocation d'un bloc pour le compte d'un possesseur, il recherche d'abord une page ayant le même possesseur; ainsi, tous les blocs alloués par 30 un possesseur d'unité d'allocation mémoire se trouvent regroupés dans une ou plusieurs pages dédiées. Le procédé selon l'invention pourra être amélioré de plusieurs manières (non exclusives): Au lieu d'associer une clé unique à un possesseur donné, le gestionnaire de mémoire peut associer une clé à chaque ensemble possesseur et unité d'allocation mémoire Cette amélioration a deux avantages: d'une part, elle réduit les probabilités de découverte des clés utilisées (en cas d'attaque cryptographique) puisque chaque clé sera utilisée moins 10 souvent; d'autre part, elle réduit les risques en cas de découverte d'une clé puisque seule l'unité d'allocation mémoire associée sera mise en danger. Le gestionnaire de mémoire peut également intégrer dans chaque unité de mémoire une zone permettant d'en vérifier l'intégrité, par exemple à partir 15 d'un simple "checksum" (somme des contrôles) signé ou d'un algorithme cryptographique La donnée contenue dans cette zone est mise à jour par le gestionnaire de mémoire à chaque accès en écriture à l'unité Elle peut être utilisée par le gestionnaire de mémoire à des fins de vérification, soit systématiquement à chaque accès à l'unité, soit de façon périodique La 20 vérification consiste simplement, avant l'accès demandé, à recalculer la donnée d'intégrité à partir du contenu de l'unité (données en clair) et à la comparer à la donnée contenue dans la zone d'intégrité Une modification intempestive ou illicite du contenu de l'unité pourra alors être détectée, ce qui renforcera la sécurité de la gestion des données. 25 L'association de différents niveaux de sécurité aux applications et l'utilisation de moyens de chiffrement différents (typiquement algorithmes, longueurs de clés) selon le niveau de sécurité associé permettent de proportionner le cot de mise en oeuvre (temps d'exécution 30 notamment) à l'objectif recherché en matière de sécurité. 6 A titre d'exemple non limitatif, il pourra être justifié de réserver les moyens cryptographiques les plus puissants (et les plus coteux) pour la protection d'une unité de mémoire destinée à recevoir des clefs de chiffrement ou des droits d'accès. La combinaison du procédé selon l'invention à un mécanisme de protection physique (MMU) permet une protection à granularité plus fine. Par exemple, les applications peuvent être regroupées en plusieurs grandes catégories (éventuellement, et de manière non limitative, selon le niveau 10 de confiance qu'on peut leur accorder, la première distinction naturelle pouvant être entre applications des utilisateurs et applications du système d'exploitation), chaque catégorie étant protégée des autres par le mécanisme physique et les applications étant protégées entre elles par le procédé de confinement logiciel selon l'invention. -7 REVENDICATIONS 1 Procédé de sécurisation par confinement logiciel d'un système informatique qui exécute des codes manipulant des données, faisant intervenir: au moins un gestionnaire de mémoire gérant des unités d'allocation mémoire qui peuvent être typiquement une page de taille fixe ou un bloc de taille variable, au moins des possesseurs et des demandeurs d'unités d'allocation 10 mémoire pouvant être typiquement une application de l'utilisateur du système d'exploitation du système informatique ou le système d'exploitation lui-même, caractérisé en ce qu'il comprend une séparation des données par possesseur d'au moins une unité d'allocation mémoire et le chiffrement desdites 15 données avec une clé dédiée. 2 Procédé selon la revendication 1, caractérisé en ce qu'il comprend les étapes suivantes: une allocation de mémoire réalisée par le gestionnaire de mémoire à la 20 demande d'un autre composant du système d'exploitation qui transmet audit gestionnaire de mémoire l'identité du demandeur; un contrôle par le susdit gestionnaire de mémoire de l'ensemble des unités d'allocation, chacune étant associée à un possesseur de l'unité d'allocation mémoire; une utilisation par le gestionnaire de mémoire d'un secret associé à chaque possesseur; une utilisation par le gestionnaire de mémoire d'une clé pour chaque possesseur; une vérification par le gestionnaire de mémoire, pour chaque demande 30 d'accès à une unité d'allocation mémoire, de l'identité du demandeur; si cette identité n'est pas identique à celle du possesseur de ladite unité d'allocation mémoire, alors l'accès à l'unité d'allocation mémoire est refusé par le gestionnaire de mémoire; une réalisation par le gestionnaire de mémoire du chiffrement (dans le cas d'une demande d'écriture) ou du déchiffrement (dans le cas d'une demande 5 de lecture) des données concernées avec la clé associée au possesseur, cette clé étant au moins recalculée par le gestionnaire de mémoire. 3 Procédé selon la revendication 2, caractérisé en ce que l'unité d'allocation est la page, et que le gestionnaire de mémoire, lorsqu'il reçoit 10 une demande d'allocation d'un bloc pour le compte d'un possesseur d'unité d'allocation mémoire, recherche d'abord une page ayant le même possesseur de façon à ce que tous les blocs alloués par ledit possesseur se trouvent regroupés dans une ou plusieurs pages dédiées. 4 Procédé selon la revendication 2, caractérisé en ce que la transmission de l'identité du demandeur se fait soit par la gestion d'un contexte courant, soit par le passage de paramètres aux fonctions du gestionnaire de mémoire. 5 Procédé selon la revendication 2, caractérisé en ce que le gestionnaire de mémoire calcul dynamiquement la clé d'un possesseur à partir du secret associé audit possesseur et d'une clé dite "maître" à laquelle seule le gestionnaire de mémoire a accès. 6 Procédé selon la revendication 1, caractérisé en ce que le gestionnaire de mémoire associe une clé à chaque ensemble possesseur et unité d'allocation mémoire au lieu d'associer une clé unique à chaque possesseur. -9 7 Procédé selon la revendication 1, caractérisé en ce que le gestionnaire de mémoire intègre dans chaque unité d'allocation mémoire une zone permettant d'en vérifier l'intégrité. 8 Procédé selon la revendication 1, caractérisé en ce qu'il associe différents niveaux de sécurité aux applications et utilise des moyens de chiffrement différents selon le niveau de sécurité associé. 9 Procédé selon la revendication 1, caractérisé en ce qu'il est combiné 10 à un mécanisme de protection physique. Procédé selon la revendication 1, caractérisé en ce qu'il est implémenté sur un système embarqué tel un terminal du type téléphone portatif, un terminal de paiement bancaire, un terminal de paiement portatif, 15 un assistant digital ou "PDA", une carte à puce.