ES2901207T3 - Interfaz de comunicación para una red de área extensa de baja potencia, dispositivo inalámbrico y servidor que usan tal interfaz de comunicación - Google Patents

Interfaz de comunicación para una red de área extensa de baja potencia, dispositivo inalámbrico y servidor que usan tal interfaz de comunicación Download PDF

Info

Publication number
ES2901207T3
ES2901207T3 ES17754193T ES17754193T ES2901207T3 ES 2901207 T3 ES2901207 T3 ES 2901207T3 ES 17754193 T ES17754193 T ES 17754193T ES 17754193 T ES17754193 T ES 17754193T ES 2901207 T3 ES2901207 T3 ES 2901207T3
Authority
ES
Spain
Prior art keywords
communication interface
cryptographic
key
encrypted
memory
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
Application number
ES17754193T
Other languages
English (en)
Inventor
Olivier Hersent
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Actility SA
Original Assignee
Actility SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Actility SA filed Critical Actility SA
Application granted granted Critical
Publication of ES2901207T3 publication Critical patent/ES2901207T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/3236—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 cryptographic hash functions
    • H04L9/3242—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 cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/11—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits using multiple parity bits
    • H03M13/1102—Codes on graphs and decoding on graphs, e.g. low-density parity check [LDPC] codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Una interfaz de comunicación (200) para soportar comunicación entre un dispositivo inalámbrico (101, 102, 103) y un servidor (121) a través de una red de área extensa de baja potencia, LPWAN, en donde la interfaz de comunicación (200) comprende: una parte de ejecución no confiable (201) configurada para operar de acuerdo con una pila de protocolos de comunicación de LPWAN (203) que incluye al menos un protocolo de LPWAN seguro usando primitivas criptográficas; una memoria (205) configurada para almacenar código informático encriptado (206) y al menos una clave criptográfica encriptada (207, 208, 209), en donde el código informático encriptado (206) y la al menos una clave criptográfica encriptada (207, 208, 209) se encriptan usando un secreto raíz; una parte de ejecución confiable (202), que incorpora el secreto raíz (210), configurada para desencriptar el código informático encriptado (206) y la al menos una clave criptográfica encriptada (207, 208, 209) de la memoria (205), en donde la parte de ejecución confiable (202) está configurada adicionalmente para ejecutar las primitivas criptográficas del al menos un protocolo de LPWAN seguro usando la al menos una clave criptográfica desencriptada y el código informático desencriptado de la memoria (205).

Description

DESCRIPCIÓN
Interfaz de comunicación para una red de área extensa de baja potencia, dispositivo inalámbrico y servidor que usan tal interfaz de comunicación
Sector de la técnica
La presente invención se refiere una comunicación inalámbrica y, más específicamente, a asegurar la comunicación entre un dispositivo inalámbrico y un servidor a través de una red de área extensa de baja potencia (LPWAN).
Estado de la técnica
Las Redes de Área Extensa de Baja Potencia (LPWAN) son redes inalámbricas de baja potencia que permiten las comunicaciones de largo alcance a una tasa de bits baja. Estas redes son particularmente adecuadas para aplicaciones de Máquina a Máquina (M2M) y de Internet de las Cosas (IoT), que se limitan en términos de memoria capacidad, potencia de cálculo y energía. Sigfox, LTE-NB1 ("Evolución a Largo Plazo - Máquina a Máquina, Banda Estrecha") o LoRaWAN ("Red de Área Extensa de Radio de Largo Alcance") son ejemplos de tales redes.
La Figura 1 describe la arquitectura de una LPWAN que, por medio de ilustración, puede ser del tipo de LoRaWAN. Una red LoRaWAN sigue una topología de estrella, en la que los mensajes entre dispositivos, llamados dispositivos de extremo, 101, 102, 103 y un servidor de red central 121 se transmiten y reciben a través de pasarelas 111, 112. El dispositivos de extremo 101, 102, 103 y las pasarelas 111, 112 se comunican de acuerdo con la tecnología de radio LoRa de tasa de bits baja, mientras las pasarelas y el servidor de red 121 normalmente se comunican usando tecnologías de red de retorno de tasa de bits más alta, tales como Ethernet o 4G, por ejemplo. El servidor de red, a continuación, se comunica con una pluralidad de servidores de aplicación 131, 132 desde los cuales los proveedores de aplicaciones explotan datos de los dispositivos de extremo 101, 102, 103, y pueden ordenar al servidor de red que envíe paquetes de enlace descendente a los dispositivos de extremo.
Para algunas aplicaciones, por ejemplo, en aplicaciones comerciales y de IoT industriales, tienen que desplegarse un gran número de dispositivos conectados equipados con sensores: podrían ser potencialmente decenas de miles de millones de sensores de comunicación a conectar a las redes en los próximos años. Estos sensores operan en baterías y transmiten diariamente cantidades muy pequeñas de datos a una tasa de bits baja a servidores. Las LPWAN son, por lo tanto, una buena solución para estas aplicaciones, que no necesitan una tasa de bits alta, y para estos dispositivos con recursos limitados, para los que se necesita una autonomía de varios años.
En LPWAN, la comunicación de IoT entre un dispositivo (también designado en este punto por "dispositivo de extremo") y su plataforma de procesamiento de datos habitualmente tiene lugar a través de una interfaz de frecuencia de radio (RF), abierta a una escucha clandestina. Esta comunicación necesita asegurarse para garantizar la confidencialidad así como integridad de los datos desde y hacia el dispositivo.
El estado actual de la técnica en comunicaciones seguras de IoT depende de un (o varios) secreto o secretos compartidos que se usa o usan, directamente o por medio de técnicas de derivación de clave, para encriptar y/o autenticar comunicaciones entre un dispositivo de extremo y un servidor de red.
En algunas implementaciones avanzadas, los secretos compartidos se usan por el aire y se calcula a partir de una clave criptográfica, en lo sucesivo denominada "clave de aplicación", conocida tanto por el dispositivo de extremo como el servidor de red, que nunca se comunica por el aire.
Por ejemplo, en la norma de LoRaWAN, activar un dispositivo de extremo en la red puede hacerse por el método de "activación por el aire" (OTAA). Para conseguir una OTAA, el dispositivo de extremo envía un mensaje y un criptograma calculado con su clave de aplicación (AppKey). El servidor comprueba si el dispositivo de extremo está autorizado para unirse a la red, sobre la base de esta AppKey, que se ha comunicado de antemano al servidor (durante el proceso de puesta en marcha de dispositivo). Si el dispositivo de extremo está autorizado, el servidor envía un mensaje de enlace descendente que incluye algunos datos criptográficos. A continuación, se derivan dos claves de sesión (una para funciones relacionadas con red tales como protección de integridad, la otra para encriptación de carga útil de usuario) en el dispositivo de extremo, basándose en los datos recibidos.
La limitación de la arquitectura de seguridad actual se vincula a la posibilidad de ataques físicos al dispositivo de extremo o al servidor. Algunas aplicaciones de seguridad alta pueden depender de la información generada por un sensor de IoT, y la posibilidad de desencadenamientos de datos falsos desde un sensor legítimo puede conducir a consecuencias importantes. Si un atacante accede a un servidor, se exponen las claves de aplicación de potencialmente millones de dispositivos.
Si un atacante puede acceder físicamente al sensor, el atacante será capaz de acceder físicamente a la memoria flash y RAM de dispositivo y, por lo tanto, acceder a la clave de aplicación que se usa para arrancar la seguridad de la comunicación. Un implementador puede elegir encriptar este secreto, pero tal encriptación dependerá del código, o secretos adicionales que también están presentes en la memoria, y el atacante, por lo tanto, siempre tiene suficiente información para revertir la estrategia de ofuscación y alcanzar el secreto de arranque.
Las limitaciones destacadas en las secciones anteriores se refieren a la accesibilidad física de la memoria usada para almacenar la clave de aplicación. En los últimos 20 años, se han desarrollado tecnologías para proporcionar protección física a una clave de aplicación, dentro de un módulo que implementa múltiples estrategias para hacer "imposible" recuperar una clave secreta. "Imposible" tiene que entenderse en el sentido de "no conseguible con medios que son proporcionales al beneficio potencial que puede obtenerse accediendo a la clave secreta".
Tales módulos de seguridad tienen que implementar métodos criptográficos estándar que dependen de la clave secreta, tal como operaciones de clave pública y clave secreta r Sa . El módulo físico que implementa un secreto protegido físicamente y código criptográfico y que proporciona una Interfaz de Programación de Aplicación (API) segura a un procesador externo se denomina un "Elemento Seguro" (SE).
Ejemplos y realizaciones de seguridad de datos de la técnica anterior pueden encontrarse en las siguientes referencias "STMicroelectronics, STSAFE-AI SX Authentication, data integrity and confidentiality for Sigfox Ready(TM) IoT devices Contents", "Murata, LoRa Module datos Sheet Sample CMWX1ZZABZ", "Lora Alliance, LoRaWAN Security -Frequently Asked Questions" y el documento US2016/036826.
Sin embargo, la utilización de Elementos Seguros en el contexto de seguridad de IoT tiene muchos inconvenientes. Por ejemplo:
- representan un coste significativo, que, relacionado al coste de RF y subsistema de microcontrolador usado habitualmente en un dispositivo de IoT, puede añadir un 50 % o más al coste del dispositivo;
- usan energía adicional, en un contexto en el que los dispositivos se optimizan en ocasiones para duración de la batería de 10 años o más;
- usan espacio de placa de circuito impreso adicional, mientras que la compacidad es importante;
- convencionalmente, pueden operar únicamente primitivas criptográficas estándar específicas, definidas durante la etapa de diseño. Como resultado las operaciones "no estándar" o cálculos intermedios basándose en información de secreto aún necesitan implementarse en un espacio no seguro y, por lo tanto, pueden exponer la información de secreto a través del bus de comunicación y RAM;
- implementan habitualmente únicamente las primitivas criptográficas generales estándar que se adaptan para el ordenador o mundo de almacenamiento seguro, pero no tienen en cuenta las limitaciones extremas en un enlace de comunicación de IoT: tecnologías de LPWAN, tal como LoRaWAN por ejemplo, se limitan a 50 bytes por enlace ascendente más o menos en el enlace descendente, y aceptan únicamente muy pocos mensajes de enlace ascendente o enlace descendente por día. La criptografía basada en certificado, o métodos de troceo, no son usables, por lo tanto, en su forma estándar. Por lo tanto, necesitarían desarrollarse SE especializados para cada tecnología de IoT, haciendo imposible diseñar dispositivos multiprotocolo y añadiendo al coste de diseño;
- no permiten mejoras sin añadir significativamente al coste de SE total. La capacidad de mejora es importante en el contexto de IoT, en el que pueden desplegarse millones de dispositivos durante las próximas décadas, y permanecer operacionales durante más de 10 años. El dispositivo de extremo debe ser adaptable a los avances en la tecnología de seguridad en este marco de tiempo.
Por lo tanto, existe una necesidad de soluciones alternativas para garantizar la seguridad de comunicación de IoT de LPWAN.
Objeto de la invención
La presente invención se define mediante las reivindicaciones independientes adjuntas 1, 15 y 23. Realizaciones se exponen en las reivindicaciones dependientes.
La invención se refiere a una interfaz de comunicación para soportar comunicación entre un dispositivo inalámbrico y un servidor a través de una LPWAN. La interfaz de comunicación comprende:
- una parte de ejecución no confiable configurada para operar de acuerdo con una pila de protocolos de comunicación de LPWAN que incluye al menos un protocolo de LPWAN seguro usando primitivas criptográficas; - una memoria para almacenar código informático y al menos una clave criptográfica en una forma encriptada; - una parte de ejecución confiable que incorpora un secreto raíz para desencriptar la al menos una clave criptográfica de la memoria, en donde la parte de ejecución confiable está configurada para ejecutar las primitivas criptográficas del al menos un protocolo de LPWAN seguro usando la clave criptográfica desencriptada y código informático de la memoria.
Esta interfaz de comunicación puede usarse en un dispositivo o un servidor (servidor de red o servidor de aplicación).
La parte de ejecución confiable puede implementar todas las operaciones que tienen que asegurarse (encriptación, desencriptación, ejecución de primitivas criptográficas...) mientras la parte de ejecución no confiable puede comunicarse con un dispositivo o servidor a través de un enlace no seguro. Por ejemplo, la parte de ejecución confiable encripta un mensaje y la parte de ejecución no confiable envía el mensaje encriptado a través de un enlace de comunicación estándar (no seguro).
Ventajosamente, la interfaz de comunicación comprende un chip de microcontrolador que incluye tanto la parte de ejecución no confiable como la parte de ejecución confiable
Por lo tanto, un único chip de semiconductor puede efectuar todas las funciones de seguridad y comunicación, que es particularmente deseable en el caso de dispositivos de extremo que potencialmente son muy numerosos y, por lo tanto, deben tener un coste de hardware bajo.
En una realización, la memoria tiene una sección de memoria reprogramable para almacenar código informático y una clave de aplicación criptográfica en una forma encriptada, y una sección de RAM o flash para almacenar, en una forma encriptada, al menos una clave de sesión criptográfica calculada por la parte de ejecución confiable como una función de la clave de aplicación criptográfica.
El uso de una sección de memoria reprogramable hace posible ventajosamente actualizar/mejorar una clave de aplicación o una porción del código almacenado en la memoria. Por lo tanto, la interfaz de comunicación de la presente invención garantiza la seguridad de comunicación de IoT de LPWAN mientras asegura menores costes y mejor evolución. Por ejemplo, el ingeniero/administrador a cargo de la fabricación de un objeto conectado puede cambiar la clave de aplicación de un dispositivo tanto en el servidor como en el dispositivo. Este administrador también puede cambiar una porción de código en la interfaz de comunicación del servidor, de modo que este cambio puede enviarse, a continuación, a un grupo de multidifusión de dispositivos.
Para implementar esta transmisión de multidifusión, la sección de memoria reprogramable puede proporcionarse adicionalmente para almacenar una clave de grupo criptográfica escrita en una forma encriptada por la parte de ejecución confiable en respuesta a un comando para unirse a un grupo de multidifusión de dispositivos inalámbricos.
En el contexto de una LPWAN que incluye protocolos de comunicación basándose en claves de aplicación y sesión (tal como LoRaWAN por ejemplo), la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable puede comprender encriptar elementos de información concatenados de un primer conjunto de elementos de información con una clave de aplicación desencriptada de la memoria para derivar una primera clave de sesión, en donde el primer conjunto de elementos de información incluye al menos un nonce.
Más específicamente, los elementos de información concatenados del primer conjunto pueden incluir un primer nonce generado por el servidor, un identificador de la LPWAN y un segundo nonce generado por el dispositivo inalámbrico.
En este contexto, la parte de ejecución confiable puede configurarse para calcular el material de derivación de clave enviada por el aire durante la toma de contacto de derivación de clave y, a continuación, encriptar la primera clave de sesión con el secreto raíz y escribir la primera clave de sesión encriptada en una sección de RAM o flash de la memoria.
La ejecución de una de las primitivas criptográficas por la parte de ejecución confiable puede comprender encriptar un mensaje proporcionado por la parte de ejecución no confiable usando la primera clave de sesión. El procedimiento de encriptación es específico al protocolo de LPWAN, habitualmente no disponible en un Elemento Seguro estándar: se ejecuta por la parte segura de la interfaz de comunicación a partir de código encriptado de implementación del procedimiento de encriptación específico, siendo dicho código encriptado comprobado en integridad y desencriptado usando el secreto de raíz de subsistema seguro.
La ejecución de una de las primitivas criptográficas por la parte de ejecución confiable también puede comprender encriptar elementos de información concatenados de un segundo conjunto de elementos de información con la clave de aplicación desencriptada de la memoria para derivar una segunda clave de sesión, en donde el segundo conjunto de elementos de información incluye al menos un nonce.
Los elementos de información concatenados de este segundo conjunto pueden incluir un primer nonce generado por el dispositivo inalámbrico, un identificador de la LPWAN y un segundo nonce generado por el servidor.
La parte de ejecución confiable puede configurarse para encriptar la segunda clave de sesión con el secreto raíz y escribir la segunda clave de sesión encriptada en una sección de RAM o flash de la memoria.
Cuando se deriva una segunda clave de sesión, la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable puede comprender calcular un valor de comprobación de integridad de mensaje (MIC) basándose en un mensaje encriptado usando la segunda clave de sesión. La MIC puede calcularse adicionalmente basándose en elementos concatenados, incluyendo una dirección del dispositivo inalámbrico.
Este valor de MIC puede incluirse en una carga útil para un mensaje de enlace ascendente o enlace descendente enviado a través de la LPWAN.
Un valor de MIC también puede calcularse:
- basándose en elementos concatenados, incluyendo un nonce generado por el dispositivo inalámbrico, un identificador del dispositivo y un identificador de un proveedor de aplicaciones, usando una clave de aplicación desencriptada de la memoria; y/o
- basándose en elementos concatenados, incluyendo un identificador de la LPWAN y una dirección del dispositivo inalámbrico, usando una clave de aplicación desencriptada de la memoria.
Tales valores de MIC pueden incluirse en una carga útil para un mensaje de "petición de unión" (desde el dispositivo de extremo al servidor de red) y para un mensaje de "aceptación de unión" (desde el servidor de red al dispositivo de extremo), respectivamente, en el caso de una OTAA en la LPWAN.
Otro aspecto de la invención se refiere a un dispositivo inalámbrico que tiene una interfaz de comunicación como se ha descrito anteriormente para comunicarse con un servidor a través de una LPWAN.
La parte de ejecución confiable de la interfaz de comunicación del dispositivo puede configurarse para cambiar al menos una clave criptográfica almacenada en una forma encriptada en la memoria de la interfaz de comunicación en respuesta a un comando de actualización de clave recibido a través de la LPWAN. El cambio de la clave criptográfica puede realizarse por la parte de ejecución confiable usando una clave de actualización almacenada en una forma encriptada.
Por lo tanto, si una clave criptográfica se ha visto comprometida, puede cambiarse fácilmente y de una forma segura. La parte de ejecución confiable de la interfaz de comunicación puede configurarse para cambiar una porción del código informático almacenado en la memoria en respuesta a un comando de mejora de código recibido a través de la LPWAN. El comando de mejora de código puede recibirse en una dirección de multidifusión de la LPWAN en al menos un mensaje encriptado que se desencripta por la parte de ejecución confiable usando una clave de grupo criptográfica almacenada en una forma encriptada en la memoria.
Por lo tanto, es posible mejorar de forma segura y fácil un código almacenado en memoria (por ejemplo, primitivas criptográficas de arranque, o algoritmos de derivación de clave de corto plazo de grupo de multidifusión) de todos los dispositivos de un grupo.
En este contexto de mejora de código, la interfaz de comunicación puede configurarse para aplicar decodificación por redundancia al al menos un mensaje encriptado para obtener una porción de código mejorada para cambiar la porción del código informático almacenado en la memoria.
Cuando un mensaje de mejora se envía desde un servidor a un dispositivo, puede suceder una pérdida de paquetes. Añadir redundancia en la información transmitida (aplicando codificación/decodificación por redundancia en el lado de servidor/dispositivo, respectivamente) permite que el dispositivo compense una pérdida de información.
Por ejemplo, la decodificación por redundancia puede comprender una decodificación de comprobación de paridad de baja densidad (LDPC).
Adicionalmente, la parte de ejecución confiable puede configurarse para calcular un código de troceo basándose en una clave criptográfica almacenada en una forma encriptada en la memoria y una porción de código mejorada recibida como parte del comando de mejora de código, y la interfaz de comunicación puede configurarse para transmitir el código de troceo a un servidor de verificación y para recibir una respuesta desde el servidor de verificación para validar si tiene que cambiarse la porción del código informático.
Esto habilita ventajosamente comprobar la autenticidad del mensaje recibido en el contexto de una mejora de código. Otro aspecto más de la invención se refiere a un servidor que tiene una interfaz de comunicación como se ha descrito anteriormente para comunicarse con una pluralidad de dispositivos inalámbricos a través de una LPWAN.
La memoria de la interfaz de comunicación puede almacenar una pluralidad de claves de aplicación criptográficas en una forma encriptada, siendo cada clave de aplicación criptográfica para un respectivo dispositivo inalámbrico de la LPWAN.
Para cambiar la clave de aplicación criptográfica para uno de la pluralidad de dispositivos inalámbricos, la interfaz de comunicación puede configurarse para transmitir un comando de actualización de clave al uno de los dispositivos inalámbricos a través de la LPWAN, a través de una dirección de unidifusión del uno de la pluralidad de dispositivos inalámbricos, y la parte de ejecución confiable de la interfaz de comunicación puede configurarse para cambiar la clave criptográfica almacenada en una forma encriptada en la memoria de la interfaz de comunicación para el uno de la pluralidad de dispositivos inalámbricos.
Para cambiar una porción de código informático usada por un grupo de dispositivos inalámbricos, la interfaz de comunicación puede configurarse para transmitir un comando de mejora de código a través de la LPWAN, a través de una dirección de multidifusión de la LPWAN. La parte de ejecución confiable de la interfaz de comunicación puede configurarse para encriptar el comando de mejora de código con una clave de grupo criptográfica asociada con la dirección de multidifusión de la LPWAN antes de la transmisión a través de la dirección de multidifusión.
Como se ha mencionado anteriormente, el comando de mejora de código encriptado puede codificarse por redundancia y, a continuación, se divide en una pluralidad de fragmentos transmitidos en respectivos mensajes a la dirección de multidifusión de la LPWAN. En una realización particular, el comando de mejora de código encriptado puede codificarse por redundancia usando codificación de LDPC.
Finalmente, una comprobación de autenticidad del mensaje puede realizarse como se indica a continuación:
- la interfaz de comunicación recibe un primer código de troceo desde uno del grupo de dispositivos inalámbricos, - la parte de ejecución confiable calcula un segundo código de troceo basándose en una clave criptográfica almacenada en una forma encriptada en la memoria para el uno del grupo de dispositivos inalámbricos y una porción de código mejorada que hay que sustituir para la porción de código informático usada por el grupo de dispositivos inalámbricos,
- la interfaz de comunicación compara el primer y segundo códigos de troceo y para enviar una respuesta al uno del grupo de dispositivos inalámbricos dependiendo de si el primer y segundo códigos de troceo son idénticos o no. Otras características y ventajas del método y aparatos divulgados en este documento serán evidente a partir de la siguiente descripción de realizaciones no limitantes, con referencia a los dibujos adjuntos.
Descripción de las figuras
La presente invención se ilustra a modo de ejemplo, y no por medio de limitación, en las figuras de los dibujos adjuntos, en los que números de referencia similares hacen referencia a elementos similares en los que:
- La Figura 1 es una representación de una arquitectura de red LoRaWAN a la que puede aplicarse la invención; - La Figura 2 es un diagrama de bloques de una interfaz de comunicación, en una posible realización de la presente invención;
- La Figura 3 es un diagrama de flujo que ilustra las diferentes etapas de una actualización de clave criptográfica, en una posible realización de la presente invención;
- La Figura 4a es un diagrama de flujo que ilustra las diferentes etapas de una mejora de código criptográfico en el lado de servidor, en una posible realización de la presente invención;
- La Figura 4b es un diagrama de flujo que ilustra las diferentes etapas de una mejora de código criptográfico en el lado de dispositivo, en una posible realización de la presente invención.
Descripción detallada de la invención
Expresiones tales como "comprender", "incluir", "incorporar", "contener", "ser", "estar" y "tener" se interpretarán de una manera no exclusiva cuando se interpreta la descripción y sus reivindicaciones asociadas, en concreto se interpretarán para permitir que otros artículos o componentes que no se definen explícitamente también estén presentes. La referencia al singular también se interpretará como una referencia al plural y viceversa.
Un experto en la materia apreciará fácilmente que diversos parámetros divulgados en la descripción pueden modificarse y que diversas realizaciones divulgadas pueden combinarse sin alejarse del alcance de la invención. La Figura 2 es un diagrama de bloques de una interfaz de comunicación en una posible realización de la presente invención.
Esta interfaz de comunicación 200 puede incluirse en un dispositivo (o dispositivo de extremo) o en un servidor (servidor de red o servidor de aplicación).
De acuerdo con la Figura 2, la interfaz de comunicación 200 contiene al menos una parte de ejecución no confiable 201, una parte de ejecución confiable 202 y una memoria 205.
Por "parte de ejecución confiable" se entiende una parte de un procesador o microprocesador que está asegurado, y que garantiza que el código informático y datos en ejecución o cargados dentro están protegidos en términos de confidencialidad e integridad. Por otra parte, "parte de ejecución no confiable" se refiere a una parte de un procesador que no garantiza esta protección de código informático o datos.
En una realización preferida, las partes de ejecución confiable y no confiable se incluyen ambas en un único chip de microcontrolador 212. A modo de ejemplo y sin limitación, el microcontrolador puede ser un procesador comercializado por la empresa ARM y equipado con la tecnología de seguridad "Trustzone®", que está programada en el hardware. Este tipo de procesador puede ejecutar un sistema operativo seguro y un sistema operativo no seguro (o "normal") al mismo tiempo desde un único núcleo.
En la realización particular representada en la Figura 2, la parte de ejecución no confiable 201 gestiona la capa de aplicación 204, que contiene aplicaciones funcionales en las que se implementan el comportamiento y funcionalidades de dispositivo. También puede implementar los controladores para gestionar las unidades periféricas de dispositivo. Puede implementar además las librerías de protocolo de comunicación 203 para comunicarse con el equipo 213 (que puede ser un servidor si la interfaz de comunicación 200 es parte de un dispositivo de extremo, o un dispositivo de extremo es la interfaz de comunicación 200 es parte de un servidor), de acuerdo con una pila de protocolos de comunicación de LPWAN, tal como LoRaWAN, por ejemplo.
La parte de ejecución confiable puede ejecutar funciones de seguridad de LPWAN 211, tales como funciones de encriptación, desencriptación o verificación de integridad. También incorpora un secreto raíz 210, que es un secreto relacionado con el componente, específico al microprocesador y distinto de la "clave de aplicación" usada para arrancar una comunicación a través de la LPWAN. El secreto raíz 210 habilita encriptar y desencriptar información que hay que almacenar en o leer de la memoria en el microprocesador. Se incorpora en el microprocesador durante la fabricación de factoría, y se hace disponible por el fabricante al usuario/ingeniero/administrador a cargo del despliegue de los dispositivos de extremo, de modo que este usuario/ingeniero/administrador es capaz de escribir código informático en la memoria.
La memoria 205 puede almacenar datos no encriptados (es decir, datos almacenados de una forma "normal" no encriptada) y datos encriptados (es decir, datos almacenados en una forma encriptada), incluyendo al menos una clave criptográfica AppKey en un área de memoria 207 y código informático en un área de memoria 206.
La memoria también puede almacenar, en una forma encriptada, claves de sesión criptográficas AppSKey, NwkSKey, derivadas a partir de algoritmos incluidos en el código informático 206 que pueden cargarse y ejecutarse en la parte de ejecución confiable 202.
Los nombres de clave criptográfica tales como AppKey, AppSKey o NwkSKey se mencionan en este punto con referencia a los protocolos de LoRa por medio de ilustración. Se apreciará que otros nombres pueden estar en uso en otros tipos de LPWAN sin cambiar las características técnicas analizadas a continuación.
Puede obtenerse más información sobre el ejemplo ilustrativo de redes LoRaWAN de la "Especificación de LoRa", o "Especificación de LoRaWAN", Versión V1.0, escrita por N. Sornin, M. Luis, T. Eirich, T. Kramp y O. Hersent y publicada por LoRa Alliance, Inc., enero de 2015.
Como se muestra en la realización ilustrativa de la Figura 2, la memoria 205 incluye una sección de memoria reprogramable 205a y una sección de RAM o flash 205b.
La sección de memoria reprogramable 205a puede almacenar, por ejemplo, el código informático en el área 206 y la clave criptográfica AppKey en el área 207. Estas son piezas de información semi permanentes que un dispositivo de extremo debe mantener incluso en su reposo. Pueden actualizarse, pero principalmente sobre una base a largo plazo. Por lo tanto, la sección de memoria reprogramable 205a puede hacerse habitualmente como una sección de memoria flash. El ingeniero a cargo de la gestión de los dispositivos de extremo puede modificar todo o parte del código en el área de memoria 206, así como la AppKey en área de memoria 207. Esto habilita actualizar algoritmos criptográficos, que pueden ser complejos en el contexto de redes de loT como se analiza adicionalmente a continuación, y para cambiar la AppKey, por ejemplo, si se ha visto comprometida.
Por otra parte, las claves de sesión almacenadas en las áreas 208, 209 se cambian cada vez que se establece una nueva sesión de comunicación. Únicamente necesitan almacenamiento a corto alcance que puede conseguirse con una sección de RAM 205b. Como alternativa, también puede usarse una sección de memoria flash.
Las AppKey almacenadas en el área de memoria 207 son claves de aplicación usadas para arrancar un protocolo de comunicación inalámbrica seguro, y el código informático almacenado en el área de memoria 206 incluye primitivas criptográficas del protocolo de comunicación.
En el caso de una interfaz de comunicación en un dispositivo de extremo, la clave de aplicación AppKey es una clave asociada específicamente al dispositivo de extremo. En el caso de una interfaz de comunicación en un servidor de red, la memoria almacena una pluralidad de claves de aplicación, estando cada clave de aplicación asociada a un dispositivo de extremo que pertenece a la red. Debido a la gran cantidad de claves que hay que almacenar en el lado del servidor, esta pluralidad de claves de aplicación pueden almacenarse como alternativa en una forma encriptada en un disco duro separado físicamente de otras secciones de memoria.
En esta realización, para establecer una comunicación entre un dispositivo que incluye la interfaz de comunicación 200 y el equipo 213 de acuerdo con un protocolo de comunicación inalámbrica, se ejecuta una función de desencriptación 211 para desencriptar la AppKey usando el secreto raíz 210. A continuación, se ejecutan primitivas criptográficas basándose en la clave de aplicación desencriptada, para derivar, por ejemplo, una o más claves de sesión criptográficas tales como la AppSKey y la NwkSKey anteriormente mencionadas.
Los siguientes ejemplos se desarrollan en el caso de protocolos de comunicación de LoRa, pero tiene que entenderse que la presente invención no se limita a esos, y puede usarse para cualquier tipo de LPWAN que incluye el uso de primitivas criptográficas.
En el caso de protocolos de comunicación de LoRa:
- la memoria 205 de la interfaz de comunicación 200 del dispositivo de extremo contiene el identificador de dispositivo (DevEUI), el identificador de proveedor de aplicaciones (AppEUI) y la clave de aplicación encriptada (AppKey) -habitualmente, la AppKey puede encriptarse mediante la Norma de Encriptación Avanzada (AES)-128; y - la memoria 205 de la interfaz de comunicación 200 del servidor de red contiene las AppKey de todos los dispositivos relacionados con el servidor.
El método de activación por el aire (OTAA) para que un dispositivo de extremo se una a la red consiste en las siguientes etapas:
- el dispositivo de extremo envía al servidor de red un mensaje de "petición de unión" que contiene el AppEUI y el DevEUI del dispositivo de extremo seguido por un nonce DevNonce elegido por el dispositivo de extremo. También se transmite un Código de Integridad de Mensaje (MIC) al servidor. Por ejemplo, el MIC se calcula como los cuatro octetos menos significativos de 'cmac' usando la siguiente primitiva criptográfica:
cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce),
MIC = cmac[0..3],
donde MHDR designa el encabezamiento de una capa de protocolo de control de acceso al medio (MAC) usada en la LPWAN en el mensaje de "petición de unión", y x 11 x2 |...| xn representa la operación de concatenación aplicada a un número n de elementos de información x 1, x2 ,..., xn.
Tal función criptográfica es típica de las funciones de seguridad no estándar requeridas por la naturaleza de las LPWAN que no están disponibles desde un elemento seguro multipropósito estándar;
- el servidor comprueba el MIC recibido a través de la AppKey y determina si el dispositivo está autorizado;
- si el dispositivo está autorizado por el servidor, el servidor envía un mensaje de "aceptación de unión" al dispositivo.
Este mensaje de aceptación de unión contiene un nonce AppNonce elegido por la capa de aplicación en el servidor de red, un identificador de red (NetID), una dirección de dispositivo de extremo (DevAddr), un retardo entre transmisión y recepción (RxDelay) y una lista opcional de frecuencias de canal (CFList) para la red a la que se une el dispositivo de extremo. El valor de MIC para el mensaje de aceptación de unión puede calcularse como se indica a continuación:
cmac = aes128_cmac(AppKey,
MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList)
MIC = cmac[0..3],
donde DLSettings es un byte de información de configuración de enlace descendente de la capa MAC.
En el dispositivo de extremo 200, después de recibir el mensaje de aceptación de unión, pueden derivarse dos claves de sesión, AppSKey y NwkSKey, a partir de primitivas criptográficas ejecutadas en la parte de ejecución confiable 202 de la interfaz de comunicación del dispositivo de extremo.
Estas dos claves de sesión, que son específicas para el dispositivo de extremo, se calculan dinámicamente tanto por el dispositivo como el servidor, y se renuevan en cada nueva sesión. Son necesarias para transmitir posteriormente datos desde el dispositivo al servidor. Más específicamente, la NwkSKey, que en algunas versiones de la norma de LoRaWAN puede calcularse de forma separada en la dirección de enlace descendente y enlace ascendente, se usa tanto por el servidor de red (121 en la Figura 1) como el dispositivo de extremo para calcular y verificar el MIC de todos los mensajes de datos para garantizar la integridad de datos. Se usa adicionalmente para encriptar y desencriptar el campo de carga útil de mensajes de datos de solo MAC. La AppSKey se usa tanto por el servidor de aplicación (131 o 132 en la Figura 1) como el dispositivo de extremo para encriptar y desencriptar el campo de carga útil de mensajes de datos específicos de la aplicación. También se usa para calcular y verificar una MIC a nivel de aplicación que puede incluirse en la carga útil de mensajes de datos específicos de la aplicación.
En el caso de una OTAA en un protocolo de comunicación de LoRa de LPWAN, las dos claves de sesión se derivan como se indica a continuación:
- después de la recepción del mensaje de aceptación de unión desde el servidor de red, el dispositivo de extremo (101 en la Figura 1) está en posesión de un número de elementos de información que incluyen el AppNonce (un valor aleatorio o alguna forma de ID único proporcionado por el servidor de red), el DevNonce (generado por el dispositivo de extremo 101) y el ID de red NetID;
- a continuación, las primitivas criptográficas pueden ejecutarse en la parte de ejecución confiable (202 en la Figura 2) usando la AppKey desencriptada y elementos de información concatenados que incluyen AppNonce, DevNonce y NetId, para derivar la AppSKey y la NwkSKey, que se encriptan con el secreto raíz y almacenan en la forma encriptada en la memoria (205 en la Figura 2).
Habitualmente, de acuerdo con la especificación de LoRaWAN 1.0, las claves de sesión se derivan como se indica a continuación:
NwkSKey = aes128_encrypt(AppKey,
0x01 | AppNonce | NetID | DevNonce | pad16)
AppSKey = aes128_encrypt(AppKey,
0x02 | AppNonce | NetID | DevNonce | pad16)
Otras versiones de la especificación de LoRaWAN calculan varias claves de sesión de red, por ejemplo, en la dirección de enlace ascendente y enlace descendente, y para redes visitadas en una situación de itinerancia. También el código MIC puede dividirse en dos partes para la verificación de redes domésticas y visitadas. Todos estos cambios pueden implementarse como evoluciones directas de la realización ilustrada para la versión 1.0 de LoRaWAN.
Con la interfaz de comunicación de la presente invención, la derivación de NwkSKey, AppSKey y MIC consiste en una sucesión de operaciones que se ejecutan en su totalidad en un espacio seguro, usando las primitivas criptográficas de LPWAN como una Interfaz de Programación de Aplicación (API) entre la parte de ejecución no confiable de microcontrolador (que puede ejecutar código de aplicación estándar y la mayoría de pila de protocolos de LPWAN), y la parte de ejecución confiable. Por lo tanto, los algoritmos criptográficos de LPWAN que se requieren para exponer material criptográfico al entorno no seguro que ejecuta la pila de protocolos se implementan en la parte de ejecución confiable. Residen encriptados en memoria, y están disponibles a la parte confiable únicamente en tiempo de ejecución, inaccesible desde cualquier atacante.
Una vez que el dispositivo de extremo se activa en la red, pueden intercambiarse mensajes de datos entre el dispositivo de extremo y el servidor. En los protocolos de comunicación de LoRa, un mensaje (en enlace ascendente o enlace descendente) transporta una carga útil PHY que incluye un encabezamiento de mAc (MHDR), una carga útil de MAC y un código de integridad de mensaje (MIC). La carga útil de MAC contiene un encabezamiento de trama (FHDR), un campo de puerto opcional (FPort) y un campo de carga útil de trama opcional (FRMPayload). El mensaje, por lo tanto, puede escribirse: msg = MHDR | FHDR | FPort | FRMPayload.
Si una trama de datos transporta carga útil, FRMPayload debe encriptarse antes de que se calcula el código de integridad de mensaje (MIC). La encriptación se basa en una clave criptográfica que es la NwkSKey o la AppSKey, dependiendo del valor del FPort del mensaje de datos. Más específicamente, se usa la NwkSKey si FPort = 0, y se usa la AppSKey si FPort = 1...255.
Finalmente, el valor de MIC puede calcularse a través de todos los campos en el mensaje de un mensaje encriptado usando la NwkSKey como se indica a continuación:
cmac = aes128_cmac(NwkSKey, B0 | msg)
MIC = cmac[0..3]
donde Bo es un bloque que incluye, en particular, la dirección de dispositivo (DevAddr).
La Figura 3 es un diagrama de flujo que ilustra las diferentes etapas de una actualización de clave criptográfica, en una posible realización de la presente invención.
En algunas situaciones, puede necesitarse una actualización de una clave criptográfica, por ejemplo, la clave de aplicación AppKey, de un dispositivo (por ejemplo, cuando el subsistema de controlador de red central de IoT se ha pirateado y la AppKey se ve comprometida).
Desde los datos de actualización de clave 301, el servidor 121 envía (etapa 303) un comando de actualización de clave al dispositivo de extremo 101, a través de la dirección de unidifusión del dispositivo de extremo 101. En paralelo, se almacena (302) la nueva clave en una forma encriptada en la memoria de la interfaz de comunicación del servidor 121, en lugar de la clave antigua (que significa que la lista de claves de aplicación en relación con el conjunto de dispositivos conectados al servidor se actualiza con la nueva clave de aplicación del dispositivo de extremo 101).
A continuación, el dispositivo de extremo 101 recibe el comando de actualización de clave y la parte de ejecución confiable del dispositivo de extremo procede con el cambio (etapa 304) de la clave de aplicación.
La encriptación de la clave nueva se hace desde una "clave de actualización" especializada 305 que se ha almacenado por adelantado (por ejemplo, durante la fabricación) en el dispositivo de extremo 101 para este propósito. Como alternativa, el cambio puede hacerse usando una primitiva criptográfica específica ("primitiva de clave de actualización"), almacenada en la memoria de la interfaz de comunicación del dispositivo de extremo 101, desde la cual la parte de ejecución confiable puede encriptar la clave nueva (306) a partir de la clave anterior.
Por supuesto, la encriptación en el lado de servidor también puede realizarse a través de una "clave de actualización" almacenada en la memoria de interfaz de comunicación del servidor.
Las Figuras 4a y 4b son diagramas de flujo que ilustran las diferentes etapas de una mejora de código criptográfico, en una posible realización de la presente invención.
IoT es un campo muy innovador, que significa que pueden añadirse evoluciones de los protocolos con el paso del tiempo, así como mejoras y correcciones a las características de seguridad de los protocolos.
Un ejemplo de una mejora de seguridad se refiere a los algoritmos criptográficos que se almacenan en la sección reprogramable de la memoria de una pieza de equipo (dispositivo de extremo o servidor). Mientras que tal mejora es una aplicación clásica en el contexto tradicional de microcontroladores, no es directa en el contexto de las redes de IoT, en las que las primitivas de comunicación se limitan a un tamaño de carga útil muy pequeño (habitualmente 50 bytes en el caso de LoRaWAN), y se someten a una limitación de ciclo de trabajo (habitualmente un 1 % del tiempo de comunicación, compartido en enlace descendente entre todos los dispositivos en una célula de RF dada).
Como consecuencia, para permitir la capacidad de mejora en el contexto de enlaces de comunicación de IoT, se requiere:
- transmitir de forma eficiente el código mejorado simultáneamente a múltiples dispositivos, mientras se minimiza el tiempo de comunicación de célula de RF; y
- minimizar la cantidad de datos enviados por el aire para un cambio de código dado.
La presente invención permite tales mejoras de código, que cumplen con estos requisitos.
Para evoluciones de código y algoritmo, que no necesitan ser secretas, sino únicamente autenticarse, es posible transmitir únicamente los cambios en el código compilado. Al contrario de la práctica común de transmisión de todo el código binario recompilado al dispositivo, únicamente puede transmitirse la diferencia entre el código binario mejorado y el código original. Esto puede hacerse usando disciplina de compilación en la que todas las subfunciones de un código se vinculan en compensaciones predefinidas, de modo que un cambio en un bloque funcional no afecta a punteros en otros bloques. Por lo tanto, se usa un "parche" de código muy pequeño, que es compatible con las restricciones de comunicación de IoT.
Por lo tanto, con referencia a la Figura 4a que describe un proceso de una mejora de código de lado de servidor, la diferencia entre la secuencia de código mejorada completa y la secuencia de código original completa puede calcularse durante una primera etapa 401. El resultado de esta etapa es, a continuación, un comando de mejora de código que incluye un conjunto de secuencias de código que comprende únicamente las partes de código que tienen que mejorarse.
En la etapa 402, el comando de mejora de código puede encriptarse por la parte de ejecución confiable del servidor. Para la encriptación, es posible usar una clave de multidifusión (o clave de grupo): cuando un dispositivo inalámbrico envía un comando para unirse a un grupo de multidifusión de dispositivos inalámbricos, se envía al dispositivo una "clave de grupo" criptográfica, específica al grupo de multidifusión de dispositivos inalámbricos. Esta clave de grupo criptográfica puede encriptarse por la parte de ejecución confiable con el secreto raíz del microprocesador y almacenarse en la sección reprogramable de la memoria. Cada dispositivo del grupo de dispositivos inalámbricos, así como el servidor de red, tiene la clave de grupo encriptada almacenada en la sección de memoria reprogramable de su interfaz de comunicación. La clave de grupo puede usarse directamente, o indirectamente por medio de derivación de clave, por ejemplo, derivando una clave de desencriptado de carga útil de paquete de multidifusión basándose en el troceo de clave de grupo y contador de paquete de enlace ascendente de LoRaWAN del paquete decodificado.
Ya que cada dispositivo del grupo de multidifusión puede experimentar una pérdida de paquete aleatoria por diferentes razones, en la etapa 403 puede añadirse opcionalmente información redundante. Por lo tanto, un dispositivo de recepción puede compensar una gran pérdida de información. En una realización específica, esto puede conseguirse usando códigos de Comprobación de Paridad de Baja Densidad (LDPC), que están bien adaptados para aplicaciones que requieren una transferencia de información fiable y eficiente. La corrección de errores en recepción usando códigos de LDPC es bien conocida en la técnica. Véase, por ejemplo Gallager, R. G., "Low Density Parity Check Codes", Monografía, M.I.T. Press, 1963.
El comando de mejora de código puede dividirse, a continuación, en una pluralidad de fragmentos durante una etapa 404, de modo que cada fragmento puede transmitirse (etapa 405) en un mensaje a la dirección de multidifusión del grupo de dispositivos que necesitan mejorarse.
Haciendo referencia ahora a la Figura 4b, los fragmentos encriptados se reciben a continuación (etapa 406) por un dispositivo de extremo del grupo de dispositivos, y se desencriptan por la parte de ejecución confiable del dispositivo con la clave de grupo criptográfica. A continuación, una decodificación por redundancia, que corresponde al algoritmo elegido para la codificación por redundancia en el lado de servidor, puede aplicarse opcionalmente a la pluralidad de fragmentos (etapa 407). Los fragmentos se recomponen, a continuación, (etapa 408) para obtener la porción de código mejorada que tiene que cambiarse en el código informático almacenado en la memoria del dispositivo de extremo. A continuación, la porción de código a mejorar puede sustituirse por la correspondiente porción de código mejorada, y puede recuperarse la secuencia de código mejorada completa (etapa 409).
Para comprobar la autenticidad (etapa 410) de los datos recibidos, el dispositivo puede usar, después de recopilar y reconstruir el código de mejora, su propia clave de aplicación criptográfica (AppKey) para calcular un primer troceo del parche recibido (por ejemplo, un troceo de SHA256). A continuación, el código de troceo se envía a un servidor de verificación que comprende una interfaz de comunicación de acuerdo con la presente invención. El servidor de verificación puede ser el servidor de red o un servidor seguro separado.
La parte de ejecución confiable del servidor de verificación calcula, a continuación, un segundo troceo de la AppKey del dispositivo en cuestión (siendo esta AppKey almacenada en la memoria del servidor, como todas las claves de aplicación de los dispositivos conectados al servidor). Finalmente, el servidor de verificación comprueba si el código de troceo corresponde a los datos que tienen que transmitirse al dispositivo comparando los dos troceos. Si los dos troceos son iguales, el servidor de verificación envía un mensaje al dispositivo de extremo para validar que el código informático puede cambiarse, y el código mejorado se almacena en la memoria del dispositivo (etapa 411).
Una ventaja de usar la clave de aplicación criptográfica individual del dispositivo de extremo en lugar de la clave de grupo es mejorar el nivel de seguridad. De hecho, si la clave de grupo se ve comprometida, usar la AppKey individual para autenticar los datos recibidos evita introducir código malicioso o comprometido en todos los dispositivos del grupo.
La interfaz de comunicación propuesta, y su uso en un dispositivo o en un servidor, proporciona una mayor efectividad en términos de coste y espacio a través de estado de la técnica de IoT existente eliminando la necesidad de un chip de elemento seguro (SE) específico. También puede abordar el problema de la obsolescencia asociado con los chips de SE proporcionando los medios técnicos de mejora de tanto las claves raíz criptográficas como de código de un subsistema de seguridad de IoT, en el contexto de restricciones severas de enlace de comunicación (cantidad de datos muy limitada).
En la red, permite un alto nivel de seguridad de las LPWAN eliminando cualquier exposición de material secreto a través de enlace de comunicación o memoria no segura. El acceso a claves criptográficas sensibles de los dispositivos se vuelve físicamente imposible. Por lo tanto, se reduce la necesidad de tener una protección específica de sistemas informáticos, o terceras partes confiables.
Por ejemplo, incluso si algunas de las realizaciones se han presentado en el contexto de protocolos de comunicación de LoRa, la presente invención no se limita a estos. Puede usarse en cualquier LPWAN que incluye primitivas criptográficas, o versiones de la LoraWAN distintas de 1.0.
Además, incluso si el método de "activación por el aire" se ha descrito en este punto, la presente invención no se limita a este tipo de activación. Por ejemplo, en el contexto de una LoRaWAN, la presente invención puede usarse en el caso en el que los dispositivos de extremo se activan mediante personalización (APB), en la que la DevAddr y las dos claves de sesión NwkSKey y AppSKey se almacenan directamente en el dispositivo de extremo en lugar del DevEUI, el AppEUl y la AppKey.
También, incluso si la invención se ha presentado para algunos métodos de activación o mejora, puede usarse en otras situaciones. Por ejemplo, la exportación de claves, que puede requerirse, por ejemplo, por fuerzas de seguridad nacionales, puede realizarse por una interfaz de comunicación como se divulga en el presente documento. Puede implementarse por primitivas personalizadas específicas que se ejecutan en modo seguro, por ejemplo, requiriendo la presentación simultánea de varios secretos de modo que el acceso a claves se vuelve posible únicamente en la presencia de un notario o entidad confiable similar.

Claims (30)

REIVINDICACIONES
1. Una interfaz de comunicación (200) para soportar comunicación entre un dispositivo inalámbrico (101, 102, 103) y un servidor (121) a través de una red de área extensa de baja potencia, LPWAN,
en donde la interfaz de comunicación (200) comprende:
una parte de ejecución no confiable (201) configurada para operar de acuerdo con una pila de protocolos de comunicación de LPWAN (203) que incluye al menos un protocolo de LPWAN seguro usando primitivas criptográficas;
una memoria (205) configurada para almacenar código informático encriptado (206) y al menos una clave criptográfica encriptada (207, 208, 209), en donde el código informático encriptado (206) y la al menos una clave criptográfica encriptada (207, 208, 209) se encriptan usando un secreto raíz;
una parte de ejecución confiable (202), que incorpora el secreto raíz (210), configurada para desencriptar el código informático encriptado (206) y la al menos una clave criptográfica encriptada (207, 208, 209) de la memoria (205), en donde la parte de ejecución confiable (202) está configurada adicionalmente para ejecutar las primitivas criptográficas del al menos un protocolo de LPWAN seguro usando la al menos una clave criptográfica desencriptada y el código informático desencriptado de la memoria (205).
2. La interfaz de comunicación (200) de acuerdo con la reivindicación 1,
que comprende un chip de microcontrolador (212) que incluye tanto la parte de ejecución no confiable (201) como la parte de ejecución confiable (202).
3. La interfaz de comunicación (200) de acuerdo con la reivindicación 1,
en donde la memoria (205) tiene una sección de memoria reprogramable (205a) para almacenar código informático (206) y una clave de aplicación criptográfica (AppKey) en una forma encriptada, y una sección de RAM o flash (205b) para almacenar, en una forma encriptada, al menos una clave de sesión criptográfica (AppSKey, NwkSKey) calculada por la parte de ejecución confiable (202) como una función de la clave de aplicación criptográfica.
4. La interfaz de comunicación (200) de acuerdo con la reivindicación 3,
en donde la sección de memoria reprogramable (205a) se proporciona adicionalmente para almacenar una clave de grupo criptográfica escrita en una forma encriptada por la parte de ejecución confiable (202) en respuesta a un comando para unirse a un grupo de multidifusión de dispositivos inalámbricos (101, 102, 103).
5. La interfaz de comunicación (200) de acuerdo con cualquiera de las reivindicaciones anteriores,
en donde la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable (202) comprende encriptar elementos de información concatenados de un primer conjunto de elementos de información con una clave de aplicación (AppKey) desencriptada de la memoria (205) para derivar una primera clave de sesión (AppSKey), en donde el primer conjunto de elementos de información incluye al menos un nonce.
6. La interfaz de comunicación (200) de acuerdo con la reivindicación 5,
en donde los elementos de información concatenados del primer conjunto incluyen un primer nonce generado por el servidor (121), un identificador de la LPWAN y un segundo nonce generado por el dispositivo inalámbrico (101, 102, 103).
7. La interfaz de comunicación (200) según una cualquiera de las reivindicaciones 5 y 6,
en donde la parte de ejecución confiable (202) está configurada para encriptar la primera clave de sesión (AppSKey) con el secreto raíz (210) y escribir la primera clave de sesión encriptada en una sección de RAM o flash (205b) de la memoria.
8. La interfaz de comunicación (200) según una cualquiera de las reivindicaciones 5 a 7,
en donde la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable (202) comprende encriptar un mensaje proporcionado por la parte de ejecución no confiable (201) usando la primera clave de sesión (AppSKey).
9. La interfaz de comunicación (200) según una cualquiera de las reivindicaciones 5 a 8,
en donde la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable (202) comprende encriptar elementos de información concatenados de un segundo conjunto de elementos de información con la clave de aplicación (AppKey) desencriptada de la memoria (205) para derivar una segunda clave de sesión (NwkSKey), en donde el segundo conjunto de elementos de información incluye al menos un nonce.
10. La interfaz de comunicación (200) de acuerdo con la reivindicación 9,
en donde los elementos de información concatenados del segundo conjunto incluyen un primer nonce generado por el dispositivo inalámbrico (101, 102, 103), un identificador de la LPWAN y un segundo nonce generado por el servidor (121).
11. La interfaz de comunicación (200) según una cualquiera de las reivindicaciones 9 y 10,
en donde la parte de ejecución confiable (202) está configurada para encriptar la segunda clave de sesión (NwkSKey) con el secreto raíz (210) y escribir la segunda clave de sesión encriptada en una sección de RAM o flash (205b) de la memoria.
12. La interfaz de comunicación (200) según una cualquiera de las reivindicaciones 9 a 11,
en donde la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable (202) comprende calcular un valor de comprobación de integridad de mensaje, MIC, basándose en un mensaje encriptado usando la segunda clave de sesión (NwkSKey).
13. La interfaz de comunicación de acuerdo con cualquiera de las reivindicaciones anteriores,
en donde la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable (202) comprende calcular un valor de comprobación de integridad de mensaje, MIC, basándose en elementos concatenados, incluyendo un nonce generado por el dispositivo inalámbrico, un identificador del dispositivo, y un identificador de un proveedor de aplicaciones, usando una clave de aplicación (AppKey) desencriptada de la memoria (205).
14. La interfaz de comunicación de acuerdo con cualquiera de las reivindicaciones anteriores,
en donde la ejecución de una de las primitivas criptográficas por la parte de ejecución confiable (202) comprende calcular un valor de comprobación de integridad de mensaje, MIC, basándose en elementos concatenados, incluyendo un identificador de la LPWAN y una dirección del dispositivo inalámbrico, usando una clave de aplicación (AppKey) desencriptada de la memoria (205).
15. Un dispositivo inalámbrico (101, 102, 103) que comprende una interfaz de comunicación (200) configurada para comunicar con un servidor (121) a través de una red de área extensa de baja potencia, LPWAN, en donde la interfaz de comunicación (200) es de acuerdo con cualquiera de las reivindicaciones anteriores.
16. El dispositivo inalámbrico (101, 102, 103) de acuerdo con la reivindicación 15,
en donde la parte de ejecución confiable (202) de la interfaz de comunicación (200) está configurada para cambiar (304) al menos una clave criptográfica almacenada en una forma encriptada en la memoria (205) de la interfaz de comunicación (200) en respuesta a un comando de actualización de clave recibido a través de la LPWAN.
17. El dispositivo inalámbrico (101, 102, 103) de acuerdo con la reivindicación 16,
en donde el cambio de la al menos una clave criptográfica encriptada se realiza por la parte de ejecución confiable (202) usando una clave de actualización almacenada en una forma encriptada (305).
18. El dispositivo inalámbrico (101, 102, 103) según una cualquiera de las reivindicaciones 15 a 17,
en donde la parte de ejecución confiable (202) de la interfaz de comunicación (200) está configurada para cambiar (411) una porción del código informático encriptado (206) almacenado en la memoria (205) en respuesta a un comando de mejora de código recibido a través de la LPWAN.
19. El dispositivo inalámbrico (101, 102, 103) de acuerdo con la reivindicación 18,
en donde el comando de mejora de código se recibe (406) en una dirección de multidifusión de la LPWAN en al menos un mensaje encriptado que se desencripta por la parte de ejecución confiable (202) usando una clave de grupo criptográfica almacenada en una forma encriptada en la memoria (205).
20. El dispositivo inalámbrico (101, 102, 103) de acuerdo con la reivindicación 19,
en donde la interfaz de comunicación (200) está configurado para aplicar decodificación por redundancia (407) al al menos un mensaje encriptado para obtener una porción de código mejorada para cambiar la porción del código informático encriptado (206) almacenado en la memoria (205).
21. El dispositivo inalámbrico (101, 102, 103) de acuerdo con la reivindicación 20,
en donde la decodificación por redundancia comprende una decodificación de comprobación de paridad de baja densidad, LDPC.
22. El dispositivo inalámbrico (101, 102, 103) según una cualquiera de las reivindicaciones 18 a 21,
en donde la parte de ejecución confiable (202) está configurada para calcular un código de troceo (410) basándose en una clave criptográfica almacenada en una forma encriptada en la memoria (205) y una porción de código mejorada recibida como parte del comando de mejora de código,
y en donde la interfaz de comunicación (200) está configurada para transmitir el código de troceo a un servidor de verificación y para recibir una respuesta desde el servidor de verificación para validar si tiene que cambiarse la porción del código informático (206 ).
23. Un servidor (121) que comprende una interfaz de comunicación (200) configurada para comunicar con una pluralidad de dispositivos inalámbricos (101, 102, 103) a través de una red de área extensa de baja potencia, LPWAN, en donde la interfaz de comunicación (200) es según una cualquiera de las reivindicaciones 1-14.
24. El servidor (121) de acuerdo con la reivindicación 23,
en donde la memoria (205) de la interfaz de comunicación (200) almacena una pluralidad de claves de aplicación criptográficas en una forma encriptada, siendo cada clave de aplicación criptográfica para un respectivo dispositivo inalámbrico (101, 102, 103) de la LPWAN.
25. El servidor (121) de acuerdo con la reivindicación 24,
en donde para cambiar (304) la clave de aplicación criptográfica para uno de la pluralidad de dispositivos inalámbricos (101, 102, 103), la interfaz de comunicación (200) está configurada para transmitir un comando de actualización de clave al uno de los dispositivos inalámbricos (101, 102, 103) a través de la LPWAN, a través de una dirección de unidifusión del uno de la pluralidad de dispositivos inalámbricos (101, 102, 103), y la parte de ejecución confiable (202) de la interfaz de comunicación (200) está configurada para cambiar la clave criptográfica almacenada en una forma encriptada en la memoria (205) de la interfaz de comunicación (200) para el uno de la pluralidad de dispositivos inalámbricos (101, 102, 103).
26. El servidor (121) según una cualquiera de las reivindicaciones 23 a 25,
en donde para cambiar una porción de código informático usada por un grupo de dispositivos inalámbricos (101, 102, 103), la interfaz de comunicación (200) está configurada para transmitir (405) un comando de mejora de código a través de la LPWAN, a través de una dirección de multidifusión de la LPWAN.
27. El servidor (121) de acuerdo con la reivindicación 26,
en donde la parte de ejecución confiable (202) de la interfaz de comunicación (200) está configurada para encriptar (402) el comando de mejora de código con una clave de grupo criptográfica asociada con la dirección de multidifusión de la LPWAN antes de la transmisión a través de la dirección de multidifusión.
28. El servidor (121) de acuerdo con la reivindicación 27,
en donde el comando de mejora de código encriptado se codifica por redundancia (403) y, a continuación, se divide (404) en una pluralidad de fragmentos transmitidos en respectivos mensajes a la dirección de multidifusión de la LPWAN.
29. El servidor (121) de acuerdo con la reivindicación 28,
en donde el comando de mejora de código encriptado se codifica por redundancia usando codificación de comprobación de paridad de baja densidad, LDPC.
30. El servidor (121) según una cualquiera de las reivindicaciones 26 a 29,
en donde la interfaz de comunicación (200) está configurada para recibir un primer código de troceo desde uno del grupo de dispositivos inalámbricos (101, 102, 103),
en donde la parte de ejecución confiable (202) está configurada para calcular un segundo código de troceo basándose en una clave criptográfica almacenada en una forma encriptada en la memoria (205) para el uno del grupo de dispositivos inalámbricos (101, 102, 103) y una porción de código mejorada que hay que sustituir para la porción de código informático usada por el grupo de dispositivos inalámbricos (101, 102, 103),
y en donde la interfaz de comunicación (200) está configurado adicionalmente para comparar el primer y segundo códigos de troceo y para enviar una respuesta al uno del grupo de dispositivos inalámbricos (101, 102, 103) dependiendo de si el primer y segundo códigos de troceo son idénticos o no.
ES17754193T 2017-03-02 2017-03-02 Interfaz de comunicación para una red de área extensa de baja potencia, dispositivo inalámbrico y servidor que usan tal interfaz de comunicación Active ES2901207T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2017/000924 WO2018158607A1 (en) 2017-03-02 2017-03-02 Communication interface for a low power wide area network, wireless device and server using such communication interface

Publications (1)

Publication Number Publication Date
ES2901207T3 true ES2901207T3 (es) 2022-03-21

Family

ID=59649965

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17754193T Active ES2901207T3 (es) 2017-03-02 2017-03-02 Interfaz de comunicación para una red de área extensa de baja potencia, dispositivo inalámbrico y servidor que usan tal interfaz de comunicación

Country Status (7)

Country Link
US (1) US11233771B2 (es)
EP (1) EP3590242B1 (es)
JP (1) JP7106561B2 (es)
ES (1) ES2901207T3 (es)
PL (1) PL3590242T3 (es)
TW (1) TWI750328B (es)
WO (1) WO2018158607A1 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2019200432A1 (en) * 2018-12-07 2020-06-25 Fleet Space Technologies Pty Ltd Remote LPWAN gateway with backhaul over a high-latency communication system
RU2720889C1 (ru) * 2018-12-21 2020-05-13 Общество с ограниченной ответственностью "СОВРЕМЕННЫЕ РАДИО ТЕХНОЛОГИИ" Компьютерно-реализуемый способ для шифрования данных для последующей конфиденциальной передачи этих зашифрованных данных в сети LPWAN
GB2586866B (en) * 2019-09-06 2021-10-27 R3 Iot Ltd A gateway for communication, and method thereof
CN110572481B (zh) * 2019-10-15 2022-07-08 广西交科集团有限公司 基于LoRa通信的智能化机电设备数据交互方法
CN113132913A (zh) * 2019-12-30 2021-07-16 北京九天微星科技发展有限公司 一种基于LoRaWan实现组播的方法
US11540119B2 (en) 2020-02-06 2022-12-27 Wiliot, LTD. System and method for providing secure and reliable communication over a low-energy wireless communication protocol
CN112073133B (zh) * 2020-08-17 2022-05-17 成都极企科技有限公司 一种LoRa网关、信道探测系统和方法
EP4211983A4 (en) * 2020-09-10 2024-10-09 13486826 Canada Inc SYSTEM AND METHOD FOR LPWAN
US12120225B2 (en) * 2020-09-25 2024-10-15 Renesas Electronics Corporation Secure key generation and management in open and secure processor environments
EP4420030A1 (en) * 2021-10-20 2024-08-28 Everynet Oy Methods and systems for dataflow control in low power wide area networks

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2865654B1 (ja) * 1998-02-03 1999-03-08 株式会社高度移動通信セキュリティ技術研究所 鍵更新方法
US6684331B1 (en) * 1999-12-22 2004-01-27 Cisco Technology, Inc. Method and apparatus for distributing and updating group controllers over a wide area network using a tree structure
US7243230B2 (en) * 2001-11-16 2007-07-10 Microsoft Corporation Transferring application secrets in a trusted operating system environment
JP3879569B2 (ja) * 2002-04-10 2007-02-14 株式会社日立製作所 ソフトウエア配布方法およびシステム
JP2005032130A (ja) * 2003-07-10 2005-02-03 Sony Corp データ管理装置、およびデータ管理方法、並びにコンピュータ・プログラム
US20100303096A1 (en) * 2009-06-02 2010-12-02 Assaf Kasher Apparatus and mehtods for increased mac header protection
FR3004041B1 (fr) * 2013-03-28 2015-04-17 Commissariat Energie Atomique Procede et dispositif d'etablissement de cles de session
JP5864510B2 (ja) * 2013-10-18 2016-02-17 富士通株式会社 修正プログラム確認方法、修正プログラム確認プログラム、及び情報処理装置
JP5766309B2 (ja) * 2014-01-06 2015-08-19 ノキア コーポレイション セキュアモジュールアプリケーションに関連する情報の管理
US20160036826A1 (en) * 2014-07-29 2016-02-04 Mcafee, Inc. Secure content packaging using multiple trusted execution environments
EP3228099A1 (en) * 2014-12-05 2017-10-11 PCMS Holdings, Inc. Protecting the integrity of log entries in a distributed system
GB2538796A (en) * 2015-05-29 2016-11-30 Novaccess S A Smart lighting
US10548000B2 (en) * 2015-06-11 2020-01-28 Intel IP Corporation Cellular IoT network architecture
US10355854B2 (en) * 2015-12-17 2019-07-16 Intel Corporation Privacy preserving group formation with distributed content key generation
US20180019976A1 (en) * 2016-07-14 2018-01-18 Intel Corporation System, Apparatus And Method For Massively Scalable Dynamic Multipoint Virtual Private Network Using Group Encryption Keys

Also Published As

Publication number Publication date
US11233771B2 (en) 2022-01-25
WO2018158607A1 (en) 2018-09-07
TW201834503A (zh) 2018-09-16
JP7106561B2 (ja) 2022-07-26
EP3590242B1 (en) 2021-09-29
US20190394172A1 (en) 2019-12-26
PL3590242T3 (pl) 2022-01-31
TWI750328B (zh) 2021-12-21
JP2020510334A (ja) 2020-04-02
EP3590242A1 (en) 2020-01-08

Similar Documents

Publication Publication Date Title
ES2901207T3 (es) Interfaz de comunicación para una red de área extensa de baja potencia, dispositivo inalámbrico y servidor que usan tal interfaz de comunicación
US12088706B2 (en) Device securing communications using two post-quantum cryptography key encapsulation mechanisms
US11777719B2 (en) Public key exchange with authenicated ECDHE and security against quantum computers
US11949798B2 (en) Secure configuration of a secondary platform bundle within a primary platform
US20200162247A1 (en) Secure firmware transfer from a server to a primary platform
US11979508B2 (en) Secure IDS certificate verification for a primary platform
US12003629B2 (en) Secure server digital signature generation for post-quantum cryptography key encapsulations
US9166782B2 (en) Dynamic distributed key system and method for identity management, authentication servers, data security and preventing man-in-the-middle attacks
EP3073668B1 (en) Apparatus and method for authenticating network devices
US20170012949A1 (en) Dynamic identity verification and authentication continuous, dynamic one-time-pad/one-time passwords and dynamic distributed key infrastructure for secure communications with a single key for any key-based network security controls
WO2016020640A1 (en) Control mechanisms for data processing devices
US20230361994A1 (en) System and Methods for Secure Communication Using Post-Quantum Cryptography
JP2009500905A (ja) セキュアパッチシステム
BRPI0718048A2 (pt) Método e equipamento para autenticação mútua
JP7551080B2 (ja) 最適化された公開鍵基盤を備える組み込みシステムのネットワークを保護および管理するための方法ならびにアーキテクチャ
US20230308424A1 (en) Secure Session Resumption using Post-Quantum Cryptography
US20240106636A1 (en) Multiple post-quantum cryptography key encapsulations with authentication and forward secrecy
US20190199521A1 (en) Method and apparatus for secure access to a sensor or device network
Cooper et al. Fido device onboard specification 1.1
Singh et al. A key hiding communication scheme for enhancing the wireless LAN security
KR101290818B1 (ko) 보안 패치 시스템
ES2700109T3 (es) Método de transmisión de datos desde un token seguro a un servidor
Cooper FIDO IoT spec
CN117426070A (zh) 在网络设备之间安全且可靠地传送消息