ES2275075T3 - Proteccion de un dispositivo contra un uso involuntario en un entorno protegido. - Google Patents
Proteccion de un dispositivo contra un uso involuntario en un entorno protegido. Download PDFInfo
- Publication number
- ES2275075T3 ES2275075T3 ES03701491T ES03701491T ES2275075T3 ES 2275075 T3 ES2275075 T3 ES 2275075T3 ES 03701491 T ES03701491 T ES 03701491T ES 03701491 T ES03701491 T ES 03701491T ES 2275075 T3 ES2275075 T3 ES 2275075T3
- Authority
- ES
- Spain
- Prior art keywords
- hash value
- key
- memory
- protected
- application
- 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
- G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Mathematical Physics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
- Emergency Alarm Devices (AREA)
- Emergency Protection Circuit Devices (AREA)
- Details Of Indoor Wiring (AREA)
Abstract
Método de protección de un dispositivo contra un uso involuntario en un entorno protegido, adaptado el dispositivo para ejecutar aplicaciones que implican un control de acceso a al menos uno de los contenidos y servicios valiosos e incluyendo el dispositivo un circuito integrado (10) con una unidad de procesamiento central (12), una memoria interna (14, 16) y conexiones de entrada/salida para la memoria externa (20, 24) incorporadas en un único chip, donde * dicha memoria externa (24) y dicho chip se conectan de manera inequívoca por encriptación de un código de aplicación y datos sensibles con una clave secreta almacenada en una zona de la memoria protegida (16) de la memoria interna, almacenándose después el código codificado y los datos codificados en la memoria externa (24), caracterizado porque * también se encriptan un número aleatorio y un valor hash del número aleatorio con dicha clave secreta y se almacenan en la memoria externa (24), el número aleatorio codificado y el valor hashse descodifican con la clave secreta al menos en cada reinicialización del dispositivo, y la descodificación del código y los datos sensibles encriptados sólo se permite si el valor hash descodificado es igual a un valor hash calculado a partir del número aleatorio descifrado.
Description
Protección de un dispositivo contra un uso
involuntario en un entorno protegido.
La presente invención se refiere a un método
para proteger un dispositivo contra un uso involuntario en un
entorno protegido y, en concreto, en un entorno de control de
acceso.
Ejemplos de aplicaciones que implican
transacciones seguras incluyen pagos y operaciones bancarias
electrónicos; ejemplos de aplicaciones que comprenden control de
acceso incluyen TV Digital de pago, grabaciones de TV Digital y
Video a petición. Un dispositivo para ejecutar tales aplicaciones
puede ser un módulo embebido en un entorno tal como un
Set-Top-Box, un chip embebido en la
placa base de un Set-Top-Box, un
lector de Tarjetas Electrónicas o un módulo conectable tal como una
tarjeta de ordenador personal que incluye normalmente un lector de
Tarjetas Electrónicas. Mientras los componentes de hardware del
módulo aseguran un buen rendimiento para tareas tales como
descodificar "video streams", la tarjeta electrónica tiene
principalmente una función de seguridad. El código de aplicación se
almacena normalmente en una memoria externa del dispositivo tal como
una memoria flash.
De manera tradicional, estos dispositivos
dependen de la seguridad de la Tarjeta Electrónica. Sin embargo, ya
que la seguridad total depende de los procedimientos incluidos en el
código de aplicación almacenado en la memoria externa o incluso en
la memoria interna del dispositivo, las funciones de seguridad de la
Tarjeta Electrónica se pueden controlar sustituyendo o modificando
el código de aplicación.
La WO 00/19299 describe un aparato para
proporcionar un entorno de procesamiento seguro. El aparato incluye
una unidad de procesamiento y una memoria de
lectura-escritura conectada a un cifrador y a un
autenticador. La información codificada escrita en la memoria de
lectura-escritura se transfiere al cifrador para
descodificarse si se necesita. La información descodificada se
rescribe en la memoria de lectura-escritura. La
unidad de procesamiento puede usar únicamente la información
descodificada, si el autenticador ha autenticado la información
descodificada usando una clave secreta.
La presente invención proporciona una
arquitectura protegida para un dispositivo que ejecuta aplicaciones
en condiciones que demandan máxima seguridad.
Según un primer aspecto de la invención, se
proporciona un método para proteger un dispositivo contra un uso
involuntario en un entorno seguro, donde el dispositivo está
adaptado para ejecutar aplicaciones que comprenden un control de
acceso a al menos uno de los contenidos y servicios valiosos y el
dispositivo incluye un circuito integrado con una unidad de
procesamiento central, una memoria interna y conexiones de
entrada/salida para la memoria externa incorporadas en un único
chip. La memoria externa y el chip se conectan de manera inequívoca
encriptando un código sensible de aplicación y datos sensibles con
una clave secreta almacenada en una zona de memoria protegida de la
memoria interna del chip, almacenándose después el código y los
datos encriptados en la memoria externa. Únicamente se permite el
uso del código de aplicación y de los datos sensibles después de
una correcta descodificación con la clave secreta. Con dicha clave
secreta también se encriptan un número aleatorio y un valor hash y
se almacenan en la memoria externa. El número aleatorio codificado y
el valor hash se encriptan con la clave secreta al menos en cada
reinicialización del dispositivo, y la descodificación del código y
los datos sensibles encriptados sólo es permitida cuando el valor
hash descodificado es igual a un valor hash calculado a partir del
número aleatorio descifrado. Como resultado, el chip y la memoria
externa se emparejan de manera inequívoca, es decir, el chip no se
puede usar con una memoria externa cuyos contenidos sensibles hayan
sido alterados o cambiados.
Un dispositivo protegido con el método de la
invención incluye un circuito integrado con una unidad de
procesamiento central, una memoria interna y conexiones de
entrada/salida para una memoria externa, todos incorporados en un
único chip. La memoria interna incluye una zona de memoria protegida
a la que tiene acceso únicamente la unidad de procesamiento
central. La zona de memoria protegida contiene una clave de
codificación protegida usada para encriptar datos sensibles
almacenados en la memoria externa. Preferentemente, el chip incluye
un generador de números aleatorios. Un valor hash (resumen o
identificación de un dato para generar claves que representen un
documento, registro, archivo, etc) se obtiene a partir de un número
aleatorio producido por el generador de números aleatorios, el
número aleatorio con su valor hash se codifican con la clave
secreta, y el número aleatorio codificado con su valor hash se
almacenan en la memoria externa. Como resultado, el dispositivo
tiene un chip que se empareja de forma inequívoca con la memoria
externa. Ya que los datos y/o el código sensibles tienen unas
características tales que no es posible una ejecución correcta de
una aplicación por parte del dispositivo a menos que estos datos
y/o el código se hayan descifrado correctamente, y el chip no va a
descodificar los datos y/o el código a menos que se verifique
correctamente su emparejamiento con la memoria externa, se impide
de manera efectiva el uso del dispositivo con contenidos de la
memoria externa que no se hayan autentificado.
La zona de memoria protegida puede contener
datos de verificación de autenticidad. La memoria interna puede
incluir también una zona de memoria de lectura únicamente con un
código de verificación de autenticidad obligatorio que permita la
ejecución de una aplicación sólo después de una verificación de
autenticidad aceptada. Por tanto, el código de aplicación
autentificado sólo lo ejecuta el dispositivo y no prospera ninguna
sustitución del mismo que trate de burlar la seguridad.
Aquí, "autenticidad" se entiende en un
sentido amplio. "Autenticidad" incluye integridad y cualquier
modificación fraudulenta del código de aplicación o de los datos
sensibles hace que el dispositivo se niegue a ejecutar la
aplicación.
aplicación.
Desde fuera del dispositivo no se puede ver
ningún código de aplicación ni datos sensibles. El código de
aplicación y los datos sensibles se almacenan codificados y se
descodifican en el dispositivo para ejecutar la aplicación. Si se
añade confidencialidad a la autenticidad, un ataque es incluso más
difícil, si no imposible, ya que los contenidos de la memoria,
siendo visibles desde fuera del dispositivo, no son
inteligibles.
Según otro aspecto de la invención, cualquier
código descargado en el dispositivo se firma con una clave privada
de un par de claves asimétricas y la ejecución correcta de la
aplicación se somete a una verificación de la firma con una clave
pública del par de claves. Además, cualquier código de aplicación
almacenado en la memoria externa se codifica con una clave secreta
almacenada en la zona de memoria protegida de la memoria
interna.
Otras características y ventajas de la invención
quedan claras en la siguiente descripción con referencia a los
dibujos que se acompañan, en los que:
Figura 1: diagrama esquemático general de un
dispositivo con una arquitectura de sistema protegido genérica para
un Módulo de Control de Acceso (CAM) y un Lector de Tarjeta
Electrónica (SCR).
Figuras 2A y 2B: diagramas que ilustran
diferentes ejemplos del proceso de preparación de un código de
aplicación firmado para su descarga en el dispositivo.
Figuras 3A a 3D: diagramas que ilustran ejemplos
correspondientes de procesos de verificación de firma en el
dispositivo.
Figura 4A: diagrama de bloques que ilustra un
proceso de preparación de un código de aplicación codificado para
su descarga en el dispositivo.
Figura 4B: organigrama que ilustra la
descodificación de la aplicación descargada.
Figuras 5A y 5B: organigramas que ilustran la
codificación y descodificación del código de aplicación almacenado
en la memoria externa del dispositivo.
Figura 6: diagrama que ilustra un proceso
emparejamiento de chip donde un chip se conecta de manera
inequívoca con los contenidos de una memoria externa del
dispositivo.
Figura 7: diagrama que ilustra un proceso de
verificación de emparejamiento de chip.
Figura 8: diagrama que ilustra una primera fase
de un proceso de personalización de un chip.
Figura 9: diagrama que ilustra una segunda fase
de un proceso de personalización de un chip.
Figura 10: representación esquemática de una
asignación variable entre los pins externos de chip y las líneas de
señal internas del chip.
Figura 11: diagrama de bloques de un dispositivo
de detección de intrusión.
Refiriéndonos ahora a la Figura 1, el
dispositivo de la presente invención incluye un circuito integrado
específico de aplicación (ASIC) designado normalmente con el número
de referencia 10. El ASIC 10 incorpora, en un único chip
semiconductor, varios componentes; entre éstos, los siguientes son
fundamentales para la invención (aunque el ASIC incluye normalmente
otros componentes):
- -
- una unidad microprocesadora (\muP) 12,
- -
- una memoria de sólo lectura (ROM) 14 conectada al \muP 12,
- -
- una zona de memoria interna protegida (ISMA) 16 conectada también al \muP 12.
Preferentemente, como se muestra en la Figura 1,
el ASIC también incluye una unidad de codificación de hardware 18
conectada al \muP 12 y a una memoria de acceso aleatorio externa
(RAM) 20 a través de una interfaz bidireccional 22, representada en
la Figura 1 con una doble flecha. El dispositivo 10 tiene, además de
la RAM externa 20, una memoria flash 24 conectada al \muP 12 a
través de una interfaz bidireccional 26, simbolizada en la Figura 1
por una doble flecha. El dispositivo 10 incluye también una interfaz
bidireccional 28 para su conexión a una tarjeta externa (SC)
30.
En un ejemplo específico, el dispositivo 10
incorpora una función de control de acceso (CA). Tal dispositivo se
suele denominar CAM (Módulo de Control de Acceso) para usar con un
Set-Top-Box (STB) en un entorno de
TV digital (DTV). Un CAM se puede embeber en la STB, o es una
tarjeta conectable al PC (PCMCIA) que se puede ajustar en una
ranura de una interfaz común (CI) de la STB e incorpora un Lector de
Tarjetas Electrónicas (SCR). Otras realizaciones del dispositivo 10
incluyen un SRC para usar con un Ordenador Personal bajo condiciones
de alta seguridad.
Con referencia a la Figura 2, un primer aspecto
de la invención consiste en que se verifica la autenticidad e
integridad de cualquier aplicación que vaya a ejecutarse en el
dispositivo, al menos en lo que se refiere a transacciones
sensibles. En general, el código de aplicación se firma con una
clave, y la ejecución de la aplicación que realiza el dispositivo
se somete a una verificación positiva de la firma. Aquí se proponen
varias realizaciones de este concepto.
En cada ejemplo, una función hash (función
resumen) obtiene un valor hash a partir del código de aplicación.
El valor hash se codifica con una clave privada de un par de claves.
La clave pública del par de claves se almacena en la memoria del
dispositivo y, ya que es una clave pública que no pertenece a un
cliente determinado, se puede almacenar en la ROM 14.
En un primer ejemplo, como puede verse en la
Figura 2A, el par de claves incluye una clave privada denominada
"SignDownPrK"; en el primer ejemplo, esta SignDownPrK es una
clave privada del diseñador de arquitectura protegida
(SADPrivateKey). La clave pública correspondiente (SADPublicKey) se
almacena en la ROM 14. En la Figura 2A, "C" es el código de
aplicación visible que se pretende descargar en el dispositivo.
Además, una firma "D" en la Figura 2A es el valor hash del
código de aplicación codificado con la clave privada.
Con referencia a la Figura 3A, donde se usan los
mismos símbolos que en la Figura 2A, C y D se reciben en el
dispositivo. Se obtiene un valor hash C' a partir de C con una
función hash que se lee de la ROM 14. D se descodifica dando D' con
la clave pública (SADPublicKey) leída de la ROM 14 mediante un
algoritmo almacenado en la ROM 14. Si C' es igual a D', el código
de aplicación C es válido y permite la ejecución por parte del
dispositivo; en otro caso, el código de aplicación C se borra. Una
vez validado el código de aplicación C, se carga en la RAM 20,
preferiblemente después de la codificación en la interfaz de
codificación RAM 18. El microprocesador 12 tendrá acceso al código
de aplicación en la RAM 20 sin que se produzca una pérdida
significativa de rendimiento incluso aunque se codifique y la
interfaz de codificación RAM 18 debe descodificarlo antes de su
ejecución, implementándose la interfaz de codificación RAM en
hardware. Como alternativa o además de lo anterior, el código de
aplicación validado se almacena permanentemente, por ejemplo, en la
memoria externa 24, aunque preferiblemente codificado.
En un segundo ejemplo, se emplea una clave
privada de cliente (CustomerPrivateKey) para codificar el valor
hash del código de aplicación C, en vez de la SADPrivateKey.
Aquí, "cliente" quiere decir una
organización que ofrece servicios y contenidos valiosos a los
usuarios finales. Normalmente, el "cliente" compra el
dispositivo de la presente invención, o al menos el ASIC 10, al
diseñador de arquitectura protegida (SAD) o a un fabricante
contratado del SAD, y distribuye el dispositivo a un usuario final
en un producto acabado.
Ahora, en una primera variante de este segundo
ejemplo, la parte pública de un par de claves de cliente se
almacena en la zona de memoria interna protegida (ISMA) 16. Como
puede verse en la Figura 3B, esa clave pública se lee en la ISMA 16
y se usa para verificar la firma D. Todas las demás fases son las
mismas que las de la Figura 3A.
En una segunda variante del segundo ejemplo, la
clave pública del diseñador de arquitectura protegida (SADPublicKey)
se almacena en la ROM 14, y la clave pública del cliente se firma
con la clave privada del diseñador de arquitectura protegida
(SADPrivateKey) y puede, por tanto, almacenarse de manera segura en
la memoria externa 24. Con referencia a la Figura 3C, la clave
pública cliente (CustomerPublicKey) primero se recupera mediante su
descodificación, con la SADPublicKey leída en la ROM 14, la clave
pública del cliente codificada leída en la memoria externa 24, y
después se verifica la firma D como en la Figura 3B.
En una tercera variante del segundo ejemplo, y
con referencia a la Figura 2B, una versión protegida de la
CustomerPublicKey (clave pública del cliente) se descarga en el
dispositivo junto con el código de aplicación C, de manera que la
CustomerPublicKey nunca estará disponible en la memoria externa 24.
En concreto, se codifica un valor hash de la CustomerPublicKey
(clave pública del cliente) con la SADPrivateKey (clave privada del
SAD) dando "F" y se descarga en el dispositivo junto con la
CustomerPublicKey (clave pública del cliente) "E". Con
referencia a la Figura 3D, la verificación de la firma de aplicación
viene precedida por una verificación de la CustomerPublicKey (clave
pública del cliente). La CustomerPublicKey (clave pública del
cliente) E descargada se resume y el valor hash E' se compara con
el resultado F' de la codificación, con la SADPublicKey (clave
pública del SAD), el valor hash codificado descargado F de la
CustomerPublicKey (clave pública del cliente). Si E' es igual a F',
se continua la verificación de la firma de aplicación D, como en la
Figura 3C; si no, se rechaza el código de aplicación C.
El código de aplicación descargado se puede
almacenar en la memoria externa 24 del dispositivo excepto para la
tercera variante del segundo ejemplo del método de descarga
firmado.
Aunque los procesos descritos aseguran hasta
ahora la autenticidad e integridad de una aplicación que a
ejecutarse en el dispositivo, otra propuesta de la invención añade
confidencialidad. En lo que se refiere a la descarga de una
aplicación, se consigue confidencialidad codificando el código de
aplicación antes de descargarlo.
Con referencia a la Figura 4, el código de
aplicación que se va a descargar en el dispositivo se codifica
dando "A" con la SADSecretKey (clave secreta SAD), una clave
simétrica del diseñador de arquitectura protegida. Un valor hash de
la aplicación se codifica dando "B" con la SADSecretKey (clave
secreta SAD). La aplicación codificada y su valor hash codificado,
A y B, se descargan ahora en el dispositivo. Con referencia a la
Figura 4B, A y B se descodifican dando A' y B', respectivamente,
usando la SADSecretKey (clave secreta SAD) leída en la zona de
memoria protegida 16. A' (el código de aplicación visible, si está
correctamente descodificado) se resume con B'', y B'' se compara
con B' (el valor hash del código de aplicación, si está
correctamente descodificado). Si B'' es igual a B', se valida el
código de aplicación descargado y descodificado; si no, se rechaza
A'.
El código de aplicación validado puede ahora ser
empleado, por ejemplo se puede almacenar permanentemente en la
memoria externa 24, aunque en la realización preferente se codifica
antes de ser almacenado.
En el esquema que se muestra en la Figura 5A, el
código de aplicación se puede obtener de la RAM 20 después de, por
ejemplo, una descarga firmada y/o codificada. Si es una aplicación
validada, se puede almacenar en la memoria externa permanente 24,
aunque preferiblemente no en su forma legible en lo que se refiere a
un código y datos de software sensibles.
En un principio, el ASIC selecciona así un
código y datos sensibles para codificarlos. Dependiendo del nivel
de seguridad y flexibilidad requeridos, se usa directamente una
clave de codificación KF o una clave derivada. Como primera opción,
la KF es la clave secreta SAD leída del área de memoria protegida
16. El código y los datos sensibles seleccionados se codifican con
esa clave y se almacenan en la memoria externa 24, junto con otros
códigos y datos no sensibles.
Como segunda opción, la KF es la clave secreta
del chip (ChipSecretKey), leída también de la zona de memoria
protegida.
Como tercera opción, se usa un número aleatorio
"RN" como clave de codificación, KF=RN, RN se codifica con la
clave secreta SAD leída de la zona de memoria protegida 16, y el
número aleatorio codificado se almacena en la memoria externa 24
como "RNEnc" (número aleatorio codificado).
Como cuarta opción, el código y los datos
sensibles se comprimen con el ASIC antes de su codificación.
Como quinta opción, se elige un número aleatorio
secreto de chip "ChipRandomNumber" de la zona de memoria
protegida 16. El ChipRandomNumber y un valor hash del mismo se
codifican dando X e Y, respectivamente, con la clave de
codificación KF. El número aleatorio codificado X y su valor hash
codificado Y se almacenan en la memoria externa 24, junto con el
código y los datos sensibles codificados y otros códigos y datos no
sensibles.
Como sexta opción, el código y los datos
sensibles se resumen y codifican con la clave KF. El EncH resultante
(valor hash codificado) se almacena en la memoria externa 24 junto
con el código y los datos sensibles codificados y otros códigos y
datos no sensibles.
Con referencia ahora a la Figura 5B, y según la
opción correspondiente de las opciones 1 a 6, tiene que determinarse
la clave adecuada KF. Con la clave KF, los contenidos codificados
de la memoria externa 24 se descodifican y pueden emplearse para
ejecutar una aplicación, por ejemplo.
Si es la opción 1, KF es la clave secreta SAD
(SADSecretKey), leída de la zona de memoria protegida 16.
Si es la opción 2, KF es la clave secreta de
chip (ChipSecretKey), leída de la zona de memoria protegida 16.
Si es la opción 3, KF se obtiene descodificando
el número aleatorio codificado RNEnc leído de la memoria externa 24
con la clave secreta SAD (SADSecret Key) leída de la zona de memoria
protegida 16.
Con la opción 4 se descomprimen los contenidos
de la memoria externa 24 antes de ser empleados.
La opción 5 requiere de una verificación de
integridad de los contenidos de la memoria externa 24. El número
aleatorio codificado X y su valor hash codificado Y se descodifican
dando X' e Y' con KF, el número aleatorio descodificado X' se
resume con Y'' y el resultado se compara con el valor hash
descodificado Y'. Si Y'' es igual a Y', se valida el contenido de
la memoria externa 24, en otro caso se rechaza.
Con la opción 6, se verifica la integridad del
código y de los datos sensibles codificados. En concreto, se lee el
valor hash codificado EncH de la memoria externa 24 y se descifra
dando H con la clave KF. Se calcula un valor hash H' a partir del
código y de los datos sensibles descodificados. Sólo si ambos
valores hash H y H' son iguales, se validan el código y los datos
sensibles descodificados.
Se entiende que las opciones 4, 5 y 6 no son
excluyentes entre si y se pueden emplear por separado o
conjuntamente con cualquiera de las opciones 1 a 3.
Para proteger además el dispositivo, la
invención propone la conexión unívoca del chip del dispositivo con
los contenidos de la memoria externa 24 (emparejamiento Memoria
Externa - ASIC).
Con referencia a la Figura 6, el código de
aplicación y los datos sensibles se identifican en la memoria
externa 24 y se codifican dando "I" con la clave secreta de
chip "ChipSecretKey", leída en la zona de memoria protegida
16, e I se almacena en la memoria externa 24. El código de
aplicación y los datos sensibles son tales que es imposible una
ejecución adecuada de la aplicación sin descifrar correctamente el
código y los datos. El generador de números aleatorios dentro del
chip del dispositivo genera un número aleatorio "RNG" que se
resume dando "K". El número aleatorio RNG y su valor hash K se
codifican dando "J" con la clave secreta de chip
"ChipSecretKey", y J también se almacena en la memoria externa
24. El chip, ahora, se conecta de forma unívoca a la memoria
externa 24.
Con referencia a la Figura 7, el chip verifica
su emparejamiento con la memoria externa 24 como mínimo después de
cada reinicialización del dispositivo. En concreto, J (el número
aleatorio codificado y su valor hash) se lee de la memoria externa
y se descifra con la "ChipSecretKey" dando "W" y "Z".
El valor hash calculado de W y Z', se compara con el valor hash
descifrado Z del número aleatorio W. Sólo si Z y Z' son iguales se
confirma el emparejamiento y se pueden recuperar el código de
aplicación y los datos sensibles de I leídos en la memoria externa
descifrando I; en otro caso, se toman medidas para evitar un uso
involuntario del dispositivo.
Inmediatamente después de su fabricación, el
chip del dispositivo sólo tiene una funcionalidad básica mediante
software y datos almacenados en la ROM 14. El software almacenado
inicialmente en la ROM 14 incluye un proceso de reinicialización,
una rutina de descarga, una biblioteca criptográfica y otras
funciones básicas. Los datos iniciales almacenados en la ROM 14
incluyen un Número de Serie, la clave pública SAD (SADPublicKey) y
un valor hash sobre el contenido de la ROM. La zona de memoria
protegida 16 se vacía y el chip queda indefenso ante usos
involuntarios.
Por tanto, según otra propuesta de la invención,
el chip se personaliza antes de ser distribuido al cliente.
Con referencia a la Figura 8, un primer nivel de
personalización del chip incluye almacenar una clave de
personalización secreta simétrica "PersoSecretKey" en la zona
de memoria protegida 16 (ISMA). Se actualiza un campo de información
interna de la zona de memoria protegida 16, "ISMAinfo", para
indicar que la "PersoSecretKey" está disponible. Se calcula un
valor hash ISMAContentHash del contenido de la zona de memoria
protegida 16 y también se almacena en la zona de memoria
protegida.
El chip puede enviarse ahora a un cliente donde
se hace un segundo nivel de personalización antes de distribuir el
chip a un usuario final en el interior de un producto. Por otro
lado, el diseñador de arquitectura protegida (SAD) puede realizar
previamente el segundo nivel de personalización antes de enviar el
chip al cliente o al usuario final.
Con referencia a la Figura 9, se ilustra un
segundo nivel de personalización que puede ser realizado por el
diseñador de arquitectura protegida o por un cliente. El diseñador
de arquitectura protegida proporciona una aplicación de
personalización especial cuya finalidad es incluirla en los datos
sensibles del dispositivo y en la información que se refiere al uso
deseado del mismo. Para descargarla en el dispositivo, la aplicación
de personalización "PersoAppli" se encripta con la clave de
personalización secreta "PersoSecretKey", y se calcula un
valor hash del código de aplicación y se firma con una clave privada
del diseñador de arquitectura protegida "SADPrivateKey". Como
alternativa, tanto el código de aplicación como su valor hash
firmados con la "SADPrivateKey" se codifican con la clave
simétrica secreta "PersoSecretKey" y se descargan en el
dispositivo. El dispositivo puede descifrar el código de aplicación
codificado con la "PersoSecretKey" leída de la zona de memoria
protegida 16 y verificar la firma de su valor hash con la
"SADPublicKey" leída de la ROM 14. Una vez que el dispositivo
ha ejecutado la aplicación de personalización, todos los datos y la
información sensibles se han incluido en el dispositivo, se
actualiza "ISMAInfo", se calcula y almacena un nuevo
"ISMAContentHash", se borra la "PersoSecretKey" y también
se borra la aplicación.
Como queda claro de la descripción anterior, el
método de la presente invención requiere acceso a partes protegidas
del chip para iniciarlo con datos confidenciales y sensibles básicos
y, en concreto, con aquellos incluidos en la zona de memoria
protegida 16. Con miras a proteger el chip contra accesos no
autorizados a partes sensibles, la invención propone usar un canal
de acceso secreto para acceder a partes sensibles del
dispositivo.
Con referencia a la Figura 10, el ASIC incluye
un cuerpo central de silicio 30 con varias conexiones de chip
internas 32 y varios terminales externos 34 (clavijas o
adaptadores). Dentro del paquete 36 del ASIC, una hilera interna de
líneas conductoras paralelas 38 permite conectar cualquiera de las
conexiones internas del chip a cualquiera de los terminales
externos 34. Al menos algunas de las asignaciones entre las
conexiones internas del chip 32 y los terminales externos 34 son
variables y se materializan mediante interruptores de accionamiento
selectivo tales como los interruptores 40, 42 en la Figura 10. Para
establecer un canal de acceso secreto, los interruptores
seleccionados 40, 42 se cierran y, después de usar el canal secreto
durante las fases de personalización anteriores, se pueden abrir y
dejar abiertos.
Siempre que se detecte una intrusión de
cualquier tipo, se toman medidas adecuadas para evitar que el
dispositivo se use de manera involuntaria. Normalmente, los
contenidos de la zona de memoria protegida 16 se borran.
Con referencia a la Figura 11, el ASIC 10
incluye un detector de intrusión 50. En un ejemplo, la zona de
memoria protegida 16 dentro del ASIC 10 es una RAM que necesita una
alimentación de energía continua para mantener la información
almacenada en su interior. La zona de memoria protegida 16 (RAM)
recibe la energía de una batería externa 52 conectada a un
alimentador externo y a las terminales de tierra del ASIC. Un
interruptor controlable 54 se introduce en el conducto de
alimentación de la zona de memoria 16. El interruptor 54 está
normalmente cerrado y se controla mediante el detector de intrusión
50. El detector de intrusión 50 tiene varias entradas conectadas a
los dispositivos de monitorización correspondientes. Uno de tales
dispositivos de monitorización puede ser un fototransistor 56 que
detecte cualquier luz que atraviese el paquete del chip al atacar
físicamente su envuelta. Otro dispositivo de monitorización puede
ser un sensor de temperatura 58 que detecte cualquier temperatura
anormal. El detector de intrusión 50 también se conecta a la fuente
de alimentación del dispositivo principal y a tierra y detecta
cualquier tensión de alimentación o consumo de energía anormales.
Aún otra entrada al detector de intrusión 50 se conecta al
generador de sincronía del sistema 60 y detecta cualquier
frecuencia anormal del reloj. Un controlador de secuencia 62
conectado a otra entrada del detector de intrusión 50 detecta
cualquier ausencia anormal de actividad del microprocesador 12 en un
momento dado. Cualquier fallo en la comprobación de la integridad,
autenticidad o firma también se comunica desde el microprocesador 12
al detector de intrusión 50.
Cualquier condición anormal informada al
detector de intrusión 50 mediante cualquiera de los dispositivos de
monitorización hace que el interruptor 54 se abra y que se borre
cualquier información de la zona de memoria protegida 16.
Claims (10)
1. Método de protección de un dispositivo contra
un uso involuntario en un entorno protegido, adaptado el
dispositivo para ejecutar aplicaciones que implican un control de
acceso a al menos uno de los contenidos y servicios valiosos e
incluyendo el dispositivo un circuito integrado (10) con una unidad
de procesamiento central (12), una memoria interna (14, 16) y
conexiones de entrada/salida para la memoria externa (20, 24)
incorporadas en un único chip, donde
- -
- dicha memoria externa (24) y dicho chip se conectan de manera inequívoca por encriptación de un código de aplicación y datos sensibles con una clave secreta almacenada en una zona de la memoria protegida (16) de la memoria interna, almacenándose después el código codificado y los datos codificados en la memoria externa (24), caracterizado porque
- -
- también se encriptan un número aleatorio y un valor hash del número aleatorio con dicha clave secreta y se almacenan en la memoria externa (24), el número aleatorio codificado y el valor hash se descodifican con la clave secreta al menos en cada reinicialización del dispositivo, y la descodificación del código y los datos sensibles encriptados sólo se permite si el valor hash descodificado es igual a un valor hash calculado a partir del número aleatorio descifrado.
2. Método según la reivindicación 1,
caracterizado porque el código de aplicación se descarga en
el dispositivo, se encripta con la clave secreta y se almacena en
la memoria externa (24).
3. Método según la reivindicación 1 ó 2,
caracterizado porque el dispositivo está adaptado para
ejecutar aplicaciones que implican transacciones seguras y/o un
control de acceso a contenidos y/o servicios valiosos; y porque
cualquier código de aplicación descargado en el dispositivo es
firmado con una clave privada de un par de claves asimétricas y la
ejecución correcta de la aplicación se somete a una verificación de
la firma con una clave pública de dicho par de claves.
4. Método según cualquiera de las
reivindicaciones anteriores, caracterizado porque después de
la fabricación del chip y antes de su distribución a un cliente, se
establece un canal de acceso confidencial para escribir una clave
de personalización secreta dentro de la zona de memoria protegida
(16).
5. Método según la reivindicación 4,
caracterizado porque el contenido de la zona de memoria
protegida (16) se protege mediante el cálculo de un valor hash del
contenido de la zona de memoria protegida y escribiendo el valor
hash en la zona de memoria protegida.
6. Método según la reivindicación 4 ó 5,
caracterizado porque se firma una aplicación de
personalización con una clave privada del diseñador de arquitectura
protegida y después se encripta con la clave de personalización
secreta, la aplicación de personalización se descarga en el
dispositivo y se descodifica con la clave de personalización
secreta, la firma de la aplicación de personalización se verifica
con la clave pública del diseñador de arquitectura protegida, y la
aplicación de personalización se ejecuta para escribir datos de
personalización sensibles en la zona de memoria protegida (16).
7. Método según la reivindicación 4 ó 5
caracterizado porque una aplicación de personalización se
encripta con una clave simétrica secreta almacenada en la zona de
memoria protegida (16) del dispositivo, un valor hash de la
aplicación de personalización se firma con una clave privada del
diseñador de arquitectura protegida, la aplicación de
personalización codificada y el valor hash firmado se cargan en el
dispositivo, la aplicación de personalización se descodifica con la
clave simétrica confidencial, la firma del valor hash se verifica
con la clave pública del diseñador de arquitectura protegida
almacenada en la memoria de sólo lectura (14) del dispositivo y la
aplicación de personalización se ejecuta para escribir los datos de
personalización sensibles en la zona de memoria protegida.
8. Método según la reivindicación 4 ó 5,
caracterizado porque una aplicación de personalización y un
valor hash de la aplicación de personalización, firmado con la clave
privada del diseñador de arquitectura protegida se encriptan con
una clave simétrica secreta almacenada en la zona de memoria
protegida (16) del dispositivo, la aplicación de personalización
codificada y el valor hash firmado se cargan en el dispositivo, la
aplicación de personalización y el valor hash firmado se
descodifican con la clave simétrica secreta, la firma del valor
hash se verifica con la clave pública del diseñador de arquitectura
protegida almacenada en la memoria de sólo lectura del dispositivo
y la aplicación de personalización se ejecuta para escribir datos
de personalización sensibles en la zona de memoria protegida.
9. Método según cualquiera de las
reivindicaciones anteriores, caracterizado porque la memoria
externa (20, 24) incluye una RAM (memoria de acceso aleatorio) (20)
y el chip tiene una interfaz hardware de
codificación/descodifica-
ción bidireccional que garantiza un alto rendimiento y un intercambio ya codificado de datos entre el chip y la RAM.
ción bidireccional que garantiza un alto rendimiento y un intercambio ya codificado de datos entre el chip y la RAM.
10. Método según cualquiera de las
reivindicaciones 1 a 9, caracterizado porque dicho chip está
provisto de un generador de números aleatorios y a partir de un
número aleatorio producido por el generador de números aleatorios
se obtiene un valor hash, el número aleatorio con su valor hash se
codifican con dicha clave secreta, y el número aleatorio encriptado
con su valor hash se almacena en la memoria externa (24).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10200288 | 2002-01-07 | ||
| DE10200288A DE10200288A1 (de) | 2002-01-07 | 2002-01-07 | Eine Vorrichtung zur Ausführung von Anwendungen, die sichere Transaktionen und/oder Zugangskontrolle zu werthaltigen Inhalten und/oder Dienstleistungen umfassen, und Verfahren zum Schutz einer solchen Vorrichtung |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2275075T3 true ES2275075T3 (es) | 2007-06-01 |
Family
ID=7711584
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03701491T Expired - Lifetime ES2275075T3 (es) | 2002-01-07 | 2003-01-07 | Proteccion de un dispositivo contra un uso involuntario en un entorno protegido. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20050125681A1 (es) |
| EP (1) | EP1461681B1 (es) |
| KR (1) | KR20040068614A (es) |
| AT (1) | ATE342548T1 (es) |
| AU (1) | AU2003202545A1 (es) |
| DE (2) | DE10200288A1 (es) |
| ES (1) | ES2275075T3 (es) |
| WO (1) | WO2003058409A2 (es) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2837944B1 (fr) * | 2002-03-26 | 2004-07-09 | Oberthur Card Syst Sa | Procede et dispositif de validation automatique d'un programme informatique utilisant des fonctions de cryptographie |
| DE10340861A1 (de) * | 2003-09-04 | 2005-04-07 | Infineon Technologies Ag | Prozessorschaltung und Verfahren zum Zuordnen eines Logikchips zu einem Speicherchip |
| US7664966B2 (en) * | 2004-05-17 | 2010-02-16 | Microsoft Corporation | Secure storage on recordable medium in a content protection system |
| US7602910B2 (en) * | 2004-11-17 | 2009-10-13 | Microsoft Corporation | Password protection |
| FR2885709A1 (fr) * | 2005-05-10 | 2006-11-17 | St Microelectronics Sa | Controle d'integrite d'une memoire externe a un processeur |
| US20070101156A1 (en) * | 2005-10-31 | 2007-05-03 | Manuel Novoa | Methods and systems for associating an embedded security chip with a computer |
| WO2007076610A1 (en) * | 2006-01-06 | 2007-07-12 | Verichk Global Technologies Inc. | Secure access to information associated with a value item |
| DE102006006109A1 (de) * | 2006-02-10 | 2007-08-16 | Robert Bosch Gmbh | Verfahren zum Manipulationsschutz eines Steuergeräts sowie gegen Manipulationen geschütztes Steuergerät |
| US7793110B2 (en) * | 2006-05-24 | 2010-09-07 | Palo Alto Research Center Incorporated | Posture-based data protection |
| US8209542B2 (en) * | 2006-12-29 | 2012-06-26 | Intel Corporation | Methods and apparatus for authenticating components of processing systems |
| US8761402B2 (en) * | 2007-09-28 | 2014-06-24 | Sandisk Technologies Inc. | System and methods for digital content distribution |
| US20100310076A1 (en) * | 2009-06-04 | 2010-12-09 | Ron Barzilai | Method for Performing Double Domain Encryption in a Memory Device |
| US9083685B2 (en) * | 2009-06-04 | 2015-07-14 | Sandisk Technologies Inc. | Method and system for content replication control |
| US8484481B2 (en) * | 2009-07-14 | 2013-07-09 | International Business Machines Corporation | Chip lockout protection scheme for integrated circuit devices and insertion thereof |
| US8812854B2 (en) * | 2009-10-13 | 2014-08-19 | Google Inc. | Firmware verified boot |
| US20110099423A1 (en) * | 2009-10-27 | 2011-04-28 | Chih-Ang Chen | Unified Boot Code with Signature |
| US9235719B2 (en) * | 2011-09-29 | 2016-01-12 | Intel Corporation | Apparatus, system, and method for providing memory access control |
| US8805850B2 (en) * | 2012-05-23 | 2014-08-12 | International Business Machines Corporation | Hardware-accelerated relational joins |
| US9641339B2 (en) | 2013-07-31 | 2017-05-02 | Arista Networks, Inc. | System and method for authentication for field replaceable units |
| KR20160014464A (ko) * | 2014-07-29 | 2016-02-11 | 삼성전자주식회사 | 메모리 시스템 및 이의 데이터 보호 방법 |
| US10896267B2 (en) * | 2017-01-31 | 2021-01-19 | Hewlett Packard Enterprise Development Lp | Input/output data encryption |
| US11625711B2 (en) * | 2018-04-24 | 2023-04-11 | Duvon Corporation | Autonomous exchange via entrusted ledger key management |
| US11443072B2 (en) * | 2018-06-29 | 2022-09-13 | Microsoft Technology Licensing, Llc | Peripheral device with resource isolation |
| US11126757B2 (en) * | 2018-10-19 | 2021-09-21 | Microsoft Technology Licensing, Llc | Peripheral device |
| EP3663959B1 (en) * | 2018-12-06 | 2021-08-11 | Mastercard International Incorporated | An integrated circuit, method and computer program |
| CN114629641B (zh) * | 2022-03-17 | 2022-10-25 | 江南信安（北京）科技有限公司 | 基于安全芯片的代码下载启动安全保护方法及装置 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5887131A (en) * | 1996-12-31 | 1999-03-23 | Compaq Computer Corporation | Method for controlling access to a computer system by utilizing an external device containing a hash value representation of a user password |
| US5983273A (en) * | 1997-09-16 | 1999-11-09 | Webtv Networks, Inc. | Method and apparatus for providing physical security for a user account and providing access to the user's environment and preferences |
| US6061449A (en) * | 1997-10-10 | 2000-05-09 | General Instrument Corporation | Secure processor with external memory using block chaining and block re-ordering |
| US6266754B1 (en) * | 1998-05-29 | 2001-07-24 | Texas Instruments Incorporated | Secure computing device including operating system stored in non-relocatable page of memory |
| CA2309627A1 (en) * | 1998-09-25 | 2000-04-06 | Hughes Electronics Corporation | An apparatus for providing a secure processing environment |
| US6292874B1 (en) * | 1999-10-19 | 2001-09-18 | Advanced Technology Materials, Inc. | Memory management method and apparatus for partitioning homogeneous memory and restricting access of installed applications to predetermined memory ranges |
| FR2810138B1 (fr) * | 2000-06-08 | 2005-02-11 | Bull Cp8 | Procede de stockage securise d'une donnee sensible dans une memoire d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede |
| JP2002014871A (ja) * | 2000-06-29 | 2002-01-18 | Fujitsu Ltd | コンテンツチェック方法、コンテンツ更新方法、および処理装置 |
-
2002
- 2002-01-07 DE DE10200288A patent/DE10200288A1/de not_active Withdrawn
-
2003
- 2003-01-07 US US10/500,983 patent/US20050125681A1/en not_active Abandoned
- 2003-01-07 AT AT03701491T patent/ATE342548T1/de not_active IP Right Cessation
- 2003-01-07 AU AU2003202545A patent/AU2003202545A1/en not_active Abandoned
- 2003-01-07 KR KR10-2004-7010610A patent/KR20040068614A/ko not_active Application Discontinuation
- 2003-01-07 DE DE60308990T patent/DE60308990T2/de not_active Expired - Fee Related
- 2003-01-07 WO PCT/EP2003/000075 patent/WO2003058409A2/en active IP Right Grant
- 2003-01-07 EP EP03701491A patent/EP1461681B1/en not_active Expired - Lifetime
- 2003-01-07 ES ES03701491T patent/ES2275075T3/es not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| WO2003058409A3 (en) | 2004-06-17 |
| KR20040068614A (ko) | 2004-07-31 |
| DE60308990D1 (de) | 2006-11-23 |
| WO2003058409A2 (en) | 2003-07-17 |
| ATE342548T1 (de) | 2006-11-15 |
| EP1461681B1 (en) | 2006-10-11 |
| DE10200288A1 (de) | 2003-07-17 |
| DE60308990T2 (de) | 2007-06-14 |
| US20050125681A1 (en) | 2005-06-09 |
| EP1461681A2 (en) | 2004-09-29 |
| AU2003202545A1 (en) | 2003-07-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2275075T3 (es) | Proteccion de un dispositivo contra un uso involuntario en un entorno protegido. | |
| ES2632795T3 (es) | Sistema de pago | |
| JP3782059B2 (ja) | アルゴリズムコードを記憶するための揮発性メモリを備える機密保護モジュール | |
| CA2780717C (en) | A method of assigning a secret to a security token, a method of operating a security token, storage medium and security token | |
| ES2202344T3 (es) | Procedimiento de carga de una zona de memoria protegida de un dispositivo de tratamiento de la informacion y dispositivo asociado. | |
| ES2318302T3 (es) | Prueba de ejecucion que utiliza funcion aleatoria. | |
| CN103415855A (zh) | 大容量存储设备存储器加密方法、***及装置 | |
| WO2010005425A1 (en) | Systems and method for data security | |
| CN102737180A (zh) | 用于数字权利管理的集成电路 | |
| CN101978647A (zh) | 保护智能卡 | |
| ES2826977T3 (es) | Programación segura de datos secretos | |
| ES2328983T5 (es) | Procedimiento y dispositivo para acordar una clave común entre un primer aparato de comunicaciones y un segundo aparato de comunicaciones | |
| JP4475386B2 (ja) | チップカードの初期化 | |
| CN103370718B (zh) | 使用分布式安全密钥的数据保护方法、设备和*** | |
| ES2627735T3 (es) | Método para acceso seguro a un contenido audio/vídeo en una unidad de descodificación | |
| US8413906B2 (en) | Countermeasures to secure smart cards | |
| KR101214899B1 (ko) | 유에스비 보안장치 및 그 보안 방법 | |
| KR101256373B1 (ko) | 장착식 스마트 카드와 메모리 카드를 구비한 유에스비 보안장치 및 그 보안 방법 | |
| Token | Security Policy | |
| Card | FIPS 140-2 Security Policy for HiCOS Combi PKI Native Smart Card Cryptographic Module | |
| Cryptographic | FIPS 140-2 Security Policy for HiCOS PKI Native Smart Card Cryptographic Module | |
| KR101610182B1 (ko) | 원격서비스 시스템의 클라이언트 단말기 보안장치 및 그 방법 | |
| IDflex | Document Version: 1.0 Date: May 2, 2012 | |
| KR19980050317U (ko) | 보호키를 내장한 pcmcia 장치 | |
| Applet | Chunghwa Telecom Co., Ltd. HICOS PKI Smart Card Chip Security Policy |