Patent Application
20090191857
1. Field of the Invention
The present invention generally relates to a system and method for remotely modifying device configurations such as machine subscriptions such that that the credentials of those subscriptions (algorithms, keys) may be implemented in a secure environment.
2. Description of the Related Art
General requirements and use cases are being developed, for example, by the third generation partnership project (3GPP) SA3 (the Security Working Group), to facilitate machine-to-machine (M2M) communication in 3GPP-defined mobile communication systems, and remote management and configuration of M2M terminals. For purposes of the present application, M2M communication is defined by the fact that an M2M terminal, which can be a terminal communicating over 3GPP or similar wireless network, does not have to be attended by a human user.
A universal subscriber identity module ((U)SIM) is an application for the universal mobile telephone system (UMTS) mobile telephony running on a Universal Integrated Circuit Card (UICC) smart card which is inserted in a 3G mobile phone. The (U)SIM is a logical entity on the physical card that stores user subscriber information, authentication information and provides storage space for text messages and phone book contacts and that includes an enhanced phone book. For authentication purposes, the (U)SIM stores a long-term pre-shared secret key K, which is shared with the Authentication Center (AuC) in an associated wireless network. The (U)SIM also verifies a sequence number that can be within a range using a window mechanism to avoid replay attacks, and is in charge of generating the session keys CK and IK to be used in the confidentiality and integrity algorithms, such as a KASUMI, or A5/3, block cipher in UMTS.
M2M terminals differ from typical mobile terminals (MS) in that the owner does not necessarily have easy access to the M2M terminals. As described in greater detail below, a M2M terminal may be used to track a moving product. An M2M terminal may also be used for metering, for example, to automatically transmit utility use data from a household.
Because the M2M terminal is not attended by a person, some current procedures related to the handling of the (U)SIM implemented on a smart card (UICC) may be cumbersome and costly. Therefore, there is a need for new or modified procedures to make M2M communication viable in the market at a large scale.
For example, in the conventional networks configurations, a physical (U)SIM change is used to realize a change of a service provider subscription. For the M2M case, this physical (U)SIM change is usually not a viable option, because of the amount of (U)SIM to be changed, the terminals could be distributed all over the country, and/or the (U)SIM may be physically inaccessible in the M2M terminal. For example, M2M-based meters may be distributed over thousands of houses and each of these MSM-based meters is typically secured and hidden in the meter to avoid tampering and manipulation.
A problem to be solved then becomes how to securely update a (U)SIM, so that it may become an authentication device for another network. At the same time, an M2M operator wants to avoid any situation, in which he needs to reveal security relevant data to a third party.
In other situations, it is known to modify network usage by updating of parameters in a Home Subscriber Server (HSS), also known as a Home Location Register (HLR) or a User Profile Server Function (UPSF). The HSS is a master user database that supports the IMS network entities that actually handle calls. In particular, the HSS contains the subscription-related information (user profiles), performs authentication and authorization of the user, and can provide information about the user's physical location.
In the field of computing, a Trusted Platform Module (TPM) can be used to authenticate hardware devices. Since each TPM chip has a unique and secret RSA key burned in during the production, it is capable of performing platform authentication. For example, it can be used to verify that the system seeking the access is the expected system. The TPM offers facilities for secure generation of cryptographic keys, the ability to limit the use of cryptographic keys, as well as a hardware random number generator. The TPM also includes capabilities such as remote attestation and sealed storage. Remote attestation creates a hash key summary of the hardware and software, and the extent that the software is being summarized is decided by the software that is encrypting the data. This configuration allows a third party to verify, for example, that the software has not been changed. Either sealing or binding techniques may be used in a TPM. Sealing techniques are used to encrypt data such that it may be decrypted only if the TPM releases the right decryption key, which occurs only if the exact same software is present as when it encrypted the data. Binding techniques encrypt data using the TPM's endorsement key, a unique RSA key burned into the chip during its production, or another trusted key.
In one embodiment, a method remotely updates stored subscriber identification parameters over a wireless network. The method includes establishing new parameters from a new operator for updating stored subscriber identification, and checking the integrity of the new parameters using data received from an old network operator. Then, an existing connection to the network is stopped and the connection is reestablished using the new parameters.
The new parameters may relate to a new network operator. The establishing of the new parameters may include storing the new parameters in parallel to the stored parameters and prioritizing the new parameters. The method may further include receiving authorization to update the parameters. The receiving of the authorization to update the parameters may include accepting a secure connection from the old network operator, receiving a token from the old network operator, where the token includes the new parameters, and verifying the token. The token may include an identifier of the new network operator, and where the verifying of the token includes analyzing the identifier. The new parameters may result in a change from the current network operator to a new network operator.
The method may be performed by a machine-to-machine terminal and/or by multiple devices. The new parameters may include changes in a universal subscriber identity module. Also, the new parameters may result in a change from the old network operator to the new network operator.
The method may further include forwarding a first random number, receiving a second random number, accepting a secure connection based on the first and second random numbers, and receiving the new parameters over the secure connection. The second random number may be produced by a new network operator, and where a computer associated with an owner of the device exchanges the both the first and the second random numbers between the device and the new network operator.
In another embodiment, an apparatus for remotely updating stored subscriber identification parameters over a wireless network. The apparatus includes a storage device configured to store the subscriber identification parameters. A processor configured to establishing new parameters for updating subscriber identification and to check the integrity of the new parameters using data received from a current network operator. A transmitter configured to stop a connection to the network and to reestablish the connection using the new parameters. The apparatus may be machine-to-machine terminal. For example, the apparatus may be a meter or a tracking device. The new parameters may include changes in a universal subscriber identity module stored in the apparatus.
The storage device is further configured to store the new parameters in parallel to the stored parameters to prioritize the new parameters. The storage device may also be configured to remove the new parameters, and where the transmitter is further configured to restore the connection to the network using the stored parameters.
The apparatus may further including a receiver configured to receiving authorization to update the parameters. The receiver may be further configured to accept a secure connection from the current network operator, and to receive a token from the current network operator, where the token includes the new parameters; and where the processor is configured to verify the token. The token may include an identifier of a new network operator, and where the processor verifies the token by analyzing the identifier.
The processor may be configured to produce a first random number and a transmitter is configured to send the first random number to the network. The receiver may be configured to receive a second random number, accepts a secure connection based on the first and second random numbers; receives the new parameters over the secure connection. The second random number may be produced by a new network operator, and a computer associated with an owner of the apparatus may exchange the both the first and the second random numbers between the apparatus and the new network operator.
In another embodiment, a method for remotely updating stored subscriber identification parameters over a wireless network includes accepting a secure connection from new network operator and establishing new parameters for updating stored subscriber identification, where the new parameters are received from the new network operator over the secure connection. The method continues with checking integrity of the new parameters, stopping a connection to the network, and reestablishing the connection using the new parameters. The method may be performed by a machine-to-machine terminal or by multiple devices. The new parameters include changes in a universal subscriber identity module. For example, the new parameters may result in a change from an old network operator to the new network operator.
The establishing of the new parameters may include storing the new parameters in parallel to the stored parameters and prioritizing the new parameters. The accepting of the secure connection may includes computing a session key using either a hash or a reverse hash, establishing an authentication and key agreement, or using public key cryptography with private and public signing keys.
The receiving of the authorization to update the parameters may include receiving a token, where the token includes the new parameters and verifying the token. The token may include an identifier of the new network operator, and the verifying of the token includes analyzing the identifier.
In another embodiment, an apparatus is configured for remote updating of stored subscriber identification parameters over a wireless network. The apparatus includes a receiver configured to accept a secure connection from new network operator, a processor configured to establish new parameters for updating stored subscriber identification, where the new parameters are received from the new network operator over the secure connection and to check integrity of the new parameters, and a transmitter configured to stop a connection to the network and to reestablish the connection using the new parameters. The apparatus may further include a storage device configured to store the new parameters in parallel to the stored parameters and to prioritize the new parameters. The apparatus may be a machine-to-machine terminal. The new parameters include changes in a universal subscriber identity module. The new parameters may result in a change from an old network operator to the new network operator.
The processor may be configured to compute a session key using either a hash or a reverse hash; establish an authentication and key agreement, or use public key cryptography with private and public signing keys.
The receiver may be configured to receive a token including the new parameters over the secure connection; and the processor may be configured to verify the token. The token may include an identifier of the new network operator, and where processor is configured to analyze the identifier.
For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:
In response to these and other needs, embodiments of the present invention provide solutions that address the problem of securely and remotely updating a (U)SIM with authentication and key agreement parameters. These solutions allow moving the subscription of an M2M terminal from one operator to another, without causing the costs involved with a manual update.
Referring now to
As described in greater detail below, the token may be sent to the machine directly or via the machine owner. The data to be updated might be shipped to the machine using application level protocols or Open Mobile Alliance Device Management. The token is presented to the machine, which verifies the token, in step 114. In step 114, if the verification is successful, the M2M machine may grant permission to update certain fields on (U)SIM with destination specific information such as the algorithm, keys, IMSI, etc. An IMSI is a unique identifier of the subscriber in the new network or, more accurately, the specific terminal of the subscriber. Similarly, authentication and key agreement algorithms may be used in the method or, alternatively, some parameters that allow customization of the authentication and key agreement algorithms.
Continuing with
In another implementation, the old operator 220, when creating the token in step 112, can imbed a name, or other identifier for the new operator. This way, the mobile device 250, after receiving the token can verify the token by matching the token and the update information.
After the (U)SIM has authorized the arrival of updates, the actual update of the mobile device is done, using the information in the Token to establish parameters for modifying the (U)SIM in step 121. In particular, the transmitted token received by the device includes the new parameters such as the IMSI, keys, authentication and key agreement algorithms and/or parameters, etc. for converting a (U)SIM-1 into a (U)SIM-2. Preferably, this update is done in two steps. In a first step the new parameters are installed parallel to the old ones in step 122 and an indication is sent that the new set has priority in step 123. For example, the old set may be flagged to expire after the next reset of the equipment. This proceeding allows implementation of a fallback to the old parameters, in case something goes wrong
Similarly, in step 121, a company may equip a phone with several software based (U)SIMs or ISIMs for roaming purposes. The company may then switch operator for example, by activate a different (U)SIM or ISIM. In this implementation, the token does not contain the necessary parameters, but instead directs the device to select from the different (U)SIM or ISIM already present on the device.
The terminal and/or (U)SIM may check the integrity of the new parameters, step 124. As some of the parameters contain confidential information, such as a. secret key, the parameters should be sent encrypted. Then, the machine resets at least its network connection in step 125.
On re-establishment of the network connection in step 126 the parameters of the destination network are used. On successful connection establishment, the new parameters will permanently replace to old parameters, making the transfer to the new network final. The (U)SIM is transformed in an authentication and key agreement device for the new network.
Referring now to
Continuing with
The machine 250 verifies the token against replay attacks. Protected hardware 255 in the device 250 to check the hash value of the token. If everything is acceptable, the (U)SIM in the device 250 is put in a state in which it is willing to implement new parameters, as described below in
In
For example, the HSS-HLR/AuC in the new operator calculates (gRh)Rh. M2M calculates (gRh)Rm. Because (gRm)Rh=(gRh)Rm, both HSS-HLR/AuC and M2M machine now have a key code number that is unknown to the public and that can be used to derive a symmetrical session key. This session key can encrypt all secret information HSS-HLR/AuC and M2M machine need to exchange (such as a new Ki, new algorithm parameters, new algorithm, etc.) in step 460.
These calculations are typically carried out in a finite field in which it is infeasible to calculate logarithms. The number g should be a generator of this finite field, such that each different number pairs N and gN give a different result. As described below, the calculations are typically carried out in protected HW in the device 250. The value for g is not secret. In the flow above, g is considered to be a predefined value. In another embodiment, the machine 250 and HSS-HLR/AuC in the new operator 230 agree explicitly upon a value for g (with machine owner as intermediary). Also the finite field in which the calculations are performed are preferably fixed. This fixing of the finite field can be done also either explicitly or implicitly. In order to provide an acceptable amount of security, the finite field is preferably a relatively large, for example 2048 bits or larger.
A (U)SIM parameters transferring system 500 in accordance with embodiments of the present application is illustrated in
Referring now to
A (U)SIM provisioning system 700 in accordance with embodiments of the present application is presented in
Likewise, the operator 720 may include a processor 721, memory 722, and input and output device 723. The destination 720 may further include software 725 and related hardware 726 for performing the functions related to the receiving and decoding of the broadcast of signals, as disclosed in the present application.
The device 730 may also include a processor 721, memory 722, and input and output devices 723 and 724, as needed to receive and forward a message. The relays 730 may further include software 725 and related hardware 726 for performing the various functions related to the receiving and decoding of the broadcast of signals, as disclosed in the present application. For example, the relays may receive and store messages to be transmitted, and access the memory and transmit the stored messages. Thus, the processing of the messages to be transmitted may be performed, as needed by circuitry in the hardware 726 or software 725.
In another embodiment of the present application present at
The M2M terminal owner 810 could also let the DSEs for his M2M terminals 840 be handled by an agent, such as a service provider specialized in this task, or a mobile network operator. The M2M terminal owner 810 would then, however, have to trust this other entity to handle the DSE securely.
As described below, in the system 800 of
The DSE may contain security credentials mirrored in the M2M terminal 840 which can be used to protect download of (U)SIM parameters from an Over-the-air (OTA) download center, associated with an the new operator 820, on to the M2M device. The DSE may also contain a private/public key pair for signing information sent to an operator. The public key may be accompanied by a certificate.
In at lease one configuration, security credentials needed to secure a download procedure are stored on the DSE Such credentials could be realized by one entry from the following non-exhaustive list: session key SK would then be computed as SK=HASH (RK, COUNTER value, etc. The validity of SK could be limited, and this limit could consist in a maximum duration, or a number of well-defined transactions, or one session between an OTA center and M2M device. Another important limit which could be set to limit the use of SK is that SK becomes invalid after as soon as the M2M terminal 840 receives a message protected by a session key computed with a higher COUNTER value as input. In order to prevent replay attacks, the M2M terminal 840 stores the latest COUNTER value used, and accept only higher COUNTER values.
Only SK and COUNTER, not RK would be disclosed by M2M owner 810 to the network operator 820. In this way, the network operator would not be able to control the M2M device forever, but only within the defined limits for the use of SK. Instead of counters, also other time-variant parameters, such as time-stamps could be used.
In another implementation, in order to avoid forcing the M2M terminal owner 810 from compute the session keys in a potentially insecure environment, the DSE may contain a sufficiently large number of independent (session key, COUNTER) pairs. The M2M terminal owner 540 could then hand such a pair to an operator of his choice when the M2M terminal owner 810 wants to obtain a subscription from this operator. The M2M terminal 810 would still need to store only RK and could compute the session key from RK and the received COUNTER value. COUNTER could also be another time-variant parameters, such as a time-stamp.
In another implementation, a hash chain is defined as follows: there is a secret root key RK, and a function HASH. Session keys SK(n) are then obtained be the formulae SK(0)=RK; SK(n)=HASH (SK(n−1)). Session keys SK(n) would have to be released first, then SK(n−1) etc., so one has to be sure to start with a sufficiently high n. All considerations on limits in a1) would apply accordingly. The idea in a2) would also apply accordingly.
In another implementation. this variant uses an implementation of an identical or modified copy of UMTS AKA in DSE and M2M terminal 830. In this way, the DSE would have the AKA functionality of an Authentication Center AuC (but not necessarily the same HW/SW structure as an AuC), the OTA server would have the functionality of a VLR or SGSN. For more information on the roles of AuC, VLR and SGSN, see, for example, 3G TS 33.102. The advantage of this configuration generally is a stronger freshness guarantee if the DSE generated the RAND in real time, and a more flexible replay protection mechanism through the use of the array mechanisms as defined in TS 33.102.
Similarly, the DSE could contain a number of pre-computed AKA authentication vectors, which could be handed to different operators one after the after. AuC functionality would not be required to be executed by the DSE 810.
In another variation, public key cryptography and, more specifically, uses a private signing key on the DSE for which the M2M terminal has the public verification key, and use of a public encryption key on the DSE for which the M2M terminal has the private decryption key. It would be possible to reveal the signing key to network operator 820. Then, the DSE would not have to be involved online in the download procedure. But this revelation of the signing key may be undesirable. Then, the DSE would have to be involved online in the signing process, as opposed to alternatives presented above. For a possible use of public key cryptography to protect the download of secret information, in particular secret cryptographic keys, See, for example. the DSKPP IETF.
In another configuration, several copies of private signing and public encryption keys could be stored on the DSE. Then, the corresponding public verification key and private decryptions keys may be stored on the M2M terminal 840.
Combination of these credentials from the above described embodiments may also be used. In one example providing authorization, public key cryptography may be used together with DSKPP or with OMA DM (Device Management, cf. http://www.openmobilealliance.org/), but the authorization of the OTA server to the M2M terminal 840 would be achieved using a one-time secret credential obtained, for example, according for example, to results of a hash table. In this example, the M2M terminal owner 810 would obtain a spare (SK, COUNTER) according to using a hash table or storing multiple points and from the DSE and give it to the operator of the OTA server, which sends it to the M2M terminal. The M2M terminal would then consider the OTA server as authorized to download information to the terminal if the terminal can obtain SK from RK and COUNTER or if some token protected with SK as input can be verified by the terminal. The use of a DSE for securing the download of a (U)SIM to a n M2M terminal is illustrated
Referring now to
Continuing with
Process flow 1000 of
While the above discussions refer to adapting (U)SIM for changing network operators, as a generalization, the same mechanisms could be applied to any set parameters to be updated in the (U)SIM. Likewise, as a further generalization, it is possible to use the invention also for other purposes besides M2M communication in a 3GPP context. For example, similar techniques may be used with any identity management system based upon the presence of identity specific parameters present in a tamper resistant memory, or with a MVNO (mobile virtual network operator) when changing from one network to another to avoid the requirement of changing the (U)SIM.
In one current application, M2M communications are used, for example, to track and trace products. For example, certain cars rental may be equipped with tracking devices to obtain the car's position for inventory purposes and to locate the car in case of theft. Similarly, M2M communications may be used for tagging relatively expensive tools and equipment, such as containers or tools in the building industry or oil industry. Typically, the M2M communications are used with relatively expensive goods where the high value of the product justifies the costs associated with the M2M-based tagging and the handling overhead, and the embodiments of the present application, as described above, may help to reduce these costs by minimizing maintenance costs associated with the M2M devices.
Using M2M communications for product tracking presents entails certain needs that are addressed through the embodiments of the present application. One aspect of M2M communications for product tracking relates to provide tamper and theft resistant mobile terminal associated with the device that includes the UICC. The tamper and theft resistant mobile terminal is conventionally provided by constructive measures, such as locking the entire M2M module within a secure enclosure and, in some cases, mounting the M2M module at places that are difficult to discover and/or access. This security requirement makes the M2M application relatively difficult to handle and, thus, even more expensive for the M2M user. For this and other reasons, the M2M user typically can access the M2M terminals only in certain instances, such as during maintenance of the tracked product. Only at these times can the user perform maintenance of the M2M equipment, including checking whether someone has tampered with the M2M equipment or swapping UICCs.
A second need for M2M communications for product tracking arises due to a need of the M2M users to have a reliable, long term functional and viable M2M application for the lifetime of a product. Toward this goal, it may be desirable for the M2M user to change the wireless communications subscription associated with the M2M device. For example, if tagged products are moved to a new location, a current service provider may no longer provide adequate in the new location. However, changing service providers in conventional configurations may be difficult with the conventional UICC configurations used in the M2M terminals due to a need to physically access and change the (U)SIM settings, especially when a M2M user has a substantial numbers of M2M terminals in the field. As described above, the user may have only limited access to the tagged products, and even when given this access, configuring the M2M terminal is difficult due to its hidden, secure configuration. Accordingly, embodiments of the present application address this need of providing a reliable, long term functional and viable M2M application for the lifetime of a product. by easing transitions between network operators as needed to control costs and to ensure improved service quality.
Overall, there may be many M2M applications where the above-mentioned problems related to securing the M2M terminals within a product while providing sufficient access to enable maintenance and service changes cannot be resolved. Thus, M2M terminals historically could be used for tracking and tracing of a large percentage of the current market goods, but that the embodiments of the present application may allow the M2M terminals to be applied on a broader basis.
In another application, M2M terminals may be used to product/servicing metering. In this application, the M2M performs functions related to transmitting information regarding the status and usage of a metered good or service. A metering device is usually untouched after installation for years. Again, the UICC should to be protected against theft and removal to prevent use of the connection to the utility for fraudulent purposes, and consequently it would be generally difficult to access the UICC.
Furthermore, changing the utility (and probably the mobile network operator) may face obstacles. While the M2M terminal in this application requires no mobility since the device mounted to a fixed location, high flexibility is desired in the allocation of the M2M terminal in case of utility change and/or mobile network operator change. The most complex case occurs when a utility customer changes his utility configurations, such as switching between power suppliers. If the new power supplier happens to contract with a different wireless network operator, either complex accounting mechanisms are needed or the utility must send out a service person to change the (U)SIM. Both solutions are relatively costly and prone to misallocations. Accordingly, embodiments of the present application address this need of providing a reliable, long term functional and viable M2M application for the lifetime of a product by easing transitions between network operators as needed to control costs and to ensure improved service quality.
For example, in embodiments of the present application, a company may equip a phone with several software based (U)SIM/ISIM's for roaming purposes. The company may then switch operator, for example by activating a different (U)SIM/ISIM, in one of the roaming countries. This would result in the same mechanism as in metering.
Similarly, embodiments of the present application ease transitions between network operators as needed to control costs and to ensure improved service quality to allow the network to support moving of large “subscription bulks.” For example, embodiments of the present application allow a group of M2M devices to change operators as needed, for example, to change operators for M2M devices used by a rental car company tracking its fleet, without or with minimal manual interaction on the subscriber database.
It should be noted that in the context of this invention report we focus on machine subscriptions in the sense that the credentials of those subscriptions (algorithms, keys) may also be implemented in software in a secure environment. The present invention is not restricted to use with a UICC smart card. In particular, the present application, when talking about (U)SIM (and ISIM), is directed to a combination of software and hardware that complies with the functions specified in 3GPP TS 31.102 ((U)SIM) or 3GPP TS 31.103 (ISIM).
In conclusion, the present application provide several embodiments to provision USIM information. In certain embodiments, authentication is done through a current operator in the switch to the new provider, and in other embodiments of the present application, the authentication is done without involving the current operator. Both solutions provide significant advantage over the conventional solution. By limiting the choice of cryptographic algorithms, neither of the embodiments requires central storage. Thus, none of the embodiments presented in the present application require the introduction of central entity such as a globally working registration service.
The involvement of the current operator may be advantageous in that the involvement of the first network operator can provide an additional instance of control against misuse of the USIM download functionality.
Conversely, using the current network operator as a trusted intermediary may be somehow problematic for a number of reasons. For example, using the current network operator as an intermediary may reduce security. Also, the M2M terminal owner may be dissatisfied with the first network operator and may have lost trust. Moreover, the first network operator may no longer be able or willing to cooperate in this process. For example, the operator may have gone out of business.
For embodiments without involvement of the current operator, the machine owner 810, or an associated agent, stores the DSE. For example, a specialized service provider may help to securely store the DSE.
Moreover, one having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.
