CN101052032A - 一种业务实体认证方法及装置 - Google Patents

Abstract

本发明提供了一种业务实体认证方法和装置，涉及网络通信领域。为了克服现有技术中存在鉴权框架不能适用于多种网络，并且业务提供者和网络之间没有提供认证的不足，本发明所述方法包括业务实体向实体认证中心发送认证请求，所述实体认证中心收到认证请求后，根据本地策略选择一种认证方式，所述业务实体与实体认证中心间基于所选认证方式进行认证交互的步骤。本发明还提供了一种业务实体认证装置，包括认证请求发送模块，协商模块和认证交互模块。本发明所述技术方案提供了一种可协商的、通用的认证方法，提高了端到端认证框架的兼容性。

Description

一种业务实体认证方法及装置

技术领域

本发明涉及网络通信领域，特别涉及一种端到端认证框架中实现业务实体的认证方法及装置。

背景技术

大多数应用服务器在向移动用户提供某一业务时，都应该首先与用户建立相互信任的关系(例如移动用户与认证代理之间，移动用户与公钥基础设施(PKI-Public Key-Infrastructure)证书机构之间，移动用户与内容提供服务器之间等)。一般来说，这种信任关系是在移动用户与应用服务器之间的双向认证过程中确立的。

在3GPP(3rd Generation Project Partnership-第三代合作伙伴计划)中，提出了3GPP中的通用鉴权框架。参见图1，为该框架的结构示意图。通用鉴权框架通常由用户201、执行用户身份初始检查验证的实体(BSF-BootstrappingServer Function)202、用户归属网络服务器(HSS-Home Subscriber System)203，和网络业务应用实体(NAF-Network Application Function)204组成。BSF 202用于与用户201进行互验证身份，同时生成BSF 202与用户201的共享密钥；HSS 203中存储用于描述用户信息的描述(Profile)文件，同时HSS 203还兼有产生鉴权信息的功能。

用户在使用NAF所提供的业务前首先要通过BSF的认证。用户与BSF之间的互认证过程是：用户向BSF发出鉴权请求，鉴权请求消息中包括用户的永久身份标识IMPI或由IMSI转换得到的永久身份标识IMPI，BSF接到来自用户的鉴权请求后，首先到HSS获取该用户的鉴权信息，BSF向HSS请求鉴权的消息中也包含了用户的永久身份标识，HSS根据用户的永久身份标识查找到该用户的属性信息并且生成鉴权矢量返回给BSF，BSF根据所获取的鉴权信息与用户之间执行AKA(鉴权和密钥协商协议)进行互鉴权。鉴权成功后，用户和BSF之间互相认证了身份并且同时生成了共享密钥Ks，BSF为这个密钥Ks定义了一个有效期限，以便Ks进行更新。之后，BSF分配一个会话事务标识(B-TID)给用户，在将B-TID发送给用户的同时包含了Ks的有效期限，该B-TID是与Ks相关联的。共享密钥Ks是作为根密钥来使用的，不会离开用户和BSF，当用户和NAF通信时，将使用由Ks衍生出的密钥。

该通用鉴权框架的缺点是：

用户与BSF认证只支持一种认证方式(即AKA的认证方式)，对于不支持AKA认证的用户，无法完成认证，从而使得该框架只适用于3GPP无线网络的移动用户使用应用业务的情况，有很大的局限性。

另外该认证机制没有提供BSF与NAF的认证，容易使攻击者假冒NAF窃取用户的一些机密信息。

在3GPP2中，也存在一种通用的鉴权框架，参见图2，为该框架示意图。3GPP2中的通用鉴权框架由移动节点(MN-Mobile Node)301，网络业务应用实体(NAF-Network Application Function)302，执行用户身份初始检查验证的实体(BSF)303，用户归属网络服务器(HSS)304，用户归属位置寄存器以及鉴权中心(HLR/AC)，和认证授权计费服务器(AAA)组成。

MN要使用NAF提供的业务首先需要与BSF进行互认证，互认证方式有3种(包括：AKA、基于CAVE的认证方式、基于AAA的认证方式)可以根据MN以及网络支持情况，以及运营商本地策略灵活选择。

该通用鉴权框架有以下缺点：

虽然3GPP2中的MN与BSF间的认证方式可以协商，但它只支持三种认证方式，当用户或网络不支持这三种中的任何一种时(例如Kerberos认证机制)，则不能使用该鉴权框架，使得鉴权框架仍然不能适用于在多种网络中业务实体在进行业务通信前与网络的互认证，故仍然存在一定的局限性。

另外该认证机制仍然没有提供BSF与NAF的认证，容易使攻击者假冒NAF窃取用户的一些机密信息。

发明内容

为了克服现有技术中存在鉴权框架不能适用于多种网络，并且业务提供者和网络之间没有提供认证的缺点，本发明的目的在于为各种网络中的业务签约者SS和业务提供者SP业务通信前需要进行的与网络的互认证过程提供一种通用、简单的认证方法，以扩大端到端认证框架的适用范围。

本发明所述技术方案如下：

一种业务实体认证方法，所述方法包括以下步骤：

步骤A：业务实体向实体认证中心发送认证请求，所述认证请求内容包括所述业务实体的身份标识；

步骤B：所述实体认证中心收到认证请求后，根据本地策略选择一种认证方式，并向所述业务实体发送含有所述认证方式认证初始化消息；

步骤C：所述业务实体与实体认证中心间基于所选认证方式进行认证交互。

所述步骤B中根据本地策略选择一种认证方式的步骤具体包括：

步骤B1：所述实体认证中心收到认证请求后，根据所述业务实体的身份标识查找实体签约数据库，得到签约信息中保存的所述业务实体所支持的认证方式信息；

步骤B2：所述实体认证中心协商所述业务实体和网络所支持的认证方式，根据本地策略选择一种认证方式。

所述步骤A中所述认证请求内容还包括所述业务实体所支持的认证方式信息；

相应地，所述步骤B中根据本地策略选择一种认证方式的步骤具体包括：

步骤B1’：所述实体认证中心收到认证请求后，得到所述业务实体所支持的认证方式；

步骤B2’：所述实体认证中心协商所述业务实体和网络所支持的认证方式，并根据本地策略选择一种认证方式。

所述步骤A中所述认证请求内容还包括所述业务实体的安全等级信息；相应地，所述步骤B进一步包括：所述实体认证中心综合业务实体、网络对认证方式的支持情况以及安全等级信息，采用本地策略选择一种安全等级及相应的认证方式。

所述业务实体可以针对需要进行的业务类型查找本地保存的业务安全等级列表选择相应的安全等级或设定安全等级。

所述安全等级信息为业务提供者的身份标识，相应地，所述步骤B中所述实体认证中心收到所述业务提供者的身份标识后，根据所述身份标识得到该业务提供者相应的业务类型，并根据所述业务类型查找安全等级列表选择相应的安全等级。

如果所述认证交互由所述实体认证中心侧发起，所述认证初始化消息中还包括所述认证交互的第一条认证消息内容。

所述步骤C具体包括：

步骤C1：所述业务实体获得认证方式后，所述业务实体与所述实体认证中心间进行基于所选认证方式的认证交互消息；

步骤C2：认证结束后，业务实体与实体认证中心得到共享密钥材料，并且实体认证中心为业务实体分配临时身份标识，所述临时身份标识与共享密钥材料关联保存。

当网络与业务实体都只支持同一种认证方式时，所述本地策略为无需认证协商，双方直接采用此认证方式进行互认证。

所述步骤A中认证请求为HTTP Digest认证请求，所述步骤B中认证初始化消息为HTTP的401消息。

所述认证方式包括但并不限于AKA认证方式、基于SIM的认证方式、基于CAVE的认证方式、基于AAA的认证方式、TLS握手协议、DH交换、公钥证书认证和生物认证。

本发明还提供了一种业务实体认证装置，所述装置包括认证请求发送模块，协商模块和认证交互模块；

所述认证请求发送模块用于业务实体向实体认证中心发送认证请求，所述认证请求内容包括所述业务实体的身份标识；

所述协商模块用于所述实体认证中心收到认证请求后，根据本地策略选择一种认证方式，并向所述业务实体发送含有所述认证方式认证初始化消息；

所述认证交互模块用于所述业务实体与实体认证中心间基于所选认证方式进行认证交互。

本发明的有益效果是：

1、本发明所述认证方法为各种网络中的业务签约者SS和业务提供者SP业务通信前需要进行的与网络的互认证过程提供一种可协商的、通用的认证方法，以扩大端到端认证框架的适用范围。

2、本发明所述认证方法提高了该端到端认证框架的兼容性，使其能够兼容3GPP和3GPP2两种标准中的通用鉴权框架。

3、本发明所述认证方法在协商认证方式时还加入了业务安全等级需求作为协商需要考虑的因素之一，既提高的资源利用率又使得高安全等级需求的业务有了较高的安全保障。

附图说明

图1是现有技术中3GPP中的通用鉴权框架图；

图2是现有技术中3GPP2中的通用鉴权框架图；

图3是本发明所述端到端通信认证的框架图；

图4是本发明所述业务实体认证方法的流程图；

图5是本发明所述业务实体在3GPP标准规范的无线网络中认证方法的流程图；

图6是本发明所述业务实体在3GPP2标准规范的无线网络中认证方法的流程图；

图7是本发明所述认证方法中SP为银行时与实体认证中心互认证的流程图；

图8是本发明所述认证装置的结构图。

具体实施方案

下面将参照相应的附图和实施例对本发明作进一步说明，但并不作为对本发明的限定。

参见图3，图中涉及到的网络元素除了2种业务实体：SS(ServiceSubscriber-网络签约者)(101)、SP(Service Provider-网络提供者)102以外，在运营商网络中，还应该存在一个EAC(Entity Authentication Center-实体认证中心)(103)和一个ESD(Entity Subscription Database-实体签约信息数据库)(104)。在本发明中，业务实体可以是业务签约者(SS)，也可以是业务提供者(SP)。其中SS分别相当于3GPP通用鉴权框架中的用户或3GPP2通用鉴权框架中的MN；SP分别相当于3GPP通用鉴权框架或3GPP2通用鉴权框架中的NAF；EAC分别相当于3GPP通用鉴权框架或3GPP2通用鉴权框架中的BSF。

实施例1：

参见图4，本发明所述的认证方法描述如下：

步骤401：业务实体向实体认证中心(EAC-Entity AuthenticationCenter)发送认证请求，请求消息中可以携带业务实体的身份标识信息，安全等级信息，业务实体所支持的认证方式信息(如果与网络的签约信息中保存有该业务实体所支持的认证方式信息，该项可以不携带)等。其中身份信息可以包含私有身份标识PID，或公开身份标识UID等；

对于安全等级的选取，可以考虑以下几种情况：

(1)业务实体可以针对需要进行的业务类型查找本地保存的业务安全等级列表选择相应的安全等级；

(2)当业务实体本地没有保存安全等级列表时，它可以根据主观需要手动选择安全等级；

(3)业务实体也可以不选择安全等级而只是将相应业务提供者的UID发送给EAC，UID能够标识出该业务提供者提供的业务类型，然后EAC根据业务类型查找安全等级列表选择相应的安全等级。

步骤402：EAC收到认证请求后，根据身份标识查找ESD中保存的签约信息，并综合业务实体、网络对认证方式的支持情况以及安全等级，采用本地策略选择一种认证方式b。所支持的认证方式包括：AKA，基于SIM的认证，基于CAVE的认证方式，基于AAA的认证方式，TLS握手协议，DH交换，公钥证书认证，生物认证等。

当网络与业务实体都只支持一种认证方式时，无需认证协商，双方直接采用此认证方式进行互认证。

EAC选择安全等级时可以结合业务的安全等级需求也可以不结合，即安全等级这一条件对于认证协商过程是可选的。

步骤403：EAC向业务实体发送认证初始化消息，该消息中携带所选认证方式的标号，安全等级(如果在步骤402的协商过程中考虑安全等级，则该安全等级应不低于业务实体所选择的安全等级)等。

如果后续的认证交互过程由EAC侧发起，则该认证初始化消息还应包括基于此认证方式的第一条认证消息所承载的信息。

上述第一条认证消息的内容对于AKA认证来说是认证向量，对TLS认证方式就是Hello Request。

步骤404：业务实体获知认证方式。如果后续的认证由实体侧发起，则该业务实体计算认证信息；如果认证由EAC侧发起，业务实体收到了相关认证信息，那么它将计算响应值。

步骤405：业务实体与EAC间进行基于所选认证方式的认证交互过程。

步骤406：认证结束后，业务实体与EAC共享了密钥材料，并且EAC为业务实体分配临时身份标识ISR-ID或IAC-ID该标识与共享密钥材料关联保存，可以作为查找密钥材料的一个索引，或者是一个安全连接的Session ID。

实施例2：

参见图5，本例中业务实体为SS，当SS为3GPP网络中的移动终端，即图中的UE，且只支持AKA认证时，本发明所述的方法如下：

步骤501：UE向EAC发送HTTP Digest认证请求，消息中携带身份标识；

步骤502：由于3GPP和UE都只支持AKA方式，因此双方不需要协商认证方式，直接采用AKA方式认证，EAC到ESD获取该用户的认证向量(RAND，AUTN，RES，CK，IK)；

步骤503：EAC在HTTP的401消息(包含Digest AKA challenge)中发送RAND和AUTN给UE；

步骤504：UE计算并检验AUTN的正确性，以确认challenge消息是否来自一个被授权的网络，同时UE计算CK、IK和RES；

步骤505：UE发送HTTP request消息给EAC，包含有Digest AKA response，由RES计算摘要值；

步骤506：EAC验证摘要值的正确性，以认证UE的合法性；

步骤507：EAC生成密钥材料Ks＝CK||IK，以及ISR-ID(该ISR-ID生成方法以及格式与3GPP通用鉴权框架中的B-TID相同)；

步骤508：EAC发送200OK消息，表示认证成功结束，消息中包含密钥材料的有效期以及ISR-ID，并由Ks加密传送给UE；

步骤509：UE也生成同样的Ks＝CK||IK，然后解密获得ISR-ID以及有效期，并和有效期认证方式等关联保存在本地。

实施例3：

本例中业务实体为SS，当SS为一移动终端UE，且支持AKA认证、证书认证等认证方法，而网络侧是3GPP2的网络支持AKA认证、基于CAVE的认证方式以及基于MN-AAA的认证方式时，参见图6，本发明所述的方法如下：

步骤601：UE向EAC发送认证请求，消息中携带身份标识，支持的认证方式，如AKA认证、证书认证；

步骤602：EAC根据UE的身份标识到ESD查找其签约信息，再根据自身所支持的认证方式类型，如支持AKA认证、基于CAVE的认证方式以及基于MN-AAA的认证方式，采用本地策略最后确定双方采用AKA方式进行认证；EAC到ESD获取该用户的认证向量(RAND，AUTN，RES，CK，IK)；

步骤603：EAC在HTTP的401消息(包含Digest AKA challenge)中发送RAND和AUTN给UE，并将认证方式标识放在payload信息中；

步骤604：UE计算并检验AUTN的正确性，以确认challenge消息是否来自一个被授权的网络，同时UE计算CK、IK和RES；

步骤605：UE发送HTTP request消息给EAC，包含有Digest AKA response，由RES计算摘要值；

步骤606：EAC验证摘要值的正确性，以认证UE的合法性；

步骤607：EAC生成密钥材料Ks＝CK||IK，以及ISR-ID(该ISR-ID生成

方法以及格式与3GPP2通用鉴权框架中的B-TID相同)；

步骤608：EAC发送200OK消息，表示认证成功结束，消息中包含密钥材料的有效期以及ISR-ID，并由Ks加密传送给UE。

步骤609：UE也生成同样的Ks＝CK||IK，然后解密获得ISR-ID以及有效期，并和有效期认证方式等关联保存在本地。

如果UE也支持基于CAVE的认证方式，而且EAC收到认证请求后，根据身法标识查找签约信息，并结合自身支持的认证方式类型，采用本地策最后确定基于CAVE的认证方式进行互认证，则后面的认证流程与3GPP2通用鉴权框架中的基于CAVE的认证流程一样。AAA认证方式时也同理可以使用本发明方案的统一框架。

实施例4：

本例中业务实体为银行SP，当银行SP欲向UE提供业务手机银行业务前，首先需要与EAC互认证生成共享密钥材料，并建立安全连接，参见图7，本发明所述的方法如下：

步骤701：SP向EAC发送认证请求，所述请求消息中携带SP的公开身份标识UID；

步骤702：EAC根据公开身份标识查找SP的签约信息，确认SP有权提供此项业务后，获取该SP的认证能力信息，即该SP所支持的认证方式，如：证书、证书TLS认、基于预共享密钥的TLS认证等；

然后，EAC查找业务安全等级列表，确认该手机银行业务属于高安全等级，并且查找认证安全等级列表，找到符合高安全等级的网络支持的认证方式有HTTP Digest AKA，证书TLS认证，最后匹配SP所支持的认证方式，确定采用证书TLS进行互认证；

步骤703：EAC向SP发起Hello Request，并且携带认证方式标识(证书TLS认证)，以及安全等级标识；

步骤704：SP获知认证方式为证书TLS，查找本地有无Session ID：IAC-ID，即：以前已经通过EAC的证书TLS认证建立了TLS安全通道并且还在有效期内，Session ID可以作为该TLS安全通道的索引；

步骤705：SP向EAC发送Client Hello消息。如果SP没有保存有效的Session ID，该消息的Session ID字段为空；如果保存有有效的Session ID：IAC-ID，该消息的Session ID字段为该IAC-ID；

步骤706：EAC收到Client Hello消息后，查看Session ID字段是否为空，如果不为空，且能够匹配到相关联的安全连接信息，EAC直接发送Finished消息验证该安全连接的认证结果和共享密钥材料是否可用。SP验证Finished消息中的参数正确后，返回Finished消息。EAC验证该Finished消息参数正确后，双方重用该安全连接。

如果Session ID字段为空或上述Finished消息有误，则EAC根据本地策略配置消息中的参数，依次发送Server certificate消息、ServerKeyExchenge消息(可选)、CertificateRequest消息。

最后，EAC返回ServerHelloDone消息，表示ServerHello以及相关消息发送完毕；

步骤707：在收到ServerHelloDone消息后，返回Certificate消息，然后发送ClientKeyExchange消息，通过这条消息双方获得了共享秘密参数；

然后，发送CertifiicateVerify消息，便于EAC清楚地验证该SP的证书；

最后，在ChangeCipherSpec消息后立即发送Finished消息，用于正式密钥交换和验证过程的成功；

步骤708：EAC验证SP的Finished消息中的信息是否正确，如果不正确中止当前握手过程。如果正确，返回Finished消息。

如果，SP验证Finished消息中的信息正确，那么双方认证和密钥交换过程成功结束。

本实例提供了3GPP/3GPP2网络认证NAF的统一化过程方案，同样是基于本发明方案的统一框架。

参见图8，本发明还提供了一种实体认证装置，所述装置包括认证请求发送模块，协商模块和认证交互模块；

所述认证请求发送模块用于业务实体向实体认证中心发送认证请求，所述认证请求的内容包括所述业务实体的身份标识；

所述协商模块用于所述实体认证中心收到认证请求后，根据本地策略选择一种认证方式，并向所述业务实体发送认证初始化消息；

所述认证交互模块用于所述业务实体与实体认证中心间基于所选认证方式进行认证交互。

以上只是本发明的优选实施方式进行了描述，本领域的技术人员在本发明技术的方案范围内，进行的通常变化和替换，都应包含在本发明的保护范围内。

Claims (12)

1、一种业务实体认证方法，其特征在于，所述方法包括以下步骤：

步骤A：业务实体向实体认证中心发送认证请求，所述认证请求内容包括所述业务实体的身份标识；

步骤B：所述实体认证中心收到认证请求后，根据本地策略选择一种认证方式，并向所述业务实体发送含有所述认证方式认证初始化消息；

步骤C：所述业务实体与实体认证中心间基于所选认证方式进行认证交互。

2、如权利要求1所述的业务实体认证方法，其特征在于，所述步骤B中根据本地策略选择一种认证方式的步骤具体包括：

步骤B1：所述实体认证中心收到认证请求后，根据所述业务实体的身份标识查找实体签约数据库，得到签约信息中保存的所述业务实体所支持的认证方式信息；

步骤B2：所述实体认证中心协商所述业务实体和网络所支持的认证方式，根据本地策略选择一种认证方式。

3、如权利要求1所述的业务实体认证方法，其特征在于，

所述步骤A中所述认证请求内容还包括所述业务实体所支持的认证方式信息；

相应地，所述步骤B中根据本地策略选择一种认证方式的步骤具体包括：

步骤B1’：所述实体认证中心收到认证请求后，得到所述业务实体所支持的认证方式；

步骤B2’：所述实体认证中心协商所述业务实体和网络所支持的认证方式，并根据本地策略选择一种认证方式。

4、如权利要求1所述的业务实体认证方法，其特征在于，所述步骤A中所述认证请求内容还包括所述业务实体的安全等级信息；相应地，所述步骤B进一步包括：所述实体认证中心综合业务实体、网络对认证方式的支持情况以及安全等级信息，采用本地策略选择一种安全等级及相应的认证方式。

5、如权利要求4所述的业务实体认证方法，其特征在于，所述业务实体可以针对需要进行的业务类型查找本地保存的业务安全等级列表选择相应的安全等级或设定安全等级。

6、如权利要求4所述的业务实体认证方法，其特征在于，所述安全等级信息为业务提供者的身份标识，相应地，所述步骤B中所述实体认证中心收到所述业务提供者的身份标识后，根据所述身份标识得到该业务提供者相应的业务类型，并根据所述业务类型查找安全等级列表选择相应的安全等级。

7、如权利要求1所述的业务实体认证方法，其特征在于，如果所述认证交互由所述实体认证中心侧发起，所述认证初始化消息中还包括所述认证交互的第一条认证消息内容。

8、如权利要求1所述的业务实体认证方法，其特征在于，所述步骤C具体包括：

步骤C1：所述业务实体获得认证方式后，所述业务实体与所述实体认证中心间进行基于所选认证方式的认证交互消息；

步骤C2：认证结束后，业务实体与实体认证中心得到共享密钥材料，并且实体认证中心为业务实体分配临时身份标识，所述临时身份标识与共享密钥材料关联保存。

9、如权利要求1所述的业务实体认证方法，其特征在于，当网络与业务实体都只支持同一种认证方式时，所述本地策略为无需认证协商，双方直接采用此认证方式进行互认证。

10、如权利要求1所述的业务实体认证方法，其特征在于，所述步骤A中认证请求为HTTP Digest认证请求，所述步骤B中认证初始化消息为HTTP的401消息。

11、如权利要求1所述的业务实体认证方法，其特征在于，所述认证方式包括但并不限于AKA认证方式、基于SIM的认证方式、基于CAVE的认证方式、基于AAA的认证方式、TLS握手协议、DH交换、公钥证书认证和生物认证。

12、一种业务实体认证装置，其特征在于，所述装置包括认证请求发送模块，协商模块和认证交互模块；

所述认证请求发送模块用于业务实体向实体认证中心发送认证请求，所述认证请求内容包括所述业务实体的身份标识；

所述协商模块用于所述实体认证中心收到认证请求后，根据本地策略选择一种认证方式，并向所述业务实体发送含有所述认证方式认证初始化消息；

所述认证交互模块用于所述业务实体与实体认证中心间基于所选认证方式进行认证交互。

Images