(19)
(11)EP 3 550 765 A1

(12)EUROPEAN PATENT APPLICATION

(43)Date of publication:
09.10.2019 Bulletin 2019/41

(21)Application number: 19177124.5

(22)Date of filing:  29.05.2015
(51)Int. Cl.: 
H04L 9/08  (2006.01)
(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR
Designated Validation States:
MA

(30)Priority: 30.05.2014 GB 201409635

(62)Application number of the earlier application in accordance with Art. 76 EPC:
15730411.4 / 3149884

(71)Applicant: Vodafone IP Licensing Limited
London W2 6BY (GB)

(72)Inventors:
  • Bone, Nicholas
    London, W2 6BY (GB)
  • Babbage, Stephen
    London, W2 6BY (GB)
  • Barry, Aguibou
    London, W2 6BY (GB)

(74)Representative: Boult Wade Tennant LLP 
Salisbury Square House 8, Salisbury Square
London EC4Y 8AP
London EC4Y 8AP (GB)

 
Remarks:
This application was filed on 28-05-2019 as a divisional application to the application mentioned under INID code 62.
 


(54)SERVICE PROVISIONING


(57) Provisioning a subscription of a service to a device comprising: receiving a message from a device 210, the message protected by first provisioning data installed on the device 205. Authenticating the message 220 using data corresponding to the first provisioning data. On successful authentication 230, providing data enabling the device to recover protected second provisioning data from a subscription manager and providing the device with the protected second provisioning data 260. A second subscription manager may also be used. Optionally the message may comprise a signature verification key corresponding to a signature key of the device. A session key may be generated using Diffie-Hellman exchange and the second provisioning data may be provided to the device encrypted by a generated session key. The first provisioning data may comprise a group key, provided to a plurality of devices, and a device key, unique to the device. Part or all of the provisioning data may be stored within the secure execution environment (SEE) within the device. The OEM and SEE manufacturer may both provide key pairs, the OEM may provide the device key pair and the SEE manufacturer may provide the group key pairs. The device may be a Machine-to-Machine (M2M) device.




Description

Field of the Invention



[0001] The present invention relates to a method, apparatus and system 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



[0002] 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.

[0003] 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.

[0004] 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.

[0005] This process has several problems:
  • Each unique personalization step adds costs;
  • There is a "detour" from the original chip maker (a party like Infineon or NXP) via the SIM personalization centre before the UICC is shipped to the OEM;
  • The UICC is constrained in terms of form factor: e.g. it must be a dedicated "chip" with its own packaging, defined contacts and size. This can create some issues in terms of size of M2M equipment, and durability of the UICC in a long-lived device or in a difficult environment (SIM card may be shaken lose, contacts may overheat, freeze, become too moist etc.) While specially packaged UICCs exist (machine form factor), these are more expensive than conventional SIM card form factors, and so are harder to apply to low cost devices.
  • With a reduction in device cost the SIM can become a disproportionate share of the total device cost.


[0006] Many types of devices may be granted access to a mobile network as long as the network access credentials (also known as AKA credentials) are valid. These credentials need to be stored in a "secure execution environment" (typically a SIM card) to prevent tampering and cloning.

[0007] However, if a mobile operator's subscription key is negotiated remotely, for example via a Diffie-Hellman key exchange, rather than loaded at manufacture of the device, then it can be difficult for the mobile operator to determine whether the resulting key is being stored in a Secure Execution Environment (like a SIM card) since authentication of the device may not be possible. These concerns are sufficiently serious to rule out an "anonymous" Diffie-Hellman approach.

[0008] One way to ensure provisioning of AKA credentials to the right target requires the device being equipped with identities that cannot be usurped. It is therefore important that each device is equipped with unique identification, and that there is an assurance that this unique identification cannot be modified without strong authorization.

[0009] If asymmetric cryptography is chosen then each device must be provisioned with a unique public-private key pair. Some entity must therefore take responsibility and some liability for the security of the device. This "liable representative" may provide a trust anchor to any entity such as the mobile network operator (MNO) that needs to verify the identity of the device.

[0010] The Machine Form Factor SIM (MFF1, MFF2) addresses some of the form factor issues, but does not address the cost and logistic issues. Furthermore, it is more expensive than typical SIM card form factor.

[0011] In 2008, Oberthur and Wavecom (later acquired by Sierra Wireless) proposed a solution called "inSIM" which would allow the SIM card to be placed inside another chip package (the baseband processor). However, the solution did not meet operator security requirements, as the operator credentials would need to be provisioned to the "inSIM" at an insecure location (OEM production line).

[0012] Recent approaches to embedded SIM (eUICC standardization efforts in GSMA and ETSI SCP, Vodafone SOBE project) allow an operator subscription to be updated remotely on the UICC. However, these approaches still require unique initial secrets to be loaded to each UICC, so do not avoid the need for a smart card personalization centre.

[0013] Further, the UICC needs to be loaded with an initial IMSI/Ki and profile (a so-called "provisioning subscription") in order to connect to a mobile network and download a permanent subscription.

[0014] US 8,589,689 describes over-the-air provisioning of authentication credentials at an access device via a first access system (e.g. CDMA), wherein the authentication credentials are for a second access system (e.g. 3GPP) lacking an over-the-air provisioning procedure. Whilst, this enables access to a mobile network, it doesn't allow devices to be provisioned by external entities in a secure manner.

[0015] Furthermore, a motivation for the use of smart cards as "Secure Execution Environments" is to avoid problems with untrusted (or rogue) subscribers. However, M2M will often use trusted business partners of a network operator as subscribers, or otherwise use large businesses with a reputation to protect. Such organisations are not likely to deliberately violate terms of service (via cloning etc.), or run up big bills without paying. A business partner may offer (or wish to use) an alternative to a smart card as a way of storing an operator's subscription key (K), either on the grounds of cost, or size, or durability.

[0016] In this case, the partner may be confident enough to accept the liability for bills in the case of a leak/clone of the subscription credentials.

[0017] Note that even with trusted business relationships, one particular challenge to consider that devices may go through distribution channels which aren't entirely trusted. If key material loaded at device manufacture is not sufficiently protected, then an individual, such as a shop assistant (for instance), could extract it and use it to discover the final key material.

[0018] In some M2M scenarios, a technician needs to configure the device prior to activating it for operations. A known solution would be to provide a batch of SIM cards to the technician to insert into the devices.

[0019] However, there is considerable complexity and risk of carrying a plurality of SIM cards. If the technician has to take them to an external or insecure environment such as a public place, then a thief could attempt to steal from the plurality or stack of SIM cards. If the theft remains unnoticed for several days, then it may have repercussions. The SIM card may be used in an unintended device, incur data and/or voice charges at the M2M customer's expense, or provide faulty information (e.g. false location information to a vehicle tracking service). Additionally, the technician might himself be a thief, or co-operating with the thief.

[0020] There is also the risk that the technician does something wrong when configuring the device and in particular when activating the subscription and "binding" it to a particular device. This could either be a human error or attempt to tamper with the credentials used to set up the network access credentials. There is a particular risk of error if the IMSI-IMEI binding was set up before insertion of the SIM card, since the technician might accidentally insert the SIM card in the wrong device. Or even if the binding is set up during or after activation (via a portal) then the SIM card might now be bound to the wrong device.

[0021] For technician provisioning, one direct countermeasure to the risks could be for any SIM card to be activated only after being inserted in the target device. The authorization of the activation may be a combination of things, e.g. the technician being authenticated to a Device Management (DM) portal, the SIM being authenticated by the mobile network, the device being authenticated by the DM portal, the device having successfully reported which SIM is currently inserted in it.

[0022] A further countermeasure could be to limit what the SIM can do when activated, e.g. it may be prohibited from making voice calls, or is only allowed to transmit small amounts of data, or only allowed to transmit to designated addresses (M2M servers) rather than the wider Internet.

[0023] Another useful countermeasure could be "binding" an IMSI (SIM identifier) to an IMEI (device identifier). This may ensure that a SIM can only be used within a target device. For example, if the SIM is placed in a different device, then the alternate IMEI is reported to the mobile network's HLR, which detects that it is not the intended device. That can lead to barring or temporarily suspending the subscription. A more complicated solution (but one that may protect against a faked IMEI) is a secure channel between the SIM card and the target device.

[0024] Cost reasons are a major driver in M2M. Security requirements may be beyond the above solutions or potential solutions and may also increase costs and decrease flexibility. Cheaper solutions to conventional SIM cards having full flexibility across a whole range of low-cost devices are also desirable.

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

Summary of the Invention



[0026] In accordance with a first aspect, there is provided method of provisioning a subscription of a service to a device, the method comprising the steps of:

receiving a message from a device, the message protected by first provisioning data installed on the device;

authenticating the message using data corresponding to the first provisioning data;

on successful authentication, providing data enabling the device to recover protected second provisioning data from a subscription manager; and

providing the device with the protected second provisioning data. The method may operate within a wired or preferably wireless or cellular network such as a 3GPP 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). If the initial provisioning data is compromised then the loss can be 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.



[0027] This method avoids a detour to a SIM card manufacturer and avoids the need for secure personalisation at an OEM.

[0028] 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 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 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.

[0029] Optionally, on successful authentication, the data enabling the device to recover the protected second provisioning data may be provided to the device or to the subscription manager. 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 subscription manager may provide an assurance that cryptographic material within the message is associated with the device.

[0030] 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.

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

[0032] Optionally, the further subscription manager (SM1) may receive the message from the device.

[0033] Optionally, the subscription manager (or a combined subscription manager and further subscription manager) may receive the message from the device.

[0034] Advantageously, the message 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.

[0035] Preferably, providing the device with the protected second provisioning data may further comprise the steps of:

generating Diffie-Hellman keys Pubd', Privd' on the device;

generating Diffie-Hellman keys on the subscription manager (Pubs', Privs');

providing the subscription manager with Pubd' protected by Sgen;

providing the device with Pubs';
generating a session key Ksession' based on Pubd', and Privs'; and

sending the second provisioning data to the device protected by the session key Ksession'

Preferably, Vgen (together with a corresponding signature key Sgen) is 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.

[0036] Optionally, the method may further comprise the step of the further subscription manager providing a message acknowledgment comprising Vgen signed by a signature key SSM1 of the further (initial) subscription manager.

[0037] Optionally, the method may further comprise the step of:
the further subscription manager receiving from the subscription manager or otherwise 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 (SM1) provides the device with the obtained data (Vsm2). This may be through a secure connection between the two subscription managers.

[0038] Optionally, the data enabling the device to authenticate the subscription manager (SM2) is 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.

[0039] Preferably, Vsm2 has a corresponding signature key Ssm2.

[0040] Advantageously, providing the device with the protected second provisioning data may further comprise the steps of:

generating Diffie-Hellman keys Pubd', Privd' on the device;

generating Diffie-Hellman keys on the subscription manager (Pubs', Privs');

providing the subscription manager with Pubd' protected by Sgen;

providing the device with Pubs' protected by Ssm2;

generating a session key Ksession' based on Pubd', and Privs'; and

sending the second provisioning data to the device protected by the session key Ksession'. The subscription manager does not have Privd' here, and does not use Pubs' when generating the session key.



[0041] Vsm2 may be transferred to the device in a similar way.

[0042] Advantageously, providing the device with the obtained data (Vsm2) may further comprise the steps of:

generating Diffie-Hellman keys Pubd, Privd on the device;

generating Diffie-Hellman keys on the subscription manager (Pubs, Privs);

providing the subscription manager with Pubd (which should be signed with Sgen);

providing the device with Pubs (which should be signed with Ssm1);

generating a session key Ksession based on Pubd and Privs; and

sending the obtained data (Vsm2) to the device protected by the session key Ksession. Preferably, Pubd should be signed with Sgen. Preferably and to improve security, Pubs should be signed with Ssm1. Therefore, Vsm2 is protected using Diffie-Hellman.



[0043] Optionally, the first provisioning data may further comprise 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 message using Sdevice and Sgroup.

[0044] Preferably, the subscription manager may use a key Vdevice to verify the signature of the message constructed using Sdevice and/or uses a key Vgroup to verify the signature of the message 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.

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

[0046] 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.

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

[0048] 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.

[0049] 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.

[0050] Preferably, the key pair Vdevice and Sdevice are generated by a separate entity (e.g. OEM) to the key pair Vgroup and Sgroup (e.g. manufacturer of the SEE).

[0051] Optionally, the second provisioning data may be one or more additional secrets Kadd, the method may further comprise 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.

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

[0053] Optionally, the one or more additional secrets Kadd may be provided to the device by deriving the one or more additional secrets Kadd from a session key using a key derivation operation carried out within the device. The session key may be the session key Ksession' based on Pubd', Privd', Pubs' and Privs', described above.

[0054] 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;

logic configured to:

receive a message from a device, the message protected by first provisioning data installed on the device;

authenticate the message using data corresponding to the first provisioning data;

on successful authentication, provide the device with data enabling the device to recover protected second provisioning data from a subscription manager; and

providing the device with the protected second provisioning data.



[0055] Optionally, the logic may be part of a further subscription manager. This further subscription manager may be a separate component or entity from the subscription manager. 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.

[0056] In accordance with a third aspect, there is provided apparatus for provisioning a subscription of a service to a device, the apparatus comprising:

one or more interfaces configured to communicate with a device and a subscription manager; and

logic configured to:

receive cryptographic data from the device over the one or more interfaces;

transmit the cryptographic data to the subscription manager over the one or more interfaces;

receive provisioning data from the subscription manager over the one or more interfaces; and

transmit the provisioning data to the device over the one or more interfaces, wherein the provisioning data is configured to validate or enable a subscription of the device to a service.



[0057] The apparatus may be a technician device. Advantageously, the device being provisioned via the technician device does not have any pre-loaded keys or secrets. This avoids the need for unique personalisation at an OEM. The device may be a M2M device or M2M device incorporating a SIM, UICC, embedded SIM or other SEE, for example.

[0058] Optionally, the logic may be further configured to digitally sign the cryptographic data with a signature key before transmission to the subscription manager. This improves security.

[0059] Optionally, the one or more interfaces are either wireless or cellular or one or more of both. In one embodiment there may be a cellular interface to the device manager and a WiFi or wired interface to the device. In another embodiment the apparatus may interface with the device over a cellular interface and so avoid the device requiring more than one interface. In such an embodiment, the apparatus effectively acts as a femtocell.

[0060] Optionally, the cryptographic data may be digitally signed as part of a Diffie-Hellman exchange between the device and the subscription manager.

[0061] Optionally, apparatus may further comprise a UICC, SIM, embedded SIM or other secure execution environment, SEE, configured to generate or store the signature key.

[0062] Preferably, the logic may be further configured to authenticate the provisioning data before transmitting the provisioning data to the device.

[0063] Optionally, the logic may be further configured to digitally sign the provisioning data before transmitting the provisioning data to the device.

[0064] Optionally, the provisioning data may be digitally signed as part of a Diffie-Hellman exchange between the device and the subscription manager.

[0065] Preferably, the provisioning data may be digitally signed by the subscription manager and authentication of the provisioning data is performed by verifying the digital signature.

[0066] Preferably, the provisioning data may be protected by the cryptographic data.

[0067] Optionally, the logic may be further configured to confirm a paired connection with the device.

[0068] Optionally, the one or more interfaces may be either wireless or cellular or one or more of both.

[0069] Preferably, the cryptographic data is a public key of a public and private key pair provided by the device.

[0070] Preferably, the logic may be further configured to verify the source of the provisioning data, and re-sign it before transmitting it to the device. The apparatus should be able to verify the source of the provisioning data, and re-sign it for the benefit of the target device. In other words, the apparatus acts as a conduit, but nevertheles the provisioning data cannot be intercepted by tampering with the apparatus.

[0071] In accordance with a fourth aspect there is provided a method for provisioning a subscription of a service to a device, the method comprising the steps of:

receiving cryptographic data from a device over one or more interfaces;

transmitting the cryptographic data to the subscription manager over the one or more interfaces;

receiving provisioning data from the subscription manager over the one or more interfaces; and

transmitting the provisioning data to the device over the one or more interfaces, wherein the provisioning data is configured to validate or enable a subscription of the device to a service.



[0072] Optionally, the provisioning data may be received from the device manager encrypted to exclude access by the provisioning apparatus. A Diffie-Hellman exchange, similar to that described previously, may be used.

[0073] Optionally, the method may further comprise the step of authenticating the source of the provisioning data before transmission to the device.

[0074] Preferably, the method may further comprise the step of digitally signing the provisioning data with a signature key before transmission to the device.

[0075] Preferably, the provisioning data may be a shared secret between the device and the subscription manager.

[0076] According to a further aspect, there is provided a system comprising one or more apparatuses or devices for provisioning a subscription of a service to a plurality of devices, one or more 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, apparatuses and/or devices. 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 cryptographic material such as keys or key pairs for including in secure execution environments to be added to or within 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.

[0077] According to a further aspect, there is provided a method of manufacturing a device in which a single wafer is cut into dies (with each die receiving both a secure and a non-secure component). One die may be inserted per chip package.

[0078] 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.

[0079] 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.

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

[0081] The following clauses provide examples of possible embodiments of the present invention.
  1. 1. A method of provisioning a subscription of a service to a device, the method comprising the steps of:

    receiving a message from a device, the message protected by first provisioning data installed on the device;

    authenticating the message using data corresponding to the first provisioning data;

    on successful authentication, providing data enabling the device to recover protected second provisioning data from a subscription manager (SM2); and

    providing the device with the protected second provisioning data.

  2. 2. The method of clause 1, wherein on successful authentication, the data enabling the device to recover the protected second provisioning data is provided to the device or to the subscription manager (SM2).
  3. 3. The method according to clause 1 or clause 2, wherein the step of authenticating the message is carried out by a further subscription manager (SM1).
  4. 4. The method of clause 3, wherein the further subscription manager (SM1) is a separate component to the subscription manager (SM2).
  5. 5. The method of clause 3 or clause 4, wherein the further subscription manager (SM1) receives the message from the device.
  6. 6. The method according to any of clauses 1 to 3, wherein the subscription manager receives the message from the device.
  7. 7. The method according to any previous clause, wherein the message comprises a signature verification key Vgen corresponding to a signature key Sgen of the device.
  8. 8. The method of clause 7, wherein providing the device with the protected second provisioning data further comprises the steps of:

    generating Diffie-Hellman keys Pubd', Privd' on the device;

    generating Diffie-Hellman keys on the subscription manager (Pubd', Privs');

    providing the subscription manager with Pubd, protected by Sgen;

    providing the device with Pubs';

    generating a session key Ksession' based on Pubd', and Privs'; and

    sending the second provisioning data to the device protected by the session key Ksession'.

  9. 9. The method of clause 7 or clause 8, wherein Vgen and Sgen are generated after the first provisioning data are installed on the device.
  10. 10. The method according to any of clauses 7 to 9 when dependent on clause 3 further comprising the step of the further subscription manager (SM1) providing a message acknowledgment comprising Vgen signed by a signature key Ssm1 of the further subscription manager (SM1).
  11. 11. The method according to any of clauses 3 to 10 further comprising the step of:
    the further subscription manager obtaining the 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 (SM1) provides the device with the obtained data (Vsm2).
  12. 12. The method according to any previous clause, wherein the data enabling the device to authenticate the subscription manager (SM2) is a signature verification key Vsm2 of the subscription manager (SM2).
  13. 13. The method of clause 12, wherein Vsm2 has a corresponding signature key Ssm2.
  14. 14. The method of clause 13, wherein providing the device with the protected second provisioning data further comprises the steps of:

    generating Diffie-Hellman keys Pubd', Privd' on the device;

    generating Diffie-Hellman keys on the subscription manager (Pubs', Privs');

    providing the subscription manager with Pubd';

    providing the device with Pubs protected by Ssm2;

    generating a session key Ksession' based on Pubd', and

    Privs'; and

    sending the second provisioning data to the device protected by the session key Ksession'.

  15. 15. The method according to any of clauses 11 to 14, wherein providing the device with the obtained data (Vsm2) further comprises the steps of:

    generating Diffie-Hellman keys Pubd, Privd on the device;

    generating Diffie-Hellman keys on the subscription manager (Pubs, Privs);

    providing the subscription manager with Pubd;

    providing the device with Pubs;

    generating a session key Ksession based on Pubd and Privs; and

    sending the obtained data (Vsm2) to the device protected by the session key Ksession.

  16. 16. The method according to any previous clause, wherein the first provisioning data further comprise 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 message using Sdevice and Sgroup.
  17. 17. The method of clause 16, wherein the subscription manager uses a key Vdevice to verify the signature of the message constructed using Sdevice and/or uses a key Vgroup to verify the signature of the message constructed using Sgroup, wherein Vdevice forms a key pair with Sdevice and Vgroup forms a key pair with Sgroup.
  18. 18. The method of clause 17, wherein the key pair Vdevice and Sdevice are generated by a separate entity to the entity that generates the key pair Vgroup and Sgroup.
  19. 19. The method according to any of clauses 16 to 18, wherein the first provisioning data further comprise a symmetric group key, Kgroup, and/ or a symmetric device key, Kdevice.
  20. 20. The method according to any previous clause, wherein the second provisioning data are 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.
  21. 21. The method of clause 20, wherein the one or more additional secrets Kadd are generated in advance.
  22. 22. The method of clause 20, wherein the one or more additional secrets Kadd are provided to the device by deriving the one or more additional secrets Kadd from a session key using a key derivation operation carried out within the device.
  23. 23. 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 message from a device, the message protected by first provisioning data installed on the device;

    authenticate the message using data corresponding to the first provisioning data;

    on successful authentication, provide the device with data enabling the device to recover protected second provisioning data from a subscription manager (SM2); and

    providing the device with the protected second provisioning data.

  24. 24. The system of clause 23, wherein the logic is part of a further subscription manager (SM1).
  25. 25. The system of clause 24, wherein the further subscription manager (SM1) is a separate component to the subscription manager (SM2).
  26. 26. Apparatus for provisioning a subscription of a service to a device, the apparatus comprising:

    one or more interfaces configured to communicate with a device and a subscription manager; and

    logic configured to:

    receive cryptographic data from the device over the one or more interfaces;

    transmit the cryptographic data to the subscription manager over the one or more interfaces;

    receive provisioning data from the subscription manager over the one or more interfaces; and

    transmit the provisioning data to the device over the one or more interfaces, wherein the provisioning data enables a subscription of the device to a service.

  27. 27. The apparatus of clause 26, wherein the logic is further configured to digitally sign the cryptographic data with a signature key before transmission to the subscription manager.
  28. 28. The apparatus of clause 27, wherein the cryptographic data is digitally signed as part of a Diffie-Hellman exchange between the device and the subscription manager (SM).
  29. 29. The apparatus of clause 28 further comprising a UICC, SIM, embedded SIM or other secure execution environment, SEE, configured to store the signature key.
  30. 30. The apparatus according to any of clauses 26 to 29, wherein the logic is further configured to authenticate the provisioning data before transmitting the provisioning data to the device.
  31. 31. The apparatus of clause 30, wherein the logic is further configured to digitally sign the provisioning data before transmitting the provisioning data to the device.
  32. 32. The apparatus of clause 31, wherein the provisioning data is digitally signed as part of a Diffie-Hellman exchange between the device and the subscription manager (SM).
  33. 33. The apparatus of clause 30, wherein the provisioning data is digitally signed by the subscription manager (SM) and authentication of the provisioning data is performed by verifying the digital signature.
  34. 34. The apparatus according to any of clauses 26 to 33, wherein the provisioning data is protected by the cryptographic data.
  35. 35. The apparatus according to any of clauses 26 to 34, wherein the logic is further configured to confirm a paired connection with the device.
  36. 36. The apparatus according to any of clauses 26 to 35, wherein the one or more interfaces are either wireless or cellular or one or more of both.
  37. 37. The apparatus according to any of clauses 26 to 36, wherein the cryptographic data is a public key of a public and private key pair provided by the device.
  38. 38. The apparatus according to any of clauses 26 to 37, wherein the logic is further configured to verify the source of the provisioning data, and re-sign it before transmitting it to the device.
  39. 39. A method for provisioning a subscription of a service to a device, the method comprising the steps of:

    receiving cryptographic data from a device over one or more interfaces;

    transmitting the cryptographic data to the subscription manager over the one or more interfaces;

    receiving provisioning data from the subscription manager over the one or more interfaces; and

    transmitting the provisioning data to the device over the one or more interfaces, wherein the provisioning data enables a subscription of the device to a service.

  40. 40. The method of clause 39, wherein the provisioning data is received from the subscription manager encrypted to exclude access by the provisioning apparatus.
  41. 41. The method of clause 39 or clause 40 further comprising the step of authenticating the source of the provisioning data before transmission to the device.
  42. 42. The method according to any of clauses 39 to 41 further comprising the step of digitally signing the provisioning data with a signature key before transmission to the device.
  43. 43. The method according to any of clauses 39 to 42, wherein the provisioning data is a shared secret between the device and the subscription manager.
  44. 44. A method substantially as described with reference to any of the accompanying drawings.
  45. 45. An apparatus substantially as described and shown in any of the accompanying drawings.
  46. 46. A computer program comprising program instructions that, when executed on a computer cause the computer to perform the method of any of clauses 1 to 22 or 39 to 44.
  47. 47. A computer-readable medium carrying a computer program according to clause 46.
  48. 48. A computer programmed to perform the method of any of clauses 1 to 22 or 39 to 47.

Brief description of the Figures



[0082] 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;

FIG. 3 shows a flowchart of a method for provisioning a device using the system of figures 1 and 2;

FIG. 4 shows a portion of a further system for provisioning a device;

FIG. 5 shows a further portion of the system of FIG. 4; and

FIG. 6 shows a flowchart of a method for provisioning a device using the system of figures 4 and 5.



[0083] 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



[0084] We propose an approach which removes the "detour" through a secure SIM card personalization centre.

[0085] 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 keys are written as Privz for a private key (including the field parameters and private exponent) and Pubz for the corresponding public key.

[0086] 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 (Ssm1 and Vsm1) and the SEE will come provisioned with the initial subscription manager verification key (Vsm1). 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). These keys should be used only once per device and then replaced with persistent keys.

[0087] The Initial Subscription Manager knows the server-side signature key (Ssm1), 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 Ssm1, and that no other entity knows both Kgroup and Kdevice. The Initial Subscription Manager requires secure interfaces with both the silicon vendor and the OEM to exchange keys. 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. Similarly, 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 (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.
1. Preferably, the group key (Kgroup) and the initial server-side key (Ssm1, Vsm1) should be changed regularly when producing new batches of devices.
2. The initial keys (Kgroup, Kdevice, Vsm1), should ideally be used only once per device, at first authentication with the Initial Subscription Manager, then replaced with fresh device-specific keys.
3. At least one fresh ECDSA keypair (Sgen, Vgen) shall be generated on the device within the SEE. A new ECDSA verification key Vgen shall be reported to the Initial Subscription Manager, 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 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 Ssm1; if not, the acknowledgement shall be signed using Ssm1.
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
DeviceSM1
Generate ECDSA key-pair (Sgen, Vgen) 100  
----------------- Device's ECDSA key Vgen integrity-protected using both Kgroup and Kdevice ---------------> 105
  Verify device's ECDSA key Vgen and issue Device Cert
<------ Vgen signed using Ssm1 [could be Device Cert] --- 110
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 (Ssm2, Vsm2) is generated preferably in advance by each Subscription Manager, and Ssm2 stored safely. 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.

[0088] Direct signing of one ECDSA key by another (e.g. signing Vsm2 using Ssm1) is not recommended, as it is hard to revoke such a signature. Instead, such a verification key should be encrypted and integrity-protected using ECDH session keys (Ksession), arising from an authenticated ECDH exchange. Both the device (Sd) and server-side (Ssm1) ECDSA keys must 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.

[0089] 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.
Table 2
DeviceSM1
Generate ECDH key-pair (Privd, Pubd) 115  
--Device's ECDH Pubd signed using Sgen [+ Device Cert]--> 120
  Verify signature on Pubd
  Generate ECDH key-pair (Privs, Pubs) and compute ECDH shared secret Ksession from Privs and Pubd 125
<-------- Server's ECDH Pubs + Pubd, signed using Ssm1 + ----
{Vsm2} encrypted and integrity protected by ECDH shared secret Ksession 130 [note Ssm2 and Vsm2 for SM2]
Verify signature on Pubs+Pubd Compute ECDH shared secret Ksession from Privd and Pubs and recover Vsm2  
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) arising from an authenticated ECDH exchange set up as described in step 4 above. Alternatively, if they have not been generated in advance, they may be generated from Ksession 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
DeviceSM2
Generate ECDH key-pair (Privd', Pubd') 135  
----------------- Device's ECDH Pubd signed using Sgen [+ Device Cert] ---------------> 140
  Verify signature on Pubd
  Generate ECDH key-pair (Privs, Pubs) and compute ECDH shared secret Ksession' from Privs' and Pubd' 145
<------------------- Server's ECDH Pubs' + Pubd', signed using Ssm2 + ------------------
{Kadd} encrypted and integrity protected by ECDH shared secret Ksession 150
Verify signature on Pubs + Pubd  
Compute ECDH shared secret Kecdh  
from Privd and Pubs and recover Kadd  

Optional Features/Variations:



[0090] 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.

[0091] 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 should re-start the whole protocol.

[0092] 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.

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

[0094] 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.

[0095] 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) and then the OEM key will be replaced. Therefore, an attacker would need to compromise both these keys to impersonate the device. For example, the 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.

[0096] Clearly, a risk of such a solution 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.

[0097] Therefore, the risk of a hacked group key is reduced by making the hacking attempt have little value to the attacker. If all of steps 1-5 are deployed, then a compromised group key would only be usable to impersonate devices which had been manufactured recently (i.e. up to the last key change), whose OEM device keys had also leaked, and which had not yet been remotely provisioned with their fresh device-specific keys: a rather limited attack window. Devices that were already remotely provisioned at the time of compromise would be unaffected. Further, being able to impersonate a device during this window would have rather little value. To gain actual network access credentials (e.g. a cellular operator's K), an attacker would need to know which device id(s) were requesting them, from which operator, and when. The attacker would then need to enter into a race condition with the legitimate device to request and retrieve the credential, and there would be an opportunity for the operator to detect the duplicate registration requests. This looks like it is a difficult attack to execute, for little value.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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 (SM1). 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.

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

[0103] 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).

[0104] The further subscription manager 50 has already generated a key pair Ssm1, Vsm1. The further subscription manager 50 sends a confirmation of receipt of Vgen to the device 20 by signing it with Ssm1 110.

[0105] A Diffie-Hellman key exchange is set up between the device 20 and the further subscription manager 40 (steps 115-130). This 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 (Kadd) 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.

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

[0107] 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, SM1) subscription manager 40 at step 220.

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

[0109] 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. In addition, SM1 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 then the device 20 can obtain the protected second provisioning data and use it to obtain the service.

[0110] 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).

[0111] As described previously, there are certain disadvantages in provisioning a (relatively expensive) SIM card. In one example implementation a technician or other person may use a handheld device 240 to login to a DM portal, under the M2M customer's account. They may then request a new credential or provisioning data for transmission to a target M2M device 20. The interaction between the target device 20 and the technician device 240 is shown schematically in figure 4.

[0112] The handheld device 240 can be moderately sophisticated in this scenario. For example it may have suitable connectivity and interfaces to request and retrieve credentials. This may be cellular connectivity, WiFi connectivity or both. Preferably, the handheld device can be authenticated by its own SIM - either traditional or embedded - so that the connection to the portal is secure and seamless.

[0113] This approach comes with the same broad risks as physical SIM distribution. The technician's device 240 might get stolen, similar to stealing a stack of SIM cards. The technician might be a thief, or acting in concert with a thief, or may just make a mistake. There are some requirements to optimize the solution and mitigate these risks:
  1. 1. Suitable anti-fraud measures should be deployed, similar to existing ways to prevent abuse of SIM cards e.g. preventing voice, limiting data, limiting connections to certain addresses etc.
  2. 2. The M2M customer takes financial liability for the credential or provisioning data (i.e. the customer can't repudiate bills if the credential is lost or used by wrong device, or the technician is rogue). This ensures that risks of technician error or abuse will be managed by the party most able to control them. For example the M2M customer may require that the technician has to be authenticated to the technician device 240 (e.g. must enter a PIN, or use fingerprint).
  3. 3. The credential is transmitted over an end-to-end secured connection into the target device, so that a thief is unable to intercept it en route, or at the technician device 240.


[0114] Other features which would improve the solution:

4. Relaying of the credential from the technician device 240 to the target M2M device 20 should be done via a local wireless protocol, rather than plugging in a cable. An automated short-range pairing may be used to minimize the risk of the credential arriving at the wrong device.

5. The "local" wireless protocol should ideally be an instance of the "global" protocol used by the target device 20, so that handheld device acts like a femtocell or cellular base station, for example. This reduces the number of radio protocols that the M2M device 20 must support, and so reduces cost and complexity.



[0115] In the case of "technician configuration" then the technician's device 240 will have been provisioned with an ECDSA signature key and certificate, but the target device 240 usually will not. The target device 20 does however have the means to generate an ECDH public key and send it over a local wireless protocol. The technician device 240 and target device 20 exchange and confirm each other's public keys. Table 4 and figure 4 illustrate the communications between the technician device 240 and the target device 20 in more detail. This communication could use an out-of-band hash like flashing lights, audio tones etc. or a loud noisy burst of 1s/0s matching the hash.

[0116] The local protocol should be sufficiently short-range and short-lived to make a Man In The Middle attack very unlikely anyway. However, note that the technician device will play a critical security role, and must be protected against tampering e.g. attempts to insert a Man In The Middle on the technician's device 240 itself.
Table 4
Target DeviceTechnician Device
<----------------Technician Device's ECDSA public key [or cert] 305 ----------------
Generate ECDH key-pair (Pubd, Privd) 310  
----------------- Target Device's ECDH public key Pubd -----------------------------> 315
<<--------- local short-range protocol to confirm Hash(public keys) ---------->> 320


[0117] The technician's device 240 signs the ECDH public key Pubd before forwarding it to a subscription manager 250, and subsequently signs the subscription manager's ECDH public key Pubsm before forwarding it to the target device 20. These communications are summarised in tables 5 and 6 and figure 5.
Table 5
Technician DeviceSM
------Signed Target Device's ECDH public key Pubd [+Technician Device cert] 405----->
  Authorization Decision:
  Is the Technician Device signature acceptable? (From an M2M customer who agrees liability for credential).
  Generate ECDH key-pair Pubsm, Privsm and compute ECDH shared secret Ksession 410
<------------------- Signed SM's (and Device's) ECDH public key Pubsm, Pubd [+ SM cert] ---------------- + {credentials Vsm} encrypted and integrity protected by ECDH shared secret 415
Verify signature on SM's ECDH public key Pubsm,  
and re-sign with own ECDSA key Stech 420  
Table 6
Target DeviceTechnician Device
<------------------------ Re-Signed SM's (and Device's) ECDH public key ------------------------+ {credentials} encrypted and integrity protected by ECDH shared secret
Compute ECDH shared secret  
and decrypt credentials  


[0118] Figure 6 shows a flowchart of a method 500 for using the technician's device 240 to provision a device 20. At step 510, cryptographic data Pubd is retrieved from the device 20.

[0119] At step 530 provisioning data is received by the technician device from the subscription manager 250. The technician device 240 then verifies, re-signs, and transmits the provisioning data Kadd to the device 20 at step 540. Kadd is authenticated and recovered by the device 20 at step 550. On successful authentication then the device 20 is subscribed to the service.

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

[0121] 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.

[0122] 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.

[0123] 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

1. Apparatus for provisioning a subscription of a service to a device, the apparatus comprising:

one or more interfaces configured to communicate with a device and a subscription manager; and

logic configured to:

receive cryptographic data from the device over the one or more interfaces;

transmit the cryptographic data to the subscription manager over the one or more interfaces;

receive provisioning data from the subscription manager over the one or more interfaces; and

transmit the provisioning data to the device over the one or more interfaces, wherein the provisioning data enables a subscription of the device to a service.


 
2. The apparatus of claim 1, wherein the logic is further configured to digitally sign the cryptographic data with a signature key before transmission to the subscription manager.
 
3. The apparatus of claim 2, wherein the cryptographic data is digitally signed as part of a Diffie-Hellman exchange between the device and the subscription manager (SM).
 
4. The apparatus of claim 3 further comprising a UICC, SIM, embedded SIM or other secure execution environment, SEE, configured to store the signature key.
 
5. The apparatus according to any of claims 1 to 4, wherein the logic is further configured to authenticate the provisioning data before transmitting the provisioning data
to the device.
 
6. The apparatus of claim 5, wherein the logic is further configured to digitally sign the provisioning data before transmitting the provisioning data to the device.
 
7. The apparatus of claim 6, wherein the provisioning data is digitally signed as part of a Diffie-Hellman exchange between the device and the subscription manager (SM).
 
8. The apparatus of claim 7, wherein the provisioning data is digitally signed by the subscription manager (SM) and authentication of the provisioning data is performed by verifying the digital signature.
 
9. The apparatus according to any of claims 26 to 33, wherein the provisioning data is protected by the cryptographic data; and/or
wherein the logic is further configured to confirm a paired connection with the device; and/or
wherein the one or more interfaces are either wireless or cellular or one or more of both; and/or
wherein the cryptographic data is a public key of a public and private key pair provided by the device; and/or
wherein the logic is further configured to verify the source of the provisioning data, and re-sign it before transmitting it to the device.
 
10. A method for provisioning a subscription of a service to a device, the method comprising the steps of:

receiving cryptographic data from a device over one or more interfaces;

transmitting the cryptographic data to the subscription manager over the one or more interfaces;

receiving provisioning data from the subscription manager over the one or more interfaces; and

transmitting the provisioning data to the device over the one or more interfaces, wherein the provisioning data enables a subscription of the device to a service.


 
11. The method of claim 10, wherein the provisioning data is received from the subscription manager encrypted to exclude access by the provisioning apparatus.
 
12. The method of claim 10 or claim 11 further comprising the step of authenticating the source of the provisioning data before transmission to the device.
 
13. The method according to any of claims 10 to 12 further comprising the step of digitally signing the provisioning data with a signature key before transmission to the device.
 
14. The method according to any of claims 10 to 13, wherein the provisioning data is a shared secret between the device and the subscription manager.
 
15. A computer-readable medium storing computer executable instructions that, when executed by a computer system comprising at least one processor, cause the computer system to perform any one of the methods of claims 10 to 14.
 




Drawing























REFERENCES CITED IN THE DESCRIPTION



This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

Patent documents cited in the description