WO2009000111A1

WO2009000111A1 - Method for authenticating two entities, corresponding electronic device and system

Info

Publication number: WO2009000111A1
Application number: PCT/CN2007/002010
Authority: WO
Inventors: Ganda Wijaya
Original assignee: Axalto Beijing Smart Cards Technology Co Ltd; Gemalto SA
Current assignee: Axalto Beijing Smart Cards Technology Co Ltd; Thales DIS France SA
Priority date: 2007-06-27
Filing date: 2007-06-27
Publication date: 2008-12-31
Anticipated expiration: 2009-12-27

Abstract

The invention relates to a method (20) for authenticating two entities, a first entity (34) sending to a second entity (32) a first message (36) comprising at least one authentication information item, as a first authentication information item, said first authentication information item depending on at least a first nonce value. According to the invention, said second entity sends (38) to said first entity a second message, as a response to said first message, said second message comprising a second nonce value to be used by said first entity to determine another authentication information item, as a second authentication information item. The invention relates also to a corresponding electronic device (12) for authenticating an external device (14) and a system (10) comprising one portable device (14) for authenticating a host device (12) and said host device cooperating with said portable device.

Description

METHOD FOR AUTHENTICATING TWO ENTITIES, CORRESPONDING ELECTRONIC DEVICE AND SYSTEM

Field of the invention:

The invention relates, in a general manner, to a method for authenticating two entities which have to communicate with each other.

The invention also relates to an electronic device for authenticating an external entity,

Moreover, the invention relates to an electronic system comprising one electronic portable device for authenticating a host device cooperating with it,

More particularly, the present invention relates to a method for authenticating two entities, for example when a synchronization protocol for data communication is utilized for communication of data between e.g. a client and a server.

State of the art :

Within the present description, it is preferred to communicate data between a client, as one entity, and a server, as another entity, using a synchronization protocol. By using the synchronization protocol, it renders possible to provide data communication between electronic devices.

With the "SyncML" protocol, a standardized synchronization protocol is provided, which facilitates communication of data between a user device and another device. Such a standard is notably defined by "SyncML Specification" accessible on the site of the "Open Mobile Alliance", at the following Internet address: http ://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html. The SyncML Specification specifies notably an authentication protocol that can be used for both client and server authentication. It is possible for a server to start a synchronization session by sending a notification message from the server to a client. The notification message includes a so-called server digest, as an authentication information item. The digest is generally a result from an encryption algorithm that has been executed by using a nonce value.

Within the present description, the word "nonce" is a single number to be used only once by an entity involved within a communication for one and the same session of communication.

The client has to authenticate the server before launching an exchange of data to be shared by the client and the server. To do this, the client generates a client digest by executing the encryption algorithm by using a client nonce value.

When the client receives the server digest, the client compares the server digest with the client digest. If the client digest and the server digest are different due to the fact that the nonce values are different, then the authentication fails on the client side. Since the authentication has failed, the client does not launch any synchronization session.

A major disadvantage of the SyncML authentication protocol just described hereinabove is that, in such a case, the exchange of data between the client, as one entity, and the server, as another entity, is stopped.

Summary of the invention :

The invention eliminates such a major disadvantage by providing a method for authenticating two entities that have to exchange data. According to the invention, an entity that receives, within a message, another entity digest based on an originator nonce value, sends back to the originator, another message that includes a recipient nonce value to be used for authenticating the originator of the first message. More particularly, the invention is a method for authenticating two entities.

A first entity sends to a second entity a first message comprising at least one authentication information item, as a first authentication information item. The first authentication information item depends on at least a first nonce value. The second entity sends to the first entity a second message, as a response to the first message. The second message comprises a second nonce value to be used by the first entity to determine another authentication information item, as a second authentication information item.

The principle of the invention is, therefore, that a recipient of the first message sends to its originator another message indicating a recipient nonce value to be used to execute an authentication algorithm.

It is to be noted that the recipient of the first message may play any role and be either a client or a server. Likewise, the originator of the first message may be respectively either a server or a client.

In such a manner, the two entities will use one and the same nonce value, the one provided by the recipient of the first message, to calculate an authentication result on both sides. Consequently, the authentication results obtained on both sides are identical and allow to continue the communication between the two involved entities, since the authentication is successful. For instance, the two entities are then permitted to launch a synchronization session.

According to another aspect, the invention is an electronic device for authenticating another external device. The device comprises communication and processing means. The device comprises means for receiving a first message that includes at least one authentication information item, as a first authentication information item. The first authentication information item depends on at least a first nonce value. According to the invention, the communication and processing means of the device are configured to send to the external device, as a response to the first message, a second message that comprises a second nonce value to be used by the external device to determine another authentication information item, as a second authentication information item. As electronic device, it can be a user device like, for example, a mobile telephone, a PDA (acronym for Personal Digital Assistant), a personal computer, or a mobile laptop. According to a further aspect, the invention is a system comprising one portable device for authenticating a host device. The host device cooperates with the portable device. The host device comprises a communication interface for communicating with the portable device. The host device comprises communication and processing means. The host device comprises means for receiving from the portable device a first message which comprises at least one authentication information item, as a first authentication information item. The first authentication information item depends on at least a first nonce value.

According to the invention, the communication and processing means of the host device are configured to send to the portable device a second message, as a response to the first message. The second message comprises a second nonce value to be used by the portable device to determine another authentication information item, as a second authentication information item.

As a host device, it can be, for example, a mobile telephone, a PDA, a personal computer, or a mobile laptop.

As a portable device, it can be any electronic device comprising at least a microprocessor and comprising at least one memory or being connected to one memory. The portable electronic device is intended to cooperate with a host device to execute a function on behalf of the host device. For example, it can constitute a token, a dongle of the USB (acronym for "Universal Serial Bus") type, or any other electronic support that may have different forms.

Brief description of the drawings:

Additional features and advantages of the invention will be more clearly understandable after reading a detailed description of one single preferred embodiment, given as an indicative and not limitative example, in conjunction with the following drawings:

- Figure 1 illustrates a simplified diagram of an embodiment of an electronic system comprising a mobile phone and a SIM card and being adapted to provide authentication according to the invention; - Figure 2 is a flow chart of an exemplifying method for authenticating two entities comprised within the system of figure 1 ; and

- Figure 3 illustrates a message flow between a client and a server, as the two entities implementing the method for authenticating of figure 2.

Detailed description of one embodiment:

Herein under is considered a case in which the invention method for authenticating two entities, when data have to be exchanged between a client, such as an electronic user device, and a server when a standardized synchronization protocol is used. However, it is only for exemplifying purposes and is not considered to reduce the scope of the present invention.

Figure 1 shows an electronic system 10 comprising a mobile telephone 12, as the electronic user apparatus, and a SIM (acronym for "Subscribed Identity Module") card 14 or the like, as a local server.

The SIM card 14 is inserted within the mobile telephone 12. The SIM card

14 includes a microprocessor and volatile and non volatile memories (not shown). The microprocessor controls and communicates with all the components of the SIM card 14, such as the memories to read them and possibly write into them.

The SIM card 14 communicates with the mobile phone 12 via a bidirectional way 13 through a contact interface (not shown) of the type ISO 7816 (for « International Standard Organization »).

The mobile telephone 12 has also a contact interface of the type ISO 7816 to cooperate with the SIM card 14. The mobile phone 12 has an antenna 11 to communicate over the air 15 through a telecommunication network 16 to a distant server 17.

The telecommunication network 16 is adapted to implement a 2G

(acronym for a second generation network, i.e. GSM for "Global System for Mobile communications") mode, 3G (acronym for a third generation network, i.e.

UMTS for "Universal Mobile Telephone System") mode and/or CDMA (acronym for a "Code Division Multiple Access"). Other distant servers (not shown) can be accessible through other links.

For instance, a server within a PC is accessible from the phone through a short range radiofrequency link, like Bluetooth, or a server within another mobile phone through an infrared interface. The mobile phone 12 includes a microprocessor and volatile and non volatile memories (not shown).

A user accesses to the mobile telephone 12 through a man machine interface, in order to be able to exploit, at least in part, one or several services accessible from the SIM card 14 through the mobile telephone 12. The user may interact with the man machine interface and operate the mobile phone 12.

The man machine interface comprises a display 18, a keypad 19, a loudspeaker

1 10 and a microphone 1 1 1.

The mobile phone 12 is adapted to communicate data to the SIM card 14, as a local server, and to the distant server 17, by using the standardized synchronization protocol such as "SyncML".

The data thus exchanged provide interoperable service enablers working across countries, operators and mobile terminals. Data that may be concerned may be of any type, and notably including phone book, contacts, emails and agenda. The mobile phone 12 and the SIM card 14 provide both an authentication function. To perform such an authentication, both client and server are adapted to implement a single authentication algorithm known as MD5 (acronym for

"Message-Digest algorithm 5"). The authentication algorithm has, as input, an own nonce, as one parameter, to calculate one corresponding digest. The digest is, as known per se, an encrypted data constituted by the result of a hash of the user name, his password and the nonce. The encrypted data includes 16 bytes of hexadecimal data.

The nonce is a pseudo-random, or the like, to be used only once by the entity that implements the invention method for authenticating the correspondent entity before exchanging data within a single communication session. initially, by any means, the SIM card 14 should share the same nonce value with the mobile phone 12. For example, a distant server (not shown) that is controlled by an operator provides, through the telecommunication network, on the one hand, the SIM card 14 with a nonce value, and on the other hand, the mobile phone 12 with a nonce value. According to another example, the SIM card 14 and the mobile phone 12 are configured through a Device Management, as known per se.

However, when the authentication algorithm of the SIM card 14 has a SIM card nonce value, as a first nonce value, and the authentication of the mobile phone 12 has the mobile phone nonce value, as a second nonce value, different from the first nonce value, then a further exchange of data between the mobile phone 12 and the SIM card 14 may be stopped.

It is to be recalled that, according the prior art, after having received the notification message, when the nonce values and the digests thus generated are different, no acknowledgement and no response is sent from the mobile phone 12, as client, to the SIM card 14, as local server.

A success of the authentication is possible where the nonce values originating from both sides do match.

According to the invention, the microprocessor of the mobile phone 12 is configured to generate and provide the SIM card 14 with the mobile phone nonce value. The mobile phone 12 and the SIM card 14 share one and the same nonce value, namely the mobile phone nonce value, which is to be used by MD5. Therefore, MD5 issues then one and the same result, the mobile phone digest, allowing thus the involved entities to successfully pass the authentication.

Advantageously, the microprocessor of the mobile phone 12 is configured to generate and provide the SIM card 14 with a status code. The status code has a value indicating that an error has occurred and the nature of the error obtained on the mobile phone side. For example, the mobile phone 12 is busy or the mobile phone 12 does not understand the notification message, and, in particular, the SIM card digest based on the SIM card nonce value or that the user of the mobile phone 12 rejects the SIM card digest, and therefore, the SIIVl card nonce value, or that the mobile phone 12 has failed to generate a mobile phone digest based on the mobile phone nonce value.

According to another embodiment, another entity, like, for example a server (not shown) accessible from the mobile phone 12 through the telecommunication network 16, generates the mobile phone nonce value and provides the mobile phone 12 through the telecommunication network 16 with the mobile phone nonce value. In such a case, the microprocessor of the mobile phone 12 is configured to receive from the identified external entity any mobile phone nonce value to be used. Such a server is preferably dedicated to the generation of mobile phones' nonce values for mobile phones that are managed and controlled by one operator. This server is directly or indirectly controlled by the operator.

Such exchange of data allow to update data related to programs, and/or to applications supported by the SIM card 14, and/or to parameters for configuring the SIM card 14, and/or to a content to be stored within the SIM card 14.

Figure 2 shows an exemplary embodiment of the invention method 20 for client authentication before exchanging data between a client, such as the mobile phone 12, and a local server, such as the SIM card 14. The invention method 20 includes different steps that are further described in an exemplary embodiment without limiting the scope of the invention.

Firstly, by any means, the mobile phone has 22 a mobile phone nonce value, and based on the mobile phone nonce value, generates a corresponding mobile phone digest by using MD5. Then, the mobile phone receives 24 from the SIM card an initialization or notification message, in order to establish a connection between the mobile phone and the local server. The notification message contains different information items, among which there is an authentication information item constituted by one SIM card digest. The SIM card digest has been calculated by using three parameters, namely a username, a corresponding password, and a SIM card nonce. The SIM card has previously generated a SIM card nonce value. Once the mobile phone has received the SIM card digest, the mobile phone verifies 26 that, for example, whether the SIM card digest and the mobile phone digest do match.

In the negative, i.e. the SIM card digest and the mobile phone digest are 5 distinct, then the mobile phone has failed to generate the SIM card digest due to the used nonce value, namely the SIM card nonce value is therefore different from the mobile phone nonce value.

The mobile phone nonce value should have been equal to the SIM card nonce value further to a mobile phone initialization. Such a mobile phone 10 initialization results from a bootstrap, a manual input, or a message originating from the SIM card, or the like. The mobile phone nonce value has been lost due, for example, to the erasure of a mobile phone memory that stores the mobile phone nonce value, or the like.

According to a variant, instead of an error relating to a failure of identity of 15 the generated digests, another error is that the mobile phone is busy, for instance, the phone book of the mobile phone is being modified by its user. According to another variant, the error is that the mobile phone does not understand the notification message, or the mobile phone user rejects the notification message due, for example, to a roaming.

20. According to the invention, the mobile phone, as client, sends 28 to the

SIM card, as local server, in response to the notification message, the mobile phone nonce value.

Preferably, the mobile phone nonce value is encrypted. The SIM card receives the mobile phone nonce value. Thus, the SIM card 25 knows that it has to use the received mobile phone nonce value to generate a corresponding authentication result.

The SIM card implements the MD5 with the mobile phone nonce value and generates 210 a corresponding digest, the mobile phone digest. The mobile phone digest is therefore also obtained on the SIM card side.

30 The SIM card and the mobile phone share one and the same digest, namely the mobile phone's one based on the mobile phone nonce value. The SIM card sends 212 to the mobile phone another notification message, as second notification message, including another digest. Such a digest is equal to the mobile phone digest, since it is calculated by using the mobile phone nonce value. The mobile phone receives the latter notification message.

Then, the SIM card and the mobile phone successfully pass the authentication.

A synchronization process between the authenticated mobile phone and SIM card may be initialized. To perform such a synchronization initialization, the mobile phone sends to the SIM card a message, in order to indicate that the mobile phone has authenticated the SIM card.

Figure 3 shows a message flow 30 between the mobile phone, as client 32, and the SIM card, as local server 34.

The message flow 30 is the one relating to the situation where the client authenticates the server using a MD5 authentication process. In such a situation, the server challenges the client.

A similar message flow is obtained when the client challenges the server i.e. the roles of the server and the client are reversed. In other words, when the originator of the messages described herein under in relation with the situation where the server challenges the client, is the server or the client, the originator respectively becomes the client or the server. In such a situation, the server authenticates the client.

The server 34 sends to the client 32 a first message constituted by a notification message 36. The entity which sends the notification message 36 challenges the recipient.

The notification message 36 comprises notably a notification package and a server digest calculated notably from a server nonce value. The notification package contains data for identifying the server 34.

After the receiving of the first message, the client 32 compares the server digest and the client digest. When the client digest and the server digest are different, the client 32 sends to the server 34 a response message 38. The response message 38 includes a status code and/or a client nonce value. The status code indicates an error type, whereas the client nonce value is to be used in order to authenticate the client.

Optionally, before sending the response message 38, the client may previously ask for a user confirmation. If the client user does not agree to send the response message 38, then the client shall not send the response message 38 to the server. Accordingly, the synchronization session shall not start.

Conversely, if the client user does agree, then the client 32 sends to the server 34 the response message 38 through a predetermined communication way. The server 34 receives then the client nonce value. The server 34 must then use the client nonce value to calculate another server digest by implementing MD5.

Since the client 32 and the server 34 have the same inputs, as parameters, the calculation on both sides allows to generate a common authentication result, namely the client digest.

According to a variant, instead of having one response message comprising both parameters, namely the status code and the client nonce value, one dedicated separated message is used for each of the two parameters. For instance, the client 32 sends to the server 34, on the one hand, a first response message including the sole status code, and on the other hand, a second response message including the sole client nonce value.

Then, the server 34 sends 310 to the client 32 a new notification message with the right digest based on the right nonce value, namely the client nonce value. It is to be noted that the server 34 may not send any new notification message including a digest when the status code indicates that the client user rejects to start the synchronization session.

The client 32 receives the latter notification message and detects the identity of the digests. Due to the identity of the authentication calculation results on both sides, the authentication successfully passes.

Then, the synchronization session is allowed to be launched. To do this, either the client 32 or the server 34 sends to the other entity a corresponding message accompanied with a data to be shared between the client and the server.

Claims

1. A method (20) for authenticating two entities, a first entity (34) sending to a second entity (32) a first message (36) comprising at least one authentication information item, as a first authentication information item, said first authentication information item depending on at least a first nonce value, characterized in that said second entity sends (38) to said first entity a second message, as a response to said first message, said second message comprising a second nonce value to be used by said first entity to determine another authentication information item, as a second authentication information item.

2. Method according to claim 1 , wherein said second nonce value is different from said first nonce value.

3. Method according to claim 1 or 2, wherein said second nonce value is provided by said second entity.

4. Method according to claim 3, wherein said second entity generates said second nonce value.

5. Method according to claim 3, wherein said second entity is connected to a third entity, said third entity generating said second nonce value, said third entity sending to said second entity said second nonce value.

6. Method according to any of claims 1 to 5, wherein said second message further comprises a status code, said status code indicating a status of said second entity with respect to said first authentication information item and/or a current activity of said second entity.

7. Method according to claim 6, wherein said status code comprises at least one of the following status indicating that said second entity: - is busy; - does not understand said first message;

- rejects said first authentication information item;

- has failed to generate said first authentication information item.

8. Method according to any of claims 1 to 7, wherein said first entity is a server and said second entity is a client.

9. Method according to any of claims 1 to 8, wherein said first and second entities are suitable to implement one and the same authentication algorithm, an implementation of said authentication algorithm generating a second authentication information item based on said second nonce value.

10.An electronic device (12) for authenticating an external device (14), said device comprising communication and processing means, said device comprising means for receiving a first message comprising at least one authentication information item, as a first authentication information item, said first authentication information item depending on at least a first nonce value, characterized in that said communication and processing means are configured to send to said external device a second message, as a response to said first message, said second message comprising a second nonce value to be used by said external device to determine another authentication information item, as a second authentication information item.

11. Device according to claim 10, wherein said second nonce value is different from said first nonce value.

12. Device according to claim 10 or 11 , wherein said communication and processing means are configured to provide said second nonce value.

13. Device according to claim 12, wherein said communication and processing means are configured to generate said second nonce value.

14. Device according to claim 12, wherein said communication and processing means are configured to receive said second nonce value.

15. Device according to any of claims 10 to 14, wherein said communication and processing means are configured to send within said second message a status code, said status code indicating a status of said device with respect to said first authentication information item and/or a current activity of said device.

16. Device according to claim 15, wherein said status code comprises at least one of the following status indicating that said device:

- is busy;

- does not understand said first message;

- rejects said first authentication information item;

- has failed to generate said first authentication information item.

17. Device according to any of claims 10 to 16, wherein said device is a client.

18. Device according to any of claims 10 to 17, wherein said device is suitable to implement an authentication algorithm, an implementation of said authentication algorithm generating a second authentication information item based on said second nonce value.

19.A system (10) comprising one portable device (14) for authenticating a host device (12) and said host device cooperating with said portable device, said host device comprising a communication interface for communicating with said portable device, said host device comprising communication and processing means, said host device comprising means for receiving from said portable device a first message comprising at least one authentication information item, as a first authentication information item, said first authentication information item depending on at least a first nonce value, characterized in that said communication and processing means are configured to send to said portable device a second message, as a response to said first message, said second message comprising a second nonce value to be used by said portable device to determine another authentication information item, as a second authentication information item.

20. System according to claim 19, wherein said second nonce value is different from said first nonce value.

21. System according to claim 19 or 20, wherein said communication and processing means are configured to provide said second nonce value.

22. System according to claim 20, wherein said communication and processing means are configured to generate said second nonce value.

23. System according to claim 20, wherein said communication and processing means are configured to receive said second nonce value from another external entity.

24. System according to any of claims 19 to 23, wherein said communication and processing means are configured to send within said second message a status code, said status code indicating a status of said portable device with respect to said first authentication information item and/or a current activity of said device.

25. System according to claim 24, wherein said status code comprises at least one of the following status indicating that said device:

- is busy;

- does not understand said first message; - rejects said first authentication information item;

- has failed to generate said first authentication information item.

26. System according to any of claims 19 to 25, wherein said portable device is a server and said host device is a client.

27. System according to any of claims 19 to 25, wherein said portable device and said host device are suitable to implement one and the same authentication algorithm, an implementation of said authentication algorithm generating a second authentication information item based on said second nonce value.

28. System according to any of claims 19 to 25, wherein said host device is a mobile phone (12) and said portable device is a smart card (14).