WO2005051018A1

WO2005051018A1 - Smart card lock for mobile communication

Info

Publication number: WO2005051018A1
Application number: PCT/EP2004/052660
Authority: WO
Inventors: Philippe Boumard
Original assignee: Gemplus
Priority date: 2003-10-28
Filing date: 2004-10-26
Publication date: 2005-06-02

Abstract

The present invention provides a method against fraudulous use of an access to a network service in a wireless system, whereby a smart card may be locked by default and may be unlocked by an authentication application, thereby allowing access to the network service. The card containing a user mobile identity of the present invention is provided with an application for locking the card by default and authenticating a target handset, thereafter unlocking the card, thereby allowing an access to a network service in a wireless system using this target handset.

Description

TITLE OF THE INVENTION Smart card lock for mobile communication

FIELD OF THE INVENTION

[0001] The present invention relates to wireless smart card technology. More specifically, the present invention is concerned with a smart card lock method and a smart card endowed with such lock method.

BACKGROUND OF THE INVENTION

[0002] Since 1990, when SIM (subscriber identity module) cards were introduced into the GSM standard (Global System for Mobile Communications), a number of applications in the field of wireless technology, have been developed, which rely on a specific handset firmware or on a specific version of a standard. SIM is a smart card for GSM systems holding a subscriber's ID number, security information and memory for a personal directory of numbers thus allowing him to call from any GSM device.

[0003] Some of these applications may be very sensitive, including for example handset based prepaid applications. Prepaid subscriptions may be one of he most important growth areas for network operators in the majority of existing and developing markets.

[0004] People using the GSM standard for mobile phones use smart card technology, whereby a smart card is inserted or integrated into a mobile handset. The card stores personal subscriber information and preferences that can be PIN code protected and transported from phone to phone. Wireless providers benefit from reduced fraud thanks to the security offered by smart cards. With the advent of mobile services such as mobile commerce, web browsing, and information services, wireless providers rely on smart cards to act as the security mechanism to protect those services. As a result, smart cards are beginning to move beyond GSM to secure mobile services for other wireless standards as well.

[0005] CDMA (Code Division Multiple Access) is now one of the most important mobile networks in the world. CDMA is a North American standard and compatible with other cellular analogue networks for "roaming". The CDMA community has created a standard that harnesses the power of smart cards for CDMA-based networks. The R-UIM (Removable User Identity Module) offers CDMA operators the advantages previously enjoyed by GSM operators using SIM card technology.

[0006] Registration to the network is a process generally independent from applications and required in every standard, and done by the handset using data provided by the smart card.

[0007] In the GSM world, the capacity to switch a SIM from one handset to another handset allows that a receiver/transmitter is not linked to the actual subscriber. However, in the case of a prepaid handset, such mobility may prove to be a problem. For example, removal of the SIM of a subscriber X and insertion of this SIM in handset of a subscriber Y may allow the subscriber X to use units paid by the subscriber Y, exactly as if the subscriber X was using the subscriber Y's phone before the SIM switch. Another problem may arise when a SIM, USIM or U-RUIM card is inserted in a handset supporting a given required technology but not a given required application (which may be a specific handset firmware or a specific version of a standard, as mentioned hereinabove): in that case, connection to the network is enabled but the application does not operate or operates unproperly. In a case of a prepaid subscription for example, prepaid units may thus not be decremented. In the case of a prepaid full SIM, this may result in the SIM not receiving all the necessary data to be able to assess the length and cost of a call for example.

[0008] Therefore, there is a need in the art for a protection method and smart card to mitigate the above-mentioned problems.

OBJECTS OF THE INVENTION

[0009] An object of the present invention is therefore to provide an improved lock method and smart card.

SUMMARY OF THE INVENTION

[0010] More specifically, in accordance with the present invention, there is provided a method for locking a card containing a user mobile identity comprising the steps of setting the card in a lock mode; authenticating an handset; and resetting the lock mode, whereby the card is protected against fraudulous access to a network service in a wireless system.

[0011] Furthermore, the present invention provides a method for locking a card containing a user mobile identity in relation to a handset comprising encrypting a network authentication command result between the smart card and the handset.

[0012] The present invention also provides a method for locking a smart card containing a user mobile identity in relation to a given handset comprising a protection of the smart card against fraudulous access to a network service in a wireless system selected in the group comprising authenticating the handset after the smart card in set a lock mode prior to resetting the lock mode; encrypting a network authentication command result between the smart card and the handset; and a combination thereof.

[0013] The present invention further provides a smart card containing a user mobile identity, which is provided with an application for locking said card authenticating a target handset, thereby unlocking the smart card and allowing an access to a network service in a wireless system using this target handset.

[0014] Other objects, advantages and features of the present invention will become more apparent upon reading of the following non- restrictive description of embodiments thereof, given by way of example only with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In the appended drawings:

[0016] Figure 1 is a flowchart of a method according a first embodiment of the present invention;

[0017] Figure 2 is a flowchart of a method according a second embodiment of the present invention;

[0018] Figure 3 is flowchart of a method according an alternative embodiment of the method of Figure 2; and [0019] Figure 4 is flowchart of a method according a third embodiment of the present invention.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0020] Generally stated, the present invention provides a method and a system against a fraudulous access to a network service in a wireless system. A number of embodiments are proposed, which may have various impacts on device architecture, levels of security and associated implementation costs. Obviously, selection of an appropriate embodiment depends on a value of business to protect and shall be assessed on a case by case basis.

[0021] More precisely, the present invention provides that a card containing a user mobile identity, referred to hereinafter as a smart card, be locked by default and may be unlocked by an authentication application, thereby allowing operations on the network.

[0022] According to a first embodiment of the method of the present invention, the method for locking a smart card generally comprises the steps of setting the smart card in a lock mode (step 12); authenticating an handset (14); and resetting the lock mode (step 16) (see Figure 1 ).

[0023] In step 12, the smart card is set in a lock mode at power up, so that it may not be used successfully to register on the wireless network before authentication of the handset according to the authentication performed previously. The lock is implemented during the power up sequence before any APDU (Application Protocol Data Unit) exchange with the card occurs. People in the art refer to APDU as the basic unit of communication with a smart card. [0024] The lock may be set so that files containing data necessary for connection on the network, such as the IMSI/Ki/Loci files of a SIM card for example, may not be read, whereby reading one of these files returns fake values or error status code. An invalidated IMSI file for example prevents GSM operations.

[0025] The lock may also be set so that an authentication command, such as a Run Algo in GSM for example, returns an error status code.

[0026] In step 14, the smart card identifies the handset or a range of handsets or specific handset capacities, during an initialization sequence. The authentication may be implemented with various levels of security and/or service. In any case, the authentication is performed very early during the initialization and before the access to the lock data in particular.

[0027] The authentication may be based on a level of features supported by an API (application program interface) between handset and card allowing using resources of a telephone (screen, keyboard, menu, star of calls, sending and receiving of SMS, etc.), referred to as a toolkit (for example SIM toolkit in GSM, Card Application Toolkit for CDMA, etc.). The authentication may also be based on a specific APDU sent to the card indicating that the handset belongs to a supported family.

[0028] The authentication may further be based on a dynamic process involving the generation of a random by the card and the encryption of this random by the handset.

[0029] Encryption may be based on secret key algorithm, which is a cryptographic system that uses a single key for encrypting and signing data, such as for example data encryption standard (DES), which is the most widely used secret key encryption algorithm, a strengthened version of DES called triple DES (or 3DES), which is commonly used in bank cards, advanced encryption standard (AES). Proprietary algorithm may be also used or public key algorithm, which is a cryptographic system that uses two different keys (public and private) for encrypting and signing data. Depending on the algorithm selected some secret information may have to be stored and used by the handset (key in case of secret key or public key encryption approach for example).

[0030] Alternatively, the authentication may also be based on a unique identifier of the handset or a range of handsets, by saving it or part thereof, on the card when the user first inserts the card into the handset. This identifier may be the IMEI in GSM for example. However, a main concern is that programmable equipment allowing "man in the middle" attacks may be designed by anyone having skills in electronics, in the case of such a static authentication using a standard mechanism, or even in the case of a system based on a dynamic authentication, wherein a dynamical data (cryptogram) is passed to the card using a specific mechanism.

[0031] Finally, the card reset the lock mode (step 16), only if the handset has been authenticated.

[0032] In a second embodiment illustrated in Figures 2 and 3 for example, a secure messaging is provided. In Figure 2, an encryption of the authentication data (SRES in GSM for example) returned by an authentication command, for example an encryption of data returned by the Run Algo is contemplated. Since this returned authentication data is unique to each occurrence of this, authentication command and independent of the random of the network, no replay is possible and the solution is not anymore sensitive to a "man in the middle attack", at least on SIM-handset interface, since communication between the handset and the card is secured at all time in relation also used.

[0033] In a third embodiment, illustrated in Figure 4 for example, a combination of the two above-described alternatives may also be contemplated, whereby, in addition to the lock of the access to a command as described hereinabove, and to limit risks of a fraudulent attack, the smart card lock may be enhanced by having an encryption of data returned by an authentication command, for example an encryption of data returned by a Run Algo.

[0034] Therefore, it appears that the authentication may be limited to a static authentication, whereby the SIM rejects RUN GSM ALGO if it is not preceded by an initial ADPU to exchange the unique identifier of the handset and random, or it may be a dynamic authentication based on the encryption by the handset of the SIM generated random.

[0035] It is to be noted that these embodiments may be designed to minimize impacts on the different standards in order to facilitate acceptance by a number of various carriers of these standards.

[0036] In cases when the handset needs to be replaced, the above described solution of providing a link between the smart card and the handset may prove inconvenient, since the smart card cannot be inserted in any other handset, Therefore, some mechanisms are contemplated to allow occasional situation where the switch is possible. To this end, according to the present invention, a unique code per smart card or even per unlink request may be used, by a diversification on a specific unlink mother key. It is to be noted that since a communication is then required with the smart card while the handset may not be in service (broken phone, or no network for instance, a specific menu is to be created in the service provider application program interfaces between handset and card to handle this specific mechanism. Each code may only be used once so as to prevent replay situation. Consequently, each smart card may be unlinked N times only, wherein N is a number predetermined by the service provider. It is to be noted that each request goes through the service provider's backend system and customer care service, and that an unlocking code is valid only once.

[0037] People in the art will appreciate that the present invention enables advanced SIM/USIM/RUIM or IDEN SIM/USIM/RUIM applications like billing of services from a SIM Card or any applications that require analyzing a subscriber activity and the usage of wireless services for example.

[0038] This invention also enables implementation of similar applications in SIM/USIM/RUIM equipped handsets without the risk of a card being inserted in an handset not supporting the application (a typical use case is prepaid managed by specific GSM/GPRS (general packet radio service) handset and the SIM card is removed and inserted in a non prepaid enabled GSM/GPRS handset).

[0039] People in the art will appreciate that the present lock method may also comprise, alone or in combination with the above-mentioned, alternatives wherein the card has a specific shape that is unique to a range of handset, so that it becomes more difficult to use the card in another handset, since some wiring is required for example, or wherein the card is glued to the handset, so that the card cannot be removed or the contacts thereof accessed. [0040] The present invention may further allow occasional unlocking of the smart card, for example in cases when a handset needs to be changed, as described hereinabove For example, the proprietary authentication may be used to unlock the card so that a standard initialization sequence may take place. Eventually, the card is reconnected to the handset.

[0041] Specific applications of a method according to the present invention will now be described as a way of examples, in the framework of the GSM technology for clarity purpose. People in the art will appreciate that a similar application may be implemented using a different technology.

[0042] The system illustrated in Figure 2 allows a resistance to potential "man in the middle attack", by providing that the card, while not locking itself and always returning the required data, protects itself by encrypting the data required by the handset to register on the network, Consequently, only a predetermined enabled handset may use this protected smart card information.

[0043] This system uses an encryption algorithm embedded in both the handset and the SIM. For instance, a sensitive GSM command is updated to support encryption (Run GSM Algo). The selected algorithm may be a secret algorithm, similar to a redemption code algorithm, or a public algorithm relying on a secret key stored in both the handset and the card.

[0044] More precisely, the output of the command between the card and the handset is encrypted, in such a way that an attack in the middle would only reveals useless encrypted information. Only a more traditional cryptographic attack on the embedded algorithm in the smart card containing the user mobile identity or in the handset may allow decryption of the data. [0045] Based on shared secret keys, standard symmetric algorithms like 3DES or AES for example have proven to provide a strong resistance against attacks. Additionally, they are well adapted to embedded devices like smart cards or handsets since they are very compact and fast, Associated key management is required, but it is now very common in the smart card field.

[0046] A main interest of public key algorithms resides on the key management, since no exchange of secret is required and keys are less exposed. Therefore, they are mainly used for very open systems characterized by an unpredictable and varying number of actors, such as systems of open payment or Internet security for example. They are usually combined with standard symmetric algorithms (3DES) to perform encryption services. However, they require a strong certificate management and processing requirements.

[0047] Proprietary algorithms are usually used in combination with standard algorithms.

[0048] In a solution based on a standard symmetric algorithm for example and illustrated in Figure 2, the network is authenticated by a key Ki in GSM, the service provider is identified by a mother key MK in the card, and a daughter key DK, derived from the MK and a unique handset identifier (such as IMEI in the GSM for example), is calculated and loaded in the handset at manufacturing. A session key SK, unique to a GSM session and based on a random or a counter imposed by the card, is used to limit exposure of DK and MK.

[0049] As illustrated in Figure 4, the secure messaging between the card and the handset makes false authentication requests to access the network fail, in the case when a user tries a switch of a handset for example, as described in relation to the third embodiment hereinabove. In the case when the card is inserted in a non allowed handset, assuming that the authentication application such as the RUN GSM ALGO in GSM is not impacted, the handset does not detect that the cryptogram returned by this authentication application is encrypted and simply forwards it to the network as it is. The network then fails to authenticate the message. An alternative authentication mechanism may be implemented, according to which the card is able to authenticate the allowed handset before returning an authentication cryptogram. An error status is then returned by the card, which then generates a card defect message than authentication failed on the network.

[0050] The mother key MK gives access to all other keys.

Knowledge of the MK might therefore break the overall security of the application. MK resides in the card, at the card personalization center, at the handset personalization center and at the service provider. Typically, the MK is generated by the service provider's security officers and injected in a security module (HSM). This HSM is then integrated in the personalization process of the card and handset, Only the service provider's security officers may regenerate the mother key.

[0051] The MK is usually stored only in secure devices located in controlled environment, such as HSM, or point of sale for example. When a card has to support a handset enabled by the service provider, MK is also stored in all the cards in the field. Even though the level of security of a smart card containing the user mobile identity is usually considered very high, obviously such a procedure creates a greater risk of exposure of the MK over time. [0052] However, given specific environments and other potential weaknesses related to prepaid application program interfaces between handset and card for example, such a solution may prove useful, since the cards are designed to handle secret keys and algorithms. Smart card manufacturers are usually very advanced in designing secure implementation resistant to side channel attacks for example. As a result, storage of MK in the card may not be considered as a major threat.

[0053] Usage of a plurality of mother keys may be a further option to reduce the impact of MK discovery. The smart card may store a plurality of MK's, which might be associated with a given type of handsets only, based on last digits of the unique identifier of the handset or a range of handsets for instance. Knowledge of one MK would limit the impact of an attack to this type of handsets only.

[0054] Daughter keys are keys issued from a diversification process of MK with a unique handset number, thereby allowing a very secure way to identify uniquely one handset. Dk resides in the handset, but it is generated internally by the card and exported by handset personalization HSM.

[0055] A unique Dk may be loaded in each handset. As mentioned hereinabove, a secure implementation may be required at the handset manufacturing level to prevent exposure of the DK in the handset. Indeed, although DK is diversified, an exposure thereof may yield a major risk for the overall application, since a single disclosed DK may be sufficient to arm a "man in the middle attack"-capable device, which might be efficient against any handset enabled by the service provider. Such a device may impersonate the broken handset by using its unique key with any card, thereby allowing decrypting all SRES generated by any card. [0056] A solution to prevent such weakness may comprise linking one card to one given handset, with an encryption method resistant against a "man in the middle attack". For example, providing a dynamic authentication of the handset by the card at the card initialization, the handset may encrypt a random returned by the card and return a resulting cryptogram to the card, The card in turn may verify the cryptogram and enable access to an authentication command, such as RUN GSM ALGO for example command, only after validation thereof. Additionally, the unique identifier of the handset or of a given range of handsets may be stored in the card the first time the card is powered up, so as to provide a reference, allowing the card to reject a handset identified by a different unique identifier at a subsequent power up. Therefore, providing the DK depends on the unique identifier, an exposed DK may not be used in a generic "man in the middle" device. Such a method would prevent a card to be switched from one allowed handset to another.

[0057] A daughter key in the card is generated during the authentication process and is maintained secret by the card. Level of security is high.

[0058] HSM used at the handset personalization center is able to generate a daughter key for any given unique identifier. Therefore, access to the HSM is to be secured and restricted. Additionally, a secure transportation of DK between HSM and a target handset is highly recommended in order to limit DK exposure, as explained hereinbefore.

[0059] Session keys are keys issued from a diversification process of DK with a unique value, i.e. either a counter or a random for example. They ensure a unity of the exchange between the card and the handset, and therefore prevent replay attacks. They are generated at each card initialization. In order to prevent attack on the encryption algorithm itself, the session keys may be associated to a usage counter that may limit the number is SRES computations allowed by the card.

[0060] When using a public key algorithm, there is a limited exposure of the key. A public/private key is not generally used directly to encrypt information but to establish securely an encryption session key such as a 3DES session key. A specific sequence created between SIM and handset allows establishing this session key. As illustrated in Figure 3, in this case, a GSM Ki key is used to authenticate the network, a Pr/Pu private/ public key is used for the handset, the service provider's root private key/root public key RPr/RPu are involved, the RPu being stored in the card. Moreover, a certificate Cert, which is signed with the service provider's root private key RPr, of the public key Pu of the handset is used. The Cert includes the unique identifier of the handset (IMEI in GSM); no expiration date is used since the SIM card has no time capability. Finally, a key session SK is provided, which is a random generated by the card.

[0061] Such a solution may be implemented in a card. PK enabled

SIM card are already available. Some specific ADPU may need to be developed for an initial card / handset exchange. Public key encryption algorithms like RSA computations may slow down the initial handshake by a couple of seconds. This solution may also be technically implemented in the handset. However, impact on architecture needs be assessed, to comply with the support of two different algorithms for example, which may have an impact on the processing capacity of the handset, considering that RSA usually requires a crypto processor in a card for example.

[0062] Since a solution based on a public key relies mainly on the management of the key generation and certification, in closed systems like the one of certain service providers, impact is mainly on the handset manufacturing process.

[0063] The card is used to store the root certificate and root public key. It ensures that this data are not modified. However, since this is public information, it is not protected in reading. A card is well designed for such a usage and may ensure a very high level of protection against data modification. Only public data are managed at the card personalization center, which ensures that the service provider's certificate may not be replaced by another one.

[0064] In the handset, the personalization process needs be updated to support a key pair generation and certification, which may not be seamless since public key management is often time consuming. When done on the fly, key pair generation and certification may impact the production performance. An alternative is to perform key pair generation and certification offline and to establish a database of key and certificate. During the personalization process, the appropriate key pair and certificate are then extracted from this database. The key generation may even be achieved by the service provider and the results exported in a secure file to the handset manufacturer.

[0065] Solution based on proprietary algorithm are usually very complex, especially in cases when there is no control over the means used to attack the system, such as in cases when the algorithm is embedded in the non-controlled handset for example.

[0066] From the foregoing, people in the art should now be in a position to appreciate that the present invention provides a method for locking a smart card in relation to one handset or to a range of handsets efficiently, by making use of cryptographic means (PK or SK for example).

[0067] In particular, the present invention provides a method for locking target files of a card, or for locking a target authentication command, thereby preventing registration.

[0068] The method of the present invention may comprise encrypting the authentication result between a card and an handset, and using a unique identifier of the handset for generating keys, which allows preventing reuse of a daughter key in the fabrication of a fraudulous device in the case a card is locked to one handset, for example. The method of the present invention may further comprise securing the card on a handset in such a way as to prevent an easy access to the contacts.

[0069] Clearly, the present invention applies to any wireless technology that relies on smart cards to store subscriber registration data as well as application. In particular, it applies to GSM, GPRS, CDMA, and iDEN since all these technologies may use a smart card containing the user mobile identity (SIM/USIM/RUIM).

[0070] Interestingly, the present invention provides a card containing the user mobile identity, which is provided with an application for locking the card and authenticating a target handset, thereby unlocking the card and allowing an access to a network service in a wireless system using this target handset. The smart card is set in a lock mode at power up, and the application for authenticating a target handset identifies the target handset during an initialization sequence. Moreover the smart card of the present invention may receive a proprietary APDU indicating that the target handset belongs to a supported family. It may also comprise a unit that generates a random while the target handset is provided with an encryption unit to this random. Alternatively, the smart card may comprise saving means to save at least part of a unique identifier of the target handset when the user first inserts the card into the handset. As explained hereinabove, the smart card may further comprise means for encrypting of data returned by an authentication command between the smart card and the handset and means for encrypting a network authentication command result between the smart card and the handset.

[0100] Although the present invention has been described hereinabove by way of embodiments thereof, it can be modified, without departing from the spirit and nature of the subject invention as defined in the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method for locking a smart card containing a user mobile identity on a given handset comprising the steps of: setting the smart card in a lock mode; authenticating the handset; and resetting the lock mode, whereby the smart card is protected against fraudulous access to a network service in a wireless system.

2. The method according to claim 1 , wherein said step of setting the smart card in a lock mode is performed during a power up sequence of the card.

3. The method according to anyone of claims 1 and 2, wherein said step of setting the smart card in a lock mode comprises providing that target files thereof may not be read, whereby reading one of these files returns fake values or error status code.

4. The method according to anyone of claims 1 and 2, wherein said step of setting the smart card in a lock mode comprises providing that an authentication command returns an error status code.

5. The method according to anyone of claims 1 to 4, wherein said step of authenticating the handset comprises identifying the handset by the card.

6. The method according to claim 5, wherein said step of authenticating the handset is performed during an initialization sequence.

7. The method according to anyone of claims 5 and 6, wherein said step of authenticating the handset comprises using a method selected in the group comprising using features supported by a toolkit, using a unique identifier of the handset, and using a specific APDU sent to the card.

8. The method according to anyone of claims 5 and 6, wherein said step of authenticating the handset comprises using a dynamic authentication process involving a generation of a random by the card and encryption of this random.

9. The method according to claim 8, wherein said encryption comprises using a process selected in the group comprising a secret key process, a proprietary process, a public key process, and a combination thereof.

10. The method according to anyone of claims 1 to 9, further comprising providing a card having a specific shape that is unique to the handset.

11. The method according to anyone of claims 1 to 10, further comprising securing the card on the handset.

12. The method according to anyone of claims 1 to 11 , wherein the given handset includes a given range of handsets.

13. The method according to anyone of claims 1 to 12, further comprising encrypting of data returned by an authentication command between the smart card and the handset.

14. A method for locking a smart card containing a user mobile identity on a handset comprising encrypting a network authentication command result between the smart card and the handset.

15. A method for locking a smart card containing a user mobile identity on a given handset comprising a protection of the smart card against fraudulous access to a network service in a wireless system selected in the group comprising authenticating the handset after the smart card in set a lock mode prior to resetting the lock mode; encrypting a network authentication command result between the smart card and the handset; and a combination thereof.

16. The method according to any of claims 1 to 16, further comprising unlinking the smart card and the handset.

17. A smart card containing a user mobile identity, said smart card being provided with an application for locking the card, authenticating a target handset, thereby unlocking said card and allowing an access to a network service in a wireless system using said target handset.

18. The smart card according to claim 17, said smart card being set in a lock mode at power up, and said application for authenticating a target handset identifies said target handset during an initialization sequence.

19. The smart card according to anyone of claims 17 and 18, wherein said smart card receives a proprietary APDU indicating that said target handset belongs to a supported family.

20. The smart card according to anyone of claims 17 and 18, wherein said smart comprises a unit that generates a random and said target handset is provided with an encryption unit to encrypt the random.

21. The smart card according to anyone of claims 17 and 18, wherein said smart card comprises saving means to save at least part of a unique identifier of said target handset when the user first inserts said card into said handset.

22. The smart card according to anyone of claims 17 to 21 , further comprising means for encrypting of data returned by an authentication command between said smart card and said handset.

23. The smart card according to anyone of claims 17 to 21 , further comprising means for encrypting a network authentication command result between said smart card and said handset.