CN1878169A - 通用引导框架中Ub接口信息交互方法 - Google Patents

Abstract

本发明涉及通信技术，公开了一种通用引导框架中Ub接口信息交互方法，使得Ub接口上B－TID的安全保护问题得到解决，并支持前后版本的兼容。本发明中，UE与BSF间通过安全能力协商建立安全联盟，使用安全联盟传递B－TID等信息。安全联盟的协商信息在原AKA协商消息中的指定参数或头域中传递。

Description

通用引导框架中Ub接口信息交互方法

技术领域

本发明涉及通信技术，特别涉及通用引导框架中Ub接口信息交互方法。

背景技术

随着移动通信业务的迅猛发展，移动数据和多媒体通信的应用将越来越广泛，在不久的将来，甚至将超过传统的话音成为移动通信承载的主要业务。而传统的第二代全球移动通信***(Global System for mobileCommunication，简称“GSM”)移动通信网络已无法适应这种新的发展趋势，为此，GSM将逐步过渡到第三代移动通信***。其中，第三代合作伙伴项目(3rd Generation Partnership Project，简称“3GPP”)所规范的宽带码分多址(Wideband Code Division Multiple Access，简称“WCDMA”)/通用移动通信***(Universal Mobile Telecommunications System，简称“UMTS”)以其不断完善和成熟的技术标准，以其灵活的网络架构、平滑的演进模式、有效的投资等诸多优势，而逐渐发展成为第三代移动通信的主要技术，并为越来越多的移动通信运营商和设备提供商所接受。

在3GPP中定义的通用引导框架(Generic Bootstrapping Architecture，简称“GBA”)如图1所示，该架构由网际协议多媒体子***(IP MultimediaSubsystem，简称“IMS”)的用户设备(User Equipment，简称“UE”)、引导服务功能实体(Bootstrapping Server Function，简称“BSF”)、归属签约用户服务器(Home Subscriber Server，简称“HSS”)、签约定位功能(Subscription Locator Function，简称“SLF”)以及网络业务应用功能实体(Network Application Function，简称“NAF”)组成。UE与BSF通过Ub接口连接；UE与NAF通过Ua接口连接；BSF与HSS通过Zh接口连接，与NAF通过Zn接口连接，与SLF通过Dz接口连接。

其中，BSF用于在与UE执行的鉴权过程中相互验证身份，同时生成BSF与UE的共享密钥Ks；HSS是用户数据库，存储UE的签约数据和配置信息等，同时还兼有产生鉴权信息的功能；SLF用于当存在多个HSS时，协助BSF查找相应的HSS；NAF用于为UE提供相应的网络业务。

当UE需要使用某种业务时，在与该业务对应的NAF联系之前，需要先向BSF进行相互鉴权。如果UE知道使用该业务需要到BSF进行相互鉴权过程，则直接发送鉴权请求到BSF进行相互鉴权；如果UE不知道需要与BSF进行相互鉴权的过程，先向该业务对应的NAF联系时，若该NAF使用GBA，并且发现该UE还未到BSF进行互认证过程，则通知该UE到BSF进行相互鉴权以验证身份。

UE与BSF进行相互鉴权以验证身份的流程如图2所示。

在步骤210中，UE向BSF发出GBA请求消息，并在该消息中携带私有用户标识，请求鉴权。

在步骤220中，BSF通过与HSS的交互获取该UE的鉴权向量信息，包括验证序号(AUTN)、随机数(RAND)、完整性密钥(IK)、加密密钥(CK)以及期望结果(XRES)。

在步骤230中，BSF向UE返回响应消息，并在响应消息中包含RAND和AUTN。

在步骤240中，UE通过运行AKA(鉴权与密钥分配)算法，检查AUTN的有效性以鉴权网络，得到IK和CK，并生成结果信息(RES)。

在步骤250中，UE再次向BSF发送GBA请求消息，并在GBA请求消息中携带RES。

在步骤260中，BSF通过判断GBA请求消息中的RES是否与XRES一致，对UE进行鉴权。

在步骤270中，BSF根据IK和CK得到根密钥(Ks)，并为Ks定义一个有效期，以便Ks进行定期更新。

在步骤280中，BSF分配一个引导事务标识(B-TID)，用于标识BSF和UE之间的本次鉴权交互事务。所分配的B-TID要求与Ks、UE的私有用户标识相关联，以便以后BSF可以根据该B-TID查找出相应的Ks。然后BSF将B-TID和Ks的有效期限一起以明文的形式发送给UE。

在步骤290中，UE保存B-TID和Ks的有效期，同时也生成和BSF侧相同的共享Ks。

UE与BSF共享的Ks用于在UE与NAF进行通信时衍生出UE与NAF间的共享密钥Ks_NAF，使得UE与NAF之间建立起双方通信的安全联盟。

目前，在步骤280中如果以明文方式发送B-TID会导致一系列的问题：

如攻击者可以很容易地找到私有用户标识与B-TID的对应关系，从而对UE进行追踪，在UE与NAF通信时，寻找机会攻击特定UE的业务；

无法保证UE在与NAF交互时，以B-TID作为临时用户标识的隐私安全；

在访问网络运营商和归属网络运营商不是同一个的情况下，B-TID可能泄漏给访问网络运营商从而导致安全隐患等等。

为了解决这个问题，一个方案是UE在与BSF进行相互鉴权之前，先与BSF建立传输层安全(Transport Layer Security，简称“TLS”)隧道，使UE与BSF之间的相互鉴权过程都在TLS隧道中进行，并通过认证符号使UE和BSF在TLS隧道两端能够相互认证，以此保证B-TID在传输过程中不被泄漏。

但是，该方案的使用会导致UE与BSF进行相互鉴权以验证身份的引导过程中必须引入另外一种安全认证机制，增加了网络负荷，而且，由于TLS效率比较低，因此也将在一定程度上影响UE执行引导过程的效率。另外，由于UE与BSF通信时，无法获知对端的版本，因此，无法实现新旧版本的互通。

解决以明文方式发送B-TID而导致一系列问题的另一方案如图3所示。

步骤310对应步骤210。步骤320至步骤330对应步骤220。步骤340对应步骤230至260。在步骤350中，BSF分配一个B-TID，用于标识BSF和UE之间的本次鉴权交互事务。所分配的B-TID要求与Ks、UE的私有用户标识相关联，以便以后BSF可以根据该B-TID查找出相应的Ks。在步骤360中，BSF将该B-TID加密后，发送给UE。在步骤370中，UE将解密后的B-TID进行保存。在步骤380中，UE以B-TID作为临时用户标识，与BSF进行业务通信。

但是，由于该方案中UE与BSF间的交互并不是在安全隧道中进行，因此，在BSF将加密后的B-TID发送给UE的过程中，还是可能会遭受中间者的攻击，而UE在接收到该B-TID后，也无法识别该B-TID是否经过攻击者的伪造或篡改。另外，对B-TID加解密的方式和密钥需要预先设置在UE和BSF中，由于UE与BSF通信时，无法获知对端的版本(也就无法知道对端的加解密方式)，因此，同样无法实现新旧版本的互通。

发明内容

有鉴于此，本发明的主要目的在于提供一种通用引导框架中Ub接口信息交互方法，使得Ub接口上B-TID的安全保护问题得到解决，并支持前后版本的兼容。

为实现上述目的，本发明提供了一种通用引导框架中Ub接口信息交互方法，包含以下步骤：

A用户设备与引导服务器功能实体通过交互安全能力信息建立安全联盟；

B所述引导服务器功能实体使用所述安全联盟向所述用户设备发送消息，其中包含引导事务标识。

其中，所述用户设备与引导服务器功能实体之间的交互完成以后，删除所述安全联盟。

此外在所述方法中，所述步骤A中，所述安全能力信息使用安全机制列表的形式传递，其中包含安全协议、安全算法和相应的优先级。

此外在所述方法中，所述安全机制列表在通用引导架构的鉴权消息的指定参数或头域中传递。

此外在所述方法中，所述步骤A进一步包含以下子步骤：

A1所述用户设备向所述引导服务器功能实体发送通用引导框架请求消息，其中携带该用户设备所支持的安全机制列表；

A2所述引导服务器功能实体向所述用户设备回应挑战响应消息，其中携带该引导服务器功能实体所支持的安全机制列表；

A3所述用户设备根据所述挑战响应消息计算出相应的完整性密钥和加密密钥；所述用户设备和引导服务器功能实体选择一个双方都支持的、并且优先级最高的安全协议以及安全算法，建立安全联盟；

A4所述用户设备向所述引导服务器功能实体发送通用引导框架请求消息，其中携带协商后的安全机制列表；

A5所述引导服务器功能实体检查收到的协商后的安全机制列表中参数的有效性。

此外在所述方法中，在所述步骤A1和A2之间还包含以下步骤：

所述支持所述安全能力信息协商的引导服务器功能实体根据来自所述用户设备的通用引导框架请求消息中是否包含安全机制列表参数，来判断用户设备是否也支持所述安全能力信息协商。如果是则执行所述步骤A2至A5，否则执行普通通用引导架构的鉴权流程。

此外在所述方法中，在所述步骤A2和A3之间还包含以下步骤：

所述支持所述安全能力信息协商的用户设备根据来自所述引导服务器功能实体的失败响应消息，来判断引导服务器功能实体是否也支持所述安全能力信息协商。如果是则执行所述步骤A3至A5，否则执行普通通用引导架构的鉴权流程。

此外在所述方法中，在所述步骤A2和A3之间还包含以下步骤：

所述支持所述安全能力信息协商的用户设备根据来自所述引导服务器功能实体的挑战响应消息中是否携带安全机制列表参数，来判断引导服务器功能实体是否也支持所述安全能力信息协商。如果是则执行所述步骤A3至A5，否则执行普通通用引导架构的鉴权流程。

此外在所述方法中，所述步骤B中的消息为所述引导服务器功能实体向所述用户设备发送的成功响应消息，该消息中包含作为参数的引导事务标识和共享密钥有效期，该消息采用所述安全联盟中协商后的安全协议和安全算法及相应密钥加密；

所述用户设备通过所述安全联盟解密得到引导事务标识和共享密钥有效期，并保存该引导事务标识和共享密钥有效期。

此外在所述方法中，对所述消息采用所述安全联盟中协商后的安全协议和安全算法进行加密时，密钥为完整性密钥、或加密密钥、或完整性密钥与加密密钥的组合、或由完整性密钥和加密密钥计算得到的根密钥。

通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，UE与BSF间通过安全能力协商建立安全联盟，使用安全联盟传递B-TID等信息。

安全联盟的协商信息在原AKA协商消息中的指定参数或头域中传递。

这种技术方案上的区别，带来了较为明显的有益效果，即因为通过安全联盟传递B-TID等信息，而安全联盟中的加密方式是通过动态协商得到的，所以相对于现有技术中静态加密或不加密的方式，B-TID等信息被被伪造或篡改的机会大大减少。

因为通过原AKA协商消息携带安全联盟的协商信息，所以从UE和BSF间的交互流程上看并没有增加任何新的消息，对网络几乎没有增加额外负担。

因为安全联盟的协商信息在AKA协商消息的指定参数或头域中传递，所以支持上述安全能力协商机制的UE或BSF在AKA协商的初期，根据安全机制列表参数或头域是否存在，就可以方便地知道对端是否支持上述安全能力协商机制，从而可以在对端不支持上述安全能力协商机制时容易地回退到旧版本的交互方式，保护了用户和运营商的已有投资。

附图说明

图1是根据现有技术中3GPP定义的通用引导框架示意图；

图2是根据现有技术中UE执行鉴权过程的流程图；

图3是根据现有技术中UE在执行引导过程中对B-TID进行加密的流程图；

图4是根据本发明的第一实施方式通用引导框架中Ub接口信息交互的正常流程图；

图5是根据本发明的第二实施方式通用引导框架中Ub接口信息交互的新旧版本互通流程图；

图6是本发明的第三实施方式通用引导框架中Ub接口信息交互的新旧版本互通流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。

本发明的核心在于，UE通过在向BSF发送的GBA请求消息中携带该UE支持的安全机制列表，使得BSF获知该UE的安全能力信息。BSF通过在向UE发送的挑战响应消息中携带该BSF支持的安全机制列表，使得UE获知该BSF的安全能力信息。UE与BSF在获知对端的安全能力信息后建立起安全联盟，BSF对包含B-TID和Ks有效期的消息按照安全联盟中协商的安全协议、安全算法及相应密钥进行加密后，发送给UE。UE在接收到该消息后，使用安全联盟中协商的安全协议、安全算法及相应密钥进行解密，保存解密后的B-TID和Ks有效期。

为了不影响BSF与多个UE同时建立安全联盟时的性能，UE侧可在保存B-TID和Ks有效期后，删除与BSF之间建立的安全联盟。

对于支持上述安全能力协商机制的UE和BSF来说，由于安全机制列表参数是携带在GBA请求消息或挑战响应消息中。因此，支持上述安全能力协商机制的BSF可以通过GBA请求消息中是否携带安全机制列表参数，支持上述安全能力协商机制的UE可以通过挑战响应消息中是否携带安全机制列表参数或者失败响应消息，来获知对端是否支持上述安全能力协商机制，从而采用相应版本的协议，实现新旧版本的互通。

本发明的第一实施方式通用引导框架中Ub接口信息交互的方法如图4所示。在本实施方式中，UE与BSF都支持上述安全能力协商机制。

在步骤401中，UE向BSF发送GBA请求消息，并在该消息中携带私有用户标识以及UE的安全机制列表。具体地说，UE为了能与BSF建立安全联盟，需要将自身的安全能力信息传递给BSF，使BSF能够知道UE支持哪些安全协议、安全协议中的哪些算法以及它们相应的优先级。并且，通过将包含安全能力信息的安全机制列表携带在GBA请求消息中的指定参数或头域中，从而减少对网络增加的负担。比如说，通过将安全机制列表携带在类似于会话发起协议(Session Initation Protocol，简称“SIP”)的Require、Porxy-Requrie或Security-client等头域中，把UE的安全能力信息传递给BSF。

接着，进入步骤402中，BSF向HSS获取认证向量。本步骤与现有技术相同，BSF通过与HSS的交互获取该UE的鉴权向量信息，如AUTN、RAND、IK、CK以及XRES等。

接着，进入步骤403，BSF向UE返回挑战响应消息，该消息中包含AUTN、RAND以及BSF的安全机制列表。具体地说，BSF在接收到UE的鉴权向量信息后，将鉴权向量信息中的AUTN和RAND，连同BSF自身的安全机制列表一并携带在挑战响应消息中，并将该消息返回给UE。其中，AUTN用于验证BSF的身份，RAND用于使UE获取与BSF侧相同的IK和CK，BSF自身的安全机制列表用于使UE获知BSF的安全能力信息，包括BSF支持的安全协议、安全协议中的安全算法以及它们相应的优先级。BSF自身的安全机制列表可以携带在挑战响应消息中的指定参数或头域中，比如说，将安全机制列表携带在类似于会话发起协议(Session Initation Protocol，简称“SIP”)的Security-Server等头域中，把BSF的安全能力信息传递给UE。

接着，进入步骤404，UE通过运行AKA算法，检查AUTN的有效性以鉴权网络，得到IK和CK，并生成RES。具体地说，UE在接收到BSF返回的挑战响应消息后，通过对其中AUTN的有效性检查验证对端BSF的身份，根据其中的RAND计算得到与BSF侧相同的IK和CK，并生成RES。

接着，进入步骤405，UE与BSF建立安全联盟。由于UE和BSF双方都知道对端的安全能力信息，因此，可以选择一个双方都支持的、并且优先级最高的安全协议以及安全算法，建立安全联盟。比如说，BSF从UE携带在GBA请求消息中的安全机制列表获知UE支持的安全协议以及安全算法有A、B和C，并且A比B的优先级高，B比C的优先级高；UE从BSF携带在挑战响应消息中的安全机制列表获知BSF支持的安全协议以及安全算法有A、B和D，A比B的优先级高，B比D的优先级高。因此，UE和BSF通过协商，可以选择双方都支持的、并且优先级最高的安全协议以及安全算法A，并使用完整性密钥、或加密密钥、或完整性密钥与加密密钥的组合、或由完整性密钥和加密密钥计算得到的根密钥作为加密密钥，建立起安全联盟。

接着，进入步骤406，UE再次向BSF发送GBA请求消息，并在该消息中携带RES以及协商后的安全机制列表，协商后的安全机制列表可以携带在GBA请求消息中的指定参数或头域中。比如说，将协商后的安全机制列表携带在类似于会话发起协议(Session Initation Protocol，简称“SIP”)的Security-Client、Security-Verify等头域中。

其中，RES用于验证UE的身份；协商后的安全机制列表用于判断UE和BSF的安全机制列表在传递过程中是否遭受到中间人的攻击。

接着，进入步骤407，BSF检查协商后的安全机制列表参数的有效性。

接着，进入步骤408，BSF检查RES的有效性以鉴权UE。本步骤与现有技术相同，BSF通过判断GBA请求消息中的RES是否与从HSS处获取的XRES一致，从而对UE进行鉴权。

接着，进入步骤409，BSF根据从HSS处获取的IK和CK生成Ks。

接着，进入步骤410，BSF将B-TID以及Ks的有效期携带在成功响应消息中发送给UE。具体地说，BSF为标识和UE之间本次鉴权交互事务而分配一个B-TID，使该B-TID与Ks、UE的私有用户标识相关联，以便以后BSF可以根据该B-TID查找出相应的Ks，并且，为Ks定义一个有效期，以便Ks进行定期更新。BSF将该B-TID以及Ks的有效期携带在成功响应消息中，并采用安全联盟中协商后的安全协议和安全算法以及相应的加密密钥对该成功响应消息进行加密，将加密后的成功响应消息发送给UE。加密时，密钥为完整性密钥、或加密密钥、或完整性密钥与加密密钥的组合、或由完整性密钥和加密密钥计算得到的根密钥。

接着，进入步骤411，UE在接收到该成功响应消息后，通过安全联盟中协商后的安全协议和安全算法以及相应的加密密钥执行相应的解密操作，得到B-TID和Ks的有效期，并将该B-TID和Ks的有效期保存在UE侧。

接着，进入步骤412，删除UE与BSF间的安全联盟。如果BSF同时与多个UE建立安全联盟，则可能会对BSF的性能造成一定程度的影响。因此，在UE侧保存完B-TID，Ks的有效期等信息后，立即删除之前与BSF建立的安全联盟。

在本实施方式中，由于B-TID等信息是通过安全联盟传递给UE的，而安全联盟中的加密方式是通过动态协商得到的，因此，相对于现有技术中静态加密或不加密的方式，B-TID等信息被伪造或篡改的机会大大减少。另外，由于UE与BSF的安全能力信息是通过安全机制列表的形式携带在原AKA协商消息中传递给对方，所以，从UE和BSF间的交互流程上看并没有增加任何新的消息，对网络几乎没有增加额外负担。

需要说明的是，由于UE与BSF只要获知彼此的安全能力信息，即可完成相互间安全协议和安全算法的协商，建立安全联盟，因此，UE与BSF间的安全联盟可以立即建立在UE接收到BSF的挑战响应消息后，或者建立在UE接收到BSF的挑战响应消息后，BSF发送成功响应消息前的任何一个时刻，而不影响本发明的实质。

本发明的第二实施方式通用引导框架中Ub接口信息交互的方法如图5所示。在本实施方式中，UE是支持上述安全能力协商机制的新版本UE，而BSF是不支持上述安全能力协商机制的旧版本BSF。

在步骤501中，UE向BSF发送GBA请求消息，并在该消息中携带私有用户标识以及UE的安全机制列表。本步骤与步骤401完全相同，在此不再赘述。

在步骤502中，BSF向HSS获取认证向量。本步骤与步骤402完全相同。

在步骤503中，BSF向UE返回挑战响应消息。由于本实施方式中的BSF是不支持上述安全能力协商机制的旧版本BSF，因此，在挑战响应消息中仅包含AUTN以及RAND，不包含BSF的安全机制列表。

在步骤504中，UE接收到挑战响应消息后，发现该消息中不包含BSF的安全机制列表，从而得知该BSF为不支持上述安全能力协商机制的旧版本BSF，因此执行普通GBA的鉴权流程。也就是说，从步骤504至步骤509与现有技术完全相同，对应步骤240至步骤290。

由此可见，UE可以通过BSF返回的挑战响应消息获知对端是否支持上述安全能力协商机制。当对端不支持上述安全能力协商机制时，可以回退到现有技术中采用的鉴权流程，从而实现新旧版本的互通。

本发明的第三实施方式通用引导框架中Ub接口信息交互的方法如图6所示。在本实施方式中，UE是支持上述安全能力协商机制的新版本UE，而BSF是不支持上述安全能力协商机制的旧版本BSF。

在步骤601中，UE向BSF发送GBA请求消息，并在该消息中携带私有用户标识以及UE的安全机制列表。本步骤与步骤401完全相同。

在步骤602中，BSF向UE返回失败消息。由于BSF是不支持上述安全能力协商机制的旧版本BSF，因此，向UE返回一个“不支持该操作”或者其他失败响应，以通知UE网络侧的BSF不支持安全机制协商。

UE在得知网络侧的BSF不支持安全能力机制协商后，回退到现有技术中采用的鉴权流程，即重新发送一个不带“UE支持的安全机制列表”参数的请求消息给BSF，即执行普通GBA的鉴权步骤，即从步骤603至步骤611对应步骤210至步骤290。

由此可见，UE也可以通过BSF返回的失败消息获知对端为不支持安全能力协商机制，并回退到现有技术中采用的鉴权流程，重新发起鉴权请求，从而实现新旧版本的互通。

需要说明的是，当UE为不支持上述安全能力协商机制的旧版本UE，而BSF是支持上述安全能力协商机制的新版本BSF时，UE向BSF发送的GBA请求消息中仅包含私有用户标识，因此，BSF可以从GBA请求消息中携带的参数得知UE不支持安全能力协商机制，从而在之后执行的步骤中采用现有技术中的流程。也就是说，当UE为不支持上述安全能力协商机制的旧版本UE，而BSF是支持上述安全能力协商机制的新版本BSF时，UE与BSF间的鉴权流程与现有技术中的鉴权流程完全相同，从而实现新旧版本的互通。

虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (10)

1.一种通用引导框架中Ub接口信息交互方法，其特征在于，包含以下步骤：

A用户设备与引导服务器功能实体通过安全能力信息协商建立安全联盟；

B所述引导服务器功能实体使用所述安全联盟向所述用户设备发送消息，其中包含引导事务标识。

2.根据权利要求1所述的通用引导框架中Ub接口信息交互方法，其特征在于，所述用户设备与引导服务器功能实体之间的交互完成以后，删除所述安全联盟。

3.根据权利要求1所述的通用引导框架中Ub接口信息交互方法，其特征在于，所述步骤A中，所述安全能力信息使用安全机制列表的形式传递，其中包含安全协议、安全算法和相应的优先级。

4.根据权利要求3所述的通用引导框架中Ub接口信息交互方法，其特征在于，所述安全机制列表在通用引导架构的鉴权消息的指定参数或头域中传递。

5.根据权利要求4所述的通用引导框架中Ub接口信息交互方法，其特征在于，所述步骤A进一步包含以下子步骤：

A1所述用户设备向所述引导服务器功能实体发送通用引导框架请求消息，其中携带该用户设备所支持的安全机制列表；

A2所述引导服务器功能实体向所述用户设备回应挑战响应消息，其中携带该引导服务器功能实体所支持的安全机制列表；

A3所述用户设备根据所述挑战响应消息计算出相应的完整性密钥和加密密钥；所述用户设备和引导服务器功能实体选择一个双方都支持的、并且优先级最高的安全协议以及安全算法，建立安全联盟；

A4所述用户设备向所述引导服务器功能实体发送通用引导框架请求消息，其中携带协商后的安全机制列表；

A5所述引导服务器功能实体检查收到的协商后的安全机制列表中参数的有效性。

6.根据权利要求5所述的通用引导框架中Ub接口信息交互方法，其特征在于，在所述步骤A1和A2之间还包含以下步骤：

所述支持所述安全能力信息协商的引导服务器功能实体根据来自所述用户设备的通用引导框架请求消息中是否包含安全机制列表参数，来判断用户设备是否也支持所述安全能力信息协商；如果是则执行所述步骤A2至A5，否则执行普通通用引导架构的鉴权流程。

7.根据权利要求5所述的通用引导框架中Ub接口信息交互方法，其特征在于，在所述步骤A2和A3之间还包含以下步骤：

所述支持所述安全能力信息协商的用户设备根据来自所述引导服务器功能实体的失败响应消息，来判断引导服务器功能实体是否也支持所述安全能力信息协商；如果是则执行所述步骤A3至A5，否则执行普通通用引导架构的鉴权流程。

8.根据权利要求5所述的通用引导框架中Ub接口信息交互方法，其特征在于，在所述步骤A2和A3之间还包含以下步骤：

所述支持所述安全能力信息协商的用户设备根据来自所述引导服务器功能实体的挑战响应消息中是否携带安全机制列表参数，来判断引导服务器功能实体是否也支持所述安全能力信息协商；如果是则执行所述步骤A3至A5，否则执行普通通用引导架构的鉴权流程。

9.根据权利要求1至8中任一项所述的通用引导框架中Ub接口信息交互方法，其特征在于，所述步骤B中的消息为所述引导服务器功能实体向所述用户设备发送的成功响应消息，该消息中包含作为参数的引导事务标识和共享密钥有效期，该消息采用所述安全联盟中协商后的安全协议和安全算法及相应密钥加密；

所述用户设备通过所述安全联盟解密得到引导事务标识和共享密钥有效期，并保存该引导事务标识和共享密钥有效期。

10.根据权利要求9所述的通用引导框架中Ub接口信息交互方法，其特征在于，对所述消息采用所述安全联盟中协商后的安全协议和安全算法进行加密时，密钥为完整性密钥、或加密密钥、或完整性密钥与加密密钥的组合、或由完整性密钥和加密密钥计算得到的根密钥。

Images