ES2934874T3 - Restablecimiento protegido de un dispositivo de internet de las cosas IdC - Google Patents

Restablecimiento protegido de un dispositivo de internet de las cosas IdC Download PDF

Info

Publication number
ES2934874T3
ES2934874T3 ES19210364T ES19210364T ES2934874T3 ES 2934874 T3 ES2934874 T3 ES 2934874T3 ES 19210364 T ES19210364 T ES 19210364T ES 19210364 T ES19210364 T ES 19210364T ES 2934874 T3 ES2934874 T3 ES 2934874T3
Authority
ES
Spain
Prior art keywords
iot device
access code
cloud backend
cloud
access
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
ES19210364T
Other languages
English (en)
Inventor
Rainer Falk
Felix Nagel
Christian Winter
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.)
Siemens Energy Global GmbH and Co KG
Original Assignee
Siemens Energy Global GmbH and Co KG
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 Siemens Energy Global GmbH and Co KG filed Critical Siemens Energy Global GmbH and Co KG
Application granted granted Critical
Publication of ES2934874T3 publication Critical patent/ES2934874T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • 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
    • 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/45—Structures or tools for the administration of authentication
    • 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/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent
    • 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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2131—Lost password, e.g. recovery of lost or forgotten passwords
    • 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
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0846—Network architectures or network communication protocols for network security for authentication of entities using passwords using time-dependent-passwords, e.g. periodically changing passwords

Abstract

La invención se refiere a un método para reconfigurar un dispositivo IoT (10), en el que el dispositivo IoT (10) se puede conectar a un backend en la nube (20) a través de una red. El método comprende los siguientes pasos preparatorios: - guardar un código de acceso ingresado localmente en el backend de la nube (20) y - almacenar el código de acceso o la información de prueba formada en función del mismo en el dispositivo IoT (10). El método también incluye los siguientes pasos para reconfigurar el dispositivo IoT (10): - consultar el código de acceso desde el backend de la nube (20), - ingresar el código de acceso solicitado en una interfaz de configuración local (13) del dispositivo IoT (10) o en un dispositivo de entrada (31) conectado a la interfaz de configuración local (13) del dispositivo loT (10), para la reconfiguración en el caso de una comparación positiva del código de acceso ingresado con el código de acceso almacenado en el dispositivo IoT (10) o la información de prueba formada dependiente del mismo. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Restablecimiento protegido de un dispositivo de internet de las cosas IdC
La presente invención hace referencia a un procedimiento para reconfigurar un dispositivo de internet de las cosas IdC (abreviatura en inglés IoT). La presente invención en particular hace referencia al problema de cómo puede tener lugar de forma protegida un restablecimiento (expresado de otro modo: una reconfiguración) de un dispositivo IdC, sin que para ello el propio dispositivo deba comunicarse con una parte de servidor de aplicación (backend) en la nube mediante una red.
Introducción
Un procedimiento de esa clase se conoce por ejemplo por la solicitud US 2016/352702 A1. Allí se describe un mecanismo para el restablecimiento de una contraseña. Para ello, un usuario que fue autorizado para el dispositivo que debe protegerse, inicia el restablecimiento de la contraseña, enviando una consulta correspondiente a un servicio de restablecimiento. A continuación, el mismo recibe un correo electrónico firmado de forma digital, con cuya ayuda es posible restablecer la contraseña en e[l lugar.
Otro procedimiento de esa clase se conoce por la solicitud CN 108986278 A.
Los dispositivos IdC registran datos y los envían protegidos a un backend en la nube. Un ejemplo de un dispositivo IdC de esa clase es el producto "Sensformer®" de la empresa Siemens, que registra datos de monitorización de transformadores y los envía para una evaluación a un backend en la nube mediante una conexión de comunicaciones protegida de forma criptográfica, en general un protocolo TLS.
Esos dispositivos IdC deben ser configurados. La configuración puede tener lugar de forma remota mediante la interfaz de la nube o mediante una interfaz de administración local (interfaz de línea de comandos o servidor web). Para impedir una modificación de la configuración no autorizada se requiere una autenticación del acceso de servicio. Para ello, en la interfaz de administración local habitualmente debe ingresarse una contraseña o un código de acceso comparable.
Cuando el código de acceso ya no es conocido, el respectivo dispositivo ya no puede configurarse ni utilizarse. Si también está interrumpida la conexión hacia el backend en la nube, por ejemplo debido a una configuración incorrecta anterior, el aparato no puede utilizarse y debe ser enviado.
Por ese motivo existe la necesidad de poder restablecer un código de acceso del dispositivo o toda la configuración del aparato (restablecimiento de contraseña/ reinicio de fábrica), para poder acceder nuevamente al acceso de administración local). Esto debe tener lugar de forma protegida, para impedir un restablecimiento inadmisible.
Descripción general de la invención
El procedimiento según la invención, según la reivindicación 1, ofrece un procedimiento de esa clase. En las reivindicaciones dependientes, en la descripción y en las ilustraciones se indican variantes y perfeccionamientos ventajosos.
El procedimiento según la invención para reconfigurar un dispositivo IdC que puede conectarse a un backend en la nube mediante una red comprende las siguientes etapas:
- almacenamiento de un código de acceso que puede ingresarse de forma local, en el backend en la nube, - almacenamiento del código de acceso o de una información de control formada en función del mismo, en el dispositivo IdC,
- consulta del código de acceso desde el backend en la nube,
- ingreso del código de acceso consultado en una interfaz de configuración local del dispositivo IdC o en un dispositivo de entrada conectado a la interfaz de configuración local del dispositivo IdC,
- comparación del código de acceso ingresado con el código de acceso almacenado en el dispositivo IdC, así como con la información de control formada en función del mismo, y
- autorización del dispositivo IdC para la reconfiguración en el caso de una comparación positiva del código de acceso ingresado con el código de acceso almacenado en el dispositivo IdC, así como con la información de control formada en función del mismo, donde la reconfiguración se anula si el dispositivo IdC no se ha conectado nuevamente al backend en la nube dentro de un periodo predeterminado después de la reconfiguración.
Las dos primeras etapas forzosamente deben realizarse antes que las etapas restantes. También pueden denominarse como etapas de preparación. El almacenamiento del código de acceso, así como de la información de control formada en función del mismo en el dispositivo IdC ya puede tener lugar de fábrica, durante la producción del dispositivo IdC. De manera alternativa, el código de acceso o la información de control también pueden tener lugar mediante el cliente durante el onboarding (incorporación), por tanto, al poner en función el dispositivo IdC. También es posible que esto se repita automáticamente, por ejemplo de forma diaria, semanal o mensual. Lo mencionado ofrece la ventaja de que los códigos de acceso nuevos y una información de control asociada pueden establecerse de forma automática. Debido a esto, los códigos de acceso establecidos anteriormente ya no pueden utilizarse de forma ilícita, aun cuando hayan sido conocidos por un agresor.
De manera ventajosa, al poner en funcionamiento el dispositivo IdC también tiene lugar una estructuración de la conexión del dispositivo IdC con el backend en la nube.
Las siguientes etapas, es decir, la consulta, el ingreso y la comparación del código de acceso, tienen lugar si el dispositivo IdC debe reconfigurarse concretamente, por ejemplo porque ya no funciona una conexión de comunicaciones entre el dispositivo IdC y el backend en la nube.
En general, el código de acceso por ejemplo puede tratarse de un valor aleatorio, de letras, cifras y/o caracteres especiales. En general puede tratarse también de una secuencia de bits, de una estructura XML o de una estructura de datos JSON.
En una primera variante, el código de acceso puede ser formado (expresado de otro modo: generado) por el propio dispositivo IdC.
De manera alternativa, el código de acceso puede ser formado por el backend en la nube.
En otra variante, un primer valor aleatorio es formado por el dispositivo IdC, y un segundo valor aleatorio es formado por el backend en la nube. En base a ello, a continuación, se genera el código de acceso en común.
En el marco de esta solicitud de patente, los términos "código de acceso" y "código de acceso del dispositivo" se utilizan como sinónimos. Además, en el marco de esta solicitud de patente "dispositivo IdC", en algunos puntos, para simplificar la lectura, está abreviado como "dispositivo".
Por un dispositivo IdC, en el marco de esta solicitud de patente, se entiende en general un dispositivo conectado mediante cables o que puede conectarse de forma inalámbrica, que genera datos y/o realiza órdenes de control. Un dispositivo IdC, en el lenguaje especializado, ocasionalmente se denomina también como "Edge Device" o "Smart Edge Device" (dispositivo de borde o dispositivo de borde inteligente).
En una forma de ejecución especial, el dispositivo IdC monitoriza un transformador. El dispositivo IdC, por ejemplo, transmite a la nube el nivel de aceite, la temperatura, la corriente de tensión negativa- corriente del bobinado y/o el posicionamiento GPS del transformador.
Por el backend en la nube se entiende un servicio de tecnologías de la información IT al que puede accederse mediante una red pública o privada. Habitualmente, puede accederse a un backend en la nube mediante Internet o una red de telefonía pública, por ejemplo 3G, LTE, 5G, LoRa, NB-IoT o SigFox. Como ejemplos de un backend en la nube pueden mencionarse Siemens MindSphere, Microsoft Azure, Amazon AWS. La transmisión de datos puede tener lugar por ejemplo mediante un protocolo TLS (TLS: Transport Layer Security, seguridad de la capa de transporte), protegida de forma criptográfica. El backend en la nube almacena el código de acceso que debe ingresarse de forma local, de modo que el mismo, en caso necesario, puede proporcionarse a un usuario autorizado. El dispositivo IdC puede almacenar el código de acceso directamente o una información de control formada en función del mismo. La información de control permite al dispositivo IdC verificar la validez de un código de acceso ingresado de forma local (como es conocido por el experto en controles de contraseñas).
En un instante posterior, el código de acceso que debe ser ingresado localmente en el dispositivo IdC puede ser consultado desde el backend en la nube, mediante un usuario autorizado. El código de acceso, por ejemplo, puede mostrarse o proporcionarse como un archivo de texto. El mismo puede visualizarse como un elemento gráfico para impedir una copia sencilla del código de acceso mediante copiado & pegado.
El código de acceso consultado desde el backend en la nube, de manera ventajosa, se ingresa en una interfaz de configuración local del dispositivo IdC. Puede tratarse por ejemplo de una interfaz RS232-, USB-, SPI o I2C. El ingreso, de manera ventajosa, tiene lugar mediante un dispositivo de entrada conectado a la interfaz de configuración local por medio de un cable LAN. También es posible que el dispositivo IdC presente una interfaz operativa, por ejemplo un teclado o una pantalla sensible al tacto (pantalla táctil), que permitan ingresar el código de acceso.
Además, el servicio de nube puede autenticar el usuario que debe acceder, y registrar qué usuario ha obtenido un código de acceso del dispositivo. Esto posibilita identificar el usuario que accede localmente a un dispositivo, aunque el dispositivo en sí mismo sólo facilite técnicamente un código de acceso del dispositivo sencillo. Esto es beneficioso para la exigencia IEC62443-4.2, de implementar una "unique user identification" (identificación de usuario única) (requirement/requerimiento CR1.1 (1)).
El código de acceso que debe ingresarse puede posibilitar distintas clases de acceso al dispositivo IdC:
En primer lugar, mediante el código de acceso es posible un acceso directo al menú de configuración del dispositivo IdC. En segundo lugar, el código de acceso podría posibilitar un restablecimiento de una contraseña de acceso local. La contraseña de acceso, en este caso, debería ser establecida nuevamente por el usuario, para poder acceder al menú de configuración. En tercer lugar es posible que mediante el código de acceso tenga lugar directamente un "reinicio de fábrica", es decir, un restablecimiento de todos los ajustes del dispositivo al ajuste de fábrica.
Una de las clases de acceso mencionadas puede estar predeterminada de forma fija en un dispositivo IdC. En una variante, sin embargo, pueden estar preparados varios códigos de acceso con una acción relacionada diferente, que pueden proporcionarse al usuario autorizado en caso necesario, mediante el backend en la nube. Un dispositivo, de este modo, realiza la acción correspondiente, en función de qué código de acceso fue ingresado.
Además, pueden proporcionarse una gran cantidad o una pluralidad de códigos de acceso que pueden ingresarse de forma local.
Un código de acceso, preferentemente, sólo puede utilizarse de forma limitada (en particular sólo una única vez). Después de restablecerse la conectividad de la nube, preferentemente, se dispone un nuevo grupo de códigos de acceso locales del dispositivo.
En una variante, el backend en la nube proporciona un código de acceso para la reconfiguración solamente cuando el dispositivo correspondiente no se ha registrado en el backend en la nube durante un cierto periodo (por ejemplo 1 hora, 1 día, 1 semana), mediante la red, y/o ha actualizado sus datos de estado. Esto ofrece la ventaja de que independientemente de las autorizaciones del usuario, un código de acceso para un acceso de administración local hacia el dispositivo se proporciona solamente cuando el dispositivo correspondiente ya no pudo conectarse al backend en la nube por un periodo más prolongado. Por el contrario, en el funcionamiento regular, cuando el acceso a la nube funciona del modo previsto, el código de restablecimiento, es decir, el código de acceso, no puede ser consultado. Aquí, la configuración del dispositivo debe tener lugar entonces mediante el backend en la nube.
En el marco de la invención, después de un acceso local dentro de una ventana de tiempo (por ejemplo 10 minutos, 1 hora, 24 horas), debe reiniciarse una comunicación que funcione en la nube. En caso de que esto no se logre, el dispositivo reactiva automáticamente otra vez la configuración anterior protegida.
La invención posibilita que un dispositivo IdC (particularmente por ejemplo un dispositivo IdC Sensformer® de la empresa Siemens), cuya configuración ya no funciona para el acceso a la nube, pueda ponerse en funcionamiento otra vez, de forma protegida. En particular, esto también funciona cuando el dispositivo IdC ya no puede comunicarse con el backend en la nube (por ejemplo porque la configuración de la red para el acceso a la nube fue configurada con errores).
Además, en el dispositivo IdC no es necesario que una contraseña del acceso de servicio local se configure de forma manual. En tanto el dispositivo IdC funcione del modo previsto, el mismo puede administrarse (expresado de otro modo: configurarse) mediante la interfaz de nube. El código de acceso preparado se proporciona solamente cuando el acceso a la nube ya no funciona. Esto ofrece la ventaja de que en el funcionamiento normal no es posible un acceso a la interfaz de configuración local del dispositivo IdC.
Breve descripción de los dibujos
A continuación, la invención se ilustra a modo de ejemplo y de forma esquemática mediante dos dibujos.
Muestran:
Figura 1: una disposición de dispositivo IdC, backend en la nube y usuario, según el estado del arte, así como Figura 2: un diagrama de operaciones de un procedimiento para reconfigurar un dispositivo IdC según una forma de ejecución de la invención.
Descripción detallada de los dibujos
La figura 1 muestra una situación de aplicación que ilustra cómo un dispositivo IdC 10 puede reconfigurarse de forma protegida, del modo habitual. Como dispositivo IdC 10 se toma como ejemplo un "dispositivo IdC Sensformer®", abreviado Sensformer®, de la empresa Siemens. El Sensformer® 10 tiene la función de monitorizar un transformador 11 conectado al mismo. El Sensformer® 10, mediante un sensor 121 propio, así como mediante sensores 122, 123 del transformador 11, detecta datos de monitorización/de funcionamiento del transformador 11 (por ejemplo temperatura y nivel de llenado del líquido de refrigeración), así como la temperatura ambiente. Esa información, mediante una interfaz de telefonía móvil 41 (por ejemplo UMTS, LTE, 5G, LoRa, NB-IdC o SigFox) y la Internet 43, se transmite a un backend en la nube 20. Debido a esto, por ejemplo, puede detectarse si el transformador 11 necesita un mantenimiento (mantenimiento predictivo). En el Sensformer® 10 está instalado un microprograma para detectar datos del sensor, eventualmente para procesarlos previamente, y para establecer una conexión de transmisión de datos hacia el backend en la nube 20. Esto último puede realizarse por ejemplo mediante TCP/IP, TLS y HTTP, MQTT, OPC UA o CoAP.
Además se establece una segunda conexión para administrar el dispositivo IdC Sensformer® 10, es decir, para modificar los ajustes de configuración de forma remota, o para instalar una actualización del microprograma. Un técnico de servicio 30 se conecta para ello mediante un dispositivo de entrada 31 y un navegador web, con la interfaz de configuración del servicio de nube (Cloud-Service), e ingresa los cambios de la configuración que se transmiten después al dispositivo IdC 10 Sensformer®. La conexión entre el dispositivo de entrada 31, por ejemplo un ordenador móvil, y la Internet 43, está identificada en la figura 1 con el símbolo de referencia 42.
En casos poco frecuentes, por ejemplo, en el caso de un funcionamiento técnico incorrecto o en el caso de un manejo incorrecto, sin embargo, puede suceder que la configuración instalada no pueda funcionar. De este modo, por ejemplo, una URL incorrecta del servicio de nube, un certificado falso del servicio de nube, un certificado falso del dispositivo, un nombre APN falso (nombre de punto de acceso, un nombre de red para un acceso de telefonía móvil) de la configuración de telefonía móvil, u otros, puede conducir a que el dispositivo IdC 10 Sensformer® ya no pueda conectarse con el backend en la nube 20. La configuración, entonces, tampoco ya puede corregirse mediante el backend en la nube 20.
Por ese motivo, para casos de esa clase está proporcionada además una interfaz de configuración local (LCI) 13, que por ejemplo puede estar realizada como una interfaz RS232, USB, SPI o I2C. El técnico de servicio 31 puede conectarse a la interfaz de configuración local 13 del dispositivo IdC 10 Sensformer® mediante una conexión de cable local. Esa conexión en general está protegida mediante una contraseña o un código de acceso que sólo es conocido por el técnico de servicio 30. Si éste la ha olvidado ya no es posible un acceso al dispositivo IdC 10 y el dispositivo IdC 10 debe ser enviado, por ejemplo para una reconfiguración.
La presente invención propone ahora que en un caso de esa clase deba ingresarse un código de acceso generado previamente en el backend en la nube y almacenado en el dispositivo IdC, para poder obtener nuevamente un acceso a los ajustes de configuración. De este modo, de forma automática, los ajustes de configuración reales pueden restablecerse por completo o parcialmente a los valores por defecto (por ejemplo restablecimiento de contraseña, reinicio de fábrica).
La figura 2 muestra un diagrama de operaciones de un procedimiento para reconfigurar un dispositivo IdC 10 según una forma de ejecución de la invención. Se trata de operaciones ilustrativas, para las que es posible una serie de alternativas y variantes que naturalmente ya fueron descritas al experto en la descripción general de la invención o que son evidentes de todos modos para el mismo debido a su conocimiento especializado.
Para la reconfiguración, el procedimiento se divide en dos fases: En primer lugar, en la fase de la generación y el almacenamiento de un código de acceso (fase 100); a continuación en la fase de la reconfiguración efectiva del dispositivo IdC 10 mediante la interfaz de configuración local 13 (fase 200). Si el dispositivo IdC 10 se ha reconfigurado de manera exitosa, el mismo puede comunicarse regularmente con el backend en la nube 20 (fase 300), y por ejemplo puede enviar sus datos del sensor al backend en la nube 20.
En el ejemplo de la figura 2, la primera fase 100 comprende las siguientes etapas: Envío de una señal de conexión desde el dispositivo IdC 10 al backend en la nube 20 (etapa 101); envío de una confirmación de recepción de la señal de conexión desde el backend en la nube 20 de regreso al dispositivo IdC 10 (etapa 102). A continuación, el backend en la nube 20 genera un código de acceso que debe ingresarse de forma local, y almacena el mismo en el backend en la nube 20 (etapa 103). El código de acceso generado o una información de control formada en función del mismo, a continuación es enviada desde el backend en la nube 20 al dispositivo IdC 10 (etapa 104). En la siguiente etapa 105, éste es almacenado en el dispositivo IdC 10 (etapa 105). A continuación tiene lugar una confirmación de que el código de acceso o bien la información de control se almacenaron en el dispositivo IdC 10 (etapa 106), y una señal, de que se interrumpe la conexión entre el dispositivo IdC 10 y el backend en la nube 20 (etapa 107). Finalmente, el backend en la nube 20 confirma esto al dispositivo IdC 10 (etapa 108).
Si ahora se produce una interrupción imprevista y no deseada de la conexión entre el dispositivo IdC 10 y el backend en la nube 20 y se presenta la necesidad de una reconfiguración del dispositivo IdC 10, se aplica la fase 200 con las siguientes etapas: Envío de una consulta con respecto al código de acceso, desde un usuario 30 hacia el backend en la nube 20 (etapa 201); respuesta del backend en la nube 20 al usuario 30 con el envío del código de acceso almacenado (etapa 202); ingreso del código de acceso obtenido en el dispositivo IdC 10, por ejemplo mediante un ordenador portátil conectado con la conexión LAN a la interfaz de configuración local del dispositivo IdC 10 (etapa 203). A continuación, en el dispositivo IdC 10, el código de acceso ingresado se compara con el código de acceso previamente almacenado, así como con la información asociada (etapa 204). Si ambos códigos de acceso coinciden, o la información de control encaja con el código de acceso ingresado, en el ejemplo representado en la figura 2 tiene lugar un reinicio de fábrica (etapa 205). Entre otras cosas, esto permite que el usuario 30 cambie los ajustes de configuración (etapa 206). Esto se le comunica al usuario 30 (etapa 207). En la siguiente etapa, el usuario 30 reconfigura el dispositivo IdC según sus ideas y requerimientos (etapa 208). Los nuevos ajustes de configuración se almacenan en el dispositivo IdC 10 (etapa 209), y finalmente se envía una confirmación al usuario 30 (etapa 210). El dispositivo IdC 10 ahora puede utilizarse nuevamente para un acceso al backend en la nube 20, de manera que se aplica la tercera fase 300, el acceso regular del dispositivo IdC 10 al backend en la nube 20. En la figura 2 esto está simbolizado mediante un envío de una señal de conexión desde el dispositivo IdC 10 al backend en la nube 20 (etapa 301) y el envío de una confirmación de recepción desde el backend en la nube 20 al dispositivo IdC 10 (etapa 302).
El procedimiento representado en la figura 2, a modo de ejemplo, muestra cómo un dispositivo IdC puede reconfigurarse de forma protegida, sin que para ello el propio dispositivo IdC deba comunicarse con el backend en la nube (durante la reconfiguración).
Lista de símbolos de referencia
10 Dispositivo IdC, por ejemplo un Sensformer®
11 Transformador
121 Sensor
122 Sensor
123 Sensor
13 Interfaz de configuración local
20 backend en la nube
30 Usuario, técnico de servicio
31 Dispositivo de entrada
41 Conexión entre el dispositivo IdC e Internet
42 Conexión entre el dispositivo de entrada e Internet
43 Conexión de Internet
100 Generación y almacenamiento de un código de acceso
101...108 Etapas
200 Reconfiguración del dispositivo IdC mediante su interfaz de configuración local
...210 Etapas
Acceso regular del dispositivo IdC al backend en la nube
, 302 Etapas

Claims (11)

REIVINDICACIONES
1. Procedimiento para reconfigurar un dispositivo internet de las cosas IdC (10), donde el dispositivo IdC (10) puede conectarse a un backend en la nube (20) mediante una red, el cual comprende las siguientes etapas:
- almacenamiento de un código de acceso que puede ingresarse de forma local, en el backend en la nube (20),
- almacenamiento del código de acceso o de una información de control formada en función del mismo, en el dispositivo IdC (10),
- consulta del código de acceso desde el backend en la nube (20),
- ingreso del código de acceso consultado en una interfaz de configuración local (13) del dispositivo IdC (10) o en un dispositivo de entrada (31) conectado a la interfaz de configuración local (13) del dispositivo IdC (10), - comparación del código de acceso ingresado con el código de acceso almacenado en el dispositivo IdC (10), así como con la información de control formada en función del mismo, y
- autorización del dispositivo IdC (10) para la reconfiguración en el caso de una comparación positiva del código de acceso ingresado con el código de acceso almacenado en el dispositivo IdC (10), así como con la información de control formada en función del mismo, donde la reconfiguración se anula si el dispositivo IdC (10) no se ha conectado nuevamente al backend en la nube (20) dentro de un periodo predeterminado después de la reconfiguración.
2. Procedimiento según la reivindicación 1, donde el código de acceso es generado por el dispositivo IdC (10) o por el backend en la nube (20).
3. Procedimiento según la reivindicación 1, donde
- un primer valor aleatorio es formado por el dispositivo IdC (10) y un segundo valor aleatorio es formado por el backend en la nube (20), y
- el código de acceso se forma en base al primer valor aleatorio y al segundo valor aleatorio.
4. Procedimiento según una de las reivindicaciones precedentes, donde la consulta del código de acceso desde el backend en la nube (20) contiene las siguientes subetapas:
- envío de una consulta al backend en la nube (20), y
- puesta a disposición del código de acceso.
5. Procedimiento según la reivindicación 4, donde la puesta a disposición del código de acceso tiene lugar mediante una indicación del código de acceso, un archivo de texto que contiene el código de acceso o un elemento gráfico que reproduce el código de acceso.
6. Procedimiento según una de las reivindicaciones 4 ó 5, donde el código de acceso se proporciona sólo con la condición de que el dispositivo IdC (10) no se haya registrado en el backend en la nube (20) mediante la red por un periodo predeterminado.
7. Procedimiento según una de las reivindicaciones precedentes, donde la consulta del código de acceso desde el backend en la nube (20) contiene
- una autenticación del usuario (30) que realiza la consulta y/o
- una detección y un almacenamiento del usuario (30) que realiza la consulta.
8. Procedimiento según una de las reivindicaciones precedentes, donde el código de acceso consultado desde el backend en la nube (20) se ingresa en un dispositivo de entrada (31) que está conectado a la interfaz de configuración local (13) del dispositivo IdC (10) mediante un cable LAN.
9. Procedimiento según una de las reivindicaciones precedentes, donde en el caso de una comparación positiva del código de acceso ingresado con el código de acceso almacenado en el dispositivo IdC (10), o con la información de control formada en función del mismo
- se proporciona una contraseña de acceso local para la reconfiguración local del dispositivo IdC (10), o - tiene lugar un restablecimiento de todos los ajustes del dispositivo, del dispositivo IdC (10), a un ajuste de fábrica.
10. Procedimiento según una de las reivindicaciones precedentes, donde el código de acceso puede utilizarse sólo en un número limitado, en particular una única vez.
11. Procedimiento según una de las reivindicaciones precedentes, donde el dispositivo IdC (10) monitoriza un transformador.
ES19210364T 2019-11-20 2019-11-20 Restablecimiento protegido de un dispositivo de internet de las cosas IdC Active ES2934874T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19210364.6A EP3825880B1 (de) 2019-11-20 2019-11-20 Geschütztes rücksetzen eines iot-geräts

Publications (1)

Publication Number Publication Date
ES2934874T3 true ES2934874T3 (es) 2023-02-27

Family

ID=68732696

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19210364T Active ES2934874T3 (es) 2019-11-20 2019-11-20 Restablecimiento protegido de un dispositivo de internet de las cosas IdC

Country Status (6)

Country Link
US (1) US20220417749A1 (es)
EP (1) EP3825880B1 (es)
CN (1) CN114902218A (es)
ES (1) ES2934874T3 (es)
FI (1) FI3825880T3 (es)
WO (1) WO2021099063A1 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180119515A (ko) * 2017-04-25 2018-11-02 김현민 스마트 휴대 기기를 이용한 스마트 기기와 로봇의 개인 맞춤형 서비스 운용 시스템 및 방법
WO2023217645A1 (de) 2022-05-10 2023-11-16 Barix Ag Abgesichertes zugriffssystem

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070250914A1 (en) * 2006-04-19 2007-10-25 Avaya Technology Llc Method and system for resetting secure passwords
BRPI0822741B1 (pt) * 2008-05-26 2020-07-07 Nxp B.V. leitor e método de determinação da validade de uma conexão a um transponder e meio legível por computador
US20120191596A1 (en) * 2011-01-26 2012-07-26 Gary Kremen Evaluating, monitoring, and controlling financial risks using stability scoring of information received from social networks and other qualified accounts
CN103856472B (zh) * 2012-12-06 2017-08-18 阿里巴巴集团控股有限公司 一种账户登录的方法及装置
US20170201382A1 (en) * 2013-04-03 2017-07-13 Ty Lindteigen Secure Endpoint Devices
JP5943359B2 (ja) * 2014-11-05 2016-07-05 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ パスワードを検証するシステム、方法およびプログラム
EP3024175B1 (en) * 2014-11-19 2019-07-31 Tanaza S.p.A. Method and system for remote management of network devices
US10291567B2 (en) * 2015-06-01 2019-05-14 ETAS Embedded System Canada Inc. System and method for resetting passwords on electronic devices
US10063557B2 (en) * 2015-06-07 2018-08-28 Apple Inc. Account access recovery system, method and apparatus
CN105100082A (zh) * 2015-07-02 2015-11-25 惠州Tcl移动通信有限公司 云终端接入家庭云系统的方法、系统及云接入控制设备
US10454900B2 (en) * 2015-09-25 2019-10-22 Mcafee, Llc Remote authentication and passwordless password reset
US9722803B1 (en) * 2016-09-12 2017-08-01 InfoSci, LLC Systems and methods for device authentication
CA2943131C (en) * 2016-09-26 2020-01-14 The Toronto-Dominion Bank Automatic provisioning of services to network-connected devices
US20180115551A1 (en) * 2016-10-20 2018-04-26 Brian Cole Proxy system for securely provisioning computing resources in cloud computing environment
KR101908373B1 (ko) * 2017-03-10 2018-10-17 한국전력공사 변압기 수소 가스 감시 시스템, 장치 및 방법
US20200073452A1 (en) * 2017-04-05 2020-03-05 Sony Corporation Wireless reset mechanism for machine-to-machine device
US10902418B2 (en) * 2017-05-02 2021-01-26 Visa International Service Association System and method using interaction token
CN107577516B (zh) * 2017-07-28 2020-08-14 华为技术有限公司 虚拟机密码重置方法、装置和系统
CN108986278B (zh) * 2018-07-13 2022-01-21 深圳市欧瑞博科技股份有限公司 一种智能门锁脱机密码授权方法及授权系统
US20210058395A1 (en) * 2018-08-08 2021-02-25 Rightquestion, Llc Protection against phishing of two-factor authentication credentials
WO2020215083A1 (en) * 2019-04-19 2020-10-22 Coinbase, Inc. Systems and methods for blockchain administration
EP3981007A1 (en) * 2019-06-07 2022-04-13 Koninklijke Philips N.V. Patient sleep therapy mask selection tool
US11228594B2 (en) * 2019-09-17 2022-01-18 Microsoft Technology Licensing, Llc. Automatic reduction of permissions for client applications
US11095440B2 (en) * 2019-11-29 2021-08-17 Verizon Patent And Licensing Inc. Systems and methods for utilizing quantum entropy in single packet authorization for secure network connections
CN113630241B (zh) * 2020-05-09 2023-04-07 杭州海康威视数字技术股份有限公司 密码恢复方法、系统及云服务器和电子设备

Also Published As

Publication number Publication date
CN114902218A (zh) 2022-08-12
WO2021099063A1 (de) 2021-05-27
US20220417749A1 (en) 2022-12-29
EP3825880A1 (de) 2021-05-26
EP3825880B1 (de) 2022-10-05
FI3825880T3 (en) 2023-01-13

Similar Documents

Publication Publication Date Title
ES2805278T3 (es) Inutilizar y bloquear un dispositivo por vía aérea
ES2641439T3 (es) Extracción de archivos de un dispositivo cliente remoto
ES2934874T3 (es) Restablecimiento protegido de un dispositivo de internet de las cosas IdC
EP2915308B1 (en) Communicating state information to legacy clients using legacy protocols
EP2230809A2 (en) Server-controlled heartbeats
KR102111180B1 (ko) 동적 프리젠테이션과 데이터 구성을 사용하여 보안 모바일 협력 애플리케이션을 구축하기 위한 플랫폼
US11902268B2 (en) Secure gateway onboarding via mobile devices for internet of things device management
CN109416713B (zh) 验证系统和非暂态信息记录介质
US20080115141A1 (en) Dynamic resource management
CN104851174B (zh) 一种高可靠性的机房智能门禁开启方法及开启系统
US20090313264A1 (en) Device-side data de-duping
ES2800430T3 (es) Método de detección de tipo de red inalámbrica y dispositivo electrónico
EP3726871A1 (en) Setting a password on a device
US10244392B2 (en) Over-the-air personalization of network devices
CN104094308A (zh) 用于交换医疗数据的移动装置的验证系统
CN104252374A (zh) 基于架构改变的程序管控方法及装置
US10149262B2 (en) Data synchronization across plural terminals by management of parent and child user identification information
KR101954976B1 (ko) 데이터 백업 관리 시스템 및 그 방법
US20190272903A1 (en) Medical record storage with electronic signature
CN112260863A (zh) 组织级别的网络设备连接管理方法、装置和计算机设备
US11902789B2 (en) Cloud controlled secure Bluetooth pairing for network device management
CN103476025A (zh) 进程管理方法及系统、移动终端
JP2016218611A (ja) 情報処理装置、プログラムおよび情報処理システム
ES2932848T3 (es) Procedimiento para regular el acceso a una conexión de datos mediante un dispositivo electrónico
ES2608493T3 (es) Método para la gestión remota de dispositivos móviles y dispositivo móvil adecuado para ello