本发明涉及3GPP通用鉴权框架(GAA)技术领域，特别是指一种用户(UE)和外围设备协商共享密钥的方法。

在第三代无线通信标准中，通用鉴权框架(GAA)是多种应用业务实体使用的一个用于完成对用户身份进行验证的通用结构，应用通用鉴权框架可实现对应用业务的用户进行检查和验证身份。上述多种应用业务可以是多播或广播业务、用户证书业务、信息即时提供业务等，也可以是代理业务。
图1示出了所述通用鉴权框架的结构。通用鉴权框架通常由用户(UE)、执行用户身份初始检查验证的实体(BSF)、用户归属网络服务器(HSS)和网络业务应用实体(NAF)组成。BSF用于与UE进行互验证身份，同时生成BSF与用户的共享密钥Ks；HSS中存储用于描述用户信息的描述(Profile)文件，同时HSS还兼有产生鉴权信息的功能。各个实体之间的接口可参见图1，本文中，可以将BSF、NAF及HSS统一称为网络侧。
用户需要使用某种业务时，如果用户知道该业务需要到BSF进行互鉴权过程，则直接到BSF进行互鉴权，否则，用户会首先和该业务对应的NAF联系，如果该NAF使用GAA通用鉴权框架，并且发现该用户还未到BSF进行互认证过程，NAF则通知该用户到BSF进行互鉴权以验证身份。
用户与BSF之间的GBA(互鉴权)的步骤包括：用户向BSF发出鉴权请求；BSF接到鉴权请求后，首先到HSS获取该用户的鉴权信息；BSF获得鉴权信息后采用HTTP digest AKA协议与用户进行双向认证以及密钥协商，完成用户和BSF之间身份的互相认证及共享密钥Ks的生成，BSF还为共享密钥Ks定义了一个有效期限，以便Ks进行定期更新。共享密钥Ks是作为根密钥来使用的，用于衍生出加密通信的密钥。
之后，BSF分配一个会话事务标识(B-TID)发送给用户，该B-TID与Ks相关联，可以用于标识Ks，还包含了Ks的有效期限。
用户收到B-TID后，重新向NAF发出连接请求，且请求消息中携带了该B-TID，同时用户侧根据Ks计算出衍生密钥Ks_NAF。
NAF收到连接请求后，先在本地查询是否有用户携带的该B-TID，如果NAF不能在本地查询到该B-TID，则向BSF进行查询，该查询消息中携带了NAF标识和B-TID。如果BSF不能在本地查询到该B-TID，则通知NAF没有该用户的信息，此时，NAF将通知用户到BSF重新进行认证鉴权。BSF查询到该B-TID后，使用与用户侧相同的算法计算出Ks的衍生密钥Ks_NAF，并向NAF发送成功的响应消息，该成功的响应中包括NAF所需的B-TID、与该B-TID对应的衍生密钥Ks_NAF、以及BSF为该密钥设置的有效期限。NAF收到BSF的成功响应消息后，就认为该用户是经过BSF认证的合法用户，同时NAF和用户也就共享了由Ks衍生的密钥Ks_NAF。
之后，NAF和用户在后续的通信过程中通过Ks_NAF来进行加密通信。
当用户发现Ks即将过期，或NAF要求用户重新到BSF进行鉴权时，用户就会重复上述的步骤重新到BSF进行互鉴权，以得到新的共享密钥Ks及衍生密钥Ks_NAF。
这里需要说明的是，对于GBA_ME过程，上述用户指的是移动设备(ME)；如果是GBA_U过程，上述用户指的是移动设备中的用户识别模块(UICC)，此时所述的生成的Ks_NAF包括两个衍生密钥：给UICC的Ks_int_NAF和给ME的Ks_ext_NAF。
随着网络技术的发展，以及市场需求的推动，网络融合已经成为人们关注的焦点。从未来发展的角度来看，多种网络融合对于用户来说，可使用任意终端(移动台、PDA、PC等)通过任意方式接入网络(WLAN、DSL、GPRS等)，而且号码可唯一、帐单可唯一。这就意味着一个用户可以具备多种终端设备，并且这些终端设备共享该用户的一个UE对应的用户消息，如UE的UICC(UICC上可以为SIM、USIM等)和ME对应的用户信息。
下面以共享UICC对应的用户信息为例进行描述：这种情况下，UICC卡固定的插入某一特定终端设备(比如手机或者其他读卡器)，而其它终端设备(也称外围设备)通过诸如USB，蓝牙或者红外线等本地接口连接到所述特定终端设备进行通信，来共享同一个UICC对应的用户信息。如图2示出了WLAN与3GPP融合，WLAN-UE使用UICC信息认证以接入WLAN的示意图。
如图3示出了图2对应的GAA架构，这种情况也称作NAF应用客户端与终端分离的情况，具体就是指：某个移动用户具备多个终端设备(除了手机以外，还具备其它终端设备如PC机，WLAN UE，掌上电脑等)，而这些终端采用同一个UE用户信息访问网络业务，NAF应用客户端并不在UE上，而是在UE以外的某一个或者某几个外围设备上，GBA客户端仍在UE上。
由于外围设备要使用UE用户信息进行认证以接入NAF，因此外围设备与UE之间的本地接口必定会传送一些诸如网络认证参数的密秘信息。但是，目前还没有较好的方法来保护这些信息，这是因为，由于用户购买UICC卡或UE时根本不能预料到底有哪些设备将会访问该UE，因此不可能在UE里预先保存与所有外围设备的共享密钥，由于和要传输信息的外围设备没有相应的保护密钥，因此难以对所述UE与外围设备之间的信息进行加密传输。

有鉴于此，本发明的主要目的在于提供了一种GAA框架下UE和外围设备协商通信共享密钥的方法，以解决外围设备与UE之间的本地接口的安全通信。
本发明提供的用户UE和外围设备协商共享密钥的方法，包括以下步骤：一种用户UE和外围设备协商共享密钥的方法，包括以下步骤：A、外围设备向UE发送连接请求，该连接请求中携带外围设备标志；
B、UE根据UE与执行用户身份初始检查验证的实体BSF的共享密钥Ks、所述外围设备标志计算出第一本地接口共享密钥；C、由网络侧根据所述UE与BSF的共享密钥Ks、获取的所述外围设备标志，计算出与第一本地接口共享密钥相同的第二本地接口共享密钥，并提供给外围设备。
步骤C后进一步包括：所述第一或第二本地接口共享密钥超过各自有效期限时，或共享密钥Ks更新后，返回步骤B。
步骤A中所述外围设备标志，用于所述UE识别不同的外围设备或者所述外围设备上的应用；所述外围设备标志为：在所述UE的用户识别模块UICC或移动设备ME中预先配置的与设备标识对应的索引值；或者，设备标识或应用标识自身；步骤B中所述UE与BSF的共享密钥Ks是UE与BSF执行互鉴权GBA过程生成的共享密钥。
步骤B进一步包括：所述UE提供给外围设备一个可用于标识所述共享密钥Ks的会话事务标识B-TID/与B-TID对应的索引值，并通过外围设备发送给所述网络侧中的网络业务应用实体NAF；步骤C所述共享密钥Ks，是所述网络侧根据获得的会话事务标识B-TID/与B-TID对应的索引值确定出的。
所述通过外围设备向所述NAF发送B-TID/与B-TID对应的索引值之前，该方法还包括：所述外围设备与所述NAF之间进行身份认证并建立安全连接。
步骤B进一步包括：所述UE将B-TID/与B-TID对应的索引值发送给所述网络侧中的网络业务应用实体NAF；步骤C所述共享密钥Ks，是所述网络侧根据获得的会话事务标识B-TID/与B-TID对应的索引值确定出的。
所述UE向NAF发送B-TID/与B-TID对应的索引值之前，该方法还包括：所述UE与所述NAF之间进行身份认证并建立安全连接。
步骤C中所述将计算出第二本地接口共享密钥提供给外围设备之前，该方法还包括：所述外围设备与所述NAF之间进行身份认证并建立安全连接。
所述身份认证为单向认证或双向认证；所述身份认证的方法为：利用公钥证书或私钥证书进行身份认证。
所述身份认证的方法具体为：利用共享密钥的基于预共享密钥的传输层安全协议PSK_TLS方式进行身份认证；或者基于共享密钥的http digest认证方式进行身份认证；或者在传输层安全协议TLS上进行http digest认证的身份认证。
所述建立安全连接的方法为：基于公钥证书的传输层安全协议TLS认证方式建立TLS连接。
所述网络侧包括BSF和NAF；步骤C所述计算第二本地接口共享密钥是由所述BSF进行计算的。
所述网络侧包括BSF和NAF；步骤C所述计算出第二本地接口共享密钥的步骤包括：由BSF根据所述共享密钥Ks计算出Ks衍生密钥，再由NAF根据所述Ks衍生密钥和所述外围设备标志计算出所述第二本地接口共享密钥。
所述计算第一和第二本地接口共享密钥的过程中，还使用以下参数进行计算：随机数RAND、用户的IP多媒体私有身份标识IMPI、所述NAF标识，特定的字符串。
所述计算第一本地接口共享密钥的过程中，所述NAF标识是UE接收外围设备配置的NAF的标识；或，预先在UE上配置有NAF标识对应到UE的用户识别模块UICC或移动设备ME标识，所述NAF标识是UE根据所述UICC或ME推算出的。
步骤C所述获取外围设备标志的步骤包括：所述UE将步骤A中接收到的所述外围设备标志发送给网络侧。
步骤C所述获取外围设备标志的步骤包括：所述外围设备向网络侧中的NAF发送连接请求时，该连接请求携带外围设备标志；网络侧从所述连接请求中获取所述外围设备标志。
所述网络侧与外围设备的信息进行加密传输。
由上述方法可以看出，本发明实现了UE与外围终端之间共享密钥的协商，从而可使用该密钥加密之间的传输，防止本地接口传输的数据被篡改或者窃取。
具体来说，本发明采用GAA框架动态协商UE与外围设备的共享密钥，并且密钥可以进行更新，从而实现之间的加密通信。本发明无须为与每个外围设备与UE之间的通信都保存一个固定的长期密钥。另外由于GBA功能是UE的UICC/ME已经支持的功能，因此采用GAA方法协商本地接口的密钥只是对UE的UICC/ME上GBA过程的重用，不影响已有的功能。
附图说明
图1为GAA框架示意图；图2为3G-WLAN网络外围设备在本地接口使用SIM认证接入WLAN的示意图；图3为NAF应用客户端和GBA客户端分离状态下的GAA框架示意图；图4为本发明采用GAA实现UE与外围设备协商密钥的第一实施例流程图；图5是本发明采用GAA实现UE与外围设备协商密钥的第二实施例流程图。

下面参见图4示出的本发明采用GAA实现UE与外围设备协商密钥的第一实施例的流程图，其中，由NAF作为密钥服务器协商UE与外围设备之间本地接口共享密钥Ks_Local，并且由NAF向外围设备分发本地接口共享密钥Ks_Local。其中，NAF与外围设备之间通信时，可以采用外围设备的公钥/对称密钥进行完整性以及数字签名保护，而NAF向外围设备发送的秘密数据可由NAF生成一个随机密钥进行保护，而该随机密钥的发送需要采用外围设备的公钥/对称密钥进行加密保护。
本实施例中，示出的UE和外围设备均属于同一个用户，以UE上使用UICC为例，对本发明进行详细说明，包括以下步骤：步骤401：当外围设备发起与UICC的通信时，首先判断自身是否存储有有效的与UE的本地接口共享密钥Ks_Local，若有，则直接使用该密钥加密与UE的通信，退出本流程；若没有，则向UE发送连接请求，并且在连接请求中携带用来标识外围设备的设备标志。
其中，设备标志用于UE识别不同的外围设备或者外围设备上某个应用。设备标志可以是：在UICC/ME中预先配置的索引值，UICC/ME通过该索引值在本地查找自身对应的设备标识信息或者设备上应用的标识信息；或者，是设备标识或应用标识自身；其中设备标识可能是对应于该外围设备的一个用户名或一个口令，尤有可能只是一个设备的硬件标识，具体采用哪种标识视网络管理外围设备的方式而定。
步骤402：UICC收到外围设备的连接请求以后，判断自身是否存储有与BSF协商的共享密钥Ks，若有，则直接执行步骤403；否则与BSF执行互鉴权(GBA)过程，以完成与BSF之间的身份互相鉴权及共享密钥Ks的协商。
GBA过程中，还可能会包括BSF到HSS获取用户的鉴权信息的步骤，由于GBA过程为公知技术，此处不再赘述。
步骤403：BSF为共享密钥Ks定义一个有效期，并分配一个可用于标识共享密钥Ks的B-TID，将所述有效期和B-TID一同发送给UICC。
当Ks到达有效期时，返回步骤402重新执行GBA过程协商生成新的Ks。
步骤404：UICC以Ks、″gba-u″‖RAND‖IMPI‖NAF_Id为参数计算Ks的衍生密钥Ks_int_NAF。其中，Ks_int_NAF＝KDF(Ks，″gba-u″‖RAND‖IMPI‖NAF_Id。
然后，再利用计算出的Ks_int_NAF导出Ks_local。比如可以以计算出的Ks_int_NAF、外围设备的设备标识/外围设备上应用标识、以及密钥服务器标识NAF_Id为参数计算UE与外围设备的本地接口共享密钥Ks_Local(也可称为第一本地接口共享密钥)。其中，Ks_Local＝KDF(Ks_int_NAF，NAF_Id‖设备标识)。也可能包含一个随机数，比如Ks_Local＝KDF(Ks_int_NAF，NAF_Id‖设备标识‖RAND)。
上述RAND是一个随机数，IMPI是指用户的IP多媒体私有身份标识，NAF_ID指用作密钥服务器NAF的标识，″gba-me″和″gba-u″代表字符串；KDF是密钥导出函数的缩写。
其中UICC可以保存Ks_Local，并以设备标志作为索引；也可以不保存，在每次需要时临时生成。
UICC获得用作密钥服务器的NAF标识可以存在下述两种方式：第一种，由于运营商网络中专门用于协商UICC和外围设备的服务器是有限数量个设备，因此某一个运营商网络内的协商密钥的NAF_Id可以是某一个固定值。NAF_Id的获得可以是直接在外围设备上进行配置，然后发送给UICC。
第二种，预先分配NAF标识时遵循号码规范配置，这样可由UICC应用的用户身份标识(如USIM应用的IMSI、ISIM应用的IMPI)推算而来。例如，如果IMSI是“234150999999999”，则根据现有号码规范可知，对应的MCC＝234，MNC＝15，MSIN＝0999999999，则NAF地址可以是″naf.mnc015.mcc234.3gppnetwork.org″。
如果采用IMPI作为用户标识，且IMPI是″user@operator.com″，则NAF地址可以是″naf.operator.com″。
步骤405：UE向外围设备返回B-TID相关信息。
一般情况下，B-TID只相当于Ks的索引，因此可以直接采用明文发送，比如可以是UICC通过插卡的ME转发给外围设备，也可以是ME直接发送。
如果不希望直接在本地接口发送B-TID，那么可以只发送一个网络可以识别B-TID的索引值给外围设备。网络可以通过索引值对应到B-TID。
而该索引值的协商过程可以是UICC/ME通过Ua接口与NAF协商的，此时，NAF需要保存B-TID与该索引值的对应关系；还可以是UICC/ME通过Ub接口与BSF协商的，此时，BSF会在bootstrapping过程结束分配一个B-TID和B-TID对应的索引值给UICC/ME。
步骤406～步骤407：外围设备收到B-TID以后，与NAF间进行对外围设备的身份认证并建立安全连接。外围设备通过建立的安全连接向NAF发送Ks_Local密钥请求。请求消息携带B-TID以及外围设备的设备标志。
如果设备标志是一个外围设备标识信息的索引值，那么网络侧BSF或者NAF中必须保存所述索引值与外围设备标识对应的关系表，以便于网络能够根据设备标志确定出是哪个设备的请求。
为了保证外围设备与NAF信息传输尤其密钥发放的安全性，为了保证该外围设备是运营商认证了的合法设备，NAF应该对外围设备的身份进行认证；为了保证密钥分发中不被窃取，密钥应该以加密方式进行分发即NAF与外围设备之间应该建立安全连接。具体实现可以是下面两种情况：第一种情况：如果外围设备具备运营商网络信任的公钥证书，可以由外围设备的私钥对消息进行数字签名。NAF收到请求以后，首先查找外围设备的公钥，并且利用公钥对数字签名进行认证。保证了与NAF通信的就是设备标志所声明的外围设备，而不是冒充的外围设备。
基于第一种情况，外围设备和NAF之间可采用基于公钥证书的传输层安全协议(TLS)认证方式建立TLS连接。密钥分发消息可以由TLS连接进行安全保护。
第二种情况：如果外围设备不具备运营商网络信任的公钥证书，而是与运营商网络共享了某一个密钥K，则可采用K对请求消息进行数字签名。并且外围设备需要将密钥索引KID在请求消息里连同B-TID一起发送给NAF。NAF收到请求以后，使用与KID对应的密钥进行验证数字签名。该KID与外围设备应该是一一对应的关系。例如外围设备标识本身作为KID时，可以通过计算：MAC＝H(设备标识‖B-TID‖K)。NAF收到请求以后，根据设备标识找到该设备标识所对应的密钥K’，然后对消息进行HASH计算：MAC-R＝H(设备标识‖B-TID‖K’)，如果二者相等，那么就说明该请求者的身份就是设备标识所声明的。
基于第二种情况，外围设备和NAF之间可以采用以下几种方式建立安全连接：1)基于HTTP digest AKA方式。既可以是NAF单向对UE进行认证，也可以是NAF与UE间进行双向认证。
2)基于预共享密钥的传输层安全协议(PSK_TLS)方式建立安全连接。
3)基于HTTP digest AKA与PSK_TLS相结合的方式。外围设备采用NAF的证书方式建立一个TLS连接，并在TLS连接上发送认证外围设备的http digest消息，已达到对外围设备的身份认证。而密钥分发消息可以由建立的安全连接进行保护。
值得指出的是，NAF可能通过其他方式获得外围设备的设备标志。例如，可以是运营商网络在本地配置已经配置了该外围设备的信息，外围设备或者UE通过短消息的方式告诉运营商网络(如BSF或NAF)要启用某个外围设备某项特征信息，运营商网络(如BSF)在本地查找到设备标志并通知NAF。也可以是外围设备或者UE通过其他消息直接告诉NAF外围设备的某项信息，比如UE通过Ua接口的安全连接通知NAF要启用哪个外围设备。
步骤408：NAF收到外围设备的密钥请求后，向BSF发送衍生密钥请求，并在请求消息携带B-TID和NAF_Id。
步骤409：BSF根据B-TID查找到与UICC的共享密钥Ks以后，以Ks，″gba-u″‖RAND‖IMPI‖NAF_Id为参数，采用UICC侧同样的算法计算出Ks的衍生密钥Ks_int_NAF。
步骤410：BSF将生成的Ks_int_NAF返回给NAF。
步骤411：NAF以接收到的Ks_int_NAF，设备标志，以及NAF_ID为参数采用与终端相同算法计算本地接口共享密钥Ks_Local(也可称为第二本地接口共享密钥)：Ks_Local＝KDF(Ks_int_NAF，NAF_Id‖设备标志)。
步骤412：NAF将计算出的本地接口共享密钥Ks_Local发送给外围设备。为了保护Ks_Local不被窃听，Ks_Local可进行加密传输。
加密的方法可以是直接采用步骤406～步骤407中建立安全连接的过程中协商的密钥和加密算法进行加密发送；或者采用衍生密钥进行保护，例如：NAF将生成随机数R作为密钥对Ks_Local进行加密保护，即Ks_Local*＝ER(Ks_Local)，比如 或者以R为密钥对Ks_Local进行其它的加密算法保护，如AES算法等。
NAF还要对R进行加密后连同密文Ks_Local*一起发送，即向外围设备发送Ks_Local*和R*：对R的加密可以采用如下加密方法：如果外围设备具备运营商网络信任的公私钥对(Kp，Ki)，以及Kp的公钥证书。那么就采用外围设备的公钥算法Kp对R进行加密：R*＝EKp(R)。
如果外围设备具备运营商向其发送的对称密钥K，那么NAF根据外围设备发送的密钥索引KID找到密钥K以后，用K对R进行加密：R*＝EK(R)。
步骤413：外围设备采用与步骤412中的加密方式相对应的密钥进行解密得到Ks_local。
例如，外围设备收到Ks_Local*和R*后，解密得到Ks_Local。对应步骤412，可包括：首先对R*解密得到R：如果是公钥加密方式，则使用对应的私钥Ki解密，即R＝DKi(R*)；如果采用的是对称加密算法，则R＝DK(R*)。
然后再以R为密钥对Ks_Local*解密得到Ks_Local：Ks_Local＝DR(Ks_Local*)。
至此，完成了为UICC和外围设备协商共享密钥Ks_Local的过程，外围设备和UICC之间的通信就可以使用该密钥作为本地接口密钥进行加密通信。
另外，还可以为上述Ks_Local设定一个有效期，由UICC或外围设备进行保存，当到达有效期时，返回步骤406，重新生成Ks_Local。
这里说明一下，上述实施例以当UICC具备GBA功能时(属于GBA_U过程)，且Ks_local的计算在UICC里进行的说明。由UICC计算的衍生密钥包括Ks_ext_NAF和Ks_int_NAF，如：Ks_ext_NAF＝KDF(Ks，″gba-me″‖RAND‖IMPI‖NAF_Id)；Ks_int_NAF＝KDF(Ks，″gba-u″‖RAND‖IMPI‖NAF_Id)。上述是以UICC选择Ks_int_NAF计算Ks_Local，不难理解，也可以是由ME选择Ks_ext_NAF计算Ks_Local。
而对于当Ks存放在ME上(属于GBA_ME过程)，则可由ME计算衍生密钥Ks_NAF，如：Ks_NAF＝KDF(Ks，″gba-me″‖RAND‖IMPI‖NAF_Id)。再使用Ks_NAF计算Ks_Local，其他原理相同，不再赘述。这种情况就是UE的ME与外围设备之间的密钥协商，不是指UICC了。
另外需要说明的，实施例中，计算Ks_Local的过程分成了两个步骤，但本领域人员不难理解，也可以分为一个步骤进行计算，如，Ks_Local＝KDF(Ks，″gba-u″‖RAND‖IMPI‖NAF_Id‖设备标识)，对于UICC，则可由UICC直接计算，对于BSF和NAF，则可由任一设备进行计算。
从上可以看出，本发明实现了用户与外围设备之间密钥的协商，从而实现了之间的加密通信。并且，不同的外围设备与UICC通信时，针对不同的外围设备生成不同密钥用于所述加密通信。
图5是本发明采用GAA实现UE与外围设备协商密钥的第二实施例流程图，如图5所示，本实施例中，示出的UE和外围设备均属于同一个用户，以UE上使用UICC为例，包括以下步骤：步骤501～步骤505：具体实现与步骤401～步骤405完全一致，这里不再重述。
步骤506～507，当UE向外围设备返回B-TID后，与NAF间进行对UE的身份认证并建立Ua接口的安全连接；UE通过建立的Ua接口的安全连接向NAF发送请求消息，用于请求NAF计算Ks_local，并将计算得到的Ks_local发送给外围设备。
步骤508～步骤511：具体实现与步骤408～步骤411完全一致，这里不再重述。
步骤512：在NAF向外围设备发送密钥之前，NAF对外围设备进行认证并建立NAF与外围设备间的安全连接。
可选地，外围设备可以认证NAF，即NAF与外围设备间进行双向认证。
NAF与外围设备间的认证与安全连接建立与步骤406和步骤407一致，这里不再重述。
步骤513～步骤514：具体实现与步骤412～步骤413完全一致，这里不再重述。
从图5和图4两个实施例的流程图所示，两个实施例的主要区别在于：向NAF请求Ks_Local的实体不同，可以是图4所示的外围设备，也可以是图5所述的UE。如果请求Ks_Local的实体是外围设备，则在请求Ks_Local之前就执行NAF与外围设备间的认证即安全连接的建立；如果请求Ks_Local的实体是UE，则在请求Ks_Local之前需要执行NAF与UE间的认证即安全连接的建立，在NAF下发Ks_Local之前，还需要执行NAF与外围设备间的认证即安全连接的建立。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。