CN101471938B - 一种点对点p2p网络中的认证方法、系统和装置 - Google Patents

Abstract

本发明的实施例公开了一种点对点P2P网络中的认证方法，包括：发起实体发送业务请求至中间实体，该业务请求承载在会话初始协议SIP上；当发起实体经中间实体认证通过后，发起实体接收中间实体发送的包括目的实体信息的响应消息，该响应消息承载在会话初始协议SIP上；当发起实体对中间实体认证通过后，发起实体发送业务请求至目的实体。本发明的实施例还公开了一种点对点P2P网络中的认证系统和装置。本发明的实施例中，通过发起实体与消息路由过程中的中间实体的认证，实现了在大规模P2PSIP网络环境下端到端的身份认证和注册资源完整性保护，有效地解决了P2PSIP网络中的ID假冒和注册资源恶意修改的问题。

Description

一种点对点P2P网络中的认证方法、系统和装置

技术领域

本发明涉及网络技术领域，尤其涉及一种点对点P2P(Peer-to-Peer，对等网络)网络中的认证方法、系统和装置。

背景技术

P2P技术是目前国际计算机网络技术领域研究的一个热点，并越来越受到人们的认可，它提供了一种新的共享资源的方法。在P2P网络环境中，成千上万台彼此连接的计算机都处于对等的地位，每台主机既是资源请求者(Client)又是资源提供者(Server)，能对其他计算机的请求做出响应，自愿提供资源与服务，因此称之为Peer对等节点。

P2P SIP(Session Initiation Protocol，会话初始协议)是一套与SIP相关的协议，使用P2P技术解析SIP请求的目标(Resource)，提供SIP消息传输，并提供其他SIP相关的服务。P2P SIP技术可以用于支撑许多应用，其典型应用包括：P2P VOIP(Voice Over Internet Protocol，互联网语音协议)、核心网等，并可能成为许多网络系统的核心协议。

P2P SIP采用结构化(Structured)的P2P网络。结构化相比于非结构化P2P网络具有扩展性高和查询速度快等优势，它允许应用程序以较小的跳数定位对象，同时每个节点的路由表仅需要很少的条目。在结构化P2P中，对象的分布和路由，主要由节点的标识号(ID)和对象的键值(key)来决定，key和ID共享一个ID空间。以Chord环为例，该环中的每个节点都有一个唯一的ID，通常由其IP地址通过哈希函数得到，即ID＝Hash(IP)，其中Hash为哈希函数，而对象的key由对象的名字通过哈希函数得到。Hash通常采用MD5或SHA1等安全哈希函数。对象O根据其key，由拥有某个ID的节点P保存和控制，此ID为系统中存在的最小的大于等于此key的ID，此时称节点P为对象O的根。例如图1A中，对象K10由节点N14保存，N14是对象K10的根。同理，K22、K30由节点N32保存。

如果一个对等网络中有n个节点，那么任意两个节点之间的通信可以在O(log n)的时间内完成。每个节点通过维护一张含有条目的系统路由表，便可以完成路由工作。这

个条目中的第i条记录了从当前节点的ID加上2i-1后，系统中存在的最小的大于等于该值的ID。在具体的路由过程中，当节点p想要和节点q进行通讯时，节点p会在自己的路由表中查找出比q小的最大标识号r，并将请求转发给节点r。节点r收到请求以后会进行和p一样的操作，直至请求顺利抵达q。例如图1B示意了节点N8的路由表，图1C示意了从N8开始查找对象K54的过程。

P2P SIP网络的典型结构如图2所示，对于该图的详细说明如下：

1)图中主要包括Peer和Client，Peer构成结构化P2P网络，Client使用P2P网络的服务。Peer通常运行在用户的机器上，可以在NAT(Network AddressTranslation，网络地址转换设备)之后。

2)图中的Peer可以与不同的SIP实体耦合，包括UA(User Agent，用户代理)Peer/Proxy(代理)Peer/Redir(重定向)Peer/PSTN(Public SwitchedTelephone Network，公共开关电话网络)Gateway(网关)Peer，它们提供了SIP UE/Proxy/Redirect/与PSTN网络互通功能，有的Proxy Peer(如图中P)还提供了与别的SIP网络互通的功能。

3)Peer除了可提供SIP地址解析服务，部分或全部Peer还可提供其他服务，例如STUN、Relay、VoiceMail。其中STUN/Relay用于提供NAT穿越支持。VoiceMail可以认为是一种增值业务。这种方式提供了一种可扩展的增值业务提供方案，其他业务如Presence/Conference同样可以叠加进来。

4)对于Authentication Server(即Auth，鉴权服务器)/Accounting(或Billing)Server(即Acc，计费服务器)，用于提供认证和记帐服务，它们与系统的安全性及可运营性相关。这两个功能由集中的服务器来提供。

P2P SIP消息格式直接使用SIP消息进行扩展来描述P2P消息。其系统主要分为七个流程：

Peer/User Enrollment流程；Peer加入流程；User注册流程；服务(Service)注册流程；User申请增值业务(Service)流程；基本呼叫流程；增值业务呼叫流程。

由于存在大量的安全攻击，故需要建立相应的安全机制。图3以会话发起流程为例，描述了该过程中可能受到的攻击。

现有技术中提出了一种在P2PSIP网络中实现基于共享秘密的端到端的认证机制。Overlay(叠加网络)网络上的每个实体(节点、用户和资源)通过带外机制事先都得到一个共享秘密(Shared Secret)。当某实体发起消息时，对消息各字段(from/to/cotact/date/call-id/Seq/message-body)利用共享秘密和HMAC-SHA1方法生成的值作为identity头，在identity-info头里带上算法参数。消息接收方利用事先知道的共享秘密和identity-info头里得到的算法参数对消息的各字段重新计算，如果计算值与identity头带的值一样，则认证通过。认证通过后，消息接收方回复响应消息，通过同样的方法生成并带上identity和identity-info头，最初的消息发起方也通过同样的方法认证响应消息。到此，双方的一次事务交互完成。

发明人在实现本发明的过程中，发现现有技术至少存在以下问题：

此认证并不全面，主要问题在于未包含安全路由，因此无法提供有效的端到端身份认证。

发明内容

本发明的实施例提供一种点对点P2P网络中的认证方法、系统和装置，以实现P2PSIP网络中的身份认证和业务完整性保护。

为达到上述目的，本发明的实施例提供一种点对点P2P网络中的认证方法，包括如下步骤：

发起实体发送业务请求至中间实体，该业务请求承载在会话初始协议SIP上；

当发起实体经中间实体认证通过后，发起实体接收中间实体发送的包括目的实体信息的响应消息，该响应消息承载在会话初始协议SIP上；

当发起实体对中间实体认证通过后，发起实体发送业务请求至目的实体。

本发明的实施例还提供一种点对点P2P网络中的认证系统，包括：发起实体、中间实体和目的实体；

发起实体，用于发送业务请求至中间实体，该业务请求承载在会话初始协议SIP上；接收中间实体发送的包括目的实体信息的响应消息，该响应消息承载在会话初始协议SIP上；根据对中间实体认证通过，发送业务请求至目的实体；

中间实体，用于接收发起实体发送的业务请求；根据对发起实体认证通过，发送包括目的实体信息的响应消息至发起实体；

目的实体，用于接收发起实体发送的业务请求。

本发明的实施例还提供一种点对点P2P网络中的发起实体，包括：

请求消息生成单元，用于生成业务请求，发送业务请求至中间实体或目的实体，该业务请求承载在会话初始协议SIP上；

发起认证单元，用于对中间实体或目的实体返回的消息进行认证。

与现有技术相比，本发明的实施例具有以下优点：

通过发起实体与消息路由过程中的中间实体的认证，完善了节点间的认证流程，实现了在大规模P2PSIP网络环境下端到端的身份认证和注册资源完整性保护，有效地解决了P2PSIP网络中的ID假冒和注册资源恶意修改的问题，提高了P2PSIP网络的可信可管理性。

附图说明

图1A是现有技术中Chord环的结构示意图；

图1B是现有技术中节点上路由表的示意图；

图1C是现有技术中节点查找对象的过程；

图2是现有技术中P2P SIP网络的典型结构示意图；

图3是现有技术中会话发起流程中可能受到的攻击的示意图；

图4A是本发明的实施例中Peer的加入流程示意图；

图4B是本发明的实施例中Peer加入流程中先路由再认证的流程示意图；

图5A是本发明的实施例中User的注册流程示意图；

图5B是本发明的实施例中User的注册流程示意图；

图5C是本发明的实施例中User的注册流程示意图；

图6是本发明的实施例中基本呼叫流程示意图；

图7是本发明的实施例中服务注册流程示意图；

图8是本发明的实施例中User申请增值业务流程示意图；

图9A是本发明的实施例中增值业务呼叫流程的主叫留言流程示意图；

图9B是本发明的实施例中增值业务呼叫流程的被叫收听流程示意图；

图10是本发明的实施例中P2P网络中的认证系统结构示意图。

具体实施方式

以下结合附图和实施例，对本发明的实施方式作进一步说明。

本发明实施例提供一种P2P网络中的认证方法，对于发起实体的业务请求消息，在查找和路由过程中经过中间实体时，业务的发起实体和中间实体间需要进行认证，认证通过后进行消息的转发。

以下对P2P SIP系统的各流程中，本发明实施例的应用方式进行逐一描述。

(1)Enrollment(登记)流程

对于新节点的Enrollment流程，根据产生KU(公钥)/KR(私钥)的对象不同，可以分为两类：1)KU/KR由节点本身产生，节点发送KU给CA(Certificate Authority，证书授权)，请求证书签名。2)KU/KR由CA产生，用TLS(Transport Layer Security，传输层安全)方式获取个人证书，该请况下CA知道私钥。此Enrollment过程中的认证方法可以采用已有方法。

(2)Peer加入流程(Peer间认证)

本发明的实施例中，Peer的加入流程如图4A所示，以新加入的节点为PeerE为例，该Peer加入流程包括如下步骤：

步骤s4a01、peer E向peer G发起注册并附上自己的Identity，peer G可以是任意节点或bootstrap(引导节点)节点，peer G认证peer E的Identity。如果peerG认证peer E失败，则返回401消息(401消息表示试图未经授权访问受密码保护的内容)，后面的流程在这一点上如未特别说明，均与此相同。

步骤s4a02、peer G发现peer E不是由自己负责，返回302消息(302消息表示重定向消息)给peerE通知其应该去找别的节点。下一个节点的信息包含在peer G返回的消息所填的contact字段中，同时peer G附上自己的Identity以便peer E认证，peer E认证收到消息中的peer G的Identity。

步骤s4a03、该查找过程一直持续，由于原理相同本流程图省略，最终找到为peer E负责的节点peer D。peer E向peer D发起注册并附上自己的Identity。

步骤s4a04、peer D返回200ok消息(200消息表示一切正常)说明peer E该由自己负责，peer D的路由表中填入peer E的Peer ID，同时返回自己的Identity，让peer E认证。

步骤s4a05、peer D把应该由peer E负责的资源发给peer E，同时附上自己的Identity以便peer E认证。

步骤s4a06、peer E确认负责的资源，并发送消息给peer D。peer D对消息进行认证，步骤s4a06和s4a05中消息的Seq(Sequence，序列号)必须一致。如果认证成功，peer D使peer E正常加入overlay(叠加网络)；如果认证失败，则peer D拒绝peer E加入overlay。

由以上流程可以看出，在此节点加入过程中，peerE对每一次收到的消息均进行认证，并执行安全消息转发流程(后面的流程如未特别说明，均与此相同)。peer D对于步骤s4a06中消息的处理，在一定程度上可以防止peer E的IP假冒。因为如果peer E的IP是假冒的，peer E无法收到步骤s4a05中的消息，peer E难以获知Seq，则peer E在步骤s4a06的消息中难以构造有效的identity。

在此节点加入流程中，也可以采用先路由再认证的方法：即只在加入节点和准入节点间进行认证而其他节点间先不进行认证，若当事者双方认证失败，则重新执行认证流程，即在路由过程中，每一次节点间的交互都认证，认证失败，则回溯或进行冗余路由，重复下去直到找到正确的节点。该先路由再认证的方法如图4B所示，包括以下步骤：

步骤s4b01、peer E向peer G发起注册，peer G可以是任意节点或bootstrap节点。

步骤s4b02、peer G发现peer E不是由自己负责，返回302消息(302消息表示重定向消息)给peer E通知其应该去找别的节点。

步骤s4b03、这个过程一直持续，由于原理相同本流程图省略，最终找到为peer E负责的节点peer D，peer E向peer D发起注册并附上自己的Identity。

步骤s4b04、peer D返回200ok消息(200消息表示一切正常)说明peer E该由自己负责，peer D的路由表中填入peer E的Peer ID，同时返回自己的Identity，让peer E认证。

步骤s4b05、peer D把应该由peer E负责的资源发给peer E，同时附上自己的Identity以便peer E认证。

若此时peer D对peer E的注册请求认证失败并返回失败消息，则peer E进行回溯或进行冗余路由，重复下去直到找到正确的节点。回溯路由的具体步骤为：peer E回溯到与peer D进行认证前的上一节点，这里假设为节点G，peer E再次向peer D发起注册，同时附上自己的Identity，以确认能否与节点G注册成功。按照这种方法直至找到正确的节点。冗余路由的具体步骤为：peer E从新寻找一条路径，以寻找负责自己的正确节点。

以下的流程中，都可以采用这种路由过程中进行认证的方法，或采取先路由后认证的方法，在认证失败时进行回溯路由或冗余路由。以下的各认证流程中，如未特别说明，都可以采用这种方法。

在上述认证过程中，每个peer利用自己的私钥生成identity头，并在identityinfo头中注明证书下载地址，该下载地址可以在节点本地保存，或在网络中的其他位置保存，以便其他节点在没有本节点的证书时能够从该下载地址进行证书的下载，该证书的下载过程为：需要获取其他节点证书的节点向下载地址发送请求获取证书消息，下载地址的实体确认该消息后将证书发送给该节点。另外302消息也包括Identity，实现双向认证，重新Reg的Identity需重新生成，虽然Call-ID不变但Seq变化。

以上认证流程结束后，若peer E通过了peer D的认证，则peer D使peer E正常加入overlay。具体的，peer D通知相关节点peer E加入了overlay，使peer E能够路由某些消息。若peer E没有通过peer D的认证，则peer D拒绝peer E正常加入overlay，peer D不通知相关节点peer E的加入，使peer E无法参与路由。

(3)User注册流程

该User注册流程与上述实施例中描述的peer注册过程相似，流程的原理相同，即流程所涉及的当事双方必须作认证，与中间的路由过程中经过的实体可以做认证。但由于UA client的加入，流程有所变化，所涉及的实体不仅包括节点，还包括UA client。对于User注册，可以存在三种流程，设计的基本原则是：注册User必须与保存User资源的节点间做认证，与查找过程中的节点间可以做认证。

方案a：与peer加入流程类似，将每一跳的结果直接返回A，其流程如图5A所示。

步骤s5a01、用户A向peer E发起查询，寻找负责自己的节点，附上自己的Identity。

步骤s5a02、peer E收到消息后认证用户A的Identity，返回302消息说明不该自己负责，同时附上自己的Identity。根据某种路由算法，peer E把自己认为用户A应该找的下一个节点peer G填在contact中随302消息一同返回。

步骤s5a03、用户A认证收到的消息，并向下一节点peer G发出查询。

步骤s5a04、重复步骤s5a02，直到找到最终节点peer P。

步骤s5a05、用户A向peer P发起查询，附上自己的Identity。

步骤s5a06、peer P返回200ok消息，说明用户A该由自己负责，peer P把用户A的注册消息、Identity头和Identity-info头三部分构成Resource Ticket，保存下来，同时返回自己的Identity，让用户A认证。

上述步骤s5a01～5a06中，用户A与每一跳的节点进行双向认证。例如UAA-peer E，UA A-peer G，UA A-peer P，保证了每一跳的安全性。但是用户A要感知重定向中的每一过程，UA在业务处理中参与度太高。该过程不需要client协议，但client要支持identity，且要对peer ID进行认证，协议简单。

如果上述流程中步骤s5a01到步骤s5a04采取should认证，是因为从统一的角度来看CA方案与集中式方案相比流程简单，每一步的意义也比较明确，用should保证路由的安全性。

方案b：采用RFC 3261中的tunnel(隧道)模式，如下图5B所示：

步骤s5b01、用户A向peer E发起查询，寻找负责自己的节点，附上自己的Identity

步骤s5b02、peer E收到消息后认证用户A的Identity，发现用户A不由自己负责，把IdentityA封装起来，外层Reg消息中，除request_uri、date、Seq外，都由s5b01中的消息复制，加上自己的IdentityE，继续向peer G查询用户A该由哪个节点负责

步骤s5b03、peer G收到消息后认证peer E的Identity，经过查询发现用户A不由自己负责，返回302消息说明不该自己负责，同时附上自己的Identity。根据某种路由算法，peer G认为应该由peer P负责，则在302消息中携带peer P的信息。

步骤s5b04、peer E认证收到的消息，并向下一节点peer P发出查询，并附上自己的Identity。

步骤s5b05、peer P认证peer E，同时认证封装起来的用户A的Identity，当两者同时认证通过，返回200ok消息，说明用户A该由自己负责，peer P把用户用户A的注册消息、Identity头和Identity-info头三部分构成Resource Ticket，保存下来，同时返回自己的Identity，让用户A和peer E认证。

步骤s5b06、peer E认证通过后，将步骤s5b05中的IdentityP封装起来，外层200消息中，除request_uri、date、Seq外，都由消息步骤s5b05复制，加上自己的IdentityE，继续向用户A发送。用户A先认证peer E的Identity，然后认证封装起来的peer P的Identity。如果任一认证未通过，用户A需要找另外的peer，重新发起注册。

上述步骤s5b01～5b06中，步骤s5b02中peer E将步骤s5b01中的消息作为message body(消息体)封装起来。同时peer E构造自己的identity，但如果peerE不需要被认证，则可以不构造而直接进行转发。

上述流程中，如果不用隧道模式，即步骤s5b06中peer E直接转发步骤s5b05中的消息而不进行修改是不可实施的。若直接转发，则peer P返回200ok的时候是用s5b05中的消息的Seq生成IdentityP，而s5b05和s5b06中的消息是两个不同的事务，其Seq不同，故s5b05中peer P的Identity无效。所以一定要用隧道进行封装。

上述流程中，UA A-peer E间双向或单向认证，peer节点间也双向认证；UA A-peer P间双向认证。该流程不需要client协议，但client要支持identity，且要对peerID进行认证。另外，由于Peer需要故tunnel操作，如peer E入tunnel，peer P出tunnel，过程较复杂，且需扩充peer协议。

方案c：先进行查询，查找某个Hashi值，再直接到该Hashi值对应的节点进行注册。流程如下：

步骤s5c01、用户A向peer E发起查询，寻找为自己负责的节点，附上自己的Identity。

步骤s5c02、peer E收到消息后认证用户A的Identity，发现用户A不该自己负责。根据某种路由算法，peer E把消息转发给自己认为用户A应该找的下一个peer G，同时把相应的字段修改成自己的内容，并进行签名。

步骤s5c03、peer G认证收到的消息，发现自己不是负责节点，peer G把自己认为peer E应该找的下一个节点peer P填在contact中随302消息一同返回，并附上自己的Identity。

步骤s5c04、重复s5b02，直到找到最终节点peer P，peer E向peer P发起查询，附上自己的Identity。

步骤s5c05、peer P认证peer E的Identity，返回200ok消息，200响应的contact头域包含peer P的IP地址，说明用户A该由peer P负责，同时返回自己的Identity，让peer E认证。

步骤s5c06、peer E认证peer P的Identity后，用自己的Identity替换掉peer P的Identity，同时peer E和peer P做认证；把200ok消息转发给用户A，把找到peer P的消息告诉用户A同时用户A和peer E做认证。

步骤s5c07、用户A直接向peer P发起注册请求，附上IdentityA。

步骤s5c08、peer P把用户A的注册消息、Identity头和Identity-info头三部分构成Resource Ticket，保存下来，返回200ok消息，同时附上自己的Identity让A认证。

如果步骤s5c06或步骤s5c08中的消息认证失败，则UAA需要找另外的peer，重新发起注册。

步骤s5c05和步骤s5c06这两步中的认证过程可以有几种设计选择。以下有三种方案，其中peer E不能直接转发步骤s5c05中的消息，否则无法实现peer A和peer E之间的认证：

方案一、图5C中所采用的方案需扩展peer协议，使其支持对resource的find_successor操作。定义参数user的值为user＝resource(已过时)。P返回的步骤s5c05中的消息为200 IdentityP，表示已经找到目标节点，200响应的contact头域包含peer P的IP地址，同时peer E和peer P做认证；peer E在步骤s5c06中消息为200 IdentityE，用peer E的Identity替换掉peer P的Identity，把找到peer P节点的消息告诉用户A同时用户A和peer E做认证。

以下为消息的两个实例，其中假设用户A的IP地址为10.0.0.1；peer E的IP地址为10.0.0.5；peer P的IP地址为10.0.0.16，目前user＝resource已经过时，需定义新的格式。

步骤s5c05中的消息：

REGISTER sip:10.0.0.5 SIP/2.0

To:A<sip:A10.0.0.1；user＝peer>

From:A<sip:A10.0.0.1；user＝peer>；tag＝456248

Call-ID:843817637684230998sdasdh09

Seq:1826REGISTER

Expires:7200

overlay＝chat；expires＝600

Content-Length:0

Identity:IdentityA

Identity-info

步骤s5c06中的消息：

SIP/2.0 200ok

  From:E<sip:E10.0.0.5；user＝peer>

      To:A<sip:A10.0.0.1；user＝peer>

      Contact:P<sip:P10.0.0.16；user＝peer>

    Call-ID:843817637684230998sdasdh09

    Seq:1826REGISTER

    Expires:7200

    DHT-PeerID:E            <sip:E10.0.0.5；user＝peer>；algorithm＝shal；

overlay＝chat；expires＝600

    Content-Length:0

    Identity:IdentityE

    Identity-info

方案二：

步骤s5c05中返回404 IdentityP，表示A的contact在P中未找到，此消息还包含P的dht-peerID头域，其中有P的peerID和IP信息。步骤s5c06返回的消息改为404 IdentityE，即需去掉IdentityP加上IdentityE，但dht-peerID头域不修改。之后，A根据dht-peerID中的P的IP地址，直接向P发起步骤s5c07中的消息。

使用该方案时，UAA难以正确认证peer E。因为s5c06中消息的dht-peerID是P的，而identity却是E构造的。另外，虽然UA A在s5c01中将消息发往peer E，UA A知道s5c06中的消息必然来自于E，A可以基于这一点来对s5c06中的identity进行认证。但这种方法不是基于s5c06中本身包括的消息来对s5c06进行认证，因此存在缺陷。

方案三：

步骤s5c05中返回302 IdentityP消息表示找到所需的节点但其中没有UAA的contact信息，并在contact中填加P的IP地址；步骤s5c06中把这个消息继续传递给UA A，同时去掉P的头加上自己的头，即302 IdentityE。使用该方法需要对对302消息进行区分，对302消息增加了语义：找到了负责的节点但没有A对应的内容。而传统302消息只能表示没找到。本方案在处理中需增加一步用来判断具体语义。例如E对不同的302消息，需进行不同的处理：对于s5c03，根据contact中的内容向P查询；对于s5c05，发现其又重定向到P，因此将其转发到A。

优点：不需扩展peer协议

(4)基本呼叫流程

如图6所示，步骤s601到s606为查询过程，与user注册过程类似，其中s605和s606是peer R出示自己保存的用户C的resource ticket(资源票据)给用户A来认证。步骤s607到s613的流程与普通流程类似。

如果对s606中的消息认证失败，则重新开始执行每步认证流程。具体的流程与User注册流程基本相同，也包括3种方案。不同之处是：步骤s605、步骤s606需要增加根据resource ticket的认证。如果步骤s606中resource ticket认证成功，而identity认证失败，仍认为认证是成功的

如果步骤s606的消息认证成功，而步骤s609的消息认证失败，可认为系统受到攻击(例如from头域被恶意修改)，或系统出错。此时需要其他机制来对此进行恢复，例如要求IP报文走其他路由，通过带外方式通知对方刷新注册消息，通知对方检查系统等。

其他消息的认证直接发生于当事者双方，认证失败可认为系统受到攻击或出错。s601到s606是查询过程，不涉及数据更新，可以进行认证。s607到s613步，用户A与用户C间双向认证。如果对s607中的消息认证失败，则重新开始走每步认证流程，s601到s606中必须进行认证。

认证中的问题与解决方法与User注册流程相同。

由于基于resource ticket的认证是端到端的，所以只要它认证成功，即使其它失败了，也可以认为步骤s601到s606的认证成功。

(5)服务注册流程

如图7所示，与peer加入流程安全机类似，区别在于：步骤s703中比普通认证多了一个属性证书AC_S_info，表明属性证书的地址，peer R收到peerS的注册消息后认证其公钥证书和属性证书，并保存resource ticket，resourceticket的生成方法见上文实施例中的描述。

另外，可以选择以下两种方式来说明节点的属性：a，公钥证书和属性证书方式；b，公钥证书扩展方式。

图7为方式a，查询过程中只须认证peer S的公钥证书，不须认证它的服务属性，最终节点peer R才需要对peer S做公钥和服务属性两种认证：s703和s704。

如果是公钥证书扩展，即：方式b，则s703中不需要AC_S_info；但公钥证书扩展涉及到的证书管理问题更严重。本流程与集中式方法表面上有些不同(参见集中认证)，s704返回的200消息中包含了401然后认证对方证书的过程，与集中式方法本质是相同的。

针对peer S是否有能力提供服务，有两种证书技术。其中，公钥证书扩展具体为：证书除了绑定公钥外还绑定了服务属性，操作简单但是增加一个服务属性需要修改证书，导致证书管理麻烦。也可以同时使用公钥证书和属性证书，该操作比较复杂但是正式的管理简单。

(6)User申请增值业务(Service)流程

如图8所示，与User注册流程相似，以方案a为例(其他原理相同)，每一次都与user交互，流程如下：

步骤s805中比普通认证多了一个属性证书信息AC_A_info，peer P收到peer A的注册消息后认证其公钥证书和属性证书，并保存resource ticket，resource ticket的生成方法见上述实施例中的内容。

User在Enrollment过程申请了一个服务就相应获取一个可以使用这种服务的证书或更新原来的属性证书，这是CA分发的。之后User在通知overlay时，就出示自己的属性证书，并生成相应的业务属性激活ticket，相当于自己签发的属性证书。这里的属性证书与服务注册流程中的属性证书作用不同，这里表示用户有使用什么服务的资格，服务注册流程中属性证书表示能提供什么服务。

属性证书的作用具体为，在Open(开放)的P2P环境中，如果不考虑资源问题，提供的业务就可以让别的节点使用，所有节点都可以用的话就不需要属性证书，只需要激活便可使用。但如果考虑的运营的环境，需对某些客户提供特定的服务，普通用户没有权限使用，而且资源还是受限的，故还是需要用属性证书来限制对资源的使用。

激活ticket的作用具体为，用户被允许使用某业务，并不代表用户会使用此业务。激活过程表示有权限的用户准备使用某业务，而这种激活过程可以用密码学的方法进行保护，因此有了激活ticket。

(7)增值业务呼叫流程

主叫留言流程如图9A所示，被叫收听流程如图9B所示。

步骤s9a01到s9a06为peer查询流程，s9a05和s9a06步骤中的消息除了告诉用户A用户C不在线外，还带有用户C可以使用的增值业务；如果对步骤s9a06中的消息认证失败，则重新开始执行每步认证流程。具体的流程与User注册流程基本相同，也包括3种方案。不同之处在于：步骤s9a05、s9a06需要增加根据resource ticket的认证。如果s9a06中resource ticket认证成功，而identity认证失败，仍认为认证是成功的

s9a07和s9a08为服务查询流程。

s9a09到s9a14与普通流程类似，其中s9a11中EKUc[K2||IDa||T||L]用C的公钥加密，放在服务节点S上，只有C才能解密，S不知道这个ticket无法修改。

步骤s9b01到s9b04为用户上线注册更新contact过程，overlay上存储用户信息的节点返回200消息里带上用户可以使用哪些业务的Resource Ticket；步骤s9b03和s9b04中的消息返回用户A的资源票据给用户C认证。

步骤s9b05和步骤s9b06为服务查询流程，用户查找提供VM服务的节点。

步骤s9b07中发出invite请求。

步骤s9b08中，VM S返回自己的Identity以及EKUc[K2||IDa||T||L]，只有C用自己的私钥才能解密，得到加密媒体流的密钥K2，用于解密收听VM。

采用与基本呼叫流程类似的安全机制，还包括：

1.恶意的服务节点选择ID窃取留言信息，这种威胁可以在服务节点注册时对服务节点的ID做认证来避免。

2.留言信息的加密及完整性保护。留言用户对每段媒体流用会话密钥加密，并用自己的私钥做签名，会话密钥用留言接收方的公钥加密，三部分内容传到服务节点保存起来。

3.留言接收时，先用自己私钥解密出会话密钥，用会话密钥解密每段媒体流，并用留言方的公钥认证签名。

本发明的实施例还提供了一种P2PSIP网络中的认证系统，如图10所示，包括发起实体10、中间实体20和目的实体30，其中以中间实体为只有一个为例。

发起实体10，用于将业务请求通过中间实体20向目的实体30发送，并在业务请求经中间实体20路由到目的实体30的过程中，与路由过程中的中间实体依次进行认证；

中间实体20，用于与发起实体10进行认证，认证通过时将业务请求向目的实体30转发；

目的实体30，用于与发起实体10进行认证，处理发起实体10发送的业务请求。

具体地，发起实体10进一步包括：请求消息生成单元11、发起认证单元12和证书存储单元13，其中：

请求消息生成单元11，用于生成需要向目的实体30或中间实体20发送的业务请求，该业务请求中包括携带本实体的标识Identity、证书下载地址、资源票据Resource Ticket、属性证书中的一种或多种。

发起认证单元12，用于对中间实体、和/或目的实体返回的消息进行认证。

证书存储单元13，用于存储本实体的证书，在其他实体需要时向其提供。

具体地，中间实体20进一步包括：下一跳选择单元21和中间认证单元22，其中：

下一跳选择单元21，用于接收到发起实体10发送的业务请求时，根据本实体的信息获取可能为该发起实体10查询的目的实体，将该获取到的实体作为下一跳实体，向该下一跳实体转发该业务请求。

中间认证单元22，用于在需要时根据发起实体发送的业务请求，与发起实体10进行认证。

具体地，目的实体30进一步包括：目的认证单元31和响应消息生成单元32，其中：

目的认证单元31，用于接收到发起实体10发送的业务请求时，对其中的内容进行认证。

响应消息生成单元32，用于根据目的认证单元31的认证结果生成响应消息并向发起实体10发送。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台P2PSIP网络中的实体执行本发明各个实施例所述的方法。

以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (6)

1.一种点对点P2P网络中的认证方法，其特征在于，包括如下步骤：

发起实体发送业务请求至中间实体，所述业务请求承载在会话初始协议SIP上；

当所述发起实体经所述中间实体认证通过后，所述发起实体接收所述中间实体发送的包括目的实体信息的响应消息，所述响应消息承载在会话初始协议SIP上；

当所述发起实体对所述中间实体认证通过后，所述发起实体发送所述业务请求至所述目的实体；

当所述发起实体经所述目的实体认证通过后，所述发起实体接收所述目的实体发送的业务响应，所述业务响应承载在会话初始协议SIP上；

所述发起实体对所述目的实体进行认证；

当所述发起实体经所述目的实体认证失败后，所述发起实体接收所述目的实体发送的失败消息，所述发起实体执行回溯路由或冗余路由；

所述回溯路由具体包括：

所述发起实体重新与所述中间实体进行认证，认证通过后，所述发起实体重新与所述目的实体进行认证；

所述冗余路由具体包括：

所述发起实体与不同于所述中间实体的其他中间实体进行认证，认证通过后，所述发起实体重新与所述目的实体进行认证。

2.如权利要求1所述点对点P2P网络中的认证方法，其特征在于，所述发起实体为：请求业务的节点或从用户代理接收所述业务请求的节点；

所述目的实体为：提供所述业务的节点或提供所述业务的用户代理。

3.如权利要求2所述点对点P2P网络中的认证方法，其特征在于，所述业务请求包括所述发起实体的标识和公钥证书的下载地址；当所述发起实体为所述从用户代理接收所述业务请求的节点时，所述业务请求还包括所述用户代理的标识。

4.如权利要求3所述点对点P2P网络中的认证方法，其特征在于，所述业务请求还包括属性证书的下载地址。 

5.一种点对点P2P网络中的认证系统，其特征在于，包括：发起实体、中间实体和目的实体，其中

所述发起实体，用于发送业务请求至所述中间实体，所述业务请求承载在会话初始协议SIP上；接收所述中间实体发送的包括所述目的实体信息的响应消息，所述响应消息承载在会话初始协议SIP上；根据对所述中间实体认证通过，发送所述业务请求至所述目的实体；

所述中间实体，用于接收所述发起实体发送的所述业务请求；根据对所述发起实体认证通过，发送包括所述目的实体信息的响应消息至所述发起实体；

所述目的实体，用于接收所述发起实体发送的所述业务请求；

所述目的实体，还用于根据对所述发起实体认证通过，发送业务响应至所述发起实体，所述业务响应承载在会话初始协议SIP上；

所述发起实体，还用于接收所述目的实体发送的所述业务响应，对所述目的实体进行认证；

所述目的实体，还用于根据对所述发起实体认证失败，发送失败消息至所述发起实体；

所述发起实体，还用于接收所述目的实体发送的所述失败消息，执行回溯路由或冗余路由；

所述回溯路由具体包括：

所述发起实体重新与所述中间实体进行认证，认证通过后，所述发起实体重新与所述目的实体进行认证；

所述冗余路由具体包括：

所述发起实体与不同于所述中间实体的其他中间实体进行认证，认证通过后，所述发起实体重新与所述目的实体进行认证。

6.一种点对点P2P网络中的发起实体，其特征在于，包括：

用于发送业务请求至中间实体的单元，所述业务请求承载在会话初始协议SIP上；

用于当所述发起实体经所述中间实体认证通过后，接收所述中间实体发 送的包括目的实体信息的响应消息的单元，其中，所述响应消息承载在会话初始协议SIP上；

用于对所述中间实体进行认证的单元；

用于当所述中间实体认证单元对所述中间实体认证通过后，发送所述业务请求至所述目的实体的单元；

用于当所述发起实体经所述目的实体认证通过后，接收所述目的实体发送的业务响应的单元，所述业务响应承载在会话初始协议SIP上；

用于对所述目的实体进行认证的单元；

用于经所述目的实体认证失败后，接收所述目的实体发送的失败消息的单元；

用于当所述认证失败消息接收单元接收到所述失败消息之后，执行回溯路由的单元，其中，所述回溯路由具体包括：

所述发起实体重新与所述中间实体进行认证，认证通过后，所述发起实体重新与所述目的实体进行认证；

用于当所述认证失败消息接收单元接收到所述失败消息之后，执行冗余路由的单元，其中，所述冗余路由具体包括：

所述发起实体与不同于所述中间实体的其他中间实体进行认证，认证通过后，所述发起实体重新与所述目的实体进行认证。 

Images