Patent Application
20140365769
The present invention relates to radio telecommunication systems. More particularly, and not by way of limitation, the present invention is directed to an apparatus and method for remote initial provisioning of Universal Subscriber Identity Modules (USIMs) and subsequent changing of an operator.
There is currently an ongoing study item in 3GPP targeting to create an architecture and solution for remote initial provisioning of USIMs and subsequent changing of an operator. The study is reported in the technical report, 3GPP TR 33.812, version 1.3.0. Remotely manageable USIMs are considered for Machine-to-machine (M2M) communication, i.e., communication between devices without user interaction.
A typical use case for an M2M device is electric metering. In this case, an electric supplier company installs automatic metering devices that report the amount of consumed electricity back to the billing department via a 3GPP network. Since millions of such devices may be installed, remote management of subscriptions would greatly reduce costs, for example, in the case of a change of subscription. in this use case, the end user and the owner of the devices is an enterprise with a large number of devices in the field. Thus, it is likely that the owner will have its own servers that can manage the devices.
Another use case is for built-in terminals in cars. In this case it is a single owner of the car that would like to control which telecommunication operator the car is using, and also the services to which the car is attached such as insurance service, maintenance services, and road toll services. In this use case, it is envisioned that a car owner's mobile terminal could function as the enterprise server above, containing all the necessary intelligence to manage the car.
The existing 3GPP architecture and remotely managed procedure for provisioning an M2M device is complex and still leaves security gaps.
There is no solution for how to simplify the process of changing the operator, and how to couple that process to secure service set-up. Under existing procedures, at manufacture time, a Platform Validation Authority (PVA) certificate is installed as a trusted certificate in a M2ME device. However, all operators with a certificate signed by the PVA are able to perform a valid provisioning of the M2M device. This creates the problem commonly referred to as slamming, i.e., illegal changing of subscribers telephone service without their consent.
From an operator's perspective it is also important that the discovery function through which the device discovers its new Selected Home Operator (SHO) is authenticated by the device. An unauthenticated rouge discovery function could divert a large number of M2M devices to connect to some operators network, causing a denial-of-service attack on the network.
Current devices use a SIM/USIM card to provide the TRE, and one method of changing the operator is to physically replace the SIM/USIM card. However, some devices are unattended, so physically changing the SIM/USIM card is difficult. Also, just because a person has physical access to the device does not mean that person has the right to change the operator.
There is currently no flexible authentication mechanism to prevent these types of attacks and drawbacks associated with the prior art.
An embodiment of the present invention provides the device with the ability to authenticate that a provisioning of the device is actually initiated by the owner of the device. The invention also provides the device with the ability to authenticate the Discovery and Registration Function (DRF) involved in a change of operator.
There is need for multiple keys in the process of provisioning Downloadable USIMs (DLUSIMs) and the subsequent change of operator. In the provisioning phase a symmetric key KPIMSI is first used to give initial air time, and following this, an asymmetric (or in some cases, symmetric) key KProvision is used to download the DLUSIM. When the operator is changed, a new KPIMSI may be needed, and the invention provides the ability to send a command to the remote device to authorize the change of operator. Also, throughout the life-cycle of the device, different end-user services may request to set up secure end-to-end connections. This can be done by allowing the end-user services to download their specific clients onto the device. If this is done, it should be done only with the authorization from the device owner. According to the invention the key hierarchy can be used to achieve easier operator change and also to facilitate secure end-to-end service set-up.
According to embodiments of the invention, a device is configured with a device key KDevice and a plurality of one-way functions enabling derivation of a key hierarchy. By introducing a KDevice (and making some keys derivable from this) the management activities are simplified. The present invention derives all other keys from this single KDevice with one-way functions known to the device and device owner, denoted by hi(), 0≦i≦6. By introducing one device key, the invention also simplifies the device-manufacturing process and the usability for the end-user, independent of whether the end-user is an enterprise or a consumer. It is also much easier to let the device change its purpose over time.
To enable this key management scheme, where a manager of the device (most commonly the owner of the device, but this may in different scenarios be also outsourced to another entity or be taken up by a user trusted by the owner) has the final control of the device, the invention provides a method for updating the device key and for changing a subscriber key.
Further, the invention provides a modified Mail device and owner node. According to exemplary embodiments, the owner node is implemented as an enterprise server or as a mobile entity (ME).
Characteristic features of the invention relate to a key-hierarchy extending the DLUSIM framework to also cover general M2M applications and incorporating it into the general Open Mobile Alliance Device Management (OMA DM) framework. A further extension relates to how to change KDevice, and how to change the subscription key without sending it over the cellular channel.
Thus, in one embodiment, the present invention is directed to a method of securely changing control of a device from an old manager to a new manager, wherein the device obeys commands from a manager only if the commands include a device key known to the device. The method includes the steps of initiating the change of control by the old manager, the initiating step including changing a first device key in use between the old manager and the device to a second device key, and sending the second device key from the old manager to the new manager, preferably over a secure connection. The method also includes completing the change of control by the new manager, the completing step including changing the second device key in use between the new manager and the device to a third device key. Upon completion of the change of control, the new manager does not know the first device key and the old manager does not know the third device key.
In another embodiment, the present invention is directed to a method of downloading a new Downloadable Universal Subscriber Identity Module (DLUSIM) to a communication device while changing the communication device from a first operator network to a second operator network. The method begins by a manager of the communication device registering with the second operator network, wherein the registering step includes transferring KAuth to the second operator network. The communication device then receives a bootstrapping message instructing the device to connect to a provisioning service of the new operator network, wherein the bootstrapping message includes an address of the provisioning service of the new operator network and an authentication nonce. The new operator network then validates the communication device when the communication device attempts to connect to the provisioning service, This is followed by the second operator network generating a new DLUSIM and encrypting the DLUSIM with KProvision, and downloading the DLUSIM as an encrypted blob to the communication device from an Open Mobile Alliance Device Management (OMA DM) provisioning server in the second operator network. The communication device then attaches to the second operator network utilizing the new DLUSIM.
In another embodiment, the present invention is directed to a arrangement for downloading a new DLUSIM to a communication device when the communication device changes from a first operator network to a Selected Home Operator (SHO) network. The arrangement includes an OMA DM provisioning server; a Platform Validation Authority (PVA); a Home Subscriber Server/Authentication Center (HSS/AuC); and a registration unit. The registration unit is configured to receive from a manager of the communication device, a subscription registration including KAuth, and to cause a bootstrapping message to be sent to the communication device. The bootstrapping message, which includes an address of the provisioning server and an authentication nonce, instructs the communication device to connect to the provisioning server. Wherein the provisioning server is configured to receive a connection attempt from the communication device; communicate with the PVA to validate the communication device upon receiving the connection attempt from the communication device; upon successful validation of the communication device, communicate with the HSS/AuC to generating the new DLUSIM and to encrypt the new DLUSIM with KProvision; and download the new DLUSIM as an encrypted blob to the communication device, for subsequent attachment of the communication device to the SHO network utilizing the new DLUSIM.
In another embodiment, the present invention is directed to an OMA DM provisioning server in a SHO network for downloading a new DLUSIM to a communication device when the communication device changes from a first operator network to the SHO network. The SHO network is in communication with a PVA and includes an HSS/AuC and a registration unit. The registration unit is configured to receive from a manager of the communication device, a subscription registration including KAuth, and to cause a bootstrapping message to be sent to the communication device. The bootstrapping message, which includes an address of the provisioning server and an authentication nonce, instructs the communication device to connect to the provisioning server. The provisioning server includes a processor coupled to a non-transitory memory that stores computer program instructions. When the processor executes the computer program instructions, the provisioning server is caused to receive a connection attempt from the communication device; communicate with the PVA to validate the communication device upon receiving the connection attempt from the communication device; upon successful validation of the communication device, communicate with the HSS/AuC to generating the new DLUSIM and to encrypt the new DLUSIM with and download the new DLUSIM as an encrypted blob to the communication device, for subsequent attachment of the communication device to the SHO network utilizing the new DLUSIM.
In the following section, the invention will be described with reference to exemplary embodiments illustrated in the figures, in which:
The M2M device 11 uses the standard GSM/UMTS procedures (GPRS/PS) to decode network information, and attaches to the network of any mobile network operator. In the attach message, the M2M device sends its International Mobile Station Identity (IMSI) to the chosen operator, referred to as the Visited Operator (VO) 15. The VO contacts the OHO 12 and asks for authentication vectors (AVs). The HSS/AuC 13 returns the AVs, and the VO uses the received AVs to authenticate the M2M device.
If authentication of the M2M device by the VO is successful, the VO provides IP connectivity for the M2M device to be able to reach the DRF 14. The DRF aids the M2M device to find its new SHO 17. This may be done by sending an OMA DM bootstrapping message 20 to the M2M device. This message also sets the device in a state that enables it to receive a new USIM. The M2M device 11 then connects to the SHO 17, which requests TRE validation credentials from the M2M device. These credentials are forwarded to the trusted third party PVA 16. The PVA validates the authenticity and integrity of the M2M device, and returns the status to the SHO. Upon receiving a positive validation, the SHO prepares a new DLUSIM, encrypts it, and transfers it to the DP-SP 19. The DP-SP provisions a DLUSIM object to the M2M device, possibly by using the OMA DM protocol. The M2M device provisions the downloaded DLUSIM into the TRE and reports the success/failure status of the provisioning to the DP-SP.
As noted above, this existing remotely managed procedure for provisioning an M2M device is complex and still leaves security gaps. An embodiment of the present invention provides the device with the ability to authenticate that a provisioning of the device is actually initiated by the owner of the device. The invention also provides the device with the ability to authenticate the Discovery and Registration Function (DRF) involved in a change of operator.
According to embodiments of the invention, a device is configured with a device key KDevice and a plurality of one-way functions enabling derivation of a key hierarchy. There is a need for multiple keys in the process of provisioning DLUSIMs and the subsequent change of operator. In the provisioning phase a symmetric key KPIMSI is first used to give initial air time, and following this, an asymmetric (or in some cases symmetric, although most of this text will assume an asymmetric key) KProvision is used to download the DLUSIM. When the operator is changed, a new KPIMSI is needed, and the invention provides the ability to send a command to the remote device to authorize the change of operator.
Also, throughout the life-cycle of the device, different end-user services may request to set up secure end-to-end connections. This can be done by allowing the end-user services to download their specific clients onto the device. If this is done, it should be done only with the authorization from the device owner. According to the invention the key hierarchy can be used to achieve easier operator change and also to facilitate secure end-to-end service set-up.
By introducing a KDevice, and deriving other keys from this, the management activities are simplified, In the present invention, all keys are derived from this single key with known one-way functions, denoted by hi(), 0≦i≦6.
In an exemplary embodiment, the following relationships are established:
Update of the device key:
KDevicei+1=h0(KDevicei, params)
Calculate a subscriber key (both KPIMSI and key used by USIM):
KS=h1(KDevice, params)
Calculate Trusted Environment management key (to update functions used by the TRE, also DLUSIM mgmt app):
KTRE management=h2(KDevice, params)
Calculate operator change authentication key (to authenticate change of subscriber key):
KAuth=h3 (KDevice, params)
Calculate end-user-service key (to authenticate an end-user application to the M2M device similar to GBA, can also be used as the application provisioning key):
KEnd-user service=h4(KDevice, params)
Calculate application provisioning key (to manage applications outside of he TRE, may be derived in the same way as the end-user-service key):
KApplication provisioning=h5(KDevice, params)
Additionally, the following one-way function may be used to update he subscriber key in a USIM:
KSi+1=h6(KSi, params)
The parameters are different from key to key, but may include a sequence number, operator identifiers, or other additional data used to bind the key to a specific situation, session, or purpose. In some cases it may be beneficial to use the same one-way function for all derivations, i.e., hi(x)=h(x), 0≦i≦6. In such a scenario the parameters taken as input must be arranged such that collisions of inputs are avoided.
There are different scenarios during which the device being remotely managed for DLUSIM can be deployed. Two exemplary scenarios are when the device owner is an enterprise and when the device owner is a consumer. An exemplary enterprise scenario is when the M2M device is contained in an Automatic Meter Reader. An exemplary consumer scenario is when the M2M device is contained in a car.
Referring to
Referring to FIG, 28, in the consumer case, the device owner may be an individual consumer. In the case with a consumer as an end-user, it cannot be assumed that the consumer owns the server. Thus, the end-user service 23 is shown separately. Preferably, all key-management is handled in an invisible manner for the consumer. It can be assumed, however, that the consumer has a Mobile Equipment (ME) 24 with a Secure Element (SE) 25 at his disposal. An SE is characterized in that internal data processing and data storage is not available to a user external to the SE. A user external to the SE can only access or provide data over an interface to the SE. The ME may be the consumer's mobile phone, which controls a car sensor device 26 in the consumer's car. The car sensor device also includes an M2M device 31 as a subset.
With a standardized method of deriving keys, each manager of the device (SHO 27, End-user service 23, and Software Provisioning Server 28) can receive the keys that allow the manager to perform its duties, and keys can be handled without any resemblance with each other. Yet the impact on the manufacturing process can be kept at a minimum with storage of only one key. The key-deriving methods on the owner side can also be cost-effectively implemented.
On the M2M device 31, there must be support for the required one-way functions and access to the device key. There may also be functionality for updating the device with new key-deriving functions (or new set of parameters) to enable new usages throughout the lifetime of the device. Additionally, functionality for changing the device key (for example in the case of owner change) may also be implemented.
The original device key may be provided as a software key on a storage medium whereby a new key derived from the original key may overwrite the original key or be stored on a separate storage medium. The original device key may also be provided as a hard-coded key, and an actual device key may be derived from the original hard coded key and stored on a storage medium.
The M2M device 31 includes a Trusted Environment (TRE) 32, a unit for application management (OMA DM) 33, and an end-user application 34. Various management units within the TRE such as a TRE Management Unit 35, a KDevice Management Unit 36, and a Downloadable USIM (DLUSIM) Management Unit 37 control the updating of the KDevice 38 and generating of a DLUSIM 39. Dotted lines represent outputs from the management units.
The KDevice Management Unit 36 utilizes the existing KDevice 38 and inputs, for example from an owner node, to update KDevice utilizing: KDevicei+1=h0(KDevicei, params).
A Functions Unit 40 controls a set of functions for deriving other keys based on the KDevice 38 and inputs from the TRE Management Unit 35. These functions include:
It is assumed that a trusted third party has issued an asymmetric key KProvision {KPubM2ME, KPrivM2ME} for an M2M device. The private key is installed in a TRE in the device. The public key is distributed by some method to the owner. An encryption of a message m, using the public key Kpub, is denoted as c=EKPub(m); similarly decryption using the private key, KPriv, is denoted by m=DKpriv(c). KDevice is used as an authenticator. This enables the M2M device to authenticate that the issuer of the command is in possession of the valid device key.
The functions contained in the SE are the same as the ones described in the Enterprise server, but the GUI (Operator/Device Management Application) 56 and other non-secret information such as end-user applications 57 may be located outside of the SE. In this way, no secret information ever leaves the SE.
At step 63, the old owner's node 61 utilizes a public key of a public/private key pair shared with the M2M device to encrypt the currently active device key KDevice0 with a change command and a secret parameter known by the old owner's node, and sends a change device key command C1 to the M2M device 31. The M2M device decrypts the command utilizing the private key of the public/private key pair and determines a device key KDevice0′ at step 64. At step 65, the M2M device compares KDevice0′ with KDevice0 to determine if they are equal. If not, the connection is dropped, and the device key remains the same. To avoid brute force attacks, it is prudent that the time between allowed attempts is regulated, and that the device key has sufficient length.
If KDevice0′ is equal to KDevice0, the M2M device calculates a new device key KDevice1 at step 65 using the currently active device key KDevice0 and the secret parameter received from the old owner's node. The old owner's node also calculates the new device key KDevice1 at step 66 so that the new device key KDevice1 does not have to be transmitted over the air interface. At step 67, the old owner's node sends the new device key KDevice1 to the new owner's node 62, preferably over a secure connection. This provides the new owner's node with control over the M2M device without disclosing the old device key, KDevice0.
At step 68, the new owner's node 62 utilizes the public key to encrypt the new device key KDevice1 with a change command and a secret parameter known by the new owner's node, and sends a change device key command C2 to the M2M device 31. The M2M device decrypts the command utilizing the private key and determines a device key KDevice1 at step 69. At step 70, the M2M device compares KDevice1 with KDevice1 to determine if they are equal and if so, the M2M device calculates a new device key KDevice2 using the new device key KDevice1 and the secret parameter received from the new owner's node. The new owner's node also calculates the new device key KDevice2 at step 71 so that the new device key KDevice2 does not have to be transmitted over the air interface. Note that all commands are protected by the asymmetric key KProvision, which is not known outside of the TRE 32 of the M2M device, and therefore the new KDevice2 is impossible for the old owner to retrieve. This scenario is also applicable, for example, when ownership of a car is transferred between an old owner and a new owner.
According to a second exemplary embodiment, an operator change is performed without explicitly sending a USIM or a subscriber key over the air to the device.
According to the invention, a change of operator is performed by the old operator handing over the subscriber key to the new operator. However, as in the previous embodiment, the old and the new operator would like to be able to change the keys to protect themselves against the other operator.
It is assumed that a subscriber key, KS0, is installed in the M2M device 31, and the old operator 81 is in possession of an authentication key, KAuth0). When the owner 83 of the M2M device creates a new subscription with the new operator 82, the owner derives at least two authentication keys {KAuth1,KAuth2} from KDevice according to KAuth=h3(KDevice, params) at step 84. The first key, KAuth1, is used to authenticate the change of the subscriber key at start of the subscription period. The second key, KAuth2 for the new operator and KAuth0 for the old operator, is used to change the key before handing over the device to a new operator. In one embodiment, the owner may send the authentication keys to the new operator in a subscription registration message at 85, and the new operator informs the old operator at step 86 that the new operator has a new subscription with the M2M device. Of course information may be sent between the entities in different ways due to different setups. For example, the owner may only provide KAuth2 to the new operator at the time of operator change. In this way, the operators do not have to store KAuth2 for the entire subscription period of the device.
At step 87, the old operator 81 utilizes the public key to encrypt KAuth0 with a change command and a secret parameter known by the old operator, and sends a change subscription key command C1 to the M2M device 31. The M2M device verifies the command at step 88, and if the currently active authentication key KAuth0 is correct, the M2M device calculates a new subscription key KS1 according to KS1=h6(KS0, secret). The old operator then calculates the new subscriber key KS1 at step 89 so that the new subscriber key KS1 does not have to be transmitted over the air interface. At step 90, the old operator sends the new subscriber key KS1 to the new operator, preferably over a secure connection, At step 91, the old operator then orders the M2M device to change its IMSI via OTA.
At step 92, the new operator 82 utilizes the public key to encrypt KAuth with a change command and a secret parameter known by the old operator, and sends a change subscription key command C2 to the M2M device. At step 93, the M2M device derives a value for KAUTH1′ according to (KAUTH1′, ChangeKSECMD, Secret)=DKPrivM2ME(C2). At step 94, the M2M device then verifies that KAuth1′=h3(KDevice0,param1) and if so, the M2M device calculates a new subscription key KS2 according to KS2=h6(KS1, secret). The new operator then calculates the new subscriber key KS2 at step 95 so that the new subscriber key KS2 does not have to be transmitted over the air interface.
It can be seen that the owner 83 initiates the process, and then the old operator 81 takes over, changes the subscription key, and informs the new operator 82. The new operator then again changes the subscription key, after or before which the new operator may have made a validation of the M2M device. It is important that the device is always placed in an HSS with the correct IMSI and KS. This information can be put in the HSS before the change of subscription key is made, as shown in
To be able to calculate the resulting key after a run of the key update procedure, an attacker needs to have knowledge of both the previous subscriber key stored in the TRE 32, and the secret sent by the operator. An attempt to change the subscriber key without an included valid authentication key, KAuth results in an aborted procedure. The current authentication key should still remain active, as switching to the next would risk synchronization issues and denial-of-service attacks.
According to still another embodiment, owner and operator are both changed. In the case of an owner change of device, the new owner may also like to switch the operator. In this scenario, it is important to avoid updating a device key and a subscriber key simultaneously. This might result in derived keys that are different on the device and the operator side. The new owner should make sure that he has updated the device key before he contacts the newly selected operator and initiates the switch.
Initially, the M2M Device 31 is attached to the old home operator's (OHO) network 81. At step 101 the owner registers at a new Selected Home Operator (SHO) 82 and transfers the KAuth as defined above and shown in
The carrier for both the bootstrapping message and for the DLUSIM blob may be OMA DM. In the above, it is assumed that the authentication nonce in the bootstrapping message is based on KAuth. Also, the bootstrapping message may include either a certificate identifying the new SHO, or there may be a KAuth also in the encrypted DLUSIM blob.
Preferably, the USIM is never revealed in a decrypted state outside of the TRE, and preferably KAuth is not revealed outside of the TRE either. From an implementation perspective, the OMA DM client may be located outside of the TRE, and thus in another embodiment, KAuth is not coupled to OMA DM. KAuth may be used either as a password or the basis of a password, which is included in the encrypted blob as a parameter, or KAuth can be used as a integrity protection key such as the key used in a MAC used to protect the encrypted blob.
On the server side, KAuth may be utilized by the OMA DM server, but there are other setups where this is less appropriate. One example is when the OMA DM server is not positioned in the new SHO network. In this case, the operator may apply KAuth, and confidentiality protection before handing the encrypted SIM over to the third party supplying the OMA DM service.
The various embodiments described herein may use OMA DM functionality to implement the various functional steps. OMA DM is preferred as the carrier of a DLUSIM, and it is hence preferred to use the OMA DM Mgmt Tree to organize these changes. However, the OMA DM client (which is the engine using the OMA DM Mgmt Tree) is not the sole entity involved in the management of the DLUSIM. There may also be a DLUSIM Mgmt client, which is using the OMA DM client as a subroutine for the provisioning part. Even if the security of the DLUSIM does not hinge on the security of the OMA DM, the OMA DM Mgmt Tree should look correct. Also, the OMA DM engine's security should be based on KDevice for other management changes.
It is assumed that the device owner has control of the OMA DM Mgmt object “SEMO”. This means in practice that a default OMA DM server identifier may be <device.owner> and that the <device.owner> has Access Control List (ACL) value:
Add=device.owner&Delete=device.owner&Get=*&Replace=device.owner.
The <device.owner> mgmt server may be authenticated by a KApplication Provisioning. It is also acceptable if this same key or derivations of it are used for authenticating other parts of the OMA DM Mgmt Tree. The KApplication provisioning can of course also be calculated by the TRE. So in principle, the TRE can manage the SEMO in the OMA DM Mgmt Tree itself.
All functions and DLUSIMs in the SEMO then have their own management objects in the SE, which are situated below the SEMO in the OMA DM Mgmt Tree. These functions and DLUSIMs have an extended ACL compared to above, where the SPs or operators can be added to the list as well. To manage these functions in the TRE itself, another key called KTRE Management, also derived from KDevice, is used in a similar fashion as in the DLUSIM download mechanism described above. This setup gives the device owner the final say in what is happening in his device, but allows the operators to check and verify that no other DLUSIMs are installed in the device, and also to securely manage their own objects.
Further embodiments may use GBA functionality for implementing various detailed functional steps. The KEnd-user service may, for example, be KS-NAF as defined in the 3GPP GBA standard; and the KDevice functions as KS. This requires that the ME function as the Bootstrapping Server Function (BSF) in the consumer case. To illustrate this use case, consider the case in which the MM device is a car. Here the owner of the car wants to connect an insurance service to the car. By surfing in to the insurance site, performing a key exchange with the insurance company, and then logging in to the car and performing a similar key exchange, the car and the insurance company can now set up a secure connection with each other according to GBA.
As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a wide range of applications. Accordingly, the scope of patented subject matter should not be limited to any of the specific exemplary teachings discussed above, but is instead defined by the following claims.
This application is a divisional of co-pending U.S. patent application Ser. No. 12/606,490 filed Oct. 27, 2009, which claims the benefit of U.S. Provisional Application No. 61/108,994 filed Oct. 28, 2008, the disclosures of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 20130185560 A1 | Jul 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61108994 | Oct 2008 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12606490 | Oct 2009 | US |
| Child | 13711990 | US |
