ES2962688T3 - Módulo electrónico conectable formado por clústeres de elementos asegurados - Google Patents
Módulo electrónico conectable formado por clústeres de elementos asegurados Download PDFInfo
- Publication number
- ES2962688T3 ES2962688T3 ES19212398T ES19212398T ES2962688T3 ES 2962688 T3 ES2962688 T3 ES 2962688T3 ES 19212398 T ES19212398 T ES 19212398T ES 19212398 T ES19212398 T ES 19212398T ES 2962688 T3 ES2962688 T3 ES 2962688T3
- Authority
- ES
- Spain
- Prior art keywords
- secure elements
- cryptographic
- elementary
- secure
- data
- 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.)
- Active
Links
- 238000012545 processing Methods 0.000 claims abstract description 56
- 238000000034 method Methods 0.000 claims description 22
- 230000000295 complement effect Effects 0.000 claims description 6
- 238000004590 computer program Methods 0.000 claims description 5
- 230000010365 information processing Effects 0.000 claims description 4
- 238000001368 micro-extraction in a packed syringe Methods 0.000 claims description 4
- 238000009826 distribution Methods 0.000 claims description 3
- 238000003672 processing method Methods 0.000 claims description 3
- 238000012795 verification Methods 0.000 abstract description 8
- 238000004364 calculation method Methods 0.000 abstract description 6
- 230000006854 communication Effects 0.000 description 19
- 238000004891 communication Methods 0.000 description 19
- 230000008569 process Effects 0.000 description 10
- 230000004044 response Effects 0.000 description 8
- 230000002123 temporal effect Effects 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 230000032258 transport Effects 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 6
- 238000003860 storage Methods 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 238000013478 data encryption standard Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 238000005520 cutting process Methods 0.000 description 2
- 230000015654 memory Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012163 sequencing technique Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000011282 treatment Methods 0.000 description 2
- VBMOHECZZWVLFJ-GXTUVTBFSA-N (2s)-2-[[(2s)-6-amino-2-[[(2s)-6-amino-2-[[(2s,3r)-2-[[(2s,3r)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-2-[[(2s)-2,6-diaminohexanoyl]amino]-5-(diaminomethylideneamino)pentanoyl]amino]propanoyl]amino]hexanoyl]amino]propanoyl]amino]hexan Chemical compound NC(N)=NCCC[C@@H](C(O)=O)NC(=O)[C@H](CCCCN)NC(=O)[C@H](CCCCN)NC(=O)[C@H]([C@@H](C)O)NC(=O)[C@H]([C@H](O)C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCN=C(N)N)NC(=O)[C@@H](N)CCCCN VBMOHECZZWVLFJ-GXTUVTBFSA-N 0.000 description 1
- 235000015429 Mirabilis expansa Nutrition 0.000 description 1
- 244000294411 Mirabilis expansa Species 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000013496 data integrity verification Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 108010068904 lysyl-arginyl-alanyl-lysyl-alanyl-lysyl-threonyl-threonyl-lysyl-lysyl-arginine Proteins 0.000 description 1
- 235000013536 miso Nutrition 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000004513 sizing Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Classifications
-
- 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
- G06F21/72—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 in cryptographic circuits
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- 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
- G06F21/76—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 in application-specific integrated circuits [ASIC] or field-programmable devices, e.g. field-programmable gate arrays [FPGA] or programmable logic devices [PLD]
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
- H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
-
- 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/30—Security of mobile devices; Security of mobile applications
- H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/40—Security arrangements using identity modules
-
- 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/80—Wireless
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Storage Device Security (AREA)
- Credit Cards Or The Like (AREA)
Abstract
La invención se refiere a un módulo electrónico, del tipo tarjeta electrónica, conectable a un dispositivo host. El módulo incluye un controlador para comunicarse con el dispositivo anfitrión, así como grupos de elementos seguros, por ejemplo tarjetas inteligentes, conectados, dentro del mismo grupo, a un bus común que los conecta al controlador. Este último convierte una orden criptográfica recibida del dispositivo anfitrión en una pluralidad de tareas criptográficas elementales similares. Estas tareas elementales implementan la misma operación o función criptográfica, como cifrado, descifrado, firma, cálculo de datos de integridad, firma o verificación de integridad, pero utilizan información diferente. A continuación, el responsable del tratamiento controla la ejecución de estas tareas criptográficas elementales por parte de los elementos seguros. Se pueden agregar nuevos elementos seguros certificados al módulo, proporcionando escalabilidad y adaptabilidad de las capacidades de procesamiento, sin necesidad de recertificación. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Módulo electrónico conectable formado por clústeres de elementos asegurados
Campo técnico
La invención se encuentra en el campo de los módulos de hardware de seguridad (Hardware Security Module o HSM en inglés). Se trata, en particular, de un módulo electrónico, del tipo tarjeta electrónica, conectable a un dispositivo anfitrión. Técnica anterior
Un módulo de hardware de seguridad, en lo sucesivo denominado módulo HSM, es un aparato electrónico que ofrece funcionalidades criptográficas. En particular, los HSM se utilizan habitualmente para las siguientes tareas:
- la gestión, la importación, la exportación y la salvaguardia de claves criptográficas. En este caso, el módulo HSM debe poder establecer conexiones seguras con terminales remotos (p. ej., PINPAD) utilizando estas claves criptográficas;
- la preparación de datos, que comprende, por ejemplo, el procesamiento de datos (por ejemplo, cifrado) y la generación de claves criptográficas;
- la personalización a distancia que también comprende el procesamiento de datos (por ejemplo, cifrado y descifrado) sobre la marcha.
Hoy en día, los módulos HSM suelen adoptar la forma de tarjetas electrónicas criptográficas integradas, con por ejemplo una interfaz de conexión de tipo PCI porPeripheral Component Interconnecten inglés, PCI-express o incluso USB porUniversal Serial Busen inglés, o la forma de cajas SCSI/IP externas (Net HSM), por ejemplo.
Estos módulos HSM comprenden medios de procesamiento criptográfico, típicamente criptoprocesadores.
En la práctica, el hardware se suelda sobre los módulos HSM y estos últimos se pueden sellar con funcionalidades a veces de autodestrucción. No es así posible modificar la estructura de dicho módulo HSM, por ejemplo para añadir un criptoprocesador, sin tener que ponerse en contacto nuevamente con el fabricante. Además, como el módulo HSM debe garantizar niveles de seguridad suficientes, tradicionalmente está certificado. También, cuando se debe realizar una modificación, es necesario volver a certificar el módulo HSM una vez modificado. Sin embargo, estas modificaciones periódicas parecen necesarias, ya que el volumen de datos a procesar aumenta regularmente, así como la capacidad de cálculo requerida y el espacio de almacenamiento necesario.
Por otra parte, la adición de nuevos módulos de hardware HSM para seguir estas necesidades cada vez mayores de potencia de cálculo y de almacenamiento presenta un coste importante que convendría reducir.
Finalmente, la adición de tales módulos de hardware HSM también conduce a un aumento de energía y, por consiguiente, requiere una regulación térmica adecuada. A título ilustrativo, la actualización a distancia de 3,3 millones de tarjetas SIM de teléfonos móviles en un día requiere la potencia de cálculo de 150 a 200 servidores que incorporan módulos de hardware HSM.
Así, existe la necesidad de mejorar los módulos de hardware HSM existentes. En particular, es necesario mejorar su independencia respecto del fabricante para reducir así su coste de explotación y de adquisición, así como su flexibilidad respecto a las necesidades de recertificación y de capacidad de evolución de las capacidades de tratamiento. Estas diferentes necesidades pueden satisfacerse manteniendo un buen nivel de rendimiento y de seguridad de las operaciones criptográficas que son allí implementadas, considerándose como técnica anterior relevante el documento US2017/103217. Exposición de la invención
La invención está definida por las reivindicaciones independientes 1, 11 y 14.
Por tanto, la presente invención tiene por objeto paliar al menos uno de estos inconvenientes.
En este contexto, la invención propone en primer lugar un módulo electrónico, de tipo tarjeta electrónica, conectable a un dispositivo anfitrión, comprendiendo el módulo electrónico:
- un controlador de módulo configurado para comunicar con el dispositivo anfitrión, y
- uno o más clústeres (o agrupaciones) de elementos seguros conectados, dentro del mismo clúster, a un bus común que los une al controlador del módulo,
en el que el controlador de módulo está configurado para convertir una operación criptográfica (por ejemplo, un comando o solicitud recibida desde el dispositivo anfitrión a través de una interfaz de anfitrión del controlador) en una pluralidad de tareas criptográficas elementales similares utilizando información diferentes y para controlar la ejecución de las tareas criptográficas elementales por los elementos seguros.
Las tareas criptográficas elementales son similares en el sentido de que se basan, por ejemplo, en una misma operación o función criptográfica elemental, utilizando la totalidad o parte de informaciones/datos diferentes. A modo de ejemplo, una tarea elemental implementa una operación criptográfica elemental elegida entre una operación de cifrado de datos, una operación de descifrado de datos, un cálculo de firma de datos, una verificación de firma de datos, un cálculo de datos de integridad, una verificación de integridad de datos, una generación de claves criptográficas para ejemplo RSA. El resultado de una tarea elemental puede utilizarse en particular para realizar una tarea elemental siguiente en el mismo elemento seguro, o incluso para la tarea elemental de otro elemento seguro.
Un módulo así definido es evolutivo sin requerir una recertificación para cada modificación. De hecho, es fácil añadir nuevos elementos seguros ya certificados en un clúster existente o en forma de un nuevo clúster para aumentar las capacidades de procesamiento criptográfico y de almacenamiento seguro. Además, al igual que el controlador de módulo, que no efectúa ninguna operación delicada y se contenta con formar y enviar las tareas elementales, no tiene que ser modificado desde el punto de vista de la seguridad (es decir, en relación con una operación criptográfica), no es necesaria ninguna recertificación.
Por otra parte es preferible configurar cada elemento seguro para una tarea (u operación) elemental particular con el fin de sacar provecho de todas sus capacidades de procesamiento criptográfico.
Correlativamente, la invención también se refiere a un procedimiento de procesamiento en un módulo electrónico, del tipo tarjeta electrónica, conectable a un dispositivo anfitrión y que comprende un controlador de módulo configurado para comunicarse con el dispositivo anfitrión y uno o más clústeres de elementos seguros conectados, dentro del mismo clúster, a un bus común que los une al controlador de módulo, comprendiendo el procedimiento las siguientes etapas:
- convertir, mediante el controlador de módulo, una operación criptográfica en una pluralidad de tareas criptográficas elementales similares utilizando informaciones diferentes, y
controlar la ejecución de las tareas criptográficas elementales por los elementos seguros.
Un servidor puede comprender una unidad de procesamiento y una pluralidad de módulos electrónicos como se han definido anteriormente conectados a la unidad de procesamiento.
Otras características del método y del módulo electrónico o del servidor según modos de realización de la invención se describen a continuación.
En un modo de realización, las tareas criptográficas elementales ejecutadas simultáneamente por los elementos seguros implementan la misma operación criptográfica elemental sobre datos con ayuda de una clave criptográfica específica para cada elemento seguro. La simultaneidad puede ser total o parcial (para tener en cuenta un desfase en la transmisión de comandos elementales correspondientes a los elementos seguros). De este modo se puede paralelizar la misma operación para diferentes claves criptográficas.
Este es, por ejemplo, el caso cuando la tarea criptográfica elemental comprende la generación de datos cifrados dedicados a una flota remota de equipos objetivos, por ejemplo de elementos seguros, y cada uno de los elementos seguros del módulo electrónico implementa una clave criptográfica, por ejemplo una clave de sesión, específica de un respectivo equipo objetivo/elemento seguro de la flota remota. La flota es “remota” porque es distinta del equipo anfitrión que recibe el módulo electrónico. A modo de ejemplo, podría tratarse de una flota de terminales móviles en el campo o de una flota de tarjetas con chip para configurar.
Dicho enfoque se puede utilizar para gestionar a distancia una flota de tarjetas SIM o eUICC, por ejemplo. Según este enfoque, cada uno de la totalidad o parte de los elementos seguros del módulo electrónico puede así emparejarse con un elemento seguro de dicha flota remota, denominado elemento seguro remoto. Cada uno de estos elementos seguros del módulo electrónico puede entonces, por ejemplo, generar (en particular mediante diversificación) una clave criptográfica a partir de una información secreta compartida con el elemento seguro emparejado, tal como una clave maestra, y de un número de serie, con fines de procesar ( por ejemplo, cifrar o descifrar) datos específicos del elemento seguro emparejado.
Según una característica particular, los elementos seguros del módulo electrónico son del mismo tipo que los elementos seguros de la flota remota. En esta configuración, el módulo electrónico no requiere ventajosamente ninguna certificación adicional del hardware a la ya realizada para los SE de la flota.
En una aplicación particular del enfoque definido anteriormente, los datos procesados simultáneamente por los elementos seguros del módulo electrónico son idénticos y comprenden datos de actualización de un sistema operativo (OS) de los elementos seguros de la flota remota. Alternativamente, puede tratarse de datos de actualización de cualquier aplicación instalada o que se ha de instalar en los elementos seguros remotos.
Así, los mismos datos del sistema operativo (OS) son cifrados, por los elementos seguros del módulo electrónico, con ayuda de diferentes claves criptográficas correspondientes respectivamente a los elementos seguros remotos. Los inventores han constatado que tal módulo electrónico según la invención ofrece prestaciones interesantes, en particular, para el cifrado de un sistema operativo (OS) (o de una aplicación) actualizado que se ha de difundir a un gran número de tarjetas SIM o eUICC. Medios clásicos, tipo OTA (por “over-the-air”) vía SMS con protocolo cifrado, o bien, por ejemplo, vía el protocolo HTTPs (por “Hypertext Transfer Protocol Secure” en inglés) basado en HTTP (por “Hypertext Transfer Protocol Secure”) protegido por PSK TLS (para “Pre-Shared Key Transport Layer Security” (“Seguridad de la capa de transporte de clave pre-compartida”)) se pueden utilizar para enviar los bloques cifrados del sistema operativo (OS) actualizados a estas tarjetas remotas.
En otra aplicación considerada, los datos procesados simultáneamente por los elementos seguros del módulo electrónico comprenden datos de perfil de telefonía móvil específicos de los respectivos elementos seguros de la flota remota. Un perfil de telefonía móvil contiene, por ejemplo, todos los datos o características necesarios para que un operador de telefonía móvil (denominado MNO por "mobile network operator” (“operador de red móvil")) identifique el elemento seguro (generalmente una tarjeta SIM, UICC o eUlCC) en su red móvil y ofrecerle así capacidades de comunicación y conectividad. El módulo electrónico de la invención permite aquí a un operador móvil MNO gestionar eficazmente los perfiles a cargar entre sus abonados.
En otro modo de realización, las tareas criptográficas elementales ejecutadas simultáneamente (aún una vez al menos parcialmente) por los elementos seguros de un clúster implementan la misma operación criptográfica elemental sobre diferentes datos con ayuda de una misma clave criptográfica compartida por los elementos seguros. Este enfoque permite procesar, por ejemplo cifrar o descifrar, de manera eficiente y a menor coste, un flujo de datos realizando un procesamiento al menos parcialmente paralelo sobre bloques constituyentes (normalmente consecutivos) del flujo. En este caso, los diferentes datos corresponden a diferentes partes (por ejemplo, bloques) de un mismo flujo de datos. Se ve así que variando el número de elementos seguros, sin nueva certificación, es posible adaptar el módulo electrónico al caudal del flujo a procesar, en particular para garantizar un procesamiento en tiempo real (por ejemplo, se puede aumentar el número de elementos seguros si los flujos a procesar son de mayor tamaño).
Para realizar un enlace seguro entre dos ordenadores, se puede prever ventajosamente utilizar un módulo electrónico según la invención en cada uno de los dos extremos. De este modo, es posible ajustar rápidamente las capacidades de cada uno de los extremos a las necesidades, por ejemplo al volumen de procesamiento en tiempo real permitido por la red, a las capacidades del otro extremo, etc. En este caso, la invención propone un sistema que comprende dos dispositivos que se comunican entre sí, comprendiendo cada dispositivo un módulo electrónico tal como se ha definido anteriormente, implementando los elementos seguros de uno de los dos dispositivos tareas criptográficas elementales que son complementarias (es decir, recíprocas, tales como cifrado/descifrado, firma/verificación de firma, etc.) de los implementados por los elementos seguros del otro dispositivo. En este caso, los datos procesados por uno de los módulos electrónicos se transmiten al otro módulo electrónico para un procesamiento inverso o recíproco.
En un modo de realización de la invención, todos los elementos seguros de un clúster están configurados para implementar la misma operación criptográfica elemental utilizando informaciones diferentes y al menos dos clústeres están configurados para implementar dos operaciones criptográficas elementales diferentes. Por tanto, es posible dedicar diferentes partes de hardware del módulo electrónico a tareas diferentes, eventualmente complementarias. En particular, esta disposición permite el establecimiento a largo plazo del enlace seguro mencionado anteriormente, pudiendo cada ordenador implementar las diferentes operaciones criptográficas para una comunicación bidireccional segura (por ejemplo un clúster para el cifrado antes de la transmisión y el otro clúster para el descifrado de los datos recibidos).
En otro modo de realización de la invención, el controlador del módulo comunica con los elementos seguros según un modo maestro/esclavo para la ejecución de las tareas criptográficas elementales. Esto permite un control preciso de la pluralidad de elementos seguros.
En otro modo de realización más, los elementos seguros están certificados, en particular los elementos seguros cumplen con al menos una de las siguientes normas de seguridad: FIPS 140-3/4, Criterios Comunes EAL4+ o versión 3.1 versión 4, MEPS, MEPS2, ISO/IEC19790:2012. La seguridad del módulo electrónico está garantizada por la certificación de cada elemento seguro que contiene.
En aún otro modo de realización, un bus que conecta los elementos seguros de un clúster a dicho controlador de módulo es un bus SPI o I2C o I3C o ISO o UART (para "Universal Asynchronous Receiver Transmitter” o emisor receptor asíncrono universal). En este caso, el controlador incluye una interfaz (con su correspondiente microcontrolador) SPI, ISO, UART, I2C (versión 6.0 del 4 de abril de 2014) o I3C (MIPI I3C v1.0).
En otro modo de realización aún, los elementos seguros del o de los clústeres están dispuestos en dos caras opuestas de la tarjeta electrónica. Esta disposición permite aumentar la capacidad de procesamiento del módulo electrónico, a un coste reducido.
En aún otro modo de realización, los elementos seguros de un clúster están dispuestos para ejecutar tareas criptográficas elementales similares utilizando informaciones diferentes en paralelo. El control de la ejecución en paralelo (al menos parcialmente) lo realiza en particular el controlador de módulo, que puede, por ejemplo, actuar como maestro frente a los elementos seguros que actúan como esclavos. En función de las capacidades de los buses de comunicación entre el controlador del módulo y los elementos seguros, esta disposición permite optimizar el uso de los recursos criptográficos formados por los elementos seguros. La ejecución paralela por los elementos seguros se repite en el tiempo (generalmente sobre bloques de datos sucesivos a tratar) permitiendo obtener rendimientos de procesamiento al menos equivalentes al de los módulos HSM de la técnica anterior.
Según una característica particular, el controlador de módulo está configurado para multiplexar temporalmente en el bus del clúster, durante un intervalo de tiempo correspondiente a un período estimado de ejecución de una tarea criptográfica elemental por un elemento seguro, comandos elementales destinados a los elementos seguros del clúster para la ejecución (al menos parcialmente) simultánea de tareas criptográficas elementales por estos elementos seguros durante un período de ejecución posterior. Así, mientras los elementos seguros ejecutan su tarea actual (durante el período estimado), el controlador de módulo transmite el siguiente comando para ejecutar durante el siguiente período. Este comando puede incluir en particular el bloque de datos que deben procesarse durante este período siguiente. Al realizarse así la multiplexación temporal, se optimiza la utilización del bus para aumentar la capacidad de procesamiento criptográfico del clúster.
Cabe señalar que un bus full duplex permite al mismo tiempo que el controlador de módulo reciba los bloques procesados por los elementos seguros durante un periodo precedente.
Según otra característica particular, el número de elementos seguros sobre el clúster está limitado (es decir, inferior o igual) a la relación entre la duración del período estimado de ejecución de una tarea criptográfica y el tiempo de transmisión de un comando elemental (a un SE). Esta disposición garantiza que el controlador de módulo pueda abordar cada elemento seguro en el clúster durante cada período estimado. Todos los elementos seguros pueden así ejecutar una tarea elemental en cada período sucesivo, optimizando así la utilización de los recursos criptográficos del módulo electrónico.
En aún otro modo de realización, el módulo electrónico tiene la forma de una tarjeta electrónica que se puede conectar a un ordenador.
En un modo de realización particular, las diferentes etapas del procedimiento antes mencionado son determinadas por instrucciones de un programa informático.
Por consiguiente, la invención se refiere también a un programa informático sobre un soporte de informaciones, siendo este programa susceptible de ser implementado por una unidad de procesamiento, comprendiendo este programa instrucciones adaptadas a la implementación de las etapas del procedimiento tal como se ha mencionado anteriormente.
Este programa puede utilizar cualquier lenguaje de programación y estar en forma de código fuente, código objeto o código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada o en cualquier otra forma deseable.
La invención también se refiere a un soporte de informaciones legible por una unidad de procesamiento, y que comprende instrucciones de un programa informático tal como se ha mencionado anteriormente.
El soporte de informaciones puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo una ROM de microcircuito, o incluso un medio de grabación magnético, por ejemplo un disco duro, o incluso una memoria flash.
Por otra parte, el soporte de informaciones puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede encaminarse a través de un cable eléctrico u óptico, por radio o por otros medios. El programa según la invención puede descargarse en particular en una plataforma de almacenamiento de una red de tipo Internet.
Alternativamente, el soporte de informaciones puede ser un circuito integrado en el que se incorpora el programa, estando adaptado el circuito para ejecutar o utilizarse en la ejecución del procedimiento en cuestión.
El soporte de informaciones y el programa informático antes mencionados tienen características y ventajas similares al procedimiento que implementan.
Breve descripción de los dibujos
Otras particularidades y ventajas de la invención aparecerán aún en la descripción siguiente, ilustrada por las figuras adjuntas que ilustran ejemplos de realización desprovistos de cualquier carácter limitativo.
[Fig. 1] La Figura 1 representa esquemáticamente un contexto en el que es necesario un conjunto de servidores HSM según la técnica anterior para actualizar una flota de elementos seguros en terminales.
[Fig. 2] La Figura 2 representa esquemáticamente un sistema en el que se utiliza un módulo electrónico según una realización particular.
[Fig. 3] La Figura 3 representa esquemáticamente un módulo electrónico según un modo de realización particular.
[Fig.4] La Figura 4 representa esquemáticamente la arquitectura lógica de un controlador de módulo electrónico según un modo de realización particular.
[Fig. 5] La Figura 5 representa en forma de diagrama de flujo, las principales etapas de un procedimiento implementado por un módulo electrónico del controlador según un modo de realización particular.
[Fig. 6] La Figura 6 ilustra la secuencia temporal de los comandos intercambiados entre las interfaces del controlador del módulo electrónico y los elementos seguros conectados, en un modo de realización particular.
Descripción detallada
Generalmente, la invención se refiere a un módulo electrónico conectable a un dispositivo anfitrión, respetando las normas de seguridad de un módulo hardware de seguridad HSM. En particular, este módulo electrónico está diseñado, por ejemplo, para conectarse a una bahía de servidor, garantizando así su modularidad y capacidad de evolución. El servidor puede así comprender una unidad de procesamiento y una pluralidad de dichos módulos electrónicos, enchufados en la bahía, conectados a la unidad de procesamiento.
La Figura 1 representa esquemáticamente un contexto de la técnica anterior, en el que es necesario un conjunto de servidores clásicos 14-X dotados de módulos HSM para realizar procesamientos criptográficos destinados a uno o más equipos objetivo 10-X de un conjunto 10 de equipos.
Como se ha ilustrado, los equipos objetivo pueden ser terminales móviles 10-1, 10-2, 10-3, 10-4 y 10-5, 10-6, 10-7, 10-8 que forman una flota en el campo de elementos seguros (no representados) incorporados, o incluso soldados, en los terminales.
Alternativamente, los equipos objetivo 10-X puede estar en fábrica, listos para ser personalizados como consecuencia de los procesamientos criptográficos aquí mencionados.
Por ejemplo, los terminales 10-1, 10-2, 10-3, 10-4 son teléfonos móviles básicos que incorporan un elemento seguro amovible (primer tipo de elemento seguro), por ejemplo una UICC(Universal Integrated Circuit Carden inglés) conforme a la norma ETSI TS 102221 v.11.0.0, y los terminales 10-5, 10-6, 10-7, 10-8 son teléfonos inteligentes(smartphonesen inglés) en los que se sueldan elementos seguros embarcados (segundo tipo de elementos seguros), por ejemplo una eUICC(embedded Universal Integrated Circuit Carden inglés), tal como se refiere en la norma ETSI TS 103383 v.13.2.0.
A continuación, los equipos objetivo se designan por la referencia genérica 10, salvo mención contraria. En ciertos modos de realización, la totalidad o parte de los equipos objetivo no incorpora necesariamente elementos seguros. Por ejemplo, los procesamientos criptográficos puedes implementar un protocolo de transporte de datos seguro, por ejemplo el protocolo TLS (para “Transport Layer Security” (“seguridad de la capa de transporte”)), destinado a equipos convencionales (desprovistos de elementos seguros).
Todos estos equipos objetivo son capaces de comunicarse a través de una o más redes de comunicación NTW 12. La red 12 es, por ejemplo, una red de telefonía móvil que comprende convencionalmente estaciones base (no representadas) para conectar los terminales móviles, así como una pluralidad de entidades (tipo pasarela GMSC, servidores HLR, MSC, VLR, etc., no representados). La red 12 comprende por ejemplo un servidor de gestión de suscripciones (no representado,Subscription Manageren inglés) cuya función clásica es gestionar las flotas de elementos seguros, y más precisamente gestionar (cargar sobre, actualizar en, eliminar desde terminales móviles) perfiles de abonados con operadores móviles MNO.
En la variante en la que los equipos objetivo está en fábrica, la red 12 puede ser un simple bus de comunicación.
También de manera conocida, los elementos seguros incorporados en los equipos objetivo 10 están equipados con un sistema operativo en el que se ejecutan funciones seguras ofrecidas a las aplicaciones de los terminales, por ejemplo funciones de cifrado para transacciones de pago a través de una aplicación de pago móvil prevista en los terminales.
Este sistema operativo de los elementos seguros puede actualizarse, generalmente bajo la responsabilidad del operador del MNO. Asimismo, los perfiles de los abonados podrán ser actualizados en los elementos seguros, bajo la acción del servidor de gestión de suscripciones. Para hacer esto, la actualización, es decir, los datos de actualización, deben cargarse en todos los terminales de la flota, es decir, en un gran número de elementos seguros.
Clásicamente, esta actualización se efectúa a distancia, por vía OTA, por medio de numerosos servidores 14-1, 14-2, 14 3, 14-4, 14-5, 14-6 que ofrecen funcionalidades criptográficas por módulos HSM, soportando por ejemplo los siguientes algoritmos criptográficos: DES (“Data Encryption Standard” (“Estándar de cifrado de datos”)), 3DES (Triple DES), AES (“Advanced Encryption Standard” (“Estándar de cifrado avanzado”)), RSA (Rivest, Shamir y Adelman), ECC (Criptografía sobre las curvas elípticas), MD5 (Message Digest 5), SHA-1 (“Secure Hash Algorithm 1” (“Algoritmo Hash seguro 1”)) o SHA-2. Posteriormente, estos servidores equipados con módulos HSM de la técnica anterior se designan con la referencia genérica 14.
Como ya se ha mencionado, estos servidores son sellados y ofrecen poca modularidad por lo que es necesario volver a su fabricante para modificarlos o certificarlos.
De una manera más general, esta desventaja surge cuando es necesario realizar un gran número de operaciones criptográficas seguras (donde el acceso a las claves criptográficas debe estar altamente protegido). De hecho, hasta la fecha, sólo los servidores equipados con módulos HSM parecen diseñados para tal utilización.
Se diseña así un módulo electrónico, del tipo tarjeta electrónica, conectable a un dispositivo anfitrión, como alternativa a los módulos HSM caros y poco modulares o poco evolutivos de la técnica anterior. Comprende, además de un controlador de módulo configurado para comunicarse con el dispositivo anfitrión, uno o más clústeres de elementos seguros conectados, dentro de un mismo clúster, a un mismo bus, es decir un bus común, que los conecta con el controlador. La capacidad evolutiva y la modularidad residen en parte en la organización de los elementos seguros en clústeres que permite añadir o eliminar uno o más clústeres, pero también en el uso de entidades elementales de procesamiento, en este caso los elementos seguros, que son fáciles de añadir o eliminar bajo demanda.
El controlador de módulo se configura entonces para convertir una operación criptográfica (por ejemplo, un comando o una solicitud recibida desde el dispositivo anfitrión a través de una interfaz de anfitrión del controlador) en una pluralidad de tareas criptográficas elementales similares usando informaciones diferentes y luego para controlar la ejecución de las tareas criptográficas elementales por los elementos seguros, es decir enviar comandos correspondientes a los diferentes elementos seguros.
De forma general, los elementos seguros del módulo electrónico garantizan su seguridad, sin que sea necesario un componente seguro adicional en la tarjeta. Así estos elementos seguros pueden ser gestionados por un controlador de módulo no seguro, por ejemplo un circuito FPGA (“Field-Programmable Gate Array” para red de puertas programable), sin que esto afecte a la seguridad del módulo, tanto a nivel de protección de datos (en particular, secretos tales como claves criptográficas), como frente a ataques físicos contra el módulo.
Ventajosamente, la seguridad inherente a los elementos seguros, cuando están certificados, permite efectuar operaciones criptográficas en un entorno completamente seguro, y ello a bajo coste. La pluralidad de elementos seguros permite también efectuar estas operaciones en paralelo (al menos parcialmente), de modo que la potencia de cálculo global del módulo electrónico en un instante dado permite asegurar las funciones criptográficas de los módulos HSM de la técnica anterior, por un coste mucho menor.
Además, esta seguridad inherente de los elementos seguros permite una cierta modularidad del módulo electrónico ya que la adición de elementos seguros en el módulo (en un clúster existente o como un clúster nuevo) no requiere certificación adicional.
La figura 2 representa esquemáticamente un sistema en el que se utiliza un módulo electrónico 22 según la invención. Esta figura ilustra dos aplicaciones típicas de uso de este módulo, dependiendo por ejemplo de si el o los equipos objetivo son una flota de terminales móviles 10 equipada con elementos seguros o si es el propio equipo 10' dotado de uno o más módulos electrónicos según la invención. Por supuesto, como variante, los terminales objetivo pueden ser simples ordenadores o servidores dotados o no de elementos seguros, o incluso ser simplemente elementos seguros (por ejemplo tarjetas inteligentes a configurar en fábrica).
En estas diversas aplicaciones, el servidor 20 se comunica con los equipos objetivo 10, 10', implicando esta comunicación la realización de una operación criptográfica, tal como por ejemplo el cifrado de datos a transmitir a los equipos objetivo, el descifrado de los datos cifrados recibidos desde los equipos objetivo, la firma de datos a transmitir, la verificación de una firma recibida, el cálculo de datos de integridad de los datos a transmitir, la verificación de los datos de integridad, la generación de claves criptográficas para personalizar los equipos objetivo (normalmente tarjetas con chip), etc.
Para hacer esto, los inventores prevén, en lugar de los servidores sellados 14 de la técnica anterior, uno o más módulos electrónicos 22 nuevos conectables al equipo anfitrión 20, tal como un servidor, típicamente en una bahía. Cada módulo electrónico 22 cumple individualmente los estándares de seguridad de un módulo HSM clásico, gracias en particular a la certificación individual de cada uno de los elementos seguros que lo constituyen, por ejemplo conforme a una de las normasFederal Information Processing StandardFIPS 140-3/4 ( proyecto 140-3 del 7 de marzo de 2013 o proyecto 140-4 del 1 de julio de 2014); Criterios comunes CC EAL4+ o versión 3.1;“Minimum Energy Performance Standard’(“Norma de Rendimiento Energético Mínimo”) MEPS o MEPS2, ISO/IEC19790:2012.
Una bahía de este tipo que comprende una pluralidad de módulos electrónicos conectables puede así constituir ventajosamente un servidor modular que ofrezca funcionalidades criptográficas que permitan garantizar un nivel de seguridad comparable a los módulos HSM clásicos siendo al mismo tiempo mucho menos costoso, más cómodo de certificar y menos voluminoso.
Un módulo electrónico 22, un ejemplo del cual se describe aquí con referencia a la Figura 3, comprende una tarjeta electrónica, un medio 30 de conexión a la bahía (por ejemplo una interfaz PCI, preferiblemente PCI-Express, con un dispositivo anfitrión, aquí el servidor 20), un controlador de módulo 32, uno o más clústeres 34-1, 34-2, 34-3, 34-4, 34-5, 34-6 (referenciados más generalmente con 34) de elementos seguros 35-1,35 -2, 35-3 (referenciados más generalmente con 35) conectados, dentro del mismo clúster 34, a un mismo bus 36-1,36-2, 36-3, 36-4, 36-5, 36-6 (referenciados más generalmente con 36) que los conecta al controlador, así como una memoria volátil 37 de trabajo, tipo RAM (por “random access memory” (“memoria de acceso aleatorio”).
El bus que conecta los elementos seguros de un clúster 34 a dicho controlador de módulo 32 es típicamente un bus preferiblemente SPI o alternativamente I2C o I3C o incluso ISO o UART, y el controlador 32 incluye entonces interfaces 33-1,33-2, 33- 3, 33-4, 33-5, 33-6 de comunicación (referenciados más generalmente con 33) correspondientes, uno por clúster 34. Se pueden utilizar diferentes tipos de bus internos 36, aunque preferentemente se implementa el mismo tipo de bus.
El medio 30 de conexión está conectado mediante un bus 31 de comunicación al controlador 32. El bus 31 es por ejemplo del tipo PCI o PCI-e (porPeripheral Component Interconnect Expressen inglés), del tipo I2C (porInter-Integrated Circuiten inglés) o del tipo I3C. PCI-e, I2C e I3C son marcas comerciales.
El controlador de módulo 32 puede ser reconfigurable, por ejemplo ser una red de puertas programables FPGA. El controlador de módulo 32 normalmente comunica con los elementos seguros en un modo maestro/esclavo para la ejecución de tareas criptográficas elementales por los elementos seguros. Así, cada clúster 34 está formado por una pluralidad de elementos seguros 35 (aunque ocasionalmente un clúster puede contener un único elemento seguro por razones de tamaño si los otros clústeres están llenos), desempeñando cada uno el papel de esclavo en la comunicación con el controlador 32.
En la práctica, el tamaño de los clústeres depende de las capacidades de las interfaces 33 de comunicación. Por ejemplo, el número de elementos seguros en un clúster puede corresponder (en cualquier caso estar limitado, es decir, menor o igual) a la relación entre la duración (T en la Figura 6 que se describe a continuación) del procesamiento, por ejemplo del cifrado, de un bloque de un tamaño dado (y más generalmente, una duración estimada de ejecución de una tarea criptográfica por un elemento seguro) y la duración del transporte (T1 en la Figura 6 que se describe a continuación) de este bloque en el bus de comunicación (en otros términos el tiempo de transmisión del comando elemental correspondiente, que incluye el bloque a procesar). Así, es posible optimizar la banda pasante entre la interfaz 33 de comunicación y el clúster 34 de elementos seguros 35 para minimizar el número de interfaces 33 necesarias.
En un modo de realización, los elementos seguros del o de los clústeres están dispuestos en dos caras opuestas de la tarjeta electrónica, para aumentar los rendimientos de procesamiento del módulo electrónico, siempre que el controlador 32 tenga suficientes interfaces 33.
En ciertos casos, los clústeres 34 pueden ser de diferentes tamaños, es decir comprender un número diferente de elementos seguros 35. Sin embargo, la utilización de clústeres del mismo tamaño permite simplificar su gestión por parte del controlador 32.
En términos generales, un módulo 22 conforme a los modos de realización soporta API clásicas (por Application Programming Interface en inglés) para comunicar con el equipo anfitrión 20, por ejemplo del tipo PKCS#11, Open SSL, MS CAPI, Java JCE/JCA. También se admiten Windows (marca) y Linux (marca).
Los modos de realización previstos no se limitan al número de interfaces 33, de clústeres 34, de elementos seguros 35 representados.
Como se ha introducido anteriormente, para realizar una operación criptográfica solicitada por ejemplo mediante un comando o solicitud del servidor 20, el controlador 32 descompone, es decir convierte, esta operación criptográfica en una pluralidad de tareas criptográficas elementales similares que debe asignar a los distintos elementos seguros 35 que tiene a su disposición.
El dimensionamiento de los clústeres 34 de elementos seguros 35 (en términos del número de clústeres y del número de elementos seguros) se puede realizar previamente a partir de un volumen de procesamientos criptográficos predefinido, por ejemplo la actualización del sistema operativo (OS) de 3,3 millones de equipos objetivo por día (como se muestra en el siguiente ejemplo). El controlador de módulo 32 tiene así conocimiento de qué interfaces 33 están conectadas a los clústeres 34 y el número de elementos seguros 35 en cada clúster. Además, se pueden utilizar medios de direccionamiento convencionales en los bus 36 para permitir una comunicación entre el controlador 32 y cada uno de los elementos seguros 35.
Con fines de optimización, el controlador de módulo 32 controla los elementos seguros 35 de un clúster 34 para ejecutar (al menos parcialmente) tareas criptográficas elementales similares utilizando informaciones diferentes en paralelo. El controlador puede, por ejemplo, aprovechar la multiplexación de comandos destinados a enviar estas tareas elementales a los buses que conectan cada uno de los clústeres. En detalle, el módulo controlador 32 puede multiplexar temporalmente en el bus de un clúster, durante un intervalo de tiempo T correspondiente a un período estimado de ejecución de una tarea criptográfica elemental por un elemento seguro, comandos elementales destinados a los elementos seguros del clúster para la ejecución simultánea de tareas criptográficas elementales por estos elementos seguros durante un período de ejecución posterior.
Esta multiplexación se ilustra en la Figura 6 (descrita posteriormente) desde el punto de vista del controlador 32 (que envía los comandos elementales y luego recibe las respuestas) para comandos elementales de cifrado destinados a un elemento seguro de un clúster.
Las líneas de puntos de la primera línea ilustran el envío de comandos multiplexados (con bloques para cifrar, por ejemplo, generalmente cualquier dato para procesar) a otros cuatro elementos seguros durante el período asignado T (friso superior), luego la recepción de las cuatro respuestas correspondientes (bloques cifrados) con un desfase de un período T (friso intermedio). Los cinco elementos seguros de este ejemplo procesan (cifran) los datos simultáneamente, al menos parcialmente (durante el período asignado T, como lo muestra la superposición de los procesamientos representados en la parte inferior de la figura).
La figura 4 representa esquemáticamente una posible arquitectura lógica para un controlador según un modo de realización particular, por ejemplo el controlador 32 de la figura anterior.
En este ejemplo, el controlador 32 es una FPGA. Comprende una interfaz PCI-Express 40. Esta interfaz 40 está configurada para comunicarse con los medios 30 de conexión mostrados en la Figura 3, a través de un bus 31 también mostrado en la Figura 3.
El controlador 32 incluye una máquina 42 de estado(Data Dispatcheren inglés) configurada para gestionar el transporte de datos en la arquitectura lógica. También está configurado para comunicarse con la memoria RAM 37 en la Figura 3.
Esta máquina 42 de estados también está conectada a los multiplexores 44 y 46 que también forman parte del controlador 32. Estos multiplexores son responsables de gestionar la distribución de datos entre las m interfaces de comunicación 33 1, 33-2,...33-m (en la Figura 3, m=6). En la práctica, cada interfaz 33-i tiene una memoria tampón RAM interna (no representada) para almacenar los datos a procesar por los elementos seguros 35 del correspondiente clúster 34-i, por ejemplo datos de diversificación para la generación de claves criptográficas, bloques de datos (por ejemplo, bloque de actualización de un sistema operativo OS o bloque de perfil de abonado) a cifrar o descifrar o a partir de los cuales se debe calcular una firma o información de integridad, firmas que se deben verificar, informaciones de integridad que se deben verificar, etc.
En este ejemplo, las interfaces de comunicación son de tipo SPI. En la práctica, la interfaz comunica una señal de reloj denominada SCLK, una señal MOSI (porMaster Out Slave Inen inglés) que transmite datos procedentes del controlador (maestro) a uno de los elementos seguros (esclavos) del clúster, una señal MISO (porMaster In Slave Outen inglés) que transmite datos desde un elemento seguro (esclavo) con destino al controlador (maestro), una señal de selección (denominada CS[0,n-1]) de un elemento seguro dado en el bus. Estas diferentes señales permiten la comunicación en el bus entre el controlador 32 y cada uno de los elementos seguros 35 del clúster conectado 34-i.
En otro ejemplo, las interfaces de comunicación son del tipo I2C. En la práctica, la interfaz comunica una señal de reloj SCL (paraSerial Clock Line(“Línea de reloj en serie”)) y una señal SDA (paraSerial Data Line(“Línea de datos en serie”)) transmitiendo datos procedentes del controlador y de los elementos seguros del clúster. La selección de un elemento seguro en el clúster se realiza mediante la transmisión desde el controlador de su dirección única al bus antes de cada transacción.
Los vínculos lógicos (representados por flechas llenas) entre los elementos constitutivos del controlador y los elementos vinculados a él son los siguientes:
-PCI_data_in: este bus PCI transporta datos procedentes de la interfaz PCI-Express 40;
-RAM_in: este bus transporta estos datos hasta la memoria RAM 37;
-RAM_out: este bus transporta los datos desde la RAM 37 al multiplexor 44;
-SPI_data: este bus transporta los bloques de datos o datos de diversificación hasta las interfaces 33;
-SPI_data_out 1...m: este bus transporta los bloques cifrados (por los elementos seguros) recibidos desde las interfaces 33;
-PCI_data_out: este bus transporta los datos (cifrados) a enviar a la interfaz PCI-Express 40.
Los comandos intercambiados (intercambios representados por flechas de puntos) con la máquina 42 de estados y los demás elementos son los siguientes:
-PCI_send: comando de envío de datos (cifrados) a la bahía (al PC) por la interfaz PCI-express;
-PCI_receive: comando de recepción de datos (a cifrar) procedentes de la bahía (al PC) por la interfaz PCI-express;
-RAM read/writw: comando para lectura/escritura en la RAM 37;
-Ctrl_MUX1 / Ctrl_MUX2: comandos de los multiplexores 44 y 46;
-SPI_order 1...m: comandos de las interfaces SPI.
La Figura 6 ilustra la secuencia temporal de los intercambios entre las interfaces 33 del controlador 32 y los elementos seguros 35 conectados, en un modo de realización particular. Esta secuenciación se lleva a cabo al nivel de una interfaz 33, por ejemplo en un bus SPI, que permite al controlador transmitir y recibir simultáneamente. La secuenciación se basa en la multiplexación temporal, por período T, de los comandos elementales con destino a los elementos seguros 35 y, por consiguiente, en una multiplexación temporal en retorno de las respuestas de los elementos seguros 35.
Durante una etapa 60, se envían primeras órdenes elementales desde la interfaz 33 a los elementos seguros 35 del clúster 34 considerado según un multiplexación temporal. La línea continua corresponde al envío (de duración T1) a un primer elemento seguro determinado. Los trazos discontinuos de la primera línea muestran los envíos (de duración T1) a los demás elementos seguros del clúster durante el período predefinido T, aquí otros cuatro.
El primer comando elemental puede contener simplemente datos de diversificación (a veces específicos de los elementos seguros) para permitir que los elementos seguros generen su propia clave criptográfica y/o un primer bloque de datos a procesar (por ejemplo, primer bloque de sistema operativo OS actualizado o de perfil de abonado).
No representado, cada elemento seguro envía un mensaje de estado al recibir su comando elemental.
Al recibir estos primeros comandos elementales, cada elemento seguro 35 inicia la generación (por diversificación) de su clave criptográfica y/o el tratamiento criptográfico, por ejemplo de cifrado de un bloque de datos, utilizando esta clave (o cualquier otra clave ya memorizada). Esta es la etapa 62 donde los diferentes elementos seguros 35 del clúster operan en paralelo (véanse los cinco bloques 62 de procesamiento superpuestos en la parte inferior de la figura).
Durante una etapa 63 que comienza al final del primer periodo T, los siguientes comandos elementales (que incluyen un siguiente bloque de datos) son enviados sucesivamente por la interfaz 33 a los elementos seguros 35 según siempre la misma multiplexación temporal.
Cuando recibe este nuevo comando elemental, cada elemento seguro 35 ha terminado de procesar el bloque anterior. Luego comienza el procesamiento criptográfico del siguiente bloque así recibido (etapa 66).
Simultáneamente, reenvía el resultado del procesamiento anterior (por ejemplo, un bloque cifrado) durante la etapa 64. La interfaz 33 del controlador 32 recibe así todos los resultados de los diferentes elementos seguros siempre según la misma multiplexación temporal (en trazo continuo en la segunda línea, el retorno del primer elemento seguro, y en trazos discontinuos los retornos de los otros elementos seguros en el mismo orden que el envío de los comandos elementales).
Este proceso se repite mientras haya bloques de datos a procesar (envío del siguiente comando elemental en la etapa 65, recepción del segundo bloque procesado en la etapa 67).
Cuando se han enviado todos los bloques de datos a procesar, el controlador 32 puede enviar un comando elemental simplificado (sin bloque de datos) para pedir el resultado del último bloque procesado.
La figura 5 representa las etapas principales de un procedimiento implementado por el módulo electrónico 22 según un modo de realización particular.
Durante una etapa 50, se inicializa el módulo 22. Por tanto, su tarjeta electrónica está alimentada. Esto tiene el efecto de inicializar un canal de comunicación entre el módulo y el equipo anfitrión 20.
Luego, el módulo 22 (más precisamente el controlador 32 a través de la interfaz 30/31) recibe en la etapa 51 un comando del equipo anfitrión 20 con el fin de efectuar una operación criptográfica. Esta operación criptográfica (cuyos ejemplos se han presentado anteriormente) puede ser la totalidad o parte de una tarea solicitada por un usuario al equipo anfitrión.
A continuación, el controlador 32 realiza una conversión 52 de esta operación criptográfica en una multitud de tareas elementales que deben realizar los elementos seguros 35.
Esta conversión 52 puede comprender, por ejemplo, el corte 520 de datos a procesar en bloques de datos, la recuperación opcional 521 de datos de diversificación por elemento seguro, la formación 522 de comandos elementales y luego la asignación y programación 523 de estos comandos elementales por la interfaz SPI 33.
Los datos a cortar son, por ejemplo, datos de actualización de un sistema operativo OS, datos de perfil de abonado o un flujo de datos, por ejemplo multimedia. A título ilustrativo, el corte se realiza en bloques sucesivos de 240 octetos.
La etapa 521 es opcional pues se realiza si es necesario generar una clave criptográfica mediante el elemento seguro 35. En los ejemplos introducidos anteriormente, los datos de diversificación pueden incluir un identificador de un equipo objetivo 10, 10' y/o un dato de sesión (por ejemplo, un valor aleatorio compartido con el equipo objetivo).
Como se introdujo en relación con la Figura 6, se pueden crear tres tipos de comando elemental en la etapa 522 para cada elemento seguro 35 a solicitar.
El primer comando elemental incluye, por ejemplo, el primer bloque de datos a procesar por este elemento seguro 35, así como los datos de diversificación asignados al mismo (por ejemplo, el identificador de un equipo objetivo emparejado). Los comandos elementales posteriores sólo comprenden los bloques de datos posteriores a procesar por este elemento seguro 35. La respuesta a cada uno de estos comandos elementales posteriores es el resultado (bloque procesado) del procesamiento del comando elemental anterior.
El último comando no incluye ningún bloque de datos y solo solicita el resultado (bloque procesado) del procesamiento del comando elemental anterior (es decir el penúltimo comando elemental).
En los ejemplos descritos a continuación, los bloques de datos enviados a los elementos seguros 35 pueden ser idénticos (el caso, por ejemplo, de la actualización del sistema operativo OS del equipo objetivo 10): por lo tanto, cada elemento seguro 35 procesa los mismos datos para un dispositivo objetivo determinado.
Alternativamente, los bloques de datos enviados a los elementos seguros 35 pueden ser diferentes, por ejemplo ser bloques sucesivos de un archivo: los elementos seguros 35 realizan por tanto en paralelo un procesamiento en bloque de dicho archivo, por ejemplo utilizando la misma clave criptográfica (utilizada por el equipo objetivo en particular).
La etapa 523 permite que el controlador 32 asigne los diferentes comandos elementales así creados a las interfaces SPI 33 que van bien, y en un orden apropiado para la multiplexación temporal como se muestra, por ejemplo, en la Figura 6. Los comandos elementales ordenados se almacenan, por ejemplo, en la memoria RAM de las interfaces SPI 33.
Después, en la etapa 53, sigue el envío de los comandos elementales ordenados en la interfaz SPI 33 correspondiente. Esto da como resultado envíos sucesivos a los elementos seguros 35 como se muestra en la Figura 6.
Los procesamientos al nivel de los elementos seguros 35 consisten simplemente en ejecutar los comandos elementales recibidos y reenviar los resultados obtenidos (bloque procesado) como respuestas. Estos tratamientos son acompasados por los envíos de comandos elementales por el controlador 32.
En la etapa 54, el controlador 32 recibe así las respuestas de los elementos seguros solicitados, es decir principalmente de los bloques procesados (por ejemplo cifrados o descifrados).
Estos bloques recibidos se añaden en la etapa 55.
Por ejemplo, cuando cada elemento seguro 35 procesa los mismos datos para un equipo objetivo dado, son los bloques procesados recibidos del mismo elemento seguro 35 los que se añaden entre sí para formar un archivo o paquete procesado global para el equipo objetivo, por ejemplo, datos de actualización cifrados listos para ser enviados.
En la variante en la que los elementos seguros 35 comparten el procesamiento por bloque de un archivo, son los bloques procesados recibidos de todos estos elementos seguros 35 los que se añaden. Para ello, el controlador 32 asegura de guardar el mismo orden para la agregación que el utilizado para el corte del fichero inicial en bloques.
El envío 53, la recepción 54 y la adición 55 se repiten mientras queden comandos elementales no enviados en las interfaces SPI 33 (prueba 56).
Cuando se han procesado todos los comandos elementales, los datos añadidos (por ejemplo, ya sea un archivo procesado global, ya sean datos procesados por equipo objetivo) forman la respuesta al comando recibido inicialmente en la etapa 51. También, estos datos añadidos se devuelven al equipo anfitrión 20 como respuesta, durante la etapa 57.
Esto permite que el equipo anfitrión 20 obtenga eficientemente estos datos resultantes de procesamientos criptográficos seguros. Luego puede usarlos para transmitirlos al o a los equipos objetivo 10, 10', por ejemplo para enviar datos de actualización del sistema operativo OS eUICC remotos 10 que están cifrados con ayuda de una clave específica para cada uno de estos eUICC o para enviar un flujo multimedia (cifrado) al equipo objetivo 10'. Se trata en particular de las dos aplicaciones típicas evocadas anteriormente y descritas con más detalle ahora.
Volviendo a la figura 2, en la primera aplicación típica evocada, el módulo electrónico 22 se encarga de garantizar la gestión a distancia de una flota de elementos seguros que equipan los terminales móviles 10.
Sólo con fines ilustrativos, los elementos seguros 35 que componen el módulo electrónico 22 pueden ser del mismo tipo (o de los mismos tipos) que el (los) de los elementos seguros que equipan los terminales móviles 10 de la flota remota. La expresión “elementos seguros del mismo tipo” significa que estos elementos seguros cumplen con el mismo estándar de tarjeta. Por ejemplo, dos tarjetas SIM son del mismo tipo, mientras que una tarjeta SIM y una tarjeta eUICC son de tipos diferentes. Esto permite que la invención no requiera ninguna otra certificación que la ya prevista para los elementos seguros de la flota remota a gestionar.
Por supuesto, todos o parte de los elementos seguros 35 pueden ser de naturaleza diferente a la de los elementos seguros de la flota remota a gestionar. La flota remota puede igualmente no estar formada por elementos seguros, sino únicamente por equipos electrónicos clásicos.
En un modo particular, cada elemento seguro 35 del módulo 22 está emparejado con un elemento seguro de la flota remota de modo que el elemento seguro del módulo pueda generar una clave criptográfica a partir de una información secreta (por ejemplo una función de cifrado o una clave secreta) y de una información (número de identificación del elemento seguro) compartida con el elemento seguro emparejado o, alternativamente, puede detener dicha clave criptográfica compartida con el elemento seguro emparejado. Esto permite, en particular, garantizar un nivel de seguridad satisfactorio, teniendo que realizar menos operaciones para garantizar esta seguridad al nivel del terminal móvil y/o de la tarjeta.
Por ejemplo, los terminales móviles 10-1, 10-2, 10-3, 10-4 integran cada uno al menos un elemento seguro de un primer tipo (aquí, amovible, por ejemplo una tarjeta SIM) mientras que los terminales móviles 10-5, 10-6, 10-7, 10-8 integran cada uno al menos un elemento seguro de un segundo tipo, aquí integrado (por ejemplo, eUICC).
En un primer ejemplo, una parte de los elementos seguros 35 del módulo 22 son del primer tipo, mientras que otra parte de los elementos seguros 35 son del segundo tipo. Por ejemplo, los de un clúster son todos del primer tipo mientras que los de otro clúster son todos del segundo tipo, lo que simplifica la gestión para el controlador 32 del módulo 22.
En un segundo ejemplo, el HSM modular 20 comprende varios módulos 22, por ejemplo un módulo 22 con elementos seguros del primer tipo y otro módulo 22 con elementos seguros del segundo tipo.
Además, los elementos seguros 10 de la flota y los 35 del módulo 22 pueden tener previstas las mismas contramedidas en caso de ataque (por ejemplo electromagnético). Además pueden tener instaladas las mismas funciones criptográficas para cifrar/descifrar datos que intercambian, como por ejemplo las actualizaciones del sistema operativo OS.
Independientemente de los tipos de elementos seguros 35 con respecto a los de la flota remota, la primera aplicación típica se refiere al cifrado de datos en los clústeres 34 de elementos seguros 35, estando destinados estos datos a ser transmitidos a los elementos seguros 10 de la flota. Con este fin, el controlador 32 puede recibir, desde el terminal anfitrión, una instrucción/solicitud/comando para cargar nuevos datos en los elementos seguros de la flota. A continuación, estos datos deberán ser tratados, en particular cifrados, utilizando una clave específica para cada uno de los elementos seguros de la flota.
Por ello es por lo que la instrucción recibida se convierte en tareas criptográficas elementales destinadas a los elementos seguros, para procesar estos datos con ayuda de una clave específica, al nivel de cada elemento seguro 35.
Se trata, por tanto, de una situación en donde las tareas criptográficas elementales ejecutadas simultáneamente (al menos en parte) por los elementos seguros implementan la misma operación criptográfica elemental, un cifrado en el ejemplo, sobre datos con ayuda de una clave criptográfica específica de cada elemento seguro. Más precisamente, implica generar datos cifrados dedicados a una flota remota de elementos seguros, en cuyo caso los elementos seguros 35 del módulo electrónico 22 implementan cada uno una clave criptográfica, por ejemplo una clave de sesión, específica de un respectivo elemento seguro de la flota remota.
A título de ejemplo, se pueden así procesar dos tipos de datos para elementos seguros remotos.
El primer ejemplo típico se refiere a los datos de actualización del sistema operativo OS (o cualquier otra aplicación) de estos elementos seguros remotos (eventualmente todo un sistema operativo OS compilado). En este caso, los datos procesados simultáneamente por los elementos seguros del módulo electrónico son idénticos e incluyen datos de actualización de un sistema operativo OS (o cualquier otra aplicación) de los elementos seguros de la flota remota. Esto permite actualizar una flota completa de elementos seguros.
El segundo ejemplo típico se refiere a los datos de perfiles del abonado que un operador MNO desea cargar en las tarjetas SIM o UICC o eUICC de sus abonados. En este caso, los datos procesador simultáneamente por los elementos seguros del módulo electrónico incluyen datos de perfiles de telefonía móvil específicos de los respectivos elementos seguros de la flota remota. De hecho, el perfil a cargar (o actualizar) difiere de un abonado al otro. Esto permite cargar eficazmente perfiles eventualmente diferentes sobre un gran número de elementos seguros remotos.
Por supuesto, se pueden considerar otros ejemplos que requieren el procesamiento de datos para una pluralidad de equipos objetivo 10.
Cualquiera que sea el ejemplo, el proceso de procesamiento de datos según la invención es similar (véase la Figura 5).
A modo ilustrativo, se tiene interés en el cifrado (pero puede ser cualquier otra operación criptográfica) de un sistema operativo OS (pero podría ser cualquier otro tipo de datos), de un tamaño aproximado de 500 Ko basado en el algoritmo AES 256 y/o MAC.
En la práctica, el sistema operativo OS que se va a cifrar se corta en bloques (por ejemplo, de 240 octetos) y luego el controlador 32 envía una copia de cada bloque, bloque por bloque, a los elementos seguros 35 de uno o más clústeres 34 para que la totalidad o parte de estos elementos seguros cifren (bloque tras bloque) una copia del sistema operativo OS con una clave de cifrado específica, en particular la clave criptográfica (obtenida por diversificación) de un elemento seguro de la flota remota que le ha sido asignado (por ejemplo a través del emparejamiento evocado anteriormente).
Por este hecho, los elementos seguros 35 cifran en paralelo (con un ligero desfase como se muestra en la Figura 6) el mismo bloque recibido del controlador durante sustancialmente la misma duración T (véase la Figura 6), antes de pasar al siguiente bloque. El resultado es que todos los bloques del sistema operativo OS se cifran en última instancia para cada elemento seguro 10 de la flota para el cual se ha asignado un elemento seguro 35 de cifrado.
Los inventores han constatado que esta aplicación requiere alrededor de una cincuentena de elementos seguros 35 en el módulo 20 para permitir la actualización diaria del sistema operativo OS de una flota de 3,3 millones de elementos seguros.
Según modos de realización, cada elemento seguro 35 puede generar su propia clave de cifrado, correspondiente a la clave criptográfica del elemento seguro remoto con el que está emparejado. En particular, la clave de cifrado es calculada por el elemento seguro 35 a partir de una clave raíz o maestra común a todos los elementos seguros 35 del módulo 22 y de datos de diversificación que le envía el controlador. La generación de la clave de cifrado, eventualmente una clave de sesión, puede resultar en particular de una doble diversificación de la clave raíz, utilizando en primer lugar un identificador preferiblemente único del elemento seguro remoto al que se ha asignado el elemento seguro 35, y después con ayuda de un identificador de sesión. Eventualmente se pueden generar varias claves criptográficas según el protocolo y el canal seguro entre el servidor 20 y los elementos seguros de la flota remota.
En la segunda aplicación típica evocada, se trata para el módulo electrónico 22 de procesar un archivo grande, por ejemplo un flujo multimedia, intercambiado con un equipo objetivo 10'. Normalmente, el equipo objetivo 10' está dimensionado de manera similar al equipo anfitrión 20, de manera que incluye el mismo número de módulos electrónicos 22 o al menos suficientes módulos electrónicos 22 para poder procesar el archivo intercambiado. Por supuesto, también se puede implementar una asimetría de tamaño, por ejemplo, si el procesamiento criptográfico implementado en uno consume menos recursos criptográficos que el procesamiento criptográfico complementario implementado en el otro.
La utilización de módulos electrónicos 22 al nivel de dos equipos remotos (en este caso el dispositivo anfitrión 20 y el dispositivo remoto 10') pretende permitir el establecimiento de una comunicación altamente segura, capaz de ofrecer rendimientos elevados. Los dos módulos electrónicos 22 en los dos extremos de la comunicación son típicamente complementarios porque sus elementos seguros implementan tareas criptográficas elementales que son complementarias (es decir, recíprocas, tales como cifrado/descifrado, firma/verificación de firma, etc.).
Para hacer esto, las tareas criptográficas elementales ejecutadas simultáneamente (al menos en parte) por los elementos seguros de un clúster implementan la misma operación criptográfica elemental (cifrado o descifrado por ejemplo) sobre diferentes datos (cada bloque que compone el archivo a procesar) con ayuda de la misma clave criptográfica compartida por los elementos seguros. Esta clave es la misma al nivel de los dos equipos (algoritmo criptográfico simétrico) o está asociada a la utilizada en el otro equipo (clave privada-clave pública en el caso de un algoritmo criptográfico asimétrico).
De esta forma se paralelizan las operaciones criptográficas a realizar sobre el archivo. Esto da como resultado una alta velocidad de procesamiento y transmisión entre los dos equipos, para una solución económicamente atractiva (habida cuenta del bajo coste de un circuito FPGA y de elementos seguros tradicionales).
Los dos equipos pueden ser dos servidores en dos sitios que se comunican entre sí, o una clave USB (o equivalente) de un empleado que se comunica con un servidor de su empresa, o incluso un terminal móvil u objeto conectado en el campo que comunica con un servidor de un centro de datos.
A modo de ilustración, considérese una cámara IP que envía un flujo de video a 500 Kbits por segundo (kbps) a un servidor remoto a través de Internet. Se implementa un cifrado de bloques de 128 bits mediante el algoritmo AES. El período estimado T de cifrado de dicho bloque por un elemento seguro 35 es de aproximadamente 1 ms, lo que garantiza una velocidad de transmisión de 128 kbps por elemento seguro 35. Cuatro elementos seguros (500/128) parecen suficientes para realizar el procesamiento del vídeo en tiempo real (tanto al nivel de la cámara IP como al nivel del servidor remoto).
Así, se ve que para un sitio dotado de un gran número de cámaras IP de este tipo, basta con aumentar el número de elementos seguros para permitir un procesamiento (cifrado) y una transmisión en tiempo real. Por ejemplo, 80 elementos seguros conectados dentro de un módulo 22 permiten alcanzar un rendimiento de 10 Mbps. El coste de una solución técnica de este tipo sigue siendo bajo.
En esta segunda aplicación típica, los elementos seguros 35 del módulo electrónico 22 pueden contener cada uno una primera clave criptográfica KEY1 para procesar datos (archivo/flujo) intercambiados o a intercambiar con un primer equipo objetivo 10' y una o más segundas claves criptográficas. KEY2-KEYn para procesar datos (archivo/flujo) intercambiados o a intercambiar con uno o más segundos dispositivos objetivo 10' respectivamente.
Alternativamente, se pueden dedicar diferentes clústeres 34 (y por lo tanto diferentes bus SPI 36) al procesamiento de datos (archivo/flujo) intercambiados o para ser intercambiados con diferentes equipos objetivo 10'.
Asimismo, para mejorar el rendimiento de un módulo 22, se puede prever que todos los elementos seguros 35 de un clúster 34 estén configurados para implementar una misma operación criptográfica elemental utilizando informaciones diferentes (pero preferiblemente la misma clave criptográfica) y al menos dos clústeres están configurados para implementar dos operaciones criptográficas elementales diferentes. Por ejemplo, un clúster 34 (o un bus SPI 36 correspondiente) está dedicado a operaciones de cifrado y/u otro clúster a operaciones de descifrado y/u otro clúster a operaciones de firma (o verificación de firma) de mensajes y/u otro clúster a la operaciones de integridad de mensajes (cálculo o verificación). Los ejemplos anteriores son sólo modos de realización de la invención que no se limita a los mismos.
Claims (14)
1. Módulo electrónico (22), de tipo tarjeta electrónica, conectable a un dispositivo anfitrión (20), comprendiendo el módulo electrónico:
- un controlador (32) de módulo configurado para comunicar con el dispositivo anfitrión, y
- uno o más clústeres (34) de elementos seguros (35) conectados, dentro de un mismo clúster, a un bus común (36) que los conecta con el controlador (32) de módulo,
en donde el controlador (32) de módulo está configurado para convertir una operación criptográfica en una pluralidad de tareas criptográficas elementales similares usando informaciones diferentes y para controlar la ejecución de las tareas criptográficas elementales por los elementos seguros (35), y
en donde los elementos seguros (35) del módulo electrónico (22) están certificados como conformes con al menos una de las siguientes normas de seguridad: Federal Information Processing Standard (“Norma Federal para el procesamiento de información”) o "FIPS" 140-3/4, Criterios Comunes EAL4+ o versión 3.1 distribución 4, Minimum Energy Performance Standard (“Norma de Rendimiento Energético Mínimo”) o "MEPS", MEPS2, ISO/IEC19790:2012.
2. Módulo electrónico (22) según la reivindicación 1, en donde tareas criptográficas elementales ejecutadas simultáneamente por los elementos seguros (35) implementan la misma operación criptográfica elemental sobre los datos con ayuda de una clave criptográfica específica de cada elemento seguro.
3. Módulo electrónico (22) según la reivindicación 2, en donde la tarea criptográfica elemental comprende la generación de datos cifrados dedicados para una flota remota de elementos seguros (10), y cada uno de los elementos seguros (35) del módulo electrónico (22) implementa una clave criptográfica que es específica de un elemento seguro respectivo (10) de la flota remota.
4. Módulo electrónico (22) según la reivindicación 2 o 3, en donde los datos procesados simultáneamente por los elementos seguros (35) del módulo electrónico (22) son idénticos y comprenden datos de actualización de un sistema operativo de los elementos seguros (10) de la flota remota.
5. Módulo electrónico (22) según la reivindicación 2 o 3, en donde los datos procesados simultáneamente por los elementos seguros (35) del módulo electrónico (22) comprenden datos de perfiles de telefonía móvil que son específicos de los respectivos elementos seguros (10) de la flota remota.
6. Módulo electrónico (22) según la reivindicación 1, en donde tareas criptográficas elementales ejecutadas simultáneamente por los elementos seguros (35) de un clúster (34) implementan la misma operación criptográfica elemental sobre diferentes datos con ayuda de la misma clave criptográfica compartida por los elementos seguros.
7. Módulo electrónico (22) según la reivindicación 6, en donde los diferentes datos corresponden a diferentes partes del mismo flujo de datos.
8. Módulo electrónico (22) según una cualquiera de las reivindicaciones 1 a 7, en donde el controlador (32) de módulo está configurado para multiplexar por división en el tiempo, en el bus (36) del clúster (34), durante un intervalo de tiempo (T) correspondiente a un período estimado de ejecución de una tarea criptográfica elemental por un elemento seguro (35), comandos elementales con destino a elementos seguros (35) del clúster (34) para la ejecución al menos parcialmente simultánea de tareas criptográficas elementales por estos elementos seguros durante un período siguiente de ejecución.
9. Sistema que comprende dos dispositivos (20, 10') que se comunican entre sí, comprendiendo cada dispositivo un módulo electrónico (22) según la reivindicación 6 o 7, implementando los elementos seguros (35) de uno de los dos dispositivos tareas criptográficas elementales que son complementarias de las implementadas por los elementos seguros del otro dispositivo.
10. Sistema servidor (20) que comprende una unidad de procesamiento y una pluralidad de módulos electrónicos (22) según una cualquiera de las reivindicaciones 1 a 8 conectados a la unidad de procesamiento.
11. Procedimiento de procesamiento en un módulo electrónico (22), de tipo tarjeta electrónica, conectable a un dispositivo anfitrión (20) y que comprende un controlador (32) de módulo configurado para comunicar con el dispositivo anfitrión y uno o más clústeres (34) de elementos seguros (35) conectados, dentro de un mismo clúster, a un bus común (36) que los conecta al controlador de módulo, comprendiendo el procedimiento las siguientes etapas:
- convertir (52) el controlador de módulo una operación criptográfica en una pluralidad de tareas criptográficas elementales similares utilizando informaciones diferentes, y
- controlar (53) la ejecución de las tareas criptográficas elementales por los elementos seguros (35),
en el que los elementos seguros (35) del módulo electrónico (22) están certificados como conformes con al menos una de las siguientes normas de seguridad: Federal Information Processing Standard (“Norma Federal para el procesamiento de la información”) o "FIPS" 140-3/4, Criterios Comunes EAL4+ o versión 3.1 distribución 4, Minimum Energy Performance Standard (“Norma de Rendimiento Energético Mínimo”) o "MEPS", MEPS2, ISO/IEC19790:2012.
12. Procedimiento de procesamiento según la reivindicación 11, en el que las tareas criptográficas elementales ejecutadas simultáneamente por los elementos seguros (35) comprenden la generación de datos cifrados dedicados a una flota remota de elementos seguros (10) e implementan la misma operación criptográfica elemental sobre datos con la ayuda de una clave criptográfica específica para cada elemento seguro y apropiada para un elemento seguro respectivo (10) de la flota remota.
13. Procedimiento de procesamiento según la reivindicación 11, en el que las tareas criptográficas elementales ejecutadas simultáneamente por los elementos seguros (35) de un clúster (34) implementan la misma operación criptográfica elemental en diferentes porciones de un mismo flujo de datos, con la ayuda de una misma clave criptográfica compartida por los elementos seguros.
14. Soporte de informaciones legible por una unidad de procesamiento, y que comprende instrucciones de un programa informático que, cuando son ejecutadas por la unidad de procesamiento, implementan etapas del procedimiento según una cualquiera de las reivindicaciones 11 a 13.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1872297A FR3089377B1 (fr) | 2018-12-04 | 2018-12-04 | Module électronique connectable formé de grappes d’éléments sécurisés |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2962688T3 true ES2962688T3 (es) | 2024-03-20 |
Family
ID=66530147
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES19212398T Active ES2962688T3 (es) | 2018-12-04 | 2019-11-29 | Módulo electrónico conectable formado por clústeres de elementos asegurados |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3663945B1 (es) |
ES (1) | ES2962688T3 (es) |
FR (1) | FR3089377B1 (es) |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10073981B2 (en) * | 2015-10-09 | 2018-09-11 | Microsoft Technology Licensing, Llc | Controlling secure processing of confidential data in untrusted devices |
US10218696B2 (en) * | 2016-06-30 | 2019-02-26 | Microsoft Technology Licensing, Llc | Targeted secure software deployment |
US10069860B1 (en) * | 2017-02-14 | 2018-09-04 | International Business Machines Corporation | Protection for computing systems from revoked system updates |
-
2018
- 2018-12-04 FR FR1872297A patent/FR3089377B1/fr active Active
-
2019
- 2019-11-29 EP EP19212398.2A patent/EP3663945B1/fr active Active
- 2019-11-29 ES ES19212398T patent/ES2962688T3/es active Active
Also Published As
Publication number | Publication date |
---|---|
EP3663945B1 (fr) | 2023-08-09 |
FR3089377A1 (fr) | 2020-06-05 |
EP3663945C0 (fr) | 2023-08-09 |
FR3089377B1 (fr) | 2020-12-25 |
EP3663945A1 (fr) | 2020-06-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3171622B1 (en) | Method and device for installing profile of euicc | |
US20220131709A1 (en) | Mutually Authenticated ECDHE Key Exchange for a Device and a Network Using Multiple PKI Key Pairs | |
ES2925633T3 (es) | Aparato y procedimiento para la instalación de un perfil en el sistema de comunicación | |
US11101999B2 (en) | Two-way handshake for key establishment for secure communications | |
US10965453B2 (en) | System and method for authenticated encryption based on device fingerprint | |
ES2863324T3 (es) | Procedimiento para operar una red de automatización, red de automatización y producto de programa informático | |
CN104811444B (zh) | 一种安全的云端控制方法 | |
CN109274647B (zh) | 分布式可信内存交换方法及*** | |
CN110912686B (zh) | 一种安全通道的密钥的协商方法及*** | |
CN110169102A (zh) | 隐私保护的方法及设备 | |
WO2019025749A1 (en) | REMOTE CONTROL OF A COMPUTER DEVICE | |
CN106372516B (zh) | 一种基于M-PHY接口实现的加密Hub装置 | |
Urien | Introducing TLS/DTLS secure access modules for IoT frameworks: concepts and experiments | |
EP3281431B1 (en) | Uicc key provisioning | |
ES2962688T3 (es) | Módulo electrónico conectable formado por clústeres de elementos asegurados | |
CN102244649B (zh) | 一种安全网络间传输数据的方法和资料处理机 | |
CN106295372B (zh) | 一种基于EMMC接口实现的加密Hub装置 | |
CN113452514B (zh) | 密钥分发方法、装置和*** | |
Urien | An Innovative Four-Quarter IoT Secure Architecture Based on Secure Element | |
CN111125801A (zh) | 一种基于usb自动切换单向远程文件传输方法及装置 | |
CN106055989B (zh) | 一种数据传递方法及终端 | |
US11968187B2 (en) | Multi-independent level security for high performance computing and data storage systems | |
US20150142984A1 (en) | System and Method for Security over a Network | |
ES2530205T3 (es) | Sistema de almacenamiento de datos | |
CN114244506A (zh) | 一种量子密钥的快速同步的方法及*** |