GB2547039A

GB2547039A - Secured service provisioning

Info

Publication number: GB2547039A
Application number: GB1602161.0A
Authority: GB
Inventors: Bone Nicholas
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2016-02-05
Filing date: 2016-02-05
Publication date: 2017-08-09
Also published as: GB201602161D0

Abstract

Method and system for provisioning a subscription of a service to a device comprising: receiving a communication from a device, the communication protected by first provisioning data installed on the device. Authenticating the communication using data corresponding to the first provisioning data. Sharing a newly generated secret with the device. Generating a session key Ksession based on previously existing data available to the device and the newly generated shared secret. Using the session key Ksession to establish protected data, the protected data enabling the device to recover second provisioning data from a subscription manager (SM2).

Description

SECURED SERVICE PROVISIONING Field of the Invention

The present invention relates to a method and apparatus for provisioning a subscription of a service to a device and in particular but not limited to a machine-to-machine device operating within a cellular network.

Background of the Invention

In a cellular or other network, some methods for a device to access services require the device to have a subscriber identity, typically encoded within a secure environment such as a UICC, SIM or embedded SIM, for example. The subscriber identity may be given provisioning data (usually in the form of cryptographic material), which allows the device to subscribe to one or more services. Subscription may involve the addition of the subscriber identity to a subscriber profile repository or subscriber list held by a subscription manager. The addition of the subscriber identity to such a repository can be dependent on the device presenting suitable provisioning data, which may be checked and validated. Providing the device (or the UICC, SIM or embedded SIM) with these provisioning data is known as provisioning the subscription of a service.

Existing SIM cards (UICC) may be personalised individually with unique keys and identifiers at a secure personalisation centre. This may be operated by a SIM vendor or manufacturer like Gemalto or Giesecke and Devrient.

The SIM cards are then distributed from that centre either to operator warehouses, or increasingly in the case of machine-to-machine (M2M) devices, directly to a modem or whole device manufacturer (OEM) for integration as a component part. The OEM then has to personalise the rest of the device e.g. with a flash image, unique device ID, MAC address and possibly other keys .

The UICC needs to be loaded with an initial IMS1/¾ and profile (a so-called "provisioning subscription") in order to connect to a mobile network and download a permanent subscription. WO2015/181359 describes a scheme that improves the personalisation of SIM cards and other UICCs and especially those that are optimised for M2M applications. This scheme improves the efficiency and flexibility of the provisioning process. However, and more generally, additional security may be required when passing any key material relating to specific SIM cards from the manufacturer (or personaliser) to other parties. Weaknesses in this process are highlighted by https ://theintercept.com/2015/02/19/great-sim-heist/ retrieved 29 January 2016).

Furthermore, even if the initial distribution and provisioning of keys remains secure, it is feasible that a successful cryptographic attack on key exchange protocols such as ECDH, will eventually develop (perhaps within the lifetime of 5G networks). This could come about by advances in quantum computing, for example. In such a scenario, the initial provisioned keys (e.g. K±, Kgroup, Koem and Ksml) may remain secure but there may be successful attacks on subsequent provisioning actions using key exchange protocols.

This problem may also extend to different protocols intended to provide perfect forward secrecy, such as IPsec and TLS, for example.

Therefore, there are required a method, system and apparatus that overcomes these problems.

Summary of the Invention

Telecommunications subscription key management is achieved by performing a key derivation operation or function with inputs from an existing shared secret and a new shared secret (e.g. obtained using a Diffie-Hellman protocol). Preferably, the existing shared secret is pre-loaded or provisioned onto a device (e.g. K±) and known to a subscription manager. This technique therefore, effectively converts a weak (or vulnerable) initial secret into a strong shared secret (e.g. new K± or Kadd) that is used to obtain a service from a provider.

In accordance with a first aspect, there is provided a method of provisioning a subscription of a service to a device, the method comprising the steps of: receiving a communication or message from a device, the communication protected by first provisioning data installed on the device; authenticating the communication using data corresponding to the first provisioning data; sharing a newly generated secret with the device; generating a session key KseSsion based on previously existing data available to the device and the newly generated shared secret; and using the session key KseSsion to establish protected data, the protected data enabling the device to recover second provisioning data from a subscription manager (SM2). The method may operate within a wired or preferably wireless or cellular network such as a 3GPP or 5G environment, for example. This allows a silicon vendor or manufacturer to provide a secure execution environment (SEE), e.g. UICC, SIM or other component, to a device manufacturer (e.g. a M2M device or OEM manufacturer), who can provision the SEE with device manufacturer provisioning data. The mobile operator does not have to ensure that the device manufacturer provisioning data is itself provisioned very securely, as it will not itself be used to access a service. Typically, on first power up of the new device the initial or first provisioning data may be used to obtain further or second provisioning data (e.g. a key for the device to subscribe to the required service) or other additional key material. If the initial provisioning data is compromised then the loss can be more effectively controlled and does not lead to the compromise of the key used to subscribe to the service. Preferably, the initial provisioning data is changed regularly by the device manufacturer and/or silicon manufacturer between device manufacturing runs to further improve security. This method has particular benefits within machine-to-machine (M2M) applications but can be applied more widely.

Furthermore, this method can more effectively resist breaches in security relating to the loss or interception of initial keys like Κ±, which if detected, may otherwise require UICCs such as SIMs, to be discarded. The existing data available to the device may be first provisioning data. The existing data may also be available to the subscription manager or a further or external server or further subscription manager.

Optionally, use of the session key KseSsion to establish data comprises sending the data to the device protected by the session key KseSsion (e.g. encrypted using the session key). In another implementation, a key is derived from the session key Ksession by the device. Similarly, the subscription manager (SM2) (or further subscription managers) can also derive the key or a corresponding key, from the session key KseSsion· This also reduces the amount of data sent to the device.

Advantageously, the method is used to provide a new subscription key to a device. This may optionally replace an old, existing or pre-provisioned subscription key.

Preferably, sharing the newly generated secret with the device comprises executing Diffie-Hellman key agreement protocol and more preferably, by executing an elliptic curve Diffie-Hellman (ECDH) key agreement protocol.

Optionally, the existing data available to the device includes any one or more of: an authentication key {K±); a group key (Kgroup) ; an OEM key (Koem) ; a previously shared secret; a previous session key; measurements of a radio environment; or timestamps. Other existing data may be used, including other previously provisioned, derived or generated data. Any or all of these data may be stored within a UICC or SEE.

Optionally, the protected data enabling the device to recover the protected second provisioning data is provided to the device or to the subscription manager (SM2) or derived by either or both. For example, an initial subscription manager may provide (or "make available to") a different subscription manager the means to authenticate the device. In this example, the initial (further) subscription manager may provide an assurance that cryptographic material within the message is associated with the device.

The initial subscription manager may create a "Device Cert" which can be used by the other subscription manager to obtain assurance about the device. This Device Cert may be provided by the initial subscription manager to the device, and then by the device to the other subscription manager. But it does not necessarily need to be sent to the device; instead, the initial subscription manager may make the Device Cert available to the other subscription manager by other means .

Advantageously, the communication may comprise a signature verification key Vgen corresponding to a signature key Sgen of the device. This message may also be one way of identifying the device.

Preferably, Vgen and Sgen are generated after the first provisioning data are installed on the device. However, it may be generated before the first provisioning data are installed on the device.

Preferably, the step of authenticating the communication is carried out by a further subscription manager (SMI). In one embodiment, the subscription manager may be an initial or further subscription manager that does not provide the second provisioning data, but instead only provides or establishes protected data enabling the device to recover the protected second provisioning data from the (different) subscription manager allowing subsequent provision to the service.

However, in another embodiment the same subscription manager will both authenticate the message and provide or establish the protected second provisioning data. In one example the first provisioning data may be stored within the device or a SEE of the device in advance.

Optionally, the initial or further subscription manager (SMI) may be a separate component, entity, physical device, server or computer to the subscription manager (SM2).

Preferably, the method may further comprise the step of the further subscription manager (SMI) providing a communication acknowledgment comprising Vgen signed by a signature key Ssml of the further (initial) subscription manager (SMI). This allows the device to authenticate the further (i.e. initial) subscription manager.

Preferably, the existing data available to the device comprises key material Kexisting that is shared with the further subscription manager (SMI).

Optionally, the existing data available to the device may be a verification key, Vsmlr of the further subscription manager (SMI). Other existing data may be used.

Preferably, the further subscription manager (SMI) may receive the communication from the device.

Optionally, the method may further comprise the step of: the further subscription manager (SMI) obtaining or establishing data (Vsm2 or data derived from a session key) to enable the device to authenticate the subscription manager (SM2) when recovering the protected second provisioning data, and wherein the further subscription manager (SMI) provides the device with the obtained data (Vsm2) or the device establishes such data from the session key. This may be through a secure connection between the two subscription managers .

Optionally, the data enabling the device to authenticate the subscription manager (SM2) may be a signature verification key Vsm2 of the subscription manager. It may also be a symmetric key. This allows the device to authenticate the subscription manager.

Preferably, Vsm2 has a corresponding signature key Ssm2.

Optionally, the first provisioning data may include or may further include any one or more of a group key, Sgr0uPf and a device key, Sdevice/· wherein SgroUp is provided to a plurality of devices and wherein Sdevice is unique to the device, and further wherein authenticating the device comprises the step of the device signing the communication using Sdevice and Sgroup.

Preferably, the subscription manager may use a key Vdevice to verify the signature of the communication constructed using Sdevice and/or uses a key Vgroup to verify the signature of the communication constructed using SgroUp, wherein Vdevice forms a key pair with Sdevice and Vgroup forms a key pair with SgroUp. The elliptic curve digital signature algorithm (ECDSA) or another algorithm may be used with these keys.

Optionally, the first provisioning data may further comprise a symmetric group key, Kgroup, and/or a symmetric device key, Kdevice or one of the keys may be symmetric, while the other is asymmetric.

Preferably, the key pair Vdevice and Sdevice may be generated by a separate entity to the entity that generates the key pair Vgroup and Sgr0up (e.g. a manufacturer of the SEE) .

Preferably, the second provisioning data may be one or more additional secrets Kadd, the method further comprising the steps of generating the one or more additional secrets Kadd, and providing the one or more additional secrets Kadd to the device. Kadd may be operator credentials, for example.

Optionally, the one or more additional secrets Kadd may be generated in advance. This may be on the server-side, for example .

Optionally, the one or more additional secrets Kadd may be protected using a session key KseSsion'.

Optionally, ΚεβΞΞ±οη<· may be identical to Ksession.

Optionally, the one or more additional secrets Kadd are provided to the device by deriving the one or more additional secrets Kadd from the session key KseSsion' using a key derivation operation carried out within the device.

Advantageously, the session key KseSsion' may be generated based on further existing data available to the device and/or a further newly generated shared secret.

Optionally, the further newly generated secret may be generated by executing a Diffie-Hellman, DH, or elliptic curve Diffie-Hellman, ECDH, key agreement protocol.

Optionally, the further existing data available to the device may include any one or more of: an authentication key, K±; a group key, KgroUp', an OEM key, Koem; a previously shared secret; a previous session key; measurements of a radio environment; or timestamps.

Preferably, the further existing data available to the device may comprise key material KexiSting' that is shared with the subscription manager (SM2).

Optionally, Kexisting- may be identical to Kexisting.

According to a second aspect, there is provided a system for provisioning a subscription of a service to a device, the system comprising: a secure communications interface; a logic configured to: receive a communication from a device, the communication protected by first provisioning data installed on the device; authenticate the communication using data corresponding to the first provisioning data; share a newly generated secret with the device; generate a session key KseSsion based on previously existing data available to the device and the newly generated shared secret; and use the session key KseSsion to establish protected data, the protected data enabling the device to recover second provisioning data from a subscription manager (SM2).

Optionally, the logic may be part of a further subscription manager. This further subscription manager (SMI) may be a separate component or entity from the subscription manager (SM2). The system may include one or more subscription managers, a plurality of devices, and a communications network (e.g. cellular) for communicating between the one or more subscription managers. Preferably, the system may include a server or other entity for generating keys or key pairs for initially provisioning the devices. Preferably, the system may include a server or other entity for generating keys or key pairs for including in secure execution environments to be added to the devices. These servers or other entities may also communicate with the one or more subscription managers over the communications network, which will preferably be secure .

Preferably, the part or all of provisioning data may be stored within a secure execution environment, SEE, within the device. This improves security. Furthermore, the processing or generation of cryptographic material may take place within the SEE. For example, KgroUp may be stored but not Kdevice·

Optionally, the first provisioning data may include a subscription manager verification key, Vsmi, allowing the device to verify communications from the first or initial subscription manager. Such communications may be protected using a first signature key, Ssmi, wherein Vsmi and Ssmi form an asymmetric key pair. The keys may be generated by an ECDSA or another algorithm, for example. VSmi and Ssmi may be generated in advance and Vsmi applied to batches of devices (or SEE to be incorporated into devices) . Preferably, Vsmi and Ssmi are changed at intervals to improve security. Ssmi is known by the subscription manager (i.e. an initial subscription manager).

Preferably, the subscription manager may use a key Vdevice to verify signatures constructed using Sdevice and/or use a key Vgroup to verify signatures constructed using Sgroup/· wherein Vdevice forms a key pair with Sdevice and VgroUp forms a key pair with Sgroup· Again, ECDSA or another algorithm may be used with these keys.

Optionally, the key pair Vdevice and Sdevice may be generated by a separate entity to the entity that generates the key pair Vgroup and Sgroup. For example, Vdevice and Sdevice may be generated by the manufacturer of the device (e.g. M2M device) . Vgroup and Sgroup may be generated by the manufacturer of the SEE, or a component hosting the SEE, for example.

The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium.

The computer system may include a processor such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and non-volatile storage medium. A computer-readable medium may be included to store the logic or program instructions. The different parts of the system may be connected using a network (e.g. wireless networks, cellular and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operation system such as UNIX, Windows (RTM) or Linux, for example.

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 schematic diagram of a portion of a system for provisioning a device including a first subscription manager; FIG. 2 shows a further portion of the system of FIG. 1 including a second subscription manager; and FIG. 3 shows a flowchart of a method for provisioning a device using the system of figures 1 and 2.

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

As a guide to notation, Kx denotes a generic secret key. This may be a symmetric key, or the secret half of an asymmetric key-pair. Elliptic Curve Digital Signature Algorithm (ECDSA) keys are written as Sy for a signature key, and Vy for a signature verification key (so that Sy and Vy form a key-pair). Elliptic Curve Diffie-Hellman (ECDH) keys are written as Privz for a private key (including the field parameters and private exponent) and Pubz for the corresponding public key. A secure execution environment (SEE) may come already provisioned with a group key (Kgroup) from the silicon vendor or manufacturer, preferably as part of the ROM mask. This may be either a symmetric key, or the signature key SgrouP of an asymmetric keypair (Sgroup, Vgroup) . To protect against man-in-the-middle attacks, an Initial (or first) Subscription Manager may have an asymmetric key pair {Ssml and Vsml) and the SEE will come provisioned with the initial subscription manager verification key (Vsml) . A device-unique key {Kdevice) may be loaded once the SEE is integrated by a full M2M device manufacturer (OEM). Again, this may be a symmetric key, or the signature key Sdevice of an asymmetric keypair (Sdevice, Vdevice) ·

As provisioning of these keys may be achieved under a low level of security, these keys should be used only once per device and then replaced with persistent keys. The device may also be provisioned with an initial subscription key (K±) which may also be provisioned under a low level of security. But even if the initial subscription key was provisioned securely, the scheme can still be used to update the K± remotely.

The Initial Subscription Manager knows the server-side signature key {Ssmi) , the group key (Kgroup if symmetric or Vgroup if asymmetric) , and the OEM-provided keys (.Kdevice if symmetric, or Vdevice if asymmetric) . The Initial Subscription Manager must ensure that no other entity knows Ssmi, and that no other entity knows both Kgroup and Kdevice· A vulnerability may exist within the interfaces between the Initial Subscription Manager, the silicon vendor and/or the OEM used to exchange keys (see for example, https ://theintercept.com/2015/02/19/great-sim-heist/ retrieved 29 January 2016). The Initial Subscription Manager could, for example, generate a symmetric group key or a group key-pair and provide Kgroup to the silicon vendor, or receive a symmetric KgrouP after it has been generated by the silicon vendor, or receive the group verification key Vgroup after the group key-pair has been generated by the silicon vendor. The Initial Subscription Manager could, for example, provide secret keys Kdevice and corresponding serial numbers to the OEM for loading to devices, or else receive symmetric keys (e.g. Kdevice) from the OEM after they have been loaded to each device, or receive verification keys Vdevice from the OEM after the corresponding signature keys Sdevice have been loaded to each device. Again, these transfers involve risks. 1. Preferably, the group key (Kgroup) and the initial server-side key (Ssmif Vsml) should be changed regularly when producing new batches of devices. 2. The initial keys (Kgroup, Kdevice, and Vsml) , should ideally be used only once per device, at first authentication with the Initial Subscription Manager, then replaced with fresh device-specific keys. If the initial K± is provisioned under a low level of security, it should also be used only once and then immediately replaced. 3. At least one fresh ECDSA keypair (Sgen, Vgen) should be generated on the device within the SEE. A new ECDSA verification key Vgen shall be reported to the Initial Subscription Manager (ISM, or SMI), integrity-protected using both the group key and the OEM device key, and then signed by a "liable representative" (e.g. the Initial Subscription Manager themselves) . The Vgen signed by the liable representative is called the "Device Cert". The ISM (SMI) shall return an acknowledgement to the device that Vgen has been received and verified. This acknowledgement may consist of the Device Cert itself, if signed using Ssmi! if not, the acknowledgement shall be signed using Ssmi.

Figure 1 illustrates schematically the system 10 of a device 20 having a SEE 30 and Initial Subscription Manager 40, described above. The steps of this process are also shown in table 1.

Table 1 4. At least one fresh ECDSA verification key Vsm2 shall be transferred to the device to authenticate each Subscription Manager used for further update operations. The first time this operation is performed, the device must contact the Initial Subscription Manager; after that, it may contact any known Subscription Manager to introduce a new one. The key-pair (SSm2r Vsm2) is generated preferably in advance by each Subscription Manager, and SSm2 stored safely (there could, for example be Ssm3, Ssm4, SSm5r S,smn, etc. for further Subscription Managers) It is safe to use the same ECSDA key Ssm2 at the Subscription Manager for multiple devices; however, if the SM has several ECDSA keys, then the SM will keep track of which device has which key. Other or additional keys (Kadd) may be shared in this way.

Direct signing of one ECDSA key by another (e.g. signing Vsm2 using Ssmi) is not recommended, as it is hard to revoke such a signature. Instead, such a verification key should be encrypted and integrity-protected using session keys (KsesSion) .

Before Ksession is generated, an ECDH key is derived at the device and SM. This is shown in Figure 1 (and the top part of table 2) as: f*(Privd, Pubs) = Kecdh on the device side; and f(Privs, Pubd,)= Kecdh on the SM.

However, using Kecdh alone to protect any further provisioning creates a risk that future attacks on Diffie Heilman key exchange (for example based on quantum computers) will allow an attacker to recover the new key material. Such a risk can be reduced by instead using existing data or an existing key as well as Kecdh to generate Ksession, which is then used to protect further communications and transfers (see bottom half of table 2) .

Table 2

Ksession is derived by both the device and the SM using a key derivation function (KDF). The KDF uses one of the existing keys known to both the device and the SM, and Kecdh.

Ksession ~ KDF(fCecc(h/ KeK±sting)

Kexisting may include any one or more of:

An existing K± however secure or insecure (including a K± which may have been pre-loaded at factory, or agreed by any previous run of the key exchange protocol),

An existing KgroUp or Kdevice (again however secure or insecure)

An existing Vsm or V±sm, provided this is not trivially discoverable by the attacker

Any other data that may have been agreed by previous runs of the key exchange protocol (such as other previous values of Kecdd or Ksession or Kadd) ,

Any other data that may have been exchanged between or reliably discovered by the two parties but which is not trivially discoverable to the attacker (e.g. precise measurements of the radio environment, precise timestamps of various messages).

The KDF may be, for example: A secure hash function like SHA-2 or SHA-3 An iterated secure hash function (e.g. the same function applied 1000 times)

An HMAC

A block cipher like AES

Any other cryptographic function having the property that unless Kecdh and KexiSting are both known, it is impossible (or highly unlikely) to predict the output value Κεβεε±οη.

Both the device {Sd) and server-side (Ssmi) ECDSA keys should sign the exchange. To avoid the costs of repeatedly generating ECDH keys, a fixed field and generator may be used, but with variable private exponents chosen.

Figure 2 illustrates schematically the system of the device 20 and Subscription Manager 50, described above. The steps of this process are also shown in table 2. The steps shown in table 2 and figure 2 may be carried out by the same subscription manager as those of table 1 and figure 1 (i.e. an initial subscription manager) or any subscription manager that is already known to the device. 5. Additional secrets Kadd (in particular operator credentials Kop) may be generated at the server-side. They may be generated in advance and (safely) stored in anticipation, and then encrypted and integrity protected using session keys (Ksession<) . Alternatively, if they have not been generated in advance, they may be generated from ΚεβΞΞίοη' by a suitable key derivation operation which may also be implemented on the device. Such additional secrets must not be encrypted using the group key (Kgroup) or OEM key (Kdevice) . Kgroup and Kdevice should ideally be used once, but never again.

Table 3

Observe that Kexlsti„g' may be the same key as KexiSting, or it may be any other existing key known to both the device and SM2 before the start of step 5.

As in step 4, both the device (Sd) and server-side (Ssm2) ECDSA keys should sign the exchange. If they do not do so, or do not check each other's signatures, then in case of a Man In the Middle (MITM) attack, the peers will get all the way to the end of the protocol, except that they find they derive different session keys at the end (and the MITM attacker doesn't know either key, because he doesn't know the "old" or existing secret, Kexisting') · When the peers try to use these keys, something now breaks. They then need to go back and try the whole key derivation protocol again, which is wasteful of system resources.

Trying to use the keys, failing, and then resuming the protocol also creates the risk that an attacker may gain enough information to learn the value of Kexisting< after performing the attack the first time. For example, values of the "old" secret Kexisting' may be guessed to see what the session keys would have been if that guess was right. These may be checked to determine if this is consistent with the messages sent by the peers when trying to use the session keys. If the "old" or existing secret is weak in any way (e.g. some bits known and the remainder may be guessed), then the attacker may be able to learn the "old" existing secret before the peers try the protocol again.

The use of signatures thus provides a valuable enhancement to identify that someone is attempting to MITM the key exchange. The peers will notice and immediately break off (i.e. detect a failed authentication of one or more messages). The failed message can then be flagged for investigation and may be used to trace the attacker .

Even if an attacker happens to learn the "old" shared secret before (or during) a MITM attack then the ECDSA signature from the (initial) subscription manager still can't be forged, so the MITM attacker won't escape detection.

The attacker might be able to impersonate the device (to the initial subscription manager) , but the device itself should fail the protocol and report the failure, or will try again (which the subscription manager can then detect). The device owner may complain (flag or otherwise communicate) that the protocol keeps failing (and this can be used by the subscription manager to detect that something was wrong). The system may use any or all of these procedures, checks or monitoring techniques to recover from an attack.

Optional Features/Variations:

Steps 3, 4 and 5 are very similar in their structure, and indeed it is possible to combine two of them (or all three of them) by concatenating the outgoing and incoming messages for each step; this reduces the total number of passes required for the protocol, and hence reduces the overall execution time for the protocol. If steps 4 and 5 are combined, then Κεβεε±οη' may be the same key as Κεβεε±οη. A safer way to handle errors is that if the device fails to receive a response from the server (or if the response is invalid), then it may re-start the whole protocol.

An explicit acknowledgement message from the device may be sent at the end of the protocol, or there may be an implicit acknowledgement by successful use of the credentials delivered in Step 5.

Preferably, there should also be a backoff policy to suppress large numbers of failed authentication attempts and protocol restarts.

These features avoid the "detour" though still require a unique personalization at the OEM. However, the OEM usually has to provision something unique per device (e.g. a serial number or MAC address) so it is relatively straightforward to inject a unique key at the same time.

Typical device OEMs may not have a reputation for secure key generation and key handling. However, one advantage of the present system is that an OEM-provided device key would not have to be hugely trustworthy by itself, since the device will be authenticated by a combination of the device key (from OEM) and group key (from silicon vendor) as well as a newly generated shared secret and then the OEM key will be replaced. Therefore, an attacker would need to compromise old and new key material/secrets to impersonate the device. For example, the existing key may be equal to or derived from a serial number or MAC address. Provided the device Serial Number/MAC address is not known to the attacker in advance (and provided the derived key Kdevice is only used once) , this may provide sufficient security.

Clearly, a risk is that the group key may itself become compromised by a physically invasive attack on just one SEE. The ability of even high end smart cards to protect "master" keys is mixed: they have been extracted in PayTV solution, whereas operator algorithm configuration parameters (shared across multiple SIM cards) generally have not been extracted: the likely reason is that these have little value by themselves to an attacker. However, this risk is mitigated by the use of a new shared secret to generate a different session key every time.

Another advantage is that the form factor of SEE becomes highly flexible: it no longer needs standardized contacts for injecting key material at a personalization centre, and no longer needs its own dedicated packaging and card reader (or its own pins/bus) within the device.

The SEE silicon could for instance be transmitted to the OEM in wafer form, for integration into an existing package (as for instance with InSIM). This is still not "soft SIM", since the SEE would still be protected e.g. against invasive physical attacks, and side channel attacks.

In one example implementation, a single wafer may consist of secure components (the SEE) and non-secure components (e.g. a modem or baseband core). This means a single wafer can be cut into dies (with each die receiving both a secure and a non-secure component), and then one die inserted per chip package .

In summary, the method may be described as a set of steps of a protocol. The end result of the protocol is for the device 20 to be subscribed to a service by a subscription manager 50 with provisioning data stored within the device. Initially, the device 20 will have installed keys Kgroup and Kdevice (i.e. first provisioning data). As described previously, these may be symmetric or asymmetric keys. The device will generate the key pair Sgen/· Vgen 100. Vgen is sent as part of a message protected by Kgroup and Kdevice 105 to the initial or further subscription manager 40 (SMI). The subscription manager 50 (SM2) and further subscription manager 50 may be functions of the same entity (i.e. a single subscription manager) or separate entities.

Vgen and Sgen form a key pair where Sgen may be used to sign messages .

The subscription manager 50 generates the key pair Ssm2, Vsm2. This may be done in advance or before the protocol executes .

The further (or initial) subscription manager 40 receives from the subscription manager 50 Vsm2. This should be by a secured connection (not shown in the figures).

The further subscription manager 50 has already generated a key pair Ssmi/· Vsmi. The further subscription manager 50 sends a confirmation of receipt of Vgen to the device 20 by signing it with Ssmi 110. A Diffie-Hellman key exchange is set up between the device 20 and the further subscription manager 40 (steps 115-130). This provides the new shared secret, which is used together with the existing material to provide a session key. The session key is used to provide the device 20 with Vsm2.

The purpose of this is to enable the device 20 to authenticate the subscription manager 50 when it recovers the second provisioning data (Xadd) to be able to subscribe to the service. Whilst authentication of the subscription manager 50 with the device 20 is preferable, the device 20 may be provisioned to the service by the subscription manager 50 without such precautions but with increased risk to the device subscriber .

With the device 20 now in possession of data that allows the device to securely recover the second provisioning data (Kadd) r the subscription manager 50 and the device 20 can initiate their own Diffie-Hellman key exchange (135-150) to set up a session key Κεβεε±οη'. The second provisioning data (Kadd) being sent to the device 20 protected (in this embodiment, both signed and encrypted) by Ksession'.

Figure 3 shows a flowchart of a method 200 for provisioning a subscription of a service to a device. The subscription manager 50 is used to subscribe the device 20 to the service. First, temporary or single use provisioning data are installed on the device 20 at step 205. At step 210 the first provisioning data is used to protect a message sent from the device 20 to the further subscription manager 40. The first provisioning data is authenticated by the further (initial, SMI) subscription manager 40 at step 220.

If authentication is not successful 230 then the process stops 240 (and has to restart) or an error is returned.

If authentication is successful 230 then the further subscription manager 40 provides the subscription manager 50 with data that may be subsequently used to authenticate the device for provisioning at step 250 or this is achieved by establishing a session key to derive such data. In addition, SMI may provide Vsm2 to the device, and the device then uses this to authenticate SM2. The subscription manager (SM2) 50 sends the protected second provisioning data to the device 20 at step 260. As the further subscription manager 50 has already sent the device 20 data necessary to recover the protected second provisioning data (or the device 20 and the further subscription manager 50 have otherwise established such data from a session key) then the device 20 can obtain or derive the protected second provisioning data and use it to obtain the service.

At step 270, the second provisioning data is either successfully received, in which case the device is subscribed to the service (step 290) or if not then the process stops (step 280).

The service may include: voice calls, data communication, SMS, MMS, 3G, 4G, LTE or other services, for example.

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, the two initial keys are described as coming from "the silicon vendor" and "the full M2M device manufacturer (OEM)". However, these may be any "first party" and "second party". Furthermore, the public (verification) part Vgen of that key pair is sent to the Initial Subscription Manager 40, signed by Kgroup, Kdevice. Kgroup and Kdevice are not necessarily installed first with the key pair generation and public key export happening later. An alternative order of events would be for at least one of Kgroup and Kdevice to be installed AFTER the key pair generation, although still before the public key export. A session key can be any key that is derivable by, received by or available to different parties of a communication or message, for example. The session key may be temporary and used only for one or a number of communications. The session key can be symmetric or asymmetric .

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.

Claims

CLAIMS:

1. A method of provisioning a subscription of a service to a device, the method comprising the steps of: receiving a communication from a device, the communication protected by first provisioning data installed on the device; authenticating the communication using data corresponding to the first provisioning data; sharing a newly generated secret with the device; generating a session key Ksession based on previously existing data available to the device and the newly generated shared secret; and using the session key Ksession to establish protected data, the protected data enabling the device to recover second provisioning data from a subscription manager (SM2).

2. The method of claim 1, wherein sharing the newly generated secret with the device comprises executing a Diffie-Hellman, DH, or elliptic curve Diffie-Hellman, ECDH, key agreement protocol.

3. The method of claim 1 or claim 2, wherein the existing data available to the device includes any one or more of: an authentication key, K±; a group key, KgroUp; an OEM key, Koem; a previously shared secret; a previous session key; measurements of a radio environment; or timestamps.

4. The method according to any previous claim, wherein the protected data enabling the device to recover the protected second provisioning data is provided to the device or to the subscription manager (SM2).

5. The method according to any previous claim, wherein the subscription manager receives the communication from the device.

6. The method according to any previous claim, wherein the communication comprises a signature verification key Vgen corresponding to a signature key Sgen of the device.

7. The method of claim 6, wherein Vgen and Sgen are generated after the first provisioning data are installed on the device.

8. The method according to any previous claim, wherein the step of authenticating the communication is carried out by a further subscription manager (SMI).

9. The method of claim 8, wherein the existing data available to the device comprises key material KexiSting that is shared with the further subscription manager (SMI).

10. The method of claim 8, wherein the existing data available to the device is a verification key, Vsml, of the further subscription manager (SMI)

11. The method according to any of claims 8 to 10, wherein the further subscription manager (SMI) is a separate component to the subscription manager (SM2).

12. The method according to any of claims 8 to 11, wherein the further subscription manager (SMI) receives the communication from the device.

13. The method according to any of claims 8 to 12 further comprising the step of the further subscription manager (SMI) providing a communication acknowledgment comprising Vgen signed by a signature key SSmi of the further subscription manager (SMI).

14. The method according to any of claims 8 to 13 further comprising the step of: the further subscription manager (SMI) obtaining data (Vsm2) to enable the device to authenticate the subscription manager (SM2) when recovering the protected second provisioning data, and wherein the further subscription manager (SMI) provides the device with the obtained data ( Msm2 ) .

15. The method of claim 14, wherein the data enabling the device to authenticate the subscription manager (SM2) is a signature verification key Vsm2 of the subscription manager (SM2).

16. The method of claim 15, wherein Vsm2 has a corresponding signature key Ssm2.

17. The method according to any previous claim, wherein the first provisioning data further comprises a group key, SgrouP, and a device key, Sdevice, wherein SgroUp is provided to a plurality of devices and wherein Sdevice is unique to the device, and further wherein authenticating the device comprises the step of the device signing the communication using Sdevice and Sgr0up ·

18. The method of claim 17, wherein the subscription manager uses a key Vdevice to verify the signature of the communication constructed using Sdevice and/or uses a key Vgroup to verify the signature of the communication constructed using SgroUp, wherein Vdevice forms a key pair with Sdevice and Vgroup forms a key pair with Sgroup·

19. The method of claim 18, wherein the key pair Vdevice and Sdevice are generated by a separate entity to the entity that generates the key pair Vgroup and SgroUp·

20. The method according to any of claims 17 to 19, wherein the first provisioning data further comprise a symmetric group key, KgroUpr and/or a symmetric device key, Kdevice·

21. The method according to any previous claim, wherein the second provisioning data are one or more additional secrets Kaddf the method further comprising the steps of generating the one or more additional secrets Kadd, and providing the one or more additional secrets Kadd to the device.

22. The method of claim 21, wherein the one or more additional secrets Kadd are generated in advance.

23. The method of claim 21 or 22, wherein the one or more additional secrets Kadd are protected using a session key session ' .

24. The method of claim 23 wherein Ksessi0n' is identical to session ·

25. The method of claim 23 or claim 24, wherein the one or more additional secrets Kadd are provided to the device by deriving the one or more additional secrets Kadd from the session key Ksession' using a key derivation operation carried out within the device.

26. The method of claim 23 wherein the session key Ksession' is generated based on further existing data available to the device and a further newly generated shared secret.

27. The method of claim 26, wherein the further newly generated secret is generated by executing a Diffie-Hellman, DH, or elliptic curve Diffie-Hellman, ECDH, key agreement protocol.

28. The method of claim 26 or claim 27, wherein the further existing data available to the device includes any one or more of: an authentication key, K±; a group key, Kgroup; an OEM key, Koem; a previously shared secret; a previous session key; measurements of a radio environment; or timestamps.

29. The method according to any of claims 26 to 28, wherein the further existing data available to the device comprises key material KexiSting' that is shared with the subscription manager (SM2).

30. The method according to any of claims 9 to 29, wherein KexiSting' IS identical to Kexisting.

31. A system for provisioning a subscription of a service to a device, the system comprising: a secure communications interface; a logic configured to: receive a communication from a device, the communication protected by first provisioning data installed on the device; authenticate the communication using data corresponding to the first provisioning data; share a newly generated secret with the device; generate a session key Ksession based on previously existing data available to the device and the newly generated shared secret; and use the session key Ksessi0n to establish protected data , the protected data enabling the device to recover second provisioning data from a subscription manager (SM2).

32. The system of claim 31, wherein the logic is part of a further subscription manager (SMI).

33. The system of claim 32, wherein the further subscription manager (SMI) is a separate component to the subscription manager (SM2).

34. A computer program comprising program instructions that, when executed on a computer cause the computer to perform the method of any of claims 1 to 30.

35. A computer-readable medium carrying a computer program according to claim 34.

36. A computer programmed to perform the method of any of claims 1 to 30.