Mobile terminals have to be configured with various settings to control its operation and to provide various functions and support various services.
One known method of configuration of mobile telephones with service related data is via for example a modified SMS, which includes the relevant settings. This is a unidirectional path and to be able to perform bidirectional service, Open Mobile Alliance (OMA) has specified protocols, data models, and policies for device management (DM). One of the important functions in these specifications is the bootstrap function, which configures the device with basic DM parameters, i.e credentials that facilitate mutual authentication between the DM system and the device, and GPRS connectivity parameters (DM bootstrap).
OMA has defined three different variants of the bootstrap function to support different business models. One method is factory bootstrap, wherein the device is configured with basic DM parameters at manufacture. A second method is DM system initiated bootstrap, wherein the device is configured with basic DM parameters by a DM system over the air. The device may also be configured with basic DM parameters through a smartcard (SIM or USIM), which a third method called Bootstrap via smartcard.
There are, however, several problems and drawbacks associated with systems using these methods.
Factory bootstrap method requires that the basic parameters are known at the time of manufacture or at the time of selling the apparatus. This might be known for telephones to be sold exclusively by an operator. One known method is to configure the mobile telephone at the time of selling the telephone as described in US 2005/0033693 A1. An automatic dispenser is provided, comprising means for configuring the electronic device in response to user input via a user interface. A terminal type, subscription etc. is selected via the user interface and the terminal is automatically configured accordingly, so that the customer can leave the shop with a fully configured terminal.
DM bootstrap method specifies that IMSI (International Mobile Subscriber Identity) must be used to encode the basic DM parameters when a DM system performs bootstrap over the air. This is done by sending an encrypted SMS with the basic parameters to the mobile terminal. The shared secret used for the encryption is the IMSI.
The IMSI has however not been designed to be secret, and thus it is not secret. With access to an IMSI of a particular device a rough DM system can send a bootstrap over the air to that device. The rough DM server can then request the device user to establish a “secure” DM session and then change the device's service configurations in such a way that some or all services stop working. The rough DM system may also get access to sensitive information in the device.
As a complement to the OMA DM specifications (OMA DM) 3GPP has specified the Automatic Device Detection (ADD) function that facilities detection of new device/smartcard combination in a GSM/WCDMA network [3GPP 22.101]. ADD is a function implemented in the HLR (home location register), which checks if the IMEI (International Mobile Equipment Identity) has been added (a new subscriber) or changed for a subscriber (a subscriber changing device).
By supporting the ADD function, combined with DM system initiated bootstrap, the DM system will be notified when a new subscriber is added to the network or an existing subscriber moves its smartcard to another device. Thereby, the DM system has the possibility to automatically send the basic DM parameters over the air to the device and then through a secure DM session configure the device with relevant services.
The Bootstrap over the air method is considered insecure by some operators tried to convince device manufactures to not allow this type of bootstrap in their devices. As a result, depending on device brand and model, it will not be possible to combine the 3GPP ADD function and bootstrap over the air in a DM system to automatically configure relevant services in a device.
Instead operators have preferred bootstrap through smartcard that is considered secure. The operator's business system subscribes on synchronized data, i.e to get a notification when the device has been updated with service related parameters. Provisioning data, i.e basic DM parameters and service related parameters are delivered by the operator's business system to the DM system. These parameters are stored in the DM system.
The DM system is ordered to transfer the stored service related parameters to the device. The DM system assumes that a smartcard with the basic DM parameters has not been inserted in the device and waits for that to happen. The user of the device receives a smartcard with pre-configured basic DM parameters from the operator. The user inserts the smartcard into the device and after switch on, the device reads the basic DM parameters from the smartcard and establishes a DM session to the DM system. The DM system configures the device with service related parameters previously received from the operator's business system. The DM system notifies the operator's business system that service related parameters have been configured in the device.
The disadvantage with bootstrap through smartcard is that it is difficult to combine with the 3GPP ADD function. The main reason for this is that the DM system, when detecting a device, is not aware of what basic DM parameters that have been stored on the smartcard. This means that the DM system, must be configured with the device's basic DM parameters before device detection to allow the device to establish a secure DM session.
Another disadvantage is that there usually exists a lot of smart cards((U)SIM cards) already in use by subscribers, and these needs also to be configured.
It is also a drawback that the ADD function will trigger a change of no use, i.e. it is not taken care of.
A smartcard in a device may also be updated with basic DM parameters over the air. The operator's business system subscribes on synchronized data. i.e to get a notification when the device has been updated with service related parameters. Provisioning data, i.e basic DM parameters (user id, password and GPRS connectivity parameters) and service related parameters (e.g. E-mail settings) are delivered by the operator's business system to the DM system. These parameters are stored in the DM system.
The operator's business system orders the DM system to transfer the stored service related parameters to the device. The DM system assumes that a smartcard with the basic DM parameters has not been inserted in the device and waits for that to happen.
The operator's business system orders a smartcard management system to update the smartcard with basic DM parameters. The smartcard management system downloads the basic DM parameters to the smartcard over the air. As an alternative, the DM system may, after having received the basic data above, deliver the data to the device.
Since no IMSI/IMEI has changed there will be no change detection by the ADD function. That means that DM may be initiated first when the user spontaneously reboot his telephone. Hence, after switch on, the device reads the basic DM parameters from the smartcard and establishes a DM session to the DM system. The DM system configures the device with service related parameters previously received for the operator's business system. The DM system notifies the operator's business system that service related parameters have been configured in the device.
The disadvantage with bootstrap through smartcard is that it is difficult to combine with the 3GPP ADD function. In this case the device has been detected at an earlier point of time, i.e when the smartcard was inserted in the device for the first time. This means that the DM system will not detect the device again when it reads the basic DM parameters from the smartcard. The DM system discovers the device when it tries to establish a secure DM session, but this session will be rejected by the DM system unless it has previously been configured with the device's basic DM parameters.
Thus, drawbacks with this solution is that the ADD function will not detect any change of IMSI/IMEI and the DM system must also be preconfigured with basic data, so that these are already in place when the device attempts to set up its first DM session.
This means that when using smartcard initiated bootstrap, it is not possible to automatically detect a new device/smartcard combination and then securely configure relevant services in the device through OMA DM.
Thus, there is a need for a new method and apparatus for secure bootstrap of the device by combining Bootstrap through smartcard and the 3GPP ADD function, which obviates at least some of the disadvantages cited above.
USPTO Backgrounds
USPTO Backgrounds