ES2973643T3 - Comunicación con un dispositivo máquina a máquina - Google Patents

Comunicación con un dispositivo máquina a máquina Download PDF

Info

Publication number
ES2973643T3
ES2973643T3 ES20195438T ES20195438T ES2973643T3 ES 2973643 T3 ES2973643 T3 ES 2973643T3 ES 20195438 T ES20195438 T ES 20195438T ES 20195438 T ES20195438 T ES 20195438T ES 2973643 T3 ES2973643 T3 ES 2973643T3
Authority
ES
Spain
Prior art keywords
server
lwm2m
traffic
boot
communication traffic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES20195438T
Other languages
English (en)
Inventor
Sophie Nicole Bourne
Tim Snape
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone Global Enterprise Ltd
Dabco Ltd
Original Assignee
Vodafone Global Enterprise Ltd
Dabco Ltd
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
Priority claimed from GB201316370A external-priority patent/GB201316370D0/en
Priority claimed from GB201318339A external-priority patent/GB201318339D0/en
Application filed by Vodafone Global Enterprise Ltd, Dabco Ltd filed Critical Vodafone Global Enterprise Ltd
Application granted granted Critical
Publication of ES2973643T3 publication Critical patent/ES2973643T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1668—Details of memory controller
    • G06F13/1689—Synchronisation and timing concerns
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4027—Coupling between buses using bus bridges
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/38—Transceivers, i.e. devices in which transmitter and receiver form a structural unit and in which at least one part is used for functions of transmitting and receiving
    • H04B1/3816—Mechanical arrangements for accommodating identification devices, e.g. cards or chips; with connectors for programming identification devices
    • 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
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/37—Managing security policies for mobile devices or for controlling mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. Transmission Power Control [TPC] or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • 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/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Medical Informatics (AREA)
  • Bioethics (AREA)
  • Mathematical Physics (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Método y sistema para enrutar el tráfico de comunicaciones entre un dispositivo de máquina a máquina, M2M, conectado a una red de telecomunicaciones y que tiene una Identidad de Suscriptor Móvil Internacional, IMSI, y un servidor, comprendiendo el método asignar un nombre de punto de acceso, APN, de una pluralidad de APN basados en el IMSI del dispositivo M2M. Enrutar, a través del APN asignado, el tráfico de comunicaciones entre el dispositivo M2M y el servidor, en el que el servidor se determina basándose en uno o más de: el IMSI, el APN y una característica de un tráfico de comunicación entre el dispositivo M2M y el servidor. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Comunicación con un dispositivo máquina a máquina
Campo de la invención
La presente invención se refiere a un método y sistema para la comunicación con un dispositivo máquina a máquina y, en particular, para el enrutamiento del tráfico de comunicaciones entre el dispositivo máquina a máquina y un servidor.
Antecedentes de la invención
Los dispositivos máquina a máquina (M2M) suelen ser numerosos, difíciles de alcanzar y tienen capacidades limitadas (debido al bajo coste, el tamaño pequeño, la baja potencia de procesamiento o la duración limitada de la batería). Todo ello hace que su gestión, muchas veces en remoto, sea muy complicada. Además, los dispositivos M2M a menudo necesitan gestionarse de forma segura. Por ejemplo, pueden contener información que sea comercialmente sensible y/o confidencial para una o más entidades que gestionan y/o poseen dichos dispositivos. Es necesario gestionarlos de forma remota y segura, respetando al mismo tiempo estas limitaciones.
El dispositivo M2M debe poder contactar con un servidor de gestión de dispositivos (DM) de manera segura. Si bien en el momento de la fabricación el dispositivo puede contar con las direcciones y URL necesarias para ubicar este servidor DM, esto requiere que los proveedores del dispositivo tengan conocimiento sobre los usuarios finales del dispositivo. Además, si las direcciones o ubicaciones del servidor DM cambian, a continuación, los dispositivos M2M deberán actualizarse para impedir que las comunicaciones se pierdan o se desvíen erróneamente.
Por lo tanto, se requiere un sistema y un método que permita a los dispositivos M2M comunicarse de manera más fiable y segura.
Nhon Chu et al: “OMA DM v1.x compliant Lightweight device management for constrained M2M devices”, TRANSACIONES DE COMUNICACIONES EUROPEAS, describe la gestión de dispositivos OMA DM v1.x ligeros compatibles con dispositivos M2M limitados.
Detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema.
Una de estas arquitecturas de 3GPP es la arquitectura genérica de autenticación (GAA), que es un complejo de estándares que se describe, por ejemplo, en 3GPP TS 33.919 (titulado "seguridad 3G; arquitectura genérica de autenticación (GAA); Descripción del sistema", actualmente se puede recuperar en http://www.3gpp.org/ftp/Specs/html-info/33919.htm).
La arquitectura genérica de arranque (GBA) es un estándar 3GPP definido en 3GPP TS 33.220 (titulado "arquitectura genérica de autenticación (GAA); Arquitectura genérica de arranque (GBA)", actualmente se podría recuperar en http://www.3gpp.org/ftpVspecs/html-info/33220.htm). GBA es parte del complejo de estándares llamado GAA (véase más arriba).
GBA es un estándar que posibilita que se derive (arranque) un secreto compartido a partir de la asociación de seguridad existente entre una red móvil y una tarjeta SIM. Esto implica un elemento de red llamado función de servidor de arranque (BSF). En otras palabras, GBA aprovecha la seguridad de una tarjeta SIM (tarjeta de circuito integrado universal - UICC) para autenticar equipos móviles y, a continuación, derivar material clave para aplicaciones de uso general.
GBA se puede utilizar ventajosamente para proporcionar alta seguridad a la comunicación entre un cliente y el servidor, permitiendo así gestionar, controlar y, en general, comunicarse remotamente con un dispositivo de manera de alta seguridad. En particular, se utiliza<g>B<a>(o una arquitectura similar a GBA) para habilitar una comunicación segura con el dispositivo (que, según un aspecto de la presente descripción, puede ser un dispositivo M2M), siendo dicha comunicación entre un servidor y un cliente, estando el cliente asociado con el dispositivo, y en donde esta comunicación se realiza para gestionar el dispositivo y/o los servicios proporcionados por (o a través de) el dispositivo, permitiendo así una gestión segura de ese dispositivo y/o o los servicios proporcionados por (o a través de) el dispositivo. De esta manera, el dispositivo y/o los servicios proporcionados por (o a través de) el dispositivo se puede gestionar de forma segura y eficaz de manera remota a través de un servidor remoto.
GBA se ha desarrollado principalmente para proteger la transmisión móvil (por ejemplo, televisión de pago y equivalentes). De hecho, los estándares para el servicio de transmisión y multidifusión multimedia (MBMS) se basan en GBA. De manera similar, el perfil de tarjeta inteligente de alianza móvil abierta (OMA) conjunto de habilitadores de servicios de transmisión móvil (BCAST) se basa en GBA. Hasta la fecha, la mayor parte del número limitado de despliegues de GBA en el mundo ha sido para transmisión móvil. GBA también se ha estandarizado como una característica opcional junto con los servicios de presencia y dentro de diversos servicios de "identidad federada" (por ejemplo, alianza de libertad (Liberty Alliance), ID abierto (OpenID)). En general, se comprende que GBA ha sido diseñado para su uso con dispositivos móviles, tales como teléfonos móviles, portátiles, ordenadores, y muchas de las características diseñadas se han proporcionado teniendo esto en cuenta.
Se ha propuesto una variante de GBA, llamada "GBA Push", para proteger un mensaje entre un cliente y un servidor DM en el contexto de la seguridad de gestión de dispositivos OMA. La gestión de dispositivos OMA está diseñada específicamente para la gestión de dispositivos móviles, tales como teléfonos móviles, tabletas, ordenadores, etc. Un documento estándar reciente diferente (TS 102 690) simplemente menciona, en el contexto de las comunicaciones M2M, el uso de un GBA estándar para proteger las comunicaciones entre una capa de servicio de dispositivo/pasarela y una capa de servicio de red.
Existen algunas alternativas para identificar/autenticar a un usuario/dispositivo móvil en un servicio. Todas estas alternativas son más sencillas que utilizar GBA. Por ejemplo, los operadores móviles y los proveedores de servicios pueden utilizar el enriquecimiento de encabezados<w>A<p>.
Alternativamente, el proveedor de servicios puede solicitar al usuario que introduzca su número de teléfono, envíe una contraseña de un solo uso por SMS a ese número de teléfono y pedirle al usuario que lea el SMS e introduzca la contraseña. Todas estas alternativas ya funcionan bien con dispositivos y operadores móviles, por lo que los proveedores de servicios las utilizan, aunque no son tan seguras como GBA.
Además, muchos proveedores de servicios prefieren ofrecer servicios a una amplia gama de dispositivos móviles, muchos de los cuales no contienen una tarjeta SIM (por ejemplo, PC, portátiles, tabletas sólo con Wi-Fi, etc.). Dado que GBA depende de una tarjeta SIM/UICC para funcionar, no ha habido interés en utilizarla.
Una seguridad sólida no es posible con las alternativas actuales, tales como un PIN introducido por el usuario o un mensaje de arranque entregado por SMS. Estas alternativas no serían factibles o no proporcionarían el nivel de seguridad requerido. En primer lugar, es posible que no haya un usuario cerca para introducir un PIN (ya que la mayoría de los dispositivos M2M funcionan independientemente de la intervención humana). En segundo lugar, es probable que el proveedor de servicios quiera una seguridad sólida (por ejemplo, porque los dispositivos M2M pueden incluir infraestructura crítica), mientras que los arranques basados en PIN tienen una seguridad más débil. En tercer lugar, si un arranque basado en SMS o PIN sale mal (el servidor se conecta a un cliente equivocado, el cliente se conecta a un servidor equivocado o hay un intermediario), entonces es probable que el usuario se dé cuenta, se queje y lo arregle, mientras que es poco probable que un dispositivo M2M se dé cuenta y se queje, por lo que puede verse comprometido permanentemente. Ninguno de los dos es particularmente práctico según los métodos existentes. Por ejemplo, la gestión del dispositivo OMA utiliza GBA Push para proteger un mensaje entre un cliente y un servidor DM, y no hay explicación de cómo se podría utilizar o incluso modificar una arquitectura similar para gestionar el dispositivo. Además, como se ha mencionado anteriormente, la gestión del dispositivo OMA no es compatible para su uso con un dispositivo M2M, como se ha dado a conocer anteriormente. Esto es particularmente cierto para dispositivos M2M simples y de bajo coste, tales como sensores simples, interruptores, rastreadores de bajo coste, etc. Además, el documento estándar mencionado anteriormente utiliza una GBA estándar para proteger las comunicaciones entre una capa de servicio de dispositivo/pasarela y una capa de servicio de red. Así, la comunicación no se utiliza para comunicaciones relacionadas con la gestión de dispositivos/servicios y no está claro, según las observaciones realizadas anteriormente, cómo se podría utilizar o incluso modificar una arquitectura similar para gestionar el dispositivo desde el servidor. Además, por las razones mencionadas anteriormente, la gestión del dispositivo OMA y el documento estándar son incompatibles, y una combinación de GBA Push para la gestión de dispositivo OMA con el documento estándar no es factible, ya que daría como resultado un protocolo de gestión de dispositivos incorrecto (es decir, uno que no es adecuado para dispositivos M2M, particularmente dispositivos M2M simples), y un esfuerzo muy laborioso para hacer que ambos sean compatibles y eliminen los elementos que son redundantes.
La OMA ha definido un protocolo ligero para gestionar (así como interactuar con) dispositivos M2M y gestionar servicios proporcionados por dispositivos M2M (por ejemplo, control remoto de sensores o máquinas conectados). Este protocolo se llama LWM2M y se describe en detalle en http://technical.openmobilealliance.org/Technical/release_program/lightweightM2M_v1_0.a.spx.
Este protocolo se ejecuta sobre el protocolo CoAP (análogo a http), más específicamente CoAP sobre DTLS (coaps), que es análogo a http sobre TLS (https). Sin embargo, los coaps requieren que se proporcione una asociación segura entre un dispositivo y un servidor de red (servidor DM) y no proporcionan medios sólidos para aprovisionar dicha asociación desde cero.
Un aspecto de seguridad de OMA LWM2M se define en la especificación técnica de máquina a máquina ligera. Versión candidata 1.0 - 10 de diciembre de 2013 (OMA-TS-LightweightM2M-V1_0-20131210-C).
Además, existen dos protocolos, el primero llamado DTLS definido en RFC 6347 (titulado "Seguridad de Capa de Transporte de Datagrama versión 1.2"; actualmente se podría recuperar en http://tools.ietf.org/html/rfc6347); el segundo llamado CoAP definido en draft-ietf-core-coap-18 (titulado "protocolo de aplicación limitada (CoAP)"; actualmente se podría recuperar en http://datatracker.ietf.org/doc/draft-ietf-core-coap/). Ambos protocolos se utilizan actualmente en LWM2M. CoAP es todavía sólo un borrador del IETF (no un RFC completo), y la versión 1.2 de DTLS también es comparativamente nueva (enero de 2012): las versiones de TLS a menudo han existido como RFC durante varios años antes de recibir una adopción generalizada.
La seguridad del canal del protocolo de datagramas de usuario (UDP) para [CoAP] se define por la seguridad de capa de transporte de datagramas (DTLS) [RFC6347], que es el equivalente de TlS v1.2 [RFC5246] para HTTP y utiliza un subconjunto de conjuntos de cifrado definidos en TLS. (Se refiere al registro de conjuntos de cifrado de TLS http://www.iana.org/assignments/tls-parameters/tls-parameters.xml) El enlace DTLS para CoAP se define en la sección 9 de [CoAP]. DTLS es una solución de seguridad basada en sesiones de larga duración para UDP. Proporciona un protocolo de toma de contacto segura con generación de claves de sesión, autenticación mutua, integridad de datos y confidencialidad.
El material de claves utilizado para proteger el intercambio de información dentro de una sesión DTLS se puede obtener utilizando uno de los modos de arranque definidos en la sección 5.1.2 modos de arranque de OMA LWM2M. Los formatos del material de claves transportado en las instancias de objetos de seguridad LWM2M se definen en el apéndice E.1.1.
También existe una autenticación con resumen de protocolo HTTP de autenticación, que se define en RFC 3310 (titulado "Protocolo de transferencia de hipertexto (HTTP) autenticación con resumen utilizando autenticación y acuerdo de claves (AKA)", que actualmente se puede recuperar en http://www.ietf.org/rfc/rfc3310.txt).
El grupo GAA de especificaciones TS 33.222 (titulado "arquitectura genérica de autenticación (GAA); acceso a funciones de aplicaciones de red utilizando el protocolo de transferencia de hipertexto sobre seguridad de capas de transporte (HTTPS)") define un enfoque general para la clave previamente compartida TLS (TLS-PSK, RFC 4279). Actualmente se puede recuperar en http://www.3gpp.org/ftp/Specs/html-info/33222.htm). Por ejemplo, véase especialmente la sección 5.4.
En particular, con referencia a GBA, la especificación 3GPP TS 33.220 define los componentes e interfaces que se muestran en la fig. 1. Estos se describen además como:
NAF 122, la "función de aplicación de red" es un componente del lado del servidor de una aplicación que se protegerá utilizando GBA.
BSF 130, "función de servidor de arranque", es un componente del lado del servidor, que obtiene vectores de autenticación del HLR/HSS 140 y envía un desafío al dispositivo móvil, "UE", 110 durante el protocolo GBA. Tras una autenticación con éxito, deriva el secreto compartido.
HLR/HSS 140, el "registro de ubicación local" o "sistema de abonado local", es el sistema 3GPP existente que almacena detalles de suscripción y credenciales (K e IMSI) para cada tarjeta SIM (tarjeta de circuito integrada universal - UICC) emitida por un operador de telefonía móvil. Puede ser "conocedor de GBA" (de manera que almacene detalles de la suscripción de un usuario de GBA) o puede ser un componente heredado.
EL UE, el "equipo de usuario", 110 es un dispositivo móvil que contiene una tarjeta SIM (UICC). El UE 110 soporta una aplicación cliente que se comunica con la NAF 122, así como un servicio que interactúa con la UICC, se comunica con la BSF 130 y deriva el secreto compartido antes de pasarlo a la aplicación cliente. Este servicio se denomina (de manera algo confusa) "Servidor GAA" en TR 33.905 (titulado "recomendaciones para plataformas abiertas fiables", actualmente se puede recuperar en http://www.3gpp.org/ftp/specs/htmlinfo/33905.htm).
La Ua 150 es la interfaz entre el dispositivo móvil (UE) 110 y la función de aplicación de red (NAF) 120.
La Ub 160 es la interfaz entre el dispositivo móvil (UE) 110 y la función de servidor de arranque (BSF) 130. Esto se especifica en detalle en TS 24.109 (titulado "Interfaz de arranque (Ub) 160 e interfaz de función de aplicación de red (Ua) 150; Detalles del protocolo", actualmente se puede recuperar en http://www.3gpp.org/ftp/Specs/htmlinfo/24109.htm).
Zh/Zh' 180 es la interfaz entre la BSF 130 y el HSS o HLR 140. La interfaz Zh 180 se utiliza con un HSS 140 que es "conocedor de GBA". La interfaz Zh' 180 se utiliza con un HLR o HSS 140 heredado. Las interfaces Zh y Zh' 180 se especifican en detalle en TS 29.109 (titulado "arquitectura genérica de autenticación (GAA); las interfaces Zh y Zn basadas en el protocolo Diameter; etapa 3", actualmente se puede recuperar en http://www.3gpp.org/ftp/Specs/htmlinfo/29109.htm) y TS 29.229 (titulado "Interfaces Cx y Dx basadas en el protocolo Diameter; detalles del protocolo", actualmente se puede recuperar en http://www.3gpp.org/ftp/Specs/html-info/29229.htm).
Zn 170 es la interfaz entre la NAF 122 y la BSF 130: puede utilizar, bien un protocolo de servicios web (SOAP sobre http), o bien el protocolo Diameter (RFC 3588). Esto se especifica en detalle en TS 29.109 (véase más arriba). Hay algunos otros componentes e interfaces definidos dentro de los estándares GAA, pero no se describen en detalle aquí.
Hay varias versiones diferentes de GBA definidas en los estándares. Los tipos de GBA pueden incluir GBA-ME, GBA-U, GBA-SIM, etc. Es posible que la versión llamada "GBA-ME" no requiera personalizaciones especiales de la UlCC, excepto que la UlCC contiene una SIM 3G (una USIM). Sin embargo, se pueden utilizar otras versiones. Puede que sea necesario utilizar la variante 2G de GBA (utilizando una SIM en lugar de una USIM).
Compendio de la invención
Según un primer aspecto, se proporciona un método, como se describe en la reivindicación 1, para el enrutamiento del tráfico de comunicaciones entre un dispositivo máquina a máquina, M2M, conectado a una red de telecomunicaciones y que tiene una identidad de abonado móvil internacional, IMSI, y un servidor, comprendiendo el método las etapas de:
asignar un nombre de punto de acceso, APN, entre una pluralidad de APN basados en la IMSI del dispositivo M2M; y
enrutar, a través del APN asignado, el tráfico de comunicaciones entre el dispositivo M2M y el servidor, en donde el servidor se determina basándose en uno o más de: la IMSI, el APN y una característica de un tráfico de comunicaciones entre el dispositivo M2M y el servidor.
Por lo tanto, el tráfico de comunicaciones de los dispositivos y, en particular, de los dispositivos M2M, puede enrutarse de manera más flexible y pueden realizarse cambios después de que se hayan desplegado los dispositivos M2M.
Opcionalmente, el servidor puede seleccionarse entre una pluralidad de servidores basándose en el protocolo de transporte del tráfico de comunicaciones recibido desde el dispositivo o dispositivo M2M. Por lo tanto, el enrutamiento se puede lograr automáticamente, lo que conduce a una fiabilidad mejorada de las comunicaciones. Preferiblemente, el protocolo del tráfico de comunicaciones puede determinarse a partir del número de puerto. Los puertos pueden estar dedicados a protocolos particulares y, por lo tanto, el número de puerto puede determinar el enrutamiento.
Opcionalmente, el tráfico de comunicaciones puede seleccionarse del grupo que consta de protocolo de aplicación limitada, CoAP, HTTP, CoAPs, HTTPs, UDP y TCP. Se pueden utilizar otros tipos de tráfico.
Opcionalmente, la característica del tráfico de comunicaciones entre el dispositivo M2M y el servidor puede ser que sea un protocolo reconocido o no reconocido.
Opcionalmente, la característica del tráfico de comunicaciones puede seleccionarse del grupo que consta de protocolo de datagramas de usuario, UDP, protocolo de control de transmisión, TCP y SMS.
Ventajosamente, la característica del tráfico de comunicaciones puede ser un identificador de protocolo URL. Por ejemplo, las reglas de enrutamiento pueden basarse en la detección de http://, coap://, https:// o coaps:// en la URL. Preferiblemente, el servidor puede ser uno o más o una combinación de servidores seleccionados entre: un servidor de gestión de dispositivos, DM; un servidor de función de servidor de arranque, BSF; un servidor de arranque DM, un servidor ligero M2M, LWM2M; un servidor de arranque LWM2M; una función de aplicación de red, NAF; un servidor DM; y un servidor BSF. La BSF puede utilizarse para autenticar un secreto compartido y, en particular, puede utilizar el protocolo GBA para hacerlo. El servidor puede ser de cualquier otro tipo. Cuando el servidor es un servidor DM y un servidor BSF combinados, existen ventajas particulares en términos de simplificación de las comunicaciones, pero se pueden utilizar otras combinaciones de servidores (por ejemplo, un servidor de arranque DM y un servidor BSF combinados).
Preferiblemente, el tráfico CoAP puede enrutarse a un servidor DM y el tráfico HTTP puede enrutarse a una BSF; o El tráfico CoAPs o HTTPs se puede enrutar a un servidor DM y el tráfico CoAP o HTTP se puede enrutar a un BSF; o el tráfico CoAP y CoAPs puede enrutarse a un servidor DM y el tráfico HTTP o HTTPs puede enrutarse a un BSF; o
el tráfico seguro puede enrutarse a un servidor DM y el tráfico no seguro puede enrutarse a un BSF. Por lo tanto, el enrutamiento para funciones separadas puede enrutarse automáticamente dependiendo de la funcionalidad requerida. Se pueden realizar otras combinaciones de estas reglas de enrutamiento.
Opcionalmente, el tráfico de comunicaciones UDP se puede enrutar al servidor DM y el tráfico de comunicaciones TCP se puede enrutar al servidor BSF.
Opcionalmente, el servidor puede indicar una dirección o direcciones (por ejemplo, URL) para el servidor o servidores alternativos con los que enrutar el tráfico de comunicaciones. Por lo tanto, el tráfico de comunicaciones puede enrutarse automáticamente a un servidor predeterminado, que, a continuación, puede ser capaz de seleccionar o nominar servidores alternativos. Esto puede utilizarse para fines de balanceo de carga o para enrutar grupos específicos de dispositivos M2M (quizás gestionados por operadores particulares, o tipos de dispositivos M2M) a servidores dedicados.
Opcionalmente, la dirección o direcciones del servidor o servidores alternativos pueden estar contenidas dentro de un indicio de clave previamente compartida (psk) indicada por el servidor o pueden estar contenidas dentro de un mensaje de arranque. De lo contrario, el dispositivo M2M puede ignorar el indicio psk o el mensaje de arranque, pero se puede extraer la información relativa a la dirección del servidor alternativo.
Opcionalmente, el mensaje de arranque puede ser una operación lógica de escritura.
Opcionalmente, la operación lógica de escritura puede realizarse en recursos personalizados. Por ejemplo, los recursos personalizados pueden ser el Id "NAF" o el Id "BSF".
Preferiblemente, el mensaje de arranque puede carecer de cualquier seguridad que provoque un rechazo de la operación de escritura. Esto se puede utilizar para impedir que se implemente el mensaje de arranque pero aun así permitir que el dispositivo M2M derive la dirección o direcciones del servidor.
Opcionalmente, el mensaje de arranque puede protegerse con una clave pública.
Preferiblemente, el mensaje de arranque puede entregarse desde un servidor ligero máquina a máquina, LWM2M. El dispositivo LWM2M puede implementar estándares y protocolos adecuados que habilitan un entorno de comunicación más eficiente.
Opcionalmente, el servidor LWM2M puede comprender además una función de servidor de arranque, BSF. Esto puede simplificar la función del servidor de arranque.
Preferiblemente, la operación lógica de escritura puede ser una escritura en un objeto de seguridad LWM2M u otro objeto dentro del dispositivo M2M.
Opcionalmente, el mensaje de arranque puede entregar credenciales para comunicarse con un servidor de gestión de dispositivos, DM.
Preferiblemente, el método puede comprender además la etapa de entrega desde LWM2M y BSF combinados, un mensaje de información GBA Push, g Pi, que proporciona credenciales para el dispositivo M2M para comunicarse con el servidor DM. Las credenciales de producción pertinentes pueden derivarse, a continuación, del GPI, simplificando aún más la BSF.
Opcionalmente, el enrutamiento puede limitarse a expirar después de una o un número predeterminado de conexiones o está limitado a un período de tiempo.
Opcionalmente, una vez finalizado el enrutamiento, el dispositivo M2M puede enrutarse a un servidor diferente. Opcionalmente, al finalizar el enrutamiento se asigna un APN diferente.
Según un segundo aspecto, se proporciona un sistema como se ha descrito en la reivindicación 11 para enrutar el tráfico de comunicaciones entre un dispositivo máquina a máquina, M2M, conectado a una red de telecomunicaciones y que tiene una identidad de abonado móvil internacional, IMSI, y un servidor, comprendiendo el sistema:
una interfaz configurada para recibir comunicaciones desde el dispositivo M2M; y lógica configurada para: recibir en la interfaz la IMSI del dispositivo M2M, asignar un nombre de punto de acceso, APN, de una pluralidad de APN basados en la IMSI del dispositivo M2M, y
enrutar, a través del APN asignado, el tráfico de comunicaciones entre el dispositivo M2M y el servidor, en donde el servidor se determina basándose en uno o más de: la IMSI, el APN y una característica de un tráfico de comunicaciones entre el dispositivo M2M y el servidor.
Preferiblemente, el sistema puede comprender además una pluralidad de dispositivos M2M configurados para comunicarse con la interfaz y comunicarse con el servidor. Puede haber miles o millones de dispositivos M2M de este tipo, lo que aumenta aún más la necesidad de un enrutamiento más automatizado.
Preferiblemente, el sistema puede comprender además una pluralidad de APN seleccionables mediante la lógica. Estos pueden utilizarse, por ejemplo, para diferentes grupos de dispositivos M2M.
Preferiblemente, el servidor puede ser cualquiera de uno o más seleccionados entre: un servidor de gestión de dispositivos, DM; un servidor de función de servidor de arranque, BSF; un servidor ligero M2M, LWM2M; un servidor de arranque LWM2M; una función de aplicación de red, NAF; y un servidor DM y un servidor BSF combinados.
Preferiblemente, el sistema puede comprender además un servidor DM y/o un servidor BSF.
Opcionalmente, el servidor puede configurarse para indicar una dirección o direcciones de un servidor o servidores alternativos con los que enrutar el tráfico de comunicaciones.
Opcionalmente, la dirección o direcciones del servidor o servidores alternativos pueden estar contenidas dentro de un indicio de clave previamente compartida, PSK, indicado por el servidor o estar contenidas dentro de un mensaje de arranque.
Opcionalmente, el mensaje de arranque puede ser una operación lógica de escritura o una operación lógica de escritura en recursos personalizados.
Opcionalmente, el mensaje de arranque puede carecer de cualquier seguridad que provoque un rechazo de la operación de escritura. En otras palabras, la operación de escritura está destinada a fallar, pero se utiliza como portadora de los detalles de la dirección.
Ventajosamente, el sistema puede comprender además un servidor ligero máquina a máquina, LWM2M, configurado para entregar el mensaje de arranque.
Opcionalmente, el sistema puede comprender además uno o más servidores de gestión de dispositivos, DM, y en donde el mensaje de arranque entrega credenciales para comunicarse con uno o más servidores DM.
Ventajosamente, el servidor LWM2M puede comprender además una función de servidor de arranque, BSF.
Opcionalmente, el LWM2M y el BSF combinados se pueden configurar para entregar un mensaje de información GBA Push, GPI, que proporciona credenciales para que el dispositivo M2M se comunique con el servidor DM.
Los métodos descritos anteriormente pueden implementarse como un programa informático que comprende instrucciones de programa para operar un ordenador. El programa informático puede almacenarse en un medio legible por ordenador.
El sistema informático puede incluir un procesador tal como una unidad central de procesamiento (CPU). El procesador puede ejecutar lógica en forma de programa de software. El sistema informático puede incluir una memoria que incluye un medio de almacenamiento volátil y no volátil. Puede incluirse un medio legible por ordenador para almacenar la lógica o las instrucciones de programa. Las diferentes partes del sistema pueden conectarse utilizando una red (por ejemplo, redes inalámbricas y redes cableadas). El sistema informático puede incluir una o más interfaces. El sistema informático puede contener un sistema operativo adecuado, tal como por ejemplo UNIX, Windows (RTM) o Linux.
Debería observarse que cualquier característica descrita anteriormente se puede utilizar con cualquier aspecto o realización particular de la invención.
Breve descripción de las figuras
La presente invención se puede poner en práctica de varias maneras y ahora se describirán realizaciones a modo de ejemplo únicamente y con referencia a los dibujos adjuntos, en los que:
La fig. 1 muestra un diagrama esquemático de componentes e interfaces con los que se puede utilizar GBA;
La fig. 2 muestra un diagrama esquemático de un ejemplo de una arquitectura que puede utilizarse según la presente invención, en particular cuando se utiliza GBA;
La fig. 3 muestra un diagrama de flujo ilustrativo de comunicaciones intercambiadas dentro de la arquitectura ilustrativa de la fig. 2;
La fig. 4 muestra un diagrama esquemático de un ejemplo de una arquitectura alternativa que puede utilizarse según la presente invención, en particular cuando se utiliza una arquitectura genérica de arranque (GBA);
La fig. 5 muestra un diagrama esquemático de un servidor de gestión de dispositivos (DM) en comunicación con un dispositivo máquina a máquina (M2M);
La fig. 6 muestra un diagrama esquemático de un sistema y método para iniciar comunicaciones entre el servidor DM y el dispositivo M2M de la fig. 5;
La fig. 7 muestra un diagrama esquemático de otro sistema y método para iniciar comunicaciones entre el servidor DM y el dispositivo M2M de la fig. 5; y
La fig. 8 muestra un diagrama de flujo del método de la fig. 7.
Debería observarse que las figuras se ilustran por simplicidad y no necesariamente están dibujadas a escala. Las características similares se proporcionan con los mismos números de referencia.
Descripción detallada de las realizaciones preferidas.
Un dispositivo puede comunicarse de forma segura con un servidor. El dispositivo puede ser un dispositivo máquina a máquina (M2M) o un dispositivo equivalente (por ejemplo, un dispositivo, un dispositivo genérico o específico de comunicación, que incluye uno o más módulos capaces de proporcionar capacidades M2M).
Los aspectos de la arquitectura genérica de autenticación (GAA) y la arquitectura genérica de arranque (GBA) se identifican en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba. En particular, la arquitectura específica en la que se pueden basar el método y el sistema es GBA.
La arquitectura genérica de arranque (GBA) utiliza asociaciones de seguridad existentes entre una red (por ejemplo, una red móvil) y una tarjeta (por ejemplo, una tarjeta SIM o UICC) para derivar una clave que se puede utilizar para la comunicación segura entre el cliente y el servidor. Por consiguiente, si el dispositivo está asociado con dicha tarjeta, así como con el cliente, el método puede utilizar ventajosamente la GBA para derivar los elementos de seguridad (por ejemplo, un secreto compartido) para posibilitar que el cliente asociado con el dispositivo se comunique de forma segura con el servidor. Por consiguiente, el dispositivo podría adaptarse ventajosamente para que esté asociado con la tarjeta y el cliente y utilice GBA para derivar los elementos de seguridad para la comunicación segura con el servidor. Además, como GBA se basa en estándares, el impacto de las modificaciones requeridas puede ser relativamente limitado y la solución general sería muy atractiva (en particular, para los usuarios/propietarios de M2M así como para los operadores de redes y/o proveedores de servicios).
Los dispositivos M2M son diferentes de los dispositivos móviles para los que se ha diseñado originalmente la gestión de dispositivos OMA (tales como teléfonos móviles, portátiles, ordenadores, como se explica en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba), y el uso de GBA (en cualquiera de sus versiones) con M2M no es una implementación sencilla.
Se ha propuesto una variante de GBA, llamada "GBA Push" para proteger un mensaje entre un cliente y un servidor DM en el contexto de la seguridad de gestión de dispositivos OMA, y se identifica en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba. Se ha de observar que, aunque GBA Push y GBA están relacionados, no es trivial utilizar GBA en lugar de GBA Push (y viceversa). Esto se debe a que estas dos arquitecturas tienen algunas diferencias importantes. Primero, en GBA el dispositivo tiene que contactar la BSF para solicitar un RAND y AUTN (y utilizarlo para derivar un Ks_local). Por el contrario, en GBA Push, el cliente no tiene que hablar con la BSF, simplemente recibe un mensaje preparado por la BSF. Además, en GBA no es necesario modificar la interfaz Ua. En GBA Push, la interfaz Ua ha de modificarse de alguna manera para transportar el mensaje push o debe añadirse una nueva interfaz. Por consiguiente, GBA Push no se puede utilizar con un protocolo de aplicación arbitrario. Para GBA Push, el protocolo de aplicación tiene que ser "conocedor de GBA" en algún sentido (por ejemplo, para que pueda transportar los mensajes de información GBA Push (GPI)). En GBA, Ks_local se puede utilizar para derivar varias K<s>_<n>A<f>diferentes (por ejemplo, para diferentes servidores de aplicaciones). En GBA Push, sólo una NAF puede utilizar/confiar en el Ks_local. Por consiguiente, GBA Push es ligeramente menos eficiente que GBA.
La información de GBA Push se describe en 3GPP TS 33.223, sección 5.2.1. La codificación se define en la sección 5.3.5. Véase en particular la tabla 5.2.1.1 y la fig. 5.3.5.1 en 3GPP TS 33.223 V12.0.0 (2013-12) que se puede encontrar en:
http://www.3gpp.org/ftp/Specs/archive/33_series/33.223/33223-c00.zip
Además, como se ha dado a conocer anteriormente, los dispositivos M2M tienen capacidades muy limitadas (por ejemplo, computación, comunicación, vida, etc.) y estas limitaciones hacen que su gestión sea más compleja y difícil de implementar de una manera sencilla. GBA requiere una serie de interfaces y componentes que son difíciles de implementar con M2M (para ver ejemplos y descripciones de estas interfaces y componentes, consulte las secciones siguientes).
Para gestionar de manera más eficiente y segura el dispositivo y/o los servicios proporcionados por (o a través de) el dispositivo, estas interfaces y componentes deben modificarse o adaptarse de otro modo para que puedan funcionar de manera adecuada y efectiva con dispositivos M2M.
Por ejemplo, transportar la interfaz Ub (y el protocolo asociado) a través de dispositivos M2M limitados es muy difícil. Por ejemplo, la interfaz Ub estándar utiliza HTTP y HTTP con resumen. La razón probable para esto es que, como se ha mencionado anteriormente, GBA se ha diseñado teniendo en mente los dispositivos móviles, tales como los teléfonos móviles. Entonces, dado que todos los teléfonos utilizan HTTP y, por lo tanto, todos tienen una pila HTTP, a continuación, HTTP ha sido el protocolo más fácil de utilizar para la interfaz Ub. Sin embargo, esto no es cierto para los dispositivos M2M. Por ejemplo, según el protocolo M2M ligero (LWM2M) (véase más abajo para más detalles), se utiliza un protocolo llamado CoAP en dispositivos M2M, precisamente porque es una alternativa más simple/eficiente a HTTP. Alternativamente, esta interfaz Ub podría tunelizarse, por ejemplo a través de otra interfaz (por ejemplo, la Ua), de manera que se pueda simplificar el sistema.
Adicionalmente, la construcción de todos los componentes necesarios (por ejemplo, el servidor GAA, interfaces) en un dispositivo M2M con capacidad limitada parece ser muy difícil. Por ejemplo, las limitaciones de espacio físico y virtual, así como las limitaciones computacionales, crean problemas considerables para la construcción de los componentes necesarios. Además, es muy difícil tener una o más interfaces entre la aplicación o aplicaciones M2M y una tarjeta en el dispositivo, tal como una UICC. Esto se debe, por ejemplo, al hecho de que la mayoría de los módems M2M no soportan la interfaz o interfaces de bajo nivel requeridas. En general, la integración global de las interfaces y componentes necesarios de GBA con un dispositivo M2M parece muy difícil. Una solución posible, aunque no óptima, podría ser aprovisionar previamente los dispositivos m2m (por ejemplo, teniendo los dispositivos M2M ya diseñados y/o fabricados con los componentes e interfaces necesarios) y los elementos asociados necesarios para el uso de GBA (por ejemplo, siendo la tarjeta capaz de interactuar con el dispositivo M2M) de manera que se pueda utilizar GBA. Hasta la fecha, ningún dispositivo M2M está previamente aprovisionado con estas características.
Además, como se ha observado anteriormente, GBA no se utiliza ampliamente. Hay otras razones por las que GBA no se utiliza ampliamente. Por ejemplo, el uso de GBA requiere soporte en el dispositivo, en la red (por ejemplo, BSF, véase más abajo) y por servicios individuales (que pueden desplegarse, por ejemplo, por un operador móvil o por otras partes). En el caso de uso preferido (transmisión móvil), también se requiere compatibilidad con la tarjeta SIM (ya que utiliza GBA-U). Por consiguiente, la falta de coordinación y voluntad de actuar/cooperar entre las distintas partes involucradas en este despliegue (por ejemplo, fabricantes de dispositivos, operadores móviles, proveedores de servicios) ha bloqueado hasta ahora la implementación de GBA.
Por todas las razones anteriores, se puede utilizar GBA (o una arquitectura similar a GBA, por ejemplo una variante y/o una versión adecuadamente modificada) para habilitar una comunicación segura con un dispositivo (en particular, un dispositivo M2M). La comunicación puede ser entre un servidor y un cliente, estando el cliente asociado con el dispositivo, y en donde esta comunicación puede realizarse para gestionar el dispositivo y/o los servicios proporcionados por (o a través del) el dispositivo. Esto habilita una gestión segura de ese dispositivo y/o de los servicios proporcionados por (o a través del) el dispositivo y crea una combinación nueva e innovadora que produce un efecto sinérgico y proporciona muchas ventajas técnicas.
Por ejemplo, como ya se ha mencionado anteriormente, la GBA proporcionará un nivel de seguridad más alto y muy sólido para las comunicaciones relacionadas con la gestión de dispositivos/servicios con dispositivos M2M, que es un punto muy crítico e importante.
Otra ventaja, además o combinada con la sólida seguridad descrita anteriormente, es la automatización total. Además, un proveedor de servicios M2M no tiene el coste/complejidad de configurar sus propias soluciones de seguridad, ya que la solución puede ser proporcionada directamente por el operador móvil que implementa la solución descrita en esta solicitud. En particular, un proveedor de servicios no tiene que configurar una PKI, emitir certificados, precargar claves en los dispositivos, etc.
Por consiguiente, el método puede comprender además que la provisión de la comunicación segura se basa en una asociación de seguridad entre una red y una tarjeta, estando asociada la tarjeta al dispositivo. Por ejemplo, la tarjeta puede estar incorporada dentro del dispositivo (por ejemplo, soldada en el dispositivo) o proporcionada al dispositivo mediante una conexión adecuada. En general, la tarjeta puede asociarse de cualquier manera adecuada para que exista una asociación entre la tarjeta y el dispositivo. La red puede ser una red móvil o cualquier red equivalente, mientras que la tarjeta puede ser una tarjeta SIM, una UICC o cualquier tarjeta asociada a la red. El método puede comprender además la derivación de un secreto compartido basado en la asociación de seguridad. El método puede comprender además la provisión al cliente y al servidor del secreto compartido así como habilitar la comunicación segura. El servidor puede ser un servidor adaptado para gestionar el dispositivo (por ejemplo, gestionar remotamente el dispositivo, enviar actualizaciones, transferir información hacia y desde el dispositivo, controlar parámetros del dispositivo, etc.) y para gestionar servicios proporcionados por el dispositivo (por ejemplo, el dispositivo se utiliza para encender/apagar y/o atenuar las luces de la calle). El secreto compartido puede ser una clave y/o una disposición de seguridad similar.
El método puede comprender además autenticación entre el cliente y el servidor. La autenticación puede basarse en el secreto compartido. La autenticación se puede realizar a través de un componente de autenticación. La autenticación puede realizarse mediante una primera autenticación entre el cliente y un componente de autenticación y una segunda autenticación entre el servidor y el componente de autenticación. El cliente y el servidor pueden autenticarse de forma independiente mediante un componente de autenticación. Como resultado de que el componente de autenticación autentica al cliente y al servidor, tanto el cliente como el servidor pueden compartir el secreto compartido. La autenticación podrá realizarse mediante el secreto compartido. El secreto compartido puede compartirse entre el cliente y el servidor. Alternativamente, el secreto compartido puede compartirse entre el cliente, el servidor y el componente de autenticación. La autenticación puede resultar implícitamente de que el cliente, el servidor y el componente de autenticación compartan el secreto compartido. El método puede comprender además la derivación de un segundo secreto compartido basándose en el secreto compartido, siendo compartido el segundo secreto compartido entre el cliente y el servidor. Este segundo secreto compartido puede utilizarse, a continuación, para la autenticación como se ha dado a conocer anteriormente.
La obtención del secreto compartido en el cliente puede basarse en un identificador asociado con un componente de autenticación del servidor. El secreto compartido se puede obtener en el servidor a partir del componente de autenticación. La obtención del secreto compartido en el servidor se obtiene basándose en un identificador asociado al secreto compartido. El identificador lo genera el componente de autenticación. El identificador puede ser proporcionado al servidor por el cliente.
Se puede utilizar el protocolo OMA LWM2M para gestionar (así como interactuar con) dispositivos M2M y gestionar servicios proporcionados por dispositivos M2M (como se describe en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema"). Sin embargo, se pueden utilizar otros protocolos de gestión de dispositivos o el método y el sistema se pueden extender a otros servicios M2M (por ejemplo, protegiendo la entrega de SMS binarios).
GBA podría utilizarse ventajosamente junto con LWM2M para, por ejemplo, establecer claves para LWM2M, mientras que al mismo tiempo LWM2M y los procedimientos especificados en el mismo podrían utilizarse para transportar y/o llevar cualquier mensaje y/o comunicación que se relacione con GBA. Por ejemplo, esto se puede hacer mediante el uso de túneles específicos (por ejemplo, Ub) o mensajes de información GBA Push (GPI). El uso de GBA junto con LWM2M crea una combinación nueva e innovadora que produce un efecto sinérgico y proporciona muchas ventajas técnicas. Por ejemplo, permite abordar muchos más dispositivos de gama baja, tales como los dispositivos M2M. Esto se debe, por ejemplo, al uso de un protocolo de gestión de dispositivos adecuadamente optimizado para M2M, en lugar de uno reutilizado a partir del espacio del consumidor (por ejemplo, OMA DM v1, TR-069). Este protocolo optimizado se puede utilizar para transportar mensajes GBA, evitando la necesidad de una pila HTTP separada, y para gestionar parámetros GBA (identificadores de dispositivo y aplicación, vidas útiles, métodos de derivación de claves, etc.). Además, cuando van acompañados de sistemas de red apropiados para proporcionar enrutamiento y descubrimiento automatizados (por ejemplo, del servidor LWM2M y bSf), GBA y LWM2M se combinan ventajosamente para eliminar el coste de la precarga de configuraciones y credenciales, facilitando así dispositivos de bajo coste. GBA con LWM2M soporta de forma segura dispositivos de bajo coste que están desatendidos o no tienen Ul, donde no hay opción para la interacción del usuario (tal como la entrada de un PIN) y donde no hay ningún usuario que sea capaz de detectar y recuperarse de fallos de autenticación (servidor falso, cliente falso o Man In The Middle (intermediario)). Además, g Ba funciona sin requerir ninguna clave pública o procesamiento de certificado en el dispositivo. Esto es particularmente ventajoso en dispositivos más simples, ya que estos dispositivos pueden tener un soporte mínimo de clave pública o errores de implementación al manejar certificados.
Por consiguiente, el secreto compartido puede utilizarse como clave en el estándar LWM2M. Además, los procedimientos estándares LWM2M pueden utilizarse para la transmisión y/o recepción de cualquier comunicación utilizada dentro de la GBA.
El secreto compartido se puede utilizar como clave o secreto compartido dentro del protocolo DTLS (identificado en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba), ya sea cuando el LWM2M se utiliza junto con un protocolo DTLS o cuando el DTLS se utiliza solo o junto con uno o más protocolos.
La comunicación segura puede ser además una comunicación de datos. La comunicación de datos puede ser una comunicación basada en SMS. Se puede utilizar un enlace SMS. La comunicación de datos puede ser una comunicación basada en UDP.
El método puede comprender además el cifrado de una comunicación a través de la comunicación segura de datos. El cifrado se puede realizar utilizando un estándar de cifrado avanzado. La comunicación basada en SMS puede protegerse aún más mediante el uso de un protocolo inalámbrico (OTA), por ejemplo, una estructura segura de paquetes para aplicaciones UlCC. Este protocolo está definido en el estándar ETSi 102.225. El protocolo OTA puede disponerse para proteger la comunicación con la tarjeta de identificación asociada con el dispositivo.
También se ha observado que el protocolo OTA se puede utilizar ventajosamente junto con el estándar LWM2M, en el que el LWM2M se puede utilizar para gestionar parámetros, claves y elementos similares para el protocolo OTA. El uso de OTA con LWM2M no es una implementación sencilla. OTA es una solución diseñada para la seguridad de las tarjetas SIM, ya que presenta algunos desafíos técnicos reales si se utiliza para LWM2M. En particular, si bien existe software escrito para tarjetas SIM y servidores SIM OTA para soportar el estándar ETSI 102.225, no existe un software similar en el espacio de gestión de dispositivos para dispositivos (y, en particular, no para clientes y servidores OMA DM).
Por lo tanto, los fabricantes de dispositivos M2M no tienen un código base que puedan adaptar fácilmente para su uso con estos dispositivos.
Además, el estándar ETSI 102.225 no explica cómo configurar las claves y parámetros para utilizar con el estándar. Simplemente asume que todas las claves y parámetros están precargados y son conocidos tanto por la tarjeta SIM como por el servidor OTA. Aunque esta suposición es aceptable en el espacio SIM, porque las tarjetas SIM pueden equiparse de forma segura con las claves necesarias en la etapa de fabricación y los fabricantes de SIM tienen interfaces con los operadores para comunicar las claves y parámetros necesarios, no se puede decir lo mismo sobre LWM2M, donde esa infraestructura no existe.
Así, el uso de OTA junto con LWM2M crea una combinación nueva e innovadora que produce un efecto sinérgico y proporciona muchas ventajas técnicas. Por ejemplo, es necesario proteger el portador de SMS y hasta ahora no se ha encontrado ninguna solución. El uso de OTA habilita el uso del portador de SMS en LWM2M. Sin él, no sería posible utilizar comunicaciones basadas en SMS en LWM2M y eso limitaría la aplicabilidad del estándar LWM2M general.
Por consiguiente, se pueden utilizar los procedimientos estándar LWM2M para gestionar los parámetros y/o claves utilizadas en el protocolo OTA. El método se puede utilizar además junto con LWM2M, como se ha descrito anteriormente.
También se ha observado que el método descrito anteriormente, implementado utilizando GBA (o una arquitectura similar), se puede utilizar junto con SMS de manera que se pueda emplear GBA para establecer claves para comunicaciones seguras basadas en SMS (por ejemplo, SMS), mientras que al mismo tiempo las comunicaciones basadas en SMS pueden utilizarse para transportar o llevar mensajes asociados con GBA, por ejemplo, llevar mensajes de información GBA Push (GPI). El uso de comunicaciones basadas en SMS junto con GBA crea una combinación nueva e innovadora que produce un efecto sinérgico y proporciona muchas ventajas técnicas. Por ejemplo, GBA se puede utilizar para establecer las claves compartidas que se necesitan para proteger los SMS, mientras se utilizan SMS como transporte para entregar los mensajes GBA necesarios. Además, los SMS utilizados para entregar los mensajes GBA pueden proteger su integridad (y cifrarse parcialmente) utilizando las claves que establecerá GBA, por lo que en ningún momento se depende de SMS no seguros. Esta combinación sinérgica permite el uso de SMS como único portador para el tráfico M2M, algo que de otro modo no sería posible, excepto precargando las claves necesarias para proteger el tráfico de SMS o cambiando a un protocolo diferente para negociar estas claves: Ambas alternativas añadirían complejidad y coste. Por lo tanto, proporcionaría una solución de seguridad muy alta para obtener claves compartidas de manera que la seguridad de las claves no se vea comprometida y, al mismo tiempo, se habilite una comunicación basada en SMS en virtud del aprovisionamiento de las claves.
Por consiguiente, cuando el método se implementa utilizando GBA, la GBA puede utilizarse para establecer claves para la transmisión y/o entrega segura de SMS. Las comunicaciones basadas en SMS pueden utilizarse para la transmisión y/o recepción de cualquier comunicación utilizada dentro de GBA, teniendo en cuenta que estas comunicaciones pueden en sí mismas protegerse utilizando las claves que se derivarán en GBA.
Además de lo anterior, el servidor puede comprender adicionalmente un componente de autenticación de servidor. También, el cliente puede comprender además un componente de autenticación de cliente. El componente de autenticación del servidor puede realizar la autenticación del servidor con el componente de autenticación. El componente de autenticación del cliente puede realizar la autenticación del cliente con el componente de autenticación.
Además, el componente de autenticación puede ser una función de servidor de arranque (BSF), el componente de autenticación del servidor puede ser una función de aplicación de red (NAF) y el componente de autenticación del cliente puede ser un servidor GAA.
El método puede comprender además la comunicación entre el servidor y el cliente para determinar los parámetros de seguridad que se han de utilizar para la comunicación segura, en donde la comunicación se realiza utilizando un protocolo de gestión de dispositivos (por ejemplo, GBA). La comunicación segura puede ser para uso en el protocolo de gestión de dispositivos.
En una realización adicional, se proporciona un método para habilitar una comunicación segura para su uso en un dispositivo y/o protocolo de gestión de servicios/aplicaciones, siendo la comunicación segura entre un servidor y un cliente, estando el cliente asociado con un dispositivo, requiriendo la comunicación segura que se acuerden parámetros de seguridad entre el cliente y el servidor, comprendiendo el método la comunicación entre el servidor y el cliente para acordar los parámetros de seguridad, en donde la comunicación se realiza utilizando el protocolo de gestión del dispositivo. El dispositivo puede ser un dispositivo M2M.
En una realización adicional, se proporciona un aparato, sistema, módulo o red para habilitar una comunicación segura con un dispositivo, siendo dicha comunicación entre un servidor y un cliente, estando asociado el cliente con el dispositivo. Además, el aparato, sistema, módulo o red puede incluir además medios para realizar cualquiera de las etapas o características de los métodos descritos anteriormente. El dispositivo puede ser un dispositivo M2M. En una realización adicional, se proporciona un aparato, sistema, módulo o red para habilitar una comunicación segura para su uso en un dispositivo y/o protocolo de gestión de servicios/aplicaciones, siendo la comunicación segura entre un servidor y un cliente, estando asociado el cliente con un dispositivo, requiriendo la comunicación segura que se acuerden parámetros de seguridad entre el cliente y el servidor, comprendiendo el método la comunicación entre el servidor y el cliente para acordar los parámetros de seguridad, en donde la comunicación se realiza utilizando el protocolo de gestión del dispositivo. Además, el aparato, sistema, módulo o red puede incluir adicionalmente medios para realizar cualquiera de las etapas o características de los métodos descritos anteriormente. El dispositivo puede ser un dispositivo M2M.
En una realización adicional, se proporciona un cliente que incluye cualquier medio, característica o funcionalidad correspondiente a los medios, características o funcionalidades relativas al cliente como se ha citado anteriormente por cualquiera de los métodos descritos más arriba.
En una realización adicional, se proporciona un servidor que incluye cualquier medio, característica o funcionalidad correspondiente a los medios, características o funcionalidades relativas al servidor como se ha citado anteriormente mediante cualquiera de los métodos descritos más arriba.
En una realización adicional, se proporciona un dispositivo que comprende una tarjeta y un cliente, en donde el dispositivo está dispuesto para habilitar una comunicación segura, siendo la comunicación segura entre un servidor y el cliente, en donde la provisión de la comunicación segura se basa en una asociación de seguridad entre una red y una tarjeta, el cliente puede comprender cualquier medio, característica o funcionalidad correspondiente a los medios, características o funcionalidades relativas al cliente como se ha citado anteriormente en cualquiera de los métodos descritos más arriba. El dispositivo puede ser un dispositivo M2M.
En una realización adicional, se proporciona un servidor dispuesto para habilitar la comunicación segura con un dispositivo, siendo la comunicación segura entre el servidor y un cliente asociado con el dispositivo, en donde la provisión de la comunicación segura se basa en una asociación de seguridad entre una red y una tarjeta, estando asociada la tarjeta con el dispositivo. El servidor puede comprender cualquier medio, característica o funcionalidad correspondientes a los medios, características o funcionalidades relativas al servidor como se ha citado anteriormente en cualquiera de los métodos descritos más arriba. El dispositivo puede ser un dispositivo M2M. En una realización adicional, se proporciona un sistema para habilitar la comunicación segura con un dispositivo, siendo dicha comunicación entre un servidor y un cliente, estando asociado el cliente con el dispositivo, en donde la provisión de la comunicación segura se basa en una asociación de seguridad entre una red y una tarjeta, estando asociada la tarjeta con el dispositivo. El dispositivo puede ser un dispositivo M2M.
En una realización adicional, se proporciona un método para habilitar la comunicación segura de datos con un dispositivo, siendo la comunicación entre un servidor y un cliente asociado con el dispositivo, en donde la seguridad de la comunicación se habilita mediante un secreto de arranque. El dispositivo puede ser un dispositivo M2M. El protocolo de seguridad se puede utilizar para proteger la comunicación de datos. El secreto de arranque se puede utilizar para obtener los elementos de seguridad utilizados para el protocolo seguro. El secreto de arranque puede ser un secreto previamente compartido, siendo dicho secreto proporcionado directamente al servidor y al cliente. El secreto previamente compartido puede proporcionarse permanentemente al servidor y al cliente (por ejemplo, aprovisionando previamente al cliente y/o al servidor con dicho secreto previamente compartido, por ejemplo, en la etapa de fabricación o antes de que el cliente y/o el servidor se utilicen en un sistema). El secreto previamente compartido puede ser un secreto previamente compartido sólido y de alta entropía o un secreto previamente compartido temporal de baja entropía. El secreto de arranque puede basarse en una clave pública o en un método basado en certificados. El secreto de arranque se puede proporcionar a través de un servidor de arranque. Los elementos de seguridad pueden ser claves y/o disposiciones similares bien conocidas en la técnica.
La comunicación puede ser una comunicación basada en SMS. El protocolo de seguridad está definido por ETSI TS 102.225. El método puede utilizar el enlace de SMS. El dispositivo puede estar asociado además con una tarjeta, y la seguridad de la comunicación de datos puede controlarse por medio de la tarjeta. Cualquier comunicación entrante basada en SMS puede descifrarse y/o comprobarse mediante la tarjeta, y/o cualquier comunicación saliente basada en SMS puede cifrarse y/o comprobarse mediante la tarjeta.
La comunicación puede ser una comunicación basada en UDP. El protocolo de seguridad puede ser un protocolo DTLS.
La comunicación segura de datos puede proporcionarse a través de una interfaz de comunicación. La interfaz de comunicación se puede utilizar para gestionar el dispositivo o para gestionar las operaciones de arranque.
La comunicación de datos puede realizarse según el protocolo LWM2M.
En una realización adicional, se proporciona un aparato, sistema, módulo o red para habilitar la comunicación segura de datos con un dispositivo, siendo la comunicación entre un servidor y un cliente asociado con el dispositivo, en donde la seguridad de la comunicación se habilita mediante un secreto de arranque. El dispositivo puede ser un dispositivo M2M.
En una realización adicional, se proporciona un método para recuperar elementos de seguridad necesarios para habilitar la comunicación segura de datos con un dispositivo, siendo la comunicación entre un servidor y un cliente asociado con el dispositivo, en donde los elementos de seguridad se recuperan utilizando un protocolo de arranque. El dispositivo puede ser un dispositivo M2M. El protocolo de arranque puede recuperar los elementos de seguridad en una sesión segura. La sesión puede protegerse basándose en un protocolo de seguridad. El protocolo de seguridad puede ser un protocolo DTLS. El protocolo de arranque puede estar basado en GBA. La comunicación de datos puede ser una comunicación basada en SMS. El protocolo de arranque puede ser un protocolo de arranque LWM2M. Los elementos de seguridad pueden ser claves y/o disposiciones similares bien conocidas en la técnica. En una realización adicional, se proporciona un aparato, sistema, módulo o red para habilitar la comunicación segura de datos con un dispositivo, siendo la comunicación entre un servidor y un cliente asociado con el dispositivo, en donde los elementos de seguridad se recuperan utilizando un protocolo de arranque. El dispositivo puede ser un dispositivo M2M.
La comunicación segura puede tener el propósito de gestionar el dispositivo y/o el cliente y/o los servicios (por ejemplo, proporcionados por el dispositivo) por parte del servidor. Tanto el dispositivo como el servidor pueden ser máquinas (es decir, que no requieren ninguna intervención humana para funcionar). Cuando el dispositivo sea una máquina, se podrá utilizar el servidor para gestionarlo. Nuevamente, la gestión se puede realizar sin ninguna intervención humana (por ejemplo, automáticamente).
Como se ha dado a conocer anteriormente, la solución podría utilizarse junto con el protocolo LWM2M, pero la solución podría extenderse a otros protocolos de gestión de dispositivos o a otros servicios M2M (por ejemplo, asegurando la entrega de SMS binarios). En particular, y como se ha dado a conocer anteriormente, el uso de la solución junto con un protocolo específico de M2M, tal como LWM2M, permite que la solución sea muy eficiente cuando se utiliza con dispositivos M2M y, en particular, cuando se utiliza para gestionar el dispositivo y/o los servicios proporcionados por (o a través del) el dispositivo. En otras palabras, todas las ventajas mencionadas anteriormente se mejoran y optimizan aún más cuando la solución se utiliza junto con un protocolo específico de M2M.
Además, también se proporciona cualquier aspecto o combinación de aspectos según cualquiera de las reivindicaciones.
También se proporciona cualquier combinación de las características descritas en relación con cualquiera de los aspectos, incluso si no se da a conocer explícitamente.
Con referencia a la fig. 2, se muestra una arquitectura (100) ilustrativa que puede implementarse, en particular cuando se utiliza GBA. Un dispositivo 110 (en el ejemplo, un dispositivom2my/o un equipo de usuario) está asociado con una tarjeta 112 (en el ejemplo, una UICc) y un cliente 116 (en el ejemplo, un cliente de gestión de dispositivos (DM). Obsérvese que este cliente también podría ser un cliente LWM2M, es decir, un cliente que puede gestionar el dispositivo en sí y los servicios/aplicaciones proporcionados por el dispositivo, por ejemplo, control de activos). El dispositivo 110 también está asociado con un componente 114 de autenticación de dispositivo (en el ejemplo, un servidor GAA). Además, se proporciona un servidor 120 (en el ejemplo, un servidordM), el servidor asociado con un componente 122 de autenticación de servidor (en el ejemplo, una función de aplicación de red (NAF)). Además, se proporciona un componente 130 de autenticación (en el ejemplo, una función de servidor de arranque (BSF)) y un registro 140 (en el ejemplo, un HLR o HSS). Además, se proporcionan cuatro interfaces diferentes para la comunicación entre los diversos componentes, en particular la interfaz 150 Ua entre el dispositivo 110 y el servidor 120, la interfaz 160 Ub entre el dispositivo 110 y el componente 130 de autenticación, la interfaz 170 Zn entre el componente 130 de autenticación y el servidor 120, y la interfaz Zh/Zh' entre el componente 130 de autenticación y el registro 140.
En particular, con referencia a GBA, el documento TS 33.220 define los siguientes componentes e interfaces, que se muestran en la fig. 2. NAF, la "función de aplicación de red", es un componente del lado del servidor de una aplicación que puede protegerse utilizando GBA. En una realización preferida, la NAF puede ser un componente de software dentro de un servidor de gestión de dispositivos (DM).
Algunos aspectos de BSF, HLR/HSS, UE, Ua, Ub, Zh/Zh' y Zn se proporcionan en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba.
Tras la autenticación con éxito del dispositivo 110, la BSF 130 deriva el secreto compartido Ks_NAF, que es recuperado por la NAF. En una realización preferida, lo más probable es que la BSF 130 esté en un servidor separado del HLR/HSS 140, pero dentro de un clúster de plataforma M2M.
El HLR/HSS puede ser "conocedor de GBA" (para que almacene detalles de la suscripción de un usuario de GBA) o puede ser un componente heredado. En una realización preferida, el HLR/HSS sería el HLR o HSS de un operador móvil M2M (es decir, uno dedicado específicamente a dar servicio a conexiones M2M). El UE 110 es, en la solución propuesta, un dispositivo M2M.
En una realización preferida, la Ua es la interfaz entre un cliente 116 de gestión de dispositivos y un servidor 120 de gestión de dispositivos.
En una realización preferida, la Ub sería la interfaz entre el componente 114 de "Servidor GAA" del dispositivo y la BSF 130.
En una realización preferida, se utiliza la interfaz Zn.
En la solución propuesta, esta interfaz está entre el servidor 120 de gestión de dispositivos y la BSF 130. La versión WS de la interfaz permitiría la colocación de un servidor DM en múltiples ubicaciones (no solo en el clúster de plataforma/operador M2M) y permitiría NAF futuros en múltiples ubicaciones.
Con referencia a la fig. 3, ahora se describe el procedimiento para configurar la comunicación segura según la presente invención, en particular cuando se utiliza GBA.
En 205, el UE 110 contacta a través de la interfaz Ua con la NAF 122 (en la realización descrita, el cliente 116 de gestión de dispositivos contacta con el servidor 122 de gestión de dispositivos) y descubre que la NAF requiere que adquiera un secreto compartido utilizando GBA. Esto podría ser porque no existe ningún secreto, o el secreto existente ha caducado, o, de otro modo, la NAF lo considera inválido.
La interfaz exacta y el método de comunicación pueden ser específicos de la aplicación en cuestión. A continuación se da a conocer una posible interfaz y método de comunicación para M2M ligeros de OMA.
A través de la interfaz UE interna desde el cliente DM al servidor GAA: en 210, el cliente 116 DM solicita al servidor 114 GAA obtener un secreto compartido. Presenta un identificador para la NAF correspondiente (NAF_Id).
A través de la interfaz Ub: en 215, el UE 110 se pone en contacto con la BSF (el servidor 114 GAA se pone en contacto con la BSF 130). Esta puede ser una solicitud GET http básica. El UE presenta una "IMPI" (equivalente a una IMSI) o una "TMPI" (equivalente a una TMSI) por razones de anonimato, si hay alguna disponible.
A través de la interfaz Zh o Zh': en 220, la BSF 130 solicita un vector de autenticación del HLR/HSS 140. En 225, el HLR/HSS 140 devuelve un vector nuevo, que consiste en un RAND, AUTN, XRES, CK e IK, por ejemplo.
La BSF 130 genera un identificador de transacción (B-TID) y pasa (230) el B-TID junto con el RAND y el AUTN de regreso al UE 110. También puede indicar la vida útil del B-TID y la clave asociada.
A través de la interfaz UE interna desde el servidor GAA a la UlCC: en 235, el servidor 114 GAA reenvía el RAND y el AUTN a la UlCC 112 que valida el AUTN. Si el AUTN es válido, a continuación, se autentica a la BSF 130. En 240, la UlCC 112 devuelve un RES, CK e IK al servidor 114 GAA.
En 245, el UE 110 (Servidor 114 GAA) contacta nuevamente con la BSF 130, utilizando el RES resultante para la autenticación de HTTP con resumen (que se identifica en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba).
La BSF 130 verifica HTTP con resumen utilizando XRES. Si coincide, a continuación, el UE 110 se ha autenticado correctamente. La BSF 130 almacena la tupla <IMPI, B-TID, RAND, CK, IK> y le dice en 250 al UE 110 que la autenticación ha sido correcta. El UE 110 almacena <B-TID, RAND, CK, IK>.
A través de la interfaz 110 de UE interna desde el cliente 116 DM al servidor 114 GAA: el UE 110 (servidor 114 GAA) deriva un secreto Ks_NAF utilizando CK, IK, RAND, IMPI y NAF_Id. En 255, pasa Ks_NAF y el B-TID de regreso al cliente 116 DM.
A través de la interfaz Ua nuevamente: en 260, el UE 110 (Cliente 116 DM) contacta con la NAF (Servidor 122 DM) y presenta B-TID como se ha recuperado anteriormente.
A través de la interfaz Zn: en 265, la NAF 122 entra en contacto con la BSF 130 y presenta BTID. La BSF 130 autentica la NAF, deriva la Ks_NAF correspondiente y en 270 la devuelve a la NAF, junto con un indicador de la vida útil de la clave.
El UE 110 (cliente 116 DM) y NAF (servidor 122 DM) ahora comparten Ks_NAF. Pueden utilizarlo directamente o derivar sus propias claves de sesión para una mayor comunicación.
Nuevamente, la interfaz exacta y el método de comunicación pueden ser específicos de la aplicación en cuestión. A continuación se da a conocer una posible interfaz y método de comunicación para M2M ligeros de OMA.
Como se ha mencionado anteriormente, la solución podría utilizarse junto con el estándar LWM2M. Este estándar puede verse como un sucesor de los estándares de gestión de dispositivos OMA existentes (OMA DM 1.0 a 1.3), pero altamente optimizado para dispositivos de tipo máquina de gama baja y con un alcance de gestión extendido más allá del dispositivo en sí, incluyendo la gestión de servicios proporcionados por el dispositivo M2M, tal como el control de activos. Esto contrasta, por ejemplo, con OMA DM 2.0, que es el sucesor de dispositivos de consumo como teléfonos inteligentes, tabletas, etc. Otros estándares de gestión de dispositivos ampliamente utilizados incluyen TR-069, que se ha desarrollado por Broadband Forum para gestionar los equipos de instalaciones del cliente (en particular módems DSL).
El flujo ilustrativo descrito con referencia a la fig. 3 es muy genérico y puede utilizarse con muchos tipos diferentes de protocolos de gestión de dispositivos (u otros protocolos de aplicación). Como puede verse, muchos detalles de la interfaz Ua están fuera del alcance de 3GPP y se dejan para que otros estándares los completen (o se dejan a implementaciones propietarias). Sin embargo, la integración con el estándar LWM2M es posible, como se describe en estos ejemplos. Según la especificación (véase más arriba), la seguridad para OMA LWM2M se basa en DTLS v1.2 (véase más arriba) y CoAP (véase más arriba). Tanto el cliente como el servidor deben soportar DTLS de clave previamente compartida (por ejemplo, véase la sección 7.1.1, página 41), mientras que la compatibilidad con la autenticación basada en certificados es sólo opcional. Esto significa que una clave derivada de GBA (Ks_NAF) podría utilizarse como una clave previamente compartida DTLS y funcionaría con cualquier par de cliente DM/servidor DM.
Se hace referencia al enfoque general para TLS de clave previamente compartida en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba. Los protocolos GBA y TLS-PSK funcionan bien juntos. En 205 se ha descrito anteriormente, el mensaje "saludo al servidor " contiene un campo donde el servidor puede indicar que soporta el arranque de GBA y, en respuesta, el cliente puede proporcionar un identificador (B-TID) para una clave de arranque (260) lista. O si el cliente aún no tiene una clave de arranque, le pide al servidor GAA que obtenga una, antes de reanudar el "saludo al cliente" y el "saludo al servidor" en 260. El uso de Ks_NAF para derivar claves de sesión se especifica completamente dentro del protocolo TLS-PSK. La especificación 3GPP asume HTTP/TLS, pero el enfoque básico es el mismo para CoAP/DTLS.
Para mejorar la coherencia con el perfil OMA de GBA, es posible que la especificación LWM2M deba definir un "identificador de protocolo" para la clave previamente compartida DTLS y que OMNA la registre (véase la sección 5.2.1 del perfil<o>M<a>GBA, versión aprobada 1.1 - 31 de julio de 2012 encontrado en: http://technicai.openmobilealliance.org/Technical/release_program/sec_cf_archive.aspx).
Aparte de los aspectos GBA, el dispositivo M2M puede configurarse para soportar la seguridad de OMA LWM2M, a la que se hace referencia en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba.
Aspectos adicionales
1. Desarrollo de dispositivos para GBA
Como puede verse en la fig. 2 y en la fig. 3, el dispositivo M2M puede contener varios componentes internos. Debería soportar un cliente DM que sea "conocedor de GBA", así como un componente de "Servidor GAA".
El componente del servidor GAA debería soportar interfaces internas para el cliente DM y la tarjeta SIM (UICC), así como la interfaz Ub externa para BSF. La interfaz con la UICC puede ser particularmente desafiante, ya que es posible que el dispositivo M2M no exponga una API existente para permitir que el software del dispositivo envíe comandos a la UlCC. Una posibilidad (que puede utilizarse) es que el módem exponga comandos AT. Sin embargo, es posible que esto no sea a un nivel suficientemente bajo (AT+CSIM permite que las APDU sin procesar se comuniquen con la UlCC) en todos los casos. Además, puede haber problemas de seguridad: si bien el servidor GAA debe ser capaz de conectarse con UlCC, las aplicaciones generales instaladas en el dispositivo no deberían ser capaces de utilizar esta interfaz, ya que eso podría permitir que partes externas se hagan pasar por el dispositivo (y generar fraude en la red celular). Por lo tanto, la API de la tarjeta SIM debería tener privilegios, además de tener un nivel suficientemente bajo para ser utilizable.
2. Tunelización Ub o GBA Push
La interfaz de BSF se basa en la autenticación http y HTTP con resumen. Una alternativa puede ser la "tunelización" de la interfaz Ub dentro de la interfaz Ua, de manera que el dispositivo sólo necesite soportar el protocolo CoAP (también no HTTP).
Una alternativa relacionada es utilizar la variante GBA "Push" y transportar mensajes push (interfaz Upa) dentro de la interfaz Ua. Ambos requerirían identificar comandos y parámetros adecuados en la interfaz Ua (es decir, el protocolo de gestión de dispositivos relevante) para transportar el túnel o enviar mensajes. Las interfaces y el flujo de mensajes para GBA push se describen a continuación (véase también 3GPP TS 33.223, titulado "seguridad 3G; arquitectura de autenticación genérica (GAA); Función de arquitectura genérica de arranque (GBA) Push, actualmente se puede recuperar en http://www.3gpp.org/ftp/Specs/html-info/33223.htm).
Con referencia a la fig. 4, a continuación se muestra un ejemplo de procesamiento y flujo de mensajes para GBA Push:
1. Una NAF establece una NAF SA compartida con un UE que está registrado para servicios Push. Conoce la identidad del suscriptor.
2. El Push-NAF genera la solicitud GPI (información GBA Push) y envía la solicitud GPI a la BSF.
3. Al recibir la solicitud de la NAF, la BSF comprueba que la NAF esté autorizada y resuelve el identificador de abonado solicitado en un identificador privado (por ejemplo, IMSI).
4. La BSF recupera un nuevo AV (vector de autenticación) y el GUSS (GBA, configuraciones de seguridad de usuario) del abonado desde el HSS.
5. El HSS envía el AV y el GUSS a la BSF.
6. Cuando la BSF recibe la respuesta AV del HSS, genera las claves NAF basadas en el NAF_Id solicitado y crea la respuesta GPI relevante.
7. La BSF envía la respuesta GPI a la NAF.
8. La NAF almacena la información recibida junto con otra información del usuario en una NAF SA.
9. A continuación, la NAF reenvía la GPI al UE a través de Upa utilizando el mecanismo de transporte seleccionado y la dirección de transporte dada.
10. Cuando el UE recibe el mensaje que contiene la GPI, procesa la GPI como para la GBA normal, y almacena las NAF SA correspondientes.
El UE y la NAF ahora están listos para utilizar la NAF SA establecida.
El documento TR33.223 especifica que Upa es una nueva interfaz separada de Ua: "se introduce un nuevo punto de referencia Upa entre la NAF y el UE" (sección 4.2.1). Como tal, la interfaz Ua no debería saber si se está utilizando GBA o GBA-push.
3. Aprovisionamiento de la dirección de la BSF y la NAF
La dirección de la BSF (http URL) puede estar precargada cuando se fabrica el dispositivo. Podría ser gestionado por el propio dispositivo, lo que parecería crear un problema del "huevo y la gallina", pero el servidor DM podría, por ejemplo, proporcionar una dirección para una BSF aceptable en saludo al servidor (ServerHello). O el operador móvil M2M podría enrutar el tráfico http a una dirección BSF predeterminada. De manera similar, es posible que sea necesario precargar la ubicación del servidor DM preferido, o el operador móvil M2M podría enrutar el tráfico CoAP a una dirección de servidor DM predeterminada.
4. Variantes de GBA (GBA-ME. GBA-U. GBA-SIM, etc.)
Se hace referencia a varias versiones diferentes de GBA en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema". GBA-U tiene ventajas de seguridad, pero también ventajas logísticas: permite una vida útil más larga para el B-TID ya que la clave derivada se almacena de forma más segura. Permite la retención segura de Ks durante los ciclos de apagado, por ejemplo. GBA-U requiere soporte específico de la UICC, por lo que tendría un (modesto) incremento en el coste. Dado que los dispositivos M2M normalmente cuentan con una nueva UICC de todos modos en la fabricación, es un coste de software/desarrollo más que un coste de hardware. También, en un modelo con una UlCC personalizada, esto puede permitir una solución que utilice comandos AT restringidos para el módem, en lugar de<a>T+CSIM completo.
5. Ubicación de la NAF (servidor DM) y tipo de interfaz Zn
El ejemplo de arquitectura permite que haya varios servidores DM en diferentes ubicaciones: podría ser parte de un clúster de plataforma M2M (por ejemplo, operador móvil M2M), o alojado en otro lugar por un operador de red/proveedor de servicios, o quizás por un cliente de dicho operador/proveedor. Es posible que la BSF deba estar ubicada dentro de una zona desmilitarizada (DMZ) con cortafuegos, o tal vez conectada a través de un proxy http en la DMZ (permitiendo así el acceso al servicio web http externo desde las NAF), y, a continuación, ejecutaría la interfaz Diameter al HLR/HSS. Puede que no sea deseable exponer una interfaz http directamente en el servidor que soporta el HLR, o tunelizar Diameter a través de firewalls. Sin embargo, si el servidor DM es en sí mismo parte del clúster de la plataforma M2M, a continuación, esto puede ser un exceso de ingeniería. Posiblemente, a continuación, resulte aceptable una solución Diameter para la interfaz Zn.
6. Uso de la interfaz Zh o Zh'
Idealmente, el HLR puede actualizarse a un HSS completo con soporte para el punto de referencia Zh. Sin embargo, si el HLR/HSS sólo soporta Zh', a continuación, la BSF necesitará ser más complicada y asumir algunas de las funciones de gestión de suscripciones (perfiles, vida útil, políticas de seguridad) típicamente asociadas con el HSS.
7. Desarrollo del componente NAF
Si bien la funcionalidad NAF parece bastante sencilla, será necesario desarrollarla para cada servidor DM utilizado y para cada aplicación adicional que utilice GBA.
Las claves GBA podrían utilizarse para proteger SMS (por ejemplo, cifrar/proteger la integridad de SMS utilizando una interfaz de paquetes segura, por ejemplo, como eTs I TS 102.225 que se utiliza para SIM OTA). Es probable que este canal de SMS sea más eficiente que DTLS.
Además, independientemente de GBA, un protocolo de SMS seguro podría vincularse a un protocolo de gestión de dispositivo y/o servicio, a saber: utilizando un protocolo de SMS seguro (por ejemplo, diseñado originalmente para SIM OTA (102 225)), pero ahora adaptado para comunicaciones LWM2M, combinado con el uso del protocolo LWM2M para definir (y gestionar) los parámetros necesarios para el protocolo SMS seguro (es decir, los Klc, KID, SPI, TAR y claves relevantes).
GBA podría utilizarse para derivar las claves de forma segura.
En los párrafos siguientes se describen aspectos adicionales y características ventajosas o preferibles.
LWM2M necesita una solución de seguridad para el portador de SMS. Sin una solución, los SMS no podrán utilizarse como portadores, lo que limitará gravemente el alcance de LWM2M. Una solución a este problema es utilizar la seguridad SIM OTA (por ejemplo, véase TS 102225).
TS 102.225 se basa en que las claves y los parámetros ya estén acordados entre el cliente y el servidor. Sin embargo, es difícil precargarlos en los dispositivos cliente LWM2M y garantizar que se envíen a los servidores, porque no existe una infraestructura actual para hacerlo. No tendría sentido entregar las claves y parámetros a través de SMS no seguros.
Existen varias soluciones propuestas para entregar estas claves y parámetros de forma segura.
En una primera solución, se proporciona conmutación de portador a UDP/Coap y ejecución de DTLS. La sesión DTLS se puede utilizar para proteger el protocolo de arranque LWM2M. El arranque LWM2M se puede utilizar para configurar las claves y los parámetros del TS 102.225 de forma segura. Obsérvese que los recursos/objetos gestionados deben definirse para permitir que el servidor de arranque los actualice; El formato de estos recursos se especifica en los párrafos numerados a continuación.
En una segunda solución, se prevé confiar en una tarjeta SIM (UICC) a la que ya se le han proporcionado claves y parámetros, y utilizar esta tarjeta para terminar la seguridad TS 102225. Obsérvese que, debido a que esta solución proporciona un canal seguro, se puede utilizar el mismo canal para entregar otras claves y parámetros.
En una tercera solución, se proporciona el uso de GBA para configurar las claves y los parámetros. Esto funciona porque la GPI (información GBA Push) se puede entregar a través de SMS no seguros. Por lo tanto, no es necesario tener una clave inicial para proteger el SMS. (Obsérvese que la entrega de parámetros como Kic, KID, SPI y TAR no es obvia, pero estos son sólo 6 bytes y hay campos en la GPI, por ejemplo, App_Lbl, NAF_Id, P-TID que podrían utilizarse para transportar esta información.)
Se proporcionan más detalles en los párrafos numerados a continuación.
Se hace referencia a la seguridad del canal UDP para [CoAP] en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba.
Dado que el protocolo LWM2M utiliza DTLS para autenticación, integridad de datos y para fines de confidencialidad, el cliente LWM2M y el Servidor LWM2M deberían mantener una sesión DTLS en uso durante el período más largo que se pueda lograr de manera segura sin correr el riesgo de comprometer las claves y los contadores de la sesión. Si una sesión persiste durante los ciclos de suspensión, debería utilizarse un almacenamiento cifrado y con integridad protegida para las claves y los contadores de sesión.
Obsérvese que la relación Cliente-Servidor de DTLS (es decir, quién ha iniciado el protocolo de enlace) es independiente de la relación Cliente-Servidor de LWM2M.
Teniendo en cuenta que cualquier dispositivo con un cliente LWM2M puede ser gestionado por cualquier servidor LWM2M y servidor de arranque LWM2M, la elección de conjuntos de cifrado no se limita a la lista definida en la sección 9 de [CoAP]. Debido a la naturaleza sensible de la información de arranque, se debe tener especial cuidado para garantizar la protección de esos datos, incluyendo las limitaciones y dependencias dentro de una relación Cliente LWM2M/Servidor de arranque según el modo de seguridad adoptado.
Con respecto al arranque desde una tarjeta inteligente, se debe tener el mismo cuidado y se debería establecer un canal seguro entre la tarjeta inteligente y el dispositivo LWM2M como se describe en el apéndice H de OMA LWM2M en referencia al protocolo de canal seguro de GlobalPlatform 03 (SCP 03) enmienda D v1.1 de septiembre de 2009. El material de claves utilizado para proteger el intercambio de información utilizando una sesión DTLS se puede obtener utilizando uno de los modos de arranque a los que se hace referencia en "detalles de los estándares y tecnologías 3GPP utilizados para implementar aspectos del método y sistema" más arriba.
Los recursos (es decir "modo de seguridad", "clave pública o identidad", "clave pública o identidad del servidor" y "clave secreta") en el objeto de seguridad LWM2M que están asociados con el material de claves se utilizan ya sea 1) para proporcionar seguridad del canal UDP en interfaces de "registro de dispositivo", “gestión del dispositivo y habilitación de servicios" y "reportes de información" si la instancia del objeto de seguridad LWM2M se relaciona con un servidor LWM2M, o,
2) para proporcionar seguridad de canal en la interfaz de arranque si la instancia del objeto de seguridad LWM2M se relaciona con un servidor de arranque LWM2M.
Los clientes LWM2M DEBEN estar aprovisionados directamente para su uso con un servidor LWM2M de destino (modo de arranque de configuración previa del fabricante) o bien ser aprovisionados para un arranque seguro con un servidor de arranque LWM2M. Cualquier cliente LWM2M que soporta el modo de arranque iniciado por el cliente o el servidor DEBE soportar al menos uno de los siguientes métodos seguros:
1) Arranque con un secreto previamente compartido sólido (alta entropía), como se describe en la sección 7.1 de OMA LWM2M. Los conjuntos de cifrado definidos en esta sección NO DEBEN utilizarse únicamente con un secreto previamente compartido de baja entropía.
2) Arranque con un secreto previamente compartido temporal y de baja entropía (tal como un PIN, una contraseña y un número de serie privado) utilizando el conjunto de cifrado TLS_E<c>DHE_PSK_WITH_AES_128_CBC_SHA256, como se define en RFC5489.
3) Arranque con una clave pública o un método basado en certificados (como se describe en las secciones 7.1.2 y 7.1.3 de OMA LWM2M). El cliente LWM2M DEBE utilizar un par de claves únicas, una que sea exclusiva para cada cliente LWM2M.
Para una interoperabilidad total, un servidor de arranque LWM2M DEBERÁ soportar todos estos métodos.
NOTA: Los métodos de seguridad anteriores también pueden ser utilizados por el servidor de arranque LWM2M para aprovisionar Klc y KID para la seguridad del canal SMS (véase a continuación la seguridad del canal SMS). Seguridad del canal SMS
Modo de estructura de paquetes seguros SMS
La estructura de paquetes seguros se basa en [3GPP TS 31 115]/[ETSI TS 102225], que define paquetes seguros para diferentes mecanismos de transporte. La solución se ha diseñado originalmente para proteger estructuras de paquetes para aplicaciones basadas en UlCC; sin embargo, para LWM2M es adecuado para proteger la carga útil de SMS intercambiada entre el cliente y el servidor.
El modo de estructura de paquetes seguros SMS especificado en esta sección DEBE ser soportado cuando se utiliza el enlace SMS.
Un cliente LWM2M que utiliza el enlace SMS DEBE ser aprovisionado directamente para su uso con un servidor LWM2M de destino (modo de arranque de configuración previa del fabricante o aprovisionamiento de tarjeta inteligente) o bien ser capaz de arrancar a través del enlace UDP.
El terminal para el canal de SMS (entrega de SMS terminados en dispositivos móviles y envío de SMS originados en dispositivos móviles) DEBERÁ estar en la tarjeta inteligente o en el dispositivo. Cuando el dispositivo cliente LWM2M no soporta una tarjeta inteligente, el terminal está en el dispositivo cliente LWM2M.
Un cliente, servidor o servidor de arranque LWM2M que soporta el enlace SMS DEBERÁ descartar los mensajes SMS que no están protegidos correctamente utilizando los parámetros esperados almacenados en el recurso "parámetros de clave de enlace de SMS" y las claves esperadas almacenadas en el recurso "Claves secretas de enlace de SMS", y NO DEBERÁN responder con un mensaje de error protegido utilizando los parámetros y claves correctos.
Terminal del dispositivo
Si el terminal del canal SMS está en el dispositivo, se DEBERÁN aplicar las siguientes configuraciones:
SMS de clase 1 como se especifica en [3GPP TS 23.038]
TP-PID de 111101 (descarga de datos ME) como se especifica en [3GPP TS 23.040]
TP-OA: el TP-OA (dirección de origen según se define en [3GPP 23.040] de un paquete de comandos entrante (por ejemplo, solicitud CoAP) DEBE reutilizarse como TP-DA del paquete saliente (por ejemplo, respuesta de CoAP) Terminal de tarjeta inteligente
Si el terminal del canal SMS está en la tarjeta inteligente, SE DEBERÁN aplicar las siguientes configuraciones: SMS de clase 2 como se especifica en [3GPP TS 23.038]. El encabezado SMS [3GPP TS 23.040] DEBE definirse como se muestra a continuación:
• TP-PID: 111111 (descarga de datos USIM) como se especifica en [3GPP TS 23.040]
• TP-OA: el TP-OA (dirección de origen según se define en [3GPP 23.040] de un paquete de comandos entrante (por ejemplo, solicitud CoAP) DEBE reutilizarse como TP-DA del paquete saliente (por ejemplo, respuesta de CoAP)
Mecanismos del modo de paquete seguro SMS
1. Transferencia segura de SMS a UICC
Un paquete seguro SMS que encapsula una solicitud CoAP recibida por el dispositivo LWM2M DEBE ser, según [E<t>S<i>T<s>102 225]/[3GPP TS 31.115], dirigida a la aplicación LW<m>2<m>UlCC en la tarjeta inteligente donde se descifrará, se añadirá si es necesario y se comprobará para su integridad.
Si el descifrado y la comprobación de integridad tienen éxito, el mensaje contenido en el SMS DEBE proporcionarse al cliente LWM2M.
Si falla el descifrado o la comprobación de integridad, se DEBE descartar el SMS.
El mecanismo para proporcionar la solicitud CoAP descifrada al cliente LWM2M se basa en los comandos básicos GET_DATA de [GP S<c>P03]. Estos datos DEBEN seguir el formato siguiente
data_rcv _ ::= <address><coap_msg>
address ::= TP_OA ; originated address (dirección de origen)
coap_msg ::= COAP_TAG <coap_request_length><coap_request>
coap_request_length ::= 16BITS_VALUE
coap_request ::= CoAP message payload (carga útil del mensaje)
NOTA: En la versión actual de LWM2M, la forma en que se activa la aplicación cliente LWM2M para recuperar el mensaje disponible de la tarjeta inteligente queda a discreción del dispositivo: es decir, un dispositivo LWM2M de clase media que implementa el kit de herramientas [ETSI TS 102223] con clase "e" y el soporte "k" podría activarse automáticamente mediante mecanismos del kit de herramientas, mientras que un dispositivo LWM2M más simple podría depender de mecanismos de sondeo en la tarjeta inteligente para recuperar datos cuando estén disponibles.
2. Transferencia de SMS segura al servidor LWM2M
Para el envío de un mensaje CoAP al servidor LWM2M, el cliente LWM2M prepara datos que contienen el TP-DA correcto para utilizar, concatenado con el mensaje CoAP y DEBE proporcionar esos datos a la aplicación LWM2M UlCC al utilizar el comando STORE-DATA [GP SCP03].
Según [ETSI TS 102 225]/[3GPP TS 31.115] la tarjeta inteligente será la encargada de preparar (cifrado/concatenación) el mensaje CoAP antes de enviarlo como un comando SEND_SMS de paquete seguro SMS ([ETSI TS 102223]).
El paquete seguro de SMS DEBE tener el formato de datos protegidos especificado en la sección 7.3.1.2.
El canal seguro como se especifica en el anexo H DEBE utilizarse para proporcionar los datos preparados a la tarjeta inteligente.
La seguridad del canal SMS la proporciona la estructura de paquetes seguros [ETSI TS 102225] y [SCP080] que define paquetes seguros para diferentes mecanismos de transporte.
La solución se ha diseñado originalmente para proteger estructuras de paquetes para aplicaciones basadas en UICC; sin embargo, para LWM2M es adecuada para proteger el canal SMS entre el cliente y el servidor.
La seguridad del canal SMS especificada en esta sección DEBE aplicarse cuando se utiliza el enlace SMS.
Cuando el dispositivo LWM2M soporta una tarjeta inteligente, la seguridad DEBERÍA finalizar en la tarjeta inteligente. El cliente LWM2M DEBERÍA pasar mensajes SMS a la tarjeta inteligente para cifrado y protección de integridad antes de enviarlos, y DEBERÍA pasar mensajes SMS cifrados recibidos del servidor LWM2M a la tarjeta inteligente para descifrado y comprobación de integridad.
Un cliente LWM2M que soporta el enlace de SMS DEBERÁ soportar la estructura de paquetes seguros como se define en [ETSI TS 102225] y [SCP080]. El cliente LWM2M DeBe RÁ compartir las claves relevantes, identificadas por Klc y KID, con un servidor de arranque LWM2M durante el arranque, o con un servidor LWM2M en caso contrario.
Un servidor de arranque LWM2M que soporta el enlace de SMS DEBERÁ soportar la estructura de paquetes seguros como se define en [ETSI TS 102225] y [SCP080].
Un servidor LWM2M que soporta el enlace de SMS DEBERÁ soportar la estructura de paquetes seguros como se define en [ETSI TS 102225] y [SCP080].
En el modo de estructura de paquetes seguros de SMS, un mensaje CoAP tal como se define en [CoAP ] DEBE encapsularse en paquetes seguros [3GPP 31.115], al implementar, para SMS punto a punto (SMS_PP), la especificación [ETS<i>102225] general para aplicaciones basadas en UICC.
Lo siguiente se aplica al cliente LWM2M, al servidor de arranque LWM2M y al servidor LWM2M:
• El comando "paquete de comandos" especificado en [3GPP 31.115]/[ETSI TS 102225] DEBE utilizarse tanto para la solicitud CoAP como para el mensaje de respuesta.
• La estructura del paquete de comandos contenido en el mensaje corto DEBE seguir la especificación [3GPP 31.115].
• No se DEBERÁ confiar en el DES único.
• DEBE utilizarse AES o Triple DES con tres claves diferentes.
• Preferiblemente se debería utilizar AES. Cuando se utiliza AES, se debería utilizar con el modo CBC para cifrado (véase codificación de Klc en [ETSI TS 102225] sección 5.1.2) y en modo CMAC para integridad (véase codificación de KID en [ETSI TS 102225] sección 5.1.3).
• SPI DEBERÁ establecerse de la siguiente manera (véase codificación de SPI en [ETSI TS 102 225] sección 5.1.1).:
osuma de control criptográfica
ocifrado
oEl cifrado y la suma de control criptográfica DEBEN utilizar, bien AES, o bien triple DES
oNo se DEBERÁ utilizar DES único
oDEBERÍA utilizarse AES
oCuando se utiliza Triple DES, a continuación, DEBE utilizarse en modo CBC externo y DEBEN utilizarse 3 claves diferentes
oCuando se utiliza AES, DEBE utilizarse con el modo CBC para el cifrado (véase codificación de Klc en [ETSI TS 102225] sección 5.1.2) y en modo CMAC para integridad (véase codificación de KID en [ETSI TS 102225] sección 5.1.3
oprocesar si y solo si el valor del contador es mayor que el valor en el RE
• Preferiblemente, TAR (véase codificación de TAR en [ETSI TS 101 220], sección 6) DEBERÁ establecerse en un valor en el intervalo BF Ff00 - BF FF FF.
NOTA: Se solicitará un TAR para la seguridad de SMS LWM2M a ETSI SCP y el intervalo anterior se aplica sólo hasta que se haya asignado el TAR.
Datos protegidos: contiene el mensaje de aplicación protegido que DEBE codificarse como BER-TLV, la etiqueta (TBD: por ejemplo, 0x05) indicará el tipo (por ejemplo, tipo CoAP) de ese mensaje.
Habrá dos TAR diferentes para cancelar la seguridad en la tarjeta inteligente o en el dispositivo.
Las claves de cifrado e integridad y los valores de contador asociados DEBERÍAN conservarse en una tarjeta inteligente u otro entorno de almacenamiento seguro a prueba de manipulaciones (por ejemplo, un elemento seguro incorporado). El cliente DEBERÍA pasar SMS MT a la tarjeta inteligente/SE para descifrado y comprobación de integridad, y DEBERÍA pasar SMS MO a la tarjeta inteligente/SE para cifrado y protección de integridad antes del envío.
Si las claves y los valores de contador asociados no se almacenan de la forma recomendada anteriormente, DEBERÁN tratarse como claves de sesión con una vida útil no mayor que la duración de la vida útil del registro. El Cliente LWM2M DEBERÁ adquirir nuevo material de claves, descartarlo en cada operación de "Registro" o "Actualización", cargar material de claves nuevo utilizando uno de los mecanismos que se describen a continuación y reiniciar los contadores.
-Volver a arranca a través del mecanismo GBA Push, como se describe en [OMA DM v2.0] sección 9.3.1.3. GBA Push utiliza una UICC para generar el llamado secreto compartido Ks_(ext/int)_NAF tanto en la red como en el dispositivo. A partir de esta clave maestra Ks_(ext/int)_NAF, a continuación se generan dos secretos de sesión: el DMBEK y el DmBIK. El valor de Klc (clave de cifrado para SMS) DEBERÁ establecerse truncando DMBEK a la longitud de clave relevante (tomando los bits 0 a 127 para AES-128, o los bits 0 a 167 bits para 3DES), y el valor de la KID (clave de integridad para SMS) DEBERÁ establecerse de manera similar truncando DMBIK a la longitud de clave relevante (bits 0 a 127 para AeS-128, o bits 0 a 167 para 3DES). La información GBA push DEBERÁ entregarse al cliente LWM2M utilizando un SMS de Clase 1 como se especifica en [3GPP TS 23.038] con un TP-PID de 111101 (descarga de datos ME) como se especifica en [3GPP TS 23.040].
-Volver a arrancar desde la tarjeta inteligente mediante uno de los siguientes métodos:
oUtilizando el mecanismo GBA Push descrito anteriormente, específicamente con GBA-U, y con la tarjeta inteligente generando el DMBIK y DMBEK a partir de Ks_int_NAF.
oUtilizando la gestión remota de archivos (RFM) o la gestión remota de aplicaciones (RAM) como se especifica en [ETSI TS 102.226]. El servidor LWM2M DEBERÁ generar nuevos datos clave aleatorios de longitud adecuada para Klc y KID y garantizar que se entreguen a la tarjeta inteligente mediante un SMS de Clase 2 como se especifica en [3gPpTS 23.038] con un TP-PID de 111111 (UsIM descarga de datos) como se especifica en [3GPP TS 23.040], protegido utilizando las claves de seguridad OTA relevantes para RFM o RAM.
La tarjeta inteligente DEBERÁ colocar las claves de sesión actualizadas en el archivo de aprovisionamiento. EF_LWM2M_Bootstrap.
- Volver a arrancar a través del enlace de UDP, asegurado como se describe en la sección 7.1 (Seguridad UDP). Cuando el enlace UDP no está disponible, el servidor LWM2M (o servidor de arranque) DEBERÍA enviar SMS al cliente LWM2M para actualizar las claves de sesión antes del siguiente intento de operación de "Registro" o "Actualización". Si el Cliente LWM2M intenta ponerse en contacto con el servidor LWM2M utilizando un registro expirado, o intenta "Registrarse" o "Actualizarse" utilizando una clave obsoleta, el servidor LWM2M DEBERÁ responder con un error (4.00 solicitud incorrecta) y DEBERÁ enviar SMS para actualizar las claves de sesión. Sin embargo, el Servidor LWM2M DEBERÍA enviar dicho SMS antes de que expire el registro actual, si el cliente LWM2M está activo; o si el cliente LWM2M está en un ciclo de suspensión, el servidor LWM2M (o servidor de arranque) DEBERÍA enviar dicho SMS la próxima vez que esté activo. Estas medidas evitarán una operación fallida de "Registro" o "Actualización".
En cuanto a la sección 7.1 (seguridad UDP), cuando una sesión persiste durante los ciclos de suspensión, DEBERÍA utilizarse almacenamiento cifrado y con integridad protegida para las claves y contadores de sesión. Alternativamente, las nuevas claves de sesión DEBERÁN establecerse mediante uno de los mecanismos anteriores al activarse desde un ciclo de suspensión.
Preferiblemente, Klc, KID, SPI y TAR DEBERÁN almacenarse en el recurso "parámetros de clave de enlace de SMS".
Preferiblemente, los valores de clave correspondientes deberían almacenarse en el recurso "claves secretas de enlace de SMS".
Un cliente LWM2M que utiliza el enlace SMS puede, bien aprovisionarse directamente para su uso con un servidor LWM2M de destino (modo de arranque de configuración previa del fabricante), o bien ser capaz de arrancar a través del enlace UDP.
Un cliente, servidor o servidor de arranque LWM2M que soporta el enlace de SMS DEBERÁ descartar los mensajes SMS que no estén correctamente protegidos utilizando los parámetros esperados almacenados en el recurso "parámetros de clave de enlace de SMS" y las claves esperadas almacenadas en el recurso "claves secretas de enlace de SMS", y NO DEBERÁ responder con un mensaje de error protegido utilizando los parámetros y claves correctos.
Objeto LWM2M: Seguridad LWM2M
Descripción: Este objeto LWM2M proporciona el material de claves de un cliente LWM2M apropiado para acceder a un servidor LWM2M específico. Una instancia del objeto DEBERÍA dirigirse a un servidor de arranque LWM2M Estos recursos de objetos LWM2M solo DEBEN ser modificados mediante un servidor de arranque LWM2M o aprovisionamiento de tarjeta inteligente y NO DEBEN ser accesibles mediante ningún otro servidor LWM2M.
Información de objeto ilustrativa:
Información de recurso
Seguridad del canal UDP: formato de recurso de clave de seguridad
Esta sección define el formato de la clave secreta, la clave pública y los recursos de identidad del servidor LWM2M y los objetos de arranque de LWM2M cuando se utiliza la seguridad del canal UDP. Estos recursos se utilizan para configurar el modo de seguridad y el material de claves que utiliza un cliente con un servidor en particular. Los objetos se configuran en el cliente utilizando uno de los mecanismos de arranque descritos en la sección 5.1 de o Ma LWM2M. El uso de este material de claves para cada modo de seguridad se define en la sección 7.1 de OMA LWM2M.
Modo de clave previamente compartida (PSK)
La PSK es una clave secreta binaria compartida entre el cliente y el servidor de la longitud adecuada para el conjunto de cifrado utilizado [RFC4279]. Esta clave se compone de una secuencia de bytes binarios en el recurso de clave secreta. Los conjuntos de cifrado PSK predeterminados definidos en esta especificación utilizan una clave AES de 128 bits. Por lo tanto, esta clave estaría representada en 16 bytes en el recurso de clave secreta.
La identidad PSK correspondiente a esta PSK se almacena en la clave pública o recurso de identidad. La identidad PSK simplemente se almacena como una cadena UTF-8 según [RFC4279]. Los clientes y servidores DEBEN soportar una identidad PSK de al menos 128 bytes de longitud según lo exige [RFC4279].
Modo de clave pública sin formato (RPK)
El modo de clave pública sin formato requiere una clave pública y una clave privada del tipo y longitud adecuados para el conjunto de cifrado utilizado. Estas claves se transportan como una secuencia de bytes binarios con la clave pública almacenada en la clave pública o recurso de identidad y la clave privada almacenada en el recurso de clave secreta. Los conjuntos de cifrados RPK predeterminados definidos en esta especificación utilizan una clave ECC de 256 bits. Por lo tanto, el recurso de certificado contendría una clave pública de 32 bytes y el recurso de clave secreta una clave privada de 32 bytes.
Modo Certificado
El modo certificado requiere un certificado X.509v3 junto con una clave privada coincidente. La clave privada se almacena en el recurso de clave secreta como en el modo RPK. El certificado se representa simplemente como binario X.509v3 en el valor de la clave pública o recurso de identidad.
Seguridad de carga útil de SMS: formato de recurso de clave de seguridad
Esta sección define el formato de la clave secreta, la clave pública y los recursos de identidad del servidor LWM2M y los objetos de arranque de LWM2M cuando se utiliza la seguridad de carga útil de SMS. Estos recursos se utilizan para configurar el material de claves que un cliente utiliza con un servidor en particular. Los objetos se configuran en el cliente utilizando uno de los mecanismos de arranque descritos en la sección 5.1. El uso de este material de claves se define en la sección 7.2.
Los parámetros de la clave SMS se almacenan en el orden Klc, KID, SPI, TAR (Klc es el byte 0).
El orden de los bits dentro de los bytes DEBERÁ seguir las "convenciones de codificación" de ETSI TS 102221 (b8 MSB, b1 LSB).
Parada
Si se ha de eliminar una instancia del objeto de seguridad, es necesario eliminar o modificar algunos recursos y configuraciones relacionados. Por lo tanto, cuando la operación de eliminación se envía a través de una interfaz de arranque, el cliente DEBE proceder siguiendo el procedimiento.
1. Si hay una instancia del objeto a la que sólo puede acceder un servidor de la instancia del objeto de servidor (es decir, el servidor es el propietario del control de acceso y el servidor LWM2M puede acceder a la instancia del objeto sólo en una instancia del objeto de control de acceso), la instancia del objeto y la instancia del objeto de control de acceso correspondiente DEBE eliminarse
2. Si múltiples servidores pueden acceder a una instancia del objeto, incluyendo el servidor, cuya instancia del objeto de seguridad se ha de eliminar, entonces:
- Se DEBE eliminar una instancia de recurso ACL para el servidor en la instancia del objeto de control de acceso para la instancia del objeto.
- Si el servidor es el propietario del control de acceso de la instancia del objeto de control de acceso, entonces el propietario del control de acceso DEBE modificarse a otro servidor según las reglas siguientes: El cliente DEBE elegir el servidor que tenga la suma más alta de cada número asignado a un derecho de acceso (Escribir: 1, Eliminar: 1) para el propietario del control de acceso. Si dos o más servidores tienen la misma suma, el cliente DEBE elegir uno de ellos como propietario del control de acceso.
3. DEBE eliminarse la observación del servidor
4. DEBE eliminarse la instancia del objeto del servidor
5. El cliente PUEDE enviar la operación de "cancelar el registro" al servidor.
Nota: Para monitorizar la modificación del propietario del control de acceso, el servidor PUEDE observar el recurso del propietario del control de acceso.
Como mejora adicional, GBA BSF se puede fusionar con el servidor de arranque LWM2M. Esto hace que sea más fácil descubrir un único servidor. Esto se muestra en la fig. 5 en la que un servidor 420 combinado contiene tanto el BSF 130 como el LWM2M 440.
Las figs. 6 y 7 muestran diagramas esquemáticos que indican cómo el dispositivo 110 M2M puede acceder al servidor Bs F LWM2M combinado. Si bien el BSF 420 LWM2M combinado se muestra en las figs. 6 y 7, otras realizaciones pueden funcionar donde el BSF y el LWM2M están incorporados como entidades separadas (por ejemplo, como se muestra en la fig. 2). Sin embargo, se pueden utilizar técnicas de descubrimiento iguales o similares, como se describe a continuación.
El dispositivo 110 M2M requiere algún mecanismo para encontrar un servidor y en particular el servidor LWM2M (servidor DM) o el servidor BSF. Como se ha descrito anteriormente, el servidor LWM2M utiliza la interfaz Ua y el servidor BSF utiliza la interfaz Ub. Por lo tanto, el dispositivo 110 M2M requiere las direcciones IP, URL y/o puertos correctos para ponerse en contacto y comunicarse con los distintos servidores. Como se ha dado a conocer anteriormente, puede no ser particularmente factible o conveniente aprovisionar previamente el dispositivo 110 M2M con todas las direcciones y URL necesarias ya que esto requeriría que dichas configuraciones se especifiquen en la fecha de fabricación y no sería fácil cambiar o modificar estos datos más adelante. Los estándares de gestión de dispositivos OMA proponen el uso de un servidor de arranque para cargar los detalles de servidor relevantes de un servidor DM. Sin embargo, esto transfiere el problema a uno del aprovisionamiento de los detalles en el servidor de arranque.
A continuación se describe cómo se puede utilizar la infraestructura de enrutamiento para lograr el descubrimiento automatizado del servidor LWM2M (Dm) y/o BSF. Un ejemplo de este método 600 se muestra como diagrama de flujo en la fig. 8. Un nodo 410 de soporte GPRS de pasarela (GGSN) proporciona un nombre 430 de punto de acceso predeterminado (APN) para actuar como enrutamiento predeterminado para el tráfico 620 CoAP cuando el dispositivo 110 M2M se conecta por primera vez en 610. Por lo tanto, el tráfico puede enrutarse automáticamente en 630 a un servidor 420 DM predeterminado. El GGSN 410 puede variar el servidor 420 predeterminado (por ejemplo, servidor LWM2M/BSF combinado) dependiendo de la IMSI proporcionada por el dispositivo 110 M2M (ciertos grupos de números IMSI pueden enrutarse a un servidor 420 y otros grupos de números IMSI pueden enrutarse a un servidor 420' diferente).
Además, el tráfico CoAP tendrá un puerto (5683) dedicado, por lo que se puede aplicar una regla de enrutamiento predeterminada de corta duración para este puerto. En otras palabras, todas las comunicaciones en este puerto pueden enviarse a un servidor 420 de combinación LWM2M/BSF predeterminado (servidor DM) o puede haber un enrutamiento predeterminado de corta duración para todo el tráfico UDP, por ejemplo. Puede haber reglas de enrutamiento predeterminadas similares para el tráfico HTTP (BSF 130) o todo el tráfico TCP, o un DNS predeterminado que envía todo el tráfico HTTP al BSF 130 hasta que se complete la configuración de gestión del dispositivo.
Una vez que se ha alcanzado el servidor 420 DM predeterminado (ya sea mediante el método 400 descrito con respecto a la fig. 6 u 8 o por otros medios), el servidor 420 predeterminado puede indicar una dirección para un servidor 640 alternativo y/o servidor BSF preferido (por ejemplo, combinación de servidor 420' LWM2M/BSF). Esto puede permitir que se logre el balanceo de carga u otras configuraciones de red. La fig. 7 muestra cómo se puede hacer esto de forma esquemática. El servidor 420 DM predeterminado puede proporcionar al dispositivo 110 M2M un indicio de clave previamente compartida (psk) que incluye los detalles de la dirección del servidor 420' alternativo. Por ejemplo, se puede incluir un indicio psk al ejecutar TLS o DTLS. La dirección del servidor 420' alternativo puede suministrarse mediante otros mecanismos. El APN (y por tanto el enrutamiento) puede asignarse o reasignarse basándose en otras propiedades o parámetros detectados tales como el APN actual o una característica del tráfico de comunicación entre el dispositivo M2M y el servidor 420, por ejemplo.
Por ejemplo, un mensaje de arranque LWM2M puede utilizar una operación lógica de escritura (mensaje) en recursos personalizados (tales como "NAFJD" y "BSF_ID"). Si el mensaje de escritura no contiene seguridad, a continuación, el dispositivo M2M puede rechazar formalmente la operación de escritura, pero puede utilizar la información que contiene la operación de escritura para derivar la dirección del servidor 420' alternativo. En otras palabras, la operación lógica de escritura falla (como se pretendía) pero el mensaje que se ha recibido contiene suficiente información para permitir que el dispositivo 110 M2M localice el servidor 420' alternativo.
Como se describe con referencia a la fig. 5, el BSF se puede fusionar con el servidor 440 de arranque LWM2M para formar un servidor 420 DM combinado. Por lo tanto, sólo habrá una única entidad por descubrir. En el mensaje de arranque de escritura descrito con referencia a la fig. 7, el servidor 440 de arranque LWM2M puede entregar credenciales para interactuar con un servidor 420' DM alternativo o de producción. Por lo tanto, el mensaje de escritura indica al dispositivo M2M que escriba en un objeto de seguridad de acceso al servidor (pero este mensaje pretende que falle la autenticación). El servidor 420 BSF/LWM2M combinado puede entregar un mensaje de información GBA Push (GPI) que permite derivar las credenciales de producción relevantes en el dispositivo 110 M2M. Esta optimización puede conducir a un BSF 130 especialmente simplificado.
Se ha de comprender que la descripción anterior se proporciona a modo de ejemplo y sólo para el beneficio de la comprensión de la solución, y debe incluir también cualquier combinación de las características anteriores, así como cualquier alteración, modificación o adición que podría ser realizada por un experto mediante el uso de sus habilidades y/o conocimientos generales en la técnica relevante y/o relacionada.
Muchas combinaciones, modificaciones o alteraciones de las características de las realizaciones anteriores serán fácilmente evidentes para el experto y están destinadas a formar parte de la invención. Cualquiera de las características descritas específicamente en relación con una realización o ejemplo se puede utilizar en cualquier otra realización realizando los cambios apropiados.

Claims (15)

REIVINDICACIONES
1. Un método para el enrutamiento del tráfico de comunicaciones entre un dispositivo (110) máquina a máquina, M2M, conectado a una red de telecomunicaciones y que tiene una identidad de abonado móvil internacional, IMSI, y un servidor, seleccionado de una pluralidad de servidores, comprendiendo el método las etapas de: asignación de un nombre de punto de acceso, APN, entre una pluralidad de APN basados en la IMSI del dispositivo M2M; y
enrutamiento, a través del APN asignado, del tráfico de comunicaciones entre el dispositivo (110) M2M y el servidor, en donde el servidor se determina basándose en una característica de un tráfico de comunicación entre el dispositivo M2M y el servidor,
en donde el servidor se selecciona de una pluralidad de servidores y se determina basándose en un protocolo de transporte del tráfico de comunicación recibido del dispositivo M2M determinado a partir del número de puerto, y/o en donde la característica del tráfico de comunicación es un protocolo de datagrama de usuario, UDP, o un protocolo de control de transmisión, TCP, y/o
en donde cuando el tráfico de comunicación es seguro, se enruta el tráfico a un servidor de gestión de dispositivos, DM, y cuando el tráfico de comunicación no es seguro, se enruta el tráfico a un servidor de función de servidor de arranque, BSF.
2. El método de la reivindicación 1, en donde cuando la característica del tráfico de comunicación es UDP, se enruta el tráfico de comunicaciones UDP al servidor DM y cuando la característica del tráfico de comunicación es TCP, se enruta el tráfico de comunicaciones TCP al servidor BSF.
3. El método según cualquiera de las reivindicaciones anteriores, cuando el servidor se determina basándose en un protocolo de transporte del tráfico de comunicación o cuando la característica del tráfico de comunicación es UDP o TCP, en donde el servidor es cualquiera de uno o más de una combinación de servidores seleccionados de: un servidor de gestión de dispositivos, DM, un servidor (120) de función de servidor de arranque, BSF; un servidor de arranque DM, un servidor M2M ligero, LWM2M; un servidor de arranque LWM2M; y una función de de aplicación de red, NAF; y un servidor (130) DM y un servidor BSF combinados.
4. El método según cualquier reivindicación anterior, en donde el servidor indica una dirección o direcciones para el servidor o servidores alternativos con los que enrutar el tráfico de comunicaciones.
5. El método de la reivindicación 4, en donde la dirección o direcciones del servidor o servidores alternativos están contenidas dentro de un indicio de clave previamente compartida, PSK, indicado por el servidor o están contenidas dentro de un mensaje de arranque.
6. El método de la reivindicación 5, en donde el mensaje de arranque es una operación lógica de escritura.
7. El método según cualquiera de las reivindicaciones anteriores, en donde el enrutamiento está limitado a vencer después de una o un número predeterminado de conexiones o se limita a un período de tiempo.
8. El método de la reivindicación 7, en donde después de la expiración del enrutamiento, el dispositivo (110) M2M se enruta a un servidor diferente.
9. El método según la reivindicación 7 o la reivindicación 8, en donde al expirar el enrutamiento se asigna un APN diferente.
10. El método según cualquiera de las reivindicaciones anteriores, cuando el tráfico de comunicación es seguro o no es seguro, en donde cuando el tráfico de comunicación es seguro, el tráfico seguro es tráfico CoAPs o HTTPs y se enruta al servidor DM y cuando el tráfico de comunicación no es seguro, el tráfico no seguro es el tráfico CoAP o HTTP y se enruta al servidor BSF.
11. Un sistema (110) para el enrutamiento del tráfico de comunicaciones entre un dispositivo (110) máquina a máquina, M2M, conectado a una red de telecomunicaciones y que tiene una identidad de abonado móvil internacional, IMSI, y un servidor, seleccionado de una pluralidad de servidores, comprendiendo el sistema: una interfaz configurada para recibir comunicaciones desde el dispositivo (110) M2M; y lógica configurada para: recibir en la interfaz la IMSI del dispositivo (110) M2M,
asignar un nombre de punto de acceso, APN, de una pluralidad de APN basados en la IMSI del dispositivo (110) M2M, y
enrutar, a través del APN asignado, el tráfico de comunicaciones entre el dispositivo (110) M2M y el servidor, en donde el servidor se determina basándose en una característica de un tráfico de comunicación entre el dispositivo M2M y el servidor,
en donde, el servidor se selecciona de una pluralidad de servidores y se determina basándose en un protocolo de transporte del tráfico de comunicación recibido del dispositivo M2M determinado a partir del número de puerto, y/o en donde la característica del tráfico de comunicación es un protocolo de datagrama de usuario, UDP, o un protocolo de control de transmisión, TCP, y/o
en donde cuando el tráfico de comunicación es seguro, se enruta el tráfico a un servidor de gestión de dispositivos, DM, y cuando el tráfico de comunicación no es seguro, se enruta el tráfico a un servidor de función de servidor de arranque, BSF.
12. El sistema según la reivindicación 11, que comprende además una pluralidad de dispositivos (110) M2M configurados para comunicarse con la interfaz y comunicarse con el servidor.
13. El sistema de la reivindicación 11 o la reivindicación 12, que comprende además una pluralidad de APN seleccionables por la lógica.
14. El sistema según cualquiera de las reivindicaciones 7 a 11 y 13, cuando el servidor se determina basándose en un protocolo de transporte del tráfico de comunicación, o cuando la característica del tráfico de comunicación es UDP o TCP, en donde el servidor es cualquiera de uno o más seleccionado de: un servidor (120) de gestión de dispositivos, DM; un servidor (130) de función de servidor de arranque, BSF; un servidor M2M ligero, LWM2M; un servidor de arranque LWM2M; una función (122) de aplicación de red, NAF; y un servidor DM y servidor BSF (130) combinados.
15. El sistema de la reivindicación 14, en donde el servidor es un servidor (120) DM y/o un servidor (130) BSF y está configurado para indicar una dirección o direcciones de un servidor o servidores alternativos con los que enrutar el tráfico de comunicaciones.
ES20195438T 2013-09-13 2014-09-12 Comunicación con un dispositivo máquina a máquina Active ES2973643T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB201316370A GB201316370D0 (en) 2013-09-13 2013-09-13 Secure device management
GB201318339A GB201318339D0 (en) 2013-10-16 2013-10-16 Machine to machine architecture
GB1409652.3A GB2518256A (en) 2013-09-13 2014-05-30 Communicating with a machine to machine device

Publications (1)

Publication Number Publication Date
ES2973643T3 true ES2973643T3 (es) 2024-06-21

Family

ID=51214488

Family Applications (4)

Application Number Title Priority Date Filing Date
ES20209753T Active ES2933426T3 (es) 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina
ES20195438T Active ES2973643T3 (es) 2013-09-13 2014-09-12 Comunicación con un dispositivo máquina a máquina
ES14776684T Active ES2893353T3 (es) 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina
ES21154414T Active ES2979346T3 (es) 2013-09-13 2014-09-12 Comunicación segura con un dispositivo móvil

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES20209753T Active ES2933426T3 (es) 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina

Family Applications After (2)

Application Number Title Priority Date Filing Date
ES14776684T Active ES2893353T3 (es) 2013-09-13 2014-09-12 Comunicación con dispositivos de máquina a máquina
ES21154414T Active ES2979346T3 (es) 2013-09-13 2014-09-12 Comunicación segura con un dispositivo móvil

Country Status (6)

Country Link
US (14) US10305862B2 (es)
EP (15) EP3832982B1 (es)
CN (1) CN105706469B (es)
ES (4) ES2933426T3 (es)
GB (15) GB2518254B (es)
WO (12) WO2015036783A1 (es)

Families Citing this family (219)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE49491E1 (en) * 2012-06-08 2023-04-11 Samsung Electronics Co., Ltd. Method and system for selective protection of data exchanged between user equipment and network
WO2014112969A1 (en) * 2013-01-15 2014-07-24 Hewlett-Packard Development Company, L.P. Dynamic firmware updating
US9800621B2 (en) 2013-05-06 2017-10-24 Convida Wireless, Llc Registration for device triggering
US9100175B2 (en) 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
US9350550B2 (en) 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
GB2518254B (en) 2013-09-13 2020-12-16 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
US10700856B2 (en) 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9871889B1 (en) * 2014-03-18 2018-01-16 EMC IP Holing Company LLC Techniques for automated capture of configuration data for simulation
CN104954399B (zh) * 2014-03-27 2018-06-19 正文科技股份有限公司 绑定移动载具与智能装置之方法及其绑定系统
KR20180043385A (ko) * 2014-04-09 2018-04-27 콘비다 와이어리스, 엘엘씨 서비스 인에이블러 기능
US10569036B2 (en) 2014-05-27 2020-02-25 Resmed Inc. Remote diagnostics of respiratory therapy devices
KR101950122B1 (ko) * 2014-07-22 2019-05-22 콘비다 와이어리스, 엘엘씨 경량 기기 간 프로토콜을 디바이스 관리 프로토콜과 상호연동하기
GB2529838B (en) * 2014-09-03 2021-06-30 Advanced Risc Mach Ltd Bootstrap Mechanism For Endpoint Devices
EP3198893A1 (en) * 2014-09-25 2017-08-02 Telefonaktiebolaget LM Ericsson (publ) Device mobility with coap
US9763063B2 (en) * 2014-10-06 2017-09-12 Derek D. Kumar Secure broadcast beacon communications
US9807079B2 (en) * 2014-10-23 2017-10-31 Palo Alto Network, Inc. Single sign on proxy for regulating access to a cloud service
CN107113333B (zh) * 2014-12-11 2021-06-08 英国电讯有限公司 在服务器计算机上安装软件的方法和通信接口装置
US20160344744A1 (en) * 2015-01-13 2016-11-24 Gustavo Tanoni Application protocol query for securing gba usage
US9591027B2 (en) * 2015-02-17 2017-03-07 Qualys, Inc. Advanced asset tracking and correlation
US10200486B2 (en) * 2015-02-26 2019-02-05 Urban Airship, Inc. Mobile event notifications for network enabled objects
US10084865B2 (en) 2015-02-26 2018-09-25 Urban Airship, Inc. Mobile event notifications
KR102033465B1 (ko) 2015-02-27 2019-10-17 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 통신 디바이스와 네트워크 디바이스 사이의 통신에서의 보안 설비
GB2536698A (en) * 2015-03-26 2016-09-28 Eoghan Hynes Secure communications between a beacon and a handset
US11258874B2 (en) * 2015-03-27 2022-02-22 Globallogic, Inc. Method and system for sensing information, imputing meaning to the information, and determining actions based on that meaning, in a distributed computing environment
WO2016162382A1 (en) 2015-04-07 2016-10-13 Tyco Fire & Security Gmbh Machine-to-machine and machine to cloud end-to-end authentication and security
US10701111B2 (en) * 2015-04-10 2020-06-30 Nokia Of America Corporation Method and apparatus for device management
KR102423885B1 (ko) * 2015-05-08 2022-07-21 한국전자통신연구원 연산 에러 검출이 가능한 준동형 암호 방법 및 그 시스템
CA3018526C (en) 2015-05-22 2023-06-20 John A. Nix Cryptographic unit for public key infrastructure (pki) operations
GB2538773A (en) 2015-05-28 2016-11-30 Vodafone Ip Licensing Ltd Device key security
CN105045114B (zh) * 2015-05-29 2019-11-19 四川长虹电器股份有限公司 一种信息处理方法、云服务平台及信息处理系统
US10135871B2 (en) * 2015-06-12 2018-11-20 Accenture Global Solutions Limited Service oriented software-defined security framework
CN107924437A (zh) 2015-06-17 2018-04-17 瑞典爱立信有限公司 用于使得能够实现凭证的安全供应的方法以及相关无线装置和服务器
CN108028829A (zh) 2015-07-02 2018-05-11 瑞典爱立信有限公司 用于获得对网络的初始接入的方法以及相关的无线设备和网络节点
EP3320708B1 (en) * 2015-07-06 2022-03-09 Telefonaktiebolaget LM Ericsson (publ) Facilitating secure communcation between a client device and an application server
GB2540354A (en) 2015-07-13 2017-01-18 Vodafone Ip Licensing Ltd Generci bootstrapping architecture protocol
CN106487501B (zh) * 2015-08-27 2020-12-08 华为技术有限公司 密钥分发和接收方法、密钥管理中心、第一和第二网元
US10057382B2 (en) * 2015-09-24 2018-08-21 Amrita Vishwa Vidyapeetham Intelligent “IoT gateway”
KR101707602B1 (ko) * 2015-09-25 2017-02-17 상명대학교 천안산학협력단 해시 트리 기반 보안 메시지 인증 방법 및 이를 위한 장치
US20180295197A1 (en) * 2015-10-07 2018-10-11 Samsung Electronics Co., Ltd. Method for resource mapping between restful server and onem2m system
US20190222653A1 (en) * 2015-10-23 2019-07-18 Telefonaktiebolaget Lm Ericsson (Publ) Establishment of operational status of a machine-to-machine device
WO2017088908A1 (en) * 2015-11-24 2017-06-01 Telefonaktiebolaget Lm Ericsson (Publ) Charging record authentication for anonymized network service utilization
US11044593B2 (en) * 2015-12-03 2021-06-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and devices for managing constrained devices
KR102576667B1 (ko) 2016-01-25 2023-09-11 애플 인크. 비-네이티브 크리덴셜들과 함께 전자 디바이스들을 사용하는 거래들의 수행
US10708781B2 (en) 2016-01-27 2020-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Method for setting up a secure connection between LWM2M devices
US11290425B2 (en) * 2016-02-01 2022-03-29 Airwatch Llc Configuring network security based on device management characteristics
WO2017139046A1 (en) * 2016-02-09 2017-08-17 Presenso, Ltd. System and method for unsupervised root cause analysis of machine failures
US10268495B2 (en) * 2016-02-18 2019-04-23 Verizon Patent And Licensing Inc. Virtual device model system
US20170262523A1 (en) 2016-03-14 2017-09-14 Cisco Technology, Inc. Device discovery system
US10158991B2 (en) * 2016-03-17 2018-12-18 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
US10172000B2 (en) * 2016-03-17 2019-01-01 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
US10135946B2 (en) 2016-04-11 2018-11-20 Verizon Patent And Licensing Inc. Sending messages to mobile devices
US10484363B2 (en) * 2016-05-23 2019-11-19 Lg Electronics Inc. Method and apparatus for authenticating a device using Bluetooth technology
WO2017202432A1 (en) 2016-05-23 2017-11-30 Hsl Energy Holding Aps An apparatus for production of steam from an aqueous liquid
WO2017202466A1 (en) * 2016-05-26 2017-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Network application function registration
US9847875B1 (en) * 2016-06-20 2017-12-19 Verizon Patent And Licensing Inc. Methods and systems for bootstrapping an end-to-end application layer session security keyset based on a subscriber identity master security credential
US11075806B1 (en) 2016-06-30 2021-07-27 Juniper Networks, Inc. Hierarchical naming scheme for state propagation within network devices
EP3270620A1 (en) * 2016-07-13 2018-01-17 Gemalto Sa Method and devices for managing a secure element
EP3270321B1 (en) * 2016-07-14 2020-02-19 Kontron Modular Computers SAS Technique for securely performing an operation in an iot environment
US10298996B2 (en) 2016-08-18 2019-05-21 At&T Intellectual Property I, L.P. Satellite TV user community smart device monitoring and management
US10650621B1 (en) 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network
US10791108B2 (en) * 2016-10-04 2020-09-29 Joseph Jay Austin Apparatuses, systems and methods for tracking network connected devices
US11240093B2 (en) * 2016-10-07 2022-02-01 Convida Wireless, Llc Service layer resource management for generic interworking and extensibility
CN107995673A (zh) * 2016-10-27 2018-05-04 中兴通讯股份有限公司 一种语音数据处理装置、方法及终端
US20180139090A1 (en) * 2016-11-15 2018-05-17 John Geiger Method for secure enrollment of devices in the industrial internet of things
US10455057B2 (en) * 2016-11-29 2019-10-22 Verizon Patent And Licensing Inc. System and method for Lightweight-Machine-to-Machine device registration and assignment
GB2558205B (en) * 2016-12-15 2019-07-03 Arm Ip Ltd Enabling communications between devices
US11316775B2 (en) 2016-12-21 2022-04-26 Juniper Networks, Inc. Maintaining coherency in distributed operating systems for network devices
US10887173B2 (en) 2016-12-21 2021-01-05 Juniper Networks, Inc. Communicating state information in distributed operating systems
JP2018101724A (ja) * 2016-12-21 2018-06-28 株式会社村田製作所 積層セラミックコンデンサ
US11316744B2 (en) 2016-12-21 2022-04-26 Juniper Networks, Inc. Organizing execution of distributed operating systems for network devices
US20180184290A1 (en) * 2016-12-22 2018-06-28 Cypress Semiconductor Corporation Embedded Certificate Method for Strong Authentication and Ease of Use for Wireless IoT Systems
US10430566B2 (en) * 2016-12-27 2019-10-01 Paypal, Inc. Vehicle based electronic authentication and device management
CN108306911B (zh) * 2017-01-12 2020-12-29 中移物联网有限公司 一种物联网事件监测方法及设备
US10439895B2 (en) * 2017-01-31 2019-10-08 Salesforce.Com, Inc. Dynamic selection of channels for incoming communication
US10389593B2 (en) * 2017-02-06 2019-08-20 International Business Machines Corporation Refining of applicability rules of management activities according to missing fulfilments thereof
ES2742128T3 (es) * 2017-03-03 2020-02-13 Boeing Co Sistema y método implementado por ordenador para la autentificación entre máquinas de un aparato
US10929573B2 (en) * 2017-03-21 2021-02-23 The Boeing Company Systems and methods for designing and modeling products in a cloud environment
US10992711B2 (en) * 2017-04-13 2021-04-27 At&T Intellectual Property I, L.P. Network aware data driven internet of things service engine
US10972453B1 (en) * 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
CN107231275B (zh) * 2017-05-31 2021-07-30 普天智能照明研究院有限公司 用于用户设备与家居设备连接配置的方法
US10548185B2 (en) * 2017-06-23 2020-01-28 At&T Mobility Ii Llc Facilitating integrated management of connected assets that utilize different technologies and that are located across disparate wireless communications networks
US10528293B2 (en) 2017-06-26 2020-01-07 International Business Machines Corporation Grouping devices as a virtual device for providing better quality of device data
US11316670B2 (en) * 2017-07-03 2022-04-26 Telefonaktiebolaget Lm Ericsson (Publ) Secure communications using network access identity
JP6934762B2 (ja) * 2017-07-04 2021-09-15 株式会社ソラコム 機器をリモートで管理するための装置、方法及びそのためのプログラム
CN107493571B (zh) * 2017-07-20 2020-04-14 深圳市盛路物联通讯技术有限公司 物联网中继器基于类型的上行数据加密控制方法及装置
US20190036896A1 (en) * 2017-07-27 2019-01-31 Cisco Technology, Inc. Generic Bootstrapping Architecture (GBA) Based Security Over Constrained Application Protocol (CoAP) for IoT Devices
US10628151B2 (en) * 2017-08-10 2020-04-21 Dell Products L.P. Systems and methods for usage driven determination of update criticality
US10944753B2 (en) * 2017-08-17 2021-03-09 Verizon Patent And Licensing Inc. IoT devices wireless network connectivity policy management
TWI685227B (zh) * 2017-08-28 2020-02-11 大同股份有限公司 閘道器、物聯網裝置控制系統與其方法
WO2019042540A1 (en) * 2017-08-30 2019-03-07 Telefonaktiebolaget Lm Ericsson (Publ) RECONFIGURATION OF COMMUNICATION DEVICES
US10901812B2 (en) * 2017-09-18 2021-01-26 Rapyuta Robotics Co., Ltd. Managing communication between cloud and heterogeneous devices across networks
US10560326B2 (en) 2017-09-22 2020-02-11 Webroot Inc. State-based entity behavior analysis
CN107749878B (zh) * 2017-10-16 2021-05-14 新华三信息安全技术有限公司 一种同步文件的方法及装置
WO2019075608A1 (zh) * 2017-10-16 2019-04-25 Oppo广东移动通信有限公司 一种加密数据流的识别方法、设备、存储介质及系统
US10833923B2 (en) 2017-10-26 2020-11-10 Skylo Technologies Inc. Dynamic multiple access for distributed device communication networks with scheduled and unscheduled transmissions
KR102005361B1 (ko) * 2017-10-31 2019-07-30 주식회사 디케이아이테크놀로지 저전력/광대역 네트워크를 지원하는 아이오티 단말의 오티에이 기술을 이용한 클라우드기반 단말 통합관리시스템
US10469600B2 (en) * 2017-11-14 2019-11-05 Dell Products, L.P. Local Proxy for service discovery
US10833926B2 (en) * 2017-11-17 2020-11-10 T-Mobile Usa, Inc. Touchless secure bootstrapping of IoT devices
US11212246B2 (en) 2017-11-27 2021-12-28 Realnetworks, Inc. Messaging platform communication processing using message cluster detection and categorization
WO2019106451A1 (en) * 2017-11-30 2019-06-06 Telefonaktiebolaget Lm Ericsson (Publ) Serving-network based perfect forward security for authentication
US10306442B1 (en) 2018-01-16 2019-05-28 Skylo Technologies Inc. Devices and methods for specialized machine-to-machine communication transmission network modes via edge node capabilities
CN108337308B (zh) * 2018-01-31 2021-08-10 高新兴物联科技有限公司 Lwm2m客户端与上位机数据通信方法、装置及其系统
CA3090131A1 (en) * 2018-02-02 2019-08-08 Atc Technologies, Llc Network device data exchange coordination
US11729612B2 (en) * 2018-03-08 2023-08-15 Cypress Semiconductor Corporation Secure BLE just works pairing method against man-in-the-middle attack
US10747290B1 (en) * 2018-03-30 2020-08-18 Shopkick, Inc. Varying application strategy based on device state
KR20190118862A (ko) * 2018-04-11 2019-10-21 에스케이하이닉스 주식회사 메모리 시스템 및 메모리 컨트롤러의 동작 방법
US11269701B2 (en) * 2018-04-17 2022-03-08 Nippon Telegraph And Telephone Corporation Device control apparatus, device control method, and device control system
US20190332814A1 (en) * 2018-04-27 2019-10-31 Nxp B.V. High-throughput privacy-friendly hardware assisted machine learning on edge nodes
US10990593B2 (en) * 2018-05-04 2021-04-27 Saleforce.com, inc. Providing matching security between data stores in a database system
US10594549B2 (en) * 2018-05-18 2020-03-17 Nant Holdings Ip, Llc Fine grained network management to edge device features
US12058214B2 (en) 2018-05-18 2024-08-06 Nant Holdings Ip, Llc Fine grained network management to edge device features
WO2019227473A1 (en) * 2018-06-01 2019-12-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for performing communication in internet of things
WO2020001738A1 (en) * 2018-06-25 2020-01-02 Telefonaktiebolaget Lm Ericsson (Publ) Communication protocol discover method in constrained application protocol (coap)
EP3811647B1 (en) * 2018-06-25 2022-02-23 Telefonaktiebolaget LM Ericsson (publ) Bootstrapping devices on a network
US20210203733A1 (en) * 2018-06-26 2021-07-01 Telefonaktiebolaget Lm Ericsson (Publ) Automated Constrained Datamodel Provisioning Procedure
GB2575433B (en) * 2018-06-26 2020-07-08 Advanced Risc Mach Ltd Automatic client device registration
US11438447B2 (en) * 2018-07-03 2022-09-06 Telefonaktiebolaget Lm Ericsson (Publ) First node, communication device, and methods performed thereby for handling positioning information
US10778444B2 (en) * 2018-07-11 2020-09-15 Verizon Patent And Licensing Inc. Devices and methods for application attestation
US20240073009A1 (en) * 2018-07-16 2024-02-29 Winkk, Inc Registration of endpoints by authentication server when onboarding to network
FR3084181A1 (fr) * 2018-07-20 2020-01-24 Orange Procede de coordination d'une pluralite de serveurs de gestion d'equipements
CN110831002B (zh) * 2018-08-10 2021-12-03 华为技术有限公司 一种密钥推演的方法、装置及计算存储介质
US10868876B2 (en) * 2018-08-10 2020-12-15 Cisco Technology, Inc. Authenticated service discovery using a secure ledger
US11100228B2 (en) * 2018-10-25 2021-08-24 Dell Products, L.P. System and method to recover FPGA firmware over a sideband interface
CN111147421B (zh) 2018-11-02 2023-06-16 中兴通讯股份有限公司 一种基于通用引导架构gba的认证方法及相关设备
WO2020102637A1 (en) * 2018-11-16 2020-05-22 Convida Wireless, Llc Control plane and user plane selection for small data
GB2579574B (en) 2018-12-03 2021-08-11 Advanced Risc Mach Ltd Bootstrapping with common credential data
GB2579571B (en) * 2018-12-03 2021-05-12 Advanced Risc Mach Ltd Device bootstrapping
EP3892021A1 (en) * 2018-12-06 2021-10-13 Convida Wireless, Llc Security lifecycle management of devices in a communications network
US11144045B2 (en) * 2018-12-18 2021-10-12 General Electric Company Apparatus and method for repair of edge devices
GB2584590A (en) * 2019-02-01 2020-12-16 Arm Ip Ltd Machine-to-machine communication mechanisms
US11516263B2 (en) * 2019-03-14 2022-11-29 T-Mobile Usa, Inc. Secure and transparent transport of application level protocols to non-IP data delivery communication channels
US11095742B2 (en) 2019-03-27 2021-08-17 Juniper Networks, Inc. Query proxy for delivery of dynamic system state
US11974199B2 (en) * 2019-04-04 2024-04-30 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for communication between LWM2M client and server
US11552781B2 (en) 2019-04-05 2023-01-10 Honeywell International Inc. Using error detection bits for cryptographic integrity and authentication
GB2582947B (en) * 2019-04-10 2021-10-13 Advanced Risc Mach Ltd Provisioning data on a device
CN113647052B (zh) * 2019-04-12 2024-07-12 飞力凯网路股份有限公司 信息处理终端、信息处理设备、信息处理方法、程序和信息处理系统
US11175899B2 (en) * 2019-04-17 2021-11-16 Vmware, Inc. Service upgrade integration for virtualized computing environments
US12164899B2 (en) 2019-04-17 2024-12-10 VMware LLC System for software service upgrade
GB2584527B (en) * 2019-05-10 2021-12-08 Advanced Risc Mach Ltd Machine to machine communications
FI3972220T3 (fi) * 2019-05-13 2025-08-27 Neo Wireless Llc Menetelmä ja laite resurssin poistamiseksi m2m-järjestelmässä
CN110213744A (zh) * 2019-05-31 2019-09-06 恒宝股份有限公司 一种智能卡实现m2m业务的方法、装置及智能卡
JP6856090B2 (ja) * 2019-06-07 2021-04-07 ダイキン工業株式会社 機器管理システム
CN112087753B (zh) * 2019-06-14 2021-12-03 华为技术有限公司 认证的方法、装置及系统
JP7315825B2 (ja) * 2019-06-14 2023-07-27 ダイキン工業株式会社 機器管理システムおよび認証方法
EP3767909B1 (de) * 2019-07-17 2025-02-26 Siemens Mobility GmbH Verfahren und kommunikationseinheit zur kryptographisch geschützten unidirektionalen datenübertragung von nutzdaten zwischen zwei netzwerken
WO2021026166A1 (en) 2019-08-06 2021-02-11 Urban Airship, Inc. Cross-channel orchestration of messages
CN110533128B (zh) * 2019-08-21 2023-08-04 上海唯链信息科技有限公司 一种基于加密的防伪溯源数据处理方法、装置、系统及介质
US11089062B2 (en) * 2019-08-29 2021-08-10 International Business Machines Corporation Automated security architecture formulation and deployment
CN110505307B (zh) * 2019-08-30 2022-04-26 公安部交通管理科学研究所 一种网间交通流数据的交换方法及系统
WO2021055883A2 (en) * 2019-09-18 2021-03-25 GPSip, Inc. Wireless location assisted zone guidance system incorporating secure transmission of location
JP7395716B2 (ja) 2019-09-19 2023-12-11 グーグル エルエルシー 解決可能なプライベートアドレスを用いたネットワークフィルタリング
CN112654013B (zh) * 2019-09-25 2022-06-14 华为技术有限公司 证书发放方法和装置
US11023220B2 (en) 2019-09-26 2021-06-01 Dell Products L.P. Firmware update with integrated smart sequence and action engine
US11429457B2 (en) 2019-09-26 2022-08-30 Dell Products L.P. System and method to securely exchange system diagnostics information between firmware, operating system and payload
EP3809259B1 (en) * 2019-10-16 2023-08-16 NXP USA, Inc. Network node firmware update
CN112714421B (zh) * 2019-10-24 2023-03-17 华为云计算技术有限公司 通信方法、网络设备以及终端设备
US11109343B2 (en) 2019-10-30 2021-08-31 Qualcomm Incorporated Transport protocol usage of confirmable versus non-confirmable notifications based on criticality of the observation
JP7092843B2 (ja) * 2019-10-31 2022-06-28 アシュラント，インコーポレーテッド 独立したコンピューティングリソースを管理し、および同期させるためのシステム、方法、装置、およびコンピュータプログラム製品
US11206135B2 (en) 2019-11-11 2021-12-21 International Business Machines Corporation Forward secrecy in Transport Layer Security (TLS) using ephemeral keys
US12373374B2 (en) * 2019-11-22 2025-07-29 STMicroelectronics (Grand Ouest) SAS Method for managing the operation of a system on chip, and corresponding system on chip
FR3103586B1 (fr) * 2019-11-22 2023-04-14 St Microelectronics Alps Sas Procédé de gestion du fonctionnement d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
CN112910826B (zh) * 2019-12-03 2022-08-23 中国移动通信有限公司研究院 一种初始配置方法及终端设备
US11658963B2 (en) 2019-12-04 2023-05-23 International Business Machines Corporation Cooperative communication validation
CN111181970B (zh) * 2019-12-31 2022-03-11 广州邦讯信息系统有限公司 一种使用国密算法应用于国产化fsu的方法和系统
KR102797871B1 (ko) 2020-01-16 2025-04-17 지티이 코포레이션 서비스 애플리케이션들과의 암호화된 통신을 위한 통신 네트워크에서의 앵커 키 생성 및 관리를 위한 방법, 디바이스, 및 시스템
WO2021093163A1 (en) 2020-01-16 2021-05-20 Zte Corporation Method, device, and system for application key generation and management in a communication network for encrypted communication with service applications
CN114846764B (zh) * 2020-01-16 2025-10-17 中兴通讯股份有限公司 为与服务应用的加密通信更新通信网络中锚密钥的方法、设备和系统
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
US10827329B1 (en) 2020-02-26 2020-11-03 At&T Mobility Ii Llc Facilitation of dynamic edge computations for 6G or other next generation network
US11418933B2 (en) 2020-03-19 2022-08-16 At&T Mobility Ii Llc Facilitation of container management for internet of things devices for 5G or other next generation network
US11627464B2 (en) 2020-05-14 2023-04-11 Cisco Technology, Inc. Grouping users by pre-shared key (PSK) in hospitality
US12032951B2 (en) 2020-06-19 2024-07-09 Apple Inc. Techniques for firmware updates with accessories
US11275576B2 (en) 2020-06-19 2022-03-15 Apple Inc. Techniques for firmware updates with accessories
CN111769940B (zh) * 2020-07-09 2023-02-03 天翼物联科技有限公司 一种密钥在线分发方法、系统及介质
CN111556487B (zh) * 2020-07-13 2020-11-06 深圳杰睿联科技有限公司 一种基于混合协议的sim卡空中传输系统及其工作方法
US12375454B2 (en) * 2020-07-15 2025-07-29 Hyundai Motor Company Method and apparatus for data anonymization and pseudonymization in M2M system
US11337096B2 (en) * 2020-07-17 2022-05-17 T-Mobile Usa, Inc. Predicting whether a user of a wireless telecommunication network will report a problem
CN111741128B (zh) * 2020-07-24 2024-08-23 上海城建职业学院 基于物联网技术的超高层建筑监测方法
CN111935697B (zh) * 2020-08-06 2022-08-19 中国联合网络通信集团有限公司 eSIM发现服务方法、发现服务器及eSIM终端
CN114143016B (zh) * 2020-08-14 2024-09-24 中兴通讯股份有限公司 基于通用引导架构gba的鉴权方法、及对应装置
US11811932B2 (en) 2020-10-26 2023-11-07 Proofpoint, Inc. Using signed tokens to verify short message service (SMS) message bodies
CN114765550B (zh) * 2020-12-31 2023-11-21 网联清算有限公司 一种业务安全处理方法及系统
CN112911728B (zh) * 2021-01-29 2023-05-02 极米科技股份有限公司 隧道直接链路建立中搜索对等终端的方法、终端及介质
CN112862994A (zh) * 2021-02-07 2021-05-28 中国第一汽车股份有限公司 一种etc防拆认证方法、etc、车载设备终端及系统
JP2022130947A (ja) * 2021-02-26 2022-09-07 株式会社日立製作所 暗号通信システム及び通信端末
US11689896B2 (en) * 2021-02-26 2023-06-27 EMC IP Holding Company LLC Secure remote access to private networks without internet connectivity
US11895133B2 (en) 2021-04-05 2024-02-06 Bank Of America Corporation Systems and methods for automated device activity analysis
US11558850B2 (en) 2021-04-13 2023-01-17 Qualcomm Incorporated Methods for handling anomaly notification messages
CN113065830B (zh) * 2021-04-19 2022-01-18 深圳市库宝软件有限公司 仓储系统属性预修改方法、装置、电子设备及存储介质
US11792165B2 (en) 2021-06-04 2023-10-17 Bank Of America Corporation Supporting data processing transactions using machine to machine (M2M) data transfer
US11784981B2 (en) 2021-06-04 2023-10-10 Bank Of America Corporation Data processing transactions using machine to machine (M2M) data transfer
US11831688B2 (en) * 2021-06-18 2023-11-28 Capital One Services, Llc Systems and methods for network security
GB2608634B (en) 2021-07-08 2024-09-18 Vodafone Group Services Ltd Device data validity
GB2609242B (en) * 2021-07-26 2024-07-17 Dabco Ltd Waking up a device
US11956199B2 (en) 2021-07-26 2024-04-09 Airship Group, Inc. Software development kit enabled cross-channel two-way software application messaging
US11265370B1 (en) * 2021-07-27 2022-03-01 Bank Of America Corporation Machine to machine (M2M) data transfer between data servers
US11785018B2 (en) 2021-07-29 2023-10-10 Bank Of America Corporation Mobile device management system for securely managing device communication
US12095744B2 (en) * 2021-10-01 2024-09-17 TrustFour Technologies, Inc. Mutual key management service system and method
US12335205B2 (en) 2021-10-15 2025-06-17 Airship Group, Inc. Automated interactive communication trigger in message distribution
US11941266B2 (en) 2021-10-20 2024-03-26 Samsung Electronics Co., Ltd. Resource isolation in computational storage devices
US20230137082A1 (en) * 2021-10-31 2023-05-04 Qualcomm Incorporated Generic Bootstrapping Architecture (GBA) Signaling To Indicate Need For Key Renegotiation
EP4187845A1 (en) * 2021-11-25 2023-05-31 Sandvik Mining and Construction Oy User authentication in an industrial system
WO2023125642A1 (zh) * 2021-12-31 2023-07-06 中国移动通信有限公司研究院 认证和/或密钥管理方法、第一设备、终端及通信设备
CN114490075B (zh) * 2022-02-07 2024-09-10 Oppo广东移动通信有限公司 虚拟资源的获取方法、装置、电子设备、存储介质及产品
US12171192B1 (en) 2022-02-14 2024-12-24 GPSip, Inc. Graphical shepherding
US12124833B2 (en) * 2022-05-13 2024-10-22 Micron Technology, Inc. Techniques for managing offline identity upgrades
US11968093B1 (en) * 2022-09-20 2024-04-23 Gen Digital Inc. Efficient scaling of a domain name system service architecture
CN115694891B (zh) * 2022-09-23 2024-05-14 智己汽车科技有限公司 一种基于中央计算平台的路侧设备通信系统及方法
US11709660B1 (en) 2022-10-12 2023-07-25 Stodge Inc. Integrated third-party application builder trigger for message flow
US12255860B2 (en) 2022-10-12 2025-03-18 Stodge Inc. Integrated third-party application builder trigger for message flow
CN115811778B (zh) * 2022-11-15 2025-12-19 西安广和通无线软件有限公司 一种业务处理方法、装置、存储介质及设备
WO2024118059A1 (en) * 2022-11-29 2024-06-06 Rakuten Mobile, Inc. Over-the-air (ota) platform for tr-069 devices to manage vendor-specific configuration and firmware
KR102522910B1 (ko) * 2022-12-29 2023-04-18 주식회사 에스티씨랩 프록시 방식의 서비스 지속성 보장 시스템 및 방법
US12507065B2 (en) * 2023-01-05 2025-12-23 Qualcomm Incorporated Preconfigured reference signal resources for secret key extraction
US12557787B1 (en) 2023-02-27 2026-02-24 GPSip, Inc. Wireless location assisted zone guidance system predictive ramped stimulation
US20240333652A1 (en) * 2023-03-31 2024-10-03 Zscaler, Inc. Systems and methods to detect and bypass network throttling in User Datagram Protocol (UDP) connections
US20240340631A1 (en) * 2023-04-04 2024-10-10 T-Mobile Innovations Llc Subscriber Identity Module Over-The-Air Push Notification
EP4542414A1 (de) * 2023-10-18 2025-04-23 Siemens Aktiengesellschaft Computer-implementiertes verfahren und system zur synchronisation von datenelementen
WO2026027900A1 (en) * 2024-08-02 2026-02-05 Dabco Limited Secure communications for constrained devices

Family Cites Families (147)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US102690A (en) * 1870-05-03 Improvement in pipe-tongs
US6185678B1 (en) * 1997-10-02 2001-02-06 Trustees Of The University Of Pennsylvania Secure and reliable bootstrap architecture
US6578066B1 (en) 1999-09-17 2003-06-10 Alteon Websystems Distributed load-balancing internet servers
US7437305B1 (en) * 1999-05-11 2008-10-14 Christopher Angel Kantarjiev Scheduling delivery of products via the internet
US7069452B1 (en) 2000-07-12 2006-06-27 International Business Machines Corporation Methods, systems and computer program products for secure firmware updates
US7774231B2 (en) * 2000-09-29 2010-08-10 Nokia Corporation Electronic payment methods for a mobile device
US7184984B2 (en) 2000-11-17 2007-02-27 Valaquenta Intellectual Properties Limited Global electronic trading system
US20020136410A1 (en) * 2001-03-26 2002-09-26 Sun Microsystems, Inc. Method and apparatus for extinguishing ephemeral keys
US20020157002A1 (en) * 2001-04-18 2002-10-24 Messerges Thomas S. System and method for secure and convenient management of digital electronic content
EP1271875A1 (en) * 2001-06-21 2003-01-02 Koninklijke Philips Electronics N.V. Device arranged for exchanging data, and method of manufacturing
US7058926B2 (en) 2001-08-13 2006-06-06 International Business Machines Corporation Tool for implementing Floating-Point related applications using customized language
US8140845B2 (en) * 2001-09-13 2012-03-20 Alcatel Lucent Scheme for authentication and dynamic key exchange
US7076657B2 (en) * 2001-12-28 2006-07-11 Siemens Communications, Inc. Use of short message service (SMS) for secure transactions
US6804777B2 (en) 2002-05-15 2004-10-12 Threatguard, Inc. System and method for application-level virtual private network
US20030229686A1 (en) 2002-06-07 2003-12-11 Kris Kortright System and method for synchronizing the configuration of distributed network management applications
US7296156B2 (en) * 2002-06-20 2007-11-13 International Business Machines Corporation System and method for SMS authentication
FI20030943A7 (fi) 2003-06-25 2004-12-26 Nokia Corp Menetelmä machine-to-machine-yksikön parametrien konfiguroimiseksi ja machine-to-machine-yksikkö
JP4617763B2 (ja) * 2003-09-03 2011-01-26 ソニー株式会社 機器認証システム、機器認証サーバ、端末機器、機器認証方法、および機器認証プログラム
KR20050049222A (ko) * 2003-11-21 2005-05-25 에스케이텔레텍주식회사 단문메시지의 기밀 전송 방법
US20050120106A1 (en) 2003-12-02 2005-06-02 Nokia, Inc. System and method for distributing software updates to a network appliance
US7360129B2 (en) 2003-12-30 2008-04-15 Broadcom Corporation Simultaneous switch test mode
FR2867652B1 (fr) * 2004-03-15 2006-05-26 Wavecom Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants
JP2008530879A (ja) 2005-02-11 2008-08-07 ノキア コーポレイション 通信ネットワークにおいてブートストラッピング手順を提供する方法及び装置
US7628322B2 (en) * 2005-03-07 2009-12-08 Nokia Corporation Methods, system and mobile device capable of enabling credit card personalization using a wireless network
FI20050384A0 (fi) 2005-04-14 2005-04-14 Nokia Corp Geneerisen todentamisarkkitehtuurin käyttö Internet-käytäntöavainten jakeluun matkaviestimissä
US9167471B2 (en) * 2009-05-07 2015-10-20 Jasper Technologies, Inc. System and method for responding to aggressive behavior associated with wireless devices
US9226151B2 (en) 2006-04-04 2015-12-29 Jasper Wireless, Inc. System and method for enabling a wireless device with customer-specific services
US8122240B2 (en) 2005-10-13 2012-02-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for establishing a security association
US8005879B2 (en) * 2005-11-21 2011-08-23 Sap Ag Service-to-device re-mapping for smart items
WO2007063420A2 (en) * 2005-12-01 2007-06-07 Nokia Corporation Authentication in communications networks
US8522025B2 (en) * 2006-03-28 2013-08-27 Nokia Corporation Authenticating an application
US8037522B2 (en) 2006-03-30 2011-10-11 Nokia Corporation Security level establishment under generic bootstrapping architecture
US20070248232A1 (en) 2006-04-10 2007-10-25 Honeywell International Inc. Cryptographic key sharing method
US20070254711A1 (en) * 2006-04-26 2007-11-01 Young David C Accessing a SIM card to obtain configuration information by a remote embedded communication module
DE102006054091B4 (de) * 2006-11-16 2008-09-11 Siemens Ag Bootstrapping-Verfahren
US20080120705A1 (en) * 2006-11-17 2008-05-22 Bellsouth Intellectual Property Corporation Systems, Methods and Computer Program Products Supporting Provision of Web Services Using IMS
US7774008B2 (en) * 2006-12-22 2010-08-10 Cellco Partnership MDN-less SMS messaging (network solution) for wireless M2M application
US7992198B2 (en) * 2007-04-13 2011-08-02 Microsoft Corporation Unified authentication for web method platforms
WO2009002236A1 (en) 2007-06-27 2008-12-31 Telefonaktiebolaget Lm Ericsson (Publ) A method and apparatus for enabling connectivity in a communication network
WO2009004590A2 (en) 2007-07-03 2009-01-08 Nokia Siemens Networks Oy Method, apparatus, system and computer program for key parameter provisioning
US8201219B2 (en) * 2007-09-24 2012-06-12 Bridgewater Systems Corp. Systems and methods for server load balancing using authentication, authorization, and accounting protocols
CN103001940A (zh) * 2007-10-05 2013-03-27 交互数字技术公司 由wtru使用的用于建立安全本地密钥的方法
US7984486B2 (en) 2007-11-28 2011-07-19 Nokia Corporation Using GAA to derive and distribute proxy mobile node home agent keys
US8625433B2 (en) * 2007-12-19 2014-01-07 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for use in a communications network
KR101861607B1 (ko) * 2008-01-18 2018-05-29 인터디지탈 패튼 홀딩스, 인크 Ｍ2ｍ 통신을 인에이블하는 방법 및 장치
US8090963B2 (en) * 2008-02-19 2012-01-03 Research In Motion Limited Automated power management of a peripheral device
US8867989B2 (en) * 2008-04-15 2014-10-21 Ams International Ag Method for reducing a noise in a signal received in a contactless-card interrogator and a circuit to perform said method
NZ589294A (en) * 2008-06-06 2012-07-27 Ericsson Telefon Ab L M Cryptographic key generation using parameters based on a set of generated keys, an incrementing sequence number and an anonymity key
WO2010012318A1 (en) * 2008-07-31 2010-02-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods, nodes, system, computer programs and computer program products for secure user subscription or registration
US8386767B2 (en) * 2008-08-15 2013-02-26 Telefonaktiebolaget L M Ericsson (Publ) Methods and systems for bootstrapping security key information using session initiation protocol
WO2010041347A1 (en) * 2008-10-10 2010-04-15 Telefonaktiebolaget L M Ericsson (Publ) Gateway apparatus, authentication server, control method thereof and computer program
US8578153B2 (en) * 2008-10-28 2013-11-05 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for provisioning and managing a device
EP2187592A1 (en) 2008-11-13 2010-05-19 Vodafone Holding GmbH Machine-to machine device and smartcard for use in the device
US20100199095A1 (en) * 2009-01-30 2010-08-05 Texas Instruments Inc. Password-Authenticated Association Based on Public Key Scrambling
EP2404459A2 (en) 2009-03-06 2012-01-11 Interdigital Patent Holdings, Inc. Platform validation and management of wireless devices
US8213971B2 (en) * 2009-04-27 2012-07-03 Qualcomm Incorporated Apparatus and method for activating computer applications with SMS messaging
EP2264642B1 (en) 2009-06-02 2014-02-26 Vodafone Holding GmbH Data exchange with a man-machine-device using short range radio communication
ES2391603T3 (es) 2009-06-02 2012-11-28 Vodafone Holding Gmbh Registro de un dispositivo móvil en una red de comunicaciones móviles
US8682903B2 (en) * 2009-06-30 2014-03-25 International Business Machines Corporation System and method for synchronized content directories on cluster devices
US9590961B2 (en) * 2009-07-14 2017-03-07 Alcatel Lucent Automated security provisioning protocol for wide area network communication devices in open device environment
EP3264686B1 (en) * 2009-10-16 2018-12-12 Tekelec, Inc. Methods, systems, and computer readable media for providing diameter signaling router with integrated monitoring and/or firewall functionality
WO2011063826A1 (en) * 2009-11-24 2011-06-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for use in a generic bootstrapping architecture
EP2336986A1 (en) 2009-12-17 2011-06-22 Gemalto SA Method of personalizing an application embedded in a secured electronic token
CN102656841B (zh) * 2009-12-18 2015-07-08 诺基亚公司 凭证转移
EP2343916B1 (en) 2010-01-12 2018-05-09 Koninklijke KPN N.V. Secure coupling of hardware components
WO2011085810A1 (en) 2010-01-14 2011-07-21 Nokia Siemens Networks Oy Method and device for data processing in a wireless network
DE102010001076A1 (de) 2010-01-21 2011-07-28 PMDTechnologies GmbH, 57076 Induktiver Näherungssensor und Verfahren zur Näherungsmessung
US8954739B2 (en) 2010-01-28 2015-02-10 Koninklijke Kpn N.V. Efficient terminal authentication in telecommunication networks
CN102783115B (zh) * 2010-02-09 2016-08-03 交互数字专利控股公司 用于可信联合标识的方法和装置
US8447970B2 (en) * 2010-02-09 2013-05-21 Microsoft Corporation Securing out-of-band messages
DE102010010760B4 (de) * 2010-03-09 2012-02-02 Siemens Aktiengesellschaft Verfahren zur Vergabe eines Schlüssels an ein einem drahtlosen Sensor-Aktor-Netz neu hinzuzufügendes Teilnehmergerät
CN102196436B (zh) * 2010-03-11 2014-12-17 华为技术有限公司 安全认证方法、装置及系统
WO2011115407A2 (en) * 2010-03-15 2011-09-22 Samsung Electronics Co., Ltd. Method and system for secured remote provisioning of a universal integrated circuit card of a user equipment
US8432871B1 (en) * 2010-03-26 2013-04-30 Juniper Networks, Inc. Offloading mobile traffic from a mobile core network
US9729516B2 (en) * 2010-04-09 2017-08-08 Gemalto Sa Method of machine-to-machine communication
WO2011131220A1 (en) * 2010-04-19 2011-10-27 Nokia Siemens Networks Oy Gba and ims authentication procedures
US8661257B2 (en) 2010-05-18 2014-02-25 Nokia Corporation Generic bootstrapping architecture usage with Web applications and Web pages
US9602277B2 (en) * 2010-06-07 2017-03-21 Protected Mobilty, Llc User interface systems and methods for secure message oriented communications
US9143324B2 (en) * 2010-06-07 2015-09-22 Protected Mobility, Llc Secure messaging
CN102299797A (zh) * 2010-06-23 2011-12-28 财团法人工业技术研究院 认证方法、密钥分配方法及认证与密钥分配方法
WO2011163561A1 (en) * 2010-06-25 2011-12-29 Interdigital Patend Holdings, Inc. Interface of an m2m server with the 3gpp core network
US8464061B2 (en) * 2010-08-30 2013-06-11 Apple Inc. Secure wireless link between two devices using probes
GB201015324D0 (en) 2010-09-14 2010-10-27 Vodafone Ip Licensing Ltd Secure association
US9185054B2 (en) * 2010-09-15 2015-11-10 Oracle International Corporation System and method for providing zero buffer copying in a middleware machine environment
CN102136934B (zh) * 2010-10-21 2015-01-21 华为技术有限公司 实现Zigbee设备远程升级的方法、装置及网络系统
CN102469455B (zh) * 2010-11-08 2016-04-13 中兴通讯股份有限公司 基于通用引导架构的机器类通信设备分组管理方法及系统
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
KR20120067459A (ko) * 2010-12-16 2012-06-26 삼성전자주식회사 서비스 제공업체와 이동망 사업자간의 기기간 단말별 서비스 인증 방법 및 장치
CN102595389B (zh) 2011-01-14 2017-11-03 中兴通讯股份有限公司 一种mtc服务器共享密钥的方法及系统
WO2012113136A1 (en) * 2011-02-22 2012-08-30 Renesas Mobile Corporation Method and apparatus for establishing a device-to-device connection
EP2679073A4 (en) 2011-02-25 2016-10-19 Ericsson Telefon Ab L M IP COMMUNICATION AUTHORIZATION WITH A MACHINE MACHINE DEVICE
TR201103175A2 (tr) * 2011-04-01 2012-10-22 Turkcell �Let���M H�Zmetler� Anon�M ��Rket� Güvenli mesaj iletimi sağlayan bir sistem ve yöntem
DE102011007534A1 (de) 2011-04-15 2012-10-18 Vodafone Holding Gmbh Datenübermittlung zu einem Identifizierungsmodul in einem Mobilfunkendgerät
WO2011157115A2 (zh) * 2011-05-30 2011-12-22 华为技术有限公司 通知网络能力的方法、装置和系统
JP2013005430A (ja) 2011-06-15 2013-01-07 Lg Electronics Inc 無線通信システムにおけるデータ送信方法及び装置
GB2492750A (en) 2011-07-04 2013-01-16 Sony Corp Communications system with reconfigurable user identification module
CN102869015B (zh) * 2011-07-04 2017-12-15 中兴通讯股份有限公司 一种mtc设备触发的方法和系统
US9131330B2 (en) * 2011-07-15 2015-09-08 Telefonaktiebolaget L M Ericsson (Publ) M2M services enablement architecture for cellular access networks
KR101295580B1 (ko) * 2011-07-15 2013-08-09 엘지전자 주식회사 무선접속시스템에서 harq 채널식별자를 이용한 harq 동작 지원방법 및 장치
US9185080B2 (en) 2011-08-12 2015-11-10 Intel Deutschland Gmbh Data transmitting devices, data receiving devices, methods for controlling a data transmitting device, and methods for controlling a data receiving device
CN103858452B (zh) 2011-10-03 2018-05-08 Lg电子株式会社 处理sms相关信号的移动性管理实体
CN105577364B (zh) 2011-10-27 2019-11-05 华为技术有限公司 一种加密方法、解密方法和相关装置
EP2774402B1 (en) * 2011-10-31 2015-12-30 Telefonaktiebolaget LM Ericsson (Publ) Securing data communications in a communications network
CN103108311B (zh) 2011-11-11 2017-11-28 中兴通讯股份有限公司 一种mtc设备与uicc绑定的方法、装置及系统
CN102497630B (zh) * 2011-11-25 2015-07-01 北京握奇数据系统有限公司 一种m2m设备及其实现业务的方法、智能卡和通信模组
CN104145465B (zh) * 2012-02-02 2017-08-29 诺基亚通信公司 机器类型通信中基于群组的自举的方法和装置
EP2815590B1 (en) * 2012-02-13 2016-12-21 Telefonaktiebolaget LM Ericsson (publ) M2m service enablement over access networks
WO2013120225A1 (en) 2012-02-16 2013-08-22 Nokia Siemens Networks Oy Method and system for group based service bootstrap in m2m environment
US8577337B2 (en) * 2012-03-05 2013-11-05 Rogers Communications Inc. Radio management method and system using embedded universal integrated circuit card
US9380038B2 (en) * 2012-03-09 2016-06-28 T-Mobile Usa, Inc. Bootstrap authentication framework
GB2501724A (en) 2012-05-02 2013-11-06 Vodafone Ip Licensing Ltd Routing messages in a telecommunications network to machine-to-machine devices
KR20130127826A (ko) * 2012-05-15 2013-11-25 엠디에스테크놀로지 주식회사 오티에이를 이용한 엠투엠 단말기의 응용프로그램 관리 시스템
CN103428666A (zh) * 2012-05-24 2013-12-04 华为技术有限公司 一种计费的方法及装置
WO2013191515A1 (ko) * 2012-06-22 2013-12-27 엘지전자 주식회사 무선 통신 시스템에서 서버를 활성화 또는 비활성화하기 위한 방법 및 장치
MX344082B (es) * 2012-09-03 2016-12-02 Ericsson Telefon Ab L M Metodos y aparatos para la disposicion automatica de identificadores externos que se utilizan para los dispositivos tipo maquina en una red 3gpp.
WO2014039387A1 (en) * 2012-09-04 2014-03-13 Interdigital Patent Holdings, Inc. Method and apparatus for using multiple universal resource identifiers in m2m communications
US9167042B1 (en) * 2012-09-10 2015-10-20 Amazon Technologies, Inc. Maintaining communication channel for device notifications
JP2015532791A (ja) * 2012-09-13 2015-11-12 日本電気株式会社 Ｍｔｃシステムにおけるキー管理
WO2014040638A1 (en) * 2012-09-14 2014-03-20 Telefonaktiebolaget L M Ericsson Operating a data back end node in a data layered architecture network
CN104685825B (zh) 2012-09-26 2018-07-06 英派尔科技开发有限公司 一种安全通信的方法、计算设备及非暂态计算机可读存储介质
KR101538424B1 (ko) * 2012-10-30 2015-07-22 주식회사 케이티 결제 및 원격 모니터링을 위한 사용자 단말
EP3185469B1 (en) * 2012-10-30 2018-10-17 LG Electronics Inc. Method and apparatus for authenticating access authority for specific resource in wireless communication system
US20140126548A1 (en) * 2012-11-05 2014-05-08 Qualcomm Incorporated Dynamic paging channel selection in a machine-to-machine wireless wide area network
US9769801B2 (en) * 2012-11-05 2017-09-19 Lg Electronics Inc. Method and apparatus for updating information regarding specific resource in wireless communication system
CN103812644B (zh) * 2012-11-09 2017-04-26 华为终端有限公司 一种信息配置方法、设备及系统
EP2741465B1 (en) * 2012-12-04 2021-03-17 Orange Method and device for managing secure communications in dynamic network environments
US10257800B2 (en) * 2012-12-05 2019-04-09 Lg Electronics Inc. Method and apparatus for authenticating access authorization in wireless communication system
WO2014093613A1 (en) 2012-12-12 2014-06-19 Interdigital Patent Holdings, Inc. Independent identity management systems
US9277378B2 (en) * 2012-12-21 2016-03-01 Verizon Patent And Licensing Inc. Short message service validation engine
US9262242B2 (en) * 2012-12-31 2016-02-16 Verizon Patent And Licensing Inc. Machine-to-machine (“M2M”) device client systems, methods, and interfaces
US9232524B2 (en) * 2013-01-05 2016-01-05 Qualcomm Incorporated Multiple access scheme for multi-channels of a network with a limited link budget
US8781104B1 (en) * 2013-01-11 2014-07-15 American Express Travel Related Services Company, Inc. System and method for enabling tracking of contract provisions in a service message switching marketplace
CN104937895B (zh) * 2013-01-18 2018-04-24 Lg电子株式会社 在无线通信系统中控制访问的方法和设备
US9002997B2 (en) 2013-01-22 2015-04-07 Amazon Technologies, Inc. Instance host configuration
US8782774B1 (en) * 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US9603189B2 (en) * 2013-03-08 2017-03-21 Nokia Technologies Oy Method and apparatus for multisim devices with embedded SIM functionality
WO2014165747A1 (en) 2013-04-05 2014-10-09 Interdigital Patent Holdings, Inc. Securing peer-to-peer and group communications
US9124403B2 (en) * 2013-04-30 2015-09-01 Qualcomm Incorporated Puncturing scheme based decoder optimizations
US9800621B2 (en) 2013-05-06 2017-10-24 Convida Wireless, Llc Registration for device triggering
US20150019637A1 (en) * 2013-07-12 2015-01-15 Seven Networks, Inc. Distributed caching systems with configurable extended caching optimization
WO2015013645A1 (en) * 2013-07-25 2015-01-29 Convida Wireless, Llc End-to-end m2m service layer sessions
US9189930B2 (en) * 2013-08-20 2015-11-17 Verizon Patent And Licensing Inc. Customizing alerts on an alerting device
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US9100175B2 (en) * 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
GB2518254B (en) 2013-09-13 2020-12-16 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
US9426729B2 (en) * 2013-10-22 2016-08-23 Cisco Technology, Inc. Network selection for mobile client devices in integrated cellular and Wi-Fi networks
WO2015072899A1 (en) * 2013-11-15 2015-05-21 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for bootstrapping of resource constrained devices

Also Published As

Publication number Publication date
ES2893353T3 (es) 2022-02-08
GB201409643D0 (en) 2014-07-16
EP3044973A1 (en) 2016-07-20
GB201414999D0 (en) 2014-10-08
GB2518522A (en) 2015-03-25
EP3044934A2 (en) 2016-07-20
US20170295143A1 (en) 2017-10-12
GB2518255A (en) 2015-03-18
GB201415925D0 (en) 2014-10-22
ES2933426T3 (es) 2023-02-08
GB2518296A (en) 2015-03-18
US20160234183A1 (en) 2016-08-11
EP3767984C0 (en) 2024-02-21
EP3800862A1 (en) 2021-04-07
US20160226828A1 (en) 2016-08-04
GB2584371A (en) 2020-12-02
GB2518301B (en) 2020-07-15
WO2015036785A1 (en) 2015-03-19
EP3044982A1 (en) 2016-07-20
GB2518976B (en) 2020-11-04
US10313307B2 (en) 2019-06-04
GB2586549A (en) 2021-02-24
EP3044976A1 (en) 2016-07-20
US20160234181A1 (en) 2016-08-11
US20160232116A1 (en) 2016-08-11
EP3044928B1 (en) 2020-11-04
GB2583432A (en) 2020-10-28
EP3767984B1 (en) 2024-02-21
US20160226847A1 (en) 2016-08-04
GB201409641D0 (en) 2014-07-16
GB2520591B (en) 2020-09-23
WO2015036789A3 (en) 2015-06-11
EP3832982A1 (en) 2021-06-09
US20160234170A1 (en) 2016-08-11
GB2518296B (en) 2021-02-24
EP3044982B1 (en) 2021-07-21
US10412052B2 (en) 2019-09-10
EP3767984A1 (en) 2021-01-20
WO2015036793A1 (en) 2015-03-19
GB201415918D0 (en) 2014-10-22
GB2518975A (en) 2015-04-08
US10673820B2 (en) 2020-06-02
EP3044927A1 (en) 2016-07-20
GB2518256A (en) 2015-03-18
GB2583432B (en) 2021-02-24
US11044234B2 (en) 2021-06-22
WO2015036773A2 (en) 2015-03-19
US9635057B2 (en) 2017-04-25
GB2519429A (en) 2015-04-22
WO2015036782A1 (en) 2015-03-19
GB2519429B (en) 2020-12-23
US20160234683A1 (en) 2016-08-11
GB202012632D0 (en) 2020-09-30
GB2520591A (en) 2015-05-27
US20160234255A1 (en) 2016-08-11
EP3800862B1 (en) 2022-11-09
WO2015036771A1 (en) 2015-03-19
GB2584371B (en) 2021-03-17
US10313308B2 (en) 2019-06-04
US10764252B2 (en) 2020-09-01
EP3044985A1 (en) 2016-07-20
EP3832982C0 (en) 2024-02-21
US20190306123A1 (en) 2019-10-03
CN105706469A (zh) 2016-06-22
EP3044975B1 (en) 2021-05-26
GB2518976A (en) 2015-04-08
GB2518301A (en) 2015-03-18
EP3044975B8 (en) 2021-06-30
GB2518522B (en) 2020-07-22
EP3044983B1 (en) 2021-05-19
WO2015036773A3 (en) 2015-06-11
WO2015036777A1 (en) 2015-03-19
CN105706469B (zh) 2020-03-10
GB2518254A (en) 2015-03-18
US11063912B2 (en) 2021-07-13
EP3044976B1 (en) 2021-11-03
US20200322315A1 (en) 2020-10-08
US20160234686A1 (en) 2016-08-11
WO2015036778A1 (en) 2015-03-19
WO2015036783A1 (en) 2015-03-19
WO2015036789A2 (en) 2015-03-19
GB2518521A (en) 2015-03-25
GB201414997D0 (en) 2014-10-08
EP3044975A1 (en) 2016-07-20
GB2586549B (en) 2021-05-26
GB201415003D0 (en) 2014-10-08
GB201415931D0 (en) 2014-10-22
GB201415921D0 (en) 2014-10-22
GB202016853D0 (en) 2020-12-09
EP3044974A1 (en) 2016-07-20
EP3044984B1 (en) 2021-07-21
EP3832982B1 (en) 2024-02-21
US10630646B2 (en) 2020-04-21
WO2015036776A1 (en) 2015-03-19
GB2518254B (en) 2020-12-16
EP3044928A1 (en) 2016-07-20
US10439991B2 (en) 2019-10-08
EP3855701A1 (en) 2021-07-28
GB201409663D0 (en) 2014-07-16
EP3044983A1 (en) 2016-07-20
GB2518257A (en) 2015-03-18
US20160234177A1 (en) 2016-08-11
GB201415927D0 (en) 2014-10-22
GB2518975B (en) 2020-12-30
GB202012324D0 (en) 2020-09-23
EP3044973B1 (en) 2021-03-17
EP3044984A1 (en) 2016-07-20
US20160234182A1 (en) 2016-08-11
ES2979346T3 (es) 2024-09-25
US10305862B2 (en) 2019-05-28
GB201409652D0 (en) 2014-07-16
WO2015036772A1 (en) 2015-03-19
WO2015036791A1 (en) 2015-03-19

Similar Documents

Publication Publication Date Title
ES2973643T3 (es) Comunicación con un dispositivo máquina a máquina