KR20050103075A - Authentication method based synchronization markup language protocol - Google Patents

Abstract

The present invention relates to an authentication method based on SyncML protocol, and in particular, a user can freely select an authentication algorithm between a client and a server requiring data synchronization, and an object thereof is to enable more reliable two-way authentication than in the related art. The present invention for this purpose is a method for transmitting and receiving a message based on the SyncML protocol between the client and the server, the first step that the client 310 attempts to connect to the server 320 for the synchronization request, the client 310 ) Is connected, the server 320 requests the user ID (ID), and when the client 310 responds to the user ID by the server 320, the server 320 generates a random value and generates the client. A third step of transmitting to the 310; and when the client 310 encodes the random value and responds to the encoded value, the server 320 reads the random value and the password value of the corresponding ID from the database 330. A fourth step of encoding and comparing whether the encoded value and the encoding value from the client 310 match, and if the comparison result is identical, the server 320 determines that the client 310 is successful in authentication. ) And perform a fifth step of proceeding with the data synchronization process.

Description

Authentication method based on the SYNCNIC protocol {AUTHENTICATION METHOD BASED SYNCHRONIZATION MARKUP LANGUAGE PROTOCOL}

The present invention relates to data synchronization technology, and more particularly, to an authentication method based on SyncML protocol.

As the Internet has evolved, personal data manager (PIM) services of personal data assistants (PDAs), portable PCs, mobile phones, etc. can be used for personal tasks such as address book searching, scheduling, and e-mail exchange. In addition, it is being used for the enterprise as a new means of business.

However, the current portable terminal is equipped with a small amount of memory, a small processor due to the limitation of the physical size, the resource is relatively limited compared to the server, the performance is also poor.

Therefore, a user may back up to a reliable server to secure important information of a device including personal address book, schedule, and the like, and may exchange information existing in different devices with each other. By the exchange of information, the same information of an individual is distributed to various terminals.

In this case, data synchronization is required. This means an arbitration operation that reflects the updated contents of the same data items distributed in a plurality of terminals and resolves the version differences between the data to match the most recent values.

 However, in general, synchronization solutions lack compatibility between devices or application services.

In order to solve this problem, Synchronization Markup Language (hereinafter, abbreviated as "SyncML") protocol standard specification has been proposed.

The SyncML synchronization protocol is a standard proposed to ensure the consistency of distributed data.It is used to match data between different devices and application services such as personal information on web portals and personal information on mobile phones or personal information on PCs. Can be used for synchronization.

SyncML synchronizes between a server and a device by sending and receiving a message including data expressed in eXtensible Markup Language (hereinafter, abbreviated as "XML") between the server and the device.

The following describes the data synchronization process between the client and server supporting SyncML.

Step 1: The client connects to the server, which encodes its ID and password and sends the encoded data to the server for authentication. The message including the encoded data is illustrated in FIG. 1.

Accordingly, the server checks the data transmitted from the client and if the authentication is successful, the server performs the following process.

Step 2: The server authenticates the client, and encodes the ID and password of the server as in the first step, or compresses the ID and password using an algorithm such as MD5, and then encodes and writes the client to the client as illustrated in FIG. Send a message.

Step 3: If the client checks the authentication data sent from the server and the authentication succeeds, if the mutual authentication succeeds, proceed to the next step.

Step 4: Perform a bidirectional or unidirectional data synchronization procedure for the changed data between the client and server.

However, the authentication protocol used in the conventional SyncML standard is a general challenge-response protocol and is known to be vulnerable to security of user authentication.

Therefore, in most cases, to supplement the authentication protocol, a third authentication server may be separately installed or a public key encryption method using a certificate may be used.

Accordingly, the present invention provides an authentication method based on SyncML protocol, which is designed to allow a user to freely select an authentication algorithm between a client and a server requiring data synchronization in order to improve a conventional problem, and to enable more reliable two-way authentication than the conventional method. The purpose is to provide.

The present invention provides a method for transmitting and receiving a SyncML protocol-based message between a client and a server in order to achieve the above object, comprising the steps of: a client connecting to a server for a synchronization request; ID), when the client answers the user ID to the server, the server generates a random value and sends it to the client, and when the server encodes the random value and responds to the encoding value from the client, the server does this. Analyzing and comparing whether the response value of the client is a legitimate value, and if the response value is determined to be a legitimate value, the server notifies the client of the authentication success and proceeds with a data synchronization process.

The message transmission between the client and the server is characterized in that it is based on the Extensible Authentication Protocol.

The response value is characterized in that the "random value + password" is encoded by the MD5 algorithm.

The comparing of the response values may include obtaining a random value and a password value of the corresponding ID from a database, encoding the obtained value by an MD5 algorithm, comparing the encoded value with the response value, and If the comparison result is matched, it is characterized in that the process of determining that the authentication success.

Hereinafter, the present invention will be described in detail with reference to the drawings.

The present invention implements SyncML Document Type Definition (hereinafter referred to as "DTD") by applying Extensible Authentication Protocol (hereinafter, abbreviated as "EAP") defined in IETF RFC2284 to SyncML authentication protocol.

The present invention further defines a new SyncML schema for an extended authentication method in which a user can arbitrarily select and determine an authentication algorithm, thereby creating an XML DTD as shown in FIG.

That is, the present invention adds the <EAP> element and its subordinate schema to apply the extended authentication protocol.

There must be <Code> and <Identifier> in <EAP>, and <EAPData> is included in some cases. The case where <EAPdata> is not required may include authentication success or authentication failure information.

<Code> may have information such as Request, Response, Success, Fail, etc., and <Identifier> serves as a unique identifier for identifying an EAP message.

<EAPData> mainly contains authentication information, and includes another schema (DataKind, Data) inside.

DataKind indicates the type of EAP message and has one of Identity, Notification, Nak, MD5Chal, One Time Password (OTP), TokenCard, and Transport Layer Security (TLS).

For example, if "<DataKind> Identity <DataKind>" is entered, this means a request or response to an Identity. If the response is to a request, then there should be a message such as "<Identity> Hong <Identity>". do.

In addition, Notification is an element indicating a notice to notify the other party, Nak means not to respond, MD5Chal is a case of requesting or responding to a challenge using the MD5 algorithm, and OTP uses a One Time Password algorithm. TokenCard is an element used when using something like a token, including a smart card.

3 is a signal flow diagram illustrating an authentication process according to an embodiment of the present invention. As shown in FIG. 3, the first step in which the client 310 attempts to connect to the server 320 for a synchronization request, and the client 310 When connected, the server 320 requests the user ID (ID), and when the client 310 responds to the user ID by the server 320, the server 320 generates a random random value to generate the client 310. A third step of transmitting the random value and if the client 310 encodes the random value and responds to the encoded value, the server 320 reads the random value and the password value of the corresponding ID from the database 330 and encodes the random value. A fourth step of comparing the encoded value with the encoding value from the client 310, and if the comparison result is identical, the server 320 notifies the client 310 of the successful authentication and synchronizes the data. It is configured to perform a fifth step of proceeding.

When described in detail with reference to Figures 4 to 9 the operation and effect of the embodiment of the present invention configured as described above.

First, client 310 attempts to connect to server 320 by TCP / IP to request synchronization.

Accordingly, when the client 310 is connected, the server 320 transmits a message (EAP-Request / Identity) requesting an ID of the user to the client 320.

The identity request message (EAP-Request / Identity) is prepared as shown in the example of FIG. In FIG. 5, the message in the <EAP> element is a message part for performing authentication, <Code> represents Request, Identifier is "1", the required authentication message type in <EAPData> is Identity, and <Data> is Means information that appears to the other party.

Thereafter, the client 310 interprets the request message received from the server 320 and generates a response message (EAP-Response / Identity) accordingly. That is, after recognizing the use of the extended authentication protocol from the <EAP> element, the client 310 confirms that the authentication message requires an identity through <Code> and <DataKind> and responds to the corresponding response message (EAP-Response / Identity). )

Accordingly, the client 310 transmits a response message (EAP-Response / Identity) including its ID to the server 320.

The response message (EAP-Response / Identity) is shown in FIG. 6. In FIG. 6, "<Code> Response <Code>" indicating a response inside <EAP>, "<DataKind> Identity <DataKind>" indicating that identity information is included, and "<Identity> indicating an ID of an actual client. Hong <Identity> ".

At this time, the server 320 interprets the response message (EAP-Response / Identity) of the client 310 and confirms that it is the response of the client 310 from "<Code> Response </ Code>" and "<DataKind> Identity < / DataKind> "," <Identity> Hong </ Identity> "confirms that the client with ID" Hong "is waiting for authentication.

Thereafter, the server 320 transmits a challenge message (EAP-Request / challenge) to the client 310 to confirm whether the client 310 is actually “Hong,” and performs an actual authentication process. This will be described on the assumption that the MD5 algorithm is used.

First, the server 320 generates a random value and transmits a challenge message (EAP-Request / challenge) including the value to the client 310.

The challenge message (EAP-Request / challenge) is encoded using an MD5 algorithm with a predetermined value (password, etc.) inside a &quot; <MD5Chal> ... <MD5Chal> &quot; Message that requests the client 310 to reply with the encoded value.

"<DataKind> ... </ DataKind>" representing the type of EAP message in the challenge message (EAP-Request / challenge) is "<DataKind> OTP </ DataKind>", "<DataKind> TokenCard </ DataKind> "," <DataKind> TLS </ DataKind> ", and so on.

At this time, the client 310 has a corresponding MD5 algorithm and an internal value of one of "<OTP> .. </ OTP>", "<TokenCard> .. </ TokenCard>", and "<TLS> .. <TLS>". Encode by to prepare the response. That is, the client 310 receiving the challenge message (EAP-Request / challenge) is randomly specified in the MD5 algorithm specified in "<DataKind> MD5Chal </ DataKind>" and in "<MD5Chal> 90384029304802039480230 </ MD5Chal>". "MD5 (random value + password + alpha)" encoding by value calculates the value to respond.

The value calculated by the MD5 algorithm is always a fixed value of 128 bits and is an irreversible function whose input value is unknown by the output value. Therefore, even if the output value is known to others, it cannot be inferred from the password, so it is used as data for authentication.

Accordingly, the client 310 generates a response message (EAP-Response / Credentials) including the question content (password) and the value calculated by the MD5 algorithm, and transmits the response message to the server 320. The response message (EAP-Response / Credentials) is shown in FIG. 8 and includes a response value for the challenge in &quot; <MD5Chal> ... </ MD5Chal> &quot;.

At this time, after receiving the response message from the client 310, the server 320 reads the challenge value transmitted from the database 330 and the password value of the corresponding IP, encodes the encoded value by the MD5 algorithm, and encodes the encoded value. Compare with the response value included in the response message.

Accordingly, the server 320 transmits an authentication success or failure message to the client 310 according to the comparison result.

That is, when the comparison result is determined to be a correct user, the server 320 notifies the client 310 of the success of authentication, and grants access to the client 310 for data synchronization. If the authentication is successful, the message transmitted to the client 310 by the server 320 is the same as the example of FIG. 9, and indicates the authentication success by "<Code> Success </ Code>" in <EAP>. At this time, the <EAPData> element is not necessary.

If the authentication is successful in the above, the synchronization process follows the general SyncML synchronization protocol.

As described in detail above, the present invention provides a framework capable of authenticating using a certificate base such as TLS (Transport Layer Security) by adding a schema for extended authentication to a protocol for data synchronization using SyncML ( Frame Work).

Accordingly, the present invention has an effect of improving the reliability of authentication by providing a service provider to be able to freely select a variety of authentication methods and by allowing the user to select and use a desired authentication method.

1 is an exemplary diagram of an authentication message sent from a conventional client to a server.

2 is an exemplary diagram of an authentication message transmitted from a conventional server to a client.

3 is a signal flow diagram illustrating an authentication process in an embodiment of the present invention.

4 is a view showing the structure of an authentication message in an embodiment of the present invention.

5 is an exemplary diagram of a message for requesting a user ID in FIG.

6 is an exemplary diagram of a message for a user ID response in FIG.

7 is an exemplary diagram of a message for requesting an authentication value in FIG.

8 is an exemplary view of a message for an authentication value response in FIG.

9 is an exemplary view of a message according to the authentication result in FIG.

Explanation of symbols on the main parts of the drawings

310: Client 320: Server

330: database

Claims (9)

In the method of transmitting and receiving a message based on SyncML protocol between the client and the server, The client connecting to the server for the synchronization request, When the client is connected, the server requests a user ID. When the client responds to the user ID to the server, the server generates a random random value and sends it to the client, If the server encodes a random value from the client, the server interprets it and compares the client's response with a valid value; If the response value is confirmed as a legitimate value, the authentication method based on SyncML protocol, characterized in that the server is configured to notify the client of the authentication success and proceed with the data synchronization process. The method of claim 1, wherein the message transfer between the client and server is Authentication method based on SyncML protocol, characterized in that it is based on EAP (Extensible Authentication Protocol). The method of claim 2, wherein the transmission message SyncML protocol-based authentication method comprising <EAP> schema to apply extended authentication protocol to general SyncML schema. 4. The schema of claim 3 wherein the <EAP> schema is <Code> including Request for response request, Response indicating response to request, Success indicating authentication success, Fail indicating authentication failure, <Identifier> for identifying EAP message, Authentication method based on SyncML protocol, characterized in that it is SyncML schema including <EAP> schema consisting of <EAPdata> including authentication related information. The method of claim 4, wherein <EAPdata> is SyncML protocol-based authentication method characterized in that the data that can be removed if it includes information indicating the authentication success (Success) or authentication failure (Fail) in the message. The method of claim 4, wherein <EAPdata> is SyncML protocol based authentication method comprising a DataKind indicating the type of EAP message. The method of claim 6, wherein DataKind is Authentication method based on SyncML protocol, characterized in that configured to have one of Identity, Notification, Nak, MD4Chal, OTP, TokenCard, and TLS. Herein, an element indicating an identity request or a response, a notification indicating an element to be notified to a counterpart, a Nak indicating an element not to respond, an MD5Chal indicating an challenge request or response using an MD5 algorithm, and an OTP An element representing a request or response when the One Time Password algorithm is used, a TokenCard is an element representing a case of using a token, including a smart card, and a TPS is an element representing a certificate base of a transport layer security. The authentication method according to claim 1, wherein the response value is a value obtained by encoding a random value and a password by an MD5 algorithm. The method of claim 1, wherein comparing the response values Obtaining a random value and a password value of the corresponding ID from a database; Summing the obtained values and encoding by MD5 algorithm; Comparing the encoded value with the response value, and The authentication method based on SyncML protocol, characterized in that if the comparison result is determined that the authentication success.