Secure device to device communication

Abstract

A method for communicating between devices is provided. The method comprises the steps of: a first device generating a first request to communicate with a second device; the first device encrypting the first request with a first key shared between a server and the first device; the server receiving the encrypted first request; in response to the server receiving the encrypted first request the server decrypting the encrypted first request using the first key and generating a first communication key material; the server encrypting the first communication key material using the first key; the first device receiving the first communication key material encrypted using the first key; the first device decrypting the encrypted first communication key material using the first key; the second device generating a second request to communicate with the first device; the second device encrypting the second request with a second key shared between the server and the second device; the server receiving the encrypted second request; in response to the server receiving the encrypted second request the server decrypting the encrypted second request using the second key; the server encrypting the first communication key material using the second key; the second device receiving the first communication key material encrypted using the second key; the second device decrypting the encrypted first communication key material using the second key; and the first device and second device initiating encrypted communications using the first communication key material.

Description

[0001] Secure Device To Device Communication

[0002] Field of the Invention

[0003] The present invention relates to a system and method enabling secure communications between separate devices. The method and system is particularly suitable for constrained devices such as Internet of Things (loT) devices.

[0004] Background of the Invention

[0005] Constrained devices, such as Internet of Things (loT) devices are often numerous, hard-to-reach, and have constrained capabilities (owing to low cost, small size, low processing power and / or limited battery life). Constrained devices may interact securely with a home location register (HLR), which maintains and manages keys shared with each device in a telecommunications network. The HLR can store identity data regarding each device such as its SIM's International Mobile Subscriber Identity (IMSI), Mobile Subscriber ISDN Number (MSISDN), and other authentication keys. The HLR enables the telecommunication network to securely identify subscribers, authenticate them, and provide other services. Keys are shared between the HLR and each device to achieve this functionality.

[0006] Whilst constrained devices may be SIM-enabled and can securely communicate with a core network, using the HLR, the devices typically can’t communicate securely with each other. Not having secure communications between devices can limit certain services, like payments and validation services. Whilst communicating via a third party can take advantage of security infrastructure, this can congest networks and increase latency. Furthermore, it is not easy to add additional security functions to these constrained devices.

[0007] Therefore, there is required a method and system that overcomes these problems.

[0008] 16976109.JAC.JAC of the Invention

[0009] Small, low powered, or otherwise constrained devices may have limited security functionality used to provide them only with secure communications to a server or network component. For example, Internet of Things (loT) devices may include a IIICC, SIM or other hardware security module (HSM) that generates and / or stores keys or key material that is shared with the server or network component. However, in some implementations it may be necessary for individual devices to communicate securely with each other and such constrained devices may not have the capability or resources to share keys between themselves in the same way. For example, the storage capacity may be limited and so it may not be possible to store a large number of keys for different devices. Furthermore, the HSM may only be configured to share keys with a single entity, e.g., between the SIM and an HLR.

[0010] When two or more devices need to communicate with each other (e.g., for the first time), each device separately issues a request to communicate with the other device. The request may include requests to communicate with multiple devices or each pair of devices may have a separate request. Each device encrypts the request using the key shared with the server or network component, e.g., a security control authority (SCA), and sends the encrypted request to the server or network component.

[0011] The server decrypts each request (using the different keys shared with each requesting device) and generates new key material that will be used to secure communications between the requesting devices. This key or communication key material is encrypted or otherwise protected with the keys or cryptographic material shared with each requesting device. Therefore, each device can separately decrypt the communication key material, which is then used directly to secure communications between the devices or the communication key material may be used to generate one or more keys used to initiate communications between the devices.

[0012] The server may send separate messages to each requesting device containing the encrypted key. Preferably, a single message can be encrypted several times with the separate encryptions being wrapped around a message package. The single message package can be sent to one of the requesting devices, which unwraps or decrypts a layer of the message package to recover the communication key material and then passes on

[0013] 16976109.JAC.JAC the partially decrypted message package onto a further requesting device that can decrypt at least a part of the package (and / or pass it on to another device if no part of the package is meant for it). The further requesting device can unwrap or decrypt a further layer of the message package (using its own different key shared with the server) to recover the communication key material. The process can continue with the message package being partially decrypted or unwrapped each time it is passed on until all requesting devices have recovered the communication key material. Therefore, such a process can provide a mesh of devices passing on different (or the same) communication key material.

[0014] The communication key material (or security parameters) may be limited to a single pair of devices or may enable secure communications between more than two devices.

[0015] The server can generate and control the communications keys determining which devices can communicate with each other. This may be based on the requests and other data, for example. Therefore, direct secure communications may be initiated in this way. In an example implementation, a similar process may be used to set up secure broadcasts from a first device to two or more other devices. The broadcast may be one-way communication from the first device to these other devices.

[0016] In accordance with a first aspect there is provided a method for communicating between devices, the method comprising the steps of: a first device generating a first request to communicate with a second device; the first device encrypting the first request with a first key shared between a server and the first device; the server receiving the encrypted first request; in response to the server receiving the encrypted first request the server decrypting the encrypted first request using the first key and generating a first communication key material; the server encrypting the first communication key material using the first key; the first device receiving the first communication key material encrypted using the first key; the first device decrypting the encrypted first communication key material using the first key; the second device generating a second request to communicate with the first device;

[0017] 16976109.JAC.JAC the second device encrypting the second request with a second key shared between the server and the second device; the server receiving the encrypted second request; in response to the server receiving the encrypted second request the server decrypting the encrypted second request using the second key; the server encrypting the first communication key material using the second key; the second device receiving the first communication key material encrypted using the second key; the second device decrypting the encrypted first communication key material using the second key; and the first device and second device initiating encrypted communications using the first communication key material. Therefore, constrained or low power devices can securely communicate with each other without needing to set up shared keys with each other in advance. The server (e.g., a secure control authority) and each device may share a key or keys (or other cryptographic material) in any way. Preferably, key sharing may make use of a IIICC or SIM on each device with the server being within or having access to a telecommunications network having a home location register (HLR). For example, the server may fetch a quintet (RAND, XRES, ALITN, CK, and IK) from a public land mobile network (PLMN) for the particular requesting device.

[0018] Optionally, the step of the server receiving the encrypted first request may further comprise: the first device sending the encrypted first request to the second device; the second device further encrypting the encrypted first request using the second key to form an encrypted request package; the second device sending the encrypted request package to the server; and the server using the second key to decrypt the encrypted request package to receive the encrypted first request. Therefore, devices do not need to be in direct communication with the server and can instead securely request and receive cryptographic material over a mesh-type system. Furthermore, because the package is encrypted in layers, each device can only decrypt messages and key material that is intended for it.

[0019] Optionally, the step of the second device encrypting the second request may further comprise the step of:

[0020] 16976109.JAC.JAC the second device adding the second request to the encrypted first request before further encrypting the encrypted first request to form the encrypted request package, and further wherein the server decrypts the encrypted second request from the encrypted request package. The chain can grow for any number of devices, with each one adding a request to the package and encrypting it with its own key (shared with the server), if necessary.

[0021] Optionally, the server may receive the encrypted second request directly from the second device; and / or the second device receives the first communication key material encrypted using the second key directly from the server. Therefore, at least one device (in a chain of devices) may be in direct communication with the server.

[0022] Optionally, the server may receive the encrypted second request from the second device through an intermediary; and / or the second device receives the encrypted first communication key material from the server through the intermediary. Preferably, the intermediary or intermediate device can pass on messages without any encryption or decryption (e.g., passively).

[0023] Optionally, the server may receive the encrypted first request directly from the first device; and / or the first device receives the first communication key material encrypted using the first key directly from the server.

[0024] Optionally, the server may receive the encrypted first request from the first device through an intermediary; and / or the first device receives the encrypted first communication key material from the server through the intermediary. The same or different intermediaries may pass on messages for each device.

[0025] Optionally, the step of the first device receiving the first communication key material encrypted using the first key may further comprise the steps of: the server using the second key to further encrypt the first communication key material encrypted using the first key to form a first encrypted communication key material package;

[0026] 16976109.JAC.JAC the second device receiving the first encrypted communication key material package; the second device using the second key to decrypt the first encrypted communication key material package to obtain the first communication key material encrypted using the first key; and the second device sending the first communication key material encrypted using the first key to the first device. Therefore, the communication key material can also be passed along a chain of devices as encrypted packages (e.g., as binary large objects - BLOBS) in a similar way to the requests being sent to the server.

[0027] Optionally, the second device may receive the first encrypted communication key material package directly from the server; and / or the second device sends the first communication key material encrypted using the first key directly to the first device.

[0028] Optionally, the second device may receive the first encrypted communication key material package from the server through an intermediary; and / or the second device sends the first communication key material encrypted using the first key to the first device through the intermediary.

[0029] Optionally, where data is sent or received through an intermediary, the intermediary may be an intermediate device. Optionally, multiple intermediate devices may be used. By using an intermediary or intermediate device, additional layers of encryption may be added, or the data may simply be relayed. Thus, the method may be more flexible as security measures may be implemented at the intermediate device improving the efficiency of the method. Additionally, the use of intermediaries can allow for greater distances between devices and / or the server. This may be particularly useful with mobility, logistics, utility metering, and where there is a gateway device for internet communications, for example.

[0030] Optionally, the intermediate device may be of the same type as one or more of: the first device; the second device; and the third device. Optionally, the intermediate device may be one of: the first device; the second device; the third device; and subsequent devices. By using the same type of device, the method may be made more efficient as it reduces the amount of additional processing required. Additionally, this may allow the

[0031] 16976109.JAC.JAC primary device, secondary device, and any subsequent devices to chain requests together improving the efficiency of the method by reducing the total number of connections required by the method.

[0032] Optionally, the intermediate device may be a constrained device. This is of particular benefit when one or more of the primary device, secondary device, and subsequent devices are also constrained devices. Using constrained devices (such as loT devices) together can avoids potential incompatibility between the intermediate device and the other devices and allow the method to be more efficient. Additionally, by using a constrained device the cost of the method may be decreased.

[0033] Optionally, the intermediate device may be a gateway device. This can allow data to flow from one discrete network to another improving the flexibility of the method as the primary device, secondary device, subsequent devices, and / or server need not be on the same network.

[0034] Optionally, the method may further comprise the steps of: the first device generating a third request to communicate with a third device; the first device encrypting the third request with the first key; the server receiving the encrypted third request; in response to the server receiving the encrypted third request the server decrypting the encrypted third request using the first key and generating a second communication key material; the server encrypting the second communication key material using the first key; the first device receiving the second communication key material encrypted using the first key; the first device decrypting the encrypted second communication key material using the first key; the third device generating a fourth request to communicate with the first device; the third device encrypting the fourth request with a third key shared between the server and the third device; the server receiving the encrypted fourth request; in response to the server receiving the encrypted fourth request the server decrypting the encrypted fourth request using the third key; the server encrypting the second communication key material using the third key;

[0035] 16976109.JAC.JAC the third device receiving the second communication key material encrypted using the third key; the third device decrypting the encrypted second communication key material using the third key; and the first device and the third device initiating encrypted communications using the second communication key material. Any number of devices can take part with each device generating separate requests to communicate with any single other device or combined requests being formed with a device requesting communication with more than one other device. The server can accept or deny any of these individual requests (or any part of a compound request).

[0036] Optionally, first communication key material and the second communication key material may be or include the same key. Therefore, each device in a pair (or more) of devices that request communications with each other can receive the same communication key or key material from the server or use the communication key material to derive the same key or keys (e.g., a symmetrical key).

[0037] Optionally, the communications initiated between the first device and the second device and the communications initiated between the first device and the third device may be one way communications with the first device transmitting the same encrypted data to the second device and to the third device. Therefore, a secure broadcast system (one to many) can be implemented. This can increase the security of the method as communications from the second device or third device is limited.

[0038] Optionally, the first request and the third request may be combined before received by the server, and / or the first communication key material and the second communication key material are received by the first device together.

[0039] Optionally, the requests to communicate may include an identifier of the requesting device.

[0040] Optionally, the identifier may be a network application function (NAF) identifier. The identifier may be a NAF ID (i.e., from a generic bootstrapping architecture - GBA system).

[0041] 16976109.JAC.JAC Preferably, the package may be a binary large object (BLOB). Other data and messaging formats may be used.

[0042] Preferably, any or all of the keys of the above methods may be symmetric keys. Improving the efficiency of the method as devices can use the same key for encryption and decryption.

[0043] Optionally, two or more of the keys of the above methods may be the same key. Therefore, multiple devices can use the same key to communicate with each other more efficiently.

[0044] Preferably, the method may further comprise the step of the server determining that communications between the requesting devices are allowed before generating the communication key material. The server may include functionality or rules determining which devices or types of devices are allowed to communicate. A database or data store of allowable pairs of devices may also be maintained.

[0045] Optionally, the method may further comprise the step of the server generating keys to be used when generating communication key material. Preferably, the method may further comprise the step of the server determining that communications between the requesting devices are allowed before generating the keys. The server may include functionality or rules determining which devices or types of devices are allowed to communicate. A database or data store of allowable pairs of devices may also be maintained.

[0046] Preferably, the determination is based on data included in the requests and / or stored rules and / or the type of the requesting devices.

[0047] Preferably, the method may further comprise the step of the server and the first and / or second devices renegotiating the first and / or second keys. This can be done when any keys expire. Determination of expiration may use any suitable method such as timestamps included with the key material or timers within the devices. This improves security as it limits the time for a third party to intercept and decrypt messages.

[0048] 16976109.JAC.JAC Preferably, the first and / or second keys may be renegotiated using the 3GPP (RTM) BEST protocol. Optionally, the protocol outlined in 3GPP (RTM) Technical Specification 33.163 may be used or any other version (including future versions) that generate keys in a similar way. Other protocols may be used.

[0049] Preferably, the first request may further comprise a session identifier that identifies the first device and / or a keyset used to encrypt the first request. The first request is for the first device to request to communicate with the second device. This additional information in the request enables the server to decrypt the request. The server and the first device may have keys shared in advance. Therefore, the server can use this additional information sent with the first request to find or derive the correct keys associated with the first device.

[0050] Preferably, any of the other requests (e.g., from the second, third, fourth or subsequent devices) may also contain session identifiers and / or keyset identifiers so that the server can also decrypt these.

[0051] In accordance with a second aspect, there is provide a server comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the server to: receive a first request from a first device to communicate with a second device, wherein the first request is encrypted with a first key shared between the server and the first device; decrypt the encrypted first request using the first key and generating a first communication key material; encrypt the first communication key material using the first key; send the first communication key material encrypted with the first key to the first device; receive a second request from a second device to communicate with the first device, wherein the second request is encrypted with a second key shared between the server and the second device; decrypt the encrypted second request using the second key; encrypt the first communication key material using the second key; and

[0052] 16976109.JAC.JAC send the first communication key material encrypted with the second key to the second device. The server may be a security control authority (SCA), for example. This may be within or in communication with a telecommunications network (e.g., 2G, 3G, 4G, LTE, 5G, 6G, etc.).

[0053] Optionally, sending the first communication key material encrypted with the first key to the first device may be further caused by the computer-executable instructions to: use the second key to further encrypt the first communication key material encrypted using the first key to form a first encrypted communication key material package; and sending the first encrypted communication key material package to the second device to decrypt using the second key and send to the first device.

[0054] In accordance with a third aspect, there is provided a system comprising: the server described above, a first device comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the first device to: generate the first request to communicate with the second device; encrypt the first request with the first key; send the encrypted first request; receive the first communication key material encrypted using the first key; and decrypt the encrypted first communication key material using the first key; and a second device comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the second device to: generate the second request to communicate with the first device; encrypt the second request with the first key; send the encrypted second request; receive the first communication key material encrypted using the second key; and

[0055] 16976109.JAC.JAC decrypt the encrypted first communication key material using the first key, wherein the computer-executable instructions of the first and second devices further cause the first device and second device to initiate encrypted communications using the first communication key material. Further devices may be included in the system with similar functionality.

[0056] 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, including a non-transitory computer-readable medium.

[0057] The computer system may include a processor or processors (e.g., local, virtual or cloud-based) such as a Central Processing Unit (CPU), and / or a single or a collection of Graphics Processing Units (GPUs). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and nonvolatile storage medium. A computer-readable medium (CRM) may be included to store the logic or program instructions. For example, embodiments may include a non-transitory computer-readable medium (CRM) storing software comprising instructions executable by one or more computers which, upon such execution, cause the one or more computers to perform the disclosed methods. Non-transitory CRM may refer to a CRM that stores data for short periods or in the presence of power such as a memory device or Random Access Memory (RAM). For example, a non-transitory computer-readable medium may include storage components, such as, a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, and / or a magnetic tape. 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 operating system such as UNIX (RTM), Windows (RTM) or Linux (RTM), for example.

[0058] It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention.

[0059] 16976109.JAC.JAC Brief description of the Fi

[0060] The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

[0061] FIG. 1 shows a flowchart of a method for providing secure communications between devices, using a server to securely provide keys;

[0062] FIG. 2 shows a schematic diagram of a computer system used to implement the method of Figure 1 .

[0063] FIG. 3 shows a flowchart of a further method for providing secure communications between devices;

[0064] FIG. 4 shows a schematic diagram of a first example system comprising the devices and server of Figure 1 ;

[0065] FIG. 5 shows a schematic diagram of a second example system comprising the devices and server of Figure 1 ;

[0066] FIG. 6 shows a schematic diagram of a third example system comprising the devices and server of Figure 1 ;

[0067] FIG. 7 shows a schematic diagram of a fourth example system comprising the devices and server of Figure 1 ;

[0068] FIG. 8 shows a schematic diagram of a fifth example system comprising the devices and server of Figure 1 ; and

[0069] FIG. 9 shows a schematic diagram of a sixth example system comprising the devices and server of Figure 1 .

[0070] It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals. Detailed description of the preferred embodiments

[0071] Figure 1 shows a flowchart of a method 10 for securely communicating between devices, e.g., constrained devices such as Internet of Things (loT) devices. In the example implementation of Figure 1 only two devices are mentioned (first device and second device). However, the method 10 may be extended to any higher number of devices with pairs of devices communicating with each other (excluding other devices because they do not share keys) or with one device securely communicating with more than one other device using the same key.

[0072] 16976109.JAC.JAC At step 20, the first device generates a request (first request) to communicate (or to obtain a key to enable communication) with the second device. The request may contain different types of data and take different forms. For example, it may contain an identifier of the first device and / or the second device or other data that can be used to derive these identifiers. The first device and a server, e.g., a secure control authority (SCA), and the first device share a key (first key), key material or cryptographic material so that they can communicate (e.g., the requests and responses) securely. The key may be shared in advance of deployment (e.g., in a factory), using keys within a UICC or SIM, or using another mechanism, e.g., provisioned using generic bootstrapping architecture (GBA) or 3GPP BEST Protocol (3GPP TS 33.163). The first request is encrypted by the first device at step 25 and the server receives the encrypted first request at step 30.

[0073] The encrypted first request may be sent directly from the first device to the server or may be transmitted through one or more intermediaries (e.g., the second or another device). The server decrypts the encrypted first request using the first key at step 35. If no key or communication key material has been generated for communications between the first and second device (or if this material has expired, not been stored, or has been deleted), then this is done at step 40.

[0074] The communication key material is encrypted using the first key (step 45) and sent to the first device, which receives it at step 50. The first device decrypts the encrypted communication key material using the first key at step 55.

[0075] A similar process takes place between the server and the second device. In other words, both first and second devices generate requests to communicate with each other and the server provides a specific communication key material to do so (for communications between the two devices) but transmits this communication key material protected using different shared keys (specific to each device).

[0076] In summary, at step 60, the second device generates a request (second request) to communicate (or to obtain a key or key material to enable communication) with the first device. At step 65, the second request is encrypted by the second device at step 65 and the server receives the encrypted second request at step 70. The server decrypts the encrypted second request using the second key at step 75. As in this example, the first

[0077] 16976109.JAC.JAC device has already requested the communication key material, and so it has already been generated (or remains valid). The communication key material is encrypted or protected using the second key (step 80) and sent to the second device, which receives it at step 85. The second device decrypts the encrypted communication key material using the second key at step 90. Communications can now be initiated between the first and second devices, which are secured by the communication key material (step 95).

[0078] The first and second requests may be generated and sent in any order. When the server receives either of these requests first it may generate the communication key material (if not already done). The server can store the communication key material (for a specific pair of devices) or regenerate new key material on subsequent occasions for a new communication session (e.g., following a communication key material expiration event). The method 10 may be implemented by one or more computer systems, including each device and the server.

[0079] As shown in Figure 2, the computer system 100 includes a number of components including communication interfaces 120, system circuitry 130, input / output (I / O) circuitry 140, display circuitry and interfaces 150, and a datastore 170. The system circuitry 120 can include one or more processors or CPUs 180 and memory 190. The system circuitry 130 may include any combination of hardware, software, firmware, and / or other circuitry. The system circuitry 130 may be implemented, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), microprocessors, and / or analogue and digital circuits.

[0080] The display circuitry may provide one or more graphical user interfaces (GUIs) 160 and the I / O interface circuitry 140 may include touch sensitive or non-touch displays, sound, voice or other recognition inputs, buttons, switches, speakers, sounders, and other user interface elements. The devices may not require GUIs or displays. In example implementations, no display or GUI is included (especially in the devices). The I / O interface circuitry 140 may include microphones, cameras, headset and microphone input / output connectors, Universal Serial Bus (USB) connectors, and SD or other memory card sockets. The I / O interface circuitry 140 may further include data media interfaces (e.g., a CD-ROM or DVD drive) and other bus and display interfaces.

[0081] 16976109.JAC.JAC The memory 190 may include volatile (RAM) or non-volatile memory (e.g., ROM or Flash memory). The memory may store the operating system 192 of the computer system 100, applications or software 194, dynamic data 196, and / or static data 198. The datastore or data source 170 may include one or more databases 172, 174 and / or a file store or file system, for example.

[0082] Figure 3 shows a flowchart of a method 200 provided as an example implementation. The method 200 provides additional details to the method 10 described with reference to Figure 1 . The method is illustrated over several pages with dashed boxes illustrating which entity carries out each set of the steps (device or server). The first and last sections of the figure illustrate steps carried out by the devices. The middle section of the figure illustrates steps carried out by the server (SCA).

[0083] As with the method 10 described with reference to Figure 1 , the method 200 starts by each device generating and encrypting a device-to-device communication request. This request is sent to the server (SCA). The SCA receives the encrypted request together with an identifier of the requesting device, e.g., an international mobile subscriber identity (IMSI). The SCA decrypts and processes the request. In this example implementation, processing of the request involves steps to determine if communications are allowed between the two (or more) devices. This determination may be based on a list of allowed pairs of devices, business rules, or other data, such as the type or original of the devices that are requesting communication. If communication is not allowed, the request (message) may be ignored or a rejection response may be issued to the requesting device.

[0084] In this example implementation, communications sessions may be maintained between devices with each session requiring a new key (or key material) and new session identifier. If a previous session is still active or valid then existing key material may be used and sent (encrypted) to the requesting device(s). If a new session is required (e.g., because this is the first time that this pair of devices have requested to communicate or if a previous session has reached its expiry time) then a new communication (session) key or key material can be generated.

[0085] Steps for generating the new communication (session) key material start with the SCA fetching a quintet (RAND, XRES, ALITN, CK, and IK) from a public land mobile network (PLMN). This can require interaction with a home subscriber server (HSS), HLR,

[0086] 16976109.JAC.JAC or another authentication centre (AuC). The communication (session) key material may include or be based on the cipher key (CK) and integrity key (IK) and recovered using RAND, ALITN, e.g., to determine security parameters. The session identifier, CK and IK may be stored so that the security parameters can be retrieved or regenerated.

[0087] The communication key material is encrypted using keys shared with the requesting device (e.g., within an existing session of the initial request). If a new session (between requesting devices) is required then the encrypted security parameters may be sent with the new session ID, new RAND, and new ALITN.

[0088] If an existing valid session exists, then it is not necessary to generate a new session identifier and communication (session) key material. Instead, only the existing (retrieved) security parameters need to be sent in encrypted form (e.g., within the session of the request).

[0089] The encrypted response is received by each device. If new RAND and ALITN are included in the request, then the IIICC o SIM within the device can use these to recover CK and IK. If an existing session is active and no new RAND and ALITN are received, then CK and IK can be recovered from the current session ID. In any case, a derivation function within each device is used to generate communication keys from CK and IK. The communication keys are used to secure communications between the devices.

[0090] Figure 4 to 9 illustrate different architectures for implementing the methods 10, 200 described with reference to Figures 1 and 3. Each architecture or example implementation provides a mechanism for devices (1 , 2, 3, 4, ...n) to communication with each other in different combinations. However, they all share the process of devices requesting communications with one or more other devices by sending encrypted requests and receiving encrypted responses individually targeted to each device.

[0091] The different architectures provide the following attributes. The system provides secure communications of some or all data and signalling between two or more devices directly, where at least one of the devices has access to the SCA. Secure communication of some or all data and signalling between two devices may also be achieved through a third device, where at least one end device has access to the SCA. Secure communication of some or all data and signalling between two devices may also be achieved through a

[0092] 16976109.JAC.JAC third device, where the third device has access to the SCA. Secure communication of some or all data and signalling between two devices may also be achieved through n devices, where at least one of the n devices has access to the SCA. Secure Broadcast communication may be provided between one and many devices, where the receiving devices have either direct or indirect access to the SCA.

[0093] In these example implementations both (or all) of the end devices have a UICC, SIM or HSM (used to generate master keys or otherwise process cryptographic material). Intermediate devices are described in some example implementations to pass on messages but do not need a SIM or HSM. The SCA is used to authorise aspects of the security and to provide keys and other data (e.g. identities, counters, key types, security parameters...) securely to both end parties.

[0094] The negotiated security may be based on PSK. New keys can be derived from the same master keys by either (or all) devices, agreed directly between the end points (devices) using current active security or from an initial starting point by re-running the original process. Once keys have been negotiated, each end device can decide whether new keys can be generated with or without the involvement of the SCA. The security could be for all data and signalling (secure tunnel) or just for selected data or signalling (selective security). For improved efficiency, multiple security associations may be negotiated in the same process. Preferably, the security process may be bearer independent. Preferably, the security protocol may enable flexible use for different topologies.

[0095] The device may be an loT end device. This is an end point for an aspect of the security. In these example implementations each device has a SIM, an interface to communicate with another device, a processor to generate an identity (session ID) known to the SCA, security processing capability, and memory or storage.

[0096] An intermediate device may be a device that provides communication (directly or indirectly) between loT devices and / or the SCA. The SCA is a secure service (on one or more servers) that establishes device identities, authorises whether they may communicate directly based on some criteria, and securely provides the security information and parameters to devices (if allowed). The SCA has access to SIM security data, encryption and decryption functionality, processor, and memory or storage. The SCA may decide on authorisation and can communicate with at least one end device either directly or indirectly.

[0097] 16976109.JAC.JAC The SCA may communicate through intermediate devices. Interfaces may include but are not limited to REST APIs.

[0098] Example implementation 1 is illustrated schematically in Figure 4. Secure communications are established or maintained, where one (or each) end device communicates directly with the SCA. This implementation may be used with mobility payments, logistics (e.g., boarder transactions), and utility metering, for example. Generic bootstrapping architecture (GBA) may be used to share keys between entities (e.g., the end devices and the SCA). Request from any one or more of the devices may further comprise a session identifier that identifies the device (e.g., device id) and / or a keyset used to encrypt the first request. This allows the SCA to decrypt each request.

[0099] The following provides example steps used in this example implementation.

[0100] 1) End device 1 creates a key request (containing a NAF ID) and encrypts it with a valid key known to the SCA by its label.

[0101] 2) End device 1 communicates the encrypted key request (e.g., in the form of a binary large object - BLOB) directly to end device 2.

[0102] 3) End device 2 encrypts the received encrypted key request BLOB together with its own key request that includes an identifier of device 2 (such as IMSI or session ID) with one of its own keys known to the SCA by its label.

[0103] 4) End device 2 sends it directly to the SCA.

[0104] 5) The SCA decrypts the message from end device 2 and the message from end device 1 .

[0105] 6) The SCA determines whether the two end devices are allowed to communicate securely and what parameters should be established.

[0106] 7) The SCA encrypts the security parameters and keys (communication key material) destined for end device 1 , as an encrypted response BLOB 1 (or package).

[0107] 8) The SCA encrypts the encrypted response BLOB for end device 1 and the security parameters and keys destined for end device 2 as an encrypted response BLOB 2.

[0108] 9) The SCA sends the encrypted BLOB 2 to end device 2.

[0109] 10) End device 2 decrypts the encrypted BLOB 2 and stores and / or processes the security parameters and keys destined for end device 2.

[0110] 11 ) End device 2 sends the encrypted BLOB 1 to end device 1 (e.g., as a partially unwrapped package).

[0111] 16976109.JAC.JAC 12) End device 1 decrypts the encrypted BLOB 1 and stores and / or processes the security parameters and keys.

[0112] 13) End device 1 and end device 2 now can communicate securely either everything (secure tunnel) or for selected items (selective security). a) At any time either device may choose to re-negotiate the key being used or negotiate additional keys, without reference to the SCA by using the existing agreed keys (if allowed). b) At any time either device may choose to re-negotiate the key used or negotiate additional keys, by using the SCA, using the process outlined in steps 1 to 12.

[0113] Example implementation 2 is illustrated schematically in Figure 5. This example shows how the method 10 can provide secure communications where both end devices communicate directly with the SCA rather than through each other, as described with the example described with reference to Figure 4. This example implementation may be used with mobility payments and logistics (boarder transactions), for example.

[0114] The following provides example steps used in this example implementation.

[0115] 1 ) End device 1 creates a key request (e.g., containing a device identifier such as IMSI or session ID or other identifier) and encrypts it with a valid key known to the SCA by its label.

[0116] 2) End device 1 communicates the encrypted key request BLOB directly to the SCA as encrypted request BLOB 1 .

[0117] 3) The SCA generates a key response with key materials, session ID and security parameters as encrypted response BLOB 1 .

[0118] 4) The SCA stores the session and key information and sends the encrypted response BLOB 1 to end device 1 directly.

[0119] 5) End Device 1 decrypts and processes the encrypted response BLOB 1 and stores the result for future use.

[0120] 6) When end device 1 needs to secure information with end device 2, end device 1 creates an encrypted key request BLOB 2 using the key materials and session ID stored in step 4 (this may include a device identifier such as IMSI or session ID).

[0121] 7) End device 1 sends the encrypted key request BLOB 2 by any means.

[0122] 16976109.JAC.JAC 8) End device 2 creates encrypted key request BLOB 3 by encrypting encrypted key request BLOB 2 additionally with its own security parameters, with keys and session ID that have already been agreed between the end device 2 and the SCA.

[0123] 9) End device 2 sends the encrypted key request BLOB 3 directly to the SCA.

[0124] 10) The SCA decrypts the encrypted key request BLOB 3 and then encrypted key request BLOB 2.

[0125] 11 ) The SCA verifies the information in the encrypted BLOBs and decides by some mechanism (e.g., stored rules) whether the two devices should be able to communicate directly, including any parameters that should be associated with this secure information.

[0126] 12) The SCA calculates the information (if any) it needs to send to end device 1 and encrypts it with the same security keys and session ID used in step 6. This is encrypted response BLOB 2.

[0127] 13) The SCA calculates the information it needs to send to end device 2 and encrypts it and encrypted response BLOB 2 with the same security keys and session ID used in step 8. This is encrypted response BLOB 3.

[0128] 14) The SCA sends encrypted response BLOB 3 to end device 2.

[0129] 15) The end device 2 decrypts and / or processes and stores the security keys, session ID, and security parameters sent to it by the SCA and sends the encrypted response BLOB 2 (e.g., partially unwrapped package) to end device 1 (by any suitable means).

[0130] 16) End device 1 decrypts and processes encrypted response BLOB 2 and stores the information as required.

[0131] 17) End point 1 and end device 2 can now communicate securely either for all traffic (secure tunnel) or selected items (selective security). a) At any time either device may choose to re-negotiate the key being used or negotiate additional keys, without reference to the SCA by using the existing agreed keys (if allowed). b) At any time either device may choose to re-negotiate the key used or negotiate additional keys, being with reference to the SCA by using the by using the process outlined in steps 1 to 16.

[0132] Example implementation 3 is illustrated schematically in Figure 6. This example shows how the method 10 can provide secure communications where both end devices communicate with the SCA via another device / gateway (e.g., an intermediary device).

[0133] 16976109.JAC.JAC This example implementation may be used with mobility, logistics, utility metering, and where there is a gateway device for internet communications, for example.

[0134] This example implementation is similar to example implementation 2 (shown in Figure 5) except that communication between the end devices and the SCA occurs through a third device or set of devices. The communication bearer can be any suitable bearer for each communications leg. Device 3 (intermediary device) may (or may not) secure the communication between itself and the SCA. Device 3 is typically a gateway device.

[0135] Example implementation 4 is illustrated schematically in Figure 7. This example shows how the method 10 can provide secure communications where end device 2 (or an end of a chain of devices) communicates with the SCA via another device and / or gateway (or collection of devices). This implementation may be used with logistics, energy metering, and mesh solutions, for example.

[0136] This solution is similar to example implementation 1 (and 3) except that communications between end device 2 and the SCA is via one or more gateway or intermediate devices. The communication bearer can be any suitable bearer for each communications leg. Device 3 may (or may not) secure the communication between itself and the SCA. This example implementation provides optimised power and data consumption.

[0137] Example implementation 5 is illustrated schematically in Figure 8. This example shows how the method 10 can provide secure communications where end devices can negotiate multiple security associations at the same time, using the SCA with the end devices in series. This example implementation may be used with mesh solutions, farming, and industrial applications, for example.

[0138] This example implementation is similar to example implementation 1 , except that each end device can determine which other end devices they want to have secure communications with in the same message. Each end device packages and encrypts requests from other devices together with their own request and passes it on to each other end device towards the SCA. On reception of encrypted response BLOBs destined for that end device, the target end device decrypts and process the information itself and distributes on other encrypted response packets for other end devices. The

[0139] 16976109.JAC.JAC communication bearer can be any suitable bearer for each communications leg. This example implementation optimises the power required to setup multiple security associations.

[0140] Example implementation 6 is illustrated schematically in Figure 9. This example shows how the method 10 can provide secure communications for broadcast services from one end point to multiple other end points, using the SCA. Communications with the SCA may be direct or may be through another device or gateway (intermediary device). This example implementation may be used with secure broadcast examples. This example implementation allows end device 1 to securely broadcast information to a plurality of other end devices.

[0141] The following provides example steps used in this example implementation.

[0142] 1 ) End device 1 creates a broadcast key request (containing a device identifier such as IMSI, session ID or other identifier) and encrypts it using a valid key for communication between end device 1 and the SCA (as encrypted BLOB 1 ).

[0143] 2) End device 1 sends the encrypted BLOB 1 directly (or indirectly) to the SCA.

[0144] 3) The SCA decrypts the BLOB and determines whether the requested service is allowed and determines what parameters should be applied.

[0145] 4) The SCA encrypts the security parameters and keys destined for end device 1 as an encrypted response BLOB 1 .

[0146] 5) End device 2 (3,... n) creates a broadcast receive key request (optionally containing a NAF ID or other identifier) and encrypts it using a valid key for communication between end device 2 (3,... n) and the SCA as encrypted BLOB 2 (3,... n).

[0147] 6) The SCA decrypts the BLOB and determines whether the requested service is allowed and determines what parameters should be applied.

[0148] 7) The SCA encrypts the security parameters and keys destined for end device 2 (3,... n) as an encrypted response BLOB 2 (3,... n).

[0149] 8) The SCA sends the encrypted BLOB 2 (3,... n) to end device 2 (3,... n).

[0150] 9) End device 2 (3,... n) decrypts the encrypted BLOB 2 (3,... n) and stores and / or processes the security parameters and keys destined for end device 2 (3,... n).

[0151] 10) End device 1 can now broadcast securely to end device 2 (3,... n) and end device 2 (3,... n) can receive these secured broadcasts either for all broadcast messages (secure tunnel) or for selected items (selective security).

[0152] 16976109.JAC.JAC The steps may be repeated, where indicated, for end devices 3, 4, 5, ... n, for example.

[0153] The method and system may be implemented in hardware, software, or a combination of hardware and software. The method and system may be implemented either as a server comprising a single computer system or as a distributed network of servers connected across a network. Any kind of computer system or other electronic apparatus may be adapted to carry out the described methods.

[0154] As used throughout, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" (such as an ion multipole device) means "one or more" (for instance, one or more ion multipole device). Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including but not limited to", and are not intended to (and do not) exclude other components. Also, the use of “or” is inclusive, such that the phrase “A or B” is true when “A” is true, “B is true”, or both “A” and “B” are true.

[0155] The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the disclosure and does not indicate a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0156] The terms “first” and “second” may be reversed without changing the scope of the disclosure. That is, an element termed a “first” element may instead be termed a “second” element and an element termed a “second” element may instead be considered a “first” element.

[0157] Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed.

[0158] 16976109.JAC.JAC It is also to be understood that, for any given component or embodiment described throughout, any of the possible candidates or alternatives listed for that component may generally be used individually or in combination with one another, unless implicitly or explicitly understood or stated otherwise. It will be understood that any list of such candidates or alternatives is merely illustrative, not limiting, unless implicitly or explicitly understood or stated otherwise.

[0159] Unless otherwise described, all technical and scientific terms used throughout have a meaning as is commonly understood by one of ordinary skill in the art to which the various embodiments described herein belongs.

[0160] As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims.

[0161] For example, whilst the examples and method illustrate two and three end devices with a single SCA, any number of end devices may be added to a system. Furthermore, additional SCAs may be included for load balancing purposes or to service devices of different types or customers.

[0162] Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

[0163] 16976109.JAC.JAC

Claims

- 26 -CLAIMS:1 . A method for communicating between devices, the method comprising the steps of: a first device generating a first request to communicate with a second device; the first device encrypting the first request with a first key shared between a server and the first device; the server receiving the encrypted first request; in response to the server receiving the encrypted first request the server decrypting the encrypted first request using the first key and generating a first communication key material; the server encrypting the first communication key material using the first key; the first device receiving the first communication key material encrypted using the first key; the first device decrypting the encrypted first communication key material using the first key; the second device generating a second request to communicate with the first device; the second device encrypting the second request with a second key shared between the server and the second device; the server receiving the encrypted second request; in response to the server receiving the encrypted second request the server decrypting the encrypted second request using the second key; the server encrypting the first communication key material using the second key; the second device receiving the first communication key material encrypted using the second key; the second device decrypting the encrypted first communication key material using the second key; and the first device and second device initiating encrypted communications using the first communication key material.

2. The method of claim 1 , wherein the step of the server receiving the encrypted first request further comprises: the first device sending the encrypted first request to the second device; the second device further encrypting the encrypted first request using the second key to form an encrypted request package;16976109.JAC.JACthe second device sending the encrypted request package to the server; and the server using the second key to decrypt the encrypted request package to receive the encrypted first request.

3. The method of claim 2, wherein the step of the second device encrypting the second request further comprises the step of: the second device adding the second request to the encrypted first request before further encrypting the encrypted first request to form the encrypted request package, and further wherein the server decrypts the encrypted second request from the encrypted request package.

4. The method according to any previous claim, wherein the server receives the encrypted second request directly from the second device; and / or the second device receives the first communication key material encrypted using the second key directly from the server.

5. The method according to any of claims 1 to 3, wherein the server receives the encrypted second request from the second device through an intermediary; and / or the second device receives the encrypted first communication key material from the server through the intermediary.

6. The method according to any of claims 1 to 3, wherein the server receives the encrypted first request directly from the first device; and / or the first device receives the first communication key material encrypted using the first key directly from the server.

7. The method according to any previous claim, wherein the server receives the encrypted first request from the first device through an intermediary; and / or the first device receives the encrypted first communication key material from the server through the intermediary.

8. The method according to any previous claim, wherein the step of the first device receiving the first communication key material encrypted using the first key further comprises the steps of:16976109.JAC.JACthe server using the second key to further encrypt the first communication key material encrypted using the first key to form a first encrypted communication key material package; the second device receiving the first encrypted communication key material package; the second device using the second key to decrypt the first encrypted communication key material package to obtain the first communication key material encrypted using the first key; and the second device sending the first communication key material encrypted using the first key to the first device.

9. The method of claim 8, wherein the second device receives the first encrypted communication key material package directly from the server; and / or the second device sends the first communication key material encrypted using the first key directly to the first device.

10. The method of claim 8, wherein the second device receives the first encrypted communication key material package from the server through an intermediary; and / or the second device sends the first communication key material encrypted using the first key to the first device through the intermediary.11 . The method according to any previous claim, further comprising the steps of: the first device generating a third request to communicate with a third device; the first device encrypting the third request with the first key; the server receiving the encrypted third request; in response to the server receiving the encrypted third request the server decrypting the encrypted third request using the first key and generating a second communication key material; the server encrypting the second communication key material using the first key; the first device receiving the second communication key material encrypted using the first key; the first device decrypting the encrypted second communication key material using the first key; the third device generating a fourth request to communicate with the first device;16976109.JAC.JAC- 29 - the third device encrypting the fourth request with a third key shared between the server and the third device; the server receiving the encrypted fourth request; in response to the server receiving the encrypted fourth request the server decrypting the encrypted fourth request using the third key; the server encrypting the second communication key material using the third key; the third device receiving the second communication key material encrypted using the third key; the third device decrypting the encrypted second communication key material using the third key; and the first device and the third device initiating encrypted communications using the second communication key material.

12. The method of claim 1 1 , wherein first communication key material and the second communication key material are the same key or include the same key.

13. The method of claim 12, wherein the communications initiated between the first device and the second device and the communications initiated between the first device and the third device are one way communications with the first device transmitting the same encrypted data to the second device and to the third device.

14. The method according to any of claims 1 1 to 13, wherein the first request and the third request are combined before received by the server, and / or the first communication key material and the second communication key material are received by the first device together.

15. The method according to any previous claim, wherein the requests to communicate include an identifier of the requesting device.

16. The method of claim 15, wherein the identifier is a network application function, NAF, identifier.

17. The method according to any of claims 2, 3 or 8 to 10, wherein the package is a binary large object, BLOB.16976109.JAC.JAC- 30 -18. The method according to any previous claim, wherein the keys are symmetric keys.

19. The method according to any previous claim further comprising the step of the server determining that communications between the requesting devices are allowed before generating the communication key material or keys.

20. The method of claim 19, wherein the determination is based on data included in the requests and / or stored rules and / or the type of the requesting devices.21 . The method according to any previous claim further comprising the step of the server and the first and / or second devices renegotiating the first and / or second keys.

22. The method of claim 21 , wherein the first and / or second keys are renegotiated using the 3GPP BEST protocol.

23. The method according to any previous claim, wherein the first request further comprises a session identifier that identifies the first device and / or a keyset used to encrypt the first request.

24. A server comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the server to: receive a first request from a first device to communicate with a second device, wherein the first request is encrypted with a first key shared between the server and the first device; decrypt the encrypted first request using the first key and generating a first communication key material; encrypt the first communication key material using the first key; send the first communication key material encrypted with the first key to the first device; receive a second request from a second device to communicate with the first device, wherein the second request is encrypted with a second key shared between the server and the second device; decrypt the encrypted second request using the second key;16976109.JAC.JAC- 31 - encrypt the first communication key material using the second key; and send the first communication key material encrypted with the second key to the second device.

25. The server of claim 24, wherein sending the first communication key material encrypted with the first key to the first device is further caused by the computer-executable instructions to: use the second key to further encrypt the first communication key material encrypted using the first key to form a first encrypted communication key material package; and sending the first encrypted communication key material package to the second device to decrypt using the second key and send to the first device.

26. A system comprising: the server or claim 24 or claim 25, a first device comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the first device to: generate the first request to communicate with the second device; encrypt the first request with the first key; send the encrypted first request; receive the first communication key material encrypted using the first key; and decrypt the encrypted first communication key material using the first key; and a second device comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the second device to: generate the second request to communicate with the first device; encrypt the second request with the first key; send the encrypted second request; receive the first communication key material encrypted using the second key; and16976109.JAC.JAC- 32 - decrypt the encrypted first communication key material using the first key, wherein the computer-executable instructions of the first and second devices further cause the first device and second device to initiate encrypted communications using the first communication key material.16976109.JAC.JAC

Images