WO2019063855A1 - Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet - Google Patents

Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet Download PDF

Info

Publication number
WO2019063855A1
WO2019063855A1 PCT/ES2017/070640 ES2017070640W WO2019063855A1 WO 2019063855 A1 WO2019063855 A1 WO 2019063855A1 ES 2017070640 W ES2017070640 W ES 2017070640W WO 2019063855 A1 WO2019063855 A1 WO 2019063855A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication server
internet platform
credentials
client
identifier
Prior art date
Application number
PCT/ES2017/070640
Other languages
English (en)
French (fr)
Inventor
Antonio José LOPEZ NAVARRO
Arsene LAURENT
Javier GARCÍA PUGA
Jorge Antonio RIVERA
José RODRÍGUEZ PÉREZ
Original Assignee
Telefónica Digital España, S.L.U
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 Telefónica Digital España, S.L.U filed Critical Telefónica Digital España, S.L.U
Priority to BR112020006080-1A priority Critical patent/BR112020006080A2/pt
Priority to PCT/ES2017/070640 priority patent/WO2019063855A1/es
Priority to EP17926443.7A priority patent/EP3681185A4/en
Publication of WO2019063855A1 publication Critical patent/WO2019063855A1/es

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication

Definitions

  • the present invention relates, generally, to the identification and secure authentication of devices.
  • the present invention provides a method, and a communication server, for secure identification and authentication of a device to an internet platform, employing network capabilities of a mobile communications operator.
  • the invention also provides routing capabilities of a data to different internet platforms without the need to make changes in the firmware of the devices.
  • an intermediate debugging point is also offered, which allows guaranteeing where there is an integration or operation problem and the capacity of enrichment of the data sent by the device with information known by the network.
  • the present invention is based on the concept of "Border Computing" (described in the paper published by IEEE with INSPEC Accession Number: 14916986) by processing data acquired by devices, in particular loT devices, at an intermediate stage in terms of network regarding an internet platform, or loT platform.
  • loT imposes a communication model that relies heavily on cloud computing (described in the paper published by IEEE with INSPEC Accession Number: 14986379) in some cases due to the relatively low processing and storage capacity of the final devices, and in others, in order to simplify the configuration, increase usability and make the most of the ubiquity of users in a technological approach that tends to become more widespread.
  • Fig. 1 shows a basic scheme of an architecture based on cloud computing.
  • IPv4 The exhaustion of the address space in the IPv4 scheme is an example that any limit can be exceeded. While with IPv6 precautions were taken so that the limit was much more difficult to overcome, the solution to the problem, at least the one that is more in use, was the translation of private addresses to public and vice versa (NAT, for its acronym in English ).
  • NAT for its acronym in English
  • an intermediary node of the network is responsible for pre-processing the headers of IP traffic to alleviate the pressure on the demand and consequent allocation of the increasingly scarce universe of available addresses.
  • Availability. - Internet works under the application in layers of several services in the "best effort" mode, that is, without guarantees regarding the level of service, so it is not 100% stable or reliable in terms of transport. This means that devices will inevitably find situations in which they will lose connectivity to the internet platform.
  • An architecture based on Fog Computing allows each loT device to cope with this situation. Having a data treatment at the border allows for greater resilience to the solution.
  • This need has historically meant a barrier to entry to cloud-based services.
  • the main methods currently used are in line with the methods used on the Internet, mainly symmetric encryption (using keys or shared secrets) or asymmetric (using X.509 certificates), all under a secure transport layer such as TLS .
  • TLS secure transport layer
  • the provision of these identities (shared key or digital certificate) in the different devices is a complicated process that in many occasions is carried out by means of a particularization of the firmware of each device or a manual provision. This process ultimately translates into an increase in costs, both of the device (more powerful HW is required to store the credentials securely and implement the TLS algorithms) and in manufacturing (individual customization stage by device to provide the credential) individual).
  • identity management is performed many times in the loT platform, for example by revoking device credentials. This assures us that the device does not have access to the platform, but in no case does it prevent the possibility of making connections to the mobile network and that it continues transmitting without control.
  • a typical architecture to develop a loT solution is to connect the devices to an Internet platform that facilitates the integration of the devices, providing device and data management services.
  • LoT solutions typically address needs in a mass market, hence the total cost of the solution, and therefore the degree of penetration in the market, depends to a large extent on the cost of loT devices.
  • the objects that happen to be connected normally have a limited space for the components that will add the connectivity and local processing which imposes limitations on the components to be selected since usually each independent functionality (GeoLocation module, Clock , etc.) takes up space and adds an incremental cost to the solution.
  • GaoLocation module, Clock , etc. takes up space and adds an incremental cost to the solution.
  • aspects of the present invention provide a method for secure identification and authentication of a device, such as a loT device, to an internet platform, preferably hosted in the cloud.
  • the method includes:
  • e1 send, by the communications server, the credentials to the device so that the latter sends said information collected from the physical object to the internet platform, where the credentials are used for authentication of the device before the internet platform;
  • step e2) sending, by the communications server, using said credentials and the identifier of the device, the information collected from the physical object together with the network information obtained in step c), to the internet platform.
  • the request received by the communication server is to establish a connection with a plurality of internet platforms, wherein the method comprises in step e) extracting the client credentials used in each of said plurality of internet platforms; and performing step e2) simultaneously for each of the plurality of internet platforms.
  • the method further comprises receiving, by the communication server, the device, a request to establish a connection with another internet platform; and perform step e2) for the other internet platform.
  • step c) further comprises adding the extracted network information to the information collected from the physical object.
  • the communication server prior to step a), receives a text message that includes a one-time key (or token) with a private numbering assigned to the communication server and an identifier of said client, and validates the origin and the client of the text message. If the origin corresponds to the client, the communications server obtains the credentials of the internet platform and stores them temporarily associated with the one-time password and with the customer's identifier, so that the request of stage a) in this The case also includes the one-time password and the customer's identifier.
  • the communication server returns the stored credentials if the single-use key and the client identifier received in the request match the single-use key and the client identifier associated with the stored credentials or alternatively send an error message to the device in case they do not match.
  • the aforementioned error message may comprise an indication that the authentication of the device is valid but the credentials are not yet available or an indication that the authentication of the device is not valid.
  • the network information extracted in step c) may include: the unique identifier of the device SIM card, a customer international identity number (IMSI), an international identity number of the device such as the number IMEI or the MSISDN number, the make and / or model of the device, a location of the network-based device, etc.
  • IMSI customer international identity number
  • MSISDN number international identity number of the device
  • the make and / or model of the device a location of the network-based device, etc.
  • aspects of the present invention also provide a communication server for secure identification and authentication of a device to an internet platform.
  • the proposed communication server comprises:
  • an authentication module configured to obtain, once received, a device, preferably a loT device, a request to establish a connection with at least one internet platform, an IP address of said device and validate that the IP address is assigned to a client of the communication server, wherein the device collects information from a physical object acquired by one or more sensors;
  • a connectivity management module configured to verify, using the IP address, that the device is a legitimate device and to return an identifier of the device in case this is a legitimate device;
  • a data enrichment module configured to extract network information from the device from the IP address
  • a credential repository configured to store client credentials on the internet platform
  • a protocol adapter module configured to extract said credentials from the client and to send them to the device so that the latter sends said information collected from the physical object to the internet platform or to send, using the credentials and the identifier of the device, the information compiled from the physical object together with the network information obtained from the internet platform.
  • said protocol adapter module is modular and configured to allow a connection of the device to a plurality of internet platforms.
  • the present invention allows to obtain a lower cost in the development of the end2end solution. Thanks to the simplification of the provision processes, eliminating the need of distributing individual credentials to each device, the invention allows all devices to share the same firmware and it is not necessary to particularize them.
  • the invention makes a lower consumption of data, since it is not necessary to establish an additional secure transport layer between devices and server, since the one provided by the mobile network is used, thus avoiding having to implement the SSL / TLS handshake, and a lower power consumption, which means a longer battery life of the device, by not having to execute encryption algorithms (SSL / TLS) and reduce the number of data sent wirelessly.
  • the invention also reduces the number of security errors.
  • the loT solution provider is released from performing many of the critical processes for the security of the solution (eg identity bootstrapping, authentication token choice, or credential rotation), a misconfiguration that compromises is less likely to occur. the solution.
  • Fig. 1 schematically shows an architecture based on cloud computing.
  • Fig. 2 schematically shows the elements of the communication server for identification and secure authentication of a device to an internet platform, according to a first embodiment of the present invention.
  • FIG. 3 schematically shows the architecture used by the method and communication server proposed according to a second embodiment of the present invention.
  • Fig. 4 schematically shows the architecture used by the communication method and server proposed according to a third embodiment of the present invention.
  • the present invention provides identification and secure authentication of loT 100 devices to connect to Internet platforms, or loT, 300 platforms generally located in the cloud, employing network capabilities of a mobile communications operator.
  • the present invention is located in the network layer ("Network Layer"), within network capabilities ("Network Capabilities”), serving as a link with the service and application support layer ("Service support and Application support layer”).
  • Network Layer network layer
  • Network Capabilities serving as a link with the service and application support layer
  • Routing information to different internet platforms 300 the invention provides a routing point, through a communications server 200, to different internet platforms 300. In this way, it allows the user to perform a single simple integration as the devices 100 are authenticated by the information available on the network and the provision of credentials is not necessary.
  • the invention allows the authentication credentials to be managed outside the device 100 with the internet platform 300, so that all devices 100 can share the same factory firmware and no processes are necessary identity provision manuals.
  • the invention allows enriching the information provided by the device 100 in the internet platform 300 with network information such as ICCID, MSISDN or IMEI of the device 100.
  • network information such as ICCID, MSISDN or IMEI of the device 100.
  • the software of the device 100 selects the internet platform 300 to which it sends the data and has both the destination server and the credentials to be used with it.
  • This situation limits the possibility of migration between providers of internet platforms 300, since despite using common protocols (MQTT, HTTP), they use different authentication methods that make it impossible for the provider of a loT solution to migrate between platforms without having that significantly modify the firmware of all your devices.
  • loT solutions based on non-IP LPWA connectivity such as SIGFOX or LORA, by not supporting in the device 100 the possibility of integration with most internet platforms 300, offer in the infrastructure of the communications operator the possibility of routing the data to one or another platform.
  • loT solutions that use 2G, 3G, 4G cellular connectivity and that have IP connectivity, there is no mechanism in the communications operator infrastructure to select the destination loT platform.
  • the invention allows the solution provider to integrate its devices 100 with only the communications server 200.
  • the provider of the solution loT can use a communication interface of the communication server 200 to be able to route the information of your devices 100 to the internet platform 300 that you consider.
  • the devices 100 use a standard protocol (MQTT, HTTP) but without having to use specific credentials of the destination internet platform 300.
  • MQTT standard protocol
  • HTTP HyperText Transfer Protocol
  • the loT solution provider can select one or more target internet platforms 300, without having to make any changes to the software of its 100 devices.
  • the incorporation of new 300 internet platforms or changes in the current ones it will also be carried out centrally without the need for changes in the devices.
  • Provision of identity token the distribution of these identity tokens is another delicate process beyond the reach of internet platforms 300 and that is a critical design decision for the provider of the loT solution. This often causes the identity token to be manually provisioned in the device 100, stored in it in an unsafe manner or even stored in a permanent storage that does not allow its rotation in case it is suspected or known that the token Identity has been compromised.
  • the invention allows the provider of a loT solution not to have to undertake the generation and provisioning processes of the identity token. Not only reducing the effort devoted to these operations of interaction with the device 100 but also avoiding the security risks associated with an insecure execution thereof.
  • the solution provider does not need to generate an identity token per device 100 that is dependent on the destination internet platform 300 because the identity is used in the cellular network of the device 100.
  • the GGSN of the cellular network assigns it an IP address.
  • the communication provider knows at all times the identity in the cellular network (MSISDN, IMSI), the identity of the device used (IMEI) and the identity of the SIM card used (ICCD) for this data context. In this way, starting from the originating IP address of the device 100, the communications provider can know the network identity of the device 100 and in this way translate it into the appropriate identity in the internet platform 300 destination selected by the provider of the loT solution. In order to carry out this translation it is necessary that the communication server 200 has access to the network signaling information as well as the connection credentials with the destination internet platform 300 that allows the management of device identities 100.
  • the invention is not vulnerable to the IP spoofing techniques since in a cellular network the GGSN, although a device 100 modifies its IP address and sends the packets with a different address than the one assigned, the packets will never be sent to it. back to malicious device 100. It always raises the use of protocols that need connection (HTTP, MQTT) so the handshake phase can not be completed in case of IP spoofing.
  • the devices 100 should incorporate, if necessary for the application, information about the cellular network and about the network parameters of the device 100. This implies communication between the device software and the communications module, which is not always easy to obtain.
  • the invention allows the provider of a loT solution not to have to undertake the development in the software of the device 100 necessary to obtain this information from the communication module. Additionally, the sending of this information from the device 100 implies an additional consumption of data and therefore of battery that is not necessary thanks to the invention.
  • This improvement is particularly interesting in case it is necessary to use the network information to obtain the final information, for example, in the case of resolving the location, it is necessary to use the LAC and CellID that knows the communications module and consult a additional service from a third party to solve it. The same case is necessary when you want to resolve the name of the manufacturer of the module and the model from the IMEI.
  • the communications server 200 consists mainly of of:
  • a protocol adapter module 204 This element is responsible for making the connection to the internet platform 300 and sending the data received from the device 100. It is noteworthy that this element absorbs the complexity and evolution of the destination platform APIs 300, freeing the device 100 from making software updates to adapt to them. The main task of which is responsible is to handle the authentication with the internet platform 300 of destination, in this way in case of requiring a complex encryption or mutual authentication based on X.509 digital certificates, the device 100 should not worry about it . This entails a significant reduction in the capacity of the necessary hardware resources in the device 100 and in the consumption of data that the device must send to perform, for example, a TLS handshake.
  • the protocol adapter 204 is capable of changing the destination internet platform 300 transparently for the device 100, as well as sending the data to various platforms 300 simultaneously with a single sending of information by the device 100.
  • This module 204 is preferably modular, in this way it allows the connection to different providers of internet platform 300 with different relevant protocols such as HTTP, MQTT and COAP.
  • the credentials employed in the connection to the internet platform 300 will be taken from a credential repository 205 of the communication server 200.
  • a data enrichment module 203 This element is responsible for expanding the information sent by the device 100 with data available in the network such as: ICCID of the SIM card, IMSI, IMEI of the device 100, make and model of the device 100 or location based on network, etc. This information is available in a connectivity management module 202 and can be consulted from the IP received from the device 100.
  • An authentication module 201 (network): This element is responsible for verifying the identity of the device 100 and allowing its connection for sending data to the internet platform 300. This element uses the IP received in the request sent by the device 100 and consult connectivity management module 202. Authentication will be successful as long as connectivity management module 202 recognizes the IP of device 100 as valid for the client.
  • Credential Repository 205 This element is responsible for maintaining the relationship between the network identity of the device 100 known to the connectivity management module 202 and the identity assigned by the client in the internet platform 300.
  • ⁇ Management module for connectivity 202 This element is responsible for managing the life cycle of the connectivity of the device 100 and knows all the network information related thereto such as: assigned IP, ICCID of the SIM card, IMSI, IMEI of the device 100, brand and model of the device or location of the same based on network. You must allow a query of this network information from the IP address assigned to the device 100.
  • the device 100 is a device of the client of the communication server 200 that is responsible for collecting information of an object to which it is connected (for example, a vehicle, a washing machine or a locator, among others) from sensors and certain processing capacity to send them to the internet platform 300. Additionally, the device 100 can have acting capabilities that allow it to perform certain actions on the connected object, receiving commands from the internet platform 300.
  • the device 100 has a mobile communications module that uses an ICC card as a mechanism for authenticating the client with the network and which is known by the connectivity management module 202 in the process of connection to it.
  • this element is responsible for storing the data collected by the device 100 and offering it to an application 301.
  • This element maintains an identity of the device 100 for which it offers individual credentials that are stored in the device. credential repository 205.
  • the application 301 is responsible for representing the client the information gathered by the device 100 on the internet platform 300 and for generating the action commands on it.
  • the data transmission flow from the device 100 to the internet platform 300 is as follows.
  • the device 100 sends a request to the authentication module 201 without any authentication credentials through a mobile or cellular network.
  • the authentication module 201 obtains the IP address of the received request and consults the connectivity management module 202 to validate that that IP address has been assigned by the cellular network to a client device 100.
  • the management module of connectivity 202 from the IP address consulted, confirms that the request is from a legitimate device 100 and returns an identifier of the device 100 (for example the IMSI of the ICC of device 100). Otherwise, it will return an error and the request will not progress.
  • the authentication module 201 progresses the request of the device 100 to the data enrichment module 203 and it requests the connectivity management module 202 the available network information of that device 100 such as: ICCID of the SIM card, IMSI, IMEI of the device, brand and model of the device or location of the same based on network.
  • the data enrichment device 203 progresses the request of the device 100 enriched with the network information obtained to the protocol adapter module 204, which adapts the request to the destination protocol of the internet platform 300.
  • the protocol adapter module 204 consults the credentials repository 205 to obtain the credentials appropriate to the destination protocol together with the identity of the device 100 on the platform 300.
  • the adapter module 204 In case this information does not exist locally, the adapter module 204 must be able to interact with the internet platform 300 to register the device. 100 or retrieve them if you are already registered.
  • the protocol adapter module 204 sends the data of the device 100 along with the network information of the data enrichment module 203 and the appropriate credentials to the internet platform 300.
  • the application 301 retrieves the data from the internet platform 300 and presents them in a way that is appropriate for the end user.
  • Fig. 3 there is shown a second embodiment of the invention.
  • the communications server is used as a credential broker.
  • the device 100 maintains the direct connection to the internet platform 300, using a service displayed by the communications server 200 to obtain the credentials in said internet platform 300 using for this the identification and authentication provided by the net.
  • the authentication module 201 after obtaining and validating the identity and authentication through the connectivity module 202 in a manner analogous to the previous embodiment, obtains the credentials for said device 100 in the internet platform 300 through the protocol adapter module 204 and provides them to the device 100 for later use.
  • the device 100 in case of authentication error in its communication with the platform 300, will initiate a new request to the authentication module 201 to renew its credentials.
  • the main objective of the present invention is also achieved, displaying a single factory firmware on all devices 100, and avoid the subsequent manual installation of the certificates necessary for secure communication with the chosen internet platform 300.
  • This alternative allows to maintain a direct connection, without intermediate points, between the device 100 and the internet platform 300, which reduces the complexity in the operation. Also, the encryption of the communication is implemented end-to-end from the device 100 to the platform 300.
  • the connection of the device 100 with the internet platform 300 requires minimum computing capabilities for the encryption of the communication on the side of the device 100, which leaves many devices 100 out of range. low cost used in a wide range of use cases, as is the case of smart meters. Also, the use of end-to-end encryption from the device 100 requires a higher consumption of mobile bandwidth, as well as a shorter battery life. If the user wishes to change the internet platform 300, it is necessary to reprogram the device 100 with the interface of the new internet platform 300 in the event that standard APIs are not used in them. This alternative does not allow to automatically enrich the information sent to the internet platform 300 with network information.
  • the communication server is used as a credential broker with authentication of a text message.
  • the device 100 continues to maintain a direct connection to the internet platform 300, including in this case the communication server 200 to an SMS service module 206 to identify and authenticate the device 100 prior to obtaining the credentials in the internet platform. 300.
  • the device 100 sends a text message, preferably an SMS message, through the SMS service module 206 including as content a temporary one-time token (or one-time use key), as well as a identifier of the client in the connectivity management module 202 and a private numbering (shortcode) assigned to the communications server 200.
  • a text message preferably an SMS message
  • the SMS service module 206 including as content a temporary one-time token (or one-time use key), as well as a identifier of the client in the connectivity management module 202 and a private numbering (shortcode) assigned to the communications server 200.
  • the token contained in the SMS message preferably has a minimum number of characters to avoid collisions between requests of different devices 100, it is temporary, with a duration of a few minutes, and of a single use.
  • the SMS service module 206 routes the received message (including the content and origin thereof) to the authentication module 201, validating the origin and client in the connectivity management module 202 in a manner analogous to the cases described above. If the origin belongs to the customer's inventory, it obtains the credentials in the internet platform 300 and the stores temporarily associated with the token generated by the device 100 and the identifier of the client contained in the SMS message. After an established waiting time, the device 100 makes an HTTPS request for downloading the credentials in the internet platform 300, including in said request the token and the client identifier. If the credentials exist for said pair, they are returned in the HTTPS request. Otherwise, the following error codes may be returned: o Valid authentication process, but credentials not yet available: 404 Not Found
  • the device 100 in case of authentication error in its communication with the internet platform 300, will initiate a new process for the renewal of its credentials following the steps mentioned above.
  • This third embodiment is based on standard functionalities of the mobile network, since it is based on the authentication of the SMS service module 206 instead of on the network authentication procedures owned by each operator: identification through the private IP of the operator. device 100 in the cellular network or addition of HTTP headers by transparent proxies. Likewise, problems with the NATs are eliminated, which in some cases of use can hide the private IP of the device 100, preventing its identification in the authentication module 201.
  • the validation via the SMS service module 206 introduces an asynchronous communication, requiring a variable waiting time prior to the recovery of the credentials by the device 100. This forces to configure in the device 100 a waiting time greater than estimated, and to schedule recovery procedures in case the credentials are not available during that time. Similarly, there is no confirmation to the device 100 of the authentication process initiated with the SMS message.
  • the device 100 can only check the status of the authentication by means of the HTTPS query to the authentication module 201 that will return the credentials when it has finished. Confirmation of the authentication process could be enabled with a return SMS message originating in the authentication module 201 to the device 100, including the token, client identifier and authentication result as content.

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)

Abstract

Método y servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet, El método comprende realizar por un servidor de comunicaciones (200): recibir, de un dispositivo (100), una petición para establecer una conexión con al menos una plataforma de internet (300), en donde dicho dispositivo (100) recopila información de un objeto físico; obtener una dirección IP del dispositivo (100) y validarla devolviendo un identificador del dispositivo (100); extraer información de red del dispositivo (100); extraer unas credenciales del cliente en la plataforma de internet (300); y enviar dichas credenciales al dispositivo (100) para que este último envíe dicha información recopilada del objeto físico a la plataforma de internet (300) o enviar, utilizando dichas credenciales y el identificador del dispositivo (100), la información recopilada del objeto físico junto con la información de red obtenida a la plataforma de internet (300).

Description

Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet
Campo de la técnica
La presente invención concierne, generalmente, a la identificación y autenticación segura de dispositivos. En particular, la presente invención proporciona un método, y un servidor de comunicaciones, para identificación y autenticación segura de un dispositivo a una plataforma de internet, empleando capacidades de red de un operador de comunicaciones móviles. La invención también proporciona capacidades de encaminamiento de un dato a diferentes plataformas de internet sin necesidad de realizar cambios en el firmware de los dispositivos. Adicionalmente, también se ofrece un punto de depuración intermedio que permite garantizar dónde existe un problema de integración u operación y la capacidad de enriquecimiento de los datos enviados por el dispositivo con información conocida por la red.
Antecedentes de la invención
La presente invención se basa en el concepto de "Computación de Frontera" (descrita en el paper publicado por IEEE con INSPEC Accession Number: 14916986) mediante el procesamiento de datos adquiridos por dispositivos, en particular dispositivos loT, en una etapa intermedia en términos de red respecto a una plataforma de internet, o plataforma loT. loT impone un modelo comunicacional que se apoya con fuerza en la computación en la nube (descrita en el paper publicado por IEEE con INSPEC Accession Number: 14986379) en algunos casos debido a la relativamente baja capacidad de procesamiento y almacenamiento de los dispositivos finales, y en otros con el fin de simplificar la configuración, aumentar la usabilidad y sacar el mayor provecho de la ubicuidad de los usuarios en un enfoque tecnológico que tiende a masificarse.
La Fig. 1 muestra un esquema básico de una arquitectura basada en computación en la nube.
Algunos desafíos se presentan en la medida que esta tendencia inunda las redes de comunicaciones con dispositivos loT de una manera muy acelerada. A continuación se presenta el estado del arte respecto a algunos de los desafíos más importantes.
Capacidad.- El agotamiento del espacio de direcciones en el esquema IPv4 es un ejemplo de que todo límite puede superarse. Si bien con IPv6 se tomaron precauciones para que el límite fuese mucho más difícil de superar, la solución al problema, al menos la que está más en uso, fue la traducción de direcciones privadas a públicas y viceversa (NAT, por sus siglas en inglés). En este esquema un nodo intermediario de la red es responsable de pre-procesar las cabeceras del tráfico IP para aliviar la presión en la demanda y consiguiente asignación del cada vez más escaso universo de direcciones disponibles.
Disponibilidad. - Internet funciona bajo la aplicación en capas de varios servicios en modalidad "mejor esfuerzo", es decir sin garantías en cuanto al nivel de servicio, por lo que no es 100% estable ni confiable en cuanto a transporte se refiere. Esto significa que inevitablemente los dispositivos loT encontrarán situaciones en las que perderán conectividad con la plataforma de internet. Una arquitectura basada en Fog Computing permite que cada dispositivo loT pueda hacer frente a esta situación. El disponer de un tratamiento de los datos en la frontera permite brindar mayor resiliencia a la solución.
Confidencialidad. -
Esta necesidad ha significado históricamente una barrera de entrada a los servicios basados en la nube.
Integridad. -
El implementar cualquier sistema de intermediación exige verificar que la integridad de los datos se mantenga ante la pérdida, o posible modificación no deseada, de los datos. En este caso la confianza se depositaría en el operador móvil y se puede verificar utilizando mecanismos de chequeo extremo a extremo o mecanismos basados en Blockchain.
Interoperabilidad.-
La flexibilidad a la hora de seleccionar distintos despliegues de sistemas, de red, de componentes, de plataformas de internet, etc. es crítica para la sostenibilidad de cualquier solución loT por lo que es importante que las implementaciones se basen en arquitecturas y estándares abiertos. Para esto se creó el Consorcio OpenFog con la misión de desarrollar y evolucionar una arquitectura de referencia que permita aprovechar al máximo las posibilidades que ofrece este paradigma computacional. nvención resuelve entre otros los siguientes problemas: - Problemas actuales en los mecanismos de provisión de Identidad y autenticación de dispositivos:
Las mejores prácticas en seguridad loT aplicadas a dispositivos indican la necesidad de disponer de credenciales individuales por dispositivo, de manera que si en algún momento una determinada credencial es comprometida, ésta no pondrá en riesgo la integridad del resto de dispositivos desplegados en campo.
Los principales métodos utilizados en la actualidad están en línea con los métodos utilizados en Internet, principalmente cifrado simétrico (mediante claves o secretos compartidos) o asimétrico (mediante la utilización de certificados X.509), todo ello bajo una capa de transporte segura como TLS. La provisión de estas identidades (clave compartida o certificado digital) en los diferentes dispositivos es un proceso complicado que en muchas ocasiones se realiza mediante una particularización del firmware de cada dispositivo o una provisión manual. Este proceso al final se traslada en un incremento de costes, tanto del dispositivo (se requiere HW más potente capaz de almacenar las credenciales de forma segura e implementar los algoritmos TLS) como en la fabricación (etapa de personalización individual por dispositivo para provisionar la credencial individual).
Por otro lado, la gestión de identidad se realiza en muchas ocasiones en la plataforma loT, por ejemplo revocando credenciales del dispositivo. Esto nos asegura que el dispositivo no tiene acceso a la plataforma, pero en ningún caso impide la posibilidad de realizar conexiones a la red móvil y que siga transmitiendo sin control.
- Problemas relacionados con el consumo de datos, energía y computación relacionado con los mecanismos de autenticación de dispositivos:
Tal como se ha visto en el apartado anterior, los principales métodos utilizados en la actualidad están en línea con los métodos utilizados en Internet, como por ejemplo, capa de transporte TLS con certificados X.509 para autenticación. La implementación de estos mecanismos de seguridad tiene un fuerte impacto en el diseño y desarrollo del dispositivo:
• Impacto en capacidad computacional. La implementación de algoritmos de seguridad tipo SSL o TLS, incluyendo la gestión de claves, requiere que el dispositivo sea más complejo y potente, pues es necesario ejecutar estos procesos que suelen ser bastante intensivos en el uso de CPU y memoria.
• Impacto en la transmisión de datos. Antes de iniciar una transmisión de datos "útiles", es necesario realizar una serie de diálogos (handshakes) encargados de securizar la comunicación mediante autenticación mutua. En un caso típico de TLS v.1.2 con certificados X.509, la realización de este tipo de handshake puede requerir la transmisión de 7 Kbytes de datos, independientemente del payload útil que luego se quiera transmitir. Por ejemplo, si luego únicamente se quiere enviar el dato de una temperatura en formato json ("{ temp: 35}"), se estaría hablando de un ratio de 10/(7*1024)=0, 001 de mensaje útil vs tamaño total de mensaje.
• Impacto en el consumo de energía. Tanto la ejecución de algoritmos de cierta complejidad (ej. TLS) como la de transmisión de datos de manera inalámbrica, tienen un fuerte impacto en consumo de energía del dispositivo.
- Problemas actuales en la Integración de Plataformas de Internet:
Por lo general, una arquitectura típica para desarrollar una solución loT consiste en conectar los dispositivos a una plataforma de Internet que facilite la integración de los dispositivos, proporcionando servicios de gestión de dispositivos y datos.
Como a día de hoy no hay una estandarización de protocolos (incluyendo payload), este tipo de integraciones puede presentar una serie de desventajas:
• En muchos casos las plataformas de Internet no son capaces de ofrecer información de si los dispositivos están enviando datos a un endpoint incorrecto o tienen errores en el establecimiento de conexión. Esto dificulta el proceso de integración de dispositivos en las mismas.
• La posible necesidad de migración entre una plataforma de Internet de un proveedor a otra es un proceso complejo que implica la provisión de nuevas credenciales por dispositivo y la implementación de una nueva integración con los protocolos disponibles en esa plataforma.
- Problemas relacionados con la complejidad, tamaño y coste, de los Dispositivos loT: Las soluciones loT típicamente atienden necesidades en un mercado de masas, de ahí que el coste total de la solución, y por lo tanto el grado de penetración en el mercado, dependa en gran medida del coste de los dispositivos loT. De igual manera, los objetos que pasan a estar conectados normalmente disponen de un espacio limitado para los componentes que añadirán la conectividad y procesamiento local lo cual impone limitaciones en los componentes a ser seleccionados pues por lo general cada funcionalidad independiente (módulo de GeoLocalización, Reloj, etc.) ocupa espacio y añade un coste incremental a la solución. - Problemas relacionados a la gestión y mantenimiento de los Dispositivos loT:
La cardinalidad y simplicidad (por diseño) de los dispositivos loT en una solución representa normalmente un desafío importante respecto a la gestión y mantenimiento de los mismos. Es normal encontrar soluciones en las que el firmware sea inmutable o muy difícil de actualizar y por lo tanto complicado y hasta imposible corregir errores en el mismo o añadir nuevas funcionalidades por la dificultad que implica realizar actualizaciones remotas. Normalmente es inviable (muy costoso e impráctico) enviar a un técnico a realizar el trabajo a cada dispositivo o que el operador de la solución lo lleve o envíe a un centro de soporte o realice la actualización de forma desasistida. Exposición de la invención
Aspectos de la presente invención proporcionan un método para identificación y autenticación segura de un dispositivo, tal como un dispositivo loT, a una plataforma de internet, preferiblemente alojada en la nube. El método comprende:
a) recibir, por un servidor de comunicaciones, del citado dispositivo, una petición para establecer una conexión con la citada plataforma de internet, en donde el dispositivo, que incluye un módulo de comunicaciones móviles, está asociado a un cliente del servidor de comunicaciones mediante un identificador único de una tarjeta SIM, y recopila información de un objeto físico adquirida por uno o más sensores, y en donde el servidor de comunicaciones está operativamente conectado con la plataforma de internet;
b) obtener, por el servidor de comunicaciones, una dirección IP de dicho dispositivo y validar que dicha dirección IP está asignada al cliente en el servidor de comunicaciones, devolviendo en caso que la validación sea correcta un identificador del dispositivo; c) extraer, por el servidor de comunicaciones, información de red del dispositivo a partir de la dirección IP;
d) extraer, por el servidor de comunicaciones, unas credenciales del cliente en la plataforma de internet; y
e1) enviar, por el servidor de comunicaciones, las credenciales al dispositivo para que este último envíe dicha información recopilada del objeto físico a la plataforma de internet, en donde las credenciales son utilizadas para autentificación del dispositivo ante la plataforma de internet; o
e2) enviar, por el servidor de comunicaciones, utilizando dichas credenciales y el identificador del dispositivo, la información recopilada del objeto físico junto con la información de red obtenida en el paso c), a la plataforma de internet.
En un ejemplo de realización, la petición recibida por el servidor de comunicaciones es para establecer una conexión con una pluralidad de plataformas de internet, en donde el método comprende en la etapa e) extraer las credenciales del cliente utilizadas en cada una de dicha pluralidad de plataformas de internet; y realizar la etapa e2) simultáneamente para cada una de la pluralidad de plataformas de internet.
En un ejemplo de realización, el método comprende además recibir, por el servidor de comunicaciones, del dispositivo, una petición para establecer una conexión con otra plataforma de internet; y realizar la etapa e2) para la otra plataforma de internet. En un ejemplo de realización, la etapa c) comprende además añadir la información de red extraída a la información recopilada del objeto físico.
En aún otro ejemplo de realización, el servidor de comunicaciones, previamente a la etapa a), recibe un mensaje de texto que incluye una clave de un solo uso (o token) con una numeración privada asignada al servidor de comunicaciones y un identificador de dicho cliente, y valida el origen y el cliente del mensaje de texto. Si el origen corresponde al cliente, el servidor de comunicaciones obtiene las credenciales de la plataforma de internet y las almacena temporalmente asociadas con la clave de un solo uso y con el identificador del cliente, de manera que la petición de la etapa a) en este caso incluye además la clave de un solo uso y el identificador del cliente. El servidor de comunicaciones devuelve las credenciales almacenadas si la clave de un solo uso y el identificador del cliente recibidos en la petición coinciden con la clave de un solo uso y con el identificador del cliente asociados a las credenciales almacenadas o alternativamente envía un mensaje de error al dispositivo en caso que no coincidan. El citado mensaje de error puede comprender una indicación que la autenticación del dispositivo es válida pero las credenciales no están aún disponibles o una indicación que la autenticación del dispositivo no es válida.
Según la presente invención, la información de red extraída en la etapa c) puede incluir: el identificador único de la tarjeta SIM del dispositivo, un número de identidad internacional del cliente (IMSI), un número de identidad internacional del dispositivo tal como el número IMEI o el número MSISDN, la marca y/o modelo del dispositivo, una localización del dispositivo basada en red, etc.
Aspectos de la presente invención proporcionan también un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet. El servidor de comunicaciones propuesto comprende:
un módulo de autenticación configurado para obtener, una vez recibida, de un dispositivo, preferiblemente un dispositivo loT, una petición para establecer una conexión con al menos una plataforma de internet, una dirección IP de dicho dispositivo y validar que la dirección IP está asignada a un cliente del servidor de comunicaciones, en donde el dispositivo recopila información de un objeto físico adquirida por uno o más sensores;
un módulo de gestión de conectividad configurado para verificar, utilizando la dirección IP, que el dispositivo es un dispositivo legítimo y para devolver un identificador del dispositivo en caso que este sea un dispositivo legítimo;
un módulo enriquecedor de datos configurado para extraer información de red del dispositivo a partir de la dirección IP;
un repositorio de credenciales configurado para almacenar unas credenciales del cliente en la plataforma de internet; y
un módulo adaptador de protocolos configurado para extraer dichas credenciales del cliente y para enviarlas al dispositivo para que este último envíe dicha información recopilada del objeto físico a la plataforma de internet o para enviar, utilizando las credenciales y el identificador del dispositivo, la información recopilada del objeto físico junto con la información de red obtenida a la plataforma de internet.
En un ejemplo de realización, el citado módulo adaptador de protocolos es modular y está configurado para permitir una conexión del dispositivo con una pluralidad de plataformas de internet.
La presente invención permite obtener un menor coste en el desarrollo de la solución end2end. Gracias a la simplificación de los procesos de provisión, eliminando la necesidad de distribuir credenciales individuales a cada dispositivo, la invención permite que todos los dispositivos compartan el mismo firmware y no sea necesario particularizarlos.
Asimismo, la invención realiza un menor consumo de datos, al no ser necesario establecer una capa de transporte segura adicional entre dispositivos y servidor, pues se utiliza la proporcionada por la red móvil, evitando así tener que implementar el handshake SSL/TLS, y un menor consumo de potencia, lo que supone una mayor duración de la batería del dispositivo, al no tener que ejecutar algoritmos de encriptación (SSL/TLS) y reducirse el número de datos enviados inalámbricamente.
Finalmente, la invención permite reducir también el número de errores de seguridad. Al liberarse al proveedor de la solución loT de realizar muchos de los procesos críticos para la seguridad de la solución (ej. bootstrapping de la identidad, elección del token de autenticación o rotado de credenciales) es menos probable que se produzca una mala configuración que comprometa la solución.
Breve descripción de los dibujos Las anteriores y otras características y ventajas se comprenderán más plenamente a partir de la siguiente descripción detallada de unos ejemplos de realización, meramente ilustrativa y no limitativa, con referencia a los dibujos que la acompañan, en los que:
La Fig. 1 muestra esquemáticamente una arquitectura basada en computación en la nube.
La Fig. 2 muestra esquemáticamente los elementos del servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet, según un primer ejemplo de realización de la presente invención.
La Fig. 3 muestra esquemáticamente la arquitectura utilizada por el método y servidor de comunicaciones propuestos según un segundo ejemplo de realización de la presente invención. La Fig. 4 muestra esquemáticamente la arquitectura utilizada por el método y servidor de comunicaciones propuestos según un tercer ejemplo de realización de la presente invención.
Descripción detallada de la Invención y de unos ejemplos de realización La presente invención proporciona identificación y autenticación segura de dispositivos loT 100 para conectarse a plataformas de Internet, o plataformas loT, 300 generalmente localizadas en la nube, empleando capacidades de red de un operador de comunicaciones móviles. Dentro de la arquitectura típica de loT, utilizando como modelo de referencia el propuesto en la Recomendación ITU-T Y.2060, figura 4, la presente invención se sitúa en la capa de red ("Network Layer"), dentro de capacidades de red ("Network Capabilities"), sirviendo como enlace con la capa de soporte a servicios y aplicaciones ("Service support and Application support layer"). La invención ofrece tres funcionalidades principales:
• Enrutamiento de la información a diferentes plataformas de internet 300: la invención proporciona un punto de enrutamiento, a través de un servidor de comunicaciones 200, a diferentes plataformas de internet 300. De esta forma, permite al usuario realizar una única integración sencilla pues los dispositivos 100 se autentican mediante la información disponible en la red y no es necesaria la provisión de credenciales.
• Gestión de credenciales de autenticación de plataformas de internet 300: la invención permite gestionar fuera del dispositivo 100 las credenciales de autenticación con la plataforma de internet 300, de forma que todos los dispositivos 100 pueden compartir el mismo firmware de fábrica y no son necesarios procesos manuales de provisión de identidad.
• Enriquecimiento de la información con información de red: la invención permite enriquecer la información que provisiona el dispositivo 100 en la plataforma de internet 300 con información de red como ICCID, MSISDN o IMEI del dispositivo 100. - Enrutamiento de la información a diferentes plataformas de internet:
Actualmente, desde la fase de diseño, el software del dispositivo 100 selecciona la plataforma de internet 300 a la que envía los datos y tiene fijado tanto el servidor destino como las credenciales que debe emplear con éste. Esta situación limita la posibilidad de migración entre proveedores de plataformas de internet 300, ya que a pesar de emplear protocolos comunes (MQTT, HTTP), utilizan métodos de autenticación diferentes que imposibilitan al proveedor de una solución loT la posibilidad de migrar entre plataformas sin tener que modificar significativamente el firmware de todos sus dispositivos. Únicamente las soluciones loT basadas en conectividad LPWA no IP como SIGFOX o LORA, al no soportar en el dispositivo 100 la posibilidad de integración con la mayoría de plataformas de internet 300, ofrecen en la infraestructura del operador de comunicaciones la posibilidad de enrutar los datos a una u otra plataforma. Sin embargo, para soluciones loT que emplean conectividad celular 2G, 3G, 4G y que disponen de conectividad IP, no existe en la infraestructura del operador de comunicaciones ningún mecanismo para seleccionar la plataforma loT de destino.
Por el contrario, la invención permite al proveedor de una solución loT integrar sus dispositivos 100 únicamente con el servidor de comunicaciones 200. A partir de este momento, el proveedor de la solución loT puede utilizar una interfaz de administración del servidor de comunicaciones 200 para poder encaminar la información de sus dispositivos 100 a la plataforma de internet 300 que considere. Para ello, es necesario que los dispositivos 100 utilicen un protocolo estándar (MQTT, HTTP) pero sin que deban emplear unas credenciales específicas de la plataforma de internet 300 de destino. De esta forma, el proveedor de la solución loT podrá seleccionar una o varias plataformas de internet destino 300 que desee, sin necesidad de efectuar ningún cambio en el software de sus dispositivos 100. Adicionalmente, la incorporación de nuevas plataformas de internet 300 o los cambios en las actuales también se realizará de forma centralizada sin necesidad de cambios en los dispositivos.
- Gestión de credenciales de autenticación de plataformas de internet:
Actualmente la gestión de credenciales de los dispositivos 100 se debe realizar por parte del proveedor de la solución loT interaccionando directamente sobre los dispositivos 100. Esta gestión de la identidad implica diversas decisiones de diseño y operaciones de gestión que debe realizar el proveedor de la solución, entre ellas:
• Generación de un token de identidad: en muchas ocasiones las plataformas de internet 300 dejan en manos del proveedor de la solución loT la generación del token de identidad que permite autenticar un dispositivo 100. Este token puede ser un secreto compartido, un token temporal derivado de un secreto compartido o un certificado X.509. No todas las organizaciones tienen el conocimiento y los procesos para generar y gestionar de forma segura estos tokens de identidad. Esto puede hacer que estos tokens sean predecibles, que no estén gestionados de forma segura y puedan filtrarse o incluso que sean comunes para toda la base de dispositivos.
• Provisión del token de identidad: la distribución de esos tokens de identidad es otro proceso delicado fuera del alcance de las plataformas de internet 300 y que supone una decisión de diseño crítica para el proveedor de la solución loT. Esto hace que muchas veces el token de identidad se provisione manualmente en el dispositivo 100, se almacene en este de forma insegura o incluso se guarde en un almacenamiento permanente que no permita su rotación en caso de que se sospeche o se conozca que el token de identidad ha sido comprometido.
Adicionalmente es posible que por las limitaciones de recursos técnicos en el dispositivo 100 no se soporte un procedimiento seguro de generación y provisión de estos tokens de identidad en el dispositivo 100, haciendo imposible una gestión segura de esta identidad aunque la organización tenga los recursos y el conocimiento para hacerlo. Por ello, la invención permite al proveedor de una solución loT el no tener que acometer los procesos de generación y provisión del token de identidad. No sólo reduciendo el esfuerzo dedicado a estas operaciones de interacción con el dispositivo 100 sino también evitando los riesgos de seguridad asociados a una ejecución insegura de los mismos. El proveedor de la solución no necesita generar un token de identidad por dispositivo 100 que sea dependiente de la plataforma de internet 300 destino porque se utiliza la identidad en la red celular del dispositivo 100.
Cuando un dispositivo 100 se conecta a la red celular y establece un contexto de datos para tener conectividad IP, el GGSN de la red celular le asigna una dirección IP. El proveedor de comunicaciones conoce en todo momento la identidad en la red celular (MSISDN, IMSI), la identidad del dispositivo utilizado (IMEI) y la identidad de la tarjeta SIM utilizada (ICCD) para este contexto de datos. De esta forma, a partir de la dirección IP origen del dispositivo 100, el proveedor de comunicaciones puede conocer la identidad en red del dispositivo 100 y de esta forma traducirla a la identidad adecuada en la plataforma de internet 300 destino seleccionada por el proveedor de la solución loT. Para realizar esta traducción es necesario que el servidor de comunicaciones 200 tenga acceso a la información de señalización de la red así como las credenciales de conexión con la plataforma de internet 300 de destino que permita la gestión de identidades de dispositivos 100. Es importante destacar que la invención no es vulnerable a las técnicas de IP spoofing ya que en una red celular el GGSN, aunque un dispositivo 100 modifique su dirección IP y envíe los paquetes con una dirección distinta de la asignada, nunca se le enviarán los paquetes de vuelta al dispositivo 100 malicioso. Siempre se plantea el uso de protocolos que necesitan conexión (HTTP, MQTT) por lo cual la fase de handshake no podrá completarse en caso de IP spoofing.
- Enriquecimiento de la información con información de red:
En ocasiones es necesario conocer información de red como puede ser ICCID de la tarjeta SIM, I MSI , IMEI del dispositivo 100, marca y modelo del dispositivo 100 o localización del mismo basada en red. Esta información puede ser útil para identificar el dispositivo físico que está conectado y por ejemplo realizar verificaciones de seguridad impidiendo que una tarjeta SIM se introduzca en un dispositivo 100 no autorizado. Actualmente, los dispositivos 100 deben incorporar, si es necesario para la aplicación, información sobre la red celular y sobre los parámetros de red del dispositivo 100. Esto implica comunicación entre software de dispositivo y el módulo de comunicaciones que no siempre es sencillo de obtener.
La invención permite al proveedor de una solución loT el no tener que acometer el desarrollo en el software del dispositivo 100 necesario para obtener del módulo de comunicaciones esta información. Adicionalmente, el envío de esta información desde el dispositivo 100 implica un consumo adicional de datos y por tanto de batería que no es necesaria gracias a la invención. Esta mejora es particularmente interesante en el caso de que sea necesario utilizar la información de red para conseguir la información final, por ejemplo, en el caso de resolver la localización es necesario emplear el LAC y CellID que conoce el módulo de comunicaciones y consultar a un servicio adicional de un tercero para resolverlo. El mismo caso es necesario cuando se quiere resolver el nombre del fabricante del módulo y el modelo a partir del IMEI.
Con referencia ahora a la Fig. 2, en la misma se muestra un esquema de los diferentes módulos del servidor de comunicaciones 200 para permitir la identificación y autenticación segura de un dispositivo 100 a una plataforma de internet 300. El servidor de comunicaciones 200 principalmente consta de:
• Un módulo adaptador de protocolos 204: Este elemento se encarga de realizar la conexión con la plataforma de internet 300 y enviar los datos recibidos del dispositivo 100. Es destacable que este elemento absorbe la complejidad y evolución de las APIs de plataforma 300 de destino, liberando al dispositivo 100 de realizar actualizaciones de software para adaptarse a ellas. La principal tarea de la que se encarga es manejar la autenticación con la plataforma de internet 300 de destino, de esta forma en caso de requerir un cifrado complejo o autenticación mutua basada en certificados digitales X.509, el dispositivo 100 no debe preocuparse por ello. Esto conlleva una reducción significativa en la capacidad de los recursos hardware necesarios en el dispositivo 100 y en el consumo de datos que el dispositivo debe enviar para realizar por ejemplo un handshake TLS.
El adaptador de protocolos 204 es capaz de cambiar la plataforma de internet 300 de destino de forma transparente para el dispositivo 100, así como enviar los datos a varias plataformas 300 simultáneamente con un único envío de información por parte del dispositivo 100.
El diseño de este módulo 204 es preferiblemente modular, de esta forma permite la conexión a diferentes proveedores de plataforma de internet 300 con distintos protocolos relevantes como pueden ser HTTP, MQTT y COAP.
Las credenciales empleadas en la conexión con la plataforma de internet 300 se tomarán de un repositorio de credenciales 205 del servidor de comunicaciones 200.
• Un módulo enriquecedor de datos 203: Este elemento se encarga de ampliar la información enviada por el dispositivo 100 con datos disponibles en la red como pueden ser: ICCID de la tarjeta SIM, IMSI, IMEI del dispositivo 100, marca y modelo del dispositivo 100 o localización del mismo basada en red, etc. Esta información se encuentra disponible en un módulo de gestión de conectividad 202 y puede ser consultada a partir de la IP recibida del dispositivo 100.
• Un módulo de autenticación 201 (de red): Este elemento se encarga de verificar la identidad del dispositivo 100 y permitir su conexión para el envío de datos a la plataforma de internet 300. Este elemento emplea la IP recibida en la petición enviada por el dispositivo 100 y consultará el módulo de gestión de conectividad 202. La autenticación será satisfactoria siempre que el módulo de gestión de conectividad 202 reconozca la IP del dispositivo 100 como válida para el cliente. • Repositorio de Credenciales 205: Este elemento se encarga de mantener la relación entre la identidad de red del dispositivo 100 que conoce el módulo de gestión de conectividad 202 y la identidad asignada por el cliente en la plataforma de internet 300. · Módulo de gestión de conectividad 202: Este elemento se encarga de gestionar el ciclo de vida de la conectividad del dispositivo 100 y conoce toda la información de red relativa al mismo como puede ser: IP asignada, ICCID de la tarjeta SIM, IMSI, IMEI del dispositivo 100, marca y modelo del dispositivo o localización del mismo basada en red. Debe permitir una consulta de esta información de red a partir de la dirección IP asignada al dispositivo 100.
Por otro lado, el dispositivo 100 es un dispositivo del cliente del servidor de comunicaciones 200 que se encarga de recopilar información de un objeto al cual está conectado (por ejemplo, un vehículo, una lavadora o un localizador, entre otros) a partir de sensores y cierta capacidad de procesamiento para enviarlos a la plataforma de internet 300. Adicionalmente, el dispositivo 100 puede disponer de capacidades de actuación que le permitan realizar determinadas acciones sobre el objeto conectado, recibiendo comandos de la plataforma de internet 300. El dispositivo 100 dispone de un módulo de comunicaciones móviles que emplea una tarjeta ICC como mecanismo de autenticación del cliente con la red y que es conocido por el módulo de gestión de conectividad 202 en el proceso de conexión a la misma.
Con referencia a la plataforma de internet 300, este elemento es el responsable de almacenar los datos recopilados por el dispositivo 100 y ofrecerlos a una aplicación 301. Este elemento mantiene una identidad del dispositivo 100 para el que ofrece unas credenciales individuales que son almacenadas en el repositorio de credenciales 205. La aplicación 301 es responsable de representar al cliente la información recopilada por el dispositivo 100 en la plataforma de internet 300 y de generar los comandos de actuación sobre el mismo.
En un ejemplo de realización, el flujo de envío de datos desde el dispositivo 100 hasta la plataforma de internet 300 es el siguiente. El dispositivo 100 envía una petición al módulo de autenticación 201 sin ningún tipo de credenciales de autenticación a través de una red móvil o celular. El módulo de autenticación 201 obtiene la dirección IP de la petición recibida y consulta al módulo de gestión de conectividad 202 para validar que esa dirección IP ha sido asignada por la red celular a un dispositivo 100 del cliente. El módulo de gestión de conectividad 202 a partir de la dirección IP consultada, confirma que la petición es de un dispositivo 100 legítimo y devuelve un identificador del dispositivo 100 (por ejemplo el IMSI del ICC del dispositivo 100). En caso contrario devolverá un error y la petición no progresará. Luego, el módulo de autenticación 201 progresa la petición del dispositivo 100 al módulo enriquecedor de datos 203 y éste solicita al módulo de gestión de conectividad 202 la información de red disponible de ese dispositivo 100 como puede ser: ICCID de la tarjeta SIM, IMSI, IMEI del dispositivo, marca y modelo del dispositivo o localización del mismo basada en red. El Enriquecedor de datos 203 progresa la petición del dispositivo 100 enriquecida con la información de red obtenida al módulo adaptador de protocolos 204, que adaptan la petición al protocolo destino de la plataforma de internet 300. El módulo adaptador de protocolos 204 consulta el repositorio de credenciales 205 para obtener las credenciales adecuadas al protocolo destino junto con la identidad del dispositivo 100 en la plataforma 300. En caso de que no exista esta información localmente, el módulo adaptador 204 debe ser capaz de interaccionar con la plataforma de internet 300 para registrar el dispositivo 100 o recuperarlas si ya está registrado. El módulo adaptador de protocolos 204 envía los datos del dispositivo 100 junto con la información de red del módulo enriquecedor de datos 203 y las credenciales adecuadas a la plataforma de internet 300. Finalmente, la aplicación 301 recupera los datos de la plataforma de internet 300 y los presenta de forma adecuada para el usuario final. Con referencia ahora a la Fig. 3, en la misma se muestra un segundo ejemplo de realización de la invención. En este caso el servidor de comunicaciones se utiliza como broker de credenciales. En este ejemplo de realización, el dispositivo 100 mantiene la conexión directa con la plataforma de internet 300, utilizando un servicio expuesto por el servidor de comunicaciones 200 para obtener las credenciales en dicha plataforma de internet 300 utilizando para ello la identificación y autenticación proporcionada por la red.
El módulo de autenticación 201 , tras obtener y validar la identidad y autenticación mediante el módulo de conectividad 202 de forma análoga al anterior ejemplo de realización, obtiene las credenciales para dicho dispositivo 100 en la plataforma de internet 300 a través del módulo adaptador de protocolos 204 y las provee al dispositivo 100 para su posterior uso. El dispositivo 100, en caso de error de autenticación en su comunicación con la plataforma 300, iniciará una nueva petición al módulo de autenticación 201 para renovar sus credenciales. Mediante este mecanismo, se consigue igualmente el objetivo principal de la presente invención, desplegar un único firmware de fábrica en todos los dispositivos 100, y evitar la instalación manual posterior de los certificados necesarios para la comunicación segura con la plataforma de internet 300 elegida.
Esta alternativa permite mantener una conexión directa, sin puntos intermedios, entre el dispositivo 100 y la plataforma de internet 300, lo que reduce la complejidad en la operación. Asimismo, el cifrado de la comunicación se implementa extremo a extremo desde el dispositivo 100 a la plataforma 300.
Por el contrario, como principales inconvenientes, la conexión del dispositivo 100 con la plataforma de internet 300 requiere de unas capacidades mínimas de computación para el cifrado de la comunicación en el lado del dispositivo 100, lo que deja fuera de rango a muchos dispositivos 100 de bajo coste utilizados en un amplio abanico de casos de uso, como es el caso de medidores inteligentes. Asimismo, el uso de cifrado extremo a extremo desde el dispositivo 100 requiere de un mayor consumo de ancho de banda móvil, así como una menor duración de la batería. Si el usuario desea cambiar de plataforma de internet 300, se hace necesario reprogramar el dispositivo 100 con la interfaz de la nueva plataforma de internet 300 en caso de que no se utilicen APIs estándar en las mismas. Esta alternativa no permite enriquecer automáticamente la información enviada a la plataforma de internet 300 con información de red.
Con referencia ahora a la Fig. 4, en la misma se muestra un tercer ejemplo de realización de la invención. En este caso el servidor de comunicaciones se utiliza como broker de credenciales con autenticación de un mensaje de texto. El dispositivo 100 sigue manteniendo la conexión directa con la plataforma de internet 300, incluyendo en este caso el servidor de comunicaciones 200 a un módulo de servicio SMS 206 para identificar y autenticar al dispositivo 100 previo a la obtención de las credenciales en la plataforma de internet 300. En este caso, el dispositivo 100 envía un mensaje de texto, preferiblemente un mensaje SMS, a través del módulo de servicio SMS 206 incluyendo como contenido un token temporal de un solo uso (o clave de un solo uso), así como un identificador del cliente en el módulo de gestión de conectividad 202 y una numeración privada (shortcode) asignada al servidor de comunicaciones 200. Es importante el uso de numeración privada, y no pública, para evitar ataques de SMS spoofing, en los cuales podrían llegar al módulo de servicio SMS 206 mensajes de redes externas, no confiables, con el origen del mensaje modificado. En cualquiera de los casos, se pueden poner en funcionamiento todos los mecanismos disponibles en la operadora para evitar la llegada de SMS con origen no confiable al módulo de servicio SMS 206. Por otro lado, el token contenido en el mensaje SMS preferiblemente tiene un número mínimo de caracteres para evitar colisiones entre peticiones de distintos dispositivos 100, es temporal, con una duración de pocos minutos, y de un solo uso.
El módulo de servicio SMS 206 enruta el mensaje recibido (incluyendo el contenido y el origen del mismo) al módulo de autenticación 201 , validando el origen y cliente en el módulo de gestión de conectividad 202 de forma análoga a los casos anteriormente descritos. Si el origen pertenece al inventario del cliente, obtiene las credenciales en la plataforma de internet 300 y las almacenas temporalmente asociadas al token generado por el dispositivo 100 y el identificador del cliente contenidos en el mensaje SMS. Pasado un tiempo de espera establecido, el dispositivo 100 realiza una petición HTTPS para la descarga de las credenciales en la plataforma de internet 300, incluyendo en dicha petición el token y el identificador de cliente. Si las credenciales existen para dicha dupla, estas son devueltas en la petición HTTPS. En caso contrario se pueden devolver los siguientes códigos de error: o Proceso de autenticación válido, pero credenciales aún no disponibles: 404 Not Found
o Proceso de autenticación invalido: 403 Forbidden
De forma análoga al descrito en el segundo ejemplo de realización, el dispositivo 100, en caso de error de autenticación en su comunicación con la plataforma de internet 300, iniciará un nuevo proceso para la renovación de sus credenciales siguiendo los pasos citados anteriormente.
Este tercer ejemplo de realización está basado en funcionalidades estándar de la red móvil, ya que está basado en la autenticación del módulo de servicio SMS 206 en lugar de en procedimientos de autenticación en red propietarios de cada operadora: identificación a través de la IP privada del dispositivo 100 en la red celular o adición de cabeceras HTTP por parte de proxis transparentes. Asimismo, se eliminan problemas con los NATs, que en algunos casos de uso pueden ocultar la IP privada del dispositivo 100, impidiendo su identificación en el módulo de autenticación 201.
Por otro lado, este ejemplo de realización presenta algunas limitaciones o inconvenientes. La validación mediante el módulo de servicio SMS 206 introduce una comunicación asincrona, necesitando de un tiempo de espera variable previo a la recuperación de las credenciales por parte del dispositivo 100. Esto obliga a configurar en el dispositivo 100 un tiempo de espera superior al estimado, y a programar procedimientos de recuperación para el caso que las credenciales no estén disponibles en dicho tiempo. De igual modo, no existe una confirmación al dispositivo 100 del proceso de autenticación iniciado con el mensaje SMS. El dispositivo 100 solo puede comprobar el estado de la autenticación mediante la consulta HTTPS al módulo de autenticación 201 que le devolverá las credenciales cuando éste haya finalizado. La confirmación del proceso de autenticación podría habilitarse con un mensaje SMS de retorno originado en el módulo de autenticación 201 con destino al dispositivo 100, incluyendo como contenido el token, identificador de cliente y resultado de la autenticación.
Un experto en la materia podría introducir cambios y modificaciones en los ejemplos de realización descritos sin salirse del alcance de la invención según está definido en las reivindicaciones adjuntas.

Claims

REIVINDICACIONES
1. Un método para identificación y autenticación segura de un dispositivo a una plataforma de internet, comprende:
a) recibir, por un servidor de comunicaciones (200), de un dispositivo (100), una petición para establecer una conexión con al menos una plataforma de internet (300),
en donde dicho dispositivo (100), que incluye un módulo de comunicaciones móviles, está asociado a un cliente del servidor de comunicaciones (200) mediante un identificador único de una tarjeta SIM insertada en dicho dispositivo (100), y recopila información de un objeto físico adquirida por uno o más sensores, y
en donde el servidor de comunicaciones (200) está operativamente conectado con la plataforma de internet (300), que es al menos una;
b) obtener, por el servidor de comunicaciones (200), una dirección IP de dicho dispositivo (100) y validar que dicha dirección IP está asignada al cliente en dicho servidor de comunicaciones (200), devolviendo en caso que la validación sea correcta un identificador del dispositivo (100);
c) extraer, por el servidor de comunicaciones (200), información de red del dispositivo (100) a partir de la dirección IP;
d) extraer, por el servidor de comunicaciones (200), unas credenciales del cliente en la plataforma de internet (300); y
e1) enviar, por el servidor de comunicaciones (200), dichas credenciales al dispositivo (100) para que este último envíe dicha información recopilada del objeto físico a la plataforma de internet (300), en donde las credenciales son utilizadas para autentificación del dispositivo (100) ante la plataforma de internet (300); o
e2) enviar, por el servidor de comunicaciones (200), utilizando dichas credenciales y el identificador del dispositivo (100), la información recopilada del objeto físico junto con la información de red obtenida en el paso c), a la plataforma de internet (300).
2. Método según la reivindicación 1 , en donde la petición recibida por el servidor de comunicaciones (200) es para establecer una conexión con una pluralidad de plataformas de internet (300), en donde el método comprende:
en dicha etapa d) extraer las credenciales del cliente utilizadas en cada una de dicha pluralidad de plataformas de internet (300); y
realizar dicha etapa e2) simultáneamente para cada una de la pluralidad de plataformas de internet (300).
3. Método según la reivindicación 1 , que comprende además: recibir, por el servidor de comunicaciones (200), del dispositivo (100), una petición para establecer una conexión con otra plataforma de internet (300); y
realizar dicha etapa e2) para la otra plataforma de internet (300).
4. Método según la reivindicación 1 , en donde la etapa c) comprende además añadir la información de red extraída a la información recopilada del objeto físico.
5. Método según la reivindicación 1 , que comprende además:
recibir, previamente a dicha etapa a), por el servidor de comunicaciones (200), un mensaje de texto que incluye una clave de un solo uso con una numeración privada asignada al servidor de comunicaciones (200) y un identificador de dicho cliente; y
validar, por el servidor de comunicaciones (200), el origen y el cliente de dicho mensaje de texto, en donde si el origen corresponde a dicho cliente el servidor de comunicaciones (200) obtiene las credenciales de la plataforma de internet (300) y las almacena temporalmente asociadas con la clave de un solo uso y con el identificador del cliente,
de manera que la petición de la etapa a) incluye además la clave de un solo uso y el identificador del cliente, y el servidor de comunicaciones (200) devuelve las credenciales almacenadas si la clave de un solo uso y el identificador del cliente recibidos en la petición coinciden con la clave de un solo uso y con el identificador del cliente asociados a las credenciales almacenadas o envía un mensaje de error al dispositivo (100) en caso que no coincidan.
6. Método según la reivindicación 5, en donde el mensaje de error comprende:
una indicación que la autenticación del dispositivo (100) es válida pero las credenciales no están aún disponibles; o
una indicación que la autenticación del dispositivo (100) no es válida. 7. Método según las reivindicaciones anteriores, en donde la información de red extraída en la etapa c) incluye al menos uno de: el identificador único de la tarjeta SIM del dispositivo (100), un número de identidad internacional del cliente, o número IMSI o MSISDN, un número de identidad internacional del dispositivo (100), o número IMEI, la marca y/o modelo del dispositivo (100), o una localización del dispositivo (100) basada en red. 8. Método según la reivindicación 1 , en donde el dispositivo (100) es un dispositivo loT y la plataforma de internet (300) está alojada en la nube.
9. Un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet, comprende:
un módulo de autenticación (201) configurado para obtener, una vez recibida, de un dispositivo (100), una petición para establecer una conexión con al menos una plataforma de internet (300), una dirección IP de dicho dispositivo (100) y validar que dicha dirección IP está asignada a un cliente del servidor de comunicaciones (200),
en donde dicho dispositivo (100), que incluye un módulo de comunicaciones móviles, está asociado a dicho cliente mediante un identificador único de una tarjeta SIM insertada en el dispositivo (100), y recopila información de un objeto físico adquirida por uno o más sensores;
un módulo de gestión de conectividad (202) configurado para verificar, utilizando la dirección IP, que el dispositivo (100) es un dispositivo legítimo y para devolver un identificador del dispositivo (100) en caso que este sea un dispositivo legítimo;
un módulo enriquecedor de datos (203) configurado para extraer información de red del dispositivo (100) a partir de la dirección IP;
un repositorio de credenciales (205) configurado para almacenar unas credenciales del cliente en la plataforma de internet (300); y
un módulo adaptador de protocolos (204) configurado para extraer dichas credenciales del cliente y para enviarlas al dispositivo (100) para que este último envíe dicha información recopilada del objeto físico a la plataforma de internet (300) o para enviar, utilizando dichas credenciales y el identificador del dispositivo (100), la información recopilada del objeto físico junto con la información de red obtenida a la plataforma de internet (300).
10. Servidor de comunicaciones según la reivindicación 9, en donde dicho módulo adaptador de protocolos (204) es modular y está configurado para permitir una conexión del dispositivo
(100) con una pluralidad de plataformas de internet (300).
11. Servidor de comunicaciones según la reivindicación 9, en donde la información de red extraída incluye al menos uno de: el identificador único de la tarjeta SIM del dispositivo (100), un número de identidad internacional del cliente, o número IMSI o MSISDN, un número de identidad internacional del dispositivo (100), o número IMEI, la marca y/o modelo del dispositivo (100), o una localización del dispositivo (100) basada en red.
12. Servidor de comunicaciones según las reivindicaciones 9 a 11 , que comprende además un módulo de servicio SMS (206) configurado para recibir un mensaje de texto que incluye una clave de un solo uso con una numeración privada asignada al servidor comunicaciones (200) y un identificador de dicho cliente.
PCT/ES2017/070640 2017-09-29 2017-09-29 Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet WO2019063855A1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
BR112020006080-1A BR112020006080A2 (pt) 2017-09-29 2017-09-29 método e servidor de comunicações para identificação e autenticação segura de um dispositivo para uma plataforma de internet
PCT/ES2017/070640 WO2019063855A1 (es) 2017-09-29 2017-09-29 Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet
EP17926443.7A EP3681185A4 (en) 2017-09-29 2017-09-29 COMMUNICATIONS PROCESS AND SERVER FOR SECURELY IDENTIFYING AND AUTHENTICATION OF A DEVICE USING AN INTERNET PLATFORM

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2017/070640 WO2019063855A1 (es) 2017-09-29 2017-09-29 Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet

Publications (1)

Publication Number Publication Date
WO2019063855A1 true WO2019063855A1 (es) 2019-04-04

Family

ID=65901155

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2017/070640 WO2019063855A1 (es) 2017-09-29 2017-09-29 Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet

Country Status (3)

Country Link
EP (1) EP3681185A4 (es)
BR (1) BR112020006080A2 (es)
WO (1) WO2019063855A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115174314A (zh) * 2022-06-30 2022-10-11 广州鲁邦通物联网科技股份有限公司 一种智能网关、物联网数据的采集方法和物联网系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4027675A1 (en) * 2021-01-07 2022-07-13 Deutsche Telekom AG System and method for authentication of iot devices

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060046693A1 (en) * 2004-08-31 2006-03-02 Hung Tran Wireless local area network (WLAN) authentication method, WLAN client and WLAN service node (WSN)
EP1681832A1 (en) * 2005-01-14 2006-07-19 Hewlett-Packard Development Company, L.P. Provision of services over a common delivery platform such as a mobile telephony network
US20150089621A1 (en) * 2013-09-24 2015-03-26 Cellco Partnership (D/B/A Verizon Wireless) Secure login for subscriber devices
WO2016050990A1 (en) * 2014-10-03 2016-04-07 Moqom Limited Identity and/or risk management system and method
WO2017040124A1 (en) * 2015-08-31 2017-03-09 Pcms Holdings, Inc. System and method for detection of cloned devices

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006203300A (ja) * 2005-01-18 2006-08-03 Toshiba Corp 転送装置、アクセス可否判定方法およびプログラム
US9241269B1 (en) * 2014-07-10 2016-01-19 Sprint Communications Company L.P. Method to identify a customer on a Wi-Fi network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060046693A1 (en) * 2004-08-31 2006-03-02 Hung Tran Wireless local area network (WLAN) authentication method, WLAN client and WLAN service node (WSN)
EP1681832A1 (en) * 2005-01-14 2006-07-19 Hewlett-Packard Development Company, L.P. Provision of services over a common delivery platform such as a mobile telephony network
US20150089621A1 (en) * 2013-09-24 2015-03-26 Cellco Partnership (D/B/A Verizon Wireless) Secure login for subscriber devices
WO2016050990A1 (en) * 2014-10-03 2016-04-07 Moqom Limited Identity and/or risk management system and method
WO2017040124A1 (en) * 2015-08-31 2017-03-09 Pcms Holdings, Inc. System and method for detection of cloned devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3681185A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115174314A (zh) * 2022-06-30 2022-10-11 广州鲁邦通物联网科技股份有限公司 一种智能网关、物联网数据的采集方法和物联网系统

Also Published As

Publication number Publication date
EP3681185A1 (en) 2020-07-15
EP3681185A4 (en) 2021-03-31
BR112020006080A2 (pt) 2020-09-29

Similar Documents

Publication Publication Date Title
ES2973643T3 (es) Comunicación con un dispositivo máquina a máquina
ES2931775T3 (es) Selección de instancia de función de red
ES2947942T3 (es) Autenticación secundaria de un equipo de usuario
ES2922726T3 (es) Procedimiento y aparato de gestión de un perfil de un terminal en un sistema de comunicación inalámbrica
RU2719447C1 (ru) Способ конфигурирования ключа, способ определения политики безопасности и устройство
RU2739732C2 (ru) Устройства и способы для аутентификации клиентского устройства
ES2774921T3 (es) Procedimiento y aparato para vincular la autenticación de abonados y la autenticación de dispositivos en sistemas de comunicación
ES2633351T3 (es) Procedimientos y dispositivos para realizar un cambio de red móvil
ES2647088T3 (es) Procedimientos y dispositivos para la gestión de suscripciones OTA
ES2943849T3 (es) Técnica para el manejo de certificados en un dominio de red de núcleo
ES2535386T3 (es) Procedimientos y dispositivos para gestión durante la comunicación (OTA) de módulos de identificación de abonado
US20120045060A1 (en) method and system for wireless connecting a mobile device to a service provider through a hosting wireless access node
ES2488396T3 (es) Autenticación en un sistema de comunicaciones
US8566590B2 (en) Encryption information transmitting terminal
WO2016110601A1 (es) Procedimiento de generación de una identidad digital de un usuario de un dispositivo móvil, identidad digital de usuario, y procedimiento de autenticación usando dicha identidad digital de usuario
WO2012136867A1 (es) Metodo y sistema para el aprovisionamiento remoto de subscripcion
BR112019022792A2 (pt) método de geração de chave, equipamento de usuário, aparelho, mídia de armazenamento legível por computador e sistema de comunicação
ES2887323T3 (es) Negociación de seguridad en arquitecturas basadas en servicios (SBA)
ES2913538T3 (es) Método y disposición de detección de identidad de abonado
ES2806991T3 (es) Autentificación para sistemas de próxima generación
ES2393368B1 (es) Método de identificación para acceder a servicios o aplicaciones de banda ancha móvil.
WO2019059754A9 (es) Método y sistema de comunicación segura por proxificación de sockets de red
ES2703555T3 (es) Protección de intercambio de mensajes WLCP entre TWAG y UE
WO2019063855A1 (es) Un método y un servidor de comunicaciones para identificación y autenticación segura de un dispositivo a una plataforma de internet
ES2582858T3 (es) Implementación de una asociación de seguridad durante la adscripción de un terminal a una red de acceso

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17926443

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017926443

Country of ref document: EP

Effective date: 20200407

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112020006080

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112020006080

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20200326