EP3044984B1 - Communication avec un dispositif machine à machine - Google Patents
Communication avec un dispositif machine à machine Download PDFInfo
- Publication number
- EP3044984B1 EP3044984B1 EP14776683.6A EP14776683A EP3044984B1 EP 3044984 B1 EP3044984 B1 EP 3044984B1 EP 14776683 A EP14776683 A EP 14776683A EP 3044984 B1 EP3044984 B1 EP 3044984B1
- Authority
- EP
- European Patent Office
- Prior art keywords
- server
- naf
- lifetime
- interface
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004891 communication Methods 0.000 claims description 115
- 238000000034 method Methods 0.000 claims description 114
- 230000008569 process Effects 0.000 claims description 32
- 230000000977 initiatory effect Effects 0.000 claims description 4
- 238000007726 management method Methods 0.000 description 49
- 230000004044 response Effects 0.000 description 20
- 230000006870 function Effects 0.000 description 19
- 238000005516 engineering process Methods 0.000 description 13
- 239000000463 material Substances 0.000 description 13
- 230000008901 benefit Effects 0.000 description 11
- 230000007246 mechanism Effects 0.000 description 10
- 239000011269 tar Substances 0.000 description 9
- 238000012795 verification Methods 0.000 description 8
- 238000012546 transfer Methods 0.000 description 7
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- CSRZQMIRAZTJOY-UHFFFAOYSA-N trimethylsilyl iodide Substances C[Si](C)(C)I CSRZQMIRAZTJOY-UHFFFAOYSA-N 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000002195 synergetic effect Effects 0.000 description 4
- 239000013598 vector Substances 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000009795 derivation Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000007723 transport mechanism Effects 0.000 description 3
- VIEYMVWPECAOCY-UHFFFAOYSA-N 7-amino-4-(chloromethyl)chromen-2-one Chemical compound ClCC1=CC(=O)OC2=CC(N)=CC=C21 VIEYMVWPECAOCY-UHFFFAOYSA-N 0.000 description 2
- 230000004075 alteration Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 239000000796 flavoring agent Substances 0.000 description 2
- 235000019634 flavors Nutrition 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000036316 preload Effects 0.000 description 2
- 238000010561 standard procedure Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 238000004846 x-ray emission Methods 0.000 description 2
- 206010003591 Ataxia Diseases 0.000 description 1
- 206010010947 Coordination abnormal Diseases 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 208000028756 lack of coordination Diseases 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 239000011885 synergistic combination Substances 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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
- 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
-
- 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/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
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving 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
-
- 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
Definitions
- the present invention relates to a method and system for administering an interface between a machine to machine, M2M, device and a network application function, NAF, for secure communication between the M2M device and the NAF.
- M2M devices are often numerous, hard-to-reach, and have constrained capabilities (owing to low cost, small size, low processing power or limited battery life). All of this makes their management, often remote, very complicated. Moreover, M2M devices often need to be managed in a secure manner. For example, they may contain information that is commercially sensitive and/or confidential for the one or more entities that manage and/or own said devices. There is a need to remotely manage them in a secure way, while respecting these constraints.
- the M2M device needs to be able to contact a device management (DM) server in a secure manner. Whilst at the time of manufacture the device may be pre-provisioned with the necessary addresses and URLs to locate this DM server, this requires device suppliers to have knowledge about the device's end users. Furthermore, should the addresses or locations of the DM server change then the M2M devices will require updating to prevent communications from becoming lost or misdirected.
- DM device management
- M2M devices may be provisioned with security information, for example a shared key(s).
- security information may have an associated lifetime, during which it may be valid for use in administering a secure interface between, for example, the M2M device and a DM server or Network Application Function (NAF).
- Administering the interface may include registering the interface and/or updating an existing registration.
- the secure interface registration may also have a lifetime, during which the interface may be used for secure communications, but after the expiry of which the interface may no longer be used for secure communications. New security information may therefore need to be re-bootstrapped from a bootstrapping server on a regular basis so that the security information remains valid and can be used for administering the interface.
- GAA Generic Authentication Architecture
- GBA Generic Bootstrapping Architecture
- GAA Generic Bootstrapping Architecture
- GBA is a standard which enables a shared secret to be derived (bootstrapped) from the existing security association between a mobile network and a SIM card. This involves a network element called a Bootstrapping Server Function (BSF).
- BSF Bootstrapping Server Function
- GBA leverages the security of a SIM card (UICC) to authenticate mobile equipment, and then derive key material for general-purpose applications.
- GBA may be advantageously used to provide high-security to the communication between a client and the server, thus allowing remotely managing, controlling and, in general, communicating with a device in a high security manner.
- GBA (or a GBA-like architecture) is used for enabling a secure communication with the device (which, according to an aspect of the present disclosure, may be an M2M device), said communication being between a server and a client, the client being associated with the device, and wherein this communication is done for managing the device and/or services provided by (or via) the device, thus enabling a secure management of that device and/or the services provided by (or via) the device.
- the device and/or the services provided by (or via) the device can be safely, securely and efficiently managed in a remote manner via a remote server.
- GBA has been developed mainly for securing mobile broadcast (e.g. pay TV and equivalents). Indeed, standards for Multimedia Broadcast Multicast Service (MBMS) rely on GBA. Similarly, Open Mobile Alliance (OMA) Mobile Broadcast Services Enabler Suite (BCAST) smartcard profile relies on GBA. To date, most of the limited number of deployments of GBA in the world has been for mobile broadcast. GBA has also been standardised as an optional feature in conjunction with presence services, and within miscellaneous "federated identity” services (e.g. Liberty Alliance, OpenID). In general, it is understood that GBA has been designed for use with mobile devices, such as mobile phones, laptop, computers, and many of the designed features have been provisioned with this in mind.
- OMA Open Mobile Alliance
- BCAST Mobile Broadcast Services Enabler Suite
- GBA Push A variant of GBA, called "GBA Push", has been proposed for securing a message between a client and a DM server in the context of OMA Device Management Security.
- the OMA Device Management is specifically designed for management of mobile devices such as mobile phones, tablet, computers, etc.
- TS 102 690 A different recent standard document (TS 102 690) merely mentions, in the context of M2M communications, the use of a standard GBA to secure communications between a device/gateway service layer and a network service layer.
- the service provider can request the user to enter their phone number, send an SMS one-time password to that phone number, and ask the user to read the SMS and enter the password.
- SIM card e.g. PCs, laptops, Wi-fi-only tablets etc.
- GBA relies on a SIM card/UICC in order to work, there has been no interest in using it.
- the OMA Device Management uses GBA Push for securing a message between a client and a DM server, and there is no explanation of how a similar architecture could be used or even modified for managing the device.
- the OMA Device Management is not compatible for use with an M2M device, as discussed above.
- the standard document mentioned above uses a standard GBA to secure communications between a device/gateway service layer and a network service layer.
- the communication is not used for device/service management-related communications, and it is not clear, based on the observations made above, how a similar architecture could be used or even modified for managing the device from the server.
- the OMA Device Management and the standard document are incompatible, and a combination of the GBA Push for OMA Device Management with the standard document is not feasible, as it would result in the wrong device management protocol (i.e. one that is not suitable for M2M devices, particularly simple M2M devices), and some very laborious effort to make the two compatible and delete the elements which are redundant.
- the OMA has defined a lightweight protocol for managing (as well as interacting with) M2M devices and managing services provided by M2M devices (e.g. remote control of attached sensors or machines). This protocol is called LWM2M, which is described in detail at http://technical.openmobilealliance.org/Technical/release_program/lightweightM2M_v1_0.a spx
- CoAP analogous to http
- DTLS coaps
- http http over TLS
- coaps requires a secure association to be provisioned between a device and a network server (DM Server) while providing no strong means to provision such an association from scratch.
- OMA LWM2M Lightweight Machine to Machine Technical Specification Candidate Version 1.0 - 10 Dec 2013 (OMA-TS-LightweightM2M-V1_0-20131210-C).
- the User Datagram Protocol (UDP) channel security for [COAP] is defined by the Datagram Transport Layer Security (DTLS) [RFC6347], which is the equivalent of TLS v1.2 [RFC5246] for HTTP and utilizes a subset of the Cipher Suites defined in TLS. (Refers to TLS Cipher Suite registry http://www.iana.org/assignments/tls-parameters/tls-parameters.xml)
- the DTLS binding for CoAP is defined in Section 9 of [CoAP].
- DTLS is a long-lived session based security solution for UDP. It provides a secure handshake with session key generation, mutual authentication, data integrity and confidentiality.
- the keying material used to secure the exchange of information within a DTLS session may be obtained using one of the bootstrap modes defined in Section 5.1.2 Bootstrap Modes of OMA LWM2M.
- the formats of the keying material carried in the LWM2M Security Object Instances are defined in Appendix E.1.1.
- HTTP Digest authentication is defined in RFC 3310 (entitled “Hypertext Transfer protocol (HTTP) Digest Authentication using Authentication and Key Agreement (AKA)", it can currently be retrieved at http://www.ietf.org/rfc/rfc3310.txt).
- the GAA cluster of specifications TS 33.222 (entitled “Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS) ”) defines a general approach for pre-shared key TLS (TLS-PSK, RFC 4279). This can currently be retrieved at http://www.3gpp.org/ftp/Specs/html-info/33222.htm). For example, see especially Section 5.4.
- 3GPP Specification TS 33.220 defines the components and interfaces that are shown in figure 1 . These are further described as:
- HLR/HSS 140 the "Home Location Register” or “Home Subscriber System” is the existing 3GPP system which stores subscription details and credentials (the K and IMSI) for each SIM card (UICC) issued by a mobile operator. It may be "GBA-aware” (so that it stores details for a GBA user subscription) or may be a legacy component.
- the "User Equipment” 110 is a mobile device containing a SIM card (UICC).
- the UE 110 supports a client application which communicates with the NAF 122, as well as a service which interfaces to the UICC, communicates with the BSF 130, and derives the shared secret before passing it to the client application.
- This service is (somewhat confusingly) called a "GAA Server” in TR 33.905 (entitled “Recommendations for Trusted Open Platforms", it can currently be retrieved at http://www.3gpp.org/ftp/specs/htmlinfo/33905.htm ).
- Ua 150 is the interface between the Mobile Device (UE) 110 and the Network Application Function (NAF) 120.
- NAF Network Application Function
- Ub 160 is the interface between the Mobile Device (UE) 110 and the Bootstrapping Server Function (BSF) 130. This is specified in detail in TS 24.109 (entitled “Bootstrapping interface (Ub) 160 and network application function interface (Ua) 150; Protocol details", it can currently be retrieved at http://www.3gpp.org/ftp/Specs/html-info/24109.htm ).
- Zh/Zh' 180 is the interface between the BSF 130 and the HSS or HLR 140.
- the Zh 180 interface is used with an HSS 140 that is "GBA Aware".
- the Zh' 180 interface is used with a legacy HLR or HSS 140.
- the Zh and Zh' 180 interfaces are specified in detail in TS 29.109 (entitled “Generic Authentication Architecture (GAA); Zh and Zn Interfaces based on Diameter protocol; Stage 3", it can currently be retrieved at http://www.3gpp.org/ftp/Specs/html-info/29109.htm ) and TS 29.229 (entitled “Cx and Dx interfaces based on the Diameter protocol; protocol details", it can currently be retrieved at http://www.3gpp.org/ftp/Specs/html-info/29229.htm ).
- Zn 170 is the interface between the NAF 122 and the BSF 130: this can use either a Web Services protocol (SOAP over http) or the Diameter protocol (RFC 3588). This is specified in detail in TS 29.109 (see above).
- SOAP over http Web Services protocol
- RRC 3588 Diameter protocol
- GBA-ME GBA-ME
- GBA-U GBA-U
- GBA-SIM GBA-SIM
- the version called "GBA-ME” may require no special customizations of the UICC, except that the UICC does contain a 3G SIM (a USIM).
- other versions may be used.
- the present disclosure provides a method as described in claim 1.
- Administering the interface may include establishing, or registering, secure communication over the interface, or maintaining the interface for secure communication (for example, updating an existing registration), or any other action that may be required to manage the interface itself.
- the security information may comprise any data using which communication via the interface may be secure. For example, it may be any data that enables the interface to be made a secure interface.
- the security information may comprise at least one of a secret or private key (for example, a Ks_NAF, or a key derived from the Ks_NAF) and/or a key identifier (for example, a B-TID/P-TID).
- the security information may comprise a public key, such as a raw public key, RPK, and/or a certificate etc.
- the secure interface lifetime parameter may be set to a time period for which the registration of the M2M device with the NAF should remain valid. In this way, the secure interface lifetime parameter sets a time limit for the lifetime of the registered secure interface between the M2M device and the NAF.
- the secure interface lifetime parameter may be the "Lifetime" parameter of a Register or Update operation, for example.
- the lifetime of the security information may, for example, be a lifetime of the shared secret (for example, Ks_NAF) and/or a lifetime of an identifier of the shared secret (for example, B-TID/P-TID), and/or a certificate and/or a public key lifetime etc.
- the secure interface lifetime parameter may be based on the remaining lifetime of the security information at the time of setting the secure interface lifetime parameter, or based on the value to which the lifetime of the security information was initially set, or based on the lifetime of the security information in some other way.
- the administration data may optionally include any other data that may be required for the administration of the interface.
- it may comprise a name for the M2M device, for example an "Endpoint Client Name", using which the M2M device can be identified, for example by NAF and/or the bootstrapping server function (BSF) and/or security information that can be used in securing the interface, such as a security key, and/or certificate, and/or key identifier, and/or a "Binding Mode" parameter and/or an "SMS Number” parameter etc.
- BSF bootstrapping server function
- the lifetime of the secure interface is linked to the lifetime of the security information.
- the number of unnecessary new bootstrapping runs may be reduced or eliminated, thereby reducing the data overhead of the M2M device and/or a bootstrapping server.
- the M2M device and NAF data overheads may also be reduced as administration data may only be transmitted when there is new administration data (for example, a newly bootstrapped shared secret and/or a new identifier of the shared secret), thereby reducing or eliminating unnecessary data transfers between the M2M device and NAF for updating or refreshing the interface unnecessarily.
- new administration data for example, a newly bootstrapped shared secret and/or a new identifier of the shared secret
- the bootstrapping server may enable the bootstrapping server to exercise some control over the secure interface lifetime parameter (and therefore the allowable registration lifetime of the secure interface).
- the bootstrapping server may therefore influence the value of the secure interface lifetime parameter based on its knowledge of how long particular devices can be expected to keep secrets, how secure particular devices are, what type of secure card the device contains, what threats the device faces etc.
- the bootstrapping server may also be able to exercise load balancing, for example to space out re-bootstrapping requests, update requests etc.
- the secure interface lifetime parameter may be set to a value greater than or equal to the lifetime of the at least part of the security information.
- the secure interface lifetime parameter may be set to a value greater than the lifetime of the security information by a first amount.
- the M2M device may identify that the lifetime of the security information has expired, or is close to expiry, before the existing secure interface expires. It may then attempt a new bootstrapping run before the registered secure interface expires, thereby making it possible to obtain new bootstrapped data and set up a new secure interface, or refresh the existing secure interface, before the existing secure interface expires.
- the secure interface lifetime parameter may be set to a value less than or equal to the lifetime of the at least part of the security information, or less than the lifetime of the security information by a second amount.
- the security information may comprise a key or keys that are themselves used over the secure interface (rather than, as in DTLS, used to negotiate new keys). In this case, it is preferable to avoid using the keys for longer than their lifetime, so it may be preferable to set the secure interface lifetime parameter to a value that is less than or equal to the lifetime of the at least part of the security information.
- the method may further comprise the steps of checking the remaining lifetime of the at least part of the security information; and if the remaining lifetime of the at least part of the security information is less than a security information lifetime threshold, requesting new security information from a bootstrapping server.
- the security information lifetime threshold may be 18 hours. Because the secure interface lifetime parameter is set based on the security information lifetime, the secure interface lifetime parameter may be set such that when there are only 18 hours remaining on the security information lifetime, the secure interface is still valid (i.e. the secure interface lifetime parameter is still greater than zero, and optionally greater than 18 hours if the secure interface lifetime parameter has been set to be greater than the security information lifetime parameter). If the remaining lifetime of the security information is less than 18 hours, the M2M device may attempt to obtain new security information from the bootstrapping server, such that new security information can be obtained from the bootstrapping server before the secure interface between the M2M device and NAF expires.
- the method may further comprise a step of: if the request for new security information fails (for example, because the bootstrapping server cannot be reached at that moment),, repeating the request for new security information after a period of time.
- the period of time may be set in consideration of the security interface lifetime parameter, the security information lifetime and/or the security information lifetime threshold such that multiple attempts may be made to obtain new security information before the secure interface registration between the NAF and M2M device expires.
- the step of checking the remaining lifetime of the security information may be carried out before a secure communication transmission from the M2M device to the NAF via the interface.
- the M2M device may identify that new security information should be obtained (for example, because the existing security information has expired or is close to expiry) before attempting to communicate with the NAF via the secure interface. This can improve efficiency as the M2M device can proactively obtain new security information, rather than simply attempting to connect with the NAF via an expired secure interface and then only obtain new security information after receiving an error message from the NAF.
- the administration data may further comprise a name for the M2M device, wherein the name for the M2M device is equal to, or derived at least in part from, or otherwise linked to (for example, a linkage via database look-ups, such as at a BSF, or a NAF, or in a database accessed by either of them) at least part of data that are shared between the M2M device and a bootstrapping server (for example, a BSF).
- a bootstrapping server for example, a BSF
- the data that are shared between the M2M device and bootstrapping server can be any data that is known to both entities.
- it may comprise at least one of an identifier of a shared secret (for example, a B-TID or P-TID), a shared secret (for example, a Ks_NAF), data that may be used for the derivation of a shared secret (for example, at least one of a "nonce", "RAND”, “AUTN”, "CK
- a shared secret for example, a B-TID or P-TID
- a shared secret for example, a Ks_NAF
- data that may be used for the derivation of a shared secret for example, at least one of a "nonce", "RAND”, “AUTN”, "CK
- an identifier of the M2M device for example an IMPI, TM
- the name for the M2M device may be equal to at least part of the data that are shared between the M2M device and bootstrapping server. For example, it may be the same as the identifier of the shared secret (B-TID/P-TID), or the same as a part of the identifier of the shared secret, or the same as an identifier of the M2M device (such as the TMPI), or the same as a part of an identifier of the M2M device, etc.
- the name for the M2M device may be derived, at least in part, from at least part of the data that are shared between the M2M device and the bootstrapping server.
- it may be a transformation of at least part of the data that are shared between the M2M device and the bootstrapping server (for example, a hash, or any other form of modification, of at least part of one or more of the items of data shared between the M2M device and the bootstrapping server), or a concatenation of at least part of two or more of the items of data shared between the M2M device and the bootstrapping server, etc.
- TMPI which anonymises the TMSI
- B-TID/P-TID which are randomly generated to disguise the shared secret
- the underlying private identifiers are not revealed in the name for the M2M device. It will be readily apparent that this is also true for when the name for the M2M device is derived, at least in part, from at least part of the data that are shared between the M2M device and the bootstrapping server.
- the privacy of the M2M device and/or any people or entities that are associated with the M2M device may be maintained.
- the method may further comprise the M2M device itself deriving the name for the M2M device at least in part from at least part of the data that are shared between the M2M device and the bootstrapping server.
- the bootstrapping server may derive the name for the M2M device at least in part from at least part of the data that are shared between the M2M device and the bootstrapping server (or set the name for the M2M device to be equal to at least part of the data that are shared between the M2M device and the bootstrapping server) and transmit the name for the M2M device to the M2M device (for example, in response to a request from the M2M device and/or as part of a bootstrapping process).
- the bootstrapping server and the M2M device may both set, or derive, the name for the M2M device, such that they both have the name for the M2M device without it having to be transmitted between each of them.
- the name for the M2M device is linked to at least a part of the data that are shared between the M2M device and a bootstrapping server and the administration data further comprises a data element equal to or derived from the at least part of the data that are shared between the M2M device and a bootstrapping server to which the name for the M2M device is linked.
- the name for the M2M device may be linked to an identifier (such as B-TID or P-TID) of the shared secret and/or to an identifier of the M2M device (for example, a "UE-Id", such as the MSISN, or IMSI, or IMPI, or IMPU etc).
- the name for the M2M device may have been set to equal, or been derived at least in part from, at least part of one of the items of data shared between the M2M device and the bootstrapping server, and be linked to a different item of data shared between the M2M device and the bootstrapping server.
- the name for the M2M device may be derived, at least in part, from at least part of the shared data, and the derived name for the M2M device may be linked to at least the part of the shared data that was used to derive the name for the M2M device.
- the name of the device may be linked to some secret data, such as a Ks (for example, using a database at the BSF). It is preferable not to pass the Ks itself as part of the administration data, thus the administration data may comprise a data element derived from the Ks, for example a part of or a hash of Ks.
- the administration data could contain part of or something derived from Ks_NAF (which has been derived from Ks).
- the name for the M2M device may be linked to at least a part of the data that are shared between the M2M device and the bootstrapping server by, for example, storing at the bootstrapping server and/or the NAF and/or at a location accessible by the bootstrapping server and/or the NAF, the name for the M2M device and the at least part of the data shared between the M2M device and the bootstrapping server (or a data element derived therefrom), to which the name for the M2M device is linked, with an association/linkage recorded between the two (for example, using a database linkage etc).
- the data that are shared between the M2M device and the bootstrapping sever may comprise security information for enabling secure communication via the interface.
- the security information may comprise at least one of a secret or private key (for example, a Ks or Ks_NAF, or a key derived from the Ks_NAF) and/or a key identifier (for example, a B-TID/P-TID). Additionally, or alternatively, the security information may comprise a public key, such as an RPK, and/or a certificate etc.
- a secret or private key for example, a Ks or Ks_NAF, or a key derived from the Ks_NAF
- a key identifier for example, a B-TID/P-TID
- the security information may comprise a public key, such as an RPK, and/or a certificate etc.
- the interface between the M2M device and the NAF may be a device management interface.
- the interface between the M2M device and the NAF may be a Lightweight M2M, LWM2M, interface.
- the administration data may be transmitted to the NAF as at least part of a Register operation or as at least part of an Update operation.
- the interface between the M2M device may alternatively utilise the CoAP protocol and/or the LWM2M protocol or any other suitable protocol.
- the method may be based on a Generic Authentication Architecture, GAA, in particular on a Generic Bootstrapping Architecture (GBA).
- GAA Generic Authentication Architecture
- GBA Generic Bootstrapping Architecture
- the present disclosure also provides an M2M device (for example, a User Equipment device, UE) comprising logic configured to perform the above disclosed method.
- M2M device for example, a User Equipment device, UE
- UE User Equipment device
- the present disclosure also provides a method for a network application function, NAF, to administer an interface between the NAF and a machine-to-machine, M2M, device, (for example, a User Equipment device, UE) wherein the M2M device comprises security information for enabling secure communication via the interface, the method comprising the steps of: receiving administration data from the M2M device, the registration data comprising a secure interface lifetime parameter that has been set based on a lifetime of at least part of the security information; and transmitting an administration response to the M2M device.
- NAF network application function
- the administration response may indicate that the administration data from the M2M device has been successful (for example, successful in setting up a new registered secure interface, or in updating an existing secure interface), or it may indicate that the administration data has failed (for example, a new registered secure interface has not been successfully established, or an existing secure interface has not been successfully updated).
- the secure interface lifetime parameter is set based on a lifetime of the security information
- the lifetime of the secure interface is linked to the lifetime of the security information.
- the M2M device and NAF data overheads may also be reduced as administration data may only be transmitted when there is new administration data (for example, a newly bootstrapped shared secret and/or a new identifier of the shared secret), thereby reducing or eliminating unnecessary data transfers between the M2M device and NAF for updating or refreshing the interface unnecessarily.
- new administration data for example, a newly bootstrapped shared secret and/or a new identifier of the shared secret
- the bootstrapping server may enable the bootstrapping server to exercise some control over the secure interface lifetime parameter (and therefore the allowable registration lifetime of the secure interface).
- the bootstrapping server may therefore influence the value of the secure interface lifetime parameter based on its knowledge of how long particular devices can be expected to keep secrets, how secure particular devices are, what type of secure card the device contains, what threats the device faces etc.
- the bootstrapping server may also be able to exercise load balancing, for example to space out re-bootstrapping requests, update requests etc.
- the method may further comprise checking the lifetime of the at least part of the security information; and comparing the secure interface lifetime parameter with the lifetime of the at least part of the security information; wherein if the comparison does not meet a comparison condition, the registration response is set to indicate an error in the registration data.
- the comparison condition may be that the secure interface lifetime parameter is greater than or equal to the lifetime of the at least part of the security information, or it may be that the secure interface lifetime parameter is greater than the lifetime associated with the at least part of the security information, or it may be that the secure interface lifetime parameter is greater than the lifetime associated with the at least part of the security information by a first amount.
- the comparison condition may be that the secure interface lifetime parameter is less than or equal to the lifetime of the at least part of the security information, or it may be that the secure interface lifetime parameter is less than the lifetime associated with the at least part of the security information, or it may be that the secure interface lifetime parameter is less than the lifetime associated with the at least part of the security information by a second amount.
- the security information may comprise a key or keys that are themselves used over the secure interface (rather than, as in DTLS, used to negotiate new keys). In this case, it is preferable to avoid using the keys for longer than their lifetime, so it may be preferable to set the secure interface lifetime parameter to a value that is less than or equal to the lifetime of the at least part of the security information.
- the NAF can check that the secure interface lifetime parameter compares in an expected way with the lifetime of the security information (which may be the remaining lifetime of the security information, or the value to which the lifetime of the security information was initially set). If they do not compare in an expected way, this may indicate a fault in the administration process (for example, because the M2M device has made a mistake, or it is acting in a malicious manner etc), and the NAF may terminate the administration process (for example, a registration or update process) and return an error message to the M2M device.
- the lifetime of the security information which may be the remaining lifetime of the security information, or the value to which the lifetime of the security information was initially set. If they do not compare in an expected way, this may indicate a fault in the administration process (for example, because the M2M device has made a mistake, or it is acting in a malicious manner etc), and the NAF may terminate the administration process (for example, a registration or update process) and return an error message to the M2M device.
- the method may further comprise the NAF obtaining the lifetime of the at least part of the security information.
- the lifetime of the at least part of the security information may be obtained from a bootstrapping server by transmitting the at least part of the security information (or an identifier for the at least part of the security information, for example the B-TID) and requesting that the remaining lifetime be returned.
- the NAF may obtain the remaining lifetime from its own records (for example, the NAF SA, or from other records that it stores on the NAF or in a location accessible to the NAF). Alternatively, it may obtain the remaining lifetime from any other suitable source.
- the administration data may further comprise a name for the M2M device, wherein the name for the M2M device is equal to, or derived at least in part from, or otherwise linked to, at least part of data that are shared between the M2M device and the bootstrapping server (for example, a BSF).
- the bootstrapping server for example, a BSF
- the name of the M2M device is equal to, or derived at least in part from, or otherwise linked to, at least part of data that are shared between the M2M device and the bootstrapping server
- underlying private identifiers of the M2M device may be disguised. For example, if the name of the M2M device is set to at least part of the TMPI (which anonymises the TMSI), or to at least part of the B-TID/P-TID (which are randomly generated to disguise the shared secret), the underlying private identifiers (the TMPI and/or shared secret) are not revealed in the name for the M2M device.
- the privacy of the M2M device and/or any people or entities that are associated with the M2M device may be maintained.
- the administration data may comprise a data element equal to or derived from at least a part of the data that are shared between the M2M device and the bootstrapping server and the method may further comprise a step of: checking that the name for the M2M device and the received data element are linked to each other, via at least part of the data that are shared between the M2M device and the bootstrapping server, wherein if the name for the M2M device and the received data element are not linked to each other, the administration response is set to indicate an error in the administration data.
- the name for the M2M device may be linked to an identifier (such as B-TID or P-TID) of the shared secret and/or to an identifier of the M2M device (for example a "UE-Id", such as the MSISN, or IMSI, or IMPI, or IMPU etc).
- the name for the M2M device may have been set to equal, or been derived at least in part from, at least part of one of the items of data shared between the M2M device and the bootstrapping server, and be linked to a different item of data shared between the M2M device and the bootstrapping server.
- the name for the M2M device may be derived, at least in part, from at least part of the shared data, and the derived name for the M2M device may be linked to at least the part of the shared data that was used to derive the name for the M2M device.
- the name for the M2M device may be linked to at least a part of the data that are shared between the M2M device and the bootstrapping server by, for example, storing at the bootstrapping server and/or the NAF and/or at a location accessible by the bootstrapping server and/or the NAF, the name for the M2M device and the at least part of the data shared between the M2M device and the bootstrapping server, to which the name for the M2M device is linked, with an association/linkage recorded between the two (for example, using a database linkage etc).
- the NAF may check the linkage of the name for the M2M device to the received data element (expected to be equal to or derived from at least part of the data that are shared between the M2M device and the bootstrapping server) in a variety of ways.
- the NAF may pass the two items to the bootstrapping server, which may check its records (stored either on the bootstrapping server, or at a location accessible to the bootstrapping server) to determine whether or not a linkage between the two has been stored. It may then return a result to the NAF indicating whether or not the two items have been linked to each other.
- the NAF may pass one of the name for the M2M device or the received data element (expected to be equal to or derived from at least part of the shared data to the bootstrapping server).
- the bootstrapping server may check its records and return to the NAF the item that is linked in its records to the data that the NAF passed to the bootstrapping server (i.e. the name for the M2M device or data element equal to or derived from the at least part of the shared data to which the name is linked).
- the NAF may then determine for itself whether the item returned to it by the bootstrapping server matches the data it received from the M2M device in the administration data.
- the bootstrapping server may return linked data from which the name for the M2M device can be derived.
- the NAF may then derive a name for the M2M device from the data and check that it matches the name for the M2M device that it received in the administration data.
- the NAF may perform an analogous process to that identified above, but rather than transmitting and receiving data from the bootstrapping server, it may instead interrogate its own records (kept on the NAF and/or at a location accessible to the NAF) to determine if the name for the M2M device and the data element are correctly linked.
- the NAF can verify that the data received in the administration data is correct, and proceed with registering or updating the secure interface. If it is determined that the items are not linked, the NAF will cease to register or update the secure interface and may transmit a failure message to the M2M device.
- the data that are shared between the M2M device and the bootstrapping server may comprise security information for enabling secure communication via the interface.
- the security information may comprise at least one of a secret or private key (for example, a Ks_NAF, or a key derived from the Ks_NAF) and/or a key identifier (for example, a B-TID/P-TID). Additionally, or alternatively, the security information may comprise a public key, such as an RPK, and/or a certificate etc.
- a secret or private key for example, a Ks_NAF, or a key derived from the Ks_NAF
- a key identifier for example, a B-TID/P-TID
- the security information may comprise a public key, such as an RPK, and/or a certificate etc.
- the methods may be based on a Generic Authentication Architecture, GAA, in particular on a Generic Bootstrapping Architecture (GBA).
- GAA Generic Authentication Architecture
- GBA Generic Bootstrapping Architecture
- connection between the M2M device and the NAF may utilise the CoAP protocol and/or the LWM2M protocol or any other suitable protocol.
- the present disclosure also provides a network application function, NAF, comprising logic configured to perform the above disclosed method.
- NAF network application function
- the NAF may be any server or network component that terminates secure communication on an interface between the NAF and the M2M device.
- the NAF may be configured as a proxy to sit between the M2M device and a device management server (DM server) and/or as a proxy to sit between the M2M device and a LWM2M server and/or as a proxy to sit between the M2M device and a LWM2M bootstrapping server and/or as a proxy to sit between the M2M device and a bootstrapping server.
- DM server device management server
- the NAF may additionally, or alternatively, be configured as a router to sit between the M2M device and the DM server and/or as a router to sit between the M2M device and a LWM2M server and/or as a router to sit between the M2M device and a LWM2M bootstrapping server and/or as a router to sit between the M2M device and a bootstrapping server.
- the NAF may pass any suitable traffic on to the DM server/LWM2M server/LWM2M bootstrapping server/bootstrapping server either encrypted or unencrypted such that the functionality of the server/LWM2M server/LWM2M bootstrapping server/bootstrapping server need not be modified in any way and the server/LWM2M server/LWM2M bootstrapping server/bootstrapping server does not need to be 'GBA aware'.
- the present disclosure also provides a device management server (DM server) comprising the NAF of the present disclosure.
- the NAF may be a plug-in component in the DM server, or the NAF may be the DM server itself (i.e. the NAF is identical to the DM server).
- the present disclosure also provides a LWM2M server comprising the NAF of the present disclosure.
- the NAF may be a plug-in component in the LWM2M server, or the NAF may be the LWM2M server itself (i.e. the NAF is identical to the LWM2M server).
- the present disclosure also provides a LWM2M bootstrapping server comprising the NAF of the present disclosure.
- the NAF may be a plug-in component in the LWM2M bootstrapping server, or the NAF may be the LWM2M bootstrapping server itself (i.e. the NAF is identical to the LWM2M bootstrapping server).
- the present disclosure also provides a bootstrapping server comprising the NAF of the present disclosure.
- the NAF may be a plug-in component in the bootstrapping server, or the NAF may be the bootstrapping server itself (i.e. the NAF is identical to the bootstrapping server).
- the present disclosure also provides a system comprising the above disclosed M2M device and NAF.
- the methods described above may be implemented as a computer program comprising program instructions to operate a computer.
- the computer program may be stored on a computer-readable medium.
- the computer system may include a processor such as a central processing unit (CPU).
- the processor may execute logic in the form of a software program.
- the computer system may include a memory including volatile and non-volatile storage medium.
- a computer-readable medium may be included to store the logic or program instructions.
- the different parts of the system may be connected using a network (e.g. wireless networks and wired networks).
- the computer system may include one or more interfaces.
- the computer system may contain a suitable operation system such as UNIX, Windows (RTM) or Linux, for example.
- a device may communicate securely with a server.
- the device may be a Machine to Machine (M2M) device, or an equivalent device (e.g. a device, a generic or specific communication device, including one or more modules capable of providing M2M capabilities).
- M2M Machine to Machine
- an equivalent device e.g. a device, a generic or specific communication device, including one or more modules capable of providing M2M capabilities.
- GBA Generic Authentication Architecture
- GBA Generic Bootstrapping Architecture
- GBA Generic Bootstrapping Architecture
- a network e.g. a mobile network
- a card e.g. a SIM card or UICC
- the method can advantageously use the GBA to derive the security elements (e.g. a shared secret) to enable the client associated with the device to securely communicate with the server.
- the device could be advantageously adapted so that it is associated with the card and the client and uses GBA to derive the security elements for secure communication with the server.
- GBA is standards-based, the impact of the required modifications may be relatively limited and the overall solution would be very attractive (in particular, to M2M users/owners as well as to network operators and/or service providers).
- M2M devices are different from the mobile devices that OMA Device Management was originally designed for (such as mobile phones, laptops, computers, as explained in "Details of 3GPP standards and technologies used to implement aspects of the method and system” above), and use of GBA (in any of its versions) with M2M is not a straightforward implementation.
- GBA Push A variant of GBA, called "GBA Push” has been proposed for securing a message between a client and a DM server in the context of OMA Device Management Security, and is identified in "Details of 3GPP standards and technologies used to implement aspects of the method and system" above. It is noted that, although GBA Push and GBA are related, it is not trivial to use GBA in place of GBA Push (and vice versa). This is because these two architectures have some important differences. First, in GBA the device has to contact the BSF in order to request a RAND and AUTN (and use this to derive a Ks_local). To the contrary, in GBA Push, the client does not have to talk to the BSF - it just receives a message prepared by the BSF.
- GBA Push there is no need to modify the Ua interface.
- either the Ua interface has to be modified in some way to carry the push message or a new interface must be added. Accordingly, GBA Push cannot be used with an arbitrary application protocol.
- the application protocol has to be "GBA aware" in some sense (e.g. so it can carry the GBA Push Info (GPI) messages).
- GBA Push the Ks_local can be used to derive several different Ks_NAFs (e.g. for different application servers).
- GBA Push only one NAF can use/rely on the Ks_local. Accordingly, GBA Push is slightly less efficient than GBA.
- the GBA Push Info is described in 3GPP TS 33.223, Section 5.2.1.
- the encoding is defined in Section 5.3.5. See in particular table 5.2.1.1 and figure 5.3.5.1 in 3GPP TS 33.223 V12.0.0 (2013-12) that may be found: http://www.3gpp.org/ftp/Specs/archive/33_series/33.223/33223-c00.zip
- M2M devices are very constrained in their capabilities (e.g. computation, communication, life, etc.) and these constraints make their management more complex and harder to implement in a simple manner.
- GBA requires a number of interfaces and components which are hard to implement with M2M (for examples and description of these interfaces and components, please refer to the sections below).
- these interfaces and components need to be modified or otherwise adapted so they can properly and effectively work with M2M devices.
- the standard Ub interface uses HTTP and HTTP digest.
- GBA was designed having mobile devices, such as mobile phones, in mind. So, since all phones use HTTP, and therefore all have an HTTP stack, then HTTP was the easiest protocol to be used for the Ub interface.
- M2M devices For example, according to the Lightweight M2M (LWM2M) protocol (see below for more details), a protocol called CoAP is used in M2M devices, precisely because it is a simpler/more efficient alternative to HTTP.
- this Ub interface could be tunnelled, for example via another interface (e.g. the Ua), so that the system may be simplified.
- GBA is not widely used.
- use of GBA requires support in the device, in the network (e.g. BSF - see below) and by individual services (which may be deployed, for example, by a mobile operator or by other parties).
- mobile broadcast support is also required in the SIM card (as it uses GBA-U).
- a lack of coordination and willingness to act/cooperate between the various parties involved in this deployment e.g. device manufacturers, mobile operators, service providers
- GBA (or a GBA-like architecture, for example a variant and/or a suitably modified version) may be used for enabling a secure communication with a device (in particular, an M2M device).
- the communication may be between a server and a client, the client being associated with the device, and wherein this communication may be done for managing the device and/or services provided by (or via) the device.
- This enables a secure management of that device and/or the services provided by (or via) the device and creates a new and innovative combination which produces a synergistic effect and provides many technical advantages.
- the GBA will provide a higher and very strong level of security to the device/service management-related communications with M2M devices, which is a very critical and important point.
- an M2M service provider does not have the cost/complexity of setting up their own security solutions, as the solution can be provided directly by the mobile operator implementing the solution described in this application.
- a service provider does not have to set up a PKI, issue certificates, pre-load keys to devices and so on.
- the method may further comprise that the provision of the secure communication is based on a security association between a network and a card, the card being associated with the device.
- the card may be embedded within the device (e.g. soldered in the device) or provided to the device by way of a suitable connection.
- the card may be associated in any suitable manner so that there is an association between the card and the device.
- the network can be a mobile network, or any equivalent network, while the card can be a SIM card, a UICC, or any card associated with the network.
- the method may further comprise deriving a shared secret based on the security association.
- the method may further comprise providing the client and the server with the shared secret so as to enable the secure communication.
- the server may be a server adapted to manage the device (e.g. remotely manage the device, send updates, transfer information to and from the device, control device parameters, etc.) and to manage services provided by the device (e.g. device is used to switch on/off and/or dim streetlights).
- the shared secret may be a key and/or a similar security arrangement.
- the method may further comprise authentication between the client and the server.
- the authentication may be based on the shared secret.
- the authentication may be performed via an authentication component.
- the authentication may be performed by means of a first authentication between the client and an authentication component and of a second authentication between the server and the authentication component.
- the client and the server may be independently authenticated by an authentication component.
- both the client and the server may share the shared secret.
- the authentication may be performed by means of the shared secret.
- the shared secret may be shared between the client and the server.
- the shared secret may be shared between the client, the server and the authentication component.
- the authentication may implicitly result from the client, the server and the authentication component sharing the shared secret.
- the method may further comprise deriving a second shared secret based on the shared secret, the second shared secret being shared between the client and the server. This second shared secret may then be used for the authentication as discussed above.
- the obtainment of the shared secret at the client may be based on an identifier associated with a server authentication component.
- the shared secret may be obtained at the server from the authentication component.
- the obtainment of the shared secret at the server is obtained based on an identifier associated with the shared secret.
- the identifier is generated by the authentication component.
- the identifier may be provided to the server by the client.
- the OMA LWM2M protocol for managing (as well as interacting with) M2M devices and managing services provided by M2M devices may be used. However, other device management protocols may be used or the method and system may be extended to other M2M services (for example, securing the delivery of binary SMS).
- GBA could be advantageously used in conjunction with LWM2M in order, for example, to establish keys for LWM2M, whilst at the same time LWM2M and the procedures specified therein could be used to transport and/or carry any message and/or communication which relates to GBA. For example, this can be done by using specific tunnels (e.g. Ub) or GBA Push Info (GPI) messages.
- GBA GBA Push Info
- the use of GBA together with LWM2M creates a new and innovative combination which produces a synergistic effect and provides many technical advantages. For example, it allows addressing many more low-end devices, such as M2M devices.
- GBA and LWM2M advantageously combine to eliminate the cost of pre-loading settings and credentials, so facilitating low cost devices.
- GBA with LWM2M securely supports low-cost devices which are unattended or have no UI, where there is no option for user interaction (such as entry of PIN), and where there is no user who is able to notice and recover from authentication failures (spoof server, spoof client or Man In The Middle), Moreover, GBA works without requiring any public key or certificate processing on the device. This is particularly advantageous on simpler devices, as these devices may have minimal public key support or implementation errors when handling certificates.
- the shared secret may be used as a key in the LWM2M standard.
- the LWM2M standard procedures may be used for transmission and/or reception of any communication used within the GBA.
- the shared secret may be used as a key or shared secret within the DTLS protocol (identified in "Details of 3GPP standards and technologies used to implement aspects of the method and system" above), either when the LWM2M is used in conjunction with a DTLS protocol or when the DTLS is used alone or in conjunction with one or more other protocols.
- the secure communication may further be a data communication.
- the data communication may be an SMS-based communication.
- An SMS binding may be used.
- the data communication may be a UDP-based communication.
- the method may further comprise encrypting a communication over the secure data communication.
- the encryption may be performed using an Advanced Encryption Standard.
- the SMS-based communication may be further secured by use of an Over-The-Air (OTA) protocol, e.g. a Secured Packet Structure for UICC Applications. This protocol is defined in ETSI standard 102.225.
- OTA protocol may be arranged to secure the communication with the identification card associated with the device.
- the OTA protocol can be used advantageously in conjunction with the LWM2M standard, in which the LWM2M can be used to manage parameters, keys and similar elements for the OTA protocol.
- OTA is a solution designed for SIM card security, as it has some real technical challenges if used for LWM2M.
- software written for SIM cards and SIM OTA servers to support ETSI standard 102.225 a similar software does not exist in the device management space for devices (and, in particular, not for OMA DM clients and servers).
- M2M device manufacturers do not have a code-base that they can easily adapt for use with these devices.
- the ETSI standard 102.225 does not explain how to set up the keys and parameters for use with the standard. It simply assumes the keys and parameters are all pre-loaded and known to both SIM card and OTA server. Although this assumption is acceptable in the SIM space - because SIM cards can be securely provisioned with the necessary keys at the manufacturing stage, and SIM manufacturers have interfaces with operators for communicating the necessary keys and parameters - the same cannot be said about LWM2M, where that infrastructure does not exist.
- the LWM2M standard procedures may be used to manage parameters and/or keys used in the OTA protocol.
- the method may further be used in conjunction with LWM2M, as described above.
- GBA can be used in conjunction with SMS so that the GBA can be employed to establish keys for secure SMS-based communications (e.g. SMS), while at the same time SMS-based communications can be used to transport or carry messages associated with GBA - for example, carry GBA Push Info (GPI) messages.
- SMS-based communications together with GBA creates a new and innovative combination which produces a synergistic effect and provides many technical advantages.
- GBA can be used to establish the shared keys that are needed to protect SMS, while using SMS as a transport to deliver the necessary GBA messages.
- SMS used to deliver the GBA messages can themselves be integrity protected (and partly encrypted) using the keys that will be established by GBA, so at no point is there a reliance on not secure SMS.
- This synergistic combination allow use of SMS as the sole bearer for M2M traffic, something which would not otherwise be possible, except by preloading the keys needed to secure SMS traffic, or switching to a different protocol to negotiate these keys: both of these alternatives would add complexity and cost.
- the GBA may be used to establish keys for secure transmission and/or delivery of SMS.
- SMS-based communications may be used for transmission and/or reception of any communication used within the GBA, noting that these communications may themselves be protected using the keys that will be derived in GBA.
- the server may further comprise a server authentication component.
- the client may further comprise a client authentication component.
- the server authentication component may perform authentication of the server with the authentication component.
- the client authentication component may perform authentication of the client with the authentication component.
- the authentication component may be a Bootstrapping Server Function (BSF)
- the server authentication component may be a Network Application Function (NAF)
- the client authentication component may be a GAA Server.
- BSF Bootstrapping Server Function
- NAF Network Application Function
- the method may further comprise communicating between the server and the client for determining security parameters to be used for the secure communication, wherein the communicating is performed by using a device management protocol (for example, the GBA).
- the secure communication may be for use in the device management protocol.
- a method of enabling secure communication for use in a device and/or service/application management protocol the secure communication being between a server and a client, the client being associated with a device, the secure communication requiring security parameters to be agreed between the client and server, the method comprising communicating between the server and client to agree the security parameters, wherein the communicating is performed by using the device management protocol.
- the device can be an M2M device.
- an apparatus, system, module or network for enabling secure communication with a device, said communication being between a server and a client, the client being associated with the device.
- the apparatus, system, module or network may further include means for performing any one of the steps or features of the methods described above.
- the device can be an M2M device.
- an apparatus, system, module or network for enabling secure communication for use in a device and/or service/application management protocol, the secure communication being between a server and a client, the client being associated with a device, the secure communication requiring security parameters to be agreed between the client and server, the method comprising communicating between the server and client to agree the security parameters, wherein the communicating is performed by using the device management protocol.
- the apparatus, system, module or network may further include means for performing any one of the steps or features of the methods described above.
- the device can be an M2M device.
- a client including any means, features or functionalities corresponding to the means, features or functionalities relative to the client as recited by any one of the methods described above.
- a server including any means, features or functionalities corresponding to the means, features or functionalities relative to the server as recited by any one of the methods described above.
- a device comprising a card and a client, wherein the device is arranged for enablement of secure communication, the secure communication being between a server and the client, wherein the provision of the secure communication is based on a security association between a network and the card.
- the client may comprise any means, features or functionalities corresponding to the means, features or functionalities relative to the client as recited by any one of the methods described above.
- the device can be an M2M device.
- a server arranged for enablement of secure communication with a device, the secure communication being between the server and a client associated with the device, wherein the provision of the secure communication is based on a security association between a network and a card, the card being associated with the device.
- the server may comprise any means, features or functionalities corresponding to the means, features or functionalities relative to the server as recited by any one of the methods described above.
- the device can be an M2M device.
- a system for enabling secure communication with a device said communication being between a server and a client, the client being associated with the device, wherein the provision of the secure communication is based on a security association between a network and a card, the card being associated with the device.
- the device can be an M2M device.
- a method of enabling secure data communication with a device the communication being between a server and a client associated with the device, wherein the security of the communication is enabled by a bootstrapped secret.
- the device can be an M2M device.
- the security protocol may be used to secure the data communication.
- the bootstrapped secret may be used to obtain the security elements used for the secure protocol.
- the bootstrapped secret may be a pre-shared secret, said secret being directly provided to the server and the client.
- the pre-shared secret may be permanently provided to the server and the client (e.g. by pre-provisioning the client and/or the server with said pre-shared secret, e.g. at manufacturing stage or before the client and/or server are used in a system).
- the pre-shared secret may be a strong, high entropy or a temporary, low-entropy pre-shared secret.
- the bootstrapped secret may be based on a public key or a certificate-based method.
- the bootstrapped secret may be provided via a bootstrap server.
- the security elements can be keys and/or similar arrangements well known in the art.
- the communication may be an SMS-based communication.
- the security protocol is defined by ETSI TS 102.225.
- the method may use SMS binding.
- the device may be further associated with a card, and the security of the data communication may be controlled by means of the card. Any incoming SMS-based communication may be decrypted and/or checked by means of the card, and/or any outgoing SMS-based communication may be encrypted and/or checked by means of the card.
- the communication may be a UDP-based communication.
- the security protocol may be a DTLS protocol.
- the secure data communication may be provided over a communication interface.
- the communication interface may be used for managing the device of for managing the bootstrapping operations.
- the data communication may be performed according to the LWM2M protocol.
- an apparatus, system, module or network for enabling secure data communication with a device, the communication being between a server and a client associated with the device, wherein the security of the communication is enabled by a bootstrapped secret.
- the device can be an M2M device.
- a method of retrieving security elements required for enabling secure data communication with a device the communication being between a server and a client associated with the device, wherein the security elements are retrieved using a bootstrapping protocol.
- the device can be an M2M device.
- the bootstrapping protocol may retrieve the security elements in a secure session.
- the session may be secured based on a security protocol.
- the security protocol may be a DTLS protocol.
- the bootstrapping protocol may be based on GBA.
- the data communication may be an SMS-based communication.
- the bootstrapping protocol may be a LWM2M bootstrap protocol.
- the security elements can be keys and/or similar arrangements well known in the art.
- an apparatus, system, module or network for enabling secure data communication with a device, the communication being between a server and a client associated with the device, wherein the security elements are retrieved using a bootstrapping protocol.
- the device can be an M2M device.
- the secure communication may be for the purpose of managing the device and/or the client and/or services (e.g. provided by the device) by the server.
- Both the device and the server may be machines (i.e. not requiring any human intervention to work).
- the server may be used to manage it. Again, the management may be done without any human intervention (e.g. automatically).
- the solution could be used in conjunction with the LWM2M protocol, but the solution could be extended to other Device Management protocols, or to other M2M services (e.g. securing delivery of binary SMS).
- M2M-specific protocol such as LWM2M
- the use of the solution in conjunction with an M2M-specific protocol, such as LWM2M allows the solution to be very efficient when used with M2M devices, and in particular, when used to manage the device and/or services provided by (or via) the device.
- all the advantages mentioned above are further enhanced and optimised when the solution is used in conjunction with an M2M-specific protocol.
- a device 110 in the example, an M2M Device and/or a User Equipment
- a card 112 in the example, a UICC
- a Client 116 in the example, a Device Management (DM) client.
- this client could also be an LWM2M Client, namely a client that can manage the device itself and service/applications provided by the device e.g. asset control).
- the device 110 is also associated with a device authentication component 114 (in the example, a GAA server).
- a server 120 is provided (in the example, a DM server), the server associated with a server authentication component 122 (in the example, a Network Application Function (NAF)).
- a server authentication component 122 in the example, a Network Application Function (NAF)
- NAF Network Application Function
- an authentication component 130 is provided (in the example, a Bootstrapping Server Function (BSF)) and a register 140 (in the example, an HLR or HSS).
- BSF Bootstrapping Server Function
- register 140 in the example, an HLR or HSS.
- four different interfaces are provided for communication between the various components, in particular interface Ua 150 between device 110 and server 120, interface Ub 160 between device 110 and authentication component 130, interface Zn 170 between authentication component 130 and server 120, and interface Zh/Zh' between authentication component 130 and register 140.
- NAF the "Network Application Function”
- DM Device Management
- Some aspects of a BSF, HLR/HSS, UE, Ua, Ub, Zh/Zh' and Zn are provided in "Details of 3GPP standards and technologies used to implement aspects of the method and system" above.
- the BSF 130 derives the shared secret Ks_NAF, which is retrieved by the NAF.
- the BSF 130 would most likely be on a separate server from the HLR/HSS 140, but within an M2M platform cluster.
- the HLR/HSS may be "GBA-aware" (so that it stores details for a GBA user subscription) or may be a legacy component.
- the HLR/HSS would be the HLR or HSS of an M2M mobile operator (i.e. one dedicated specifically to serving M2M connections).
- the UE 110 is, in the proposed solution, an M2M device.
- the Ua is the interface between a Device Management client 116 and Device Management server 120.
- the Ub would be the interface between the "GAA Server" component 114 of the device and the BSF 130.
- the Zn interface is used.
- this interface is between the Device Management Server 120 and the BSF 130.
- the WS version of the interface would allow placement of a DM Server in multiple locations (not just in the M2M operator/platform cluster), and allow future NAFs in multiple locations.
- the UE 110 contacts over interface Ua the NAF 122 (in the described embodiment, the Device Management client 116 contacts the Device Management server 122) and discovers that the NAF requires it to acquire a shared secret using GBA. This could be because there is no existing secret, or the existing secret has expired, or is otherwise considered invalid by the NAF.
- the exact interface and communication method may be specific to the application concerned.
- One possible interface and communication method for OMA Lightweight M2M is discussed below.
- the DM client 116 requests the GAA server 114 to obtain a shared secret. It presents an identifier for the corresponding NAF (NAF_Id).
- the UE 110 contacts the BSF (GAA Server 114 contacts the BSF 130). This may be a basic http GET request.
- the UE presents an "IMPI" (equivalent of an IMSI) or a "TMPI" (equivalent of a TMSI) for anonymity reasons, if one is available.
- the BSF 130 requests an authentication vector from the HLR/HSS 140.
- the HLR/HSS 140 returns a fresh vector, consisting of a RAND, AUTN, XRES, CK, and IK, for example.
- the BSF 130 generates a transaction identifier (B-TID) and passes (230) the B-TID together with the RAND and AUTN back to the UE 110. It may also indicate the lifetime of the B-TID, and the associated key.
- B-TID transaction identifier
- the GAA Server 114 forwards the RAND and AUTN to the UICC 112 which validates the AUTN. If the AUTN is valid, then the BSF 130 is authenticated. At 240, the UICC 112 returns a RES, CK and IK to the GAA Server 114.
- the UE 110 (GAA Server 114) contacts the BSF 130 again, using the resulting RES for HTTP Digest authentication (which is identified in "Details of 3GPP standards and technologies used to implement aspects of the method and system" above).
- the BSF 130 verifies the HTTP Digest using the XRES. If it matches, then the UE 110 has been successfully authenticated.
- the BSF 130 stores the tuple ⁇ IMPI, B-TID, RAND, CK, IK> and tells at 250 the UE 110 that the authentication was successful.
- the UE 110 stores ⁇ B-TID, RAND, CK, IK>.
- the UE 110 Over the internal UE 110 interface from DM client 116 to GAA server 114: the UE 110 (GAA Server 114) derives a secret Ks_NAF using the CK, IK, RAND, IMPI and NAF_Id. At 255, it passes Ks_NAF and the B-TID back to the DM client 116.
- the UE 110(DM Client 116) contacts the NAF (DM Server 122) and presents the B-TID as retrieved above.
- the NAF 122 contacts the BSF 130, and presents the BTID.
- the BSF 130 authenticates the NAF, derives the corresponding Ks_NAF, and at 270 returns it to the NAF, together with an indicator of key lifetime.
- the UE 110 (DM Client 116) and NAF (DM Server 122) now both share Ks_NAF. They can use it directly, or to derive their own session keys for further communication.
- exemplary flow described with reference to Fig. 3 is very generic, and can be used with many different sorts of device management protocols (or other application protocols). As can be seen, many details of the Ua interface are outside the scope of 3GPP and are left to other standards to complete (or left to proprietary implementations). However, integration with the LWM2M standard is possible, as described in these examples.
- OMA LWM2M is based on DTLS v1.2 (see above) and CoAP (see above). Both the client and server must support pre-shared key DTLS (e.g. see section 7.1.1, page 41), whereas support for certificate-based authentication is only optional. This means that a key derived by GBA (Ks_NAF) could be used as a DTLS pre-shared key and it would work with any DM client/DM server pair.
- Ks_NAF key derived by GBA
- the general approach for pre-shared key TLS is referenced in "Details of 3GPP standards and technologies used to implement aspects of the method and system" above.
- the GBA and TLS-PSK protocols work well together.
- the "Server Hello" message contains a field where the server can indicate that it supports GBA-bootstrapping, and in response, the client can then provide an identifier (B-TID) for an already bootstrapped key (260). Or if the client doesn't already have a bootstrapped key, it asks the GAA server to get one, before resuming the "Client Hello" and "Server Hello” at 260.
- the use of the Ks_NAF to derive session keys is then specified entirely within the TLS-PSK protocol.
- the 3GPP spec assumes HTTP /TLS, but the basic approach looks the same for CoAP / DTLS.
- the LWM2M spec may need to define a "protocol identifier" for DTLS pre-shared key and have it registered by OMNA (see section 5.2.1 of OMA GBA Profile, Approved Version 1.1 - 31 Jul 2012 found at htlp://technical.openmobilealliance.org/Technical/release program/sec cf archive.aspx).
- the M2M device may be configured to support the security of OMA LWM2M, which is referenced in "Details of 3GPP standards and technologies used to implement aspects of the method and system" above.
- the M2M device may contain several internal components. It should support a DM client which is "GBA aware", as well as a “GAA Server” component.
- the GAA Server component should support internal interfaces to the DM client and to the SIM card (UICC) as well as the external Ub interface to the BSF.
- the interface to the UICC may be particularly challenging, as the M2M device may not expose an existing API to allow device software to send commands to the UICC.
- One possibility (that may be used) is for the modem to expose AT commands. However, this may not be at a sufficiently low level (AT+CSIM allows raw APDUs to be communicated to the UICC) in every case.
- AT+CSIM allows raw APDUs to be communicated to the UICC
- the interface to the BSF is based on http and HTTP Digest authentication.
- One alternative may be "tunnelling" the Ub interface within the Ua interface, so that the device only needs to support the CoAP protocol (not HTTP as well).
- GBA push A related alternative is using the GBA "Push” variant, and carrying push messages (Upa interface) within the Ua interface. Both of these would require identifying suitable commands and parameters in the Ua interface (i.e. the relevant Device Management protocol) to carry the tunnel or push messages.
- the interfaces and message flow for GBA push are outlined below (see also 3GPP TS 33.223, entitled “3G Security; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Push function", it can currently be retrieved by http://www.3gpp.org/ftp/Specs/html-info/33223.htm ).
- the UE and NAF are now ready to use the established NAF SA.
- TR33.223 specifies that Upa is a new interface that is separate from Ua - "a new reference point Upa is introduced between the NAF and the UE" (Section 4.2.1). As such, the Ua interface should be unaware of whether GBA or GBA-push is being used.
- the address of the BSF may be pre-loaded when the device is manufactured. It could be device managed itself, which would seem to create a "chicken-and-egg" problem, but the DM Server could, for instance, provide an address for an acceptable BSF in the ServerHello. Or http traffic might be routed by the M2M mobile operator to a default BSF address. Similarly, the location of the preferred DM Server might need to be pre-loaded, or the M2M mobile operator could route CoAP traffic to a default DM Server address.
- GBA-U has security advantages, but also logistic advantages: it permits a longer lifetime for the B-TID as the derived key is stored more securely. It allows safe retention of Ks during power-off cycles for instance.
- GBA-U requires specific support from the UICC, so would have a (modest) increment to the cost. Since M2M devices are typically provided with a new UICC anyway at manufacture, it is a software/development cost rather than a hardware cost. Also, in a model with a customised UICC, this may allow for a solution using restricted AT commands to the modem, rather than full AT+CSIM.
- the architecture example allows for there to be several DM Servers in different locations: it could be part of an M2M platform (e.g. M2M mobile operator) cluster, or hosted elsewhere by a network operator/service provider, or perhaps by a customer of said operator/provider.
- the BSF may need to be located within a firewalled Demilitarized Zone (DMZ), or perhaps connected via an http proxy in the DMZ (so allowing external http Web Service access from NAFs), and then would execute the Diameter interface to the HLR/HSS. It may be undesirable to expose an http interface directly onto the server supporting the HLR, or to tunnel Diameter through firewalls. However, if the DM Server is itself part of the M2M platform cluster then this may be over-engineering. Possibly, a Diameter solution for the Zn interface then becomes acceptable.
- DMZ Demilitarized Zone
- the HLR may be upgraded to a full HSS with support for the Zh reference point.
- the BSF will need to be more complicated, and take on some of the subscription management functions (profiling, lifetime, security policies) typically associated with the HSS.
- GBA keys could be used to protect SMS (e.g. encrypt/ integrity protect SMS using a secure packet interface e.g. like ETSI TS 102.225 which is used for SIM OTA). This SMS channel is likely to be more efficient than DTLS.
- a secure SMS protocol could be linked to a Device and/or Service management protocol, namely: using a secure SMS protocol (e.g. originally designed for SIM OTA (102 225)), but now adapted for LWM2M communications, combined with using the LWM2M protocol to define (and manage) the necessary parameters for the secure SMS protocol (i.e. the relevant Klc, KID, SPI, TAR, and keys).
- a secure SMS protocol e.g. originally designed for SIM OTA (102 225)
- LWM2M LWM2M protocol
- GBA could be used to securely derive the keys.
- LWM2M needs a security solution for the SMS bearer. Without a solution, SMS will not be usable as a bearer, severely limiting scope of LWM2M.
- a solution to this problem is to use SIM OTA security (e.g. see TS 102 225).
- TS 102.225 relies on the keys and parameters being already agreed between client and server. However, it is difficult to pre-load these into LWM2M client devices, and ensure that they are sent to servers, because there is no present infrastructure for doing so. It would be pointless to deliver the keys and parameters over unsecured SMS.
- a first solution there is provided switching bearer to UDP/Coap and running DTLS.
- the DTLS session can be used to secure the LWM2M Bootstrap protocol.
- the LWM2M Bootstrap can be used to set the TS 102.225 keys and parameters securely. Note that managed resources/objects need to be defined to allow the Bootstrap server to update them; the format of these resources is specified in the numbered paragraphs below.
- GBA GBA Push Info
- the GPI GBA Push Info
- the delivery of the parameters like Kic, KID, SPI and TAR is not obvious, but these are only 6 bytes, and there are fields in the GPI e.g. App_Lbl, NAF_Id, P-TID which could be used to carry this info.
- the LWM2M Client and LWM2M Server SHOULD keep a DTLS session in use for as long a period as can be safely achieved without risking compromise to the session keys and counters. If a session persists across sleep cycles, encrypted and integrity-protected storage SHOULD be used for the session keys and counters.
- Client-Server relationship of DTLS i.e. who initiated the handshake
- Client-Server relationship of LWM2M is separate from the Client-Server relationship of LWM2M.
- Cipher Suites are not limited to the list defined in Section 9 of [CoAP]. Due to the sensitive nature of Bootstrap Information, particular care has to be taken to ensure protection of that data including constraints and dependencies within a LWM2M Client/ Bootstrap Server relationship according to the adopted security mode.
- the keying material used to secure the exchange of information using a DTLS session may be obtained using one of the bootstrap modes referenced in "Details of 3GPP standards and technologies used to implement aspects of the method and system" above.
- the Resources i.e. "Security Mode”, “Public Key or Identity”, “Server Public Key or Identity” and “Secret Key" in the LWM2M Security Object that are associated with the keying material are used either
- LWM2M Clients MUST either be directly provisioned for use with a target LWM2M Server (Manufacturer Pre-configuration bootstrap mode) or else be provisioned for secure bootstrapping with an LWM2M Bootstrap Server.
- Any LWM2M Client which supports Client or Server initiated bootstrap mode MUST support at least one of the following secure methods:
- a LWM2M Bootstrap Server SHALL support all of these methods.
- the Secured Packet Structure is based on [3GPP TS 31 115]/[ETSI TS 102 225]] which is defining secured packets for different transport mechanisms.
- the solution was originally designed for securing packet structures for UICC based applications, however, for LWM2M it is suitable for securing the SMS payload exchanged between client and server.
- the SMS Secured Packet Structure mode specified in this section MUST be supported when the SMS binding is used.
- a LWM2M Client which uses the SMS binding MUST either be directly provisioned for use with a target LWM2M Server (Manufacturer Pre-configuration bootstrap mode or Smart Card Provisioning) or else be able to bootstrap via the UDP binding.
- the end-point for the SMS channel (delivery of mobile terminated SMS, and sending of mobile originated SMS) SHALL be either on the smartcard or on the device.
- the end-point is on the LWM2M Client device.
- a LWM2M Client, Server or Bootstrap Server supporting SMS binding SHALL discard SMS messages which are not correctly protected using the expected parameters stored in the "SMS Binding Key Parameters" Resource and the expected keys stored in the "SMS Binding Secret Keys” Resource, and SHALL NOT respond with an error message secured using the correct parameters and keys.
- SMS channel end-point is on the device the following settings SHALL be applied:
- SMS channel end-point is on the smart card the following settings SHALL be applied: Class 2 SMS as specified in [3GPP TS 23.038].
- the [3GPP TS 23.040] SMS header MUST be defined as below:
- a SMS Secured Packet encapsulating a CoAP request received by the LWM2M device MUST be - according to [ETSI TS 102 225]/[3GPP TS 31.115] - addressed to the LWM2M UICC Application in the Smartcard where it will be decrypted, aggregated if needed, and checked for integrity.
- the message contained in the SMS MUST be provided to the LWM2M Client.
- SMS MUST be discarded.
- the mechanism for providing the decrypted CoAP Request to the LWM2M Client relies on basic GET_DATA commands of [GP SCP03] . This data MUST follow the format as below
- the LWM2M Client For sending a CoAP message to the LWM2M Server, the LWM2M Client prepares a data containing the right TP-DA to use, concatenated with the CoAP message and MUST provide that data to the LWM2M UICC Application in using the [GP SCP03] STORE-DATA command.
- SMS Secured Packet [ETSI TS 102 225]/[3GPP TS 31.115] the Smartcard will be in charge to prepare (encryption / concatenation) the CoAP message before sending it as a SMS Secure Packet ([ETSI TS 102 223] SEND_SMS command).
- the SMS Secured Packet MUST be formatted as Secured Data specified in section 7.3.1.2.
- the SMS channel security is provided by the Secured Packet Structure [ETSI TS 102 225] and [SCP080] which is defining secured packets for different transport mechanisms.
- the SMS channel security specified in this section MUST be applied when the SMS binding is used.
- the security SHOULD be terminated on the smartcard.
- the LWM2M client SHOULD pass SMS messages to the smartcard for encryption and integrity protection before sending, and SHOULD pass encrypted SMS messages received from the LWM2M server to the smartcard for decryption and integrity checking.
- a LWM2M Client which supports the SMS binding SHALL support the Secured Packet Structure as defined in [ETSI TS 102 225] and [SCP080].
- the LWM2M Client SHALL share the relevant keys - identified by Klc and KID - with a LWM2M Bootstrap Server during bootstrapping, or with a LWM2M Server otherwise.
- a LWM2M Bootstrap Server which supports the SMS binding SHALL support the Secured Packet Structure as defined in [ETSI TS 102 225] and [SCP080].
- a LWM2M Server which supports the SMS binding SHALL support Secured Packet Structure as defined in [ETSI TS 102 225] and [SCP080].
- a CoAP message as defined in [CoAP] MUST be encapsulated in [3GPP 31.115] Secured Packets, in implementing - for SMS Point to Point (SMS_PP) - the general [ETSI 102 225] specification for UICC based applications.
- LWM2M Client and LWM2M Bootstrap Server and LWM2M Server The following applies to LWM2M Client and LWM2M Bootstrap Server and LWM2M Server:
- the ciphering and integrity keys and associated counter values SHOULD be held in a smart card or other tamper-resistant secure storage environment (e.g. embedded secure element).
- the keys and associated counter values are not stored in the above recommended way, they SHALL be treated as session keys with a lifetime no greater than the duration of the Registration Lifetime.
- the LWM2M Client SHALL acquire fresh discard the key material on each "Register” or “Update” operation, load fresh key material using one of the mechanisms described below, and reset the counters.
- the corresponding key values should be stored in the "SMS Binding Secret Keys" Resource.
- a LWM2M Client which uses the SMS binding may either be directly provisioned for use with a target LWM2M Server (Manufacturer Pre-configuration bootstrap mode) or else be able to bootstrap via the UDP binding.
- a LWM2M Client, Server or Bootstrap Server supporting SMS binding SHALL discard SMS messages which are not correctly protected using the expected parameters stored in the "SMS Binding Key Parameters" Resource and the expected keys stored in the "SMS Binding Secret Keys” Resource, and SHALL NOT respond with an error message secured using the correct parameters and keys.
- This LWM2M object provides the keying material of a LWM2M Client appropriate to access a specified LWM2M Server.
- One Object Instance SHOULD address a LWM2M Bootstrap Server
- LWM2M object resources MUST only be changed by a LWM2M Bootstrap Server or SmartCard provisioning and MUST NOT be accessible by any other LWM2M Server.
- LWM2M Server URI String 0 - 255 bytes - Uniquely identifies the LWM2M Server or LWM2M Bootstrap Server, and is in the form: "coaps://host:port", where host is an IP address or FQDN, and port is the UDP port of the Server.
- Bootstrap Server Boolean Determines if the current instance concerns a LWM2M Bootstrap Server (true) or a standard LWM2M Server (false) Security Mode Integer 0-3 - Determines which UDP channel security mode is used 0: Pre-Shared Key mode 1: Raw Public Key mode 2: Certificate mode 3: NoSec mode Public Key or Identity Opaque - Stores the LWM2M Client's Certificate (Certificate mode), public key (RPK mode) or PSK Identity (PSK mode). The format is defined in Section E.1.1.
- SMS Security Mode Integer 0-255 Determines which SMS payload security mode is used (see section 7.2) 0:Reserved for future use 1 :Secure Packet Structure mode device terminated 2: Secure Packet Structure mode smartcard terminated 3: NoSec mode 255: Proprietary modes SMS Binding Key Parameters Opaque 6 bytes - Stores the Klc, KID, SPI and TAR. The format is defined in Section D.1.2. SMS Binding Secret Keys Opaque 32-48 bytes - Stores the values of the keys for the SMS binding. This resource MUST only be changed by a bootstrap server and MUST NOT be readable by any server.
- LWM2M Server SMS Number Integer MSISDN used by the LWM2M Client to send messages to the LWM2M Server via the SMS binding.
- the LWM2M Client SHALL silently ignore any SMS not originated from unknown MSISDN Short Server ID Integer 1-65535 -
- This identifier uniquely identifies each LWM2M Server configured for the LWM2M Client. This resource MUST be set when the Bootstrap Server resource has false value. Default Short Server ID (i.e. 0) MUST NOT be used for identifying the LWM2M Server.
- Client Hold Off Time Integer s Relevant information for a Bootstrap Server only. The number of seconds to wait before initiating a Client Initiated Bootstrap once the LWM2M Client has determined it should initiate this bootstrap mode
- This section defines the format of the Secret Key and Public Key and Identity resources of the LWM2M Server and LWM2M Bootstrap Objects when using UDP Channel security. These resources are used to configure the security mode and keying material that a Client uses with a particular Server. The Objects are configured on the Client using one of the Bootstrap mechanisms described in Section 5.1 of OMA LWM2M. The use of this keying material for each security mode is defined in Section 7.1 of OMA LWM2M.
- PSK Pre-Shared Key
- the PSK is a binary shared secret key between the Client and Server of the appropriate length for the Cipher Suite used [RFC4279]. This key is composed of a sequence of binary bytes in the Secret Key resource.
- the default PSK Cipher Suites defined in this specification use a 128-bit AES key. Thus this key would be represented in 16 bytes in the Secret Key Resource.
- the corresponding PSK Identity for this PSK is stored in the Public Key or Identity resource.
- the PSK Identity is simply stored as a UTF-8 String as per [RFC4279].
- Clients and Servers MUST support a PSK Identity of at least 128 bytes in length as required by [RFC4279].
- the raw-public key mode requires a public key and a private key of the appropriate type and length for the Cipher Suite used. These keys are carried as a sequence of binary bytes with the public key stored in the Public Key or Identity Resource, and the private key stored in the Secret Key Resource.
- the default RPK Cipher Suites defines in this specification use a 256-bit ECC key. Thus the Certificate Resource would contain a 32 byte public key and the Secret Key Resource a 32 byte private key.
- the Certificate mode requires an X.509v3 Certificate along with a matching private key.
- the private key is stored in the Secret Key Resource as in RPK mode.
- the Certificate is simply represented as binary X.509v3 in the value of the Public Key or Identity Resource.
- This section defines the format of the Secret Key and Public Key and Identity resources of the LWM2M Server and LWM2M Bootstrap Objects when using SMS Payload security. These resources are used to configure keying material that a Client uses with a particular Server. The Objects are configured on the Client using one of the Bootstrap mechanisms described in Section 5.1. The use of this keying material is defined in Section 7.2.
- the SMS key parameters are stored in the order Klc, KID, SPI, TAR (Klc is byte 0).
- secure communication via interface Ua 150, or via any other suitable interface between the NAF 122 and the UE 110, between the two entities may be established.
- this may be achieved using LWM2M, wherein a key derived by GBA (Ks_NAF) can be used as a DTLS pre-shared key and will work with any DM client/DM server pair.
- Ks_NAF key derived by GBA
- Figure 5 shows an example administration process for an interface between the UE 110 and the NAF 122, the administration process being for client registration as part of LWM2M (for more details, see section 5.2 of the Lightweight Machine to Machine Technical Specification Candidate Version 1.0 - 10 Dec 2013 OMA-TS-LightweightM2M-V1_0-20131210-C).
- the DM client 116 registers with the NAF 122. This is performed using the "Register" operation.
- the Register operation may comprise a number of parameters, at least some of which may be set by the DM client 116. Further details of available parameters for the Register operation may be found in section 5.2.1 of OMA-TS-LightweightM2M-V1_0-20131210-C. One of the parameters available is the "Endpoint Client Name" (further details of which may be found in section 6.2 of OMA-TS-LightweightM2M-V1_0-20131210-C). Other parameters may include, for example, "Binding Mode” and/or "SMS Number” etc, although these shall not be discussed any further herein.
- the Endpoint Client Name is a name for the DM client 116 (or more generally for the UE 110) and it identifies the DM client 116 (or more generally the UE 110) to the NAF 122 (and optionally also the BSF 130).
- the Endpoint Client Name may be set by the DM client 116 and provided to the NAF 122 during registration (and optionally provided to the BSF 130 during the bootstrap procedure, or at any other time).
- the NAF 122 (and optionally the BSF 130) may then use the Endpoint Client Name to identify the DM client 116 (or more generally the UE 110) in any subsequent processes and/or communications.
- the name chosen for the Endpoint Client Name may have privacy implications, in particular if the UE 110 is linked to a human in some way (for example, if the UE 110 is a medical device or a metering device in a house etc). Therefore, it may be preferable to set the Endpoint Client Name to a name that is unlikely to compromise the privacy of the UE 110 or any people or entities associated with the UE 110.
- the DM client 116 (or more generally the UE 110) may set the Endpoint Client Name to be equal to, or be a value derived from, or otherwise linked to, at least part of a temporary GBA identifier, or indeed any data (or any part of data) that is shared between the UE 110 and the BSF 130 (for example, as part of the bootstrapping process).
- the Endpoint Client Name could be set to be equal to at least part of two or more items of data that are shared between the UE 110 and the BSF 130.
- the Endpoint Client Name may be set to equal, it will be appreciated that any other data items shared between, or known to both of, the UE 110 and the BSF 130 may be used.
- the UE 110 contacts the BSF 130, which may be a basic GET request.
- this message could contain one or more of a "Request URI” (by default, but could contain other data), a "Host” (BSF domain name and port), a "User Agent field, a "Date” field and an "Authorization” field (which in turn contains a "private user identity”, a "realm” (equal to the host), a "nonce", a "uri” (equal to the Request URI) and a "response” field).
- the "private user identity" (which is likely to be either the IMPI or TMPI, although could be any other identifier) may be the most useful of these fields for setting the Endpoint Client Name, but it will be appreciated that at least part of any one or more of these items could be used for setting the Endpoint Client Name.
- a "401 Unauthorized” response message (defined in Table A.3-3 of TS 24.109) contains a "Server” field, another “Date” field, and a “WWW-Authenticate” field (which in turn contains the "realm”, a "nonce”, an "algorithm” (specified to be AKAv1-MD5), a "qop” field (specified to be “auth-int”) and an "opaque” field (which contains random data.
- the "nonce" field (which is constructed to contain the "RAND” and “AUTN” parameters, and other "server specific data”) may be the most useful of these fields for setting the Endpoint Client Name.
- the GAA server 114 may pass the RAND and AUTN to the UICC 112 and receive in return the RES and CK
- next “GET” message (defined in Table A.3-4 of TS 24.109) contains the same parameters as the first GET message with some additional items: the "nonce”, “opaque” and “algorithm”, which are copied from the "401 unauthorized” message above, and also a random client nonce “cnonce”, nonce count “nc” and the “response”, which is computed using HTTP Digest Authentication (RFC2617) treating the "RES" as the password.
- RRC2617 HTTP Digest Authentication
- the final "OK” message (defined in Table A.3-5 of TS 24.109) contains an "Authentication-Info” field with sub-fields “cnonce”, “nc”, “opaque”, “nonce” and “qop”, copied from the "GET” message above, and a further field “rspath” constructed using HTTP Digest authentication from the server.
- a further date field "Expires” and an xml document in the message body containing the "B-TID” and "Lifetime”. Again, it will be appreciated that at least part of any one or more of these items could be used for setting the Endpoint Client Name.
- Other data that may be shared between the UE 110 and BSF 130 may include: any additional fields and messages exchanged during Ub 160 communications error cases; any extensions to the Ub 160 messages with additional non-standard fields or headers (to communicate yet more shared data); any parameters passed from the BSF 130 to the UE 110 over the Upa interface (e.g. anything within a GBA Push Information message) and any parameters that might be exchanged as a result of tunnelling the Ub or Upa interfaces.
- any additional fields and messages exchanged during Ub 160 communications error cases may include: any additional fields and messages exchanged during Ub 160 communications error cases; any extensions to the Ub 160 messages with additional non-standard fields or headers (to communicate yet more shared data); any parameters passed from the BSF 130 to the UE 110 over the Upa interface (e.g. anything within a GBA Push Information message) and any parameters that might be exchanged as a result of tunnelling the Ub or Upa interfaces.
- the Endpoint Client Name may be set to be at least part of any one or more items of data that are shared between (i.e., known to both) the UE 110 and the BSF 130, a number of which items or data are identified above.
- a number of these items of data have a random component that is used to disguise the underlying private identifier.
- the TMPI anonymises the TMSI, and the B-TID/P-TID is randomly generated by the BSF 130 to disguise the Ks or Ks_NAF, which is kept private by the UE 110 and the BSF 130. Therefore, by setting the Endpoint Client Name to equal at least part of any one or more of these temporary identifiers, or indeed any other item of data that is shared between the UE 110 and the BSF 130 (and therefore linked in some way to underlying private identifiers), privacy of the DM client 116 and UE 110 may be maintained.
- the Endpoint Client Name may be set to a value derived at least in part from at least part of at least one of the data items shared between the UE 110 and the BSF 130.
- it may be a hash, or any other form of modification, of at least part of one or more of the data items shared between the UE 110 and the BSF 130, or a concatenation of at least part of two or more of the data items shared between the UE 110 and the BSF 130, etc.
- the BSF 130 may set the Endpoint Client Name and provide it to the UE 110.
- the BSF 130 may allocate an Endpoint Client Name during the bootstrapping process and provide it to the UE 110 as part of the bootstrapping process described earlier, or it may set the Endpoint Client Name and provide it to the UE 110 at any other time.
- the UE 110 may transmit a request to the BSF 130 for an Endpoint Client Name, in response to which the BSF 130 may return the Endpoint Client Name that it has allocated to the DM client 116/UE 110.
- the BSF 130 may generate the Endpoint Client Name using at least part of any one or more data items that are shared between the UE 110 and the BSF 130, for example at least part of any one or more of the data items identified above.
- the BSF 130 may set the Endpoint Client Name to equal at least part of any one or more of the shared data items, or to a value derived at least in part from at least part of any one or more of the shared data items. It may additionally or alternatively link the Endpoint Client Name to at least part of any one or more data items that are shared between the UE 110 and the BSF 130, for example using a database linkage at the BSF 130 or a database accessible to the BSF 130.
- the link between the Endpoint Client name and the at least part of any one or more of the shared data items may be kept via a database linkage at any other entity, for example at the NAF 122, or at a database accessible to the NAF 122.
- the Endpoint Client Name can be equal to, or a derivation from, or otherwise linked to, at least part of any one or more field/parameter/data items that are shared between the UE 110 and the BSF 130.
- the BSF 130 may keep a record of the Endpoint Client Name and link it with other information it has for the DM client 116/UE 110.
- the linkage may be to information that the NAF 122 is able to pass at a later time to the BSF 130 using the Zn 170 or Zpn interface in order to verify an Endpoint Client Name that it has received as a parameter of a Register operation (details of this are described later).
- the information includes "Session ID”, "Address” and “Realm” of both the NAF 122 and the BSF 130 (only for Diameter 5.2), the “Transaction Identifier” (B-TID), the "NAF-ID” and a "GBA_U-Awareness-Indicator”.
- B-TID Transmission Identifier
- NAF-ID NAF-ID
- GGBA_U-Awareness-Indicator a "GBA_U-Awareness-Indicator”.
- the information includes the same information identified for Zn above (except that B-TID is replaced by P-TID) and some additional parameters "UE-Id", “UE-Id-Type”, “UICC-App-Label”, a "UICC-ME” flag, a "Requested-Key-Lifetime”, a "Private-Identity-Request” and a "Security-Feature-Request”.
- the UE-ld may be something like the MSISDN, or the IMSI, or an IMS name like an IMPI or IMPU.
- the Endpoint Client Name may be linked at the BSF 130 to the identifier of the shared secret (the B-TID or P-TID) and/or the UE-ld (for the "GBA push" variant) so that the NAF 122 may later use the identifier of the shared secret to verify an Endpoint Client Name that it receives (details of this are described later).
- the UE 110 may pass the Endpoint Client Name to the BSF 130 for the BSF 130 to keep a record of the Endpoint Client Name with a linkage to other information it has for the DM client 116/UE 110, for example the B-TID/P-TID and/or UE-ld, as explained above.
- the UE 110 and the BSF 130 may both generate the Endpoint Client Name based on the same information that is shared between them.
- the BSF 130 may keep a record of the Endpoint Client Name with a linkage to other information it has for the DM client 116/UE 110, for example the B-TID/P-TID and/or UE-ld, as explained above, and the UE 110 may use the Endpoint Client Name in the "Register" operation, without the Endpoint Client name having to be passed between the BSF 130 and UE 110.
- the DM client 116 may set the value of another parameter of the Register operation - the "Lifetime".
- the Lifetime parameter sets a time period for which the registration of the DM client 116 (or more generally the UE 110) should remain valid.
- the NAF 122 should remove the registration if a new registration or an update is not received within the Lifetime. Therefore, Lifetime sets a time limit for the lifetime of the registered secure interface between the UE 110 and the NAF 122, i.e., the session lifetime of the secure interface between the UE 110 and the NAF 122.
- the DM client 116 may set the Lifetime based on a lifetime of the shared secret (Ks_NAF)/a lifetime of the identifier of the shared secret (B-TID or P-TID).
- Ks_NAF lifetime of the shared secret
- B-TID or P-TID lifetime of the identifier of the shared secret
- a lifetime of an identifier of the shared secret may be considered also to be the lifetime of the shared secret that it identifies, since after the identifier has expired, the secret to which the identifier points effectively also expires.
- the BSF 130 may set a lifetime for the identifier of the key (for example, the B-TID Lifetime, or the Key_LT, which is the GBA-push equivalent of the B-TID Lifetime). This may be communicated to the UE 110 as part of the bootstrapping process. Alternatively, it may be communicated to the UE 110 at any other time, for example the UE 110 may transmit the identifier of the shared secret to the BSF 130 and request
- the Lifetime parameter may be set based on, or in consideration of, the lifetime of the shared secret.
- "lifetime of the shared secret” could be the time remaining on the lifetime of the shared secret (for example, if it is initially set to 72 hours, 30 hours later the remaining lifetime of the shared secret will be 42 hours), or, alternatively, it could be the value to which the lifetime of the shared secret is initially set.
- the Lifetime parameter may be set to be equal to the lifetime of the shared secret, or it may be set to be larger or smaller than the lifetime of the shared secret. For example, it may be set to a value that is greater than the lifetime of the shared secret by a particular period of time (for example, greater by 5 hours, or 20 hours, or two days, or one week, or any other suitable amount, such as a value between one second and six months), or to be larger than the lifetime of the shared secret by a particular multiplier (for example, to be two times, or two and a half times, or four times, or any other suitable amount, such as a value between 0.01 and 50, greater).
- a particular period of time for example, greater by 5 hours, or 20 hours, or two days, or one week, or any other suitable amount, such as a value between one second and six months
- a particular multiplier for example, to be two times, or two and a half times, or four times, or any other suitable amount, such as a value between 0.01 and 50, greater.
- the Lifetime parameter may be based on, or derived from, or set in consideration of, the lifetime of the shared secret in any way.
- the Lifetime parameter is set to be greater than or equal to the lifetime of the shared secret.
- the DM client 116 may check the remaining lifetime of the identifier of the shared secret and use this check to determine if a new bootstrap run should be carried out to obtain a new shared secret and identifier of the shared secret. If the remaining lifetime of the shared secret has expired, or is close to expiry (for example, the remaining lifetime is less than a threshold amount, which might be 6 hours, or 12 hours, or 24 hours, or two days, or any suitable period of time, such as a period of time between one second and six months), the DM client 116 may initiate a new bootstrap run.
- a threshold amount which might be 6 hours, or 12 hours, or 24 hours, or two days, or any suitable period of time, such as a period of time between one second and six months
- the UE 110 may be prevented from regularly attempting to acquire a new shared secret and identifier, when the registration lifetime is significantly longer (for example, the UE 110 may be prevent from undertaking a new bootstrapping run every few hours when the registration lifetime is weeks or months).
- the lifetime of the identifier of the shared secret may be three days.
- the Lifetime parameter i.e. the session lifetime of the secure interface
- the threshold amount may be 12 hours. Two days and 14 hours later, when the DM client 116 checks the remaining lifetime of the identifier of the shared secret, it will determine that it has only 10 hours remaining, which is less than the threshold amount.
- it may initiate a new bootstrap run to obtain a new shared secret and/or identifier of a new shared secret, which can thus take place only when the existing shared secret is close to expiry and before the session lifetime of the secure interface expires.
- the UE 110 and BSF 130 overhead may be reduced as unnecessary new bootstrapping runs may be reduced or eliminated. Furthermore, the UE 110 and NAF 122 overhead may also be reduced because every time a new bootstrapping run is executed, a new Register or Update operation may be initiated by the DM client 116 (as explained in more detail below).
- the DM client 116 may check the remaining lifetime of the shared secret before it attempts to connect with the NAF 122 over the registered, secure interface (for example, before it connects to transmit a request for a service, or to pass requested data to the NAF 112 etc). For example, if the remaining lifetime of the identifier is non-zero, or exceeds a threshold amount (for example, 6 hours, or 12 hours, or 24 hours, or two days, or any other suitable amount, such as an amount between one second and six months) the DM client 116 may simply connect with the NAF 116 using the existing, registered, secure interface.
- a threshold amount for example, 6 hours, or 12 hours, or 24 hours, or two days, or any other suitable amount, such as an amount between one second and six months
- the registration may have expired or be close to expiry, so the DM client 116 can pre-emptively run a new bootstrapping process to obtain a new shared secret and identifier of the new shared secret and either update the previous registration, or carry out a new registration.
- the UE 110 it may be possible for the UE 110 to identify that a new bootstrapping run is required before it attempts to connect with the NAF 122 and receive an error message because the registration has expired. This may even further improve efficiency because the UE 110 can proactively obtain a new shared secret and identifier when the registration has expired or is close to expiry, rather than waiting to receive an error message from the NAF 122.
- the BSF 130 may set the lifetime of the identifier of the shared secret, which in turn will affect the Lifetime parameter set by the UE 110 for the Register operation.
- the BSF 130 may effectively therefore influence the value of the Lifetime parameter based on its knowledge of how long particular devices can be expected to keep secrets, how secure particular devices are, what type of UICC 112 the device contains, what threats the device faces etc.
- it also affords the BSF 130 the opportunity to vary the lifetime of the identifier of the shared secret and the Lifetime parameter dynamically to exercise load balancing, for example to space out re-bootstrapping requests, update requests etc.
- the shared secret lifetime may be one day, but the NAF 122 may accept a Lifetime parameter of three days.
- the UE 110 may then attempt to run a new bootstrapping process after the lifetime of the identifier expires and, if the re-run fails, try again after a period of time (for example, it may re-try at 2 hourly intervals, or 6 hourly intervals, or one day intervals, or any other suitable period of time). Because the registration Lifetime (i.e.
- the session lifetime of the secure interface between the UE 110 and the NAF 122) is greater than the lifetime of the shared secret, even if the UE 110 fails to obtain a new shared secret and identifier (for example, because the BSF 130 was unreachable at renewal time, etc), it may still continue to use the registered interface and have one or more further opportunities to re-run the bootstrapping process before the registration expires.
- a balance may be achieved between minimising the number of new bootstrapping runs and new registrations or registration updates that are undertaken (thereby reducing overheads) and avoiding expiration of the secure interface between the UE 110 and NAF 122.
- Lifetime is set to equal the lifetime of the shared secret, or where Lifetime is set to a value less than the lifetime of the shared secret, by configuring the UE 110 to attempt a new boot-strapping run when the remaining lifetime of the identifier of the shared secret is less than a threshold amount, wherein the threshold amount is such that a new bootstrapping run will be attempted at the time that Lifetime expires, or before Lifetime expires.
- the Lifetime parameter is set to be less than the lifetime of the shared secret
- the security information comprises a key or keys (for example, the Ks_NAF) that are themselves used over the secure interface.
- the lifetime of the secure registration it may be preferable for the lifetime of the secure registration to be less than the lifetime of the keys used to secure the interface, so that expired keys are not used on the interface This is in contrast to, for example, DTLS, where the security information is used to negotiate new keys.
- the Register operation might also comprise the identifier of the shared secret (for example, the B-TID or P-TID), which is referred to as the PSK Identity in LWM2M, and optionally also an identifier of the security mode to be used, for example Pre-Shared Key mode (or alternatively a raw public key mode, or a certificate mode etc).
- the Register operation might optionally comprise any other suitable registration data that might be used by the NAF 122 to register the secure interface.
- the NAF 122 may check the parameters of the operation before transmitting a "Created" response to the DM client 116 in step 520 to confirm that the registration has been successful. For example, if the BSF 130 has stored the Endpoint Client Name with a linkage to other information it has for the DM client 116/UE 110 (for example the B-TID/P-TID and/or the UE-Id), the NAF 122 may verify the Endpoint Client Name by making use of the information it has for the DM client 116/UE 110.
- the NAF 122 may pass to the BSF 130 the identifier of the shared secret (B-TID/P-TID) that is a parameter of the Register operation and request the Endpoint Client Name that the BSF 130 has linked with the identifier of the shared secret. If the Endpoint Client Name that the BSF 130 returns matches the Endpoint Client name that was included as a parameter in the Register operation, the Endpoint Client Name received as part of the Register operation may be verified by the NAF 122 and the NAF 122 may continue with the registration process as normal. If they do not match, the NAF 122 may return an error message to the DM client 116 in step 520 to indicate that registration has failed.
- B-TID/P-TID the identifier of the shared secret
- the NAF 122 may pass to the BSF 130 both the identifier of the shared secret and/or UE-ld and the Endpoint Client Name that it has received and request that the Endpoint Client Name is verified against the BSF's records.
- the BSF 130 may then return confirmation of a positive verification or an indication that the verification has failed.
- the NAF 122 may then proceed with the registration process as normal or transmit an error message to the DM client 116 in step 520 as described above.
- the NAF 122 may carry out this verification process by referring to records that are stored on the NAF 122 or in a location accessible to the NAF 122, for example on a database that is accessible to the NAF 122.
- the BSF 130 may include the Endpoint Client Name in the GPI response that it transmits to the NAF 122.
- the NAF 122 may then link the Endpoint Client Name with the other information it has for the DM Client 116/UE 110 by storing an association between them in the NAF_SA.
- the NAF 122 may then check the Endpoint Client Name that it receives as a parameter of the Register operation against the Endpoint Client Name that it has stored in association with the other information for the DM Client 116/UE 110 that it receives. Alternatively, the NAF 122 may have obtained the Endpoint Client Name from the BSF 130 at some other time and kept a record linking the Endpoint Client Name to the other information for the DM Client 116/UE 110.
- the BSF 130 or NAF 122 may link the data from which the Endpoint Client Name is set (for example, the at least part of one or more items of data that the Endpoint Client Name is set to equal, or from which the Endpoint Client Name is derived) with the other information for the DM Client 116/UE 110.
- the BSF 130 or NAF 122 may then obtain the Endpoint Client Name using the other information it has for the DM Client 116/UE 110 by looking up the data to which the other information is linked and then determine the Endpoint Client Name from that data (or, optionally, where the BSF 130 has stored this data, it may return it to the NAF 122 during verification and the NAF 122 may then determine the Endpoint Client Name from the data so that it can verify the Endpoint Client Name it receives in a Register operation).
- the NAF 122 may check that the Lifetime parameter matches, or compares in an expected way with, the lifetime of the shared secret. For example, it may compare the two lifetimes and if they do not meet a comparison condition, (which might be any suitable condition, for example, that the Lifetime parameter is equal to the lifetime of the shared secret, or that the Lifetime parameter is some amount greater than the lifetime of the shared secret, for example greater by 12 hours, or 24 hours, three days, or any other suitable amount, or that the Lifetime parameter is at least some amount greater than the lifetime of the shared secret, such as 12 hours, or 24 hours, or three days, or any other suitable amount, or that the Lifetime parameter is less than the lifetime of the shared secret, for example less by a particular period of time or less by a particular division of the lifetime of the shared secret), the NAF 122 may return an error message to the DM client 116 in step 520 to indicate that registration has failed. If, however, the comparison does meet the comparison condition,
- the DM client 116 may transmit an "Update" operation in step 530. More details relating to the Update operation may be found in section 5.2.2 of OMA-TS-LightweightM2M-V1_0-20131210-C.
- the Update operation may be used to update the registration information with the NAF 122 where one or more of the parameters of the registration have changed compared with an earlier Register or Update operation. For example, a new shared secret and/or identifier of the shared secret may have been obtained by the UE 110, and consequently the Lifetime parameter may have changed.
- One of the parameters of the Update operation that the DM client 116 may set is the Lifetime parameter. Therefore, if the Lifetime parameter has changed, for example after a re-run of the bootstrapping process, the DM client 116 may set the Lifetime parameter of the Update operation based on the new lifetime of the shared secret in the same way as described above in respect of the Register operation and transmit the Update operation in step 530.
- the NAF 122 may optionally check that the Lifetime parameter compares in an expected way with the lifetime of the indicator of the shared secret and/or verify the Endpoint Client Name, in the same way as described above in respect of the Register operation. If this check(s) fails, the NAF 122 may return an error message to the DM client 116 in step 540 to indicate that the update has failed. If the check is successful, the NAF 122 may continue the update process as normal.
- the NAF 122 may transmit a "Changed" message to the DM client 116 in step 540 to confirm that the update has been successful.
- the NAF 122 is implemented as part of the DM server 120, for example as a plug-in component to the DM server 120.
- the NAF 122 may be any server or network component which terminates the Ua 150 and uses a shared secret established by GBA to secure communications on that interface.
- the NAF 122 may form at least part of the DM server 120 or may exist separately from the DM server 120. In this way, the NAF could be any application.
- the NAF 122 may be the DM server 120, i.e. the NAF 122 may be identical to the DM server 120, or it may be a plug-in component in the DM server 120.
- the NAF 122 may act as a proxy in front of the DM server 120. As a proxy, the NAF 122 would terminate the connection from the UE 110 (thus acting as a server to the UE 110) and start a new connection with the DM server 120 (thus acting as a client to the DM server 120).
- the NAF 122 may act as a router, located between the UE 110 and the DM server 120. The NAF 122 may then pass Ua 150 traffic from the UE 110 on to the DM server 120 and pass Ua 150 traffic from the DM server 120 back to the UE 110.
- the NAF 122 can terminate the security established over the Ua 150 interface using the Ks_NAF (or a key(s) derived from the Ks_NAF) and then pass the Ua 150 traffic on to the DM server 130, either unencrypted, or encrypted in a way that does not necessarily require the DM server 130 to be GBA aware. In this way, the functionality of the DM server 130 does not have to be altered in any way and does not need to be 'GBA aware'.
- the DM server 130 may, for example, be a DM bootstrapping server, a LWM2M server or LWM2M bootstrapping server, or any generic application that may benefit from GBA.
- securing of communications over the interface between the UE 110 and the NAF 122 is achieved with use of a shared secret (for example, Ks_NAF) and an identifier of the shared secret (for example, P-TID or B-TID), it will be appreciated that it may be achieved in any other suitable way.
- Ks_NAF shared secret
- an identifier of the shared secret for example, P-TID or B-TID
- the UE 110 may comprise security information that comprises a public key (for example, RPK) that can be used as a parameter in the Register operation to register a secure interface, and/or it may comprise a certificate that can be used as a parameter in the Register operation to register a secure interface.
- RPK public key
- the security information that is used in registering the secure interface may have an associated lifetime that may be used in the setting of the Lifetime parameter. For example, for a certificate, there may be a validity date within the certificate that can represent the lifetime of the certificate.
- the key may have been supplied to the UE 110 by a bootstrapping server, for example a LWM2M bootstrapping server, (along with the private key), or by bootstrapping from the UICC 112, or by manufacturer bootstrapping.
- a bootstrapping server for example a LWM2M bootstrapping server, (along with the private key), or by bootstrapping from the UICC 112, or by manufacturer bootstrapping.
- the bootstrapping server/UICC 112/manufacturer might have associated a lifetime with the key.
- the Endpoint Client Name may be linked to other information related to the DM client 116/UE 110 (for example the B-TID/P-TID and/or the UE-Id) so that the NAF 122 may later verify the Endpoint Client Name it receives from the UE 110.
- the NAF 122 could pass a "hint" at the Endpoint Client Name to the BSF 130 (for example, by using one of the data fields available on the Zn/Zpn interface) and ask the BSF 130 to confirm if that hint is correct (for example, by returning the full Endpoint Client Name in response).
- the hint may be, for example, a part of the Endpoint Client Name that the NAF 122 has received from the UE 110 and/or a hash of the Endpoint Client Name that the NAF 122 has received from the UE 110.
- the NAF 122 may pass as the hint to the BSF 130 the "data element" (which could be equal to or derived from the shared data that is linked to the Endpoint Client name). For example, it may pass the B-TID. The BSF 130 can then look up the linked Endpoint Client Name and check that it is consistent with the hint.
- the hint may be constructed in such a way that there is an effective 1-1 mapping between Endpoint Client Names and hints, for example, the hint is a hash of the Endpoint Client Name, or the Endpoint Client Name contains a lot of random data and the hint contains enough of that random data to ensure effective uniqueness (the hint might contain 128 bit of random data, for instance).
- the BSF 130 can maintain a look-up table between hints and Endpoint Client Names and use the hint to retrieve the matching name.
- the BSF 130 may link the Endpoint Client Name to other information by storing the Endpoint Client Name at the BSF 130, or at a location accessible to the BSF 130 (for example, a database accessible to the BSF 130), with an association to the other information it has for the DM Client 116/UE 110.
- it may link the data from which the Endpoint Client Name is set (for example, the at least part of one or more items of data that the Endpoint Client Name is set to equal, or from which the Endpoint Client Name is derived) with the other information.
- the BSF 130 may then obtain the Endpoint Client Name from the other information it has for the DM Client 116/UE 110 by using the other information to look up the data to which it is linked and then determining the Endpoint Client Name from that data.
- the BSF 130 may pass to the NAF 122 the data that is linked to the other information for the DM Client 116/UE 110 and the NAF 122 may then itself obtain the Endpoint Client Name from that data in order to verify an Endpoint Client Name that it has received from the UE 110.
- communications between the UE 110 and the NAF 122 are secured using the LWM2M protocol.
- any suitable protocol such as OMA DM 1.0-1.3, OMA DM 2.0, or TR-069 may be used for this purpose and that any parameters to the protocol that are equivalent to the Endpoint Client Name and/or the Lifetime parameter may be set in an analogous way to that described above.
- each of the BSF 130, DM server 120 and NAF 122 are shown in the Figures as being implemented on single server elements. However, it will be appreciated that the functionality of each of the BSF 130, the DM server 120 and the NAF 122 may be spread across two or more devices, each of which may be co-located or located at a distance from one another.
- the interfaces between the NAF 122 and the UE 110, between the BSF 130 and the NAF 122 and between the BSF 130 and the HLR/HSS 140 are represented as direct interfaces.
- any one or more of those interfaces may take any suitable form, whereby one or more intermediate devices or elements, for example communication routing devices, may be implemented as part of the interfaces.
Claims (12)
- Un procédé destiné à un dispositif de machine à machine, M2M, (110) de façon à administrer une interface (150) entre le dispositif M2M (110) et une fonction d'application de réseau, NAF, (122) pour une communication sécurisée entre le dispositif M2M (110) et la NAF (122), où le dispositif M2M (110) comprend des informations de sécurité qui comprennent une clé ou des clés destinées à permettre une communication sécurisée par l'intermédiaire de l'interface (150), le procédé comprenant les opérations consistant à lancer, avant l'expiration d'une durée de vie des informations de sécurité et lors de l'éveil d'un cycle de sommeil :le réglage d'un paramètre de durée de vie d'interface sécurisée en fonction d'une durée de vie d'au moins une partie des informations de sécurité, où le paramètre de durée de vie d'interface sécurisée règle une période temporelle pour laquelle un enregistrement de l'interface sécurisée entre le dispositif M2M (110) et la NAF (122) demeure valide,la transmission de données d'administration à la NAF (122), où les données d'administration comprennent le paramètre de durée de vie d'interface sécurisée,si l'enregistrement de l'interface sécurisée entre le dispositif M2M (110) et la NAF (122) a expiré ou que la durée de vie restante des informations de sécurité est inférieure à une quantité seuil, le lancement préemptif d'un nouveau procédé d'amorçage de façon à obtenir de nouvelles informations de sécurité, le lancement étant préemptif du résultat de l'obtention des nouvelles informations de sécurité avant la tentative par le dispositif M2M (110) de se connecter à la NAF (122), etl'utilisation des nouvelles informations de sécurité de façon à soit actualiser l'enregistrement ou, dans une variante, effectuer un nouvel enregistrement.
- Le procédé selon la Revendication 1, où le paramètre de durée de vie d'interface sécurisée est réglé sur une valeur supérieure ou égale à la durée de vie de la au moins une partie des informations de sécurité.
- Le procédé selon la Revendication 1, où le paramètre de durée de vie d'interface sécurisée est réglé sur une valeur inférieure à la durée de vie de la au moins une partie des informations de sécurité.
- Le procédé selon la Revendication 1, comprenant en outre l'opération suivante :
si le nouveau procédé d'amorçage échoue, la répétition du nouveau procédé d'amorçage après une période temporelle. - Le procédé selon l'une quelconque des Revendications précédentes, où :les données d'administration comprennent en outre un nom pour le dispositif M2M (110), et oùle nom pour le dispositif M2M (110) est égal à, ou dérivé au moins en partie de, ou autrement relié à, au moins une partie de données qui sont partagées entre le dispositif M2M (110) et un serveur d'amorçage (130).
- Le procédé selon la Revendication 5 comprenant en outre l'opération suivante :
la dérivation du nom pour le dispositif M2M (110) au moins en partie à partir d'au moins une partie des données qui sont partagées entre le dispositif M2M (110) et le serveur d'amorçage (130). - Le procédé selon la Revendication 5 ou 6, où :le nom pour le dispositif M2M (110) est relié à au moins une partie des données qui sont partagées entre le dispositif M2M (110) et le serveur d'amorçage (130), et oùles données d'administration comprennent en outre un élément de données égal à ou dérivé de la au moins une partie des données qui sont partagées entre le dispositif M2M (110) et le serveur d'amorçage (130) auquel le nom pour le dispositif M2M (110) est relié.
- Le procédé selon l'une quelconque des Revendications 5 à 7, où les données qui sont partagées entre le dispositif M2M (110) et le serveur d'amorçage (130) comprennent les informations de sécurité.
- Le procédé selon l'une quelconque des Revendications précédentes, où l'interface est une interface de gestion de dispositif.
- Le procédé selon l'une quelconque des Revendications précédentes, où l'interface est une interface M2M légère, LWM2M.
- Le procédé selon la Revendication 10, où les données d'administration sont transmises à la NAF (122) sous la forme au moins d'une partie d'une opération d'enregistrement ou sous la forme au moins d'une partie d'une opération d'actualisation.
- Un dispositif M2M (110) comprenant une logique configurée de façon à exécuter le procédé selon l'une quelconque des Revendications précédentes.
Applications Claiming Priority (8)
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 |
GB1409643.2A GB2518255A (en) | 2013-09-13 | 2014-05-30 | Communicating with a machine to machine device |
GB1409663.0A GB2518257A (en) | 2013-09-13 | 2014-05-30 | Methods and systems for operating a secure mobile device |
GB1409652.3A GB2518256A (en) | 2013-09-13 | 2014-05-30 | Communicating with a machine to machine device |
GB1409641.6A GB2518254B (en) | 2013-09-13 | 2014-05-30 | Communicating with a machine to machine device |
GB1414999.1A GB2518522B (en) | 2013-09-13 | 2014-08-22 | Communicating with a machine to machine device |
PCT/GB2014/052773 WO2015036778A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3044984A1 EP3044984A1 (fr) | 2016-07-20 |
EP3044984B1 true EP3044984B1 (fr) | 2021-07-21 |
Family
ID=51214488
Family Applications (15)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14776684.4A Active EP3044982B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec dispositifs machine-machine |
EP20195438.5A Active EP3767984B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14777373.3A Active EP3044975B8 (fr) | 2013-09-13 | 2014-09-12 | Communication sécurisée avec un dispositif mobile |
EP14771950.4A Withdrawn EP3044934A2 (fr) | 2013-09-13 | 2014-09-12 | Procédés et systèmes pour faire fonctionner un dispositif mobile sécurisé |
EP20209753.1A Active EP3800862B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec des dispositifs machine à machine |
EP14776682.8A Active EP3044973B1 (fr) | 2013-09-13 | 2014-09-12 | Procédés et systèmes pour communiquer avec un dispositif m2m |
EP21163810.1A Pending EP3855701A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec des dispositifs machine à machine |
EP14772418.1A Withdrawn EP3044927A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif |
EP14777374.1A Active EP3044976B1 (fr) | 2013-09-13 | 2014-09-12 | Gestion de dispositifs machine-machine |
EP14777371.7A Withdrawn EP3044985A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14776681.0A Active EP3044983B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14777370.9A Active EP3044928B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14777372.5A Withdrawn EP3044974A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14776683.6A Active EP3044984B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP21154414.3A Active EP3832982B1 (fr) | 2013-09-13 | 2014-09-12 | Communication sécurisée avec un dispositif mobile |
Family Applications Before (13)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14776684.4A Active EP3044982B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec dispositifs machine-machine |
EP20195438.5A Active EP3767984B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14777373.3A Active EP3044975B8 (fr) | 2013-09-13 | 2014-09-12 | Communication sécurisée avec un dispositif mobile |
EP14771950.4A Withdrawn EP3044934A2 (fr) | 2013-09-13 | 2014-09-12 | Procédés et systèmes pour faire fonctionner un dispositif mobile sécurisé |
EP20209753.1A Active EP3800862B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec des dispositifs machine à machine |
EP14776682.8A Active EP3044973B1 (fr) | 2013-09-13 | 2014-09-12 | Procédés et systèmes pour communiquer avec un dispositif m2m |
EP21163810.1A Pending EP3855701A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec des dispositifs machine à machine |
EP14772418.1A Withdrawn EP3044927A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif |
EP14777374.1A Active EP3044976B1 (fr) | 2013-09-13 | 2014-09-12 | Gestion de dispositifs machine-machine |
EP14777371.7A Withdrawn EP3044985A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14776681.0A Active EP3044983B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14777370.9A Active EP3044928B1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
EP14777372.5A Withdrawn EP3044974A1 (fr) | 2013-09-13 | 2014-09-12 | Communication avec un dispositif machine à machine |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP21154414.3A Active EP3832982B1 (fr) | 2013-09-13 | 2014-09-12 | Communication sécurisée avec un dispositif mobile |
Country Status (6)
Country | Link |
---|---|
US (14) | US10439991B2 (fr) |
EP (15) | EP3044982B1 (fr) |
CN (1) | CN105706469B (fr) |
ES (2) | ES2933426T3 (fr) |
GB (15) | GB2586549B (fr) |
WO (12) | WO2015036777A1 (fr) |
Families Citing this family (179)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9497169B2 (en) * | 2012-06-08 | 2016-11-15 | Samsung Electronics Co., Ltd. | Method and system for selective protection of data exchanged between user equipment and network |
BR112015016953A2 (pt) * | 2013-01-15 | 2017-07-11 | Hewlett Packard Development Co | atualização de firmware dinâmico |
EP3557894B1 (fr) * | 2013-05-06 | 2023-12-27 | Convida Wireless, LLC | Déclenchement de dispositifs |
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 |
GB2586549B (en) | 2013-09-13 | 2021-05-26 | 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 | 正文科技股份有限公司 | 绑定移动载具与智能装置之方法及其绑定系统 |
US11570065B2 (en) * | 2014-04-09 | 2023-01-31 | Convida Wireless, Llc | Service enabler function |
EP3148418B1 (fr) | 2014-05-27 | 2021-01-06 | ResMed Inc. | Diagnostics à distance de dispositifs de thérapie respiratoire |
CN107211232B (zh) * | 2014-07-22 | 2020-09-25 | 康维达无线有限责任公司 | 轻量级机器对机器协议与装置管理协议的互工作 |
GB2529838B (en) * | 2014-09-03 | 2021-06-30 | Advanced Risc Mach Ltd | Bootstrap Mechanism For Endpoint Devices |
WO2016048208A1 (fr) * | 2014-09-25 | 2016-03-31 | Telefonaktiebolaget L M Ericsson (Publ) | Mobilité de dispositif avec 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 |
WO2016091690A1 (fr) * | 2014-12-11 | 2016-06-16 | British Telecommunications Public Limited Company | Configuration d'appareil serveur |
WO2016113593A1 (fr) * | 2015-01-13 | 2016-07-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Interrogation de protocole d'application pour sécuriser une utilisation d'architecture d'amorçage générique (gba) |
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 |
EP3262861B1 (fr) | 2015-02-27 | 2021-06-02 | Telefonaktiebolaget LM Ericsson (publ) | Agencements de sécurité dans une communication entre un dispositif de communication et un dispositif réseau |
GB2536698A (en) * | 2015-03-26 | 2016-09-28 | Eoghan Hynes | Secure communications between a beacon and a handset |
WO2016160626A1 (fr) * | 2015-03-27 | 2016-10-06 | Globallogic, Inc. | Détermination d'actions reposant sur l'attribution de signification à des informations détectées dans un environnement informatique distribué |
US10601823B2 (en) | 2015-04-07 | 2020-03-24 | 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 | 한국전자통신연구원 | 연산 에러 검출이 가능한 준동형 암호 방법 및 그 시스템 |
US11080414B2 (en) | 2015-05-22 | 2021-08-03 | Huawei Device Co., Ltd. | 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 |
EP3311321B1 (fr) | 2015-06-17 | 2021-08-04 | Telefonaktiebolaget LM Ericsson (PUBL) | Procédé pour permettre la fourniture sécurisée d'un justificatif d'identité, et dispositifs sans fil et serveurs associés |
WO2017001022A1 (fr) | 2015-07-02 | 2017-01-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Procédé d'obtention d'accès initial à un réseau ainsi que dispositifs sans fil et nœuds de réseau associés |
WO2017007385A1 (fr) * | 2015-07-06 | 2017-01-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Facilitation de communication sécurisée entre un dispositif client et un serveur d'application |
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 | 상명대학교 천안산학협력단 | 해시 트리 기반 보안 메시지 인증 방법 및 이를 위한 장치 |
KR20180051583A (ko) * | 2015-10-07 | 2018-05-16 | 삼성전자주식회사 | RESTful 서버와 oneM2M 시스템 간의 자원 매핑 방법 |
CN116471575A (zh) * | 2015-10-23 | 2023-07-21 | 瑞典爱立信有限公司 | 机器对机器装置的操作状态的建立 |
US10194033B2 (en) * | 2015-11-24 | 2019-01-29 | 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 |
US10708781B2 (en) | 2016-01-27 | 2020-07-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for setting up a secure connection between LWM2M devices |
WO2017139046A1 (fr) * | 2016-02-09 | 2017-08-17 | Presenso, Ltd. | Système et procédé pour l'analyse non supervisée de causes profondes de pannes de matériel |
US10268495B2 (en) * | 2016-02-18 | 2019-04-23 | Verizon Patent And Licensing Inc. | Virtual device model 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 |
EP3465000A1 (fr) | 2016-05-23 | 2019-04-10 | HSL Energy Holding APS | Appareil de production de vapeur à partir d'un liquide aqueux |
WO2017202466A1 (fr) * | 2016-05-26 | 2017-11-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Enregistrement de fonction d'application de réseau |
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 (fr) * | 2016-07-13 | 2018-01-17 | Gemalto Sa | Procédé et dispositifs de gestion d'un élément sécurisé |
EP3270321B1 (fr) * | 2016-07-14 | 2020-02-19 | Kontron Modular Computers SAS | Technique de mise en oeuvre d'une opération de manière sécurisée dans un environnement iot |
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 |
US11316744B2 (en) | 2016-12-21 | 2022-04-26 | Juniper Networks, Inc. | Organizing execution of 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 | 株式会社村田製作所 | 積層セラミックコンデンサ |
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 |
EP3649760A1 (fr) * | 2017-07-03 | 2020-05-13 | Telefonaktiebolaget LM Ericsson (PUBL) | Communications sécurisées utilisant une identité d'accès au réseau |
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 | 大同股份有限公司 | 閘道器、物聯網裝置控制系統與其方法 |
EP3677063B1 (fr) | 2017-08-30 | 2023-10-04 | Telefonaktiebolaget LM Ericsson (Publ) | Reconfiguration de dispositifs de communication |
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 |
CN110741613B (zh) * | 2017-10-16 | 2021-01-12 | Oppo广东移动通信有限公司 | 一种加密数据流的识别方法、设备、存储介质及系统 |
CN107749878B (zh) * | 2017-10-16 | 2021-05-14 | 新华三信息安全技术有限公司 | 一种同步文件的方法及装置 |
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 |
US11784797B2 (en) * | 2017-11-30 | 2023-10-10 | 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 (fr) * | 2018-02-02 | 2019-08-08 | Atc Technologies, Llc | Coordination d'echange de donnees de dispositif de reseau |
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 |
EP3804233B1 (fr) * | 2018-06-01 | 2023-11-29 | Telefonaktiebolaget LM Ericsson (publ.) | Procédé et appareil pour effectuer une communication dans l'internet des objets |
EP3811647B1 (fr) * | 2018-06-25 | 2022-02-23 | Telefonaktiebolaget LM Ericsson (publ) | Dispositifs d'amorçage sur un réseau |
GB2575433B (en) * | 2018-06-26 | 2020-07-08 | Advanced Risc Mach Ltd | Automatic client device registration |
EP3818731A1 (fr) * | 2018-07-03 | 2021-05-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Premier noeud, dispositif de communication, et procédés mis en oeuvre par ces moyens pour gérer des informations de positionnement |
US10778444B2 (en) | 2018-07-11 | 2020-09-15 | Verizon Patent And Licensing Inc. | Devices and methods for application attestation |
FR3084181A1 (fr) * | 2018-07-20 | 2020-01-24 | Orange | Procede de coordination d'une pluralite de serveurs de gestion d'equipements |
US10868876B2 (en) * | 2018-08-10 | 2020-12-15 | Cisco Technology, Inc. | Authenticated service discovery using a secure ledger |
CN110831002B (zh) * | 2018-08-10 | 2021-12-03 | 华为技术有限公司 | 一种密钥推演的方法、装置及计算存储介质 |
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的认证方法及相关设备 |
EP3881571A1 (fr) * | 2018-11-16 | 2021-09-22 | Convida Wireless, Llc | Sélection de plan de commande et de plan utilisateur pour petites données |
GB2579571B (en) * | 2018-12-03 | 2021-05-12 | Advanced Risc Mach Ltd | Device bootstrapping |
US11144045B2 (en) * | 2018-12-18 | 2021-10-12 | General Electric Company | Apparatus and method for repair of edge devices |
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 |
WO2020199827A1 (fr) * | 2019-04-04 | 2020-10-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Procédés et appareils de communication entre un client lwm2m et un serveur |
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 |
US11175899B2 (en) * | 2019-04-17 | 2021-11-16 | Vmware, Inc. | Service upgrade integration for virtualized computing environments |
GB2584527B (en) * | 2019-05-10 | 2021-12-08 | Advanced Risc Mach Ltd | Machine to machine communications |
EP3972220A4 (fr) * | 2019-05-13 | 2022-11-30 | Hyundai Motor Company | Procédé et dispositif de suppression de ressources dans un système m2m |
CN110213744A (zh) * | 2019-05-31 | 2019-09-06 | 恒宝股份有限公司 | 一种智能卡实现m2m业务的方法、装置及智能卡 |
JP6856090B2 (ja) * | 2019-06-07 | 2021-04-07 | ダイキン工業株式会社 | 機器管理システム |
JP7315825B2 (ja) * | 2019-06-14 | 2023-07-27 | ダイキン工業株式会社 | 機器管理システムおよび認証方法 |
EP3767909A1 (fr) * | 2019-07-17 | 2021-01-20 | Siemens Mobility GmbH | Procédé et dispositif de communication destiné à la transmission unidirectionnelle de données protégée de maniere cryptographique des données utiles entre deux réseaux |
US11050699B2 (en) | 2019-08-06 | 2021-06-29 | Airship Group, 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 | 公安部交通管理科学研究所 | 一种网间交通流数据的交换方法及系统 |
CA3154730A1 (fr) * | 2019-09-18 | 2021-03-25 | GPSip, Inc. | Systeme de guidage de zone assistee par localisation sans fil comportant la transmission sure d'emplacement |
CN114365453A (zh) * | 2019-09-19 | 2022-04-15 | 谷歌有限责任公司 | 使用私有可解析地址的网络过滤 |
CN115379414A (zh) * | 2019-09-25 | 2022-11-22 | 华为技术有限公司 | 证书发放方法和装置 |
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 (fr) * | 2019-10-16 | 2023-08-16 | NXP USA, Inc. | Mise à jour de micrologiciel de noeud de réseau |
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 |
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 |
US11658963B2 (en) | 2019-12-04 | 2023-05-23 | International Business Machines Corporation | Cooperative communication validation |
CN111181970B (zh) * | 2019-12-31 | 2022-03-11 | 广州邦讯信息系统有限公司 | 一种使用国密算法应用于国产化fsu的方法和系统 |
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 |
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卡空中传输系统及其工作方法 |
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 |
CN111935697B (zh) * | 2020-08-06 | 2022-08-19 | 中国联合网络通信集团有限公司 | eSIM发现服务方法、发现服务器及eSIM终端 |
CN114143016A (zh) * | 2020-08-14 | 2022-03-04 | 中兴通讯股份有限公司 | 基于通用引导架构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 |
GB2608634A (en) | 2021-07-08 | 2023-01-11 | Vodafone Group Services Ltd | Device data validity |
GB2609242A (en) * | 2021-07-26 | 2023-02-01 | Vodafone Group Services 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 |
US20230107962A1 (en) * | 2021-10-01 | 2023-04-06 | TrustFour Technologies, Inc. | Mutual Key Management Service System and Method |
US11941266B2 (en) | 2021-10-20 | 2024-03-26 | Samsung Electronics Co., Ltd. | Resource isolation in computational storage devices |
EP4187845A1 (fr) * | 2021-11-25 | 2023-05-31 | Sandvik Mining and Construction Oy | Authentification d'utilisateur dans un système industriel |
US20230367575A1 (en) * | 2022-05-13 | 2023-11-16 | Micron Technology, Inc. | Techniques for managing offline identity upgrades |
US11709660B1 (en) | 2022-10-12 | 2023-07-25 | Stodge Inc. | Integrated third-party application builder trigger for message flow |
Family Cites Families (147)
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 |
WO2000068856A2 (fr) * | 1999-05-11 | 2000-11-16 | Webvan Group, Inc. | Systeme et procede de livraison active par commerce electronique |
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 (fr) * | 2001-06-21 | 2003-01-02 | Koninklijke Philips Electronics N.V. | Dispositif pour l'échange de données, et procédé de fabrication |
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 |
FI20030943A (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 |
WO2006085207A1 (fr) | 2005-02-11 | 2006-08-17 | Nokia Corporation | Procede et dispositif permettant de fournir des procedures d'amorçage dans un reseau de communication |
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 (fr) * | 2005-12-01 | 2007-06-07 | Nokia Corporation | Authentification dans des réseaux de communications |
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 (fr) | 2007-06-27 | 2008-12-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Procédé et appareil permettant la connectivité dans un réseau de communication |
WO2009004590A2 (fr) | 2007-07-03 | 2009-01-08 | Nokia Siemens Networks Oy | Procédé, dispositif, système et programme informatique pour fournir des paramètres de clé |
US8201219B2 (en) * | 2007-09-24 | 2012-06-12 | Bridgewater Systems Corp. | Systems and methods for server load balancing using authentication, authorization, and accounting protocols |
EP2210436A1 (fr) * | 2007-10-05 | 2010-07-28 | InterDigital Technology Corporation | Technique de découpage en canaux sécurisé entre une uicc et un terminal |
US7984486B2 (en) | 2007-11-28 | 2011-07-19 | Nokia Corporation | Using GAA to derive and distribute proxy mobile node home agent keys |
WO2009080095A1 (fr) * | 2007-12-19 | 2009-07-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Procédé et appareil destinés à être utilisés dans un réseau de communication |
EP2245829B1 (fr) * | 2008-01-18 | 2016-01-06 | InterDigital Patent Holdings, Inc. | Procede permettant une communication machine-machine |
US8090963B2 (en) * | 2008-02-19 | 2012-01-03 | Research In Motion Limited | Automated power management of a peripheral device |
CN102047268A (zh) * | 2008-04-15 | 2011-05-04 | 温科·昆茨 | 降低非接触式卡询问器中收到的信号中噪声的方法和执行所述方法的电路 |
PL2528268T6 (pl) * | 2008-06-06 | 2022-04-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Generowanie klucza kryptograficznego |
EP2308254B1 (fr) * | 2008-07-31 | 2014-06-18 | Telefonaktiebolaget L M Ericsson (PUBL) | Méthodes, noeuds, système, logiciel et produits de logiciel pour abonnement ou régistration sécurisés d'utilisateurs |
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 (fr) * | 2008-10-10 | 2010-04-15 | Telefonaktiebolaget L M Ericsson (Publ) | Appareil de passerelle, serveur d'authentification, son procédé de commande et programme d'ordinateur |
US8578153B2 (en) * | 2008-10-28 | 2013-11-05 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for provisioning and managing a device |
EP2187592A1 (fr) | 2008-11-13 | 2010-05-19 | Vodafone Holding GmbH | Dispositif de communication entre machines et carte intelligente à utiliser dans le dispositif |
US20100199095A1 (en) * | 2009-01-30 | 2010-08-05 | Texas Instruments Inc. | Password-Authenticated Association Based on Public Key Scrambling |
US20110010543A1 (en) | 2009-03-06 | 2011-01-13 | 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 (fr) | 2009-06-02 | 2014-02-26 | Vodafone Holding GmbH | Échange de données avec un dispositif homme-machine utilisant une communication radio à courte distance |
EP2259610B1 (fr) * | 2009-06-02 | 2012-08-08 | Vodafone Holding GmbH | Enregistrement d'un dispositif mobile dans un réseau de communication mobile |
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 (fr) * | 2009-10-16 | 2018-12-12 | Tekelec, Inc. | Procédés, systèmes, et supports lisibles par ordinateur pour fournir un routeur de signalisation diameter avec fonction de surveillance et/ou de pare-feu intégrée. |
US8782743B2 (en) * | 2009-11-24 | 2014-07-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and apparatus for use in a generic bootstrapping architecture |
EP2336986A1 (fr) | 2009-12-17 | 2011-06-22 | Gemalto SA | Procédé de personnalisation d'une application intégrée dans un jeton électronique sécurisé |
US20120239936A1 (en) * | 2009-12-18 | 2012-09-20 | Nokia Corporation | Credential transfer |
EP2343916B1 (fr) | 2010-01-12 | 2018-05-09 | Koninklijke KPN N.V. | Couplage sécurisé de composants de matériel |
EP2524532B1 (fr) | 2010-01-14 | 2016-09-21 | Nokia Solutions and Networks Oy | Procédé et dispositif de traitement de données dans un réseau sans fil |
DE102010001076A1 (de) | 2010-01-21 | 2011-07-28 | PMDTechnologies GmbH, 57076 | Induktiver Näherungssensor und Verfahren zur Näherungsmessung |
WO2011092138A1 (fr) | 2010-01-28 | 2011-08-04 | Koninklijke Kpn N.V. | Authentification efficace des terminaux dans des réseaux de télécommunication |
KR101684753B1 (ko) * | 2010-02-09 | 2016-12-08 | 인터디지탈 패튼 홀딩스, 인크 | 신뢰적인 연합 아이덴티티를 위한 방법 및 장치 |
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 (fr) * | 2010-03-15 | 2011-09-22 | Samsung Electronics Co., Ltd. | Procédé et système pour la fourniture d'informations sécurisée et à distance à une carte de circuit intégré universelle d'un équipement d'utilisateur |
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 (fr) * | 2010-04-19 | 2011-10-27 | Nokia Siemens Networks Oy | Procédures d'authentification gba et ims |
US8661257B2 (en) * | 2010-05-18 | 2014-02-25 | Nokia Corporation | Generic bootstrapping architecture usage with Web applications and Web pages |
US9143324B2 (en) * | 2010-06-07 | 2015-09-22 | Protected Mobility, Llc | Secure messaging |
US9602277B2 (en) * | 2010-06-07 | 2017-03-21 | Protected Mobilty, Llc | User interface systems and methods for secure message oriented communications |
CN102299797A (zh) * | 2010-06-23 | 2011-12-28 | 财团法人工业技术研究院 | 认证方法、密钥分配方法及认证与密钥分配方法 |
US9736873B2 (en) * | 2010-06-25 | 2017-08-15 | Interdigital Patent 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 (fr) * | 2010-12-06 | 2012-06-06 | Gemalto SA | Procédés et système pour la manipulation de données d'une UICC |
KR20120067459A (ko) * | 2010-12-16 | 2012-06-26 | 삼성전자주식회사 | 서비스 제공업체와 이동망 사업자간의 기기간 단말별 서비스 인증 방법 및 장치 |
CN102595389B (zh) * | 2011-01-14 | 2017-11-03 | 中兴通讯股份有限公司 | 一种mtc服务器共享密钥的方法及系统 |
WO2012113136A1 (fr) * | 2011-02-22 | 2012-08-30 | Renesas Mobile Corporation | Procédé et appareil pour établir une connexion dispositif à dispositif |
EP2679073A4 (fr) * | 2011-02-25 | 2016-10-19 | Ericsson Telefon Ab L M | Autorisation de communication ip avec un dispositif de machine à machine |
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 |
CN102204217A (zh) * | 2011-05-30 | 2011-09-28 | 华为技术有限公司 | 通知网络能力的方法、装置和系统 |
JP2013005430A (ja) | 2011-06-15 | 2013-01-07 | Lg Electronics Inc | 無線通信システムにおけるデータ送信方法及び装置 |
CN102869015B (zh) * | 2011-07-04 | 2017-12-15 | 中兴通讯股份有限公司 | 一种mtc设备触发的方法和系统 |
GB2492750A (en) | 2011-07-04 | 2013-01-16 | Sony Corp | Communications system with reconfigurable user identification module |
US8989091B2 (en) * | 2011-07-15 | 2015-03-24 | Telefonaktiebolaget L M Ericsson (Publ) | Dynamic enablement of M2M services over 3GPP 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 |
KR101612648B1 (ko) | 2011-10-03 | 2016-04-26 | 엘지전자 주식회사 | Sms에 관련된 신호를 처리하는 이동성 관리 개체 |
CN105577364B (zh) | 2011-10-27 | 2019-11-05 | 华为技术有限公司 | 一种加密方法、解密方法和相关装置 |
SG11201401209SA (en) * | 2011-10-31 | 2014-07-30 | Ericsson Telefon Ab L M | 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设备及其实现业务的方法、智能卡和通信模组 |
WO2013113162A1 (fr) * | 2012-02-02 | 2013-08-08 | Nokia Siemens Networks Oy | Amorçage basé sur un groupe dans une communication de type machine |
EP2815590B1 (fr) * | 2012-02-13 | 2016-12-21 | Telefonaktiebolaget LM Ericsson (publ) | Activation de services m2m sur des réseaux d'accès |
CN104205898A (zh) | 2012-02-16 | 2014-12-10 | 诺基亚通信公司 | 用于m2m环境中基于群组的服务引导的方法和系统 |
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 | 华为技术有限公司 | 一种计费的方法及装置 |
US10097646B2 (en) * | 2012-06-22 | 2018-10-09 | Lg Electronics Inc. | Method and device for enabling or disabling server in wireless communication system |
JP5946968B2 (ja) * | 2012-09-03 | 2016-07-06 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | 3gppネットワークのマシン型デバイスにおいて使用される外部識別子を自動で提供する方法及び装置 |
US20140067902A1 (en) * | 2012-09-04 | 2014-03-06 | 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 |
US20150229620A1 (en) * | 2012-09-13 | 2015-08-13 | Nec Corporation | Key management in machine type communication system |
US9872169B2 (en) * | 2012-09-14 | 2018-01-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Operating a data back end node in a data layered architecture network |
WO2014051558A1 (fr) * | 2012-09-26 | 2014-04-03 | Empire Technology Development Llc | Identification de secret partagé pour une communication sécurisée |
CN104303454B (zh) * | 2012-10-30 | 2018-07-20 | Lg电子株式会社 | 认证对无线通信系统中的特定资源的访问授权的方法 |
KR101538424B1 (ko) * | 2012-10-30 | 2015-07-22 | 주식회사 케이티 | 결제 및 원격 모니터링을 위한 사용자 단말 |
WO2014069968A1 (fr) * | 2012-11-05 | 2014-05-08 | 엘지전자 주식회사 | Procédé et appareil de mise à jour d'informations concernant des ressources spécifiques dans un système de communication sans fil |
US20140126548A1 (en) * | 2012-11-05 | 2014-05-08 | Qualcomm Incorporated | Dynamic paging channel selection in a machine-to-machine wireless wide area network |
CN103812644B (zh) * | 2012-11-09 | 2017-04-26 | 华为终端有限公司 | 一种信息配置方法、设备及系统 |
EP2741465B1 (fr) * | 2012-12-04 | 2021-03-17 | Orange | Procédé et dispositif pour gérer des communications sécurisées dans des environnements de réseau dynamique |
US9615346B2 (en) * | 2012-12-05 | 2017-04-04 | Lg Electronics Inc. | Method and apparatus for notifying information change in wireless communication system |
EP2932680A1 (fr) | 2012-12-12 | 2015-10-21 | Interdigital Patent Holdings, Inc. | Systèmes indépendants de gestion d'identité |
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 |
EP2950497B1 (fr) * | 2013-01-18 | 2018-03-07 | LG Electronics Inc. | Procédé et appareil de contrôle d'accès dans un système de communication sans fil |
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 |
CN105009617B (zh) | 2013-03-08 | 2020-01-21 | 诺基亚技术有限公司 | 用于有嵌入的sim功能的多sim设备的方法和装置 |
JP2016518075A (ja) | 2013-04-05 | 2016-06-20 | インターデイジタル パテント ホールディングス インコーポレイテッド | ピアツーピア通信およびグループ通信のセキュリティ保護 |
US9124403B2 (en) * | 2013-04-30 | 2015-09-01 | Qualcomm Incorporated | Puncturing scheme based decoder optimizations |
EP3557894B1 (fr) | 2013-05-06 | 2023-12-27 | Convida Wireless, LLC | Déclenchement de dispositifs |
US20150019686A1 (en) * | 2013-07-12 | 2015-01-15 | Seven Networks, Inc. | Distributed caching systems with configurable extended caching optimization |
EP3025483B1 (fr) * | 2013-07-25 | 2022-09-21 | Convida Wireless, LLC | Sessions point-à-point de couche de services |
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 |
GB2586549B (en) | 2013-09-13 | 2021-05-26 | 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 |
EP3069545B1 (fr) * | 2013-11-15 | 2018-08-08 | Telefonaktiebolaget LM Ericsson (publ) | Procédés et dispositifs d'amorçage de dispositifs sous contraintes de ressources |
-
2014
- 2014-05-30 GB GB2016853.0A patent/GB2586549B/en active Active
- 2014-05-30 GB GB1409663.0A patent/GB2518257A/en not_active Withdrawn
- 2014-05-30 GB GB1409643.2A patent/GB2518255A/en not_active Withdrawn
- 2014-05-30 GB GB1409641.6A patent/GB2518254B/en active Active
- 2014-05-30 GB GB1409652.3A patent/GB2518256A/en not_active Withdrawn
- 2014-08-22 GB GB1414997.5A patent/GB2518521A/en not_active Withdrawn
- 2014-08-22 GB GB1414999.1A patent/GB2518522B/en active Active
- 2014-08-22 GB GB1415003.1A patent/GB2518296B/en active Active
- 2014-09-09 GB GB1415925.5A patent/GB2519429B/en active Active
- 2014-09-09 GB GB1415918.0A patent/GB2518975B/en active Active
- 2014-09-09 GB GB1415927.1A patent/GB2518976B/en active Active
- 2014-09-09 GB GB1415931.3A patent/GB2520591B/en active Active
- 2014-09-09 GB GB2012632.2A patent/GB2584371B/en active Active
- 2014-09-09 GB GB2012324.6A patent/GB2583432B/en active Active
- 2014-09-09 GB GB1415921.4A patent/GB2518301B/en active Active
- 2014-09-12 EP EP14776684.4A patent/EP3044982B1/fr active Active
- 2014-09-12 US US15/021,873 patent/US10439991B2/en active Active
- 2014-09-12 US US15/021,913 patent/US10313308B2/en active Active
- 2014-09-12 WO PCT/GB2014/052772 patent/WO2015036777A1/fr active Application Filing
- 2014-09-12 US US15/021,900 patent/US20160234183A1/en not_active Abandoned
- 2014-09-12 EP EP20195438.5A patent/EP3767984B1/fr active Active
- 2014-09-12 WO PCT/GB2014/052777 patent/WO2015036782A1/fr active Application Filing
- 2014-09-12 US US15/021,912 patent/US10305862B2/en active Active
- 2014-09-12 EP EP14777373.3A patent/EP3044975B8/fr active Active
- 2014-09-12 US US15/021,881 patent/US20160234683A1/en not_active Abandoned
- 2014-09-12 US US15/021,871 patent/US10673820B2/en active Active
- 2014-09-12 US US15/021,910 patent/US9635057B2/en active Active
- 2014-09-12 WO PCT/GB2014/052784 patent/WO2015036789A2/fr active Application Filing
- 2014-09-12 EP EP14771950.4A patent/EP3044934A2/fr not_active Withdrawn
- 2014-09-12 EP EP20209753.1A patent/EP3800862B1/fr active Active
- 2014-09-12 WO PCT/GB2014/052778 patent/WO2015036783A1/fr active Application Filing
- 2014-09-12 EP EP14776682.8A patent/EP3044973B1/fr active Active
- 2014-09-12 CN CN201480062205.0A patent/CN105706469B/zh active Active
- 2014-09-12 US US15/021,876 patent/US20160226828A1/en not_active Abandoned
- 2014-09-12 ES ES20209753T patent/ES2933426T3/es active Active
- 2014-09-12 WO PCT/GB2014/052786 patent/WO2015036791A1/fr active Application Filing
- 2014-09-12 WO PCT/GB2014/052768 patent/WO2015036773A2/fr active Application Filing
- 2014-09-12 WO PCT/GB2014/052766 patent/WO2015036771A1/fr active Application Filing
- 2014-09-12 US US15/021,885 patent/US10630646B2/en active Active
- 2014-09-12 US US15/021,888 patent/US10412052B2/en active Active
- 2014-09-12 ES ES14776684T patent/ES2893353T3/es active Active
- 2014-09-12 WO PCT/GB2014/052788 patent/WO2015036793A1/fr active Application Filing
- 2014-09-12 EP EP21163810.1A patent/EP3855701A1/fr active Pending
- 2014-09-12 EP EP14772418.1A patent/EP3044927A1/fr not_active Withdrawn
- 2014-09-12 US US15/021,879 patent/US10313307B2/en active Active
- 2014-09-12 EP EP14777374.1A patent/EP3044976B1/fr active Active
- 2014-09-12 EP EP14777371.7A patent/EP3044985A1/fr not_active Withdrawn
- 2014-09-12 WO PCT/GB2014/052780 patent/WO2015036785A1/fr active Application Filing
- 2014-09-12 WO PCT/GB2014/052773 patent/WO2015036778A1/fr active Application Filing
- 2014-09-12 EP EP14776681.0A patent/EP3044983B1/fr active Active
- 2014-09-12 EP EP14777370.9A patent/EP3044928B1/fr active Active
- 2014-09-12 EP EP14777372.5A patent/EP3044974A1/fr not_active Withdrawn
- 2014-09-12 WO PCT/GB2014/052771 patent/WO2015036776A1/fr active Application Filing
- 2014-09-12 WO PCT/GB2014/052767 patent/WO2015036772A1/fr active Application Filing
- 2014-09-12 EP EP14776683.6A patent/EP3044984B1/fr active Active
- 2014-09-12 EP EP21154414.3A patent/EP3832982B1/fr active Active
-
2017
- 2017-04-25 US US15/496,860 patent/US10764252B2/en active Active
-
2019
- 2019-03-19 US US16/357,727 patent/US11044234B2/en active Active
-
2020
- 2020-03-17 US US16/821,378 patent/US11063912B2/en active Active
Non-Patent Citations (1)
Title |
---|
None * |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11044234B2 (en) | Communicating with a device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20160408 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20190923 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
INTG | Intention to grant announced |
Effective date: 20200918 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 29/06 20060101ALI20200908BHEP Ipc: H04W 4/14 20090101ALI20200908BHEP Ipc: H04W 12/04 20090101ALI20200908BHEP Ipc: H04W 28/08 20090101ALI20200908BHEP Ipc: H04W 80/06 20090101ALI20200908BHEP Ipc: H04W 12/02 20090101AFI20200908BHEP Ipc: H04W 88/06 20090101ALI20200908BHEP Ipc: H04W 88/02 20090101ALI20200908BHEP Ipc: G06F 13/28 20060101ALI20200908BHEP Ipc: H04W 4/70 20180101ALI20200908BHEP Ipc: H04W 52/02 20090101ALI20200908BHEP Ipc: H04W 12/00 20090101ALI20200908BHEP Ipc: H04W 4/12 20090101ALI20200908BHEP Ipc: G06F 13/40 20060101ALI20200908BHEP Ipc: H04L 29/08 20060101ALI20200908BHEP Ipc: H04W 4/50 20180101ALI20200908BHEP Ipc: G06F 13/16 20060101ALI20200908BHEP |
|
GRAJ | Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted |
Free format text: ORIGINAL CODE: EPIDOSDIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 602014078908 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: H04W0012040000 Ipc: H04W0012043100 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
INTC | Intention to grant announced (deleted) | ||
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 29/08 20060101ALI20210127BHEP Ipc: H04L 29/06 20060101ALI20210127BHEP Ipc: G06F 13/28 20060101ALI20210127BHEP Ipc: H04W 80/06 20090101ALI20210127BHEP Ipc: H04W 4/14 20090101ALI20210127BHEP Ipc: H04W 28/08 20090101ALI20210127BHEP Ipc: H04W 52/02 20090101ALI20210127BHEP Ipc: H04W 4/70 20180101ALI20210127BHEP Ipc: G06F 13/40 20060101ALI20210127BHEP Ipc: H04W 12/37 20210101ALI20210127BHEP Ipc: H04W 12/0431 20210101AFI20210127BHEP Ipc: H04W 12/02 20090101ALI20210127BHEP Ipc: G06F 13/16 20060101ALI20210127BHEP Ipc: H04W 88/06 20090101ALI20210127BHEP Ipc: H04W 4/50 20180101ALI20210127BHEP Ipc: H04W 88/02 20090101ALI20210127BHEP Ipc: H04W 4/12 20090101ALI20210127BHEP |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: BOURNE, SOPHIE NICOLE |
|
INTG | Intention to grant announced |
Effective date: 20210209 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602014078908 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: REF Ref document number: 1413765 Country of ref document: AT Kind code of ref document: T Effective date: 20210815 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG9D |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20210721 |
|
REG | Reference to a national code |
Ref country code: GR Ref legal event code: EP Ref document number: 20210402817 Country of ref document: GR Effective date: 20211209 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1413765 Country of ref document: AT Kind code of ref document: T Effective date: 20210721 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20211122 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20211021 Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20211021 Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602014078908 Country of ref document: DE |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20210930 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 |
|
26N | No opposition filed |
Effective date: 20220422 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210912 Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210912 Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210930 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO Effective date: 20140912 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20230920 Year of fee payment: 10 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GR Payment date: 20230921 Year of fee payment: 10 Ref country code: FR Payment date: 20230928 Year of fee payment: 10 Ref country code: DE Payment date: 20230920 Year of fee payment: 10 |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: 732E Free format text: REGISTERED BETWEEN 20231123 AND 20231129 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: IT Payment date: 20230927 Year of fee payment: 10 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210721 |