ES2318302T3 - Prueba de ejecucion que utiliza funcion aleatoria. - Google Patents
Prueba de ejecucion que utiliza funcion aleatoria. Download PDFInfo
- Publication number
- ES2318302T3 ES2318302T3 ES04744002T ES04744002T ES2318302T3 ES 2318302 T3 ES2318302 T3 ES 2318302T3 ES 04744002 T ES04744002 T ES 04744002T ES 04744002 T ES04744002 T ES 04744002T ES 2318302 T3 ES2318302 T3 ES 2318302T3
- Authority
- ES
- Spain
- Prior art keywords
- program
- security
- execution
- mode
- function
- 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 OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/22—Microcontrol or microprogram arrangements
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
-
- 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/321—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 a third party or a trusted authority
-
- 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/3271—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 using challenge-response
- H04L9/3278—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 using challenge-response using physically unclonable functions [PUF]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2129—Authenticate client device independently of the user
-
- 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)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Storage Device Security (AREA)
- Debugging And Monitoring (AREA)
- Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
- Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)
Abstract
Procedimiento para probar la autenticidad de la ejecución de instrucciones de programa, que comprende: - una etapa de ejecutar instrucciones de programa bajo el control de un programa (403) de seguridad en un dispositivo (103, 202) de seguridad que comprende una función (104,203) aleatoria, siendo la función aleatoria accesible únicamente desde el programa de seguridad a través de una interfaz controlada, comprendiendo la interfaz controlada al menos una función primitiva que accede a la función aleatoria que devuelve una salida que depende de al menos parte de una representación de al menos aquellas partes del programa de seguridad que llaman a la función primitiva, - una etapa de, utilizando la función aleatoria, calcular resultados de prueba durante la ejecución del programa de seguridad que opera en un primer modo (404) accediendo a la función aleatoria a través de la interfaz controlada, y - una etapa de, utilizando la función aleatoria, verificar los resultados de prueba durante la ejecución del mismo programa de seguridad que opera en un segundo modo (405) accediendo a la función aleatoria a través de la interfaz controlada.
Description
Prueba de ejecución que utiliza función
aleatoria.
La invención se refiere a un procedimiento para
probar la autenticidad de una ejecución de programa, a un sistema
dispuesto para implantar un procedimiento de este tipo, a un
producto de programa informático para implementar un procedimiento
de este tipo, a instrucciones ejecutables por ordenador para
implementar un procedimiento de este tipo, y a una señal que
transporta resultados de prueba generados por un procedimiento de
este tipo.
En aplicaciones tales como transacciones
electrónicas puede requerirse verificar que realmente se ha
ejecutado un cálculo (o programa) en un procesador específico, ya
sea por un usuario o por un tercero. En "Controlled Physical
Random Functions", de Blaise Gassend y Dwaine Clarke y Marten
van Dijk y Srinivas Devadas, Proceedings of the 18th Annual
Computer Security Applications Conference, diciembre de 2002 (en
lo sucesivo denominado como "documento de la técnica
anterior"), se define ejecución certificada como un proceso que
produce, junto con la salida de cálculo, un certificado (denominado
certificado electrónico) que prueba al usuario de un chip de
procesador específico que se ha llevado a cabo un cálculo específico
en ese chip de procesador específico, y que el cálculo se ejecutó y
se produjo la salida de cálculo dada.
El marco utilizado en el documento de la técnica
anterior para la generación y verificación de un certificado
electrónico se construye sobre el concepto de una función aleatoria
física. Una función aleatoria física (PUF, Physical Random
Function) es una función aleatoria que se evalúa con ayuda de un
sistema físico complejo. El uso de la abreviatura PUF (en lugar de
PRF) tiene la ventaja de ser más sencilla de pronunciar, y evita la
confusión con funciones pseudoaleatorias
(Pseudo-Random Functions). Las PUF pueden
implementarse de diferentes formas. Algunas de las implementaciones
de PUF son fáciles de producir de tal manera que cada muestra de
producción (por ejemplo cada chip semiconductor individual)
implementa una función diferente. Esto permite utilizar una PUF en
aplicaciones de identificación autenticada.
Una PUF es una función que mapea desafíos con
respuestas, que está materializada en un dispositivo físico y que
tiene las siguientes dos propiedades: (1) la PUF es fácil de
evaluar: el dispositivo físico puede evaluar fácilmente la función
en un periodo de tiempo corto, y (2) la PUF es difícil de
caracterizar: a partir de un número polinómico de mediciones
físicas plausibles (en particular, determinación de pares
desafío-respuesta escogidos), un atacante que ya no
tiene (acceso a) el dispositivo de seguridad, y que sólo puede
utilizar una cantidad polinómica de recursos (tiempo, contenido,
etc.) sólo puede extraer una cantidad insignificante de información
acerca de la respuesta a un desafío escogido de manera aleatoria. En
la definición anterior, los términos corto y polinómico se refieren
al tamaño del dispositivo, que es el parámetro de seguridad. En
particular, corto significa polinomio lineal o de grado bajo. El
término plausible se refiere al estado actual de la técnica en
cuanto a técnicas de medición y es probable que cambie a medida que
se ideen procedimientos mejorados.
Ejemplos de PUF son PUF de silicio (Blaise
Gassend y Dwaine Clarke y Marten van Dijk y Srinivas Devadas,
Silicon Physical Random Funtions, Proceedings of the 9th ACM
Conference on Computer and Communications Security, noviembre
de 2002), PUF ópticas (P. S. Ravikanth, Massachusetts Institute
of Technology, Physical One-Way Functions,
2001), y PUF digitales. Las PUF de silicio utilizan variaciones
entre chips que se deben al proceso de fabricación. Las PUF ópticas
emplean la impredecibilidad de la interferometría de moteado
generada por estructuras ópticas que se irradian con un haz de luz
(láser) coherente. Las PUF digitales se refieren al clásico
escenario en el que un entorno de seguridad frente a violaciones
protege una clave secreta, que se usa con fines de cifrado y
autenticación.
Una PUF se define como controlada (una PUF
controlada o CPUF) si sólo puede accederse a ella a través de un
algoritmo de seguridad que normalmente está conectado a la PUF de
manera inseparable dentro de un dispositivo de seguridad (es decir,
cualquier intento de burlar el algoritmo llevará a la destrucción de
la PUF). En particular este algoritmo de seguridad puede restringir
los desafíos que se presentan a la PUF y puede limitar la
información acerca de las respuestas que se dan al exterior. El
control es la idea fundamental que permite a las PUF ir más allá de
simples aplicaciones de identificación autenticadas.
Un ejemplo de una CPUF se describe en el
documento de la técnica anterior. Un programa de seguridad se
utiliza bajo el control del algoritmo de seguridad, conectado a la
PUF, de modo que sólo puede accederse a la PUF a través de dos
funciones primitivas GetSecret(.) y GetResponse(.) del programa de
seguridad. GetSecret(.) garantiza que la entrada a la PUF depende
de una representación del programa de seguridad desde la que se
ejecutan las funciones primitivas. GetResponse(.) garantiza que la
salida de la PUF depende de una representación del programa de
seguridad desde la que se ejecutan las funciones primitivas. Debido
a esta dependencia, la entrada a la PUF y la salida de la PUF serán
diferentes si estas funciones primitivas se ejecutan desde un
programa de seguridad diferente. Además, estas funciones primitivas
garantizan que la generación de nuevos pares
desafío-respuesta puede regularse y ser segura, tal
como se describe también en el documento de la técnica anterior.
La ejecución certificada (tal como se describe
en el documento de la técnica anterior) utiliza la primitiva
GetSecret(.) sobre un desafío para el que el usuario puede calcular
la salida basándose en un par desafío-respuesta de
la PUF secreto que sólo conoce el usuario. De este modo, la salida
puede utilizarse con respecto al usuario para probar que ejecutó un
algoritmo en el chip de procesador específico con el algoritmo de la
PUF.
\global\parskip0.900000\baselineskip
Sin embargo, el usuario no puede usar la salida
para probar a un tercero que el programa se ejecutó activamente en
un procesador específico, porque el usuario podría haber producido
el resultado por sí mismo utilizando su par
desafío-respuesta. Sin embargo, en por ejemplo
sistemas de transacción electrónicos, a menudo es deseable poder
probar realmente a un tercero que un programa (tal como un programa
para pagar una tarifa para ver un programa) se ha ejecutado en un
procesador específico.
La publicación de patente US6.308.270 B1 enseña
un procedimiento para certificar la ejecución de un programa de
software.
Por lo tanto es un objeto de la invención
proporcionar un procedimiento que permita la generación de
resultados de prueba, que pueden utilizarse como una prueba de
ejecución para un cálculo específico en un procesador específico,
denominada prueba electrónica, como un certificado que es
verificable por cualquier tercero.
Este objeto se realiza mediante un procedimiento
para probar la autenticidad de ejecución de instrucciones de
programa, que comprende -una etapa de ejecutar instrucciones de
programa bajo el control de un programa de seguridad en un
dispositivo de seguridad que comprende una función aleatoria, siendo
la función aleatoria accesible únicamente desde el programa de
seguridad a través de una interfaz controlada, comprendiendo la
interfaz controlada al menos una función primitiva que accede a la
función aleatoria que devuelve una salida que depende de al menos
parte de una representación de al menos aquellas partes del programa
de seguridad que llaman a la función primitiva, -una etapa de,
utilizando la función aleatoria, calcular resultados de prueba
durante la ejecución del programa de seguridad que opera en un
primer modo que accede a la función aleatoria a través de la
interfaz controlada, y -una etapa de, utilizando la función
aleatoria, verificar los resultados de prueba durante la ejecución
del mismo programa de seguridad que opera en un segundo modo
accediendo a la función aleatoria a través de la interfaz
controlada.
El programa de seguridad puede ejecutarse en
modos diferentes de operación, o bien en el mismo o bien en
diferentes ciclos de ejecución. Al tener al menos dos modos de
operación en el mismo programa, el programa de seguridad puede
utilizar ventajosamente la función aleatoria en diferentes
ejecuciones de programa. Puesto que la función primitiva que accede
a la función aleatoria depende también de la representación de al
menos parte del programa de seguridad, que es el mismo programa de
seguridad que opera en modos diferentes, el acceso a la función
aleatoria se garantiza para el programa de seguridad en estos modos
diferentes, y ningún otro programa de seguridad puede acceder a la
función aleatoria de un modo que comprometa la seguridad ofrecida
por la función aleatoria. El programa "multimodo" es por lo
tanto un concepto ventajoso ya que la funcionalidad en los otros
modos ya se ha definido claramente y limitado durante la primera vez
en la que se ejecuta el programa de seguridad.
Al hacer que la salida dependa de una
representación del programa de seguridad, (casi) se garantiza que
cualquier otro programa de seguridad que se ejecute en el
dispositivo de seguridad obtenga resultados diferentes para la
misma entrada a través de la interfaz controlada. Cualquier otro
programa de seguridad, por ejemplo diseñado por un pirata
informático para obtener información para generar resultados
ilícitos de prueba, obtiene (con una alta probabilidad dependiendo
del procedimiento de representación) únicamente resultados inútiles
a través de la interfaz controlada dado que los resultados dependen
de la representación del programa de seguridad, que es diferente
para el programa de seguridad original y el programa de seguridad
utilizado por el pirata informático.
La representación del programa de seguridad
podría ser una firma hash u otra, o una parte de la misma.
Normalmente, la representación del programa de seguridad abarca el
programa de seguridad completo, pero en casos especiales (por
ejemplo cuando el programa de seguridad contiene partes grandes que
no incumben a la función aleatoria) podría ser ventajoso limitar la
representación a aquellas partes del programa de seguridad que
tratan la llamada y el tratamiento de la entrada y salida de las
funciones primitivas.
Durante la ejecución del programa de seguridad,
puede obtenerse una clave utilizando una función primitiva cuya
salida depende también de una representación del programa de
seguridad. Esta clave puede utilizarse para cifrar (parte de) los
resultados de prueba. Cualquier resultado que esté cifrado mediante
esta clave es inútil excepto en ejecuciones posteriores del mismo
programa de seguridad, ya sea en el mismo o en un modo
diferente.
El programa de seguridad se proporciona
normalmente por el usuario del dispositivo de seguridad. También
podría ser un subsistema diferente u otro sistema.
Para permitir una rápida recuperación de un
programa de seguridad específico para un uso posterior, el código
de programa podría por lo tanto almacenarse, o un código hash
del mismo, para la ejecución posterior del programa de seguridad en
el mismo o en un modo diferente, opcionalmente junto con información
acerca del permiso de a quién se permite la ejecución
posterior.
Utilizando este procedimiento, pueden utilizarse
CPUF para producir como resultados de prueba una prueba de
ejecución, denominada prueba electrónica, que es un certificado
verificable por cualquier tercero. Por ejemplo, en una aplicación
STB un distribuidor de radiodifusión se comunica con el STB para
vender contenido a su propietario (o a quien lo alquila). El
distribuidor de radiodifusión utiliza el STB del propietario y
quiere realizar una ejecución certificada del programa que incluye
la transacción entre el propietario y el distribuidor de
radiodifusión. El distribuidor de radiodifusión quiere habilitar
cualquier árbitro para que verifique que el propietario ha comprado
el contenido. Esto requiere una prueba de ejecución. Otras
aplicaciones son transacciones electrónicas en comercio
electrónico, banca electrónica y negocio electrónico.
\global\parskip1.000000\baselineskip
Una primera realización de la invención se
describe en la reivindicación 2. Los resultados de prueba pueden
utilizarse como una prueba de ejecución, denominada prueba
electrónica, como un certificado para la (posiblemente posterior)
verificación mediante el dispositivo de seguridad hacia cualquier
tercero, sin que se requiera intervención del usuario original del
dispositivo de seguridad. Cualquier tercero con acceso a la prueba
electrónica puede verificar, utilizando los resultados de prueba y
el dispositivo de seguridad, si el dispositivo de seguridad ha
producido realmente la prueba electrónica.
Una implementación ventajosa de la primera
realización de la invención se describe en la reivindicación 3. En
esta variación, el programa de seguridad que produce los resultados
de prueba en el primer modo (denominado adicionalmente en esta
realización como: modo de ejecución) también ejecuta el programa de
aplicación real en el modo de ejecución. En el segundo modo (que se
denominará como: modo de verificación) el programa de seguridad
verifica y opcionalmente descifra los resultados de prueba. Cuando
el programa de seguridad ejecuta un programa de aplicación como
parte del modo de ejecución, los resultados de prueba se extienden a
la ejecución auténtica del programa de aplicación. Los resultados
de prueba pueden contener (partes de) el programa de aplicación,
(partes de) la entrada del programa de aplicación, y (partes de) la
salida del programa de aplicación, para garantizar que la
verificación puede abarcar la verificación de qué programa de
aplicación se ha ejecutado, y/o qué entrada y salida se utilizó o,
respectivamente, se generó. Además, esto puede permitir la
recuperación (parcial) de esta información en el modo de arbitraje.
Dependiendo de la aplicación, su finalidad y la política de
seguridad, es decisión del programa de seguridad si se emiten como
salida estas partes descifradas.
Una implementación adicional de la primera
realización de la invención se describe en la reivindicación 4. En
esta variación, un tercero, en posesión de resultados de prueba
generados por un programa de seguridad específico que operó en el
primer modo, envía los resultados de prueba al dispositivo de
seguridad como entrada para ejecutar el mismo programa de
seguridad, que se ejecuta a continuación en un segundo modo para
verificar (y opcionalmente recuperar mediante descifrado) los
resultados de prueba y a continuación envía una evidencia
convincente (y opcionalmente los resultados descifrados) de vuelta
al tercero. Esta información está diseñada para convencer al
tercero de que los resultados de prueba se calcularon en un primer
modo por el mismo dispositivo de seguridad y por el mismo programa
de seguridad.
Una segunda realización de la invención se
describe en la reivindicación 5. En esta segunda realización, los
resultados de prueba comprenden datos de almacenamiento
(posiblemente cifrados) que se utilizarán para un almacenamiento de
datos seguro. Asociando el primer modo con un almacén de memoria, y
el segundo modo con una operación de carga de memoria, pueden
almacenarse resultados de prueba que comprenden datos (cifrados) en
una ubicación de memoria. De este modo una memoria física no segura
puede hacerse segura verificando/autenticando los contenidos de la
memoria al acceder a la memoria. Tanto el primer como el segundo
modo pueden utilizarse múltiples veces en el mismo o en diferentes
ciclos de ejecución del programa de seguridad.
Una posible implementación de la segunda
realización de la invención se describe en la reivindicación 6. Al
cifrar los datos almacenados en los resultados de prueba, los datos
almacenados no pueden recuperarse de los resultados de prueba
excepto por el propio programa de seguridad. El programa de
seguridad decide si (partes de) estos datos se emiten como salida
al exterior.
Una tercera realización de la invención se
describe en la reivindicación 7. Esta realización es ventajosa
porque permite almacenar información de estado acerca de la
ejecución de programa. Esto permite a un programa continuar de
manera fiable sustancialmente en el mismo estado tras una
interrupción, tras un periodo en espera o un apagado (o bien
intencionado o bien no intencionado), etcétera. En el momento de la
continuación, la información de estado se verifica en el segundo
modo antes de que se confíe en la misma como originada desde el
mismo programa operando en el primer modo.
Una implementación adicional de la tercera
realización de la invención se describe en la reivindicación 8. Al
cifrar la información de estado en los resultados de prueba, la
información de estado no puede recuperarse de los resultados de
prueba excepto por el propio programa de seguridad.
Una implementación de la invención se describe
en la reivindicación 9. Puesto que el modo de operación que ha de
seleccionarse no puede estar directamente en código fuente
(hard-coded) en el propio programa de
seguridad, se requiere un procedimiento de selección del modo de
operación diferente. Un procedimiento muy elegante y útil para
seleccionar el modo de operación es hacer que el usuario del
dispositivo de seguridad proporcione el modo como entrada al
programa de seguridad.
Una implementación ventajosa de la invención se
describe en la reivindicación 10. Con el fin de probar a un usuario
de un dispositivo de seguridad, que o bien está pidiendo al
dispositivo de seguridad que genere resultados de prueba o bien que
verifique los resultados de prueba, que la generación o verificación
se realiza realmente en el mismo dispositivo de seguridad, el
programa de seguridad se ejecuta preferiblemente como parte de un
segundo programa de seguridad, implementando el segundo programa de
seguridad una ejecución certificada tal como se describe en el
documento de la técnica anterior.
Una implementación más específica de la
invención se describe en la reivindicación 11. En esta
implementación se utiliza una PUF para implementar la función
aleatoria que se utiliza en las funciones primitivas.
Una implementación más específica de la
invención se describe en la reivindicación 12. Cuando se utiliza una
función hash aleatoria h(.), que preferiblemente está (casi)
libre de colisiones, estas funciones primitivas pueden utilizarse
de manera ventajosa para generar de manera fiable una clave que se
utiliza tanto en el primer modo para generar resultados de prueba
como en el segundo modo para verificar los resultados de prueba o
para obtener información de los resultados de prueba. Ha de
entenderse que, tal como se describe en la reivindicación 1, el
programa representa únicamente las partes relevantes (desde el punto
de vista de la seguridad) del programa de seguridad.
Una implementación más específica de la
invención se describe en la reivindicación 13. La clave generada
para calcular los resultados de prueba en esta implementación
también depende de al menos parte de las variables de entrada. Esto
tenía la ventaja de que las entradas del programa (de aplicación) no
tienen que estar codificadas en hardware en el programa de
seguridad para estar protegidas por los resultados de prueba. No
tienen que considerarse todas las entradas, puesto que algunas
entradas pueden no ser de interés, deberían permanecer
confidenciales entre el dispositivo de seguridad y el usuario del
dispositivo de seguridad (y por tanto no han de comunicarse a un
tercero), o debería permitirse que sean diferentes entre ejecuciones
de programa diferentes (la entrada que determina el modo de
operación por supuesto no debería utilizarse).
El sistema según la invención está caracterizado
según se describe en la reivindicación 14.
El producto de programa informático, tal como un
medio legible por ordenador, según la invención está caracterizado
según se describe en la reivindicación 15.
Instrucciones ejecutables por ordenador según la
invención están caracterizadas según se describe en la
reivindicación 16.
La señal según la invención está caracterizada
según se describe en la reivindicación 17.
Estos y otros aspectos de la invención se
describirán adicionalmente a modo de ejemplo con referencia a los
dibujos esquemáticos, en los que:
la figura 1 ilustra el modelo básico para
aplicaciones utilizando la PUF,
la figura 2 ilustra un uso de ejemplo de
ejecución certificada,
la figura 3 ilustra un uso de ejemplo de una
prueba de ejecución,
la figura 4 ilustra una visión general de las
diferentes capas de programa para generar una prueba electrónica
con ejecución certificada,
la figura 5 ilustra una implementación de
memoria segura, y
la figura 6 ilustra un procesamiento
interrumpido.
En todas las figuras, los mismos números de
referencia indican características similares o correspondientes.
Algunas de las características indicadas en los dibujos se
implementan normalmente en software, y como tales representan
entidades de software, tales como módulos u objetos de software.
La figura 1 ilustra el modelo básico para
aplicaciones utilizando el dispositivo 103 de seguridad que
comprende una PUF 104. El modelo, implementado por el sistema 100,
comprende:
- Un usuario 101 que quiere hacer uso de las
capacidades de cálculo de un chip 105 en o bajo el control de un
dispositivo 103 de seguridad.
- El usuario y el chip están conectados entre sí
mediante un canal 102 de comunicación público que posiblemente no
es de confianza. El usuario puede ser no sólo una persona, sino
también una pieza diferente de software, hardware, u otro
dispositivo.
El dispositivo 103 de seguridad podría
implementarse mediante un dispositivo 110 de procesamiento que
comprende un procesador 111 y una memoria 112, estando el
dispositivo de procesamiento dispuesto para ejecutar instrucciones
ejecutables por ordenador desde un producto 113 de programa
informático.
El documento de la técnica anterior describe el
tratamiento de desafíos y respuestas que son únicos para cada PUF
específica. Dado un desafío, una PUF puede calcular una respuesta
correspondiente. Un usuario está en posesión de su propia lista
privada (certificada) de CRP (pares
desafío-respuesta,
challenge-response pairs) generados
originalmente por la PUF. La lista es privada porque (salvo quizá la
PUF) sólo el usuario conoce las respuestas a cada uno de los
desafíos en la lista. Los desafíos del usuario pueden ser públicos.
Se supone que el usuario ha establecido varios CRP con el
dispositivo de seguridad.
\newpage
Las respuestas para (un número limitado de) los
desafíos sólo las conoce el usuario. Además, el dispositivo de
seguridad puede (re)calcular la respuesta para un desafío
específico. Para evitar que otras personas recuperen la respuesta
para un desafío específico, es necesaria una forma segura de
gestionar los CRP. El documento de la técnica anterior propone el
concepto de una PUF controlada para conseguirlo. Una PUF se define
como controlada (una PUF controlada o CPUF) si sólo puede accederse
a la misma a través de un algoritmo de seguridad que está
físicamente conectado a la PUF de manera inseparable (es decir,
cualquier intento de burlar el algoritmo llevará a la destrucción
de la PUF). En particular este algoritmo de seguridad puede
restringir los desafíos que se presentan a la PUF y puede limitar
la información acerca de las respuestas que se dan al exterior. El
control es la idea fundamental que permite a las PUF ir más allá de
simples aplicaciones de identificación autenticadas. Se ha descrito
y se sabe que las PUF y las PUF controladas
implementan identificación de tarjetas inteligentes, ejecución certificada y concesión de licencias de software.
implementan identificación de tarjetas inteligentes, ejecución certificada y concesión de licencias de software.
Para evitar ataques
man-in-the-middle,
se impide a un usuario pedir la respuesta a un desafío específico,
durante los protocolos de gestión CRP. Esto es una preocupación en
los protocolos de gestión CRP, ya que, en estos protocolos, el
dispositivo de seguridad envía respuestas al usuario. Esto se
garantiza limitando el acceso a la PUF, de manera que el
dispositivo de seguridad nunca da la respuesta a un desafío
directamente. La gestión CRP tiene lugar según se describe en el
documento de la técnica anterior. En los protocolos de aplicación,
las respuestas sólo se utilizan internamente para procesamiento
adicional, tal como para generar códigos de autenticación de
mensajes (MAC), y nunca se envían al usuario. La CPUF puede ejecutar
alguna forma de programa, (en lo sucesivo: un programa de
seguridad), de manera privada (nadie puede ver lo que está haciendo
el programa, o al menos el material clave que está manipulándose
permanece oculto) y de manera auténtica (nadie puede modificar sin
ser detectado lo que el programa está haciendo).
El control de la CPUF está diseñado de manera
que sólo puede accederse a la PUF a través de un programa de
seguridad, y más específicamente utilizando dos funciones primitivas
GetResponse(.) y GetSecret(.). Un conjunto de funciones primitivas
que pueden utilizarse para implementar la invención se define
como:
-
GetResponse(PC)=f(h(h(SProgram),PC))
-
GetSecret(Challenge)=h(h(SProgram),f(Challenge))
donde f es la PUF y h es una función hash
aleatoria disponible públicamente (o en la práctica alguna función
pseudoaleatoria). En estas funciones primitivas, SProgram es el
código del programa que está ejecutándose de manera auténtica. El
usuario del dispositivo puede proporcionar un programa de seguridad
de este tipo. Obsérvese que h(Sprogram) incluye todo lo que
está contenido en el programa, incluyendo valores codificados en
hardware (tales como, en algunos casos, Challenge). El dispositivo
de seguridad calcula h(SProgram), y posteriormente utiliza
este valor cuando se invocan GetResponse(.) y GetSecret(.). El
cálculo de h(SProgram) puede realizarse (justo) antes de
iniciar el programa de seguridad, o antes de las primeras creaciones
de instancia de una función primitiva. Según se muestra en el
documento de la técnica anterior, estas dos funciones primitivas
son suficientes para implementar una gestión CRP segura en la que
GetResponse(.) se utiliza esencialmente para la generación de CRP
mientras que GetSecret(.) se utiliza por aplicaciones que quieren
producir un secreto compartido a partir de un CRP.
En lo sucesivo, se utilizan las siguientes
notaciones:
- E(m,k) es el cifrado del mensaje m con
la clave k.
- D(m,k) es el descifrado del mensaje m
con la clave k.
- M(m,k) realiza un MAC del mensaje m con
la clave k.
- E&M(m,k) cifra y realiza un MAC el
mensaje m con la clave k.
- D&M(m,k) descifra el mensaje m con
la clave k si el MAC coincide. Si el MAC no coincide, emite como
salida el mensaje de que el MAC no coincide y no realiza ningún
descifrado.
El concepto de ejecución certificada se describe
en el documento de la técnica anterior. Esta tecnología se
ilustrará mediante varias implementaciones específicas. Se
proporciona una ejecución certificada utilizando un denominado
certificado electrónico. Un certificado electrónico para un programa
XProgram con entrada Input en un dispositivo de seguridad se define
como una cadena generada eficazmente mediante XProgram(Input)
en el dispositivo de seguridad de manera que el usuario del
dispositivo de seguridad puede comprobar de manera eficiente, con
una probabilidad abrumadora, si los resultados emitidos como salida
del XProgram se generaron mediante XProgram(Input) en el
dispositivo de seguridad. El usuario que solicita la ejecución del
XProgram en el dispositivo de seguridad puede fiarse de la
veracidad del fabricante del dispositivo de seguridad que puede dar
fe de que produjo el dispositivo de seguridad, en lugar de fiarse
del propietario del dispositivo de seguridad.
La figura 2 ilustra un ejemplo de ejecución
certificada sencillo, en el que el cálculo se realiza directamente
en el dispositivo de seguridad. Un usuario, Alice, quiere ejecutar
un programa Program(Input) costoso desde el punto de vista
computacional en el ordenador 201 de Bob. El ordenador de Bob tiene
un dispositivo 202 de ya ha establecido una lista de CRP 211 con el
dispositivo de seguridad. Sea (Challenge,Response) uno de los CRP
de Alice para la PUF de Bob. En una primera variación de
implementación, Alice envía (en la comunicación 221) el siguiente
programa CProgram1 231, con la entrada Inputs 232 igual a
(Challenge, E&M((XProgram,Input), h(h(Cprogram),
Response))), al dispositivo 202 de seguridad.
\global\parskip0.950000\baselineskip
CProgram1(Inputs):
inicio del programa
var
Challenge,EM,XProgram,Input,Result,Certificate;
(Challenge,EM)= Inputs;
Secret=GetSecret(Challenge);
(XProgram,Input)=D&M(EM,Secret);
abortar si el MAC no coincide;
Result=XProgram(Input);
Certificate=M(Result,Secret);
Output(Result,Certificate);
fin del programa
En una segunda variación de implementación,
Alice envía el siguiente programa CProgram2 con la entrada Inputs
igual a
(E&M((XProgram,Input),h(h(Cprogram),Response))) al
dispositivo de seguridad. Esta variación es más robusta dado que
codifica en hardware el valor Challenge en CProgram2. Por tanto, el
valor de Challenge se utiliza en las funciones primitivas.
CProgram2(Inputs):
inicio del programa
const Challenge =...;
var EM,XProgram,Input,Result,Certificate;
(EM)=Inputs;
Secret=GetSecret(Challenge);
(XProgram,Input)=D&M(EM,Secret);
abortar si el MAC no coincide;
Result=XProgram(Input);
Certificate=M(Result,Secret);
Output(Result,Certificate);
fin del programa
Por Result=XProgram(Input) se entiende
que Result forma parte de la salida del XProgram(Input).
Puede haber más salidas para las que no sea necesaria una prueba
electrónica. Output(...) se utiliza para enviar los resultados 233
desde la CPUF según se muestra en la comunicación 222. Cualquier
cosa que se envíe desde el dispositivo de seguridad es
potencialmente visible en el exterior (excepto durante la
inicialización, cuando el fabricante está en posesión física del
dispositivo de seguridad). Un diseño seguro del programa genera un
resultado que se pone en forma cifrada en Result. El cifrado puede
realizarse mediante cifrado clásico o utilizando Secret. En este
último caso, Secret está incluido en Input.
Puesto que el CRP de Alice es privado, ninguna
otra persona puede generar Secret y, por tanto, un MAC con Secret.
Un MAC se utiliza en dos puntos en el programa. El primer MAC se
comprueba mediante el programa y garantiza la autenticidad de
Inputs. El segundo MAC se comprueba por Alice y garantiza la
autenticidad del mensaje que recibe de vuelta desde el dispositivo
de seguridad. Aparte de Alice sólo el dispositivo de seguridad
puede generar Secret dado un Challenge ejecutando el programa
CProgram. Esto significa que Result y Certificate se generaron por
CProgram en el dispositivo de seguridad. Dicho de otro modo,
CProgram realizó la ejecución certificada con Inputs como entrada.
Esto prueba que Certificate es un certificado electrónico.
\global\parskip1.000000\baselineskip
De ello se desprende que los certificados
electrónicos pueden utilizarse para cálculos remotos seguros. Si
Certificate coincide, entonces esto prueba a Alice que
XProgram(Input) se ejecutó (por CProgram(Inputs)) en
el dispositivo de seguridad.
La ejecución certificada según se describe en el
documento de la técnica anterior no puede utilizarse por Alice con
respecto a un tercero para probar la ejecución de XProgram como
prueba de ejecución. Utilizando su CRP, Alice puede falsificar un
certificado electrónico Certificate para cualquier resultado Result.
Esto se desprende del hecho de que Alice puede calcular Secret
utilizando la respuesta relacionada con Challenge. Debido al hecho
de que Alice necesita su CRP (para comprobar el MAC), de ello se
desprende que Alice no puede utilizar el certificado electrónico
Certificate como una prueba de ejecución para probar a terceros que
ella ejecutó XProgram(Input) (en CProgram(Inputs)) en
el dispositivo de seguridad de Bob.
En una primera realización de la presente
invención, se utilizan resultados de prueba que pueden utilizarse
como una prueba de ejecución con respecto a cualquier tercero. Una
prueba electrónica EProof para un programa XProgram con la entrada
Input que produce los resultados Results en un dispositivo de
seguridad se define como una cadena generada por
XProgram(Input) en el dispositivo de seguridad de manera que
existe un protocolo A1 entre el dispositivo de seguridad y
cualquier árbitro con las entradas EProof y XProgram y tal vez
alguna información auxiliar, que puede decidir de manera eficaz
correctamente, con una probabilidad abrumadora, si EProof se
generó mediante XProgram(Input) en el dispositivo de
seguridad o no, y si se generó correctamente, recuperar, con una
probabilidad abrumadora, (parte de) los resultados Result que se
generaron previamente junto con EProof mediante
XProgram(Input) en el dispositivo de seguridad. El protocolo
A1 se denomina protocolo de arbitraje. El siguiente ejemplo muestra
que puede utilizarse una prueba electrónica tanto por el propietario
como por el usuario del dispositivo de seguridad.
Con el fin dar soporte a la prueba de ejecución,
se requiere ampliar la solución de ejecución certificada a una capa
de programa adicional para generar una prueba de ejecución. Un
usuario, Alice, quiere ejecutar un programa de aplicación AProgram
en el ordenador de Bob que tiene un único dispositivo de seguridad
con PUF. Alice ya ha establecido CRP con el dispositivo de
seguridad de Bob.
Como un primer ejemplo en el que puede
utilizarse esta realización, considérese una aplicación STB
(set-top-box, módulo
descodificador) en la que Alice es el distribuidor 310 de
radiodifusión y Bob es el propietario del STB 300 con un
dispositivo 301 de seguridad, véase la figura 3. En el programa 320
A, Bob compra un servicio. Alice recibe los detalles 332 de la
transacción, un certificado 333 electrónico (el certificado
electrónico verifica la autenticidad tanto de los detalles de la
transacción como de la prueba electrónica), y una prueba 334
electrónica. Alice comprueba en la etapa 340 si el certificado
electrónico coincide. Si es así, sabe que la prueba electrónica se
generó por el STB de Bob y continúa la transacción en el programa B.
La prueba electrónica puede utilizarse como una confirmación de que
Bob ha comprado el servicio porque un árbitro puede recuperar los
detalles de la transacción. En el programa 321 B, Bob recibe el
contenido 335 que pertenece al servicio que ha solicitado. El
contenido puede estar cifrado utilizando un CRP. Alice recibe una
segunda prueba 336 electrónica de las acciones de Bob en el
programa B. En primer lugar, parece como si Bob no recibiera una
prueba de la promesa de Alice de enviarle el contenido en el
programa B. Sin embargo, no sólo Alice sino también Bob puede
utilizar la primera prueba electrónica. Cualquier tercero podrá
comprobar que el STB de Bob realizó con éxito el protocolo
codificado en el programa A, que es en sí mismo la promesa de Alice
de transmitir el contenido a Bob en el programa B. Por ejemplo, Bob
puede utilizar la prueba electrónica para convencer a terceros (y
en particular a Alice) de que compró un determinado servicio, lo que
puede hacerle candidato a descuentos y mejoras.
Como un segundo ejemplo, supóngase que Alice
quiere ejecutar un programa en el dispositivo de seguridad de Bob
con una marca de fecha y hora como parte de su entrada. Los
resultados de la ejecución pueden contener una copia de esta marca
de fecha y hora con la aceptación por parte de Bob de que la marca
de fecha y hora representa la fecha y hora correcta de ejecución.
Por ejemplo, el programa está diseñado de manera que pregunta a Bob
si está de acuerdo y aborta si Bob no está de acuerdo. Dada una
prueba electrónica correcta, un árbitro recupera los resultados.
Por tanto, puede comprobar la marca de fecha y hora y verificar si
los derechos de Bob y/o Alice siguen siendo válidos.
Como tercer ejemplo, supóngase un programa
Program' con diferentes modos. Dependiendo de su modo, Program' o
bien calcula (Result,EProof)=Program(Input) en el procesador
P, siendo EProof una prueba electrónica para el programa Program
con la entrada Input en P, o bien Program' desempeña el papel de
árbitro comprobando si EProof es una prueba electrónica válida y,
si es así, reconstruye Result. En el papel de árbitro, EProof puede
utilizarse como un pase al siguiente modo en Program'. Esta técnica
implementa un acceso condicional.
La figura 4 ilustra las diferentes capas de
programa. El programa según la invención que genera o verifica la
prueba de ejecución, denominado EProgram 403, se ejecuta como la
parte XProgram del programa de ejecución certificada CProgram1 402
(o CProgram2 402) en un dispositivo 400 de seguridad con una PUF
401, para que tanto el usuario como el tercero queden convencidos
de que la ejecución tuvo lugar en el dispositivo de seguridad.
EProgram tiene tanto un modo 404 de ejecución como un modo 405 de
arbitraje.
En el modo de ejecución, el EProgram calcula no
sólo (en AProgram 406) los resultados en los que está interesada
Alice, sino también una prueba electrónica. Alice utiliza la
ejecución certificada (ejecutando el EProgram como la parte
XProgram de CProgram) para estar segura de que el programa se
ejecutó correctamente en el dispositivo de seguridad de Bob. Un
árbitro puede comprobar la prueba electrónica ejecutando el EProgram
en modo de arbitraje, usando también ejecución certificada. La idea
clave es que la primitiva GetResponse(.) depende del hash
del programa EProgram completo que contiene ambos modos. Por
consiguiente, la prueba electrónica que se generó por el programa
EProgram en el modo de ejecución (con una clave obtenida mediante la
primitiva GetResponse(.)) puede descifrarse por el programa
EProgram en el modo de arbitraje.
\global\parskip0.900000\baselineskip
La seguridad viene determinada por, en primer
lugar, la dificultad de romper la primitiva GetResponse(.), es
decir romper el hash y romper la PUF con la que se ha
definido GetResponse(.), y, en segundo lugar, la dificultad de
romper el cifrado y la primitiva MAC E&M(.).
A continuación se representan algunas
variaciones del EProgram. Algunos programas insertan directamente en
código fuente parte de la entrada, que es menos flexible pero más
robusta. La cantidad de salida presente en los resultados de prueba
también es diferente. Puede implementarse cualquier variación de
estos algoritmos.
En una primera variación, Alice quiere ejecutar
AProgram(Input) y recibir una prueba de ejecución y por lo
tanto ejecuta EProgram1(Entradas) (431) donde
Inputs=((AProgram, Input,PC),Mode) (con 435: AProgram, 434: Input),
con Mode 432 igual a "modo de ejecución" y PC 433 una cadena
aleatoria, y en el que EProgram1 es según se define más adelante.
PC se usa por GetResponse(.) como un "predesafío" para calcular
el desafío para la función aleatoria, con el fin de generar las
claves KE secretas (en modo de ejecución) o KA (en modo de
arbitraje). Alice utiliza la técnica de ejecución certificada para
ejecutar EProgram1(Inputs) en el dispositivo de seguridad de
Bob utilizando un CProgram 430 tal como se describió anteriormente.
Alice comprueba el certificado electrónico para verificar la
autenticidad de toda la salida que obtiene de vuelta desde el
dispositivo de seguridad. El certificado electrónico producido no
es sólo un certificado del resultado 438 generado por
Program(Input) sino también de la prueba 436 electrónica
generada.
EProgram1(Inputs):
inicio del
programa
var \hskip0,3cm
X,Mode,AProgram,Input,PC,Result,KE,KA,Checkbit,EMResult,
EProof,Results;
- (X,Mode)=Inputs;
- Si Mode es modo de ejecución:
- iniciar
- (AProgram,Input,PC)=X;
- Result=AProgram(Input);
- KE=GetResponse(PC);
- EMResult=E&M(Result,KE);
- EProof=(PC,EMResult);
- Results=(Result,EProof);
- fin
- Si Mode es modo de arbitraje:
- iniciar
- EProof=X;
- (PC,EMResult)=EProof;
- KA=GetRespuesta(PC);
- Result=D&M(EMResult,KA);
- CheckBit=(MAC de EMResult coincide);
- Results=(Result,CheckBit);
- fin
- Output(Results);
fin del
programa
\global\parskip0.950000\baselineskip
En una segunda variación de la primera
realización, Alice inserta directamente en código fuente la cadena
aleatoria PC en EProgram para una mayor robustez, e incorpora un
valor sometido a hash de (parte de) el programa de
aplicación AProgram y un valor sometido a hash de (parte de)
la entrada Input del programa de aplicación en Eproof, de manera
que puede verificarse posteriormente que se ha utilizado exactamente
este programa con esta entrada. En modo de arbitraje la EProof sólo
se verifica, abarcando AProgram, Input y Result, pero ninguno de
ellos se emite como salida al usuario del tercero.
EProgram2(Inputs):
iniciar
programa
const
PC=...;
var \hskip0,3cm
X,Mode,Program,Input,Result,KE,KA,Checkbit,EMResult,EProof,
Results;
- (X,Mode)=Inputs;
- Si Mode es modo de ejecución:
- iniciar
- (Program,Input)=X;
- Result=Program(Input);
- KE=GetResponse(PC);
- EMResult=E&M((Program,Intup,Result),KE);
- EProof(PC,EMResult);
- Results=(Result,EProof);
- fin
- Si Mode es modo de arbitraje:
- iniciar
- EProof=X;
- (PC,EMResult)=EProof;
- KA=GetResponse(PC);
- Result=D&M(EMResult,KA);
- CheckBit=(MAC de EMResult coincide);
- Results=(CheckBit);
- fin
- Output(Results);
fin del
programa
En una tercera variación de la primera
realización, la cadena aleatoria PC se omite en el, simplificándose
así el cálculo. La clave KE se calcula en EProgram3 mediante
KE=GetResponse() o de manera incluso más sencilla una (nueva)
función primitiva KE=f(h(EProgram3)).
En una cuarta variación de la primera
realización, PC y opcionalmente otros parámetros de entrada, aunque
no están insertados directamente en código fuente (como en la
segunda variación), todavía se utilizan como entrada a la función
aleatoria en la función primitiva. Esto se muestra en EProgram3
donde por ejemplo Program e Input se obtienen como entradas a
EProgram3 y se utilizan como entrada para GetResponse (.). No tienen
que considerarse todas las entradas, ya que algunas entradas pueden
no ser de interés, deberían mantenerse confidenciales entre el
dispositivo de seguridad y el usuario del dispositivo de seguridad
(y por tanto no comunicarse a un tercero), o debería permitirse que
sean diferentes entre diferentes ejecuciones de programa (la entrada
que determina el modo de operación por supuesto no debería
utilizarse).
\global\parskip1.000000\baselineskip
EProgram3(Inputs):
iniciar
programa
const
PC=...;
var \hskip0,3cm
X,Mode,Program,Input,Result,KE,KA,Checkbit,EMResult,EProof,
Results;
- (X,Mode)=Inputs;
- Si Mode es modo de ejecución:
- iniciar
- (Program,Input)=X;
- Result=-Program(Input);
- KE=GetResponse((PC,Program,Input));
- EMResult=E&M((Program,Input,Result),KE);
- EProof=(PC,EMResult);
- Results=(Result,EProof);
- fin
- Si Mode es modo de arbitraje:
- iniciar
- EProof=X;
- (PC,EMResult)=EProof,
- KA=GetResponse((PC,Program,Input));
- Result=D&M(EMResult,KA);
- CheckBit=(MAC del EMResult coincide);
- Results=(CheckBit);
- fin
- Output(Results);
fin del
programa
En modo de arbitraje el árbitro ejecuta el
protocolo con el dispositivo de seguridad de Bob comprendiendo tres
etapas. En la etapa 1 el árbitro recibe de Alice o Bob una prueba de
ejecución EProof en la etapa 450. Éste construye
Inputs=(EProof,Mode) (EProof: 444), donde Mode 442 es igual a modo
de arbitraje. El árbitro también obtiene el mismo EProgram y
CProgram (que el que supuestamente se ha ejecutado antes; en este
ejemplo se comunica al árbitro en la etapa 451 y la etapa 452),
probablemente desde Alice o Bob. Obsérvese que el árbitro no
necesita PC.
En la etapa 2 el árbitro utiliza la técnica de
ejecución certificada con CProgram 440 para ejecutar
EProgram(Inputs) (EProgram: 441) en el dispositivo de
seguridad de Bob. El árbitro comprueba el certificado 447
electrónico para verificar la autenticidad de los Results que
recibe de vuelta desde el dispositivo de seguridad. Si el
certificado electrónico coincide con los Results entonces el árbitro
sabe que el dispositivo de seguridad de Bob ejecutó
EProgram(Inputs) sin la interferencia de nadie y que nadie
accedió indebidamente con sus entradas o salidas. En particular
nadie modificó la entrada EProof y nadie cambió el Mode. Dicho de
otro modo, el dispositivo de seguridad de Bob ejecutó
EProgram(Inputs) en modo de arbitraje utilizando EProof. En
modo de arbitraje, el Result 445 puede suministrarse completamente,
en parte, o no suministrarse en absoluto a Output. También puede
sustituirse por información derivada del Result. Esto puede depender
de la aplicación y del árbitro. Esta decisión se implementa
entonces en el programa. Por ejemplo, por motivos de privacidad el
EProgram sólo podría enviar un resumen de los resultados al
árbitro.
En la etapa 3 el árbitro verifica si CheckBit
446 es verdadero, es decir si el MAC de EMResult coincide. Si es
así, el árbitro decide que AProgram(Input) en el dispositivo
de seguridad de Bob ha calculado EProof y Result en modo de
ejecución. Si no es así, el árbitro decide que el dispositivo de
seguridad de Bob no ha calculado EProof en modo de ejecución. En
modo de arbitraje EProgram o bien emite como salida que el MAC no
coincide (véase la definición de D&M(.) y CheckBit), o bien
emite como salida que el MAC coincide junto con un resultado
descifrado. Generar una prueba electrónica falsificada
FEProof=(FPC,FEMResult) para un resultado (falsificado) FResult es
un denominado problema difícil.
En una segunda realización, pueden usarse
resultados de prueba similares a una prueba electrónica para
conseguir un control de memoria seguro mediante programas
específicos en un dispositivo de seguridad específico con PUF,
utilizando una memoria física no segura (posiblemente fuera del
chip) o en circunstancias difíciles tales como en un tratamiento
interrumpido, entornos con piratería de software, y en entornos en
los que es probable que se distribuya ilegalmente contenido
cifrado.
La figura 5 ilustra implementación de memoria
segura. En esta realización, el primer modo 501 o modo de ejecución
se utiliza por el programa 500 de seguridad para almacenar los
resultados en memoria 503, y el segundo modo 502 o modo de
arbitraje se utiliza por el programa para cargar la memoria y para
comprobar su autenticidad. Se supone que la memoria almacena datos
Data en la ubicación Address. Ésta puede ser una dirección única o
un intervalo de direcciones. Los Data se almacenan en forma cifrada
como (PC, E&M(Data,K)), donde K es igual a
GetResponse(PC). El procedimiento, denominado Store, con la
entrada (Address,(PC,Data)) almacena datos, y se corresponde con el
modo de ejecución en EProgram, donde Result=Data, EMResult=EMData, y
EProof=(PC,EMData). El procedimiento, denominado Load, con la
entrada Address carga datos, y se corresponde con el modo de
arbitraje en EProgram, donde Result=Data, EMResult=EMData, y
EProof=(PC,EMData).
MProgram
iniciar el
programa
- Store(Address,Data):
- iniciar procedimiento
- var PC, KE, EMData;
- KE=GetResponse(PC);
- EMData=E&M(Data,KE);
- Store(PC,EMData) en Address;
- Fin del procedimiento
- Load(Address):
- iniciar el procedimiento
- var PC,EMData,KA;
- Load (PC,EMData) desde Address;
- KA=GetResponse(PC);
- Data=D&M(EMData,KA);
- CheckBit=(MAC de EMData coincide);
- Output(Data,CheckBit);
- fin del procedimiento
fin del
programa
Si un programa MProgram(Input) con los
procedimientos, Store(.) y Load(.) como parte de su código, utiliza
estos procedimientos para acceso a memoria, entonces el programa se
ejecuta en ambos modos. Tanto GetResponse(.) en Store(.) como
Load(.) dependen de la hash de un único y mismo MProgram. Si
MProgram almacena datos, opera en el primer modo: los datos se
escriben en formato de prueba electrónica cifrada en memoria. Si
carga datos, opera en el segundo modo: CheckBit emitido como salida
se utiliza para comprobar la autenticidad de los datos en el
sentido de si se originaron desde MProgram ejecutándose en el
dispositivo de seguridad de Bob. En este sentido, MProgram controla
completamente los datos que procesa. MProgram decide si emite como
salida datos no cifrados al público. Este programa es efectivamente
el propietario de los datos.
Obsérvese que un enemigo puede sustituir la
memoria actual por una versión más antigua y proceder sin ser
detectado. Para comprobar la autenticidad de que la memoria es la
más actualizada, el procesador necesita una memoria privada para
almacenar un contador de tiempo. Este contador de tiempo puede
almacenarse junto con un MAC con una clave derivada de la PUF.
Además, esta idea puede mejorarse utilizando arquitecturas más
sofisticadas que utilizan de forma segura esquemas de autenticación
de memoria de recursos fuera de chip tal como se describe en
"Architectural Support for Copy and Tamper Resistant
Software", David Lie y Chandramohan Thekkath y Mark Mitchell
y Patrick Lincoln y Dan Boneh y John Mitchell y Mark Horowitz,
Proceedings of the 9th International Conference on Architectural
Support for Programming Languages and Operating Systems
(ASPLOS-IX), noviembre de 2000, págs.
169-177, y "Caches and Merkle Trees for
Efficient Memory Authentication", Blaise Gassend y G. Edward
Suh y Dwaine Clarke y Marten van Dijk y Srinivas Devadas,
Proceedings of the 9th International Symposium on
High-Performance Computer Architecture, febrero
de 2003.
La figura 6 ilustra la arquitectura tanto para
la tercera como para la cuarta realización de la invención.
En una tercera realización de esta invención los
resultados de prueba se utilizan para almacenar el estado 602 de
ejecución de programa, de manera que un programa 601 que se ejecuta
en el dispositivo 600 de seguridad puede almacenar de manera segura
su estado 605 de programa en caso de interrupción. En el momento de
una interrupción, el estado de programa está cifrado (como en el
primer modo, 603). El dispositivo de seguridad puede continuar su
ejecución en un momento posterior sin haber revelado nunca su estado
al exterior. En el momento de la continuación, el estado de
programa se verifica y descifra (como en el segundo modo, 604) y se
restaura. El programa está por tanto totalmente al mando. Esto
permite una ejecución segura robusta frente a interrupciones. Las
aplicaciones son tratamiento seguro frente a interrupciones,
resistencia frente a piratería de software, y resistencia frente a
distribución ilegal de contenido descifrado.
En una cuarta realización, un programa puede
almacenar contenido 602 cifrado o software 602 descifrado para un
uso posterior. El contenido sólo se reproduce (o continúa
reproduciéndose) o el software sólo se ejecuta (o continúa
ejecutándose) en el mismo estado 605 en el mismo dispositivo 600 de
seguridad específico. Esto permite resistencia frente a piratería
de software o distribución ilegal de contenido descifrado.
Obsérvese que el propietario del dispositivo de
seguridad (Bob) y el usuario del dispositivo de seguridad (Alice)
pueden ser una única y misma identidad. Por ejemplo, Bob prueba a
otros mediante su prueba electrónica que calculó Result con
Program(Input). Finalmente, es una ventaja de la invención
que ni Alice ni el árbitro necesiten un dispositivo de seguridad
equipado con una PUF.
La invención es aplicable en general en el
sentido de que puede aplicarse a todas las PUF, digitales así como
físicas u ópticas. Los detalles de la construcción se dan para PUF
físicas. Pero pueden transferirse a PUF digitales u ópticas.
Son posibles alternativas. En la descripción
anterior, "que comprende" no excluye otros elementos o etapas,
"un" o "una" no excluye una pluralidad, y un único
procesador u otra unidad también puede cumplir las funciones de
varios medios enumerados en las reivindicaciones.
Claims (17)
1. Procedimiento para probar la autenticidad de
la ejecución de instrucciones de programa, que comprende:
- -
- una etapa de ejecutar instrucciones de programa bajo el control de un programa (403) de seguridad en un dispositivo (103, 202) de seguridad que comprende una función (104,203) aleatoria, siendo la función aleatoria accesible únicamente desde el programa de seguridad a través de una interfaz controlada, comprendiendo la interfaz controlada al menos una función primitiva que accede a la función aleatoria que devuelve una salida que depende de al menos parte de una representación de al menos aquellas partes del programa de seguridad que llaman a la función primitiva,
- -
- una etapa de, utilizando la función aleatoria, calcular resultados de prueba durante la ejecución del programa de seguridad que opera en un primer modo (404) accediendo a la función aleatoria a través de la interfaz controlada, y
- -
- una etapa de, utilizando la función aleatoria, verificar los resultados de prueba durante la ejecución del mismo programa de seguridad que opera en un segundo modo (405) accediendo a la función aleatoria a través de la interfaz controlada.
2. Procedimiento según la reivindicación 1, en
el que un tercero recibe los resultados de prueba como prueba de
ejecución verificable.
3. Procedimiento según la reivindicación 1, en
el que el programa de seguridad, si opera en el primer modo,
realiza las etapas de:
- -
- ejecutar un programa de aplicación con entrada de programa de aplicación que genera una salida de programa de aplicación,
- -
- utilizar la función aleatoria a través de la interfaz controlada para obtener un resultado mediante cifrado, y generar un código de autenticación de mensaje para, al menos uno de
- -
- al menos parte de la entrada del programa de aplicación,
- -
- al menos parte de la salida del programa de aplicación, y
- -
- al menos parte del programa de aplicación, y
- -
- generar resultados de prueba que comprenden el resultado cifrado y de mensaje autenticado, y
en el que el programa de seguridad, si opera en
el segundo modo, realiza las etapas de:
- -
- recibir resultados de prueba que han de verificarse, y
- -
- verificar al menos parcialmente la autenticidad del mensaje del resultado cifrado y de mensaje autenticado en los resultados de prueba.
4. Procedimiento según la reivindicación 3, en
el que el programa de seguridad, si opera en el segundo modo,
realiza una etapa adicional de enviar al usuario del dispositivo de
seguridad al menos parte de la autenticidad del mensaje al menos
parcialmente verificado del resultado cifrado y de mensaje
autenticado en la cadena en los resultados de prueba.
5. Procedimiento según la reivindicación 1, en
el que los resultados de prueba comprenden datos de almacenamiento
que se diseñan para uso posterior, permitiendo los resultados de
prueba la verificación de que los datos de almacenamiento se
originan en el programa de seguridad que está ejecutándose en el
dispositivo de seguridad.
6. Procedimiento según la reivindicación 5, en
el que los datos de almacenamiento comprendidos en los resultados
de prueba están cifrados con una clave que se calcula utilizando una
función primitiva cuya salida también depende de una representación
del programa de seguridad.
7. Procedimiento según la reivindicación 1, en
el que los resultados de prueba comprenden información (605) de
estado que se diseña para una posterior continuación del programa de
seguridad.
8. Procedimiento según la reivindicación 7, en
el que la información de estado comprendida en los resultados de
prueba está cifrada con una clave que se calcula utilizando una
función primitiva cuya salida también depende de una representación
del programa de seguridad.
9. Procedimiento según la reivindicación 1, en
el que el modo de operación se selecciona por el usuario del
dispositivo de seguridad suministrando una entrada al programa de
seguridad.
10. Procedimiento según la reivindicación 1, en
el que el programa de seguridad se ejecuta como parte de un segundo
programa (402) de seguridad, proporcionando el segundo programa de
seguridad ejecución certificada que prueba al usuario del
dispositivo de seguridad que el programa de seguridad se ejecuta por
el dispositivo de seguridad.
11. Procedimiento según la reivindicación 1, en
el que la función aleatoria comprende un sistema físico
complejo.
12. Procedimiento según la reivindicación 1, en
el que puede accederse a la función aleatoria a través de una
función primitiva
-
GetSecret(challenge)=h(h(programa),f(challenge)),
donde f(.) es la función aleatoria y h(.) es
sustancialmente una función hash aleatoria disponible
públicamente.
13. Procedimiento según la reivindicación 1, en
el que el cálculo de clave utiliza parte de la entrada del programa
de seguridad como entrada a la función aleatoria.
14. Sistema (100) que comprende una función
(104) aleatoria, un dispositivo (110) de procesamiento, que
comprende un procesador (111) y una memoria (112), para ejecutar
instrucciones legibles por ordenador, estando dispuestas las
instrucciones para hacer que el sistema implemente el procedimiento
según la reivindicación 1.
15. Producto (113) de programa informático que
tiene instrucciones ejecutables por ordenador para hacer que un
ordenador implemente el procedimiento según la reivindicación 1.
16. Instrucciones ejecutables por ordenador
para hacer que un ordenador implemente el procedimiento según la
reivindicación 1.
17. Señal que transporta resultados de prueba
generados por el procedimiento según la reivindicación 1.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US47145203P | 2003-05-16 | 2003-05-16 | |
| US471452P | 2003-05-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2318302T3 true ES2318302T3 (es) | 2009-05-01 |
Family
ID=33452448
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04744002T Expired - Lifetime ES2318302T3 (es) | 2003-05-16 | 2004-05-06 | Prueba de ejecucion que utiliza funcion aleatoria. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7877604B2 (es) |
| EP (1) | EP1636664B1 (es) |
| JP (1) | JP2007511810A (es) |
| KR (1) | KR20060018852A (es) |
| CN (1) | CN101048720A (es) |
| AT (1) | ATE416431T1 (es) |
| DE (1) | DE602004018137D1 (es) |
| ES (1) | ES2318302T3 (es) |
| WO (1) | WO2004102302A2 (es) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006053304A2 (en) | 2004-11-12 | 2006-05-18 | Pufco, Inc. | Volatile device keys and applications thereof |
| JP2006203564A (ja) * | 2005-01-20 | 2006-08-03 | Nara Institute Of Science & Technology | マイクロプロセッサ、ノード端末、コンピュータシステム及びプログラム実行証明方法 |
| US8176106B2 (en) * | 2005-12-14 | 2012-05-08 | Nxp B.V. | On-chip estimation of key-extraction parameters for physical tokens |
| EP1798653B1 (de) * | 2005-12-16 | 2011-08-03 | Aladdin Europe GmbH | Verfahren, Computerprogrammprodukt und Vorrichtung zum Schützen eines einen Funktionsblock aufweisenden Programms |
| KR101366376B1 (ko) | 2006-01-24 | 2014-02-24 | 베라요, 인크. | 신호 제너레이터에 기반한 장치 보안 |
| US8935416B2 (en) | 2006-04-21 | 2015-01-13 | Fortinet, Inc. | Method, apparatus, signals and medium for enforcing compliance with a policy on a client computer |
| US8782396B2 (en) * | 2007-09-19 | 2014-07-15 | Verayo, Inc. | Authentication with physical unclonable functions |
| US10374812B2 (en) * | 2008-06-27 | 2019-08-06 | Koninklijke Philips Electronics N.V. | Device, system and method for verifying the authenticity integrity and/or physical condition of an item |
| US8966660B2 (en) * | 2008-08-07 | 2015-02-24 | William Marsh Rice University | Methods and systems of digital rights management for integrated circuits |
| US8171306B2 (en) * | 2008-11-05 | 2012-05-01 | Microsoft Corporation | Universal secure token for obfuscation and tamper resistance |
| TWI498827B (zh) * | 2008-11-21 | 2015-09-01 | Verayo Inc | 非連網射頻辨識裝置物理不可複製功能之鑑認技術 |
| US8732468B2 (en) * | 2009-03-09 | 2014-05-20 | The Regents Of The University Of Michigan | Protecting hardware circuit design by secret sharing |
| EP2251813A1 (en) * | 2009-05-13 | 2010-11-17 | Nagravision S.A. | Method for authenticating access to a secured chip by a test device |
| US8811615B2 (en) * | 2009-08-05 | 2014-08-19 | Verayo, Inc. | Index-based coding with a pseudo-random source |
| US8468186B2 (en) * | 2009-08-05 | 2013-06-18 | Verayo, Inc. | Combination of values from a pseudo-random source |
| US20110271109A1 (en) * | 2010-05-01 | 2011-11-03 | Tor Anumana, Inc. | Systems and methods of remote device authentication |
| DE102010038703B3 (de) * | 2010-07-30 | 2012-01-26 | Robert Bosch Gmbh | Verfahren zur Erzeugung eines Herausforderungs-Antwort-Paars in einer elektrischen Maschine sowie elektrische Maschine |
| DE102012212471B3 (de) * | 2012-07-17 | 2013-11-21 | Siemens Aktiengesellschaft | Vorrichtung zum Realisieren einer physikalischen Degradations-/Tampererkennung eines digitalen ICs mittels einer (digitalen) PUF und Unterscheiden zwischen einer Degradation aufgrund von physikalischer Manipulation und aufgrund von Alterungsprozessen |
| WO2014138626A1 (en) | 2013-03-08 | 2014-09-12 | Robert Bosch Gmbh | Systems and methods for maintaining integrity and secrecy in untrusted computing platforms |
| JP6037450B2 (ja) * | 2013-05-20 | 2016-12-07 | 日本電気株式会社 | 端末認証システムおよび端末認証方法 |
| US20150143130A1 (en) * | 2013-11-18 | 2015-05-21 | Vixs Systems Inc. | Integrated circuit provisioning using physical unclonable function |
| FR3023028B1 (fr) * | 2014-06-26 | 2017-07-28 | Olivier Robert Gerard Joffray | Procede pour proteger des biens utilises par des dispositifs communiquant certifies connectes en reseaux, et pour garantir les comportements operationnels desdits dispositifs |
| EP3516566A1 (en) | 2016-09-22 | 2019-07-31 | nference, inc. | Systems, methods, and computer readable media for visualization of semantic information and inference of temporal signals indicating salient associations between life science entities |
| EP3435592B1 (en) * | 2017-01-25 | 2021-03-24 | Shenzhen Goodix Technology Co., Ltd. | Fingerprint data processing method and processing apparatus |
| GB201720946D0 (en) * | 2017-12-15 | 2018-01-31 | Nchain Holdings Ltd | Computer-implemented system and method |
| US11082241B2 (en) * | 2018-03-30 | 2021-08-03 | Intel Corporation | Physically unclonable function with feed-forward addressing and variable latency output |
| KR102134921B1 (ko) | 2018-08-01 | 2020-07-16 | 주식회사 유무시티 | 공공자전거 시스템 및 그 제어 방법 |
| US12333393B2 (en) | 2019-06-21 | 2025-06-17 | nference, inc. | Systems and methods for adaptively improving the performance of locked machine learning programs |
| US11487902B2 (en) | 2019-06-21 | 2022-11-01 | nference, inc. | Systems and methods for computing with private healthcare data |
| WO2020257783A1 (en) | 2019-06-21 | 2020-12-24 | nference, inc. | Systems and methods for computing with private healthcare data |
| WO2021023164A1 (zh) | 2019-08-02 | 2021-02-11 | 云丁网络技术(北京)有限公司 | 一种智能锁具控制方法和系统 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6308270B1 (en) * | 1998-02-13 | 2001-10-23 | Schlumberger Technologies, Inc. | Validating and certifying execution of a software program with a smart card |
| US7020776B2 (en) * | 2000-06-22 | 2006-03-28 | Microsoft Corporation | Cryptosystem based on a Jacobian of a curve |
| GB2378013A (en) * | 2001-07-27 | 2003-01-29 | Hewlett Packard Co | Trusted computer platform audit system |
| US7840803B2 (en) * | 2002-04-16 | 2010-11-23 | Massachusetts Institute Of Technology | Authentication of integrated circuits |
-
2004
- 2004-05-06 CN CNA2004800133489A patent/CN101048720A/zh active Pending
- 2004-05-06 ES ES04744002T patent/ES2318302T3/es not_active Expired - Lifetime
- 2004-05-06 JP JP2006530718A patent/JP2007511810A/ja not_active Withdrawn
- 2004-05-06 AT AT04744002T patent/ATE416431T1/de not_active IP Right Cessation
- 2004-05-06 DE DE602004018137T patent/DE602004018137D1/de not_active Expired - Lifetime
- 2004-05-06 KR KR1020057021852A patent/KR20060018852A/ko not_active Ceased
- 2004-05-06 EP EP04744002A patent/EP1636664B1/en not_active Expired - Lifetime
- 2004-05-06 WO PCT/IB2004/002342 patent/WO2004102302A2/en not_active Ceased
- 2004-05-06 US US10/556,520 patent/US7877604B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004102302A2 (en) | 2004-11-25 |
| JP2007511810A (ja) | 2007-05-10 |
| US20070039046A1 (en) | 2007-02-15 |
| ATE416431T1 (de) | 2008-12-15 |
| WO2004102302A3 (en) | 2007-03-29 |
| DE602004018137D1 (de) | 2009-01-15 |
| CN101048720A (zh) | 2007-10-03 |
| EP1636664A2 (en) | 2006-03-22 |
| US7877604B2 (en) | 2011-01-25 |
| KR20060018852A (ko) | 2006-03-02 |
| EP1636664B1 (en) | 2008-12-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2318302T3 (es) | Prueba de ejecucion que utiliza funcion aleatoria. | |
| RU2321179C2 (ru) | Способ защищенной передачи данных между двумя устройствами | |
| CN101176125B (zh) | 完整性受保护的安全存储设备的实施 | |
| US8171306B2 (en) | Universal secure token for obfuscation and tamper resistance | |
| US10652245B2 (en) | External accessibility for network devices | |
| US20060195402A1 (en) | Secure data transmission using undiscoverable or black data | |
| KR100670005B1 (ko) | 모바일 플랫폼을 위한 메모리의 무결성을 원격으로 확인하는 확인장치 및 그 시스템 그리고 무결성 확인 방법 | |
| CN111401901B (zh) | 生物支付设备的认证方法、装置、计算机设备和存储介质 | |
| US20110126023A1 (en) | Systems And Methods For Data Security | |
| US20080059809A1 (en) | Sharing a Secret by Using Random Function | |
| CN110855667B (zh) | 一种区块链加密方法、装置及系统 | |
| WO2019163026A1 (ja) | 車載機能アクセス制御システム、車載装置および車載機能アクセス制御方法 | |
| CN112883396B (zh) | 可信密码模块安全管理方法及系统 | |
| CN101657822B (zh) | 数据保管方法、客户端装置、存储装置以及数据保管系统 | |
| KR102027329B1 (ko) | 프로그램 실행권한 인증 방법 및 시스템 | |
| CN120874067A (zh) | 数据共享方法、设备及系统 | |
| CN117811734B (zh) | 业务源码加密存储与评估与鉴权方法 | |
| JP2008294861A (ja) | 鍵管理方法及びシステム及びサービス提供センタ装置及びｉｃカード及びプログラム | |
| CN121118085A (zh) | 针对u型推测解码推理框架的隐私保护方法及推理方法 | |
| CN120415700A (zh) | 一种基于ascon-puf的芯片ip认证与按设备付费许可方法及设备 | |
| HK40025607B (en) | Method and apparatus for authenticating biometric payment device, computer device and storage medium | |
| HK40025607A (en) | Method and apparatus for authenticating biometric payment device, computer device and storage medium | |
| CN115222393A (zh) | 一种基于puf的数字货币防重复花费方法及系统 | |
| CN111062005A (zh) | 版权认证密码的生成方法、认证方法、装置及存储介质 | |
| JP2007251437A (ja) | 認証方法及び安全な通信制御方法 |