Secure communications for constrained devices

Abstract

Receive, by a software application from a device, a request for a key, data describing the requested key and a requester secret shared with a second server. In response, the software application selec

Description

Field of the Invention The present invention relates to a system and method for securely communicating with constrained devices. In particular, the method and system provide a secure and efficient way for shared keys to be provided to devices that have limited processing and are constrained by particular communication protocols and / or battery power. Background of the Invention Machine to Machine (M2M), Internet of Things (loT), and narrowband loT (NB-loT) devices are often numerous, hard-to-reach, and have constrained capabilities (owing to low cost, small size, low processing power or limited battery life), which includes having limited access to communication protocols, memory and throughput or bandwidth. They all may be considered to be examples of constrained devices. All of this makes their management, often remote, very complicated. Moreover, constrained 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 communicate with them in a secure way, while respecting these constraints. 3GPP generic bootstrapping architecture (GBA) is a protocol based on HTTP, which is based on TCP / IP. Using GBA, a device may obtain data from a bootstrapping server function (BSF) so that a shared secret can be established between the M2M device and a network application function (NAF) with which the M2M device is in communication. The shared secret may then be used by the M2M device and the NAF to establish secure communication. This requires configuration of the devices to support two interfaces, one between the device and the BSF and the other between the device and the NAF, which might each utilise different communications protocols, for example CoAP and HTTP. For example, the interface between the device and the BSF may be based on HTTP, which may require a full browser implementation, and the interface between the device and the BSF may be based on CoAP. Therefore, GBA requires the device to support the internet protocol suite, TCP / IP, which may not be available to all constrained devices (e.g., NT-loT devices). Other authentication process can make use of SMS. For example, a bootstrapping message may be delivered by SMS to initiate secure communications. However, SMS may not be available to constrained devices. 3GPP TS 33.163 BEST (Battery Efficient Secure Transport for MTC devices) provides secure communications with constrained devices. Whilst BEST removes the need for a PKI server and device PKI, it has its own limitations. For example, BEST does not disguise the IMSI of a device at security setup. Therefore, there is required a method and system that overcomes these problems. Summary of the Invention Secure communications between entities (e.g., a device and a server) require cryptographic keys. Provisioning devices in advance with one or more keys is costly and not always convenient for constrained devices. A device has a secure element, such as a universal integrated circuit card (UICC), a SIM or integrated SIM (iSIM) for carrying out secure cryptographic processes. Software on the device provides functionality for obtaining a key or keys that can be used for secure communications with a server or for other uses (e.g., signing messages). The shared key can be used multiple times or refreshed, as necessary (e.g., when it expires or if lost from the memory of the device). A server generates a root of a session identifier. A session identifier is generated by the device using this session identifier root or seed. The session identifier may also include an encrypted or obscured version of an identifier of the device (e.g., its international mobile subscriber identifier or IMSI), a purpose of the session, and / or an application that will use a key or keys generated from the session identifier. The session identifier (e.g., BTID) is used as part of a seed for a new key or keys. As different keys may be required from time to time then the session identifier also includes other components or numbers that preferably change each time (e.g., the counter). This ensures that different keys can be generated without needing to repeat the initial sets of messages to share the session identifier root between the server and the device. The session identifier may include a counter that increments each use, an identifier of a use of the new key (e.g., for messaging, signing, etc.), command options and control pane, an application on the device that will use the key or keys, etc. The seed is transmitted as a message from the device to the server. The session identifier includes a counter so that different keys (e.g., hundreds) may be generated from the same root. An application on the device includes a set of group keys that are common to a plurality of devices. A key amongst the plurality of group keys is selected by the device based on the session identifier root. The device sends a message to the server encrypted using this particular group key. In response, the server sends back an authentication request to the device. This authentication request includes cryptographic material (e.g., RAND and AUTN) that the secure element of the device uses to authenticate the response and the software derives a new key. The new key is based on the cryptographic material and the message (session identifier) sent to the server. The server carries out the same derivation process to generate the same key, as the session identifier (including the session identifier root) is included in the message sent by the device to the server. The message also includes an identifier of the device (e.g., IMSI encrypted using the group key). The server uses the IMSI to retrieve the same cryptographic material (e.g., from a home location register - HLR). Now that the server and the device both have the same key, they can communicate securely until expiry of the key. If the server and the device have already set up an initial key then the cryptographic mater may be used to derive new keys using different session identifiers (e.g., incremented by a counter). The session identifiers should be unique and not repeated between devices. In accordance with a first aspect, there is provided method for sharing keys between a device and a second server, the device having a secure element and a software application comprising a plurality of group keys and associated session identifiers, the method comprising the steps of: the software application receiving from within the device a request for a key, data describing the requested key and a requester secret shared with the second server; in response to the request for the key, the software application selecting one of the plurality of group keys and an associated session identifier; the device sending a message to a first server encrypted using the selected group key, the message including the associated session identifier and an identifier of the secure element; the first server decrypting the message using the group key identified by the associated session identifier; in response to the message the first server: obtaining an authentication vector based on the identifier of the secure element, the authentication vector comprising key materials and an authentication request, generating a request session identifier root, encrypting, using the group key associated with the session identifier, a response formed from the authentication request and the request session identifier root, sending the response to the device, and generating a master key based on the key materials; the software application decrypting the response using the selected group key and sending the authentication request to the secure element; the secure element authenticating the authentication request and when valid generating the key materials from the authentication request and a key stored within the secure element; the software application deriving the master key based on the generated key materials; storing within the device the master key with the request session identifier root; the software application deriving one or more keys based on the master key, the data describing the requested key and the requester secret; the software application generating a key label for each of the one or more keys comprising the session identifier root and the data describing the requested key; the device sending the key label to the second server; the second server sending the key label and the requester secret to the first server; the first server deriving the one or keys based on the master key, the key label and the requester secret; and the first server sending the one or more keys to the second server. This further helps maintain security with constrained devices as a large number of keys does not need to be stored by the device, as these can be generated whenever required. Fewer steps may be included as certain data may be implied or extracted from a single message (including a session identifier). The session identifier root may be a concatenation or different data sets or numbers, for example. Optionally, the secure element may be a UICC, a hardware security module, or an integrated SIM, iSIM. Other secure elements (both software and hardware) may be used. Optionally, the method may further comprise the step of the device and the server securing communications using the one or more keys. The keys may be used for other purposes. A particular purpose identifier may form part of the session identifier. Optionally, the step of the secure element of the device authenticating the response may further comprise the secure element generating a response (RES) based on the key materials and further wherein securing the communications includes sending RES to the server. This can use known cellular and SIM functionality with the secure element being a UICC, SIM or iSIM, for example. Optionally, the communications are secured using advanced encryption standard, AES. Other encryption standards may be used. Optionally, the method may further comprise the step of the device and / or the server signing a message using the one or more keys. The key or keys may be used for other purposes. Optionally, the message and / or the response to the message may be encrypted using any one of: a previously generated key, wherein the message includes a session identifier associated with the previously generated key; or a pre-shared key. This can be done for subsequent key generation after an initial key or keys are agreed. The messages may between the device and the first and / or the second server, which can receive the generated keys from the first server or generate these keys based on material received from the first server, for example. Optionally, the plurality of group keys may be pre-shared keys common to a plurality of separate devices. For example, the group keys may be common to a software application (e.g., prepared by a particular entity providing a service) that is installed on a group of devices. The group keys may form part of the software application, for example. However, each time a group key is used a different one may be selected based on the session identifier. This improves security even though all devices in the group have the same set of group keys. Optionally, the session identifier may include an encrypted identifier of the device. As the identifier of the device is preferably unique then no two devices should generate the same session identifier and so no two devices will generate the same key or keys. Optionally, the encrypted identifier of the device may be the device international mobile subscriber identity (IMSI). Other identifiers may be used. Optionally, the server may obtain the authentication vector from a home location register (HLR) based on the identifier of the device. Therefore, the first and / or second server do not need to store cryptographic material for each device and can instead generate it when needed. Optionally, the message may further comprise an identifier of the serving network and the IMEI of the device. Therefore, this allows the first server to retrieve the key material (within the authentication vector) from the correct HLR. Optionally, a secure hash algorithm, SHA, may be used to derive the one or more keys. For example, this may be the SHA256 function, or any SHA-2 functions. Other hash algorithms may be used. Optionally, the software application may be executed within the secure element of the device or within an application store of the device. Optionally, the derived one or more keys may be stored within the device and associated with the session identifier. The keys may also be generated whenever required to reduce storage requirements. Optionally, the derived one or more keys may be stored within the first and / or second server. The keys may also be generated whenever required or following a particular event or trigger. Optionally, the authentication vector may include RAND and ALITN. Therefore, cellular cryptographic techniques may be used. The authentication vector may also include XRES, keys (CK' and IK') and / or Key Access Security Management Entity (KASME). Optionally, the session identifier may include data indicating a purpose of the one or more key. This adds to the complexity of the session identifier so a larger number of different keys can be generated for the same session identifier root (generated by the server). Optionally, the message may include any one or more of: data indicating a counter incremented each time the session identifier is used; and an identifier of a serving network. The counter may be incremented (by the device) for each use of the session identifier root, use and / or application combination, for example. Optionally, the method may further comprise the step of: repeating the method steps to derive one or more new keys using a different session identifier. The session identifier may be changed based on use, application, and / or counter. According to a second aspect, there is provided a device comprising: a secure element; a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the device to: receive, by a software application from within the device, a request for a key, data describing the requested key and a requester secret shared with a second server; in response to the request for the key, the software application selecting one of the plurality of group keys and an associated session identifier; send a message to a first server encrypted using the selected group key, the message including the associated session identifier and an identifier of the secure element; receive from a first server a response to the message, the response including an authentication request and a request session identifier root; decrypt the response using the selected group key and sending the authentication request to the secure element; the secure element authenticating the authentication request and when valid generating key materials from the authentication request and a key stored within the secure element; derive, by the software application, a master key based on the generated key materials; storing within the device the master key with the request session identifier root; the software application deriving one or more keys based on the master key, the data describing the requested key and the requester secret; the software application generating a key label for each of the one or more keys comprising the session identifier root and the data describing the requested key; and the device sending the key label to the second server. According to a third aspect, there is provided a system comprising: the device, as described above; and a first server comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the first server to: in response to a message received from the device: obtain an authentication vector based on the identifier of the secure element, the authentication vector comprising key materials and an authentication request, generate a request session identifier root, encrypt, using the group key associated with the session identifier, a response formed from the authentication request and the request session identifier root, send a response to the device, generate a master key based on the key materials, receive from a second server a key label and a requester secret, derive the one or keys based on the master key, the key label and the requester secret, and send the one or more keys to the second server. Optionally, the computer-executable instructions may further cause the server to retrieve the authentication vector from a home location register based on an identifier of the device included in a session identifier within the received message. Against this background and in accordance with a further aspect there is provided a method for providing secure communications between a server and a device having a secure element and a software application comprising a plurality of group keys, the method comprising the steps of: the software application generating a session identifier; identifying one of the plurality of group keys based on at least a portion of the session identifier (e.g., all or part of the session identifier or a part of the session identifier provided by the server); the device sending a message to the server encrypted using the identified group key, the message including the session identifier; in response to the message, the server sending the device an authentication request encrypted using the identified group key; the secure element of the device authenticating the response (this can be the response to the message, which is the authentication request); the software application generating cryptographic material based on the message; the device deriving one or more keys based on the cryptographic material and at least a portion of the session identifier; and the server generating the one or more keys derived from the cryptographic material and the at least portion of the session identifier. Therefore, an initial set of keys may be set up between the device and the server to provide secure communications. This initial key or keys can be used to generate new keys, which can be generated using a new session identifier. For subsequent keys, the cryptographic material does not need to be generated as the server and device already have this. However, because the session identifier changes, then new keys can be generated and communications can be secured more effectively. Therefore, the method can repeat (any number of times as long as the session identifier is different) but just with steps: the software application generating a (different) session identifier; identifying one of the plurality of group keys based on at least a portion of the session identifier; the device sending a message to the server encrypted using the identified group key, the message including the session identifier; the device deriving one or more keys based on the cryptographic material and at least a portion of the (different) session identifier; and the server generating the one or more keys derived from the cryptographic material and the at least portion of the (different) session identifier. This further helps maintain security with constrained devices as a large number of keys does not need to be stored by the device, as these can be generate whenever required. Fewer steps may be included as certain data may be implied or extracted from a single message (including a session identifier). The session identifier may be a concatenation or different data sets or numbers, for example. Preferably, the secure element may be a UICC, a hardware security module, or an integrated SIM (iSIM). Other secure elements (both software and hardware) may be used. Advantageously, the method may further comprise the step of the device and the server securing communications using the one or more generated keys. The keys may be used for other purposes. A particular purpose identifier may form part of the session identifier. Optionally, the step of the secure element of the device authenticating the response may further comprise the secure element generating a response (RES) based on the cryptographic material and further wherein securing the communications includes sending the RES to the server. This can use known cellular and SIM functionality with the secure element being a UICC, SIM or iSIM, for example. Optionally, the communications may be secured using advanced encryption standard, AES. Other encryption standards may be used. Optionally, the method may further comprise the step of the device and / or the server signing a message using the one or more keys. The key or keys may be used for other purposes. Optionally, the message and / or the response to the message may be encrypted using any one of: a previously generated key, wherein the message includes a session identifier associated with the previously generated key; or a pre-shared key. This can be done for subsequent key generation after an initial key or keys are agreed. Preferably, the plurality of group keys may be pre-shared keys common to a plurality of separate devices. For example, the group keys may be common to a software application (e.g., prepared by a particular entity providing a service) that is installed on a group of devices. The group keys may form part of the software application, for example. However, each time a group key is used a different one may be selected based on the session identifier. This improves security even though all devices in the group have the same set of group keys. Preferably, the session identifier may include an encrypted identifier of the device. As the identifier of the device is preferably unique then no two devices should generate the same session identifier and so no two devices will generate the same key or keys. Preferably, the encrypted identifier of the device may be the device international mobile subscriber identity (IMSI). Other identifiers may be used. Preferably, the server may obtain the cryptographic material from a home location register (HLR) based on the identifier of the device. Therefore, the server does not need to store cryptographic material for each device and can instead generate it when needed. Optionally, the message may further comprise an identifier of the serving network and the IMEI of the device. Therefore, this allows the server to retrieve the cryptographic material from the correct HLR. Optionally, the secure element of the device or the software application may derive the one or more keys. This may also be done within another component of the device. Optionally, a secure hash algorithm (SHA) is used to derive the one or more keys. For example, this may be the SHA256 function, or any SHA-2 functions. Optionally, the software application may be executed within the secure element of the device or within an application store of the device. Optionally, the derived one or more keys may be stored within the device and associated with the session identifier. The keys may also be generated whenever required to reduce storage requirements. Preferably, the derived one or more keys may be stored within the server. The keys may also be generated whenever required. Preferably, the cryptographic material may include RAND and ALITN. Therefore, cellular cryptographic techniques may be used. Optionally, the session identifier may include data indicating a purpose of the one or more key. This adds to the complexity of the session identifier so a larger number of different keys can be generated for the same session identifier root (generated by the server). Optionally, the software application may generate the session identifier from a session identifier root is received by the device from the server. The root may be uniquely generated by the server so that no two devices receive the same root. Optionally, the message may include any one or more of: data indicating a counter incremented each time the session identifier is used; and / or an identifier of a serving network. The counter may be incremented (by the device) for each use of the session identifier root, use and / or application combination, for example. Optionally, the method may further comprise the step of: repeating the method steps to derive one or more new keys using a different session identifier. The session identifier may be changed based on use, application, and / or counter. Optionally, the data describing the requested key may comprise any one or more of: key number; and / or key usage. These data are sent by the requester (e.g., a customer application) with the request. The data describing the key may include information determined by the requester. For example, this information can include a reason or use for the key (once derived), data determining a key number if multiple keys for the same use are to be generated (e.g., sequentially as an older key expires, a new key with a new number can be requested to replace it) or other information about the key. The data may be provided in a particular format, e.g., based on look-up table. Data encoded in this way can be sent as fewer bits or bytes. Optionally, the key usage may comprise any one or more of: general encryption key; general integrity key; application management key; script protection key; memory protection key; and server key. Other uses for the key may be provided or defined in the request. Optionally, the step of the software application generating a key label may further comprise compressing the data describing the requested key before incorporating it in the key label. For example, the key label may be defined as a code (e.g., two alphanumeric characters) representing attributes of the key label or portions of the key label. Optionally, the step of the first server sending the one or more keys to the second server may further comprise the one or more keys being sent as a REST API response. The keys may be sent in response to an API call or other message. Other types of API may be used. Optionally, the REST API response may further comprises an expiry datetime (date and / or time); and / or data describing the device (e.g., IMSI, key generation date or other data). In accordance with a further aspect, there is provided a device comprising: a secure element; a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the device to: generate a session identifier; identify one of a plurality of group keys within the memory based on at least a portion of the session identifier; send a message to a server encrypted using the identified group key, the message including the session identifier; receive an authentication request from the server, the authentication request including cryptographic material and encrypted using the identified group key; the secure element of the device authenticating the response (e.g., the response to message from the device, which can be the authentication request); generate cryptographic material based on the message; and the device deriving one or more keys from the cryptographic material and at least a portion of the session identifier. In accordance with a further aspect, there is provided a system comprising: the device, as described above; and a server comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the server to: generate a session identifier root; send the generated session identifier root to the device; identify a group key from a plurality of group keys based on the session identifier root; receive a message from the device, the message encrypted using the group key; and generate one or more keys derived from cryptographic material and at least the session identifier root. The one or more keys may also be derived from the cryptographic material (e.g., obtained from a network operator or an HLR of a network operator based on the identity of the device) and further portions (or the whole) of the session identifier. Optionally, the computer-executable instructions may further cause the server to retrieve the cryptographic material from a home location register based on an identifier of the device included in a session identifier within the received message. 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. 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, Windows (RTM) or Linux, for example. It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Brief description of the Figures 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: FIG. 1 shows a flowchart of a method used to secure communications between a device and a server; FIG. 1A shows a flowchart of a further method used to secure communications between a device and a server; FIG. 2 shows a schematic diagram of an example computer system used to implement the method of Figure 1 and Figure 1 A; FIG. 3 shows a schematic diagram of a system including the device and server implementing the method of Figure 1 and Figure 1A; FIG. 4 shows a sequence diagram illustrating the messaging used in the system of Figure 3 and Figure 1A; FIG. 5 shows a schematic diagram illustrating the messaging between the device and the server of Figure 3; FIG. 6 shows a schematic diagram illustrating the messaging between different components of the system of Figure 3; FIG. 7 shows a schematic diagram illustrating the messaging between different components of the system of Figure 3; FIG. 8 shows a table of different data objects used in the method of Figure 1 and Figure 1A; FIG. 9 shows a schematic diagram illustrating the messaging between different components of the system of Figure 3; FIG. 10 shows a comparison of existing messaging and the messaging used in the method of Figure 1 and Figure 1A; FIG. 11 shows a graphical indication of the benefits of the method of Figure 1 and Figure 1A; and FIG. 12 shows a schematic diagram illustrating the format of a session identifier used within the method of Figure 1. 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 A secure element such as a universal integrated circuit card (UICC), a SIM, or an iSIM, contains a unique identifier in the form of an international mobile subscriber identity (IMS I) number and a related key. These are used to identify and authenticate individual mobile subscribers on a telecommunication network. Therefore, the UICC provides a source of trust for the device and the network. As well as using the secure element to authenticate a subscriber with the telecommunication network, the secure element can also carry out other cryptographic functions. Furthermore, they are not limited to use within cell phones but provide security functions within other types of device, such as constrained devices. Therefore, secure elements can both provide access to a communication channel on the telecommunication network and separate security functions. SIM Trust is a set of tools and application programming interfaces (APIs) that allow third parties to make use of such security functionality, which takes advantage of the high security provided by the telecommunication network for other authentication and communication processes (e.g., payment, fraud prevention, identity verification, etc.). The described techniques and systems also take advantage of the UICC authentication functionality in a similar way to SIM Trust and can also use SIM Trust servers. This provides a similar high level of trust even for constrained devices. Constrained devices and Narrow Band loT (NB-loT) devices, in particular have stringent battery and power requirements and also need to communicate in low signal areas. NB-loT does not support either SMS or TCP / IP but does support UDP / IP. As current secure platforms for use with loT or “Economy of Things” (e.g., payments) such as the Digital Asset Broker are generally based on HTTP, which itself only supports TCP / IP, support for UDP / IP may need to be added to these platforms so that constrained devices can be integrated. One consequence of this is that the packets sent are not acknowledged at the IP transport layer, so additional acknowledgement capability is needed at the application layer where this feature is important. Two standards-based techniques enable this requirement to be achieved: CoAP CoAP; and 3GPP TS 33.163 BEST (Battery Efficient Secure Transport for MTC devices). CoAP uses DTLS for the security layer which is a public key-based security mechanism (Public Keys should be used to prevent man in the middle attacks). BEST was designed for use with network authentication-based security. BEST does not disguise the IMSI at security setup so additional work is required to protect the IMSI. PKI requires significant overheads and so is not suitable from use with constrained devices. Because of its lower overheads, BEST has been chosen as the way to provide UDP support. To minimise the impact of this change on the server design and to fill in gaps that are not specified in the BEST specification, features of GBA and BEST may be combined to provide advantages of both solutions. Many of the use cases highlighted below do not have access to a mains supply or generated battery supply (such as in a vehicle). Freight container tracking, environmental monitoring, transportation condition monitoring, asset tracking and post box utilisation use cases are particularly likely to have tight battery requirements. Battery constrained devices need to power off for large periods of time and are therefore likely to lose their IP address and / or port number. As many protocols are keyed on IP address and / or port number, this causes many security session handshakes, which require additional system resources. Modem modules used in battery constrained devices are able to maintain their RAM, whilst in low power or standby mode. Figure 1 shows a flowchart of a method 10 for providing secure communications between a device and a server. The flowchart illustrates this method 10 at a high level. Further details are provided throughout this disclosure. The flowchart of Figure 1 shows the method 10 as a simplified method according to an example implementation. At step 15, a software application on the device generates a session identifier. The session identifier may be based on data received from an external source (e.g., the server) and / or from data or information already available to the device. For example, the session identifier may be based on a session identifier root provided to the device by the server, the particular software application being used (there may be one or more software applications on the device), a particular use (e.g., messaging, signing, etc.), and / or a counter (i.e., the number of times a particular combination of the earlier components of the session identifier have been used by the device). At step 20, the software application selects one of a plurality of group keys available to the software application (e.g., forming part of the software application) based on at least a part of the session identifier. For example, this may be the session identifier root provided by the server. The selection may be made in any number of ways. For example, the session identifier root may be processed using an algorithm (e.g., checksum) to provide an identifier or number corresponding to one of the group keys. At step 25, a message is sent from the device to the server. The message is encrypted using the group key identified or selected in step 20. The message also includes or is sent with the session identifier. At step 30, the server sends a response to the message. This response is an authentication request also encrypted using the group key. This response (authentication request) is received by the device. At step 35, the response (authentication request) is itself authenticated by the device. A secure element (e.g., IIICC, SIM, or iSIM) of the device carries out the authentication. Authentication may be achieved using SIM Trust, for example. At step 40 and following successful authentication at step 35, the software application generates cryptographic material based on the message content, including the session identifier. An algorithm may be used to generate the cryptographic using the session identifier or at least a portion of the session identifier as a starting point. At step 45, the software application of the device derives a key or set of keys based on the cryptographic material. At step 50, the server also derives the same key or set of keys from the cryptographic material and at least a portion of the session identifier. However, the server can obtain the cryptographic material from an HLR (or other component of a communications network) associated with the device. The message may contain an encrypted identifier or the device and / or a network associated with or serving the device so that the correct HLR can be identified. The key or set of keys can be used to secure communications between the device and the server, for example. The key or set of keys may also be used to sign messages communicated between the device and the server or carry out other data verification. Communications may be achieved using a cellular network or another network (e.g., wired or wireless such as WiFi). The method may be implemented using one or more computer systems 200. The software application may also be described as a software development kit (SDK). A central server may implement other functions, such as software updates, distribution to devices, and maintenance. Figure 1A shows a flowchart of a further method 11 for providing secure communications between the device and a second server by sharing keys between the device and the second server using a first server. The flowchart illustrates this method 11 in more detail to the method 10 described with reference to Figure 1. Further details are provided throughout this disclosure. The device contains a software application and a secure element (UICC or SIM). The first server provides cryptographic services for a plurality of second servers (customer servers). The first server interacts with a home location register (HLR) to obtain authentication vectors for particular SIMs on individual devices. The device also contains a customer application associated with the second server. The device described with reference to Figure 1A is one of a plurality of devices served by the HLR, first server and second server. The customer application on the device generates a request for a key. This request may be triggered so that the customer application can provide a secure service to the device or the user of the device (e.g., to provide a service requiring a payment). The software application (e.g., SIM Trust SDK) on the device receives this request from the customer application at step 115. The request includes or is accompanied by data describing the requested key (e.g., its intended use, an identifier of the requesting server, and / or a number or iteration of the key if similar keys have been requested before), and a requester secret shared between the customer application and the second server. This requester secret may be pre-shared. The request may be triggered if there is no existing key or if an existing key has expired. In response to the request for the key, the software application selects one of a plurality of group keys (e.g., from within the software application or stored on the device) at step 120 and generates a session identifier to be associated with the group key in a subsequent message. The session identifier also identifies the group key (e.g., contains an identifier of the group key). The device encrypts the message using the selected group key and sends the encrypted message to the first server at step 125. The message includes the session identifier and an identifier of the secure element (e.g., its international mobile subscriber identity (IMSI)). At step 130, the first server decrypts the message from the device using the identified group key (the first server has access to the group key either from the second server or from a data store available to the first server). In response to the message, the first server obtains an authentication vector based on the identifier of the secure element (IMSI of the SIM) at step 135. The authentication vector is obtained from the HLR. The authentication vector includes key materials (e.g., Ck, Ik or Kasme) and an authentication request (e.g., in the form of RAND and AUTN). The first server also generates a request session identifier root at step 140. This can be used to generate a plurality of request session identifiers (e.g., when keys expire or need to be regenerated). The first server uses the same group key (associated with or identified by the session identifier) to encrypt a response to send to the device. The response is formed from the authentication request (e.g., RAND and AUTN) and the request session identifier root. The first server sends the response to the device at step 145. The first server also uses the key materials (obtained from the HLR) to generate a master key at step 150. The device receives the response, and the software application decrypts the response using the group key (previously selected) at step 155 and sends the authentication request (included within the response) to the secure element. The authentication request takes the form of a cellular authentication, which is normally authenticated by a SIM. The secure element authenticates the authentication request at step 160 by using keys already shared with the HLR and stored within the secure element (SIM). During the authentication process, the secure element generates key materials (e.g., Ck and Ik or Kasme) using the keys stored within the secure element (SIM) at step 165. The secure element passes the key materials to the software application, which uses them to derive a master key (step 170). The master key and the request session identifier root are stored by the software application on the device (e.g., within secure storage or in encrypted form). The software application can use the stored master key, the data describing the key use, and the requester secret to generate further keys as and when they are required (step 175). The master key may have an expiry time or date or other mechanism to make it invalid. As long as the master key remains valid, further different keys can be generated and steps 120 to 170 do not need to be repeated. However, at intervals or when the master key expires, these steps can be repeated to generate a new master key. Codes or data representing the key usage can be used as a root to generate new keys. When the same usage is required then a counter can be used to combine with these codes or characters to form a different root and so different keys can be generated. This information can be sent to the second server. The second server can receive the key or keys derived from the master key, the key label and the requester secret from the first server, e.g., over an application programming interface (API) or preferably by sending a REST API request from the second server to the first server, which provides the derived key or keys as a REST API response. Communications may be achieved using a cellular network or another network (e.g., wired or wireless such as WiFi). The method may be implemented using one or more computer systems 200. The software application may also be described as a software development kit (SDK). A central server may implement other functions, such as software updates, distribution to devices, and maintenance. As shown in Figure 2, the computer system 200 includes a number of components including communication interfaces 220, system circuitry 230, input / output (I / O) circuitry 240, display circuitry and interfaces 250, and a datastore 270. The system circuitry 220 can include one or more processors or CPUs 280 and memory 290. The system circuitry 230 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. The display circuitry may provide one or more graphical user interfaces (GUIs) 260 and the I / O interface circuitry 240 may include touch sensitive or non-touch displays, sound, voice or other recognition inputs, buttons, switches, speakers, sounders, and other user interface elements. The I / O interface circuitry 240 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 240 may further include data media interfaces (e.g., a CD-ROM or DVD drive) and other bus and display interfaces. However, many constrained devices will not contain a GUI or I / O interface to reduced complexity and improve battery life. The memory 290 may include volatile (RAM) or non-volatile memory (e.g., ROM or Flash memory). The memory may store the operating system 292 of the computer system 200, applications or software 294, dynamic data 296, and / or static data 298. The datastore or data source 270 may include one or more databases 272, 274 and / or a file store or file system, for example. Figure 3 shows a schematic diagram of a system 300 for implementing the method 10 and method 11 described with reference to figures 1 and 1 A. In this figure, the device 310 is shown as a customer device, the first server is shown as the SIM Trust Service 340 and the second server is shown as the customer’s service 320. A customer may have many devices and may have separate servers for different functions or for load balancing. The message flow and communications between the device 310 and the server 320 make use of application programming interfaces (APIs) and other intermediate components (both hardware and software). For example, the server 320 obtains the cryptographic material from the HLR within the network operator using the SIM Trust service and associated APIs. Messages flow between the device 310 and the server 320 using a digital asset broker (DAB) service or intermediate broker. Such messages may be stored and verified by the DAB service to provide additional functionality, verification and storage. Annex 1 (including in this disclosure) describes the functionality of the APIs in more detail. These may be REST APIs. The software application 330 may include separate SDK for cryptographic and noncryptographic functions. Figure 4 shows a sequence diagram illustrating the message flow and functionality of an example implementation of the method 10 or method 11 described with reference to Figure 1. In this diagram, the memory, SIM, SIM Trust SDK, Customer Application and Modem are software or hardware components of the device 310. The SIM Trust Server is the server 320 and the Network Operator comprises the HLR, which provides the cryptographic material to the server 320 in the form of a quintet. Throughout the disclosure, the session identifier may be described as a BTID (with reference to the BEST standard). Figure 5 shows a schematic diagram of a further example implementation of the system for implementing the method 10 or method 11 described with respect to Figures 1 and 1 A. The customer server (server 320) may be hosted in a virtual environment, for example. Figure 6 shows a schematic diagram of the device interfaces: SIM Trust SDK - SIM / iSIM interface This interface is almost the same as for the current SIM Trust platform. This uses the serial AT coms interface and the AT+CSIM command. SIM Trust SDK - Modem Interface An AT command serial interface communicates via the modem to the SIM trust service. The messages sent over this interface are based on BEST (3GPP TS 33.163). SIM Trust messages originate from the device (so it does not need a permanent listener). SIM Trust SDK - Customer Application A fixed set of functions and parameters are defined such that these can be relied on for production service. SIM Trust SDK - Memory Secret Materials and Provisioning Materials may be stored on insecure memory (encrypted at rest). Main Flow Diagram (without OTA) sequenceDiagram participant MEM as Memory participant SIM as SIM participant SDK as SIM Trust SDK participant CA as Customer Application participant M as Modem participant STS as SIM Trust Server participant NO as Network Operator MEM -»SDK: read configurationat first power on note over SDK: Decodeconfiguration SDK-»SDK: Idle M--»SDK: any UDP / TCP message note over SDK: silentlyIgnore CA-»SDK: request new key note over SDK:check currentBTID is valid alt BTID is valid note over SDK: Caluculatenew Key SDK-»CA: newkey, new BTID note over CA: end else BTID missing or invalid SDK-»SIM: Read IMSI SIM-»SDK: IMSI Value note over SDK: Choose random Groupkey and encrypt SDK»M: AT Command(BEST(EMSDP SessionRequest(IMM-»STS: BEST(EMSDP SessionRequest(IMSI)) note over STS: verify encryptionand decode IMSISDK--»M: AT(check for response) STS-»NO: Get quintet(IMSI) NO-»STS: Security Quintet SDK--»M: AT(check for response) note over STS: create new BTIDand store BTIDSTS-»M: BEST(EMSDP SessionStart(RAND,AUTN)) SDK-»M: AT(check for response) M-»SDK: AT(BEST(EMSDP SessionStart(RAND,AUTN)))SDK- »SIM: AUTHENTICATE(RAND,AUTN) SIM-»SDK: RES, CK and IK note over SDK: create newdevice specific key SDK-»CA: newkey, new BTID note over CA: end end Figure 7 illustrates schematically the SIM Trust Server and the server interfaces. For example, the server type may be an AWS instance running Ubuntu Other operating systems and cloud providers may be used. The following example ports are used: Protocol Connected to Purpose TLS / TCP Fast API Deliver Server side REST API server for customer REST calls. UDP BEST Interface Communication with SIM Trust BEST SDK over LIDP / IP TCP BEST Interface Communication with SIM Trust BEST SDK over TCP / IP Server SIM Trust BEST Interface: In this example, the server SIM Trust BEST interface is delivered by a python3 program (SIM-Trust-Server-Device-Side.py). It listens on a UDP port) and / or a TCP port (for TCP traffic). All communication over these ports is encrypted, tamper protected and replay protected using the BEST protocol (3GPP TS 33.163) as specified in: Constrained Device Interface Key Concepts SIM-Trust-Server-Device-Side.py communicates with the HLR to get network authentication vectors (quintets) and with database to store and retrieve BTID and key information, and to validate device status and parameters. Database:atabase is used for the example implementation. Database Name: Withheld Tables: KeySet, Devices, Users, Companies,: used to store the key materials vs. IMSI Figure 8 provides example data attributes used by the system and method. Server SIM Trust Customer Facing REST API A Customer facing REST API is provided to deliver services. This API only communicates internally with the database. This interface is matched with the current example SIM Trust REST interface. Annex 1 describes example REST APIs Customer App and Server provide: Key Retrieval - both Encryption key and integrity key. Signing and encrypting data - the data is both signed and encrypted. Signing data only - the data has been both signed but not encrypted. Encrypting data - for secure local storage in insecure memory. Decrypting data - for secure local storage in insecure memory). Shows the following functions at the Server: Key Retrieval - both Encryption key and integrity key. Signing and encrypting data - both signed and encrypted can be retrieved only by and decrypted by authorised users. Verification of data - show that data has been signed and that only authorised users can verify. Demonstrates constrained device use case(s). (e.g. push service is not required) MAY demonstrate messaging server for OTA or push services Able to be used to prove that the solution works for NB-loT (LIDP) and CAT-M (TCP) interchangeably. Figure 9 shows schematically an example server design. Figure 10 show a schematic diagram comparing the messages sent between a device and server in a system based on PKI (right side of figure) and the messages sent between a device 310 and server 320 in the present system 300. It is noted that more messages are required (and for every session) for the PKI-based system. Even if no valid key exists in the current system 300 (i.e., this is a first contact between device 310 and server 320) then fewer messages are required. If a valid key has already been exchanged, then handshaking messages are not required either in the current system 300. This demonstrates improved efficiency of the present system 300, method 10 and method 11. Figure 11 further illustrates improvements of the present system 300, method 10 and method 11. The graph on the top right of this figure illustrates schematically the probability of success of a single message (y-axis) and number of messages / time (x-axis). Due to network and radio reliability constraints, not every message will be successful. All messages need to succeed for key agreement success or the process needs to repeat. The concentric circles at the bottom of figure 11 illustrate schematically the coverage of a base station or other radio transmitter providing services to a device 310. Each circle provides the same level of reliability (on an arbitrary scale). This diagram is not to scale but shown for illustrative purposes. For the PKI system, as six messages are required then the coverage will be lower (smallest circle) as more messages reduces the coverage for the same level of reliability. The middle circle represents the coverage (for the same level of reliability) of an initial communication between the device 310 and the server 320. This is larger than the coverage for PKI because fewer messages are required as the probabilities of success for each message multiplies. The largest or outer circle represents the coverage (for an equivalent reliability) when the handshaking messages are not required. This is the greatest coverage because only a single message is required. The device 310 and server 320 can generate a new key or keys based on a session identifier with the same root but including different other data components (e.g., counter, application, use, etc.). New key or keys are generated (providing the same level of security) without requiring the initial messages. For NB-loT Constrained devices: Key Agreement is achieved through UDP / BEST communications channel. The Session ID and the key value is written to a specific MQTT message channel and may be viewed using an MQTT Client. The SIM Trust API docs page (SIM Trust REST API - Swagger III) may be used to fetch the key - it can then be compared with the one supplied by the Device. Specific Data Encryption sent via unencrypted CoAP may be achieved through UDP / CoAP channel - data privacy and tamper protected end to end, over a less secure channel. The data may be encrypted and signed at the device and results in an encrypted blob. The encrypted blob and the unencrypted data may be written to a specific MQTT message channel and viewed using the MQTT Client. The SIM Trust API docs page may be used to decode the encrypted blob and it may then be compared to the unencrypted data. For CAT-M constrained devices: Key Agreement is achieved through TCP / BEST / communications channel. Data Encryption sent via unencrypted MQTT may be achieved through TCP / MQTT / . Data Signing sent via unencrypted MQTT may be achieved through TCP / MQTT To satisfy this goal several battery consuming effects need to be considered: • Security session renegotiation due to new IP address and port details every communication. • The consequences of the device being in “standby” or “off” for most of the time. Battery power consumed by the DAB and / or SIM Trust processing. • Battery power consumed when updating the DAB Software over the air. Security Session Renegotiation: The 3GPP TS 33.163 BEST (Battery Efficient Secure Transport for MTC devices) protocol has the benefit that it is secured against the SIM Identity (IMSI) not the IP address and port. This means that the modem can end a data session and start a new session sometime later with no need to renegotiate the DTLS security channel as long as the client has at least one valid BEST session ID, counters and keys. Device in “standby” or “off”: The existing design relies on SMS to trigger device actions from the server, this means that the modem needs to be active and listening to the paging channel which consume power. This design introduces a concept of device polling when it would be naturally communicating anyway (saving power). The present improved concept may include a message store on the DAB service which delivers, stores and delivers messages to the device when it actively communicates. This can either occur on a timed basis or by a device app triggering it. The message store prevents messages being lost if the SMS does not deliver (which can happen in low coverage areas). DAB / SIM Trust Processing: The design may be optimised to use processing light security mechanisms (e.g., AES) and only to use one mechanism. It is appropriate just to use AES as a basis for security. This is very compact, quick to operate, is quantum computing safe and there is no need for an alternative algorithm as this is deemed strong. Note: AES is the basis of most mobile security and so is hardware accelerated and power optimised in modem software. DAB Software Updates: Typical battery constrained devices are hard to deliver software updates to as these updates can use significant battery power potentially significantly shortening the life of the product. To cope with this a device end scripting capability is specified that allows functionality to be added to a device without the need for a software update. Many constrained devices use a separate microprocessor system and modem as the modem part requires reasonable technical skill to implement well. The separate microprocessor system is typically both processor and memory constrained so the DAB device SDK size and processing requirements may be a significant burden. Two separate design aspects assist in optimising this solution for memory and processor constrained devices: minimal library requirements and in-module design approach. Minimal Library: The design uses a single AES-256 core algorithm for all security processes which is implementable in a very compact way. In-module design: The whole of the device end of the solution is designed so that the device SDK could be in either the modem or the modem module rather in the device. This has some added benefits: • It is more secure for the code to be in the modem (more secure) or the modem module (most secure). • It is easier to optimise the battery consumption when the SDK is aware of the modem power saving. • The modem has many of the key libraries used by the device SDK hardware accelerated for speed, security and power optimisation. • The modem already is mandated to support FOTA (Firmware over the air) updates, so there is no need for a separate process to manage bug fixes and it is possible to download the SDK to devices already in the field. • Having the SDK in the modem means that it is not taking up memory and processing resources of the device. Subkey generation using same BTID In existing systems, every time a key is requested, a GBA exchange is used that produces a single 256 bit key. The device is currently optimised to give the same BTID / key combination if the device already knows a valid BTID for the application ID requesting it (NAF ID). However, no control over the NAF ID is implemented so it is possible for an application to get the secret for one application by presenting its NAF ID and even to emulate another NAF ID. Furthermore, when using a new NAF ID, a new BTID is mandated which adds a time delay, increases battery use and uses capacity of the roaming service communication, e.g., VRS (Vodafone Roaming Services). From a practical point of view, the customer cannot easily just use the key generated as they most likely will need two keys, one for encryption / decryption and one for integrity protection. This means they will need to implement a key transformation mechanism or split the GBA key in two giving only 128bit security. The present solution has a built-in key derivation function (the similar to the one used for the GBA key calculation) that is used to derive further keys. These keys are isolated by key type, key number, NAFID and whether it is for the current system use or not. This solution is matched in the SIM Trust API to make it easy for the customer to get the relevant keys. AT commands Most modems use an AT command interface to control the modem and in many cases to pass data to and from the modem and the device. To make the SDK easy to integrate into the modem, a Common AT command set is needed so that the access to present service is consistent across many modem types and manufacturers. This goal only effects the device 310. As part of the device requirements, an AT command set is specified that allows the device to easily access the updated SIM Trust services. The specified AT Command set may also be used as a template for offering a similar interface over similar protocols between the device and the modem. Multiple BTIDs live per device If the existing SIM Trust server only holds one BTID per device so a second key request that results in a new BTID will effectively invalidate the first BTID (most likely significantly before it would have expired). This also creates a race condition under the following conditions: Two or more applications using SIM trust in the same device: When the second application requests a key a new BTID will be generated. If the first applications server has not fetched the key for the first BTID before this happens, the server will never be able to supply the key as it will have lost the BTID and its keys. This race condition means that every application will need to be aware of other applications using updated SIM Trust. A single application requiring multiple keys: It is normal for an application that is both confidentiality protecting and integrity protecting data to use two separate keys for each function. By asking for a second key, the application will invalidate the first key. It is also normal to use different keys where a device is communicating with a different entity. To manage this, the customer may implement their own key derivation function or have complex signalling with the server so it knows to fetch the first key before the second is fetched. However, both of these options are not customer friendly. Device: This goal only has a minor effect on the device 310, the device 310 needs to be able to store multiple BTIDs / keys / NAFID sets until they expire or until they are forgotten. These should not be stored in non-volatile memory (Flash, EEPROM, FRAM...). Server: The server may keep a record of all valid (session identifiers) BTIDs and their associated key(s), NAF ID and Device ID. These BTIDs need to be stored until they expire or until they are invalidated (through the API) as they may be required at anytime by the customer’s application server. As these keys may be stored for relatively long times, the keys should be securely stored at rest and access to the keys should be heavily restricted (to satisfy security requirements). Device end cryptography functions (encrypt, integrity protect, replay protect, sign and verify) The SDK provides several cryptographic functions (accessible by either SDK calls and / or AT commands) that use SIM Trust keys. The customer will not get the keys being used by these functions directly (as this has security implications). For example the following functions could be supported: Encryption: using AES-256-GCM. The customer may supply a valid BTID if they want to use the same key as for a previous encryption. The customer may supply a key number to indicate that the same key should be used as for a previous encryption. Integrity Protect: using AES-256-GCM if encryption is also being carried out or AES-256-GMAC if only integrity protection is being carried out. The customer may supply a valid BTID if they want to use the same key as for a previous integrity calculation. The customer may supply a key number to indicate that the same key should be used as for a previous integrity calculation. • Replay protection: Using transmit and receive counters for each transaction. • Cryptographic signing of data: The ability to sign data using AES-256-GMAC • Cryptographic verification of data: The ability to verify data using AES-256- GMAC Device end scripting engine A significant issue for solutions that have a remote device SDK is how to add functionality to it in the future. Every time a new software version is produced it adds another layer of legacy support requirements which very soon becomes very expensive to support. Features may be added to the existing SDK without the need to reprogram the current SDK. The most efficient way to achieve this is by using scripting languages. The scripting language allows new services and feature to be added by just changing / adding to the server software. This scripting language acquires device local information, process information, encrypt, sign, integrity protect information, package information, carryout local device actions and communicate with a central server. The script may be either stored in the device and locally or remotely triggered by the platform or the scripts may be sent by the platform for immediate execution. The central server may discover the scripting capabilities for the Device SDK. Device: The device has the ability to store scripts locally in the device. Those script may be triggered by local events or as a result of a communications trigger. The scripts may process some inputs (including things like GPS values, device properties, timer expiry...) carry out data transformation and conditional statements and be able to out put the resulting data (or store it securely for later transmission). Device end data collection means The device end SDK can collect key device data (such as VIN number for vehicles) to enrich the provenance of data for specific services (such as EV charging). The device may collect reference data from different sources. Device end secure storage in non-secure memory A key requirement in the new cybersecurity regulation is the secure storage of data at rest in the device. The encryption and decryption of data so it can be securely stored in insecure device memory is achieved by the updated SIM Trust service. The key issue is how to decrypt the stored data if the decryption key is lost. This may be achieved by retrieving it from the SIM Trust server (wrapped in a further key). Device: A data wrapping and unwrapping service together with a request and receive mechanism allows the device to retrieve a key from the SIM Trust server. Server: The device requests the key value and receives the key value for a previous data encryption session. Server certificates A security communications protocol between the central Server and the device is not based on public key cryptography but is still of a similar strength (for example BEST). Zero provisioning Zero Provisioning is about not having to customise the device provisioning for each device when they are produced. To make the SIM Trust (and DAB) simple to implement and provision, all of the provisionable information may be contained in the SDK, derived from a combinations of factors available at the device or SIM or be OTA-able to the device in an efficient and battery conserving way. The BEST solution presented in this disclosure removes the need for server PKI and device PKI. Derivable suitable keys (group keys) are embedded in the software for all devices. These two items together mean that only the Device SDK software needs to be provisioned. Zero touch This means that the device does not need to be configured in operation and implies that the server can authenticate the device and remotely manage it efficiently. It is clearly important for an loT device that all functions are achieved without user intervention. OTA SDK Management capability The needs to be an OTA mechanism that allows parameters and stored scripts for the Device SDK to be securely managed over the air. Optimised messaging for constrained devices For any battery or protocol constrained device, the number of messages sent and the size of the messages have a direct relationship to the battery life and reliability of the device. Messages are as compact as can be and care taken not to have unnecessary multiple messages flows to deliver a service. The use of TLVs to categorise and shrink messages may be used as well as other compaction techniques. Keep alive for non-constrained devices It is now common practice to keep PDP sessions active rather than repeatedly closing them and re-negotiating them (this saves core network processing time). The GSMA loT Device Connection Efficiency Guidelines Version 3.0 30 March 2016 has guidelines for keep alives. Secure coding requirements Both the device and the server are strongly secure so that a wide range of customer solutions can be addressed. IMSIs are always privacy protected The very first message (key negotiation) from the device and any key negotiation message sent if the device does not have a valid key contains the IMSI (so that the server can determine who the device is). This is privacy protected. The BEST implementation has the concept of pre-negotiated BTID key combinations that can only be used for initial key negotiation messages. These combinations can be updated securely by OTA, but even without updates, are still secure due to their infrequent use. To give separation between different customer risks, different combinations of these initial BTID / Key combinations may be compiled with different customer specific SDKs. The same initial BTID / Key combinations are used across a range of devices so at the server all of these combinations should be valid. The device may randomly pick an initial BTID / Key combination from its locally stored list of available combinations or this choice may be based on or otherwise encoded into the session identifier. Reducing the number Quintets required The consumption of quintets adds time delays and makes it more likely that MNOs might charge for this service in the future. By limiting the number of quintets used for the present services, the method and system improves the timing of our service, the reliability and lower the impact of our service on MNOs. The following functions may be supported: • Decryption: using AES-256-GCM with end padding to block size. The customer sets up a secure session and authenticates themselves. The customer then supplies the encrypted data, a valid BTID the key number and the NAFID. The API returns the decrypted data. • Integrity Verification: using AES-256-GCM if encryption is also being carried out or AES-256-GMAC if only integrity protection is being carried out. The customer sets up a secure session and authenticates themselves. The customer then supplies the encrypted data, a valid BTID the key number and the NAF ID. The API returns either “VALID” or “NOTVALID”. • Replay protection: Using transmit and receive counters for each transaction. The server maintains counters for each BTID / NAF ID combination one for server to device and one for device to server (The counters for a new BTID / NAF ID combination is 0). When replay protection is used together with either Decryption or Integrity verification, the process would error if the counter presented is less than the stored counter in the server. If a valid counter that is higher) is received, and the message is valid in all other respects, on completion of the processing of the message the counter shall be incremented to the value in the message. There may be a counter window to limit the possibilities of denial of service attacks. • Cryptographic signing of data: The ability to sign data using AES-256-GMAC • Cryptographic verification of data: The ability to verify data using AES-256- GMAC Protect key generation such that customer app will never be able to generate keys used by the system 300. For GBA, the calculated key for a specific BTID depends only on the supplied NAF ID. There is currently nothing that prevents an application from using the same NAF ID as the presently described services and therefore getting the same key. The described system and method may include a flag that indicates whether the key generated is for use with the presently described system or for external use. This flag guarantees that the generated key will always be different even if the NAF ID and BTID is the same. Key type as a parameter of key generation so that different level of security can be maintained for different uses. In current systems, the calculated key for a specific BTID depends only on the supplied NAF ID. A key type may be added so that OTA keys for instance can be treated differently to script keys and are guaranteed to be different values. The presently described system 300, method 10 and method 11 include a flag that indicates the key type. The Device SDK to SIM Trust Device Interface is made up of several communication channels / purposes: • Key agreement • Device Management (OTA) • Device script triggering • Key retrieval • DAB / Customer secure data channel This uses BEST (Battery Efficient Secure Transport) as a basis for all five of these purposes. The Key agreement will use the BEST control channel and the other four may use the BEST Data channel. The BEST protocol can be transported over any bearer. The BEST protocol relies on lower layers managing the message routing (source and destination addresses) and the packetization of the BEST message. BEST is detailed in 3GPP TS 33.163. (Rei.17 or later). General BEST implementation BEST messages are packets that have a security header and content that is either control messages or data. BEST protects control messages or data using the following features: • Session management • Counter (to protect against replay attacks) • Integrity Protection (optional) • Encryption (optional) • Authentication (during the key agreement process) BEST has two packet structures - one for control messages and one for data messages: UP / CP Flag RFU Key ID CP COUNTER Session ID EMSDP Command Cmd Options MAC 1 bit 1 bit 3 bits Note 4 Note 1 Note 2 Note 1 Note 2 Note 3 Note 2 Note 3 Note 1 Note 3 User Plane type 01 message: UP / CP Flag RFU Key ID UP COUNTER Session ID Data Length Data MAC 1 bit 1 bit 3 bits Note 4 Note 1 Note 2 Note 1 Note 2 Note 3 Note 2 Note 3 Note 1 Note 3 Control Plane type 01 message: Note 1: The length of these fields is indicated in the BEST HSE configuration TLV 5 from the HSE. Note 2: These fields are included in the integrity protection calculation. Note 3: These fields are encrypted when encryption is used. When encrypted these fields are replaced by the encrypted output. Note 4: The length of this field is as defined in the BEST Counter Scheme being 10 used. For both message types it is proposed to use the BTID (possibly with a shortened realm) as the Session ID. BEST Command Description Response if received by the Device Response if received by the HSE (Server) EMSDP Session Request This message is used by the device to request a Message ignored This command Reply with EMSDP Session Start if new session. It conditionally contains an IMSI and is always encrypted and integrity protected using AES. should only originate from a device. message is valid. EMSDP Session Start This message is used to send the new BTID and the authentication parameters associated with it EMSDP Session Start Confirmation if message is valid Message ignored This command should only originate from a HSE. EMSDP Session Start Confirmation This message sends the RES to the HSE Message ignored This command should only originate from a device. none - (end of sequence) EMSDP Session Terminate Request NOT USED (as for SIM Trust there can only be one key per session ID) Ignored Ignored EMSDP Session Terminate Response EMSDP Manage Keys Request EMSDP Manage Keys Response EMSDP Message Reject To protect the IMSI, presently described system 300, method 10 and method 11 use a select number of global sessions that can only be used for the first message that includes IMSI when there is no other valid key. New Key request (No previous session details known) The EMSDP Session Request message is sent at any time, by the device 310, to generate a new session ID and keyset where no previous session details known. This could be because it is the first time this device has communicated with the server 320, because the previous session has expired, because the server rejected the previous session or because the previous session details have been lost by the device due an event such as a power cycle. 5 This message is only sent from the device 310 to the HSE (server 320). If the device 310 receives this message, it shall ignore it. Message Format An example message may be formed as follows: Parameter Value Comment UP / CP Flag 0 (1 bit) Set to Control Pane message RFU 0 (1 bit) Set as RFU Key ID [0...7] (3 bits) Scheme key ID used CP COUNTER “001 00000001” as bits Initial counter value (note server will ignore this value) Session ID <one of the preconfigured session IDs for that range of devices> Indicates that this is a brand new session and that there are no valid available keys. EMSDP Command 10 (Hex) EMSDP Session Request Cmd Options "0108"<IMSI> "0206<config parameters>" "030100" "0B03"<encoded serving network id> (all values as hex) Where IMSI is as for IMSI TLV AES indicated in config Device to HSE Serving network MAC 4 bytes MAC calculated using indicated Scheme integrity Key and AES-256 algorithm. The encryption key used for this message may be the encryption key from one of the programmed scheme wide key sets, chosen randomly. The integrity key used for this message is the integrity key from the same programmed scheme wide key set as the encryption key. HSE Response On receiving this message, the HSE (server 320) takes the following actions in an example implementation: 1. Verify that the message structure and size is valid 2. Decrypt the EMSDP Command, Cmd Options and MAC fields using EEA2 (128-AES) and the indicated scheme encryption key. 3. Verify that the message structure and size is valid for the EMSDP Command, Cmd Options, MAC fields and any padding. 4. Verify the Session ID, EMSDP Command and Cmd Options using the MAC, the EIA2 (128-AES) algorithm and the indicated scheme integrity key. 5. Retrieve the IMSI and check that it is a valid IMSI format and that it exists in the server 6. Fetch authentication parameters from the PLMN 7. Generate a new BTID (that is unique among active BTIDs on that server). 8. Generate reply: EMSDP Session Start using the same scheme keys as used for the EMSDP Session Request. If any step fails other than step 8, the HSE aborts the key agreement process without sending anything to the device and logs the error internally as required. New Key request (Previous session details known - no handshaking required). The EMSDP Session Request message is sent at any time, by the device 310, to generate a new session ID and keyset where the previous session details known and are valid. As the device 310 knows a valid current session ID and keyset, it uses that session ID for the EMSDP Session Request, its incremented counter value and encrypts and integrity protects the request using the key set associated with that session. As the IMSI and support details are already known by the HSE (server side), the IMSI TLV may be just the Tag value and a zero length byte (0100hex) and the BEST UE configuration TLV, Enterprise Setup Information Element TLV shall be omitted. As encryption is used, the serving network TLV shall be present. This message is only sent from the device to the HSE (server). If the device receives this message, it shall ignore it. Message Format An example message is formed as follows: Parameter Value Comment UP / CP Flag 0 (1 bit) Set to Control Pane message RFU 0 (1 bit) Set as RFU Key ID [0...7] (3 bits) Session key ID CP COUNTER Encoded (last sent value +1) As per TS 33.613 Session ID BTID string, encoded ASCII encoded string of BTID with the upper bit set for all but the last byte. EMSDP Command 10 (Hex) EMSDP Session Request Cmd Options "0100" "0B03"<encoded serving network id> (all values as hex) No IMSI sent (server already knows this) Serving network MAC 4 bytes MAC calculated using indicated Scheme integrity Key and AES-256 algorithm. HSE Response On receiving this message, the HSE (server 320) takes the following actions: 1. Verify that the message structure and size is valid 2. Decrypt the EMSDP Command, Cmd Options and MAC fields using EEA2 15 (256-AES) and the indicated session encryption key. 3. Verify that the message structure and size is valid for the EMSDP Command, Cmd Options, MAC fields and any padding. 4. Verify the Session ID, EMSDP Command and Cmd Options using the MAC, the EIA2 (256-AES) algorithm and the indicated session integrity key. 5. Retrieve the IMSI and check that it is a valid IMSI format and that it exists in the server 6. Fetch authentication parameters from the PLMN 7. Generate a new BTID (that is unique among active BTIDs on that server). 8. Generate reply: EMSDP Session Start using the same session keys as used for the EMSDP Session Request. If any step fails other than step 8, the HSE aborts the key agreement process without sending anything to the device and logs the error internally as required. EMSDP Session Start The EMSDP Session Start message is sent by the HSE (server 320) to the device 310 to create a new session with associated BTID and keyset. This message may only be sent in response to a valid EMSDP Session Request message from the device 310. For UDP based NB-loT use cases, this response may happen in less than 800ms. The message is encrypted using the same encryption key used for the EMSDP Session Request message but it is integrity protected using integrity key from the new key set. This message is only sent from the HSE (server) to the device. If the HSE (server) receives this message, it shall ignore it. Message Format An example message is formed as follows: Parameter Value Comment UP / CP Flag 0 (1 bit) Set to Control Pane message RFU 0 (1 bit) Set as RFU Key ID [0...7] (3 bits) key ID used in the associated EMSDP Session Request CP COUNTER Encoded (last sent value +1) As per TS 33.613 Session ID BTID string, encoded ASCII encoded string of BTID with the upper bit set for all but the last byte. EMSDP Command 11 (Hex) EMSDP Session Start Cmd Options "0408<config parameters>" "05241 "<new key id as nibblex RAND IE> <AUTN IE> (all values as hex) BEST Service configuration TLV Key agreement TLV MAC 4 bytes MAC calculated using new session integrity Key and AES-256 algorithm. Device Response On receiving this message, the device 310 takes the following actions: 1. Verify that the message structure and size is valid 2. Decrypt the EMSDP Command, Cmd Options and MAC fields using EEA2 (256-AES) and the encryption key used in the associated EMSDP Session Request. 3. Verify that the message structure and size is valid for the EMSDP Command, Cmd Options, MAC fields and any padding. 4. Send an authentication request to the SIM using the ALITN and RAND cantained in the key agreement TLV. 5. Check that the authenticate command completed successfully and that the RES, CK and IK were generated. 6. Create Ke2menc and Ke2mint as detailed for EPS in TS33.163. and bind them as a keyset with the BTID. 7. Verify the Session ID, EMSDP Command and Cmd Options using the MAC, the EIA2 (256-AES) algorithm and the new session integrity key(Ke2mint). 8. Generate reply: EMSDP Session Start Confirmation containing the RES secured using the new session keys. 9. Return the BTID, Ke2menc and Ke2mint to the requesting device application. If any step fails other than steps 8 and 9, the device aborts the key agreement process without sending anything to the device and logs the error internally as required. EMSDP Session Start Confirmation The EMSDP Session Start Confirmation message is sent by the device to confirm to the HSE (server 320) that the authentication process completed successfully and contains the RES. Note: this part of the process is optional, however it would be the customer who is 5 the first to discover that the process failed which is not a good user experience. This message is only sent from the device 310 to the HSE (server 320). If the device receives this message, it shall ignore it. Message Format 10 An example message is formed as follows: Parameter Value Comment UP / CP Flag 0 (1 bit) Set to Control Pane message RFU 0 (1 bit) Set as RFU Key ID [0...7] (3 bits) key ID used for the current session CP COUNTER Encoded (last sent value +1) As per TS 33.613 Session ID BTID string, encoded ASCII encoded string of BTID with the upper bit set for all but the last byte. EMSDP Command 12 (Hex) EMSDP Session Start Confirmation Cmd Options "0C11"<RES> (all values as hex) AUTHENICATION RESPONSE TLV MAC 4 bytes MAC calculated using new session integrity Key and AES-256 algorithm. HSE Response On receiving this message, the device takes the following actions: 15 1. Verify that the message structure and size is valid 2. Decrypt the EMSDP Command, Cmd Options and MAC fields using EEA2 (256-AES) and the encryption key the current session. 3. Verify that the message structure and size is valid for the EMSDP Command, Cmd Options, MAC fields and any padding. 20 4. Mark the key distribution as successful. If any step fails other than step 4, the HSE aborts the key agreement process and records the key agreement process as unsuccessful. 5.3.3 BEST Data Channel (OTA, Scripting, Key retrieval and DAB) The BEST Data channel shall be used to deliver multiple types of content. To 5 optimise the battery performance and reliability, the data portion of the BEST data channel message shall contain one or more BER TLVs (Tag, Length, Values as defined in ISO 7816 part 3) that contain specific content. BER TLVs have the following structure: Tag Length Value The following Tag values are defined for messages from the device to the HSE (Pairpoint is an example name of the platform): Tag Name Description Allowed in Customer message Server Message Request Triggers the message server to send any stored message to the device. No Key Request Request the server to send a memory encryption key to the device No Customer Uplink Data Encrypted customer data to be sent to the customer server. Yes Signed Customer Uplink Data Signed customer data to be sent to the customer server. Yes Verification Response to Customer Data Customer data verification response Yes OTA Response Response to an OTA request from the server. No Script Triggered Message / Response This is a device response from a script run in the device triggered either by the Server or by an event in the device. No DAB signature Response This is a response to a DAB signature request. No The following types of content are defined for messages from the HSE to the device: Tag Name Description Allowed in Customer message Message waiting Trigger Triggers the device to fetch messages from the message server No Key Response Contains the response to a key request from the device. No Customer Encrypted Downlink Data Encrypted customer data sent from the customer server for decryption. Yes Customer Downlink Data for signature customer data to be signed locally at the device. Yes Customer Signed Downlink Data Signed customer data sent from the customer server for verification. Yes OTA Request An OTA configuration message No Device Script Trigger Triggers a device stored script or contains a “do now” script. No DAB Signature Request A data packet from DAB for signature No The Length is one or more bytes as follows: 1 to 3 bytes as follows: Coding Description 00 to 7F Length value between 0 and 127 bytes 8100 to 81FF Length value between 0 and 255 bytes 820000 to 82FFFF Length value between 0 and 65,535 bytes The value part is specific to the tag used. The value part may contain one or more TLVs with their own definition relevant to the TAG that they are contained in. SIM Trust Key calculation As discussed above, the key generated may vary based one or more of the following parameters: • The keys negotiated with the SIM (labelled by BTID) • The NAFID • The key number • The key type (enc, Int, sign, OTA, Script....) • Source (Internal to the system or requested by customer) As the Algorithm chosen is AES-256-GCM which has a need to make sure that the Nonce is unique for each key, the key number will be used as the Nonce. The Nonce shall be 12 bytes, for example. Every time a key is requested for a specific BTID the key number shall be incremented. When a new BTID is generated, the key number will be set to zero. For example, the key calculation may be as based on 3GPP TS 33.220 Annex B.2. derived key = HMAC-SHA-256 ( Key , S ) When calculating the derived key value, both the device SIM Trust SDK and the SIM Trust server shall use the following algorithm. Where: The Key may be CK || IK (concatenated). The S value is a string and shall be calculated as follows: S=FC|NAFID|len(NAFID)| KEYTYPE|len(KEYTYPE)|SOURCE|len(SOURCE) Where: Key requested by customer FC = 0xF9 Key Requested by SIM Trust FC = 0xF8 Key Requested by DAB FC = 0xF7Len() - L0 ... Ln are the two-octet representations of the length of the corresponding input (as a string). NAFID string any length (A-Z,a-z,0-9,@_-#$! chars only) that uniquely identifies an application within that device, (it does not need to be unique across devices) KEYTYPE is defined based on its intended use as follows: • “Z” - General Encryption Key (in the case of AES-xxx-GCM this key will be used for both Encryption and integrity protection). • “Y” - General Integrity Key • “N” - SDK Management OTA Key (combined Encrypt / Integrity key as AES GCM is used. • “D” - Script Protection Key • “V” - Signing Key • “K” - Memory Protection key SOURCE is defined based on who requested it as follows: • “A” - Pairpoint • “B” - Customer For example, the S value for an OTA key would be: “F8ANAPPLICATION000CZ0001A0001” Device Scripting The device may support a scripting mechanism that can be used in a variety of ways to deliver services. The scripts may be: • stored locally in the device and be triggered either by events in the device or remotely by the either the DAB or SIM Trust services. • Sent by SIM Trust or DAB - In which case the script is run immediately but not stored. Scripts may be compacted to save space in transit and to save space in the device. Scripts are stored encrypted and tamper proofed at rest when stored in persistent memory. Script Principals • Scripts may be autonomous and atomic. • Scripts may have a priority that determines the order in which they will run for the same trigger. • When multiple triggers occur, the scripts may run in the order of the triggers. • Scripts may have a common set of actions they can use. • Scripts may have local memory that survives only for the life of the script. • Scripts may not be persistent - as in they should carry out one or more actions and end. • Scripts may output to the persistent memory, SIM Trust service, DAB service or a customer service. • The system includes a means of handling script errors. • Scripts may only run if they have not been tampered with. Getting script inputs from Customer applications or sensors The ability to get inputs from the customers device and any attached sensors depends on the interface between the customer application and the SIM Trust SDK. The device may manage the acquisition of data and its presentation to the SDK. At least two types of interface exist: • AT Command Interface - Over this interface, the device is the master and the Modem is the slave. The device 310 can issue commands to the modem to which the modem gives responses. Additionally, the modem can send unsolicited messages but it cannot instruct the device 310. • Function call interface - Over this interface, the device or the modem may be master. To cause an action functions need to be exposed at the modem and functions at the device. Functions may only me exposed by the modem for the device to consume in a similar manner to the AT Command interface. To assist this the functions should be named as equivalents to the AT commands. Script Triggers The following script triggers are defined: • Modem (or device if the SDK is in the device) power on • Network Connected • Network Disconnected • Device triggered - The device software triggers a script • Named Pair updated by device - for instance the device has updated the VIN number value • New IMSI detected • Timer expiry • Geofence event A means to manage which events are triggers and which are ignored is implemented. Script cryptography functions The following cryptography functions are defined: • Generate a new key • Sign a payload • Verify a payload • Create a secure encrypted blob for transmission • Decode a transmitted secure and encrypted blob • Get a random number • Create a secure encrypted blob for storage in insecure memory • Decode a stored secure and encrypted blob Script conditional actions The following conditional functions are defined: • If... Then... Else • Case... Select... • Equal to • Not equal to • Length of string • Greater than • Less than • Mod • AND • OR • EXOR • NOT 5 Script transformation actions The following transformation functions are defined: • String to int • Int to string 10 • Binary to Hex string • Hex string to binary • update string with repeated pattern • add • subtract 15 • multiply • divide • increment • decrement • Split string 20 • Concatenate string • Find in string Script memory access actions The following memory functions are defined: 25 • Clear specified register • Clear and update register • Concatenated string to register • Get specified register value • Store value pair to secure memory 30 • Retrieve value pair from secure memory Script looping actions The following looping functions are defined: • For... Loop... 35 • While... Loop... • Break (from loop) Script output actions The following output functions are defined: • Send Output to DAB • Send Output to Device • Return value to script caller • Silently End script Script Miscellaneous actions The following miscellaneous functions are defined: • Set timer Script error handling actions The following error handling functions are defined: • Action on error • Write to log register New BTID / Session ID scheme The current BTID generation creates long BTIDs that make a significant message overhead, particularly for communication and memory constrained devices. However, many systems are expecting a URI style session ID. The scheme developed for this system and method includes the following properties: • Session ID needs to be unique across the entire server • Session ID needs to appear random (as in not sequential) • Session ID can be numbers or letters (not case sensitive) - the letter O will not be used as it is too similar to zero (so there are 35 usable characters per position) • Ideally Session ID should be based on a simple counter • Session IDs will be generated in a server - The server will be responsible for checking for duplicates. • Session IDs should include key number (2 characters gives possibility of 1225 keys) Session ID string shall be an ASCII string • Session ID should be of the form <unique code>@ securetec.pairpoint.io -the best session will only need to send the <unique code>. • The size of the running part of the session ID should be scoped so that 10,000,000 subscriptions can create 1 BTID every day (3650000000 BTIDs) Possible solution: The number of ASCII letters and numbers needed to represent the SHA256 output is 7. Add 2 characters to represent the key number (gives 1225 possible keys) Add 1 Character to represent the Server being used (allows for multiple servers) We get 10 Character unique code as follows: XXXXXXXKKS Where: XXXXXXX is BASE35(non repeating value that indicates a specific keyset) KK is key number (sequential - assigned by the device) S is server reference This means that the BEST session ID needs only to be XXXXXXXKKS which is 10 chars. The Base 35 coding scheme is as follows: Decimal Number Coded Character Decimal Number Coded Character 0 0 18 I 1 1 19 J 2 2 20 K 3 3 21 L 4 4 22 M 5 5 23 N 6 6 24 P 7 7 25 Q 8 8 26 R 9 9 27 S 10 A 28 T 11 B 29 U 12 C 30 V 13 D 31 w 14 E 32 X 15 F 33 Y 16 G Z 17 H II 34 Note: O may not used as it is too similar to zero. An alternative base 57 coding scheme may be used: Decimal Number Coded Character Decimal Number Coded Character 0 0 29 U 1 1 30 V 2 2 31 W 3 3 32 X 4 4 33 Y 5 5 34 Z 6 6 35 a 7 7 36 b 8 8 37 c 9 9 38 d 10 A 39 e 11 B 40 f 12 C 41 g 13 D 42 h 14 E 43 j 15 F 44 k 16 G 45 m 17 H 46 n 18 I 47 P 19 J 48 q 20 K 49 r 21 L 50 s 22 M 51 t 23 N 52 u 24 P 53 V 25 Q 54 w 26 R 55 X 27 S 56 y 28 T 57 z Other base coding schemes may be used. Figure 12 shows a schematic diagram of an example session identifier derived from the session ID root and data describing the key. In this example, the data describing the key includes a key type ID and a server ID. The key type ID is encoded using the base 35 code table, base 57 code table, or any other base value code table. The server ID may be data (or a code) identifying the requesting server (second server or customer service 320). Different key types or usage may be defined and used within the session ID. These may include but are not limited to: “K” - (000) - Key Agreement; “E” - (001) - General Encryption Key (in the case of AES-xxx-GCM this key will be used for both Encryption and integrity protection); “I” - (010) - General Integrity Key; “D” - (011) - SDK Management OTA Key (combined Encrypt / Integrity key as AES GCM is used; “Q” - (100) - Script Protection Key; “M” -(101)- Memory Protection key; and “S” - (110) - Server sign or encrypt key (not to be used by device). The key type codes shown above may be further encoded. 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. 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. 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. 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. 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. 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. 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. 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. For example, where a single device is shown, many similar or different devices may be included in the system. Similarly, many different servers (having similar functionality) may be included in the system for different customers. 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. ANNEX 1 API descriptions and functional details. airpoint SIM Trust REST API These docs cover the functional and management REST APIs for the Constrained Device Pairpoint SIM Trust Server These REST APIs are split into 2 sections: Functional The functional REST APIs allow customers to perform the following SIM Trust cryptographic related actions: » rstrieveTrusiKsyS - Retrieves a SIM Trust key based on the customer ID, Application ID end Sessionlabel (provided forthat key). « verlfyDataS - Verifies data based on Customer Id, Application ID, the data to be verified and the signatureblob. » deoryptDataBtob3 - Decrypts a data blob and returns both it and a validity flag based on Customer id, Application ID and the enoryptedbiob. The management REST APIs allow customers to perform the following adminastrative functions: To Re Added Functional APIs The functional REST APIs allow customers to perform SIM Trust cryptographic related actions. RetrievetrustkeyS This API returns the Key used by the Device for that session ID, when that key will expire and the associated I MS I Parameters No parameters Request body Example Value Schema Exempt® Vales Schema Responses Code Description 200 Successful Response Media type apptatiOT / json Contsols Accept header. Example Value Schema 'Vi-Val^ ; teas 422 Validation Error Media type spptatlOT / jsoe Example Vatu® Schema Links Ato / toAs Ato / mks / ®2s / e®tMerk / sM / deerypWataSl©b3 / DecryptdatabiobS This API decodes and returns the data based an the submitted encrypted databiob, the customer ID and the application ID and Parameters Try it out This APi encrypts the submitted data and returns an encrypted databieb. if an appiicationid is not supplied the appiicationld wiH be set to ’SiMTRUSTJsERVER1. Parameters No parameters Request body Erampls Value Schema Responses Oswriptton Successful Response Media type | appfcatton / jssm Eompi® Veto® Schema 422 Validation Error Media type I appfcatton / jTOH Example Veto® Schema Cod® heseripftan Example Wa® Lmks Management APfe W1 The management REST APIs allow customers to perform adminastratlve functions. Schema® HTTPValidationEnw Collapse ail abject detail Coilapse all array<object> ■ it«s A Collapse all object loc* a Collapseall array<(strlng J integer)> Ite® A Collapse all (string | integer) Any of Collapse all (string | integer) #e string j #1 integer ■ sisgxK string type* string KeyReq uest3lnTy pe Collapse ail abject applicationld* string KeyM* string KeyRequest3OotType elapse an object keyMaterialHesStr* string expiratiorsTimestaKtpUTC* string IMSI* string ValidationEnw collapse eii object ioc* Collapssall arrays (string | int@ger)> ■ Items Collapse all (string j integer) : Any of Collapse all (string | integer) string Ot integer stsg* string type* string @n©fyptDataBlob3lnType * Collapse all object deviceld* string applicationld Collapse ell (string null) Any of Collapse all (string | null) #S string null datatebeenerypted* string datatobetamperprotectedonly* string oncryptDM^Btob3Outlyps A Coiiapseaii object encrypteddataheader* string ertcrypteddatavalua* string encrypteddatatag* string Collapse all object dwieeid* string applications Collapse ell (string noli) ■ Any ofA Collepse all (string | null) ■ #8 string #1 null dBtatosign* string SSgnDat330utTyp@ A Collapse all object encrypteddataheader* string encrypteddatatag^ string wdfyData3lnType collapse ail object detatebevsri-fiecF string signatureblob* string v®rifyD^te3OutTyp® corpse ail object dataisvalid* boolean

Claims

1. A method for sharing keys between a device and a second server, the device having a secure element and a software application comprising a plurality of group keys and associated session identifiers, the method comprising the steps of:the software application receiving from within the device a request for a key, data describing the requested key and a requester secret shared with the second server;in response to the request for the key, the software application selecting one of the plurality of group keys and an associated session identifier;the device sending a message to a first server encrypted using the selected group key, the message including the associated session identifier and an identifier of the secure element;the first server decrypting the message using the group key identified by the associated session identifier;in response to the message the first server:obtaining an authentication vector based on the identifier of the secure element, the authentication vector comprising key materials and an authentication request,generating a request session identifier root, encrypting, using the group key associated with the session identifier, a response formed from the authentication request and the request session identifier root,sending the response to the device, andgenerating a master key based on the key materials;the software application decrypting the response using the selected group key and sending the authentication request to the secure element;the secure element authenticating the authentication request and when valid generating the key materials from the authentication request and a key stored within the secure element;the software application deriving the master key based on the generated key materials;storing within the device the master key with the request session identifier root;the software application deriving one or more keys based on the master key, the data describing the requested key and the requester secret;the software application generating a key label for each of the one or more keys comprising the session identifier root and the data describing the requested key;the device sending the key label to the second server;the second server sending the key label and the requester secret to the first server;the first server deriving the one or keys based on the master key, the key label and the requester secret; andthe first server sending the one or more keys to the second server.

2. The method of claim 1, wherein the secure element is a IIICC, a hardware security module, or an integrated SIM, iSIM.

3. The method of claim 1 or claim 2 further comprising the step of the device and the server securing communications using the one or more keys.

4. The method of claim 3, wherein the step of the secure element of the device authenticating the response further comprises the secure element generating a response, RES, based on the key materials and further wherein securing the communications includes sending RES to the server.

5. The method of claim 3 or claim 4, wherein the communications are secured using advanced encryption standard, AES.

6. The method according to any previous claim further comprising the step of the device and / or the server signing a message using the one or more keys.

7. The method according to any previous claim, wherein the message and / or the response to the message are encrypted using any one of:a previously generated key, wherein the message includes a session identifier associated with the previously generated key; ora pre-shared key.

8. The method according to any previous claim, wherein the plurality of group keys are pre-shared keys common to a plurality of separate devices.

9. The method according to any previous claim, wherein the session identifier includes an encrypted identifier of the device.

10. The method of claim 9, wherein the encrypted identifier of the device is the device international mobile subscriber identity, IMSI.

11. The method of claim 9 or claim 10, wherein the server obtains the authentication vector from a home location register, HLR, based on the identifier of the device.

12. The method according to any previous claim, wherein the message further comprises an identifier of the serving network and the IMEI of the device.

13. The method according to any previous claims, wherein a secure hash algorithm, SHA, is used to derive the one or more keys.

14. The method according to any previous claim, wherein the software application is executed within the secure element of the device or within an application store of the device.

15. The method according to any previous claim, wherein the derived one or more keys are stored within the device and associated with the session identifier.

16. The method according to any previous claim, wherein the derived one or more keys are stored within the first and / or second server.

17. The method according to any previous claim, wherein the authentication vector includes RAND and ALITN.

18. The method according to any previous claim, wherein the session identifier includes data indicating a purpose of the one or more key.

19. The method according to any previous claim, wherein the message includes any one or more of:data indicating a counter incremented each time the session identifier is used; and an identifier of a serving network.

20. The method according to any previous claim further comprising the step of: repeating the method steps to derive one or more new keys using a different session identifier.

21. The method according to any previous claim, wherein the data describing the requested key comprises any one or more of:key number; and / orkey usage.

22. The method of claim 21, wherein the key usage comprises any one or more of: general encryption key;general integrity key;application management key;script protection key;memory protection key; and server key.

23. The method according to any previous claim, wherein the step of the software application generating a key label further comprises compressing the data describing the requested key before incorporating it in the key label.

24. The method according to any previous claim, wherein the step of the first server sending the one or more keys to the second server further comprises the one or more keys being sent as a REST API response.

25. The method of claim 24, wherein the REST API response further comprises an expiry datetime; and / or data describing the device.

26. A device comprising:a secure element;a processor; andmemory storing computer-executable instructions that, when executed by the processor, cause the device to:receive, by a software application from within the device, a request for a key, data describing the requested key and a requester secret shared with a second server;in response to the request for the key, the software application selecting one of the plurality of group keys and an associated session identifier;send a message to a first server encrypted using the selected group key, the message including the associated session identifier and an identifier of the secure element;receive from a first server a response to the message, the response including an authentication request and a request session identifier root;decrypt the response using the selected group key and sending the authentication request to the secure element;the secure element authenticating the authentication request and when valid generating key materials from the authentication request and a key stored within the secure element;derive, by the software application, a master key based on the generated key materials;storing within the device the master key with the request session identifier root;the software application deriving one or more keys based on the master key, the data describing the requested key and the requester secret;the software application generating a key label for each of the one or more keys comprising the session identifier root and the data describing the requested key; andthe device sending the key label to the second server.

27. A system comprising:the device of claim 21; anda first server comprising:a processor; andmemory storing computer-executable instructions that, when executed bythe processor, cause the first server to:in response to a message received from the device:obtain an authentication vector based on the identifier of the secureelement, the authentication vector comprising key materials and an authentication request,generate a request session identifier root,encrypt, using the group key associated with the session identifier, a response formed from the authentication request and the request session identifier root,send a response to the device,generate a master key based on the key materials,receive from a second server a key label and a requester secret, derive the one or keys based on the master key, the key label and the requester secret, andsend the one or more keys to the second server.

28. The system of claim 27, wherein the computer-executable instructions further cause the server to retrieve the authentication vector from a home location register based on an identifier of the device included in a session identifier within the received message.

Images