CN1929475A - 以SyncML协议为基础的认证方法 - Google Patents

Abstract

本发明涉及一种数据同步技术，本发明以SyncML协议为基础的认证方法提供了一种能够让使用者自由的对要求数据同步的客户机与服务器之间的认证运算法则进行选择的双向认证的方法，本发明在客户机与服务器之间接收发送以SyncML协议为基础的信息，并对其进行认证。以SyncML协议为基础的认证方法使得服务提供商能够提供安全而且多样的认证方法，让使用者能够在这些认证方法中自由的选择其所要的一项，从而达到了提高认证可靠性的效果。

Description

以SyncML协议为基础的认证方法

技术领域

本发明涉及一种数据同步技术，特别涉及一种以SyncML协议为基础的认证方法。

背景技术

随着互联网的发展，在PDA(Personal Data Assistant)、笔记本电脑、移动电话等设备中，越来越多的使用了网络服务器的个人信息管理(PIM：Personal Information Manager)服务，名片搜索、日程管理、电子邮件交换等工作已不仅仅为个人所用，也越来越多的运用到了企业中，已经成为了一种新的商务手段。

可是，目前由于受到便携式终端其物理体积大小的限制，所以只能配备小容量的存储器和小型处理器，因此与服务器相比，所能使用的资源就受到了很大的限制，性能也比较低。

因此，使用者为了对个人名片、日程之类的个人信息进行管理，并安全的保管设备的重要信息，就要需要在可靠的服务器上进行文件备份(back-up)，并与存在于其他设备中的信息进行相互交换。通过上述信息交换，个人的同一个信息就能够分散储存到许多终端中。

在这样的情况下，数据同步(data synchronization)就成为了一种必需的技术。它是一种能针对分散储存在多个终端上的同一个数据项目，反映出被更新的内容，解决数据间的版本(version)差异，使得数据总是能与最新值保持一致的调和操作。

但是，通常各种同步解决方法缺乏装置之间或者应用服务之间的互换性。

为了解决这种问题，于是便提出了Synchronization MarkupLanguage(以下简称为“SyncML”)协议标准规格。

SyncML同步协议通过提供一个通用规范来协调客户机与服务器之间的数据交换，它有效利用了可扩展标记语言(XML)，可以使任何网络中的所有设备和应用实现同步化，保证了各个分散的数据始终保持一致，是专为满足人们对无线通信日益增长的需求而设计的。它可以使Web portal的个人信息、移动电话的个人信息或者PC的个人信息等个人资源在互不相同的设备和应用服务之间保持数据同步。

SyncML通过在服务器与客户机收发包含了表现为eXtensibleMarkup Language(可扩展标记语言，以下简称为“XML”)形态的数据信息，从而实现两者之间的同步。

下面对支持SyncML协议的客户机与服务器之间的数据同步过程进行说明。

过程1：客户机与服务器进行连接。客户机对自身的用户名和密码进行编码，将此经过编码的数据提交给服务器，要求其进行认证。包含上述编码数据的信息如图1所示。

然后，服务器对由客户机传送来的数据进行认证，如果认证成功，就可以进行下一过程。

过程2：服务器向客户机发送认证信息。服务器对服务器的用户名、密码进行与第一阶段相同的编码，或者在利用MD5运算法则对用户名、密码进行压缩之后，再执行编码操作，然后如图2的示意图所示，向客户机发送制作完成的信息。

过程3：客户机对从服务器中发送来的认证数据进行确认，在认证成功之后，再执行下一个过程。

过程4：执行针对客户机与服务器之间的改变数据的双向或单项数据同步步骤。

但是，在以往的SyncML标准中所使用的认证协议通常为挑战-响应(challenge-response)协议，这在使用者认证的安全性上存在着不足。

因此，大部分情况下，为了弥补上述认证协议的不足，需要另行设置第3认证服务器，或者需要使用利用认证书进行公开加密。

发明内容

本发明为了解决以往技术所存在的缺点，应运而生。本发明的目的是要提供一种以SyncML协议为基础的认证方法，能够实现让使用者自由的对要求数据同步的客户机(client)与服务器(server)之间的认证运算法则进行选择，并且较以往可靠性更高的双向认证。

为了达到这种目的本发明基于在客户机与服务器之间接收发送以SyncML协议为基础的信息，并对其进行认证的方法包含以下阶段：

第1阶段，客户机310为了同步需要，试图与服务器320进行连接；

第2阶段，在客户机310连接到服务器320之后，服务器320要求客户机310提供使用者的用户名(ID)；

第3阶段，在客户机310向服务器320回应提供了使用者用户名之后，服务器320生成任意的Random值，并将其传送给客户机310；

第4阶段，上述客户机310对上述Random值进行编码，当客户机向服务器320回应了编码(encoding)值之后，服务器320从数据库330开始，对上述Random值和相关用户名的密码值进行读取和编码，然后将此编码值与客户机310所回应的编码值进行比较，确认其是否一致；

第5阶段，如果上述比较的结果为两者一致的话，服务器320就会告知客户机310认证成功，并执行数据同步操作。

上述客户机与服务器之间信息传送是基于ExtensibleAuthentication Protocol得以实现的。

上述响应值是利用MD5运算法则对“Random值+密码”进行编码后所得的值。

上述响应值的比较阶段包含以下阶段：

第1过程，从数据库中获取Random值和相关用户名的密码值；

第2过程，利用MD5运算法则对上述获取的的值进行编码；

第3过程，将上述经过编码的值与响应值进行比较，确认两者是否一致；

第4过程，如果上述比较结果为一致的话，就判定为认证成功。

如上所述，本发明提供了利用SyncML，在用于数据同步的协议中追加了旨在进行可扩展认证的Schema，从而能够根据TLS(TransportLayer Security)认证为基础进行认证的框架(Frame Work)。

因此，本发明使得服务提供商能够提供安全而且多样的认证方法，让使用者能够在这些认证方法中自由的选择其所要的一项，从而达到了提高认证可靠性的效果。

附图说明

图1是从以往的客户机中传送至服务器的认证信息示意图。

图2是从以往的服务器上传送至客户机的认证信息示意图。

图3是在本发明的实施例中显示认证过程的信号流程图。

图4是在本发明的实施例中显示认证信息结构的附图。

图5是图3中用于要求提供使用者用户名的信息示意图。

图6是图3中用于使用者回应用户名的信息示意图。

图7是图3中用于进行认证值请求的信息示意图。

图8是图3中用于进行认证值回应的信息示意图。

图9是图3中根据认证结果所得出信息的示意图。

*附图主要部分符号说明*

310：客户机                   320：服务器

330：数据库

具体实施方式

下面参照附图，对本发明作详细说明。

本发明在SyncML的认证协议中运用了IETF RFC2284中所定义的Extensible Authentication Protocol(以下简称为“EAP”)，并体现了SyncML的Document Type Definition(以下简称为“DTD”)。

本发明将使用者能够任意选择并确定认证运算法则的扩展认证方法作为新的SyncML Schema进行了追加定义，并制成了如图4的示意图所示的XML DTD。

即，本发明追加了<EAP>要素(Element)以及其下位的Schema，以运用可扩展认证协议。

<EAP>内必须具有<Code>、<Identifier>，但是其中是否包含<EAPData>要视具体情况而定。在<EAP>内包含了认证成功(Success)或者认证失败(Fail)信息的情况下，可以不包含上述<EAP data>。

<Code>可以包含Request、Response、Success和Fail等信息，<Identifier>起到了作为能够识别EAP信息的唯一识别符的作用。

<EAP Data>主要包含了与认证有关的信息，在其内部还包含了其他Schema(Data Kind、Data)。

Data Kind用于表示EAP信息的种类，它包括了Identity、Notification、Nak、MD5 Chal、OTP(One Time Password)、TokenCard、TLS(Transport Layer Security)中的其中一个值。

举个例子，如果输入了“<Data Kind>Identity<Data Kind>”，那么Data Kind就表示针对Identity的请求或回应，在针对请求作出回应的情况下，它应该包含“<Identity>Hong<Identity>”信息。

另外，Notification包括了显示将要告知对方的注意事项的要素(Element)；Nak表示不要进行回应；MD5 Chal表示利用MD5运算法则，请求挑战(challenge)或者对挑战(challenge)作出回应的情况；OTP表示使用One Time Password运算法则情况的请求和回应；TokenCard包含了智能卡(Smart Card)，是使用Token时所需的要素(Element)。

图3是在本发明的实施例中显示认证过程的信号流程图。如图所示，本发明包含以下阶段：

第1阶段，客户机310为了同步需要，试图与服务器320进行连接；

第2阶段，在客户机310连接到服务器320之后，服务器320要求客户机310提供使用者的用户名(ID)；

第3阶段，在客户机310向服务器320回应提供了使用者用户名之后，服务器320生成任意的Random值，并将其传送给客户机310；

第4阶段，上述客户机310对上述Random值进行编码，当客户机向服务器320回应了编码值之后，服务器320从数据库330开始，对上述Random值和相关用户名的密码值进行读取和编码，然后将此编码值与客户机310所回应的编码值进行比较，确认其是否一致；

第5阶段，如果上述比较的结果为两者一致的话，服务器320就会告知客户机310认证成功，并执行数据同步操作。

参照图4至图9，对具有上述结构的本发明实施例作详细说明。

首先，客户机310为了同步需要，根据TCP/IP协议，试图与服务器320进行连接。

然后，在客户机310连接到服务器320之后，服务器320将请求客户机提供使用者用户名的信息(EAP-Request/Identity)发送给上述客户机320。

图5显示了上述ID请求信息(EAP-Request/Identity)的生成过程。在图5中，<EAP>要素(Element)内的信息是用于执行认证的信息，<Code>显示出Request，Identifier为“1”，<EAP Data>内的认证信息种类是Identity，<Data>表示向对方显示的信息。

然后，客户机310对服务器320发送来的请求信息进行分析，生成与之对应的响应信息(EAP-Response/Identity)。也就是说，客户机310在从<EAP>要素(Element)中得知了使用扩展认证协议之后，通过<Code>、<Data Kind>对请求Identity的认证信息进行确认，并生成与之对应的响应信息(EAP-Response/Identity)。

然后，客户机310将包含有自身用户名(ID)的响应信息(EAP-Response/Identity)发送给服务器320。

上述响应信息(EAP-Response/Identity)如图6的示意图所示。如图6所示，上述响应信息(EAP-Response/Identity)包括了<EAP>内部显示应答的“<Code>Response<Code>”、显示具有Identity信息的“<Data Kind>Identity<Data Kind>”、显示实际客户机用户名(ID)的“<Identity>Hong<Identity>”等内容。

这时，服务器320对客户机310的响应信息(EAP-Response/Identity)进行分析，并从“<Code>Response</Code>”信息中确认客户机310的应答，然后从“<Data Kind>Identity</DataKind>”、“<Identity>Hong</Identity>”信息中确认用户名为“Hong”的客户机正在等待服务器320接收认证。

然后，服务器320为了确认客户机310的实际用户名为“Hong”，将挑战(challenge)信息(EAP-Request/challenge)发送给上述客户机310，执行实际认证过程。我们假设在使用了MD5运算法则的前提下，对此进行说明。

首先，服务器320生成任意的Random值，并将包含了这个值的挑战(challenge)信息(EAP-Request/challenge)发送给客户机310。

如图7所示，上述挑战(challenge)信息(EAP-Request/challenge)就是请求客户机310对“<MD5 Chal>…<MD5 Chal>”内部的Random值与通过MD5运算法则已经确定了的数值(诸如密码等)一并进行编码，并对此编码的值作出回应的信息。

在上述挑战(challenge)信息(EAP-Request/challenge)中，用于显示EAP信息种类的“<Data Kind>…</Data Kind>”信息可以是“<Data Kind>OTP</Data Kind>”、“<Data Kind>TokenCard</DataKind>”、“<Data Kind>TLS</Data Kind>”之类的信息。

这时，客户机310根据相关的MD5运算法则和“<OTP>..</OTP>”、“<TokenCard>..</TokenCard>”、“<TLS>..</TLS>”中的其中一个内部值进行编码，并准备作出回应。也就是说，接收了挑战(challenge)信息(EAP-Request/challenge)的客户机310根据“<Data Kind>MD5Chal</Data Kind>”内部明示的MD5运算法则和“<MD5Chal>90384029304802039480230</MD5 Chal>”内部明示的Random值，进行“MD5(Random值+密码+alpha)”编码，并计算出所要回应的值。

利用上述MD5运算法则计算得出的值通常为128bit的确定值，是不能根据输出值得知输入值的非交互性函数。因此，即使将输出值告知了他人，也同样不能类推出密码，所以它被用作进行认证的数据。

然后，客户机310生成包含了被询问的内容(密码)和挑战(challenge)值(利用MD5运算法则计算得出)的响应信息(EAP-Response/Credentials)，并将其发送给服务器320。上述响应信息(EAP-Response/Credentials)如图8的示意图所示，包含了“<MD5Chal>…</MD5 Chal>″内部针对挑战(challenge)的回应值。

这时，服务器320在从客户机310中接收了响应信息之后，从数据库330中，读取自身传送出去的挑战(challenge)值以及相关IP的密码值，然后根据上述MD5运算法则，将其编码，并将此编码值与上述响应信息中所包含的回应值进行比较。

然后，服务器320根据这个比较的结果，向客户机310发送认证成功或认证失败的信息。

也就是说，服务器320在当比较的结果为两者一致时，判定当前用户是正确的使用者，然后便将认证成功的信息发送给客户机310，允许上述客户机310进入系统，执行数据同步操作。在认证成功的情况下，服务器320发送给客户机310的信息如图9的示意图所示，客户机310根据<EAP>内的“<Code>Success</Code>”得知认证成功。这时就不需要<EAP Data>要素(Element)。

如上所述，在认证成功的情况下，同步过程不同于通常的SyncML同步协议。

Claims (9)

1、一种以SyncML协议为基础的认证方法，其特征在于，包含以下阶段：

第1阶段，客户机为了同步需要，试图与服务器进行连接；

第2阶段，在客户机连接到服务器之后，服务器要求客户机提供使用者的用户名；

第3阶段，在客户机向服务器回应提供了使用者用户名之后，服务器生成任意的Random值，并将其传送给客户机；

第4阶段，上述客户机对上述Random值进行编码，当客户机向服务器回应了编码值以后，服务器从数据库开始，对上述Random值和相关用户名的密码值进行读取和编码，然后将此编码值与客户机所回应的编码值进行比较，确认其是否一致；

第5阶段，如果上述比较的结果为两者一致的话，服务器就会告知客户机认证成功，并执行数据同步操作。

2、如权利要求1所述的以SyncML协议为基础的认证方法，其特征在于，客户机与服务器之间信息传送是基于EAP得以实现的。

3、如权利要求2所述的以SyncML协议为基础的认证方法，其特征在于，发送信息包括了用于在通常的SyncML Schema中采用EAPSchema。

4、如权利要求3所述的以SyncML协议为基础的认证方法，其特征在于，EAP Schema包含了下述信息：

用于进行响应请求的Request、表示针对请求进行回应的Response、表示认证成功的Success、表示认证失败的Fail等信息的Code；

用于进行EAP信息识别的Identifier；

与认证相关的信息。

5、如权利要求4所述的以SyncML协议为基础的认证方法，其特征在于，当信息内包含了表示认证成功或者认证失败的信息时，EAPdata可以被去处。

6、如权利要求4所述的以SyncML协议为基础的认证方法，其特征在于，EAP data包含了表示EAP信息种类的Data Kind信息。

7、如权利要求6所述的以SyncML协议为基础的认证方法，其特征在于，Data Kind是Identity、Notification、Nak、MD5Chal、OTP、TokenCard、TLS中的其中一项。

8、如权利要求1所述的以SyncML协议为基础的认证方法，其特征在于，所述响应值是利用MD5运算法则对“Random值+密码”进行编码后所得的值。

9、如权利要求1所述的以SyncML协议为基础的认证方法，其特征在于，响应值的比较阶段包含以下过程：

第一，从数据库中获取Random值以及相关用户名的密码值；

第二，利用MD5运算法则对上述获取的值进行编码；

第三，将上述经过编码的值与响应值进行比较，确认两者是否一致；

第四，如果上述比较结果为两者一致，就判定为认证成功。

Images