FR2833374A1 - Procede et dispositif de controle d'acces dans un systeme embarque - Google Patents
Procede et dispositif de controle d'acces dans un systeme embarque Download PDFInfo
- Publication number
- FR2833374A1 FR2833374A1 FR0116054A FR0116054A FR2833374A1 FR 2833374 A1 FR2833374 A1 FR 2833374A1 FR 0116054 A FR0116054 A FR 0116054A FR 0116054 A FR0116054 A FR 0116054A FR 2833374 A1 FR2833374 A1 FR 2833374A1
- Authority
- FR
- France
- Prior art keywords
- subject
- attribute
- space
- access
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
- G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
- G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
- G06F12/1483—Protection against unauthorised use of memory or access to memory by checking the subject access rights using an access-table, e.g. matrix or list
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
- Selective Calling Equipment (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
La présente invention concerne un procédé de contrôle d'accès à des objets (5) contenus dans un espace mémoire d'un système informatique par un sujet (3) contenu dans un espace programme dudit système. Le sujet souhaite effectuer une opération sur lesdits objets (5). Le procédé selon la présente invention contrôle l'accès auxdits objets (5) à partir d'un attribut (8) dynamique lié audit sujet (3) dont la valeur est mise à jour suivant le ou les états présent et antérieurs du sujet. La présente invention concerne également le dispositif de contrôle d'accès mettant en oeuvre le procédé décrit ci-dessus.
Description
<Desc/Clms Page number 1>
PROCEDE ET DISPOSITIF DE CONTROLE D'ACCES DANS UN
SYSTEME EMBARQUE
La présente invention concerne un procédé et un dispositif de contrôle d'accès à des zones de mémoire attachées à des applications et des modules logiciels d'une unité électronique à microprocesseur, notamment d'un microcontrôleur. L'invention est applicable par exemple et sans caractère limitatif aux cartes à puces électroniques.
SYSTEME EMBARQUE
La présente invention concerne un procédé et un dispositif de contrôle d'accès à des zones de mémoire attachées à des applications et des modules logiciels d'une unité électronique à microprocesseur, notamment d'un microcontrôleur. L'invention est applicable par exemple et sans caractère limitatif aux cartes à puces électroniques.
DOMAINE TECHNIQUE
La carte à puce comme tout système informatique embarqué comprend un processeur, des entrées/sorties et de la mémoire qui se décompose en mémoire non volatile généralement utilisée pour le stockage des programmes et des données et en mémoire volatile généralement utilisée comme mémoire de traitement. Les systèmes embarqués ou objets portatifs et notamment les cartes à puce tendent à remplir des fonctions de plus en plus complexes, en raison, notamment, de l'implantation de programmes à applications multiples : ces cartes à puce sont désignées par le terme carte à puce multi-applications .
La carte à puce comme tout système informatique embarqué comprend un processeur, des entrées/sorties et de la mémoire qui se décompose en mémoire non volatile généralement utilisée pour le stockage des programmes et des données et en mémoire volatile généralement utilisée comme mémoire de traitement. Les systèmes embarqués ou objets portatifs et notamment les cartes à puce tendent à remplir des fonctions de plus en plus complexes, en raison, notamment, de l'implantation de programmes à applications multiples : ces cartes à puce sont désignées par le terme carte à puce multi-applications .
En matière de sécurité des cartes à puce multi-applications, l'isolement des applications les unes par rapport aux autres joue un rôle essentiel. Ainsi dans une carte à puce contenant plusieurs applications, il est important de pouvoir interdire aux applications d'accéder à des données qui ne leur appartiennent pas afin d'échapper à un usage malveillant ou à une transmission d'informations vers l'extérieur. Par exemple, on peut vouloir refuser à une première application d'accéder à des données confidentielles appartenant à une deuxième application telles que des clés cryptographiques. En particulier, les données étant stockées de façon persistante en mémoire non volatile, on veut pouvoir en restreindre la lecture ou la mise à jour aux seules applications autorisées.
<Desc/Clms Page number 2>
Par ailleurs, l'augmentation de la capacité mémoire et de la puissance de traitement des cartes à puce conduit à la réalisation d'une architecture logicielle plus structurée, dans laquelle les fonctions sont isolées les unes des autres en modules et se répartissent sur différents niveaux.
Ainsi, par exemple, dans une architecture logicielle pour carte à puce, on distingue, comme le montre la figure 1, le niveau noyau CORE en interface directe avec le matériel (et comportant notamment les routines génériques d'accès à la mémoire non volatile), le niveau système OS concernant le système d'exploitation qui gère les ressources et les services communs et le niveau applications APPLI qui regroupe les diverses applications logicielles. Chacun de ces niveaux peut se subdiviser en sousniveaux et en modules fonctionnels : le niveau système comprend par exemple des modules fonctionnels tels que le service de traitement des algorithmes cryptographiques, la gestion de la ressource mémoire et celle des entrées/sorties.
Dans un tel modèle, une application n'accède plus directement à ses données en mémoire mais par l'intermédiaire de fonctions situées aux niveaux noyau et système. C'est dans ce contexte d'accès indirects notamment que se pose le problème de la restriction d'accès à des données stockées aux seules applications autorisées.
De façon plus générale, on peut concevoir une architecture logicielle modulaire multi-niveaux dans laquelle d'une part un module fait appel à un ou d'autres modules pour exécuter une partie de ses tâches et d'autre part chaque module possède un programme et des données stockées en mémoire non volatile dans des zones bien définies, données dont on veut limiter la manipulation ou l'utilisation aux seuls modules autorisés.
<Desc/Clms Page number 3>
TECHNIQUE ANTERIEURE
De façon générale, des mécanismes logiciels de protection mémoire peuvent être réalisés dans le cas d'applications interprétées et/ou matériel sous la forme de fenêtres ouvertes sur la mémoire (tel qu'un dispositif de segmentation) ou sous la forme de matrices d'accès semistatiques. L'association d'applications à des zones mémoire se fait soit à la configuration soit lors de la sélection d'une application. De tels mécanismes n'autorisent l'accès en mémoire que pour des couples prédéterminés code/ zone de données.
De façon générale, des mécanismes logiciels de protection mémoire peuvent être réalisés dans le cas d'applications interprétées et/ou matériel sous la forme de fenêtres ouvertes sur la mémoire (tel qu'un dispositif de segmentation) ou sous la forme de matrices d'accès semistatiques. L'association d'applications à des zones mémoire se fait soit à la configuration soit lors de la sélection d'une application. De tels mécanismes n'autorisent l'accès en mémoire que pour des couples prédéterminés code/ zone de données.
Ainsi par exemple dans le cas d'une matrice d'accès, l'association de pages mémoires à des applications se fait au moment de la configuration de la carte par programmation des attributs de page ; le rôle du matériel au moment de l'exécution se limite à une simple comparaison entre l'identité du propriétaire de la page et l'identité du module qui cherche à accéder à cette page (connue par le matériel, par exemple par la position du compteur ordinal). L'inconvénient des mécanismes à matrice d'accès réside dans le fait qu'ils imposent une relation directe entre programme et données : cette relation existe tant que le propriétaire de la page accède directement à ses données (par les instructions lecture/ écriture du microprocesseur), mais elle disparaît dans les configurations où un autre module que le propriétaire veut accéder aux données en son nom)). Deux exemples illustrant cette situation sont (i) une machine virtuelle qui accède aux données des applications en leur nom et (ii) un module gestionnaire EEPROM interposé entre l'application et la mémoire non-volatile. Ces accès à relation indirecte ne peuvent être protégés par les dispositifs de type matrice d'accès.
L'invention vise à pallier les inconvénients des dispositifs et systèmes de l'art connu tout en satisfaisant aux besoins qui se font sentir.
<Desc/Clms Page number 4>
Dans le cadre d'une architecture logicielle modulaire multi-niveaux d'un système informatique et plus particulièrement dans la description qui suit d'un système embarqué tel qu'une carte à puce, l'invention a donc pour but de proposer un procédé permettant d'isoler et protéger les zones de mémoire attachées auxdits modules.
Toujours dans ce même cadre, l'invention a pour but de proposer un procédé permettant de contrôler l'accès à la mémoire et d'en restreindre l'accès aux seuls modules autorisés.
RESUME DE L'INVENTION
La présente invention concerne un procédé de contrôle d'accès à des objets contenus dans un espace mémoire d'un système informatique par un sujet contenu dans un espace programme dudit système, ledit sujet souhaitant effectuer une opération sur lesdits objets, caractérisé en ce qu'il contrôle l'accès auxdits objets à partir d'un attribut dynamique lié audit sujet dont la valeur est mise à jour suivant le ou les états présent et antérieurs du sujet.
La présente invention concerne un procédé de contrôle d'accès à des objets contenus dans un espace mémoire d'un système informatique par un sujet contenu dans un espace programme dudit système, ledit sujet souhaitant effectuer une opération sur lesdits objets, caractérisé en ce qu'il contrôle l'accès auxdits objets à partir d'un attribut dynamique lié audit sujet dont la valeur est mise à jour suivant le ou les états présent et antérieurs du sujet.
La présente invention se rapporte également à un dispositif de contrôle d'accès mettant en oeuvre le procédé décrit ci-dessus ainsi qu'au système embarqué utilisant un tel dispositif. Elle concerne également le programme mettant en oeuvre ledit procédé.
DESCRIPTION SOMMAIRE DES DESSINS
L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : la figure 1 illustre schématiquement une architecture logicielle modulaire multi-niveaux d'un système informatique ;
L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : la figure 1 illustre schématiquement une architecture logicielle modulaire multi-niveaux d'un système informatique ;
<Desc/Clms Page number 5>
. la figure 2 est un organigramme illustrant les principales étapes d'une forme de réalisation du procédé de contrôle d'accès selon la présente invention ; ' la figure 3 représente schématiquement un exemple d'enchaînement de modules et de zones mémoires auxquels souhaitent accéder lesdits modules ; 'ta figure 4 est un schéma représentant un exemple d'enchaînement de modules et de zones mémoires auxquels ont le droit d'accéder lesdits modules ; ') la figure 5 est un organigramme illustrant des étapes du procédé de contrôle d'accès selon la figure 2 selon deux variantes de réalisation l'une en trait plein et l'autre en trait plein et pointillé ; * la figure 6 illustre un système selon la figure 1 dans lequel le procédé de contrôle d'accès est mis en évidence.
MEILLEURE MANIERE DE REALISE L'INVENTION
Dans un système 1 informatique à architecture logicielle modulaire multi-niveaux tel qu'illustré par la figure 1, un module 2, a, ss, remplit une tâche spécifiée soit à la demande de l'extérieur à partir d'un jeu de commande d'entrée/sortie, soit à la demande d'un autre module, soit à la suite d'un événement matériel. Un module susceptible d'exécuter une tâche à la demande de l'extérieur est appelé ci-après une application. La réalisation de ladite tâche correspond à l'exécution d'une suite d'instructions appelée programme (A, B), stocké en mémoire non volatile dans un espace, appelé espace PROG (espace de programme) propre audit module. La suite d'instructions s'applique à un ensemble de données stockées en mémoire non volatile dans un autre espace, appelé espace DATA (espace de données), respectivement les espaces a et b pour les programmes A et B. Les espaces de données a et b consistent en des espaces pour lesquels lesdits modules a et ss possèdent des droits d'accès.
Dans un système 1 informatique à architecture logicielle modulaire multi-niveaux tel qu'illustré par la figure 1, un module 2, a, ss, remplit une tâche spécifiée soit à la demande de l'extérieur à partir d'un jeu de commande d'entrée/sortie, soit à la demande d'un autre module, soit à la suite d'un événement matériel. Un module susceptible d'exécuter une tâche à la demande de l'extérieur est appelé ci-après une application. La réalisation de ladite tâche correspond à l'exécution d'une suite d'instructions appelée programme (A, B), stocké en mémoire non volatile dans un espace, appelé espace PROG (espace de programme) propre audit module. La suite d'instructions s'applique à un ensemble de données stockées en mémoire non volatile dans un autre espace, appelé espace DATA (espace de données), respectivement les espaces a et b pour les programmes A et B. Les espaces de données a et b consistent en des espaces pour lesquels lesdits modules a et ss possèdent des droits d'accès.
A titre illustratif, sur la figure 1, l'activation du module a correspond à
<Desc/Clms Page number 6>
l'exécution du programme A stocké dans l'espace de programme PROG ; ledit programme A s'applique aux données stockées dans l'espace de données a. Si le module a bénéficie d'un droit octroyé par le module ss, son programme accède à l'espace de données b du module B (flèche en pointillés sur la figure 1).
Un module peut faire appel dans l'exécution de sa tâche à d'autres modules. De ce fait, les programmes s'enchaînent, le module appelé succédant au module appelant.
Dans le cadre du système 1 décrit ci-dessus, le procédé selon l'invention consiste non seulement à assurer l'isolation entre les diverses applications logicielles mais aussi entre tous les modules du système (quelque soit son niveau) : le procédé doit assurer qu'un module du niveau applicatif ne puisse pas avoir accès à des données sur lesquels il n'a aucun droit par le biais d'appels à des modules des niveaux inférieurs. Ainsi, le procédé selon l'invention doit restreindre l'accès des espaces mémoire aux seuls modules 2 autorisés.
La notion de contrôle d'accès est représentée sur la figure 2 : un contrôle d'accès accepte ou rejette une opération menée par une entité 3 active dite sujet S stockée dans l'espace PROG (par exemple un processus de traitement) s'exécutant au nom d'un utilisateur 4, sur des entités 5 passives dites objets (0)) de l'espace mémoire DATA (par exemple un conteneur de données stockées) ou PROG en fonction de règles 6 caractérisant la politique appliquée, d'attributs 7,8 de sécurité associés d'une part à l'objet 5 visé et d'autre part au sujet 3 s'exécutant pour un utilisateur 4 et du type d'opération. Le sujet est constitué d'un ou plusieurs modules 2 qui s'enchaînent pour effectuer une opération déterminée.
Un logiciel embarqué comme celui par exemple des cartes à puce multi-applications peut être décrit comme un sujet 3 qui d'une part
<Desc/Clms Page number 7>
s'exécute pour des utilisateurs 4 extérieurs s'adressant aux différentes applications et d'autre part mène des opérations du type accès en mémoire non volatile.
Dans le cadre de cette architecture modulaire de logiciel embarqué, l'invention propose un procédé et un dispositif de contrôle d'accès aux objets 5 caractérisé en ce qu'il est basé sur des attributs 8 dynamiques liés au sujet 3, dont la valeur dépend de l'histoire du sujet, à savoir de ses états présent et passés. Le procédé restreint l'accès aux objets aux seuls modules 2 autorisés même lorsque ces accès sont indirects, c'est à dire s'effectuant par l'intermédiaire de un ou plusieurs autres modules.
Le procédé comprend les étapes suivantes : 'une étape de gestion 9 de l'attribut 8 du sujet, en fonction de l'état présent et des états passés du sujet 3 ; a une étape de comparaison d'une information caractérisant l'objet visé qui est l'attribut 7 de l'objet et d'une information caractérisant l'état présent et les états passés du sujet qui est l'attribut 8 du sujet ; e une étape de filtrage permettant d'accepter ou de rejeter l'opération en fonction de la dite comparaison, et de manière optionnelle du type de l'opération et/ou de règles 6 prédéfinies.
Dans la description qui suit, le procédé selon l'invention sera décrit en détail dans son application à l'espace de données DATA, à savoir que l'objet visé fait partie dudit espace DATA. Pour faciliter la compréhension du procédé selon l'invention, l'étape de gestion sera décrite après celle de comparaison et de filtrage.
L'étape de comparaison consiste plus précisément à comparer une information caractérisant la zone mémoire visée à savoir plus précisément l'espace de données visé (appelé espace visé) et une information
<Desc/Clms Page number 8>
caractérisant l'espace de données associé à l'état présent et passé du programme en cours (appelé espace autorisé).
L'espace visé est identifié par un attribut 7. Selon une première variante de réalisation, l'attribut 7 est une information associée à l'opération. Selon une deuxième variante, l'attribut 7 est une information physiquement associée à la zone de mémoire visée (forme de réalisation de la figure 2). L'espace autorisé est caractérisé par un attribut 8 de même type que celui utilisé pour l'espace visé, afin de faciliter la comparaison.
Dans la première variante de réalisation, l'attribut est une adresse mémoire selon le modèle connu MMU (Memory Management Unit : Unité de Gestion de la Mémoire) ; l'opération en cours spécifie une adresse mémoire à laquelle souhaite accéder le sujet 3. La comparaison consiste alors à vérifier que l'adresse 7 en question est contenue dans une fenêtre 8 d'adresses, la fenêtre d'adresses correspondant à l'espace autorisé. Dans la deuxième variante de réalisation, l'opération en cours sélectionne un attribut 7 qui spécifie un identifiant. La comparaison consiste à vérifier l'identité entre l'identifiant 7 de l'espace visé et l'identifiant 8 de l'espace autorisé (modèle MAC-Mandatory Access Control).
L'étape de filtrage consiste à effectuer une action suivant le résultat de l'étape de comparaison, à savoir accepter l'opération si l'espace de données visé par l'opération (l'espace visé) et l'espace de données dont l'accès est autorisé au moment de l'opération (l'espace autorisé) correspondent, ou la rejeter dans le cas contraire. D'autres caractéristiques peuvent aussi être prises en considération tel que le type de l'opération, qui étend la qualification de l'espace visé, par exemple espace accessible en lecture seulement (Exemples de qualification possible : lecture, écriture, programmation (écriture de 1), effacement (écriture de 0), ou combinaison de ces termes, alimentation en instructions). Des règles 6 supplémentaires peuvent également être imposées. L'accès peut n'être accordé par exemple qu'à un seul ou quelques modules prédéterminés, cette restriction
<Desc/Clms Page number 9>
s'appliquant en plus du filtrage suivant le résultat de la comparaison entre l'espace visé et l'espace autorisé.
L'étape de gestion consiste en la gestion de l'information caractérisant l'espace de données autorisé associé à l'état du programme en cours : le procédé fait appel à un mécanisme 9 d'initialisation (que l'on considère dans la présente description comme une première mise à jour) et de mise à jour de l'espace autorisé. L'espace autorisé est initialisé ou réinitialisé à chaque changement d'application (changement vers l'application A sur la figure 4, les modules M1, M2, M3 n'étant pas des applications mais de simples modules activés pour traiter une tâche à la demande d'un autre module).
Ladite gestion dépend des caractéristiques fonctionnelles de l'architecture et de la politique de sécurité que l'on veut implémenter.
Dans le cadre d'une architecture modulaire de logiciel embarqué dans laquelle un module peut faire appel à un autre module pour soustraiter une tâche, le programme du module appelé s'applique à ses propres données et a également le privilège de s'appliquer aux données de l'espace de données du module appelant. Lors d'une succession d'appels inter modules, le privilège s'hérite d'un module à un autre : un même espace de données est accessible à toute une suite de modules. Un programme d'un module appelé peut donc s'appliquer en plus de son espace de données propre à l'espace de données de l'un quelconque des modules appelants antérieurs ou de plusieurs d'entre eux.
Toute manipulation ou utilisation de données est restreinte aux seuls modules autorisés : le procédé de contrôle d'accès selon l'invention autorise ou rejette des opérations sur des données stockées en mémoire non volatile en fonction de l'enchaînement des appels inter modules et des choix de chaque programme de s'appliquer transitoirement à ses données propres.
<Desc/Clms Page number 10>
Une politique de sécurité caractéristique de la carte à puce précise qu'un module ne peut utiliser, manipuler ou accéder qu'à ses données propres ou aux données correspondant à la tâche qui lui est confiée.
Comme le montre le premier exemple (Ex. 1) sur la figure 3, un module appelé (B) hérite du privilège de s'appliquer à l'espace de données de la tâche pour laquelle il est appelé, espace qui peut appartenir au module appelant (A) ou dont le module appelant (B) a hérité lui-même. Dans le premier exemple, il n'est pas nécessaire de mettre à jour l'espace autorisé car il ne change pas. Il est également possible (deuxième exemple : Ex. 2) que le module ait besoin d'accéder à ses données propres ; dans ce cas, l'espace autorisé est mis à jour à partir d'une demande (explicite ou implicite comme illustré sur la figure 5 et détaillée plus loin) de ce module.
Lorsque le module cesse d'accéder à son espace propre de données, il revient dans le contexte précédent et accède de nouveau à l'espace de données pour lequel un privilège lui a été transmis par l'appel de soustraitance ; l'espace autorisé retrouve sa valeur précédente à partir d'une demande (explicite ou implicite comme illustré sur la figure 5). Dans le deuxième exemple, le module B appelé par le module A accède aux données du module A (flèche u) et transitoirement (flèche v) à ses propres données. Le module C, appelé par le module B lui-même ayant été appelé par le module A, accède aux données du module B (flèche x) ou du module A (flèche y) et transitoirement à ses propres données (flèche w).
L'étape de mise à jour permettant d'autoriser l'enchaînement d'accès à des espaces visés tel que décrit ci-dessus est mise en oeuvre selon diverses formes de réalisation illustrées sur la figure 4.
La figure 4 représente, dans l'exemple illustré, les appels entre modules A, M1, M2, M3, les espaces visés lors des appels et l'évolution des espaces autorisés sur une période donnée (t1, t2).
<Desc/Clms Page number 11>
Selon une première forme de réalisation, l'étape de mise à jour est susceptible d'être réalisée au moyen d'une pile d'espaces autorisées (PILE ESPAUT sur la figure 4) : chaque module demande (de façon implicite ou explicite) à ce que son espace de données propre soit placé ou retiré de la pile des espaces autorisés, lorsqu'il a besoin d'y accéder. Dans la partie grisée de la figure 4 (lettre ( (0))), le module M2 demande avant l'appel du module M3 à ce que son espace propre m2 soit placé sur la pile des espaces autorisés. La pile est alors constituée des espaces suivants : a1 m2. Le module M3 peut accéder compte-tenu de la mise à jour de l'espace autorisé à l'espace m2 (ACCMEM). Le module M3 demande ensuite l'accès (lettre p) > ) à ses propres données m3 ; son espace propre m3 est placé sur la pile des espaces autorisés. La pile est alors constituée des espaces suivants : a1 m2 m3. Le dispositif de contrôle d'accès autorise une opération sur un espace de données lorsque l'espace de données visé par l'opération et l'espace de données dont l'accès est autorisé au moment de l'opération sont identiques : l'espace de données autorisé au moment de la comparaison correspond à l'espace du haut de la pile (selon le premier exemple : l'espace m2 ; selon le deuxième exemple : l'espace m3), ceux du fond de la pile (selon le premier exemple : l'espace a1 ; selon le deuxième exemple : les espaces a1 m2) étant des espaces qui ont été et qui seront de nouveau des espaces autorisés.
Il est à noter que la pile des espaces autorisés peut être très différente de la pile des modules appelants ; ainsi, par exemple, si aucun des modules appelés n'accède à des données propres, la pile des espaces autorisés se réduit à l'espace de données du premier module appelant (flèches r, s, t sur la figure 4-espace de données a1).
Selon une deuxième forme de réalisation, une politique de sécurité moins rigoureuse est mise en place. Cette politique de mise à jour est implémentée au moyen d'un mécanisme de gestion de type liste : chaque module peut demander (de façon implicite ou explicite) à ce que son
<Desc/Clms Page number 12>
espace de données propres soit placé ou retiré de la liste des espaces autorisés.
De manière simplifiée et illustrée sur la figure 4, chaque module appelé peut potentiellement accéder à son espace de donnée propre et son espace de données est ajouté à la liste (LIST ESP~AUT). La manipulation de la liste est implicite et synchronisée sur les appels de module. Dans ce cas, la liste des espaces autorisés se confond avec la liste des espaces de données associés aux modules identifiés dans la pile des modules appelants auxquels s'ajoute l'espace de données du dernier module appelé.
La contrainte est moins rigoureuse que dans le cas précédent : en effet, le mécanisme de mise à jour de la deuxième forme de réalisation autorise l'opération s'il y a accord entre l'espace visé et l'un des espaces autorisés de la liste. De cette façon, le mécanisme permet à un module appelant d'accéder à des données de l'un quelconque des modules appelés avant le contrôle d'accès.
Selon une première variante de l'étape de mise à jour illustrée sur la figure 5 en trait plein, la demande faite par un module 2 d'ajouter ou de retirer son espace 8 de données de la pile ou de la liste des espaces autorisés est explicite : elle se traduit par une ou des commandes internes (CIMJ sur la figure 5) de mise à jour du type ajouter (ou retirer) mon espace ou ajouter (ou retirer) un espace donnés.
Selon une autre variante de réalisation de l'étape de mise à jour illustrée en trait plein et pointillé sur la figure 5, la demande faite par un module 2 d'ajouter ou de retirer son espace 8 de données de la pile ou de la liste des espaces autorisés est implicite. La demande se traduit par une commande interne de mise à jour (CIMJ) provenant d'un mécanisme 11 d'interception ou de traitement préliminaire d'appel ; ledit mécanisme demande l'ajout (ou le retrait) de l'espace de données correspondant à
<Desc/Clms Page number 13>
l'espace visé par l'opération véhiculée par l'appel à un module appelé (ou le retour au module appelant).
Pour mettre à jour l'attribut du sujet en fonction de l'état du sujet, ou plus particulièrement, pour gérer l'information caractérisant l'espace de données associé à l'état du processus de traitement en cours, c'est à dire l'espace autorisé, le mécanisme de gestion doit traiter la demande de mise à jour correspondant au changement d'état du sujet comme le montre la figure 2.
La protection assurée par le contrôle d'accès dépend de la sécurité apportée dans la gestion dudit contrôle. Ainsi, de manière à renforcer la sécurité dans la gestion du contrôle d'accès, un mécanisme de gestion de la mise à jour est prévu sous la forme d'un contrôle de l'identité du sujet et de ses droits. La demande de mise à jour de l'attribut 8 du sujet n'est acceptée et prise en compte que si son émetteur, un module (en l'espèce le module actif ou le module d'interception) est identifié de manière sure et est autorisé à faire cette demande : le mécanisme de gestion de la mise à jour de l'attribut du sujet comporte un mécanisme 10 de contrôle de l'identité du demandeur de ladite mise à jour et de vérification de ses droits.
Le mécanisme 10 doit d'une part identifier le module à l'origine de la demande de mise à jour et d'autre part s'assurer que la demande est licite par vérification des droits du module sur l'espace de donnée visé. Les droits sont des données propres au module concerné et pré-enregistrées.
L'identité du module appelant s'obtient généralement par identification de l'espace programme de l'appelant. Une demande de brevet déposée le même jour par le présent demandeur et dont le titre est procédé et système d'identification sécurisée dans une architecture logicielle modulaire décrit un tel mécanisme d'identification.
<Desc/Clms Page number 14>
Si la demande est explicite du type ajouter (ou retirer) un espace donnés, te droit de l'espace programme sur l'espace de donnée en question est enregistré en mémoire, par exemple dans une table qui relie espace (s) programme (s) et espace (s) de données multiple (s) selon les droits des espaces programme sur les espaces de données. Cette solution est adaptée lorsqu'il est possible de partager des données entre plusieurs modules. Pour que deux ou plusieurs modules partagent un espace de données, il suffit qu'ils partagent le droit de provoquer la mise à jour de l'espace autorisé avec cet espace de données.
De manière particulière, si la demande est explicite du type ajouter (ou retirer) mon espace , la correspondance entre espace programme et espace de donnée doit être enregistrée en mémoire. Cette solution est adaptée lorsqu'il y a bijection entre espace programme et espace de données.
Si la demande est implicite, le droit de l'espace programme du module appelant sur l'espace de donné visé doit être enregistré en mémoire, par exemple dans une table qui relie espace (s) programme (s) et espace (s) de données multiple (s) de la même façon que précédemment ; la table ne sera consultée que dans le cas où l'espace visé est différent de l'espace autorisé existant.
Comme le montrent les figures 5 et 6, le mécanisme 9 d'initialisation et de mise à jour de l'espace autorisé selon l'invention est amorcé par une commande extérieure CE. La commande extérieure active ( ACTIV sur les figures) un des modules 2 du système 1. L'activation d'un desdits modules initialise ( Init ) l'espace autorisé à une valeur déterminée permettant l'accès du premier module appelé par ladite commande extérieure à la zone mémoire souhaitée. Lorsqu'un module fait appel à un autre module, le procédé selon l'invention décrit ci-dessus est exécuté.
<Desc/Clms Page number 15>
Le procédé selon l'invention a été décrit dans son application au contrôle d'accès à l'espace mémoire de données. Le procédé selon l'invention est applicable de la même façon au contrôle d'accès à l'espace mémoire de programme.
A titre d'exemple, il est décrit ci-après le cas d'une architecture à trois niveaux tel qu'on peut la trouver dans une carte à puce (figure 6).
Dans le cas illustré sur la figure 6, le mécanisme de comparaison et d'action est implémenté dans le matériel au niveau de l'accès mémoire (MEM). Le système d'exploitation (OS) en activant (ACTIV) les applications (APPLI) initialise l'espace autorisé. Le système d'exploitation (OS) comporte un mécanisme (11) d'interception des appels qui implicitement va signifier à la gestion (9,10) de l'espace autorisé, l'espace visé par l'appel fait au système (qui peut être différent de l'espace initialisé si une application en a appelé une autre). La gestion (9,10) de l'espace autorisé identifie l'application appelante et modifie suivant les droits de ladite application appelante l'espace autorisé en lui donnant la valeur de l'espace visé. La fonction de gestion du dispositif est hiérarchique, le noyau ayant la possibilité de modifier l'espace autorisé par surcharge (SURCH). La mise à jour ayant été effectuée, la comparaison des espaces ATTRI-S et ATTRI-O est réalisée en fonction d'une règle de comparaison donnée, du type de l'opération et de règles déterminées. L'accès requis par l'opération est accepté ou rejeté suivant le résultat de la comparaison.
Une réalisation particulière consiste à implémenter le mécanisme de comparaison et d'action dans le matériel ; dans ce cas, une façon de faire consiste à transférer le haut de la pile dans un registre matériel, une autre façon de faire consiste à implémenter toute la pile dans le matériel.
Dans des architectures assez simple ou avec peu de contrôle des droits la gestion du dispositif peut elle même être implémenté avec du matériel spécifique.
<Desc/Clms Page number 16>
Tout ou partie du système décrit ci-dessus peut être réalisé dans le matériel.
Par ailleurs, l'ensemble des modules dudit système peut se présenter sous tout autre type de forme et en particulier des modules dudit ensemble peuvent être regroupés entre eux ou divisés formant de nouveaux modules.
Le système selon l'invention est centralisé et unique ou hiérarchique avec des mécanismes de comparaison, d'action et de gestion séparés.
Claims (14)
1) Procédé de contrôle d'accès à des objets (5) contenus dans un espace mémoire d'un système informatique par un sujet (3) contenu dans un espace programme dudit système souhaitant effectuer une opération sur lesdits objets (5), caractérisé en ce qu'il contrôle l'accès auxdits objets (5) à partir d'un attribut (8) dynamique lié audit sujet (3) dont la valeur est mise à jour suivant le ou les états présent et antérieurs du sujet.
2) Procédé de contrôle d'accès selon la revendication 1, caractérisé en ce qu'il comporte les étapes suivantes : - une étape de mise à jour et de gestion de ladite mise à jour de l'attribut (8) dynamique du sujet ; - une étape de comparaison d'une information caractérisant l'objet (5) visé qui est l'attribut de l'objet et d'une information caractérisant l'état présent et passé du sujet (3) qui est ledit attribut dynamique du sujet ; - une étape d'action permettant d'accepter ou de rejeter l'accès en fonction du résultat de ladite comparaison, du type d'opération et/ou de règles prédéfinies et enregistrées.
3) Procédé selon la revendication 2, caractérisé en ce que l'attribut de l'objet est une information caractérisant la zone mémoire visée par l'opération effectuée par le sujet et l'attribut du sujet est une information caractérisant l'espace mémoire autorisé associé à l'état présent et passé du programme de traitement en cours, à savoir le sujet.
4) Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'attribut dynamique est une information du type adresse (s) mémoire.
5) Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'attribut dynamique est une information du type identifiant.
<Desc/Clms Page number 18>
6) Procédé selon l'une des revendications 1 à 5, caractérisé en ce que le mécanisme de mise à jour de l'attribut dynamique est du type pile, l'attribut dynamique utilisé pour le contrôle d'accès étant en haut de la pile.
7) Procédé selon l'une des revendications 1 à 5, caractérisé en ce que le mécanisme de mise à jour de l'attribut dynamique est du type liste, l'attribut dynamique utilisé pour le contrôle d'accès étant l'ensemble de ladite liste.
8) Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il consiste à gérer ladite mise à jour en contrôlant l'identité et les droits du module faisant partie du sujet et sollicitant la mise à jour de l'attribut (8) et de n'effectuer ladite mise à jour que si le module est autorisé à le faire.
9) Procédé selon l'une des revendications 1 à 8, caractérisé en ce qu'un module du sujet requiert explicitement la mise à jour de l'attribut (8) dynamique.
10) Procédé selon l'une des revendications 1 à 8, caractérisé en ce que la mise à jour est requise de manière implicite au moyen d'un mécanisme sous-jacent d'interception des appels.
11) Dispositif de contrôle d'accès d'un sujet (3) contenu dans un espace programme d'un système informatique comportant au moins des moyens de mémoire et des moyens de calcul, et souhaitant effectuer une opération sur des objets (5) contenus dans un espace mémoire dudit système, caractérisé en ce qu'il comprend des moyens permettant d'effectuer un contrôle d'accès auxdits objets à partir d'un attribut (8) dynamique lié audit sujet (3) et mis en mémoire dont la valeur est mise à jour suivant le ou les états présent et antérieurs du sujet.
<Desc/Clms Page number 19>
12) Dispositif selon la revendication 11, caractérisé en ce qu'il comprend : - un mécanisme de mise à jour et de gestion de la mise à jour d'un attribut dynamique du sujet fonction du ou des états présent et antérieurs du sujet ; - un mécanisme de comparaison d'une information caractérisant l'objet visé qui est l'attribut de l'objet et d'une information caractérisant l'état du sujet qui est l'attribut du sujet, lesdites informations étant contenues dans les moyens de mémoire ; - un mécanisme d'action permettant d'accepter ou de rejeter l'opération en fonction du résultat précédent, du type de l'opération et/ou de règles prédéfinies.
13) Système embarqué caractérisé en ce qu'il comprend le dispositif selon l'une des revendications 11 ou 12.
14) Programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une des revendications 1 à 10 lorsque ledit programme est exécuté dans un système informatique.
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0116054A FR2833374A1 (fr) | 2001-12-12 | 2001-12-12 | Procede et dispositif de controle d'acces dans un systeme embarque |
| AT02804648T ATE433157T1 (de) | 2001-12-12 | 2002-12-11 | Zugangssteuerverfahren und einrichtung in einem eingebetteten system |
| EP02804648A EP1456759B8 (fr) | 2001-12-12 | 2002-12-11 | Procede et dispositif de controle d'acces dans un systeme integre |
| DE60232541T DE60232541D1 (de) | 2001-12-12 | 2002-12-11 | Zugangssteuerverfahren und einrichtung in einem eingebetteten system |
| PCT/IB2002/005294 WO2003050686A1 (fr) | 2001-12-12 | 2002-12-11 | Procede et dispositif de controle d'acces dans un systeme integre |
| AU2002366692A AU2002366692A1 (en) | 2001-12-12 | 2002-12-11 | Access control method and device in an embedded system |
| US10/497,738 US7363293B2 (en) | 2001-12-12 | 2002-12-11 | Access control method and device in an embedded system |
| ES02804648T ES2331115T3 (es) | 2001-12-12 | 2002-12-11 | Procedimiento y dispositivo de control de acceso en un sistema integrado. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0116054A FR2833374A1 (fr) | 2001-12-12 | 2001-12-12 | Procede et dispositif de controle d'acces dans un systeme embarque |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2833374A1 true FR2833374A1 (fr) | 2003-06-13 |
Family
ID=8870387
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0116054A Pending FR2833374A1 (fr) | 2001-12-12 | 2001-12-12 | Procede et dispositif de controle d'acces dans un systeme embarque |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7363293B2 (fr) |
| EP (1) | EP1456759B8 (fr) |
| AT (1) | ATE433157T1 (fr) |
| AU (1) | AU2002366692A1 (fr) |
| DE (1) | DE60232541D1 (fr) |
| ES (1) | ES2331115T3 (fr) |
| FR (1) | FR2833374A1 (fr) |
| WO (1) | WO2003050686A1 (fr) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7266538B1 (en) * | 2002-03-29 | 2007-09-04 | Emc Corporation | Methods and apparatus for controlling access to data in a data storage system |
| US7526347B2 (en) * | 2003-02-18 | 2009-04-28 | Fisher-Rosemount Systems, Inc. | Security for objects in a process plant configuration system |
| US7117052B2 (en) | 2003-02-18 | 2006-10-03 | Fisher-Rosemount Systems, Inc. | Version control for objects in a process plant configuration system |
| JP2007536634A (ja) * | 2004-05-04 | 2007-12-13 | フィッシャー−ローズマウント・システムズ・インコーポレーテッド | プロセス制御システムのためのサービス指向型アーキテクチャ |
| US7729789B2 (en) | 2004-05-04 | 2010-06-01 | Fisher-Rosemount Systems, Inc. | Process plant monitoring based on multivariate statistical analysis and on-line process simulation |
| US7761924B2 (en) * | 2004-06-30 | 2010-07-20 | Microsoft Corporation | Manipulation of information embedded in content |
| US8074288B2 (en) * | 2005-07-15 | 2011-12-06 | Microsoft Corporation | Isolation of application-specific data within a user account |
| DE102006037493A1 (de) * | 2006-08-10 | 2008-02-14 | Giesecke & Devrient Gmbh | Tragbarer Datenträger |
| US8881039B2 (en) | 2009-03-13 | 2014-11-04 | Fisher-Rosemount Systems, Inc. | Scaling composite shapes for a graphical human-machine interface |
| US8825183B2 (en) * | 2010-03-22 | 2014-09-02 | Fisher-Rosemount Systems, Inc. | Methods for a data driven interface based on relationships between process control tags |
| US8805881B2 (en) | 2010-05-06 | 2014-08-12 | International Business Machines Corporation | Reputation based access control |
| US8359328B2 (en) | 2010-06-15 | 2013-01-22 | International Business Machines Corporation | Party reputation aggregation system and method |
| US8931048B2 (en) | 2010-08-24 | 2015-01-06 | International Business Machines Corporation | Data system forensics system and method |
| US8800029B2 (en) | 2010-10-04 | 2014-08-05 | International Business Machines Corporation | Gathering, storing and using reputation information |
| US9516006B2 (en) * | 2013-10-23 | 2016-12-06 | Google Inc. | Re-programmable secure cryptographic device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5452431A (en) * | 1991-10-30 | 1995-09-19 | U.S. Philips Corporation | Microcircuit for a chip card comprising a protected programmable memory |
| US5912453A (en) * | 1995-09-29 | 1999-06-15 | International Business Machines Corporation | Multiple application chip card with decoupled programs |
| EP1168184A1 (fr) * | 2000-06-28 | 2002-01-02 | STMicroelectronics S.A. | Microprocesseur sécurisé comprenant un systeme d'attribution de droits a des librairies |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5229652A (en) * | 1992-04-20 | 1993-07-20 | Hough Wayne E | Non-contact data and power connector for computer based modules |
| US5578808A (en) * | 1993-12-22 | 1996-11-26 | Datamark Services, Inc. | Data card that can be used for transactions involving separate card issuers |
| JP2783971B2 (ja) * | 1994-01-26 | 1998-08-06 | 日本信販株式会社 | クレジットカードの発行方法 |
| US6754886B1 (en) * | 1998-11-30 | 2004-06-22 | International Business Machines Corporation | Method and system for storing java objects in devices having a reduced support of high-level programming concepts |
-
2001
- 2001-12-12 FR FR0116054A patent/FR2833374A1/fr active Pending
-
2002
- 2002-12-11 AT AT02804648T patent/ATE433157T1/de not_active IP Right Cessation
- 2002-12-11 ES ES02804648T patent/ES2331115T3/es not_active Expired - Lifetime
- 2002-12-11 US US10/497,738 patent/US7363293B2/en not_active Expired - Lifetime
- 2002-12-11 WO PCT/IB2002/005294 patent/WO2003050686A1/fr not_active Application Discontinuation
- 2002-12-11 DE DE60232541T patent/DE60232541D1/de not_active Expired - Lifetime
- 2002-12-11 EP EP02804648A patent/EP1456759B8/fr not_active Expired - Lifetime
- 2002-12-11 AU AU2002366692A patent/AU2002366692A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5452431A (en) * | 1991-10-30 | 1995-09-19 | U.S. Philips Corporation | Microcircuit for a chip card comprising a protected programmable memory |
| US5912453A (en) * | 1995-09-29 | 1999-06-15 | International Business Machines Corporation | Multiple application chip card with decoupled programs |
| EP1168184A1 (fr) * | 2000-06-28 | 2002-01-02 | STMicroelectronics S.A. | Microprocesseur sécurisé comprenant un systeme d'attribution de droits a des librairies |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1456759A1 (fr) | 2004-09-15 |
| AU2002366692A1 (en) | 2003-06-23 |
| US20050005079A1 (en) | 2005-01-06 |
| ATE433157T1 (de) | 2009-06-15 |
| WO2003050686A1 (fr) | 2003-06-19 |
| EP1456759B1 (fr) | 2009-06-03 |
| EP1456759B8 (fr) | 2010-01-06 |
| US7363293B2 (en) | 2008-04-22 |
| DE60232541D1 (de) | 2009-07-16 |
| ES2331115T3 (es) | 2009-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3243178B1 (fr) | Procédé de traitement d'une transaction à partir d'un terminal de communication | |
| FR2833374A1 (fr) | Procede et dispositif de controle d'acces dans un systeme embarque | |
| CA2160223C (fr) | Procede de chargement d'une zone memoire protegee d'un dispositif de traitement de l'information, et dispositif associe | |
| FR2713803A1 (fr) | Carte à mémoire et procédé de fonctionnement. | |
| EP0552079B1 (fr) | Carte à mémoire de masse pour microordinateur | |
| EP1605333B1 (fr) | Contrôle de l'exécution d'un programme | |
| JPH09508733A (ja) | ポータブルデータ処理ユニットを備えたデータ交換システム | |
| EP3455812B1 (fr) | Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant | |
| FR2686171A1 (fr) | Carte a memoire de masse pour microordinateur avec facilites d'execution de programmes internes. | |
| EP0606792B1 (fr) | Procédé d'authentification d'un ensemble informatique par un autre ensemble informatique | |
| FR2987199A1 (fr) | Securisation d'une transmission de donnees. | |
| FR2840421A1 (fr) | Systemes informatiques tels que des cartes a puce ayant des architectures de memoire capables de proteger une information de securite, et procedes d'utilisation de ceux-ci | |
| WO2001084512A1 (fr) | Carte a puce multi-applicatives | |
| CN108460263A (zh) | 信息分享方法、装置和电子设备 | |
| US8880859B2 (en) | Method and arrangement for configuring electronic devices | |
| EP2912640B1 (fr) | Procédé de gestion d'identifiants dans une carte a circuit integré et carte a circuit integré correspondante | |
| US20200257785A1 (en) | User authentication | |
| EP2813962B1 (fr) | Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services. | |
| WO2002073552A1 (fr) | Verification de la conformite d'acces de sujet a des objets dans un systeme de traitement de donnees avec une politique de securite | |
| FR2923041A1 (fr) | Procede d'ouverture securisee a des tiers d'une carte a microcircuit. | |
| FR3104280A1 (fr) | Systeme electronique securise comportant un processeur et un composant memoire ; composant programmable associe | |
| EP1770524A2 (fr) | Détection d'erreur de séquencement dans l'exécution d'un programme | |
| WO2005050419A1 (fr) | Procede de securisation d'une image d'une donnee biometrique d'authentification et procede d'authentification d'un utilisateur a partir d'une image d'une donnee biometrique d'authentification | |
| EP0944880A1 (fr) | Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires | |
| FR2747813A1 (fr) | Systeme securise de controle d'acces permettant l'invalidation automatique de cles electroniques volees ou perdues et/ou le transfert d'habilitation a produire des cles |