CN101156352B - 基于移动网络端到端通信的认证方法、系统及认证中心 - Google Patents

Abstract

一种基于移动网络端到端通信的认证方法，该方法包括：第一业务实体与实体认证中心协商认证模式，该认证模式包括：该第一业务实体与实体认证中心之间的认证方法、第二业务实体与该实体认证中心之间的认证方法、该实体认证中心的认证查询方法及衍生密钥生成方法、以及该第一和第二业务实体之间的互认证方法；所述第一和第二业务实体分别按该认证模式与该实体认证中心进行互认证；当第一业务实体请求第二业务实体提供的业务时，所述实体认证中心按该认证模式为该第一和第二业务实体提供认证查询并生成二者之间的共享衍生密钥；该第一和第二业务实体使用所述共享衍生密钥按该认证模式进行互认证并生成会话密钥。

Description

基于移动网络端到端通信的认证方法、系统及认证中心

技术领域

本发明属于网络通信服务技术领域，特别涉及一种基于移动网络端到端通信的认证方法及系统、业务实体的认证方法及系统、以及认证中心。

发明背景

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

在第三代无线通信标准中，通用鉴权框架(GAA，GeneralAuthentication Architecture)是多种应用业务实体使用的一个用于对用户身份进行验证的通用结构，应用通用鉴权框架可实现对应用业务的用户进行检查和验证身份。上述多种应用业务可以是多播/广播业务、用户证书业务、信息即时提供业务等，也可以是代理业务。

图1为GAA的结构示意图，GAA通常由用户101、执行用户身份初始检查验证的实体(BSF)102、用户归属签约服务器(HSS，HomeSubscriber Server)103和网络应用功能实体(NAF，Network ApplicationFunction)104组成。BSF 102用于与用户101互验证身份，同时生成BSF 102与用户101的共享密钥；HSS 103中存储用于描述用户信息的描述(Profile)文件，同时HSS 103还兼有产生鉴权信息的功能。

用户需要使用某种业务时，如果其知道该业务需要到BSF进行互鉴权过程，则直接到BSF进行互鉴权，否则，用户会首先和该业务对应的NAF联系，如果该NAF使用通用鉴权框架，并且发现发出请求的用户还未到BSF进行互认证过程，则通知发出请求的用户到BSF进行身份验证。

用户与BSF之间鉴权成功后，用户和BSF之间互相认证了身份并且同时生成了共享密钥Ks，BSF为这个密钥Ks定义了一个有效期限，以便Ks进行更新。之后，BSF分配一个会话事务标识(B-TID，Bootstrapping Transaction Identifier)给用户，在将B-TID发送给用户设备(UE)的同时发送Ks的有效期限，该B-TID是与Ks相关联的。共享密钥Ks是作为根密钥来使用的，不会离开用户的UE和BSF，当用户和NAF通信时，将使用由Ks衍生出的密钥Ks_NAF来进行通信保护。

该通用鉴权框架的缺点是：1、用户与BSF认证只支持一种认证方法(即AKA的认证方法)。2、该认证机制没有提供BSF与NAF的认证，容易使攻击者假冒NAF窃取用户的一些机密信息。

在3GPP2中，也存在一种通用的鉴权框架，参见图2。图2为现有的3GPP2中的通用鉴权框架图。3GPP2中的通用鉴权框架由移动节点(MN，Mobile Node)201，网络应用功能实体(NAF，Network ApplicationFunction)202，执行用户身份初始检查验证的实体(BSF)203，用户归属网络服务器(HSS)204，用户归属位置寄存器/鉴权中心(HLR/AC)，和认证授权计费(AAA，Authentication Authorization Accounting)服务器组成。

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

但是，该3GPP2的通用鉴权框架有以下缺点：1、它只支持三种认证方法，其不能适用于业务实体与多种网络之间的互认证。2、该认证机制仍然没有提供BSF与NAF的认证，容易使攻击者假冒NAF窃取用户的一些机密信息。

综上所述，现有的通用鉴权框架仅能应用在所属的标准中，受到网络中业务实体与网络的限制，具有一定的局限性。

发明内容

本发明实施例的主要目的在于，为不同类型的实体之间建立相互信任关系提供一个适用于不同移动网络标准的通用认证框架。

本发明实施例的技术方案如下：

本发明实施例公开了一种基于移动网络端到端通信的认证方法，应用于包括：请求业务的第一业务实体、提供业务的第二业务实体和实体认证中心的系统，该方法包括：

所述第一业务实体与所述实体认证中心协商认证模式，该认证模式包括：该第一业务实体与实体认证中心之间的认证方法、该第二业务实体与该实体认证中心之间的认证方法、该实体认证中心的认证查询方法及衍生密钥生成方法、以及该第一业务实体与该第二业务实体之间的互认证方法；

所述第一业务实体和第二业务实体分别按协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证；

当第一业务实体请求第二业务实体提供的业务时，所述实体认证中心按该协商得到的认证模式中定义的认证查询方法为该第一业务实体和第二业务实体提供认证查询并按该协商得到的认证模式中定义的衍生密钥生成方法生成二者之间的共享衍生密钥；

该第一业务实体和第二业务实体使用所述共享衍生密钥按该协商得到的认证模式中定义的二者之间的互认证方法进行互认证并生成保护本次业务的会话密钥。

本发明实施例还公开了一种业务实体认证方法，应用于业务实体和实体认证中心之中，该方法包括：所述业务实体向所述实体认证中心发送认证请求，该请求携带该业务实体的身份信息和当前请求的业务类型；该实体认证中心按当前请求的业务类型确定提供业务的业务实体，获取该业务实体和提供该业务的业务实体的认证能力，并按二者的认证能力选择认证模式，该认证模式至少用于定义：该业务实体与实体认证中心之间的认证方法；该业务实体按协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证。

本发明实施例公开了一种认证查询方法，应用于包括：用于请求业务的第一业务实体、用于提供业务的第二业务实体和实体认证中心的系统；所述第一业务实体和第二业务实体分别与所述实体认证中心进行互认证，该实体认证中心分别为该第一业务实体和第二业务实体分配临时身份信息，并分别获得自身与该第一业务实体和第二业务实体之间的共享密钥材料；所述第一业务实体与所述实体认证中心协商认证模式，该认证模式至少用于定义该实体认证中心的认证查询方法及衍生密钥生成方法，该方法包括：

当第一业务实体请求第二业务实体提供的业务时，所述实体认证中心使用协商得到的认证模式中定义的认证查询方法、按该第一业务实体和第二业务实体的临时身份信息对二者权限进行认证；

使用该协商得到的认证模式中定义的衍生密钥生成方法、以及该第一业务实体和第二业务实体的临时身份信息和该第一业务实体的共享密钥材料，计算得到用于保护该第一业务实体和第二业务实体之间通信的共享衍生密钥。

本发明实施例公开了一种基于移动网络端到端通信的认证系统，包括：用于请求业务的第一业务实体、用于提供业务的第二业务实体和实体认证中心；

所述第一业务实体用于与所述实体认证中心协商认证模式，该认证模式用于定义与认证相关的方法，按协商得到的认证模式的定义与该实体认证中心进行互认证，向所述第二业务实体请求业务，按该协商得到的认证模式的定义、使用与该第二业务实体之间的共享衍生密钥与该第二业务实体进行互认证；

所述第二业务实体用于按该协商得到的认证模式的定义与该实体认证中心进行互认证，在该第一业务实体请求业务时按该协商得到的认证模式的定义、使用与该第二业务实体之间的共享衍生密钥与该第一业务实体进行互认证；

所述实体认证中心用于按该协商得到的认证模式的定义分别与该第一业务实体和第二业务实体进行互认证，在该第一业务实体请求业务时按该协商得到的认证模式的定义为该第一业务实体和第二业务实体提供认证查询并生成二者的共享衍生密钥。

本发明实施例还公开了一种业务实体认证系统，包括业务实体和实体认证中心；该系统进一步包括：用于保存业务实体签约数据的数据库；

所述业务实体用于与实体认证中心协商认证模式，该认证模式至少用于定义该业务实体与该实体认证中心之间的认证方法，该业务实体使用协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证；所述实体认证中心用于，在协商认证模式时，按所述请求业务的业务实体和所述提供业务的业务实体的身份信息查询该数据库得到这两个业务实体的认证能力，并按二者的认证能力选择认证模式。

本发明实施例公开了一种认证查询系统，包括：用于请求业务的第一业务实体、用于提供业务的第二业务实体和实体认证中心，所述第一业务实体与所述实体认证中心协商认证模式，该认证模式至少用于定义该实体认证中心的认证查询方法及衍生密钥生成方法；

所述实体认证中心用于在所述第一业务实体请求业务时使用协商得到的认证模式中定义的认证查询方法对该第一业务实体和所述第二业务实体的权限进行认证，并使用该协商得到的认证模式中定义的衍生密钥生成方法生成二者共享的衍生密钥。

本发明实施例还公开了一种认证中心，包括：

第一单元，用于协商业务实体的认证模式，该认证模式至少用于定义：业务实体与实体认证中心之间的认证方法；所述第一单元包括：第一模块，用于查询签约数据分别得到请求业务的业务实体和提供业务的业务实体的认证能力；第二模块，用于按所述第一模块得到的该请求业务的业务实体和提供业务的业务实体的认证能力选择一种认证模式；

第二单元，用于按所述第一单元协商得到的认证模式中定义的认证方法与所述业务实体进行互认证。

本发明技术方案带来的有益效果是：本发明提出了一个真正意义上的通用鉴权框架，其中提供的认证机制可以对多种认证方法和认证模型进行协商和选择，增加了认证机制的灵活性和通用性。在本发明框架中，业务提供者可以是移动网络中的应用服务器，也可以是开放网络中的应用服务器，还可以是功能强大的移动终端，使得业务签约者可使用的业务资源更丰富。该认证方案支持移动终端升级为业务提供者的情况，很好的满足了功能强大的移动终端需要提供业务服务的需求。

附图简要说明

图1为通用鉴权框架(GAA)的结构示意图。

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

图3为基于本发明的基于移动网络的端到端通信认证框架的示意图。

图4为本发明一实施例中业务实体与实体认证中心之间的认证方法协商及互认证过程的流程图。

图5为本发明一实施例中业务实体与实体认证中心的认证查询过程的流程图。

图6为与Kerberos模型相结合的端到端认证模型示意图。

图7为与Kerberos模型相结合的认证查询过程的框图。

图8为与Mediation模型相结合的端到端认证模型示意图。

图9为与Mediation模型相结合的认证查询过程的框图。

图10为本发明一实施例中业务实体认证方法的流程图。

图11为本发明一实施例中业务实体在3GPP标准规范的无线网络中认证方法的流程图。

图12为本发明一实施例中业务实体在3GPP2标准规范的无线网络中认证方法的流程图。

图13为本发明一实施例中SP为银行时与实体认证中心互认证的流程图。

图14为本发明认证装置一实施例的结构图。

图15所示为本发明一实施例中业务签约者与认证中心间的认证流程图。

图16所示为本发明一实施例中业务签约者与业务提供者间的互认证流程图。

图17所示为本发明一实施例中业务签约者与业务提供者重新利用认证结果生成会话密钥的流程图。

图18所示为本发明端到端通信认证装置一实施例的结构示意图。

实施本发明的方式

为了使本发明实施例的目的、技术方案和优点更加清楚明白，以下举实施例并参照附图，对本发明实施例进行进一步详细的说明。

图3显示了依据本发明的基于移动网络的端到端通信认证框架。该框架适用于不同移动网络标准，其作用在于为不同类型的业务实体之间建立相互信任关系，是一个真正意义上的通用鉴权框架。该通用鉴权框架涉及到的网络元素除了两种业务实体：业务签约者(SS，ServiceSubscriber)301和业务提供者(SP，Service Provider)302以外，在运营商网络中，还存在实体认证中心(EAC，Entity Authentication Center)303和实体签约信息数据库(ESD，Entity Subscription Database)304。在此框架中，SS与SP之间可进行通信，SS和SP可分别与EAC通信以完成各自的认证，而EAC可与ESD连接以从ESD中获取认证所需信息。在本发明实施例中，业务实体可以是业务签约者(SS)，也可以是业务提供者(SP)。其中，SS可相当于3GPP通用鉴权框架中的用户或3GPP2通用鉴权框架中的MN；SP可相当于3GPP通用鉴权框架或3GPP2通用鉴权框架中的NAF；EAC可相当于3GPP通用鉴权框架或3GPP2通用鉴权框架中的BSF。

大多数应用服务器在向移动用户提供某一项业务时，都首先与用户建立相互信任的关系(例如移动用户与认证代理之间，移动用户与PKI证书机构之间，移动用户与内容提供服务器之间等建立信任关系)。一般来说，这种信任关系是在移动用户与应用服务器之间进行的双向认证过程中确立的。随着移动网络的发展，业务的类型也越来越多样化：业务提供者不再是单纯的运营商网络本身，还可以是运营商网络以外的第三方内容提供者，甚至可以是移动用户本身。也就是说某些移动用户可以不仅限于使用网络提供的应用服务，还可以向网络中其他用户提供一些服务。本发明实施例中业务提供者可以有三种：运营商网络的AS、第三方AS以及移动用户，业务签约者有两种：一般普通移动用户或第三方AS。这样移动用户既可以是业务签约者又可以是业务提供者，而第三方AS既可以是业务提供者又可以是业务签约者。因此，原来将业务实体划分为用户和业务提供者，而本发明实施例中分为三种：1、SS，其为单纯的业务签约者，它只能申请业务(一般为普通的移动用户)；2、SP，其为单纯的业务提供者(运营商网络的AS或外部网络的SP)；3、业务签约者和业务提供者(又称为SSP，Service Subscriber and Provider)，SSP既是业务签约者又是业务提供者(可以是普通的移动用户，也可以是第三方的AS)。

在图3所示的框架中，EAC用于完成与业务实体进行认证方法协商及认证的过程，并且对端到端的通信实体的身份以及实体请求或提供业务权限的合法性进行检验，还具有生成衍生密钥等功能。ESD保存有实体的签约信息，签约信息包括：该实体签约的服务类型和/或该实体提供的服务类型，以及该实体支持的认证方法及认证资料等。其中，实体的签约信息与实体的私有身份标识一起保存。业务提供者在向其它实体提供业务或者业务签约者向其它实体请求业务之前，需要与网络存在签约关系，并将签约信息存放于ESD中。

本发明提供的认证流程包括如下几个阶段：

第一阶段(称为实体认证流程)：网络中每个业务签约者与业务提供者进行通信之前，业务实体需要先到EAC协商认证方法，并完成对身份的认证。

其中，认证方法的协商过程由业务实体发起，并在请求消息中携带自身身份标识，以及业务的安全等级需求。EAC根据安全等级、网络支持情况和实体签约信息，选择一种认证方法，并将相应信息返回给认证请求者。其中业务的安全等级不同所选择的认证方法也不同。请求者发确认消息表示协商过程结束。

业务实体与EAC按照协商的方法进行认证。该认证是双向的。认证结束后，认证请求实体(即请求认证的业务实体)和EAC生成共享的密钥材料，并且EAC将会根据认证请求实体的签约信息情况给其分配临时身份标识以及相应的有效期：1)如果该认证请求实体是SS，则EAC将向其分配一个中间业务请求标识(ISR-ID，Interim Service RequestIdentifier)；2)如果该认证请求实体是SP，则EAC将向其分配一个中间认证查询标识(IAC-ID Interim Authentication Check Identifier)。

EAC将业务实体的临时身份标识以及有效期发送给请求认证的业务实体，此后该请求认证的业务实体与EAC之间的通信都可以采用认证过程生成的业务实体与EAC间的共享密钥材料进行保护。

第二阶段(称为认证查询流程)：

业务签约者完成与EAC之间的认证后，便可向业务提供者请求业务。

其中，SP或SSP收到业务请求以后，如果已经完成与EAC之间的认证并获得有效的IAC-ID，便可向EAC查询业务签约者的认证情况；否则，首先到EAC进行认证以及密钥协商后，再向EAC请求查询业务签约者的认证情况，其中，查询请求中携带业务签约者的ISR-ID以及自身的IAC-ID。EAC收到查询请求后，首先根据业务签约者的标识以及业务提供者的标识查询二者是否有相应的权限，然后根据二者的相关信息，利用SS/SSP到EAC协商的Ks为二者计算一个用于保护业务签约者和提供者之间业务通信的衍生密钥，并发送给业务提供者。同时，业务签约者也由相同的参数以及算法计算出衍生密钥。业务实体与EAC之间认证所建立的信任关系存在一个有效期。有效期快要过期或已经过期，业务实体需要到EAC之间进行重认证过程，建立新的信任关系。

第三阶段(称为业务实体之间的互认证流程)：当SS与SP获得共享的衍生密钥后，在开始每次业务通信之前，还可以先利用所述衍生密钥在双方间进行互认证，并进一步生成保护本次通信安全的会话密钥Kr-SS-SP，然后利用该会话密钥保护本次业务通信。

下面结合附图对本发明提出的认证流程的各个阶段加以详细说明。

图4为本发明一实施例中业务实体与实体认证中心之间的认证方法协商及互认证流程图。本实施例中，业务实体与EAC间的认证方法协商和互认证过程由业务实体发起，如图4所示，包括如下步骤：

步骤401：业务实体自动选择所请求的业务或所提供的业务(如视频会议业务)对应认证方法的安全等级需求(例如，高安全等级)。

步骤402：该业务实体向EAC发送认证请求，该认证请求中携带该业务实体的身份标识以及其所选择的认证方法的安全等级等相关信息；

步骤403：该EAC收到该认证请求后，查找本地保存的安全等级列表，找到符合该安全等级需求的当前网络支持的认证方法，包括：认证协议、加密算法。例如，Http AKA是一种无线网络中的网络与终端的互鉴权协议，执行这个协议能够使通信的双方互相认证对方的身份，并且在通信的双方生成相同的密钥。

步骤404：该EAC根据业务实体的身份标识在ESD存储的签约信息中查询该业务实体的认证信息，例如该业务实体支持的认证方法，包括：认证协议、加密算法和其它相关参数。

步骤405：该ESD向该EAC返回该业务实体的认证能力信息(即所支持的认证协议和加密算法等)和其它相关参数。

步骤406：该EAC根据本地策略匹配网络和该业务实体所支持的认证协议和加密算法，确定出符合安全等级需求的并且双方都支持的认证协议和加密算法(即认证方法)，如果没有符合安全等级需求的并且双方都支持的认证协议和加密算法，则向该业务实体返回错误指示，结束本流程。

步骤407：该EAC将选定的认证方法，包括认证协议和加密算法，返回给该业务实体；

步骤408：该业务实体收到该EAC返回的信息后，确认认证方法，向该EAC返回确认响应。

步骤409：该业务实体和该EAC应用所选的认证协议和加密算法进行互认证，并在认证成功后，双方获得共享密钥材料(也称为共享密秘信息)。

如果业务实体是一个移动终端的话，那么共享密钥材料就可以是共享密钥(Ks)，如果业务实体是一个移动核心网域的应用服务器(AS)，那么业务实体和EAC在互认证过程中可能协商出的共享密钥材料为安全关联(SA，Security Association)即因特网协议安全(IPSec，InternetProtocol Security)协议中业务实体双方协商的安全通信的密钥以及密钥算法信息。

步骤410：该EAC向该业务实体返回认证成功响应，并分配业务实体临时身份标识以及相应的有效期，包括：1)如果向EAC发出认证请求的业务实体是业务签约者(SS/SSP)，则EAC将向其分配一个中间业务请求标识(ISR-ID)，以在向其它实体请求业务时使用；2)如果向EAC发出认证请求的业务实体是业务提供者(SP/SSP)，则EAC将向其分配一个中间业务查询标识(IAC-ID)，以在需要向EAC查询SS的认证情况时使用。

步骤411：该EAC和该业务实体侧分别将共享密钥材料与对应的安全等级关联并保存起来，包括：关联并保存ISR-ID/IAC-ID、密钥材料及认证方法和安全等级。

图5为本发明一实施例中业务实体与实体认证中心的认证查询过程的流程图。本实施例中，在完成了互认证之后，业务实体与实体认证中心要进行认证查询过程，具体处理如图5所示：

步骤501：SS(或SSP)向能够提供服务的SP(或另一个SSP)提出业务请求。该业务请求中包括了SS前面认证得到的中间业务请求标识(ISR-ID，)以及SP的公开身份标识(UID)，该公开身份标识是与其它业务实体联系的身份标识。

同一业务实体提供的不同的业务对应不同的UID，即可以利用UID区分出不同的业务。

步骤502：该SP收到业务请求后，查找本地是否保存有SS的ISR-ID，以识别该SS；如果保存有该ISR-ID以及与其关联的有效的衍生密钥和业务实体真实身份信息等，双方开始利用衍生密钥保护它们之间的业务，若SP发现该衍生密钥或该ISR-ID等信息处于次操作状态或已被撤销或销毁，则该SP指示该SS发起重认证请求，关于重认证发起的具体处理详见下文描述，结束本流程；如果没有保存该ISR-ID，则向EAC发出认证查询请求，并在认证查询请求中携带该SS的ISR-ID以及自身的IAC-ID和UID，然后执行步骤503；

步骤503：该EAC收到认证查询请求后，首先查询并判断其中携带的IAC-ID是否有效以及该SP是否有权提供该项业务，然后再查询并判断该认证查询请求携带的ISR-ID是否有效以及该SS是否有权请求此项业务，如果上述判断IAC-ID有效且该SP有权提供该项业务、并且判断ISR-ID有效且该SS有权请求此项业务(即验证通过)，则该EAC为该SS和SP生成衍生密钥。

步骤504：该EAC向该SP返回认证查询响应，该响应携带步骤503生成的衍生密钥和密钥有效期。其中，如果步骤503中的认证查询成功(即查询并判断为是)，则在返回的认证查询响应中携带新生成的衍生密钥，该衍生密钥通过该SP与EAC的共享密钥材料加密获得；否则，返回错误消息，并由该EAC通知相应的业务实体到EAC进行重认证，重认证发起的具体处理详见下文描述，结束本流程。

步骤505：该SP从该认证查询响应中解密得到新生成的衍生密钥，并将该衍生密钥、有效期、该SS的ISR-ID以及该SP的UID关联并保存在本地。

步骤506：该SP向该SS返回业务请求响应；

步骤507：该SS在本地利用相同的参数和密钥算法计算出相同的衍生密钥；其中，该密钥算法可以采用：数据加密标准(DES)、三重DES(3-DES)、高级加密标准(AES)256、AES1024等，其中256和1024代表密钥长度。

步骤508：该SS与该SP利用该衍生密钥保护它们之间的业务。

由于，业务实体与EAC之间通过认证所建立的信任关系存在一个有效期(如共享密钥材料具有、衍生密钥具有有效期、临时身份标识具有的有效期)。当有效期快要过期或已经过期时，业务实体需要与EAC进行二者的重认证以建立新的信任关系。

另外，根据共享密钥材料或临时身份标识所处的情况不同，业务实体可以具有以下状态：1、次操作状态：共享密钥材料、衍生密钥或临时身份标识快要过期，此时不能再用此共享密钥材料进行加密运算但能够用其解密以及验证实体身份；2、撤销状态：共享密钥材料、衍生密钥或临时身份标识已经过期，并且解除了共享密钥材料或临时身份与该实体的真实身份的对应关系；3、销毁状态：共享密钥材料、衍生密钥或临时身份标识的相关记录被删除。这样，当满足下列情况之一时，需要发起重认证过程：

1、EAC根据本地相关策略发现业务实体与EAC的共享密钥材料或临时身份标识处于次操作状态，EAC指示该业务实体发起重认证请求；

2、EAC根据本地相关策略发现共享密钥材料或临时身份标识处于撤销或销毁状态，EAC指示该业务实体发起重认证请求；

3、EAC不能根据临时身份标识查找到相关的身份信息和密钥信息时(即处于销毁状态)，EAC指示该业务实体发起重认证请求；

4、SP根据本地相关策略发现衍生密钥处于次操作状态时，SP指示该SS发起重认证请求；

5、SP根据本地相关策略发现衍生密钥处于撤销或销毁状态时，SP指示该SS发起重认证请求；

6、SP不能根据临时身份标识查找到相应的身份信息和密钥信息时(即处于销毁状态)，SP指示该SS发起重认证请求。

在上述EAC指示业务实体发起重认证请求时，该指示中标明有重认证的原因。如果重认证的原因是共享密钥材料或临时身份标识处于次操作状态，那么该业务实体在所发起的重认证请求中以临时身份标识自己。EAC收到该重认证请求后，根据该临时身份标识，确定无需协商认证方法，直接采用原来使用的认证方法进行互认证。如果重认证的原因是共享密钥材料或临时身份标识处于撤销或销毁状态，或是需要使用密钥材料时却不能根据临时身份查找到，那么该业务实体在所发起的重认证请求中以私有身份标识自己。EAC收到该重认证请求后，根据该私有身份标识，确定需要重新协商认证方法，该重新协商认证方法过程与图4所示的初始的认证过程相同。

同样，在上述SP指示SS发起重认证请求中，该指示标明有重认证的原因。如果该重认证的原因是临时身份标识处于次操作状态，那么该SS在所发起的重认证请求中以临时身份标识自己；EAC收到请求后，根据该临时身份标识，确定无需协商认证方法，直接采用原来使用的认证方法进行互认证。如果该重认证的原因是临时身份标识处于撤销或销毁状态，那么该SS在所发起的重认证请求中以私有身份标识自己；EAC收到请求后，根据该私有身份标识，确定需要重新协商认证方法，该重新协商认证方法过程与图4所示的初始的认证过程相同。

其中，在使用临时身份标识(即ISR-ID/IAC-ID)或者与之关联存储的共享密钥材料(即Ks/Kp)时，业务实体(即SS或SP)或者EAC必须首先验证临时身份标识或者共享密钥材料是否处于次操作、撤销或销毁状态。如果处于次操作、撤销或销毁状态，则业务实体或者EAC将触发相应的业务实体和EAC之间的实体重认证过程。在认证过程中，当收到标有失败原因的失败消息的时候，也可以触发实体的重认证过程。另外，若SP发现自身与SS之间的共享衍生密钥处于次操作、撤销或销毁状态，将向SS发送重认证请求，并在其中指明重认证原因。如果仅仅是共享衍生密钥处于次操作、撤销或销毁状态，而SS和SP的临时身份标识处于正常状态，则SS和SP不必与EAC进行初始的实体认证，由SS向EAC发起认证查询，并由EAC为生成新的共享衍生密钥发送给SP，再由SS生成相同的衍生密钥。

其中，对有效期和次操作状态的举例说明如下：以共享密钥材料的有效期为例，假设共享密钥材料的有效期为48小时，并设定44～48小时范围内是处于次操作状态，若共享密钥材料已生存45小时，就可以判断该共享密钥材料已经处于生命周期的次操作状态了。

当实体认证中心(EAC)具有Kerberos服务器功能时，可以采用与Kerberos模型相结合的认证查询方法。图6为与Kerberos模型相结合的端到端认证模型示意图。如图6所示，业务签约者(SS)向实体认证中心(EAC)请求业务许可票据，并向该EAC提供该SS的ISR-ID和UID，实体认证中心检查该ISR-ID和IAC-ID的有效性，生成业务许可票据，并向业务签约者返回该业务许可票据。业务签约者在向业务提供者发出业务请求时携带该业务许可票据，该业务提供者按该业务许可票据生成衍生密钥再向该业务签约者返回服务响应。

图7为与图6所示Kerberos模型相结合的认证查询过程的流程图。如图7所示，具体步骤如下：

步骤701：当业务签约者(SS)需要获得某项业务时，首先查看本地是否保存了对应于此项业务的业务许可票据，如果有，则直接跳到步骤705；如果没有，则向实体认证中心(EAC)发送业务许可票据请求，该请求中携带该业务签约者(SS)的中间业务请求标识(ISR-ID)，以及该项业务的业务提供者(SP)的公开身份标识(UID)。

步骤702：该EAC收到该业务许可票据请求后，进行身份和权限的合法性检查。首先通过查询该请求中携带的ISR-ID是否有效来判断该SS是否有权使用此项业务，然后根据该请求中携带的该SP的UID获得该SP的IAC-ID，并根据该IAC-ID是否有效判断该SP是否有权提供此项业务；

如果上述检查结果为该SP有权提供该项业务(即该SP合法)，该EAC根据该SS和SP的身份信息，以及该SS与该EAC的共享密钥材料计算出一个用于保护该SS和SP之间业务通信的衍生密钥K-SSP/SP，该EAC还产生一个包含衍生密钥、该SS的身份信息和该SP的身份信息的业务许可票据(SGT)，利用自身与该SP的共享密钥材料加密该业务许可票据。

如果检查结果为该SP无权提供该项业务(即该SP不合法)，则发出错误信息，该EAC通知相应的实体重新到实体认证中心认证身份，结束本流程。

步骤703：该EAC向该SS发送上述加密后的业务许可票据。

步骤704：该SS收到该业务许可票据后在本地采用和该EAC相同的参数和算法产生一个相同的衍生密钥。

步骤705：该SS向该SP发送业务请求，该业务请求携带该业务许可票据。

步骤706：该SP解密该业务许可票据，获得衍生密钥。

步骤707：该SP向该SS返回指示成功的业务请求响应。

步骤708：该SS与该SP利用该衍生密钥保护它们之间的业务。

除了采用上述步骤外，EAC也可以利用其与SS的共享密钥材料加密所述衍生密钥，并将加密后的衍生密钥发送给SS，从而SS不是在本地重新计算得出衍生密钥，而是通过解密获得衍生密钥。

同样，SS与SP获得共享的衍生密钥后，在开始每次业务通信之前，还可以先利用所述衍生密钥进行双方间的互认证，并进一步生成保护该次通信安全的会话密钥Kr-SS-SP，然后利用所述会话密钥保护该次业务通信。

当实体认证中心(EAC)具有充当仲裁者身份的可信的第三方(TTP，Trusted Third Party)功能时，也可以采用与Mediation模型相结合的认证查询方法。图8为与Mediation模型相结合的端到端认证模型示意图。如图8所示，业务签约者(SS)发送业务请求至实体认证中心(EAC)，请求业务提供者(SP)的业务；该EAC确定该SS合法后将业务请求转发至该SP；该SP返回携带自身IAC-ID的业务请求响应给该EAC；该EAC按此IAC-ID检查该SP的合法性，若该SP合法，则计算该SS和该SP之间的衍生密钥并发送给该SP，同时返回业务请求响应给该SS；该SS收到响应后计算得到同样的衍生密钥。

图9为与图8所示Mediation模型相结合的认证查询过程的流程图。如图9所示，具体步骤如下：

步骤901：业务签约者(SS)在需要使用业务提供者(SP)的某项业务时，首先向实体认证中心(EAC)提出业务请求，该业务请求中携带该SS的ISR-ID以及该SP的UID。

步骤902：该EAC检查该SS的ISR-ID的有效性，以及该SS的签约信息，以确定该SS是否有请求此项业务的权限。

步骤903：如果该SS是合法的，则该EAC为其转发业务请求给该SP，执行步骤904；如果该SS是不合法的，则该EAC向该SS发错误信息，通知该SS重新到该EAC认证身份，结束本流程。

步骤904：该SP返回业务请求响应，该响应中携带自身IAC-ID。

步骤905：该EAC检查该IAC-ID的有效性，以及该SP的签约信息，以确定该SP是否有权提供此项业务，如果该SP是合法的，则该EAC根据该SS和SP的身份信息，以及该SS与该EAC的共享密钥材料计算出一个用于保护该SS和SP之间业务通信的衍生密钥，执行步骤906；如果该SP是不合法的，则该EAC向该SP发错误信息，通知该SP重新到该EAC认证身份，结束本流程。

步骤906：该EAC向该SS发送业务请求成功响应，并向该SP发送经由该EAC与SP的共享密钥材料加密的衍生密钥。

步骤907：该SS收到该EAC发送的业务请求成功响应后，采用与该EAC相同的参数和算法计算得到衍生密钥。

步骤908：该SS与该SP使用该衍生密钥保护它们之间的业务。

同样，当SS与SP获得共享的衍生密钥后，在开始每次业务通信之前，还可以先利用所述衍生密钥进行双方间的互认证，并进一步生成保护本次通信安全的会话密钥Kr-SS-SP，然后利用该会话密钥保护本次业务通信。

以上只是本发明的优选的典型的实施方式进行了描述，其它类似的情况，如SSP作为业务实体时，它在通信中的身份可以变化，当它处于请求业务情况下，它与上述SS的处理方式相同，当它处于提供业务的情况下，它与上述SP的处理方式相同。因此，本领域的技术人员在本发明范围内进行的通常变化和替换，都应包含在本发明保护的范围内。

以下为基于本发明实施例通用鉴权框架的认证方法中若干第一阶段和第二阶段认证流程的实施例。

图10为本发明一实施例中业务实体认证方法的流程图。参见图10，本发明所述的认证方法描述如下：

步骤1001：业务实体向实体认证中心(EAC)发送认证请求，该认证请求中携带业务实体的身份标识信息、安全等级信息、该业务实体所支持的认证方法信息(其中，如果与网络的签约信息中保存有该业务实体所支持的认证方法信息，则该认证方法信息可以不携带)等。

其中，身份标识信息可以包括：私有身份标识(PID)或公开身份标识UID等。对于安全等级的选取，可以考虑以下几种情况：1)业务实体可以针对需要进行的业务类型查找本地保存的业务安全等级列表选择相应的安全等级；2)当业务实体本地没有保存安全等级列表时，它可以根据通过人机界面由用户手动选择安全等级；3)业务实体也可以不选择安全等级而只是将相应业务提供者(SP)的UID发送给EAC，该UID能够标识出该业务提供者提供的业务类型，然后该EAC能根据业务类型查找安全等级列表从而选择相应的安全等级。

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

当网络与业务实体都只支持一种认证方法时，无需认证协商，双方可直接采用此认证方法进行互认证。EAC选择安全等级时可以结合业务的安全等级需求也可以不结合，即安全等级这一条件对于认证协商过程是可选的。

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

如果后续的认证交互过程由EAC侧发起，则该认证初始化消息还应包括基于此认证方法的第一条认证消息所承载的信息。该第一条认证消息的内容对于AKA认证来说是认证向量，而对TLS认证方法就是HelloRequest。

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

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

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

图11为本发明一实施例中业务实体在3GPP标准规范的无线网络中认证方法的流程图。参见图11，本实施例中，业务实体为SS，当SS为3GPP网络中的移动终端，即图11中的UE，且只支持AKA认证时，认证流程如下：

步骤1101：UE向EAC发送HTTP Digest认证请求，该请求中携带其身份标识。

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

步骤1103：该EAC在HTTP的401消息(包含Digest AKAchallenge)中携带该认证向量中的RAND和AUTN给该UE。

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

步骤1105：该UE发送HTTP request消息给该EAC，其中包含DigestAKA response以及由上述RES计算的摘要值。

步骤1106：该EAC验证上述计算的摘要值的正确性，以认证该UE的合法性。

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

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

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

图12为本发明一实施例中业务实体在3GPP2标准规范的无线网络中认证方法的流程图。本实施例中，业务实体为SS，当该SS为一移动终端(UE)且支持AKA认证、证书认证等认证方法，而网络侧是3GPP2的网络，其支持AKA认证、基于CAVE的认证方法以及基于MN-AAA的认证方法时，参见图12，认证流程如下：

步骤1201：UE向EAC发送HTTP认证请求，该认证请求中携带身份标识及支持的认证方法，如AKA认证、证书认证。

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

步骤1203：该EAC在HTTP的401消息(包含DigestAKA challenge)中携带RAND和AUTN发给给UE，并将认证方法标识放在payload信息中。

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

步骤1205：该UE发送HTTP request消息给该EAC，其中包含有DigestAKA response以及经由RES计算的摘要值。

步骤1206：该EAC验证所述摘要值的正确性，以认证该UE的合法性。

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

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

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

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

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

步骤1301：SP向EAC发送认证请求，该认证请求中携带该SP的公开身份标识(UID)。

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

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

步骤1303：该EAC向该SP发起Hello Request消息，该消息携带认证方法标识(本实施例中为证书TLS认证的标识)以及安全等级标识。

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

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

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

如果该Session ID字段为空或上述Finished消息有误，则该EAC根据本地策略配置消息中的参数，依次返回Server certificate消息、ServerKeyExchenge消息(可选)、CertificateRequest消息。最后，EAC返回ServerHelloDone消息，表示ServerHello以及相关消息已发送完毕。

步骤1307：该SP在收到ServerHelloDone消息后，返回Certificate消息，然后发送ClientKeyExchange消息，通过这条消息双方获得了共享秘密参数。然后，该SP发送CertifiicateVerify消息给EAC，便于其清楚地验证该SP的证书。最后，在发送了ChangeCipherSpec消息后该SP立即发送Finished消息给该EAC，用于正式密钥交换和验证过程的成功。

步骤1308：该EAC验证该SP的Finished消息中的信息是否正确，如果不正确，则中止当前握手过程；如果正确，则返回另一Finished消息给该SP。如果该SP验证该Finished消息中的信息正确，那么双方认证和密钥交换过程成功结束。

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

基于上述本发明方法，本发明还提出了一种实体认证装置。图14为本发明认证装置一实施例的结构图。参见图14，该实体认证装置包括：认证请求发送模块、协商模块和认证交互模块。

其中，认证请求发送模块用于为业务实体向实体认证中心发送认证请求，该认证请求的内容包括该业务实体的身份标识；协商模块用于在收到认证请求后，为该实体认证中心根据其本地策略选择一种认证方法，并向该业务实体发送认证初始化消息；认证交互模块用于该业务实体与实体认证中心之间基于所选认证方法进行认证交互。这些模块实现具体功能的原理在前述方法流程中均有描述，这里不再赘述。

在上述认证方法的基础之上，本发明还提出了一种增强方案，包括：首先定义认证模式，该认证模式从整体上对实体认证和认证查询流程做了定义，包括：业务实体与实体认证中心之间的认证方法、业务实体之间的认证方法及会话密钥的生成方法等。该认证方法简述如下：

一、首先定义认证模式

可定义E2E认证模式，其主要由SS与EAC的认证方法决定，有时也由SS与SP的认证方法决定。在该认证模式中可设定：SS和EAC的认证方法、SP和EAC的认证方法、EAC提供认证查询的方法及衍生密钥的生成方法、SS和SP之间的认证方法以及会话密钥生成方法。其中，针对某些情况所定义的认证模式中可以只设定上述认证方法中的一种或者几种。例如，在SS和SP可以直接认证并建立安全连接的情况下，无需进行SS和EAC及SP和EAC的认证，则针对此种情况定义的认证模式中只需设定SS和SP之间的认证方法以及会话密钥生成方法。

认证模式中还可设定每种认证方法的选择策略，其中包括该认证方法是否可选或必选以及该认证方法是否可以协商。

本发明可采用的端到端(E2E，End to End)认证模式有如下几种：

E2E_3GPP_AKA，E2E_3GPP2_AKA，E2E_3GPP2_CAVE，E2E_WLAN，E2E_3GPP2_MNAAA，E2E_3GPP_WLAN，E2E_Kerberos，E2E_Mediation，E2E_TLS(但认证模式的定义并不限于这几种，还可以根据需要进行新的定义)。如下列出这几种认证模式的定义实例。

1、E2E_3GPP_AKA模式定义如下：

E2E_3GPP_AKA::＝struct{

SS<->EAC认证方法    AKA，

                    承载协议HTTP Digest

SP<->EAC认证方法    TLS方法(或IPSec通道等方法)

SS<->SP的认证方法   基本查询方法

                    承载协议TLS(或其他)

会话密钥生成方法    是自定义的(或其他，可选)。}

2、E2E_3GPP2_CAVE模式的定义如下：

E2E_3GPP2_CAVE::＝struct{

SS<->EAC认证方法    Authentication based on CAVE，

                    承载协议HTTP Digest

SP<->EAC认证方法    TLS方法(或IPSec通道等方法)

SS<->SP的认证方法   基本查询方法

                    承载协议TLS(或其他)

会话密钥生成方法    是自定义的(或其他，可选)。}

3、E2E_WLAN::＝struct{

SS<->EAC认证方法  AKA(或SIM)，

                  承载协议EAP(Extensible AuthenticationProtocol)可扩展认证协议

SP<->EAC认证方法  TLS方法(或IPSec通道等方法)

SS<->SP的认证方法 基本查询方法

                  承载协议TLS(或其他)

会话密钥生成方法  是自定义的(或其他，可选)。}

4、E2E_Kerberos模式的定义如下：

E2E_Kerberos::＝struct{

SS<->EAC认证方法(可协商，如AKA，基于CAVE的认证，基于证书的认证)

SP<->EAC认证方法IPSec通道(或其他，可选)

SS<->SP的认证方法Kerberos(必选，可协商采用那种Kerberos或Kerberos改进方案)

承载协议TCP(或其他)

会话密钥生成方法TLS-Krb5(或其他，可选)}

5、E2E_TLS模式的定义如下：

E2E_TLS::＝struct{

SS<->EAC认证方法  无

SP<->EAC认证方法  无

SS<->SP的认证方法 TLS

会话密钥生成方法TLS-PSK(或其他，可选)}

6、E2E_3G_GAA模式的定义如下：

SS与EAC的认证方法为：SIM，AKA，CAVE，MN-AAA Key，TLS-PSK，TLS-Cert等方法中之一；

SP和EAC互认证方法为：TLS，IKE；

认证查询和衍生密钥生成方法为：GBA；

SS与SP的互认证方法为：TLS-PSK，TLS-Cert。

7、E2E_KERBEROS模式的定义如下：

SS与EAC的认证方法为：同E2E_3G_GAA，但在认证成功后EAC生成并发送SGT给业务实体；

SP和EAC互认证方法为：NULL，TLS，IKE；

认证查询和衍生密钥生成方法为：Kerberos；

SS与SP的互认证方法为：NULL，TLS-KBR5。

8、E2E_Mediation模式的定义如下：

SS与EAC的认证方法为：同E2E_3G_GAA，还可以是IKE；

SP和EAC互认证方法为：同E2E_3G_GAA；

认证查询和衍生密钥生成方法为：Mediation；

SS与SP的互认证方法为：TLS-PSK。

9、E2E_TLS模式的定义如下：

SS与EAC的认证方法为：NULL；

SP和EAC互认证方法为：NULL；

认证查询和衍生密钥生成方法为：NULL；

SS与SP的互认证方法为：TLS-Cert，TLS-PSK。

上述模式还可以根据业务需求进行新的认证方法设定，本发明对于认证模式所限定的具体认证方法、选择策略、密钥生成方法均不作限定。

图15所示为本发明一实施例中业务签约者与认证中心间的认证流程图。参见图15，本实施例中，3GPP网络中的移动用户UE使用Internet中的应用服务器(该服务器支持Kerberos认证协议)所提供的业务，具体过程如下：

步骤1501：SS(即UE)向实体认证中心(EAC)发送业务请求，该业务请求中携带用户UE的身份标识、认证能力标识、业务类型；该业务请求也可以不携带业务类型，而携带业务提供者(SP)的公开身份标识(UID)以使EAC通过该UID到实体签约数据库(ESD)中查找相应的业务类型。

步骤1502：该EAC根据业务请求中的身份标识，并综合该SS以及SP的认证能力信息采用本地策略选取认证模式以及相应的认证方法。本实施例中设定选取的是E2E_Kerberos模式。

该EAC能根据认证模式中认证方法的选择策略及本地策略确定每一种认证方法。其中，本地策略可以为：SS和SP依据双方的认证能力以及业务类型等选取互认证方法以及会话密钥生成方法；由该SS和SP的互认证方法决定是否进行该SP与EAC的互认证，如果需要互认证则根据该SP和EAC的认证能力以及业务类型等选取认证方法。

步骤1503：根据E2E_Kerberos模式的定义，该SS与EAC认证方法为可协商，则依据本地策略(即双方的认证能力以及双方要进行的业务类型等)选择认证方法，本实施例设定中选择了AKA认证方法。其中，该SP与EAC的认证方法被设为IPSec通道或其他，并且可选，本实施例中设定选取为空，即不进行SP与EAC的认证。该SS与SP的认证方法被设为Kerberos，则可协商采用Kerberos或Kerberos改进方案，也可以协商承载协议为TCP或其他。本实施例中设定依据双方的认证能力以及业务类型等经过协商选取该SS与SP的认证方法为Kerberos且承载协议为TLS-Krb5。另外，会话密钥生成方法被设为TLS-Krb5或其他，且可选，本实施例中设定选取会话密钥生成方法为TLS-Krb5。

根据上述选定的各种认证方法，可以开始进行该SS和EAC之间的认证。如果该SS和EAC已经进行过AKA的互认证并且所生成的共享密钥和中间业务请求标识(ISR-ID)仍在有效期内，则不用执行该AKA的互认证步骤，直接跳到步骤209以生成业务许可票据(SGT)。

步骤1504：该EAC从ESD中获取用户的认证向量(RAND，AUTN，RES，CK，IK)。

步骤1505：该EAC在HTTP的401消息(含有gestAKA chanllenge)中携带RAND和AUTN并发送给该UE，并将认证方法标识a放在payload信息中。

步骤1506：该UE计算并检验所收到的AUTN的正确性，以确认所述changllenge消息是否来自一个被授权的网络，同时该UE计算CK、IK和RES。

步骤1507：该UE发送HTTP request消息给该EAC，其中包含有Digest AKA response以及经由RES计算的摘要值。

步骤1508：该EAC验证计算的摘要值的正确性，用以认证该UE的合法性。

步骤1509：该EAC生成共享密钥Ks＝CK||IK，以及中间业务请求标识(ISR-ID)，然后利用共享密钥(Ks)、该SS的身份标识以及该SP的UID生成衍生密钥(Ksp)，并将所生成的衍生密钥放在业务许可票据(SGT)中，该票据的内容包括：衍生密钥(Ksp)、SS的ISR-ID、SP的UID、有效期、防重放攻击参数等，并且该票据经由EAC与SP的共享密钥加密。

步骤1510：该EAC发送200OK消息给UE，表示认证成功结束，该200OK消息中包含共享密钥的有效期、ISR-ID以及经由共享密钥Ks加密的业务许可票据(SGT)。

步骤1511：该UE也生成共享密钥Ks＝CK||IK以及衍生密钥Ksp，然后解密获得上述200OK消息中的ISR-ID、有效期以及业务许可票据(SGT)，并将解密得到的这些信息连同认证模式信息关联保存在本地。

图16所示为本发明一实施例中业务签约者与业务提供者间的互认证流程图。参见图16，业务签约者(SS)与业务提供者(SP)间进行互认证，具体过程如下：

步骤1601：SS向SP发送ClientHello消息，该消息中携带该SP的公开身份标识(UID)、该SS所支持的TLS-KRB5加密套件、以及认证模式E2E_Kerberos的相应信息。

所谓认证模式E2E_Kerberos的相应信息指该E2E_Kerberos模式中定义的SS与SP的认证方法和会话密钥生成方法。

步骤1602：该SP收到该Client Hello消息后，发现Session ID字段为空，则选择双方都支持的TLS-KRB5加密套件，先后发送ServerRequest消息ServerHello和ServerHelloDone消息给该SS。

步骤1603：收到该ServiceHelloDone消息后，该SS向该SP发送ClientKeyExchange消息，通过这条消息双方获得预共享秘密参数(PreMasterSecret)；该SS利用该PreMasterSecret以及随机数生成会话密钥(MasterSecret)；然后，该SS在发出ChangeCipherSpec消息并随后发送Finished消息给该SP，用于正式密钥交换和验证。

步骤1604：该SP解密业务许可票据(SGT)并检验票据的有效性，获得共享衍生密钥(Ksp)，并利用共享衍生密钥(Ksp)解密该PreMasterSecret，然后由该PreMasterSecret以及随机数等生成该SS和SP的会话密钥(MasterSecret)；然后该SP验证该SS的Finished消息中的信息是否正确，如果不正确，结束本流程；否则执行步骤1605。

步骤1605：该SP发送ChangeCipherSpec消息给该SS并随后将Finished消息返回给该SS。

步骤1606：该SS验证该来自SP的Finished消息中的信息的正确性，如果该SS验证该Finished消息的信息正确，那么双方的认证和密钥交换过程成功结束。

步骤1607：该SS和SP开始传输业务通信数据。

当上述流程所建立的会话没有过期时，若SS再次向SP发送业务请求，则可以重用上次会话生成的PreMasterSecret来生成本次业务通信的新的会话密钥(MasterSecret)。

图17所示为本发明一实施例中业务签约者与业务提供者重新利用认证结果生成会话密钥的流程图。参见图17，具体流程如下：

步骤1701：SS向SP发送Client Hello消息，并携带上次会话的Session ID。

步骤1702：该SP收到该Client Hello消息后，发现Session ID不为空，且能够匹配到相关联的安全连接信息，则重用该Session ID来标识会话，并向该SS发送ServerHello消息，该消息携带该Session ID，然后发送ServerHelloDone消息给该SS。

步骤1703：该SS利用与该SP共享的PreMasterSecret生成会话密钥(MasterSecret)。

步骤1704：该SS向该SP发送ChangeCipherSpec消息，并随后发送Finished消息给该SP。

步骤1705：该SP检验接收到的Finished消息无误后，利用同样的PreMasterSecret生成会话密钥(MasterSecret)。

步骤1706：该SP发送ChangeCipherSpec消息给该SS，并随后返回Finished消息给该SS。

步骤1707：如果该SS收到的Finished消息无误，则双方互认证结束，开始传输本次业务通信数据。

根据上述基于认证模式的实体认证增强方案，本发明实施例还提出了另一种实体认证装置。该装置与图14所示装置类似。图18所示为本发明实施例端到端通信认证装置一实施例的结构示意图。参见图18，该实体认证装置包括：发送模块(类似图14中的认证请求发送模块)，用于为业务实体(SS或SP)向实体认证中心发送认证请求；选择模块(类似图14中的协商模块)，用于按发送模块发送的认证请求，为实体认证中心选择认证模式并通知业务实体；认证模块(类似图14中的认证交互模块)，用于业务实体和实体认证中心之间或业务实体之间根据选择模块所选择的认证模式进行认证。这些模块实现具体功能的原理在前述方法流程中均有描述，这里不再赘述。

当然，本发明实施例还能提供一种实体认证装置，能够实现前述两种装置的功能，该种装置可包括：第一模块，用于实现前述发送模块和认证请求发送模块的功能；第二模块，用于实现选择模块和协商模块的功能；第三模块，用于实现认证模块和认证交换模块的功能。这里就不再对此装置做进一步详述。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所做的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (24)

1.一种基于移动网络端到端通信的认证方法，应用于包括：请求业务的第一业务实体、提供业务的第二业务实体和实体认证中心的系统，其特征在于，该方法包括：

所述第一业务实体与所述实体认证中心协商认证模式，该协商得到的认证模式包括：该第一业务实体与实体认证中心之间的认证方法、该第二业务实体与该实体认证中心之间的认证方法、该实体认证中心的认证查询方法及衍生密钥生成方法、以及该第一业务实体与该第二业务实体之间的互认证方法；

所述第一业务实体和第二业务实体分别按协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证；

当第一业务实体请求第二业务实体提供的业务时，所述实体认证中心按该协商得到的认证模式中定义的认证查询方法为该第一业务实体和第二业务实体提供认证查询并按该协商得到的认证模式中定义的衍生密钥生成方法生成二者之间的共享衍生密钥；

该第一业务实体和第二业务实体使用所述共享衍生密钥按该协商得到的认证模式中定义的二者之间的互认证方法进行互认证并生成保护本次业务的会话密钥。

2.根据权利要求1所述的方法，其特征在于，所述第一业务实体与所述实体认证中心协商认证模式，包括：

该第一业务实体向实体认证中心发送认证请求，该请求携带该第一业务实体的身份信息和当前请求的业务类型；

该实体认证中心按当前请求的业务类型确定提供该业务的第二业务实体，获取该第一业务实体和第二业务实体的认证能力，并按二者的认证能力选择认证模式。

3.根据权利要求1所述的方法，其特征在于，所述认证模式进一步定义：该第一业务实体和第二业务实体之间会话密钥的生成方法，

该第一业务实体和第二业务实体生成保护本次业务的会话密钥，包括：按协商得到的认证模式中定义的会话密钥生成方法生成所述会话密钥。

4.根据权利要求1所述的方法，其特征在于，所述业务实体按协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证，包括：该业务实体与实体认证中心按所述认证方法进行相互认证并获得用于保护与该实体认证中心通信的共享密钥材料，该实体认证中心为该业务实体分配临时身份信息，该实体认证中心和该业务实体分别将所分配的临时身份信息和所获得的共享密钥材料关联保存；

所述实体认证中心为该第一业务实体和第二业务实体提供认证查询并生成所述共享衍生密钥，包括：

该实体认证中心按该第一和第二业务实体的临时身份信息分别对该第一和第二业务实体的权限进行认证，使用自身与该第一业务实体之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到用于保护第一和第二业务实体之间通信的共享衍生密钥，并返回该共享的衍生密钥给该第二业务实体；该第二业务实体关联保存该第一业务实体的临时身份信息、该共享的衍生密钥和当前请求的业务类型；该第一业务实体使用自身与该实体认证中心之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到该共享的衍生密钥。

5.根据权利要求4所述的方法，其特征在于，所述共享衍生密钥、共享密钥材料和临时身份信息具有有效期；该方法进一步包括：

当所述实体认证中心发现自身与所述第一和/或第二业务实体的共享密钥材料或该第一和/或第二业务实体的临时身份信息快过期或已过期时，则指示该第一和/或第二业务实体发起重认证过程；和/或，

当所述第一和/或第二业务实体发现自身与所述实体认证中心的共享密钥材料或自身的临时身份信息快过期或已过期时，则向该实体认证中心发起重认证过程；和/或，

当所述实体认证中心发现所述第一和第二业务实体之间的共享衍生密钥快过期或已过期时，则指示该第一业务实体发起重认证过程；和/或，

当所述第二业务实体发现自身与第一业务实体的共享的衍生密钥或该第一业务实体的临时身份信息快过期或已过期时，则指示该第一业务实体发起重认证过程。

6.一种业务实体认证方法，应用于业务实体和实体认证中心之中，其特征在于，该方法包括：

所述业务实体向所述实体认证中心发送认证请求，该请求携带该业务实体的身份信息和当前请求的业务类型；

该实体认证中心按当前请求的业务类型确定提供业务的业务实体，获取该业务实体和提供该业务的业务实体的认证能力，并按二者的认证能力选择认证模式，该认证模式至少用于定义：该业务实体与实体认证中心之间的认证方法；

该业务实体按协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证。

7.根据权利要求6所述的方法，其特征在于，所述获取该业务实体和提供业务的业务实体的认证能力，包括：

该请求业务的业务实体在所述认证请求中携带自身的认证能力，该实体认证中心在确定该提供业务的业务实体后按其身份信息查询签约数据得到该提供业务的业务实体的认证能力；或者，

该实体认证中心按该请求业务的业务实体的身份信息查询签约数据得到其认证能力，在确定该提供业务的业务实体后按其身份信息查询签约数据得到该提供业务的业务实体的认证能力。

8.根据权利要求6所述的方法，其特征在于，所述业务实体按协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证，包括：该业务实体与实体认证中心按所述认证方法进行相互认证并获得用于保护与该实体认证中心通信的共享密钥材料，该实体认证中心为该业务实体分配临时身份信息，该实体认证中心和该业务实体分别将所分配的临时身份信息和所获得的共享密钥材料关联保存。

9.根据权利要求8所述的方法，其特征在于，所述共享密钥材料和临时身份信息具有有效期；该方法进一步包括：

当所述实体认证中心发现自身与所述业务实体的共享密钥材料或该业务实体的临时身份信息快过期或已过期时，则指示该业务实体发起重认证过程；和/或，

当所述业务实体发现自身与所述实体认证中心的共享密钥材料或自身的临时身份信息快过期或已过期时，则向该实体认证中心发起重认证过程。

10.一种认证查询方法，应用于包括：用于请求业务的第一业务实体、用于提供业务的第二业务实体和实体认证中心的系统；所述第一业务实体和第二业务实体分别与所述实体认证中心进行互认证，该实体认证中心分别为该第一业务实体和第二业务实体分配临时身份信息，并分别获得自身与该第一业务实体和第二业务实体之间的共享密钥材料；其特征在于，所述第一业务实体与所述实体认证中心协商认证模式，该认证模式至少用于定义该实体认证中心的认证查询方法及衍生密钥生成方法，该方法包括：

当第一业务实体请求第二业务实体提供的业务时，所述实体认证中心使用协商得到的认证模式中定义的认证查询方法、按该第一业务实体和第二业务实体的临时身份信息对二者权限进行认证；

使用该协商得到的认证模式中定义的衍生密钥生成方法、以及该第一业务实体和第二业务实体的临时身份信息和该第一业务实体的共享密钥材料，计算得到用于保护该第一业务实体和第二业务实体之间通信的共享衍生密钥。

11.根据权利要求10所述的方法，其特征在于，该方法包括：

该实体认证中心使用协商得到的认证模式中定义的认证查询方法、按该第一和第二业务实体的临时身份信息分别对该第一和第二业务实体的权限进行认证；使用该协商得到的认证模式中定义的衍生密钥生成方法、以及自身与该第一业务实体之间的共享密钥材料以及该第一和第二业务实体的临时身份信息，计算得到用于保护第一和第二业务实体之间通信的共享衍生密钥，并返回该共享的衍生密钥给该第二业务实体；

该第二业务实体关联保存该第一业务实体的临时身份信息、该共享的衍生密钥和当前请求的业务类型；

该第一业务实体使用自身与该实体认证中心之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到该共享的衍生密钥。

12.根据权利要求10所述的方法，其特征在于，该方法包括：

该第一业务实体在向该第二业务实体请求业务时，提供自身的临时身份信息；

该第二业务实体将自身的临时身份信息和该第一业务实体的临时身份信息提供给该实体认证中心；

该实体认证中心按该第一和第二业务实体的临时身份信息对二者的权限进行认证，使用自身与该第一业务实体之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到用于保护第一和第二业务实体之间通信的共享衍生密钥，并返回该共享的衍生密钥给该第二业务实体；

该第二业务实体关联保存该第一业务实体的临时身份信息、该共享的衍生密钥和当前请求的业务类型；

该第一业务实体使用自身与该实体认证中心之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到该共享的衍生密钥。

13.根据权利要求10所述的方法，其特征在于，该方法包括：

该第一业务实体在向所述实体认证中心请求业务许可票据时，提供自身的临时身份信息和当前请求的业务类型；

该实体认证中心按该第一业务实体的临时身份信息对其权限进行认证，根据当前请求的业务类型得到所述第二业务实体的临时身份信息，并按此临时身份信息对该第二业务实体的权限进行认证，使用自身与该第一业务实体之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到用于保护第一和第二业务实体之间通信的共享的衍生密钥，产生包含该衍生密钥、该第一业务实体和第二业务实体的临时身份信息的业务许可票据并发送至该第一业务实体；

该第一业务实体使用自身与该实体认证中心之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到该共享的衍生密钥，并在向该第二业务实体请求业务时，提供该业务许可票据；

该第二业务实体从该业务许可票据中得到自身与该第一业务实体之间的共享的衍生密钥，并关联保存该第一业务实体的临时身份信息、该共享的衍生密钥和当前请求的业务类型。

14.根据权利要求10所述的方法，其特征在于，该方法包括：

该第一业务实体向所述实体认证中心提出业务请求，并提供自身的临时身份信息和当前请求的业务类型；

该实体认证中心按该第一业务实体的临时身份信息对其权限进行认证，按当前请求的业务类型转发业务请求至该第二业务实体；

该第二业务实体向该实体认证中心返回自身的临时身份信息；

该实体认证中心按该第二业务实体的临时身份信息对该第二业务实体的权限进行认证，使用自身与该第一业务实体之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到用于保护第一和第二业务实体之间通信的共享的衍生密钥并发送至该第二业务实体；

该第二业务实体关联保存该第一业务实体的临时身份信息、该共享的衍生密钥和当前请求的业务类型；

该第一业务实体使用自身与该实体认证中心之间的共享密钥材料以及该第一和第二业务实体的临时身份信息计算得到该共享的衍生密钥。

15.根据权利要求10至14中任一项所述的方法，其特征在于，当所述实体认证中心返回该共享的衍生密钥给该第二业务实体时，进一步包括：使用自身与该第二业务实体之间的共享密钥材料进行通信保护。

16.一种基于移动网络端到端通信的认证系统，包括：用于请求业务的第一业务实体、用于提供业务的第二业务实体和实体认证中心；其特征在于，

所述第一业务实体用于与所述实体认证中心协商认证模式，该认证模式用于定义与认证相关的方法，按协商得到的认证模式的定义与该实体认证中心进行互认证，向所述第二业务实体请求业务，按该协商得到的认证模式的定义、使用与该第二业务实体之间的共享衍生密钥与该第二业务实体进行互认证；

所述第二业务实体用于按该协商得到的认证模式的定义与该实体认证中心进行互认证，在该第一业务实体请求业务时按该协商得到的认证模式的定义、使用与该第二业务实体之间的共享衍生密钥与该第一业务实体进行互认证；

所述实体认证中心用于按该协商得到的认证模式的定义分别与该第一业务实体和第二业务实体进行互认证，在该第一业务实体请求业务时按该协商得到的认证模式的定义为该第一业务实体和第二业务实体提供认证查询并生成二者的共享衍生密钥。

17.根据权利要求16所述的系统，其特征在于，该系统进一步包括：用于保存业务实体签约数据的数据库；

该实体认证中心在协商认证模式时，进一步用于按所述第一业务实体和第二业务实体的身份信息查询该数据库得到该第一业务实体和第二业务实体的认证能力，并按二者的认证能力选择所述认证模式。

18.根据权利要求16所述的系统，其特征在于，

所述实体认证中心在分别与第一业务实体和第二业务实体进行互认证时，分别为该第一业务实体和第二业务实体分配临时身份信息，并分别获得自身与该第一业务实体和第二业务实体之间的共享密钥材料；在为该第一业务实体和第二业务实体提供认证查询时，使用该第一业务实体和第二业务实体的临时身份信息和该第一业务实体的共享密钥材料、按所述协商得到的认证模式的定义，计算得到用于保护该第一业务实体和第二业务实体之间通信的共享衍生密钥并返回给该第二业务实体；

该第一业务实体在请求业务时使用自身的共享密钥材料和临时身份信息、该第二业务实体的临时身份信息、按所述协商得到的认证模式的定义，计算得到共享衍生密钥；

该第二业务实体进一步用于关联保存该第一业务实体的临时身份信息、所收到的共享衍生密钥和当前第一业务实体请求的业务类型。

19.一种业务实体认证系统，包括业务实体和实体认证中心；其特征在于，该系统进一步包括：用于保存业务实体签约数据的数据库；

所述业务实体用于与实体认证中心协商认证模式，该认证模式至少用于定义该业务实体与该实体认证中心之间的认证方法，该业务实体使用协商得到的认证模式中定义的认证方法与该实体认证中心进行互认证；

所述实体认证中心用于，在协商认证模式时，按所述请求业务的业务实体和所述提供业务的业务实体的身份信息查询该数据库得到这两个业务实体的认证能力，并按二者的认证能力选择认证模式。

20.一种认证查询系统，包括：用于请求业务的第一业务实体、用于提供业务的第二业务实体和实体认证中心，其特征在于，所述第一业务实体与所述实体认证中心协商认证模式，该认证模式至少用于定义该实体认证中心的认证查询方法及衍生密钥生成方法；

所述实体认证中心用于在所述第一业务实体请求业务时使用协商得到的认证模式中定义的认证查询方法对该第一业务实体和所述第二业务实体的权限进行认证，并使用该协商得到的认证模式中定义的衍生密钥生成方法生成二者共享的衍生密钥。

21.根据权利要求20所述的系统，其特征在于，

所述实体认证中心用于按所述第一业务实体和第二业务实体的临时身份信息对该第一业务实体和第二业务实体的权限进行认证，使用第一业务实体的共享密钥材料、该第一业务实体和第二业务实体的临时身份信息计算得到共享的衍生密钥并返回给该第二业务实体；

所述第一业务实体用于按自身的共享密钥材料和临时身份信息、以及该第二业务实体的临时身份信息计算得到所述共享的衍生密钥；

所述第二业务实体用于关联保存该第一业务实体的临时身份信息、该共享的衍生密钥和当前请求的业务类型。

22.一种认证中心，其特征在于，包括：

第一单元，用于协商业务实体的认证模式，该认证模式至少用于定义：业务实体与实体认证中心之间的认证方法；所述第一单元包括：

第一模块，用于查询签约数据分别得到请求业务的业务实体和提供业务的业务实体的认证能力；

第二模块，用于按所述第一模块得到的该请求业务的业务实体和提供业务的业务实体的认证能力选择一种认证模式；

第二单元，用于按所述第一单元协商得到的认证模式中定义的认证方法与所述业务实体进行互认证。

23.根据权利要求22所述的认证中心，其特征在于，所述认证模式进一步用于定义：所述实体认证中心的认证查询方法及衍生密钥生成方法；该认证中心进一步包括：

第三单元，用于在业务实体请求业务时使用所述协商得到的认证模式中定义的认证查询方法和衍生密钥生成方法为该请求业务的业务实体和提供业务的业务实体提供认证查询并生成二者的共享衍生密钥。

24.根据权利要求23所述的认证中心，其特征在于，

所述第二单元用于生成业务实体的共享密钥材料和临时身份信息；

所述第三单元用于使用该第二单元生成的共享密钥材料、所述请求业务的业务实体及提供业务的业务实体的临时身份信息计算得到该请求业务的业务实体和该提供业务的业务实体之间的共享衍生密钥。

Images