ES2331115T3 - Procedimiento y dispositivo de control de acceso en un sistema integrado. - Google Patents
Procedimiento y dispositivo de control de acceso en un sistema integrado. Download PDFInfo
- Publication number
- ES2331115T3 ES2331115T3 ES02804648T ES02804648T ES2331115T3 ES 2331115 T3 ES2331115 T3 ES 2331115T3 ES 02804648 T ES02804648 T ES 02804648T ES 02804648 T ES02804648 T ES 02804648T ES 2331115 T3 ES2331115 T3 ES 2331115T3
- Authority
- ES
- Spain
- Prior art keywords
- subject
- access
- space
- update
- 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.)
- Expired - Lifetime
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
Abstract
Método para controlar el acceso a objetos (5) almacenados en un espacio de memoria de un sistema informático por un sujeto (3) almacenado en un espacio de programa de dicho sistema que desea realizar una operación en dichos objetos (5), que se caracteriza porque controla el acceso a dichos objetos (5) a través de un atributo dinámico (8) unido a dicho sujeto (3) cuyo valor es actualizado de acuerdo con los estados presente y pasado del sujeto.
Description
Procedimiento y dispositivo de control de acceso
en un sistema integrado.
La presente invención se refiere a un método y a
un dispositivo para controlar el acceso a áreas de memoria unidas a
aplicaciones y módulos de software de una unidad electrónica con
microprocesador, en particular un microcontrolador. La invención se
puede aplicar, por ejemplo y aunque no de forma limitativa, a
tarjetas inteligentes electrónicas.
La tarjeta inteligente, como todos los sistemas
informáticos integrados, incluye un procesador, entradas/salidas y
memoria que está dividida en memoria no volátil, utilizada
generalmente para almacenar programas y datos, y memoria volátil,
utilizada generalmente como memoria de procesamiento. Actualmente
los sistemas integrados u objetos portables y en particular las
tarjetas inteligentes realizan funciones cada vez más complejas
debido, en particular, al almacenamiento de programas de
aplicaciones múltiples: estas tarjetas inteligentes se designan con
el término "tarjeta inteligente multiaplicación".
Para la seguridad de las tarjetas inteligentes
multiaplicación, el aislamiento de las diferentes aplicaciones
entre sí resulta fundamental. En una tarjeta inteligente que
contiene varias aplicaciones es, por tanto, importante poder
denegar a las aplicaciones el acceso a datos que no les pertenecen
para evitar el uso indebido o la transferencia de información al
exterior. Por ejemplo, puede ser necesario denegar a una primera
aplicación el acceso a datos confidenciales que pertenecen a una
segunda aplicación, p. ej. claves criptográficas. En particular,
dado que los datos están almacenados de forma permanente en la
memoria no volátil, puede ser necesario limitar la lectura y la
actualización únicamente a las aplicaciones autorizadas.
Además, dado el aumento de la capacidad de
memoria y la potencia de procesamiento de las tarjetas
inteligentes, la arquitectura software se está haciendo cada vez más
estructurada, con funciones que están aisladas entre sí como
módulos y distribuidas a diferentes niveles.
Así, por ejemplo, en una arquitectura software
para tarjeta inteligente podemos identificar, como muestra la
figura 1, la capa de núcleo "CORE" que tiene una interfaz
directa con el hardware (y que comprende en particular las rutinas
de acceso a la memoria no volátil genérica), la capa de sistema
"OS" relativa al sistema operativo que gestiona los recursos y
servicios compartidos y la capa de aplicación "APPLI" que
agrupa las diferentes aplicaciones software. Cada capa puede ser
subdividida en subcapas y módulos funcionales: la capa de sistema
incluye, p. ej. módulos funcionales tales como el servicio de
procesamiento de algoritmo criptográfico, la gestión de memoria y
los recursos de entrada/salida.
En este tipo de modelo, una aplicación ya no
puede acceder a sus datos en la memoria de forma directa sino que
lo tiene que hacer a través de funciones situadas en las capas de
núcleo y de sistema. El problema de limitar el acceso a datos
almacenados a las aplicaciones autorizadas sólo surge, en
particular, en este contexto de accesos indirectos.
De forma más general, puede diseñarse una
arquitectura de software modular multicapa en donde, en primer
lugar, un módulo llama a uno o más módulos para ejecutar algunas de
sus tareas y, en segundo lugar, cada módulo tiene un programa y
datos almacenados en una memoria no volátil en áreas claramente
definidas, datos para los cuales el manejo o el uso debe estar
restringido a los módulos autorizados únicamente.
Generalmente, los mecanismos de protección de la
memoria pueden fabricarse en forma de software y/o hardware para
aplicaciones interpretadas y en forma de hardware para aplicaciones
ejecutadas como ventanas que se abren en la memoria (tal como un
dispositivo de segmentación) o como matrices de acceso
semiestáticas. Las aplicaciones se asocian a áreas de memoria
durante la configuración o cuando se selecciona una aplicación.
Estos mecanismos sólo permiten el acceso a la memoria a pares
predeterminados de áreas de código/datos.
El documento US 5,452,431 revela un mecanismo de
control de acceso a memoria en el cual la dirección del programa
proporcionada por el contador de programa de la CPU se compara con
un rango preconfigurado de direcciones para decidir si la
aplicación que se está ejecutando puede acceder a una determinada
área de memoria.
El documento US 5,312,453 revela un mecanismo de
control de acceso a memoria similar al sugerido por
US 5,452,431 pero que además tiene una reconfiguración dinámica de los rangos de dirección del programa
US 5,452,431 pero que además tiene una reconfiguración dinámica de los rangos de dirección del programa
\hbox{permitidos.}
Por ejemplo, con una matriz de acceso, las
páginas de memoria se asocian a aplicaciones cuando se configura la
tarjeta programando atributos de página; el papel del hardware en
el momento de la ejecución se limita a una simple comparación entre
la identidad del "propietario" de la página y la identidad del
módulo que intenta acceder a esta página (conocido por el hardware,
p. ej. a través de la posición del contador de programa). El
inconveniente de estos mecanismos de matriz de acceso reside en que
necesitan una relación directa entre el programa y los datos: esta
relación existe cuando el propietario de la página accede a sus
datos directamente (a través de las instrucciones de
lectura/escritura del microprocesador) pero desaparece en las
configuraciones en las que un módulo distinto al propietario desea
acceder a los datos "en su nombre". Dos ejemplos que ilustran
esta situación son (i) una máquina virtual que accede a los datos
de aplicaciones "en su nombre" y (ii) un módulo gestor de
EEPROM entre la aplicación y la memoria no volátil. Estos accesos
"de relación indirecta" no pueden ser protegidos por
dispositivos de tipo matriz de acceso.
La invención pretende superar los inconvenientes
conocidos de los dispositivos y sistemas del estado de la técnica
pero cumpliendo a la vez los requisitos que puedan surgir.
En el contexto de una arquitectura de software
modular multicapa de un sistema informático y más particularmente
en la siguiente descripción de un sistema integrado tal como una
tarjeta inteligente, el objeto de la invención es, por tanto,
proponer un método capaz de aislar y proteger áreas de memoria
unidas a dichos módulos.
En este contexto también, el objeto de la
invención es proponer un método capaz de controlar el acceso a la
memoria y limitar el acceso a los módulos que estén autorizados.
La invención se refiere a un método para
controlar el acceso a objetos almacenados en un espacio de memoria
de un sistema informático por un sujeto almacenado en un espacio
de programa de dicho sistema, deseando dicho sujeto realizar una
operación en dichos objetos, que se caracteriza porque controla el
acceso a dichos objetos a través de un atributo dinámico unido a
dicho sujeto cuyo valor es actualizado de acuerdo con los estados
presente y previos del sujeto.
La invención también se refiere a un dispositivo
de control de acceso que implementa el método descrito
anteriormente así como a un sistema integrado que utiliza dicho
dispositivo. La invención también se refiere al programa que
implementa dicho método.
La invención se describe a continuación en más
detalle haciendo referencia a los dibujos adjuntos, en donde:
- la figura 1 es una representación esquemática
de una arquitectura de software modular multicapa de un sistema
informático;
- la figura 2 es un diagrama de flujo que
ilustra las etapas principales de una forma de realización del
método de control de acceso de acuerdo con la invención;
- la figura 3 es una representación esquemática
de un ejemplo de encadenamiento de módulos y áreas de memoria a las
que dichos módulos desean acceder;
- la figura 4 es un diagrama que representa un
ejemplo de encadenamiento de módulos y áreas de memoria a las que
dichos módulos tienen derecho a acceder;
- la figura 5 es el diagrama de flujo que
muestra las etapas del método de control de acceso según la figura 2
de acuerdo con dos variantes de realización, una mostrada en trazo
continuo y la otra en trazo continuo y linea de puntos;
- la figura 6 ilustra un sistema según la figura
1 que muestra el método de control de acceso.
\vskip1.000000\baselineskip
En un sistema informático 1 con arquitectura de
software modular multicapa como se ilustra en la figura 1, un módulo
2, \alpha y \beta completa una determinada tarea solicitada por
el exterior mediante un conjunto de comandos de entrada/salida,
solicitada por otro módulo o como consecuencia de un evento
hardware. Un módulo capaz de ejecutar una tarea solicitada desde el
exterior se mencionará en adelante como una aplicación. La
ejecución de dicha tarea corresponde a la ejecución de una serie de
instrucciones denominada programa (A, B) almacenado en una memoria
no volátil en un espacio denominado espacio "PROG" (espacio de
programa) específico de dicho módulo. La serie de instrucciones se
aplica a un conjunto de datos almacenados en una memoria no volátil
de otro espacio, denominado espacio "DATA" (espacio de datos),
que son los espacios a y b para los programas A y B,
respectivamente. Los espacios de datos a y b consisten en espacios
para los cuales dichos módulos \alpha y \beta tienen derechos
de acceso. A título ilustrativo, en la figura 1 la activación del
módulo \alpha corresponde a la ejecución del programa A
almacenado en el espacio de programa PROG, aplicándose dicho
programa A a datos almacenados en el espacio de datos a. Si el
módulo \alpha tiene un derecho concedido por el módulo \beta, su
programa accede al espacio de datos b del módulo B (flecha de
puntos en la figura 1).
Mientras ejecuta su tarea, un módulo puede
llamar a otros módulos. Como consecuencia, los programas son
ejecutados de forma sucesiva, en donde el módulo llamado sigue al
módulo llamador.
En el contexto del sistema 1 descrito
anteriormente, el método de la invención consiste no sólo en aislar
las diferentes aplicaciones de software sino también en aislar
todos los módulos en el sistema (independientemente de su nivel):
el método debe garantizar que un módulo en la capa de aplicación no
pueda acceder a datos para los que no está autorizado a través de
llamadas a módulos en capas inferiores. El método de la invención
debe, por tanto, limitar el acceso a espacios de memoria únicamente
a los módulos autorizados 2.
El concepto de control de acceso está
representada en la figura 2: un control de acceso acepta o rechaza
una operación realizada por una entidad activa 3 conocida como el
sujeto "S" almacenado en el espacio PROG (p. ej. un proceso de
procesamiento) que ejecuta en nombre de un usuario 4, en entidades
pasivas 5 conocidas como objetos "O" del espacio de memoria
DATA (p. ej. un contenedor de datos almacenados) o PROG según las
reglas 6 que caracterizan la política aplicada, atributos de
seguridad 7, 8 asociados en primer lugar con el objeto objetivo 5 y
en segundo, con el sujeto 3 que ejecuta para un usuario 4 y el tipo
de operación. El sujeto consiste en uno o más módulos 2 que se
ejecutan sucesivamente para realizar una determinada operación.
Un software integrado como p. ej. el de las
tarjetas inteligentes multiaplicación puede describirse como un
sujeto 3 que primero ejecuta para usuarios externos 4 que necesitan
las diferentes aplicaciones y en segundo, realiza operaciones de
tipo acceso en la memoria no volátil.
En el contexto de la presente arquitectura de
software modular integrada, la invención propone un método y un
dispositivo para controlar el acceso a objetos 5, que se caracteriza
porque está basado en atributos dinámicos 8 unidos al objeto 3 y
cuyo valor depende de la historia del sujeto, es decir, de sus
estados presente y pasado. El método limita el acceso a objetos a
aquellos módulos autorizados 2 únicamente, incluso en el caso de
accesos indirectos, es decir, que se producen a través de unos o
más módulos diferentes.
El método incluye las etapas siguientes:
- -
- una etapa de gestión 9 para manejar el atributo 8 del sujeto, según los estados presente y pasado del sujeto 3;
- -
- una etapa de comparación de un ítem de información que caracteriza el objeto objetivo, que es el atributo 7 del objeto, y un ítem de información que caracteriza los estados presente y pasado del sujeto, que es el atributo 8 del sujeto;
- -
- una etapa de filtrado para aceptar o rechazar la operación en función de dicha comparación y opcionalmente del tipo de operación y/o de reglas predefinidas 6.
\vskip1.000000\baselineskip
En la siguiente descripción, el método según la
invención se describe en detalle en cuanto a su aplicación al
espacio de datos DATA, es decir, el objeto objetivo es parte de
dicho espacio DATA. Para que el método de la invención resulte más
fácil de comprender, la etapa de gestión se describirá después de
las de comparación y filtrado.
La etapa de comparación consiste con mayor
precisión en comparar un ítem de información que caracteriza el
área de memoria dirigida, con mayor precisión el espacio de datos
objetivo (denominado espacio objetivo), con un ítem de información
que caracteriza el espacio de datos asociado con los estados
presente y pasado del programa actual (denominado espacio
autorizado).
El espacio objetivo está identificado por un
atributo 7. De acuerdo con la primera variante de realización, el
atributo 7 es un ítem de información asociado con la operación. De
acuerdo con una segunda variante, el atributo 7 es un ítem de
información asociado físicamente con el área de memoria dirigida
(forma de realización de la figura 2). El espacio autorizado está
caracterizado por un atributo 8 del mismo tipo que el utilizado
para el espacio objetivo, para simplificar la comparación. En la
primera variante de realización, el atributo es una dirección de
memoria según el conocido modelo MMU (Memory Management Unit); la
operación actual especifica una dirección de memoria a la que el
sujeto 3 desea acceder. La comparación entonces consiste en
comprobar que la dirección 7 en cuestión está contenida en una
ventana 8 de direcciones, correspondiéndose la ventana 8 de
direcciones con el espacio autorizado. En la segunda variante de
realización, la operación actual selecciona un atributo 8 que
especifica un identificador. La comparación consiste en comprobar
la identidad entre el identificador 7 del espacio objetivo y el
identificador 8 del espacio autorizado (modelo
MAC-Mandatory Access Control).
La etapa de filtrado consiste en realizar una
acción dependiendo del resultado de la etapa de comparación, es
decir, que acepta la operación si el espacio de datos al que se
dirige la operación (el espacio objetivo) y el espacio de datos para
el cual el acceso está autorizado en el momento de la operación (el
espacio autorizado) se corresponden, o de lo contrario lo rechaza.
También pueden tenerse en cuenta otras características tales como el
tipo de operación, que amplía la cualificación del espacio objetivo,
p. ej. espacio accesible sólo en modo lectura (ejemplos de posible
cualificación: lectura, escritura, programación (escribe 1),
borrado (escribe 0) o combinaciones de estos términos, suministro
de instrucciones). También pueden imponerse reglas adicionales 6.
Por ejemplo, el acceso sólo puede ser concedido a uno o más módulos
predeterminados, en donde esta restricción se aplica además del
filtrado dependiendo del resultado de la comparación entre el
espacio objetivo y el espacio autorizado.
La etapa de gestión consiste en gestionar la
información que caracteriza el espacio de datos autorizado asociado
con el estado actual del programa: el método llama a un mecanismo 9
para inicializar (considerado en esta descripción como una
actualización inicial) y actualizar el espacio autorizado. El
espacio autorizado es inicializado o reinicializado en cada cambio
de aplicación (cambio a la aplicación A en la figura 4, en donde los
módulos M1, M2, M3 no son aplicaciones sino simples módulos
activados para procesar una tarea solicitada por otro módulo).
Dicha gestión depende de las características
funcionales de la arquitectura y de la política de seguridad que
debe ser implementada.
En el contexto de una arquitectura de software
modular integrada en la que un módulo puede llamar a otro módulo
para subcontratar una tarea, el programa del módulo llamado puede
acceder a sus propios datos y también tiene el privilegio de poder
acceder a los datos del espacio de datos perteneciente al módulo
llamador. Durante una sucesión de llamadas entre los módulos, el
privilegio se hereda de un módulo a otro: un determinado espacio de
datos puede ser accedido por toda una serie de módulos. Por tanto,
un programa de un módulo llamado puede acceder, además de a su
propio espacio de datos, también al espacio de datos de cualquiera
de los módulos que han llamado anteriormente o de varios de
ellos.
El manejo o el uso de los datos está limitado a
los módulos autorizados únicamente: el método de control de acceso
de acuerdo con la invención acepta o rechaza operariones en datos
almacenados en la memoria no volátil dependiendo del encadenamiento
de llamadas entre los módulos y de las elecciones de cada programa
para acceder a sus propios datos de forma transitoria.
Una característica de la política de seguridad
de la tarjeta inteligente es que un módulo sólo puede usar, manejar
o acceder a sus propios datos o a datos correspondientes a la tarea
que le ha sido encomendada. Como se muestra en el primer ejemplo
(Ej. 1) de la figura 3, un módulo llamado (B) hereda el privilegio
de acceder al espacio de datos de la tarea para la que ha sido
llamado, espacio que puede pertenecer al módulo llamador (A) o
heredado por el propio módulo llamado (B). En el primer ejemplo, el
espacio autorizado no necesita ser actualizado ya que no cambia. El
módulo también puede necesitar (segundo ejemplo, Ej. 2) acceder a
sus propios datos; en este caso el espacio autorizado se actualiza
mediante una solicitud (explícita o implícita como se ilustra en la
figura 5 y se detalla más adelante) de este módulo. Cuando el módulo
deja de acceder a su propio espacio de datos, vuelve al contexto
anterior y de nuevo accede al espacio de datos para el cual ha
recibido un privilegio por parte de la llamada subcontratante; el
espacio autorizado vuelve a su valor anterior mediante una
solicitud (implícita o explícita como se ilustra en la figura 5). En
el segundo ejemplo, el módulo B llamado por el módulo A accede a
los datos del módulo A (flecha u) y a sus propios datos (flecha v)
de forma transitoria. El módulo C, llamado por el módulo B, llamado
a su vez por el módulo A, accede a los datos del módulo B (flecha
x) o del módulo A (flecha y) y a sus propios datos (flecha w) de
forma transitoria.
La etapa de actualización realizada para
autorizar el encadenamiento de los accesos a los espacios objetivo
como se ha descrito antes, se implementa de acuerdo con diferentes
formas de la realización ilustrada en la figura 4.
La figura 4 representa, en el ejemplo ilustrado,
las llamadas entre los módulos A, M1, M2, M3, los espacios
objetivos durante las llamadas y los cambios a espacios autorizados
durante un determinado período (t1, t2).
De acuerdo con la primera forma de realización,
la etapa de actualización puede realizarse utilizando una pila de
espacios autorizados (PILE ESP_AUT de la figura 4): cada módulo
solicita (de forma implícita o explícita) que su propio espacio de
datos sea añadido o retirado de la pila de espacios autorizados
cuando necesita acceder a él. En la parte con fondo gris de la
figura 4 (letra "o") antes de llamar al módulo M3, el módulo
M2 pide que su propio espacio m2 sea añadido a la pila de espacios
autorizados. La pila entonces consiste en los espacios siguientes:
al m2. Teniendo en cuenta la actualización del espacio autorizado,
el módulo M3 puede acceder al espacio m2 (ACC_MEM). El módulo M3
entonces solicita acceso (letra "p") a sus propios datos m3;
su propio espacio m3 es colocado en la pila de espacios
autorizados. La pila entonces consiste en los espacios siguientes:
al m2 m3. El dispositivo de control de acceso autoriza una
operación en un espacio de datos cuando el espacio de datos al que
se dirige la operación y el espacio de datos para el cual está
autorizado el acceso en el momento de la operación son idénticos:
el espacio de datos autorizado en el momento de la comparación
corresponde al espacio que está en la parte superior de la pila (en
el primer ejemplo es el espacio m2 y en el segundo ejemplo es el
espacio m3), siendo los espacios que están en la parte inferior de
la pila (en el primer ejemplo el espacio al y en el segundo ejemplo
los espacios al m2) espacios que han sido espacios autorizados y
que lo volverán a ser.
Cabe destacar que la pila de espacios
autorizados puede ser bastante diferente de la pila de módulos de
llamada; p. ej. si ninguno de los módulos llamados accede a sus
propios datos, la pila de espacios autorizados se reduce al espacio
de datos del primer módulo llamador (flechas r, s, t de la figura 4
- espacio de datos a1).
De acuerdo con una segunda forma de realización,
se establece una política de seguridad menos rigurosa. Esta
política de actualización se implementa a través de un mecanismo de
gestión de tipo lista: cada módulo puede solicitar (de forma
implícita o explícita) que su propio espacio de datos sea colocado
o retirado de la lista de espacios autorizados.
Como se ilustra de forma simple en la figura 4,
cada módulo llamado puede acceder potencialmente a su propio
espacio de datos y su espacio de datos es añadido a la lista (LIST
ESP_AUT). El manejo de la lista es implícito y está sincronizado con
las llamadas de módulo. En este caso, la lista de espacios
autorizados es la misma que la lista de espacios de datos asociados
a los módulos identificados en la pila de módulos llamadores a la
que se ha añadido el espacio de datos del último módulo
llamado.
La limitación es menos rigurosa que en el caso
anterior; de hecho, el mecanismo de actualización en la segunda
forma de realización permite la operación si existe un acuerdo entre
el espacio objetivo y uno de los espacios autorizados de la lista.
El mecanismo, por tanto, permite a un módulo llamador acceder a
datos de cualquiera de los módulos llamados antes del control de
acceso.
Según la primera variante de la etapa de
actualización ilustrada en la figura 5 con trazo continuo, la
solicitud realizada por un módulo 2 de añadir o retirar su espacio
8 de datos a la pila o la lista de espacios autorizados es
explícita: la solicitud usa uno o más comandos de actualización
internos (CIMJ en la figura 5) del tipo "add (or remove) my
space" (añadir o retirar mi espacio) o "add (or remove) a
given space" (añadir o retirar un espacio dado).
Según otra variante de realización de la etapa
de actualización ilustrada en trazo continuo y línea de puntos en
la figura 5, la solicitud de un módulo 2 de añadir su espacio 8 de
datos, o retirarlo, de una pila o lista de espacios autorizados, es
implícita. La solicitud usa un comando de actualización interno
(CIMJ) desde un mecanismo 11 de interceptación de llamada o de
procesamiento preliminar, en donde dicho mecanismo solicita la
adición (o retirada) del espacio de datos correspondiente al
espacio objetivo mediante la operación realizada por la llamada a
un módulo llamado (o el retorno al módulo llamador).
Para actualizar el atributo del sujeto según el
estado del sujeto o, más en particular, para gestionar la
información que caracteriza el espacio de datos asociado con el
estado del procesamiento actual, es decir, el espacio autorizado, el
mecanismo de gestión debe procesar la solicitud de actualización
correspondiente al cambio del estado del sujeto, como se muestra en
la figura 2.
La protección ofrecida por el control de acceso
depende del nivel de seguridad proporcionado en la gestión de dicho
control. Para aumentar la seguridad en la gestión de control de
acceso se planifica un mecanismo de gestión de actualización como
un control de identidad del sujeto y de sus derechos. La solicitud
para actualizar el atributo 8 del sujeto sólo es aceptada y tenida
en cuenta si su emisor, un módulo (en este caso el módulo activo o
el módulo de interceptación), es identificado de forma fiable y
está autorizado para hacer esta solicitud: el mecanismo de gestión
de actualización de atributos de sujeto comprende un mecanismo 10
para comprobar la identidad del solicitante de dicha actualización
y para comprobar sus derechos.
El mecanismo 10 debe, en primer lugar,
identificar el módulo que hace la solicitud de actualización y, en
segundo lugar, comprobar que la solicitud es legal comprobando los
derechos del módulo sobre el espacio de datos objetivo. Los
derechos son específicos de los datos del módulo en cuestión y han
sido guardados previamente.
La identidad del módulo llamador se obtiene
generalmente mediante la identificación del espacio de programa del
llamador. En una solicitud de patente presentada el mismo día que
la presente solicitud por el mismo solicitante con el título
"Method and system for module chaining control in a modular
software architecture" (WO 03050660) se describe un mecanismo de
identificación de este tipo.
Si se realiza una solicitud explícita del tipo
"añadir (o retirar) un determinado espacio", el derecho del
espacio de programa sobre el espacio de datos en cuestión se guarda
en la memoria, p. ej. en una tabla que une el(los)
espacio(s)
de programa y múltiples espacios de datos de acuerdo con los derechos de los espacios de programa sobre los espacios de datos. Esta solución es adecuada cuando los datos pueden ser compartidos entre varios módulos. Para que dos o más módulos puedan compartir un espacio de datos, simplemente tienen que compartir el derecho a actualizar el espacio autorizado añadiendo este espacio de datos.
de programa y múltiples espacios de datos de acuerdo con los derechos de los espacios de programa sobre los espacios de datos. Esta solución es adecuada cuando los datos pueden ser compartidos entre varios módulos. Para que dos o más módulos puedan compartir un espacio de datos, simplemente tienen que compartir el derecho a actualizar el espacio autorizado añadiendo este espacio de datos.
De forma más específica, si se realiza una
solicitud explícita del tipo "añadir (o retirar) mi espacio",
la correspondencia entre el espacio de programa y el espacio de
datos debe ser guardada en la memoria. Esta solución es adecuada
cuando existe una relación biyectiva entre espacio de programa y
espacio de datos.
Si la solicitud es implícita, el derecho del
espacio de programa del módulo llamador sobre el espacio de datos
objetivo debe ser guardado en la memoria, p. ej. en una tabla que
una el(los) espacio(s) de programa y múltiples
espacios de datos como anteriormente; la tabla sólo será consultada
si el espacio objetivo difiere del espacio autorizado existente.
Como se muestra en las figuras 5 y 6, el
mecanismo 9 utilizado para inicializar y actualizar el espacio
autorizado según la invención es iniciado por un comando externo
CE. El comando externo activa ("ACTIV" en las figuras) uno de
los módulos 2 del sistema 1. La activación de uno de estos módulos
inicializa ("Inic") el espacio autorizado a un valor
particular que permite al primer módulo llamado por dicho comando
externo acceder al área de memoria necesaria. Cuando un módulo llama
a otro módulo se ejecuta el método de la invención descrito
anteriormente.
El método según la invención ha sido descrito en
su aplicación para controlar el acceso al espacio de memoria de
datos. De forma similar, el método según la invención puede ser
utilizado para controlar el acceso al espacio de memoria de
programa.
A título ilustrativo se describe a continuación
el caso de una arquitectura de tres capas como la que puede
encontrarse en una tarjeta inteligente (figura 6).
En el caso ilustrado en la figura 6, el
mecanismo de comparación y acción se implementa en el hardware al
nivel de acceso a memoria (MEM). Al activar (ACTIV) las
aplicaciones (APLI), el sistema operativo (SO) inicializa el espacio
autorizado. El sistema operativo (SO) comprende un mecanismo 11 de
interceptación de llamadas que notificará de forma implícita a la
gestión (9, 10) del espacio autorizado, el espacio al que se dirige
la llamada hecha al sistema (que puede ser diferente al espacio
inicializado si una aplicación ha llamado a otra). La gestión (9,
10) del espacio autorizado identifica la aplicación que llama y
modifica, en función de los derechos de dicha aplicación que llama,
el espacio autorizado dándole el valor del espacio objetivo. La
función de gestión del dispositivo es jerárquica, siendo el núcleo
capaz de modificar el espacio autorizado por sobrecarga (SURCH). Una
vez realizada la actualización, se comparan los espacios
ATTRI-S y ATTRI-O de acuerdo con una
regla de comparación dada, el tipo de operación y las reglas
específicas. El acceso solicitado por la operación es aceptado o
rechazado en función del resultado de la comparación.
Una realización especial consiste en implementar
el mecanismo de comparación y acción en el hardware; en este caso,
un método consiste en transferir la parte superior de la pila a un
registro hardware y otro método consiste en implementar toda la
pila en el hardware. En arquitecturas simples o con un control de
acceso limitado, la gestión del dispositivo puede ser implementada
con un hardware específico.
La totalidad o parte del sistema descrito
anteriormente puede ser realizada en el hardware.
Además, el conjunto de módulos de dicho sistema
puede tener cualquier otra forma y, en particular, algunos módulos
de dicho conjunto pueden ser agrupados o también divididos para
formar nuevos módulos.
El sistema según la invención está centralizado
y es único o jerárquico y presenta mecanismos separados de
comparación, acción y gestión.
Por tanto, la invención se refiere a un método
para controlar el acceso a objetos 5 almacenados en un espacio de
memoria de un sistema informático por un sujeto 3 almacenado en un
espacio de programa de dicho sistema, en donde dicho sujeto desea
realizar una operación en dichos objetos 5, que se caracteriza
porque controla el acceso a dichos objetos 5 a través de un
atributo dinámico 8 unido a dicho sujeto 3 cuyo valor es
actualizado de acuerdo con los estados presente y anteriores del
sujeto.
El atributo del objeto es un ítem de información
que caracteriza el área de memoria a la que va dirigida la
operación realizada por el sujeto y el atributo de sujeto es un
ítem de información que caracteriza el espacio de memoria autorizado
asociado con el estado presente y pasado del programa de
procesamiento actual, es decir, el sujeto.
El atributo dinámico es un ítem de información
del tipo dirección(es) de memoria o un ítem de información
del tipo identificador.
Un módulo del sujeto solicita de forma explícita
la actualización del atributo dinámico 8 o de forma implícita a
través de un mecanismo de interceptación de llamadas subyacente.
Claims (10)
1. Método para controlar el acceso a objetos (5)
almacenados en un espacio de memoria de un sistema informático por
un sujeto (3) almacenado en un espacio de programa de dicho sistema
que desea realizar una operación en dichos objetos (5), que se
caracteriza porque controla el acceso a dichos objetos (5) a
través de un atributo dinámico (8) unido a dicho sujeto (3) cuyo
valor es actualizado de acuerdo con los estados presente y pasado
del sujeto.
2. Método de control de acceso de acuerdo con la
reivindicación 1, que se caracteriza porque incluye las
etapas:
- -
- una etapa para actualizar el atributo dinámico (8) del sujeto y gestionar dicha actualización;
- -
- una etapa para comparar un ítem de información que caracteriza el objeto objetivo (5) que es el atributo del objeto y un ítem de información que caracteriza los estados presente y pasado del sujeto (3) que es dicho atributo dinámico del sujeto;
- -
- una etapa de acción para aceptar o rechazar el acceso dependiendo del resultado de dicha comparación y opcionalmente del tipo de operación y/o reglas predefinidas y guardadas.
3. Método según la reivindicación 1 ó 2, que se
caracteriza porque controla el acceso a dicho (s) objeto (s)
de acuerdo con el encadenamiento de llamadas entre módulos y la
elección de cada módulo de acceder a su propio objeto.
4. Método según una de las reivindicaciones 1 a
3, que se caracteriza porque el mecanismo de actualización
de atributo dinámico es de tipo pila, en donde el atributo dinámico
utilizado para el control de acceso está en la parte superior de la
pila.
5. Método según una de las reivindicaciones 1 a
3, que se caracteriza porque el mecanismo de actualización
de atributo dinámico es de tipo lista, siendo el atributo dinámico
utilizado para el control de acceso la totalidad de dicha
lista.
6. Método según una de las reivindicaciones 1 a
5, que se caracteriza porque consiste en gestionar dicha
actualización comprobando la identidad y los derechos de la parte de
módulo del sujeto y solicitando la actualización del atributo (8),
ya sea esta actualización implícita o explícita, y realizando
solamente dicha actualización si el módulo está autorizado para
ello.
7. Dispositivo para controlar el acceso de un
sujeto (3) almacenado en un espacio de programa de un sistema
informático que comprende al menos un medio de memoria y un medio
de computación y que desea realizar una operación en objetos (5)
almacenados en un espacio de memoria de dicho sistema, que se
caracteriza porque comprende un medio para realizar un
control de acceso a dichos objetos utilizando un atributo dinámico
(8) unido a dicho sujeto (3) y situado en la memoria, cuyo valor es
actualizado de acuerdo con los estados presente y pasado del
sujeto.
8. Dispositivo según la reivindicación 7, que se
caracteriza porque comprende:
- -
- un mecanismo para actualizar un atributo dinámico del sujeto y gestionar la actualización en función de los estados presente y pasado del sujeto;
- -
- un mecanismo para comparar un ítem de información que caracteriza el objeto objetivo que es el atributo del objeto y un ítem de información que caracteriza el estado del sujeto que es el atributo dinámico (8) del sujeto, estando dichos ítems de información almacenados en el medio de memoria;
- -
- un mecanismo de acción para aceptar o rechazar la operación dependiendo del resultado anterior, del tipo de operación y/o de reglas predefinidas.
9. Sistema integrado que se caracteriza
porque comprende el dispositivo según la reivindicación 7 ó 8.
10. Programa informático que incluye
instrucciones de código de programa para ejecutar las etapas del
método según una de las reivindicaciones 1 a 6 cuando dicho programa
se ejecuta en un sistema de procesamiento de datos.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0116054 | 2001-12-12 | ||
| 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 |
|---|---|
| ES2331115T3 true ES2331115T3 (es) | 2009-12-22 |
Family
ID=8870387
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02804648T Expired - Lifetime ES2331115T3 (es) | 2001-12-12 | 2002-12-11 | Procedimiento y dispositivo de control de acceso en un sistema integrado. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7363293B2 (es) |
| EP (1) | EP1456759B8 (es) |
| AT (1) | ATE433157T1 (es) |
| AU (1) | AU2002366692A1 (es) |
| DE (1) | DE60232541D1 (es) |
| ES (1) | ES2331115T3 (es) |
| FR (1) | FR2833374A1 (es) |
| WO (1) | WO2003050686A1 (es) |
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 |
| 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 |
| JP2007536634A (ja) * | 2004-05-04 | 2007-12-13 | フィッシャー−ローズマウント・システムズ・インコーポレーテッド | プロセス制御システムのためのサービス指向型アーキテクチャ |
| 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 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2683357A1 (fr) * | 1991-10-30 | 1993-05-07 | Philips Composants | Microcircuit pour carte a puce a memoire programmable protegee. |
| 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 | 日本信販株式会社 | クレジットカードの発行方法 |
| DE19536169A1 (de) * | 1995-09-29 | 1997-04-03 | Ibm | Multifunktionale Chipkarte |
| 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 |
| FR2811096A1 (fr) * | 2000-06-28 | 2002-01-04 | St Microelectronics Sa | Microprocesseur securise comprenant un systeme d'attribution de droits a des librairies |
-
2001
- 2001-12-12 FR FR0116054A patent/FR2833374A1/fr active Pending
-
2002
- 2002-12-11 EP EP02804648A patent/EP1456759B8/en not_active Expired - Lifetime
- 2002-12-11 AU AU2002366692A patent/AU2002366692A1/en not_active Abandoned
- 2002-12-11 AT AT02804648T patent/ATE433157T1/de not_active IP Right Cessation
- 2002-12-11 WO PCT/IB2002/005294 patent/WO2003050686A1/en not_active Application Discontinuation
- 2002-12-11 ES ES02804648T patent/ES2331115T3/es not_active Expired - Lifetime
- 2002-12-11 DE DE60232541T patent/DE60232541D1/de not_active Expired - Lifetime
- 2002-12-11 US US10/497,738 patent/US7363293B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US20050005079A1 (en) | 2005-01-06 |
| EP1456759B1 (en) | 2009-06-03 |
| DE60232541D1 (de) | 2009-07-16 |
| ATE433157T1 (de) | 2009-06-15 |
| EP1456759B8 (en) | 2010-01-06 |
| EP1456759A1 (en) | 2004-09-15 |
| AU2002366692A1 (en) | 2003-06-23 |
| FR2833374A1 (fr) | 2003-06-13 |
| US7363293B2 (en) | 2008-04-22 |
| WO2003050686A1 (en) | 2003-06-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2331115T3 (es) | Procedimiento y dispositivo de control de acceso en un sistema integrado. | |
| EP1242891B1 (en) | Partitioned memory device having characteristics of different memory technologies | |
| US9430409B2 (en) | Memory protection | |
| US20020040438A1 (en) | Method to securely load and manage multiple applications on a conventional file system smart card | |
| JP3878134B2 (ja) | データキャリアのためのマイクロプロセッサ回路、および、メモリ内に格納されたデータへのアクセスを組織化するための方法 | |
| KR20050113659A (ko) | 메모리 장치 | |
| JP2006252449A (ja) | 不揮発性メモリモジュールおよび不揮発性メモリシステム | |
| GB2356469A (en) | Portable data carrier memory management system and method | |
| JP2003196625A (ja) | Ｉｃカードプログラム及びｉｃカード | |
| CN103699434B (zh) | 一种适用于多应用之间安全访问的mpu及其多应用之间安全访问的方法 | |
| WO2006005773A1 (es) | Método y dispositivo para la compartición de información entre parcelas de memoria de entornos de recursos limitados | |
| EP1433041B1 (en) | Access to data stored in an embedded database | |
| EP1456730B1 (en) | Method and system for module chaining control in a modular software architecture | |
| US20070118680A1 (en) | Method to control the access in a flash memory and system for the implementation of such a method | |
| ES2309569T3 (es) | Acceso a elementos de datos en un soporte de datos portatil. | |
| CN116167102A (zh) | 用于管理片上系统中的存储器的方法 | |
| CN110569205A (zh) | 安全系统单芯片及其操作方法 | |
| EP3156933A1 (en) | System and method of managing application data separation in memory with a dynamically updated data access tree | |
| JPS63286990A (ja) | Ｉｃカ−ド情報処理システム |