通用鉴权框架推送业务实现方法

专利名称：通用鉴权框架推送业务实现方法
技术领域：
本发明涉及网络通信技术领域，具体涉及一种通用鉴权框架推送业务实现方法。
背景技术：
在第三代无线通信标准中，多种应用业务实体使用一个用于完成对用户身
份进行验证的通用结构，即GAA (通用鉴权框架)。应用通用鉴权框架可实现 对应用业务的用户进行检查和验证身份，并为用户访问应用业务提供安全通信 的密钥。所述多种应用业务可以是多播或广播业务、用户证书业务、信息即时 提供业务等，也可以是代理业务。 图1为GAA的结构示意图
通用鉴权框架通常由UE (用户设备)、执行用户身份初始检查验证的实体 BSF ( Bootstrapping Server Function,自引导鉴权协议服务功能)、HSS ( Home Subscriber Server,用户归属服务器)、定位HSS的位置的实体SLF ( Subscriber Locator Function ，用户位置功能)和网全备业务应用实体NAF ( Network Application Function,网络应用功能)组成。BSF用于与IJE进行互验证身份， 同时生成BSF与用户的共享密钥Ks; HSS中存储用于描述用户信息的描述文 件，同时HSS还兼有产生鉴权信息的功能。Dz、 Zh、 Zn、 Ub、 Ua为各实体之 间的4妻口 。
通常情况下，Ul':需要使用某种业务时，需要和该业务对应的NAF联系， 即UK主动向NAF发起连接请求。如果该NAF使用GAA通用鉴权框架，则UK首 先需要和BSF进行互鉴权，以验证身份。鉴权成功后，UE根据与BSF的共享密
钥Ks计算出与NAF力口密通信的衍生密钥Ks—NAF,同时将包含Ks信息的B-TID (会话事务标识)发送给NAF， NAF根据收到的B-TID从BSF获得共享密钥Ks 的衍生密钥Ks—NAF。这样，UE就可以和NAF使用衍生密钥Ks—NAF在lJa口进
行安全通信。
在某些应用场景，需要网络侧向UE主动发起通信请求，即推送(push) 业务。现有的GAA推送流程如下
在NAF采用GAA技术向用户发送推送消息之前，必须先到BSF请求Ua口 通信的Ks书亍生密钥Ks—NAF 。
如果在收到NAI:的密钥请求时，UE和BSF之间还没有协商一个可用的共 享密钥Ks，那么BSF从HSS获取一组鉴权向量，并计算得到Ks以及Ks一NAF; 同时向NAF发送该组鉴权向量中的AUTN (认证令牌)以及衍生密钥Ks-NAF， 还可能包括鉴权向量中的RAND (随机数)，B-TID (会话事务标识)和衍生密 钥Ks—NAF生存期等。然后NAF将在向UE发送的push消息中发送AUTN 、 RAND 、 B-TII) 、 NAF—ID ( NAF标识)等信息，并且可能包含加密的数据。 UE将根据AUTN， RAND值认证网络，并且计算出共享密钥Ks以及衍生密钥 Ks NAF。
如果在收到NAF的密钥请求时，UE和BSF已经协商好一个可用的共享密 钥Ks,那么BSl:将利用该共享密钥Ks计算出衍生密钥Ks一NAF，并将相应的 B-TID和Ks—NAF生存期发给NAF。 NAF在向UE发送push消息中携带B-TID和 NAF-ID，并且可能包含加密的数据。UE根据B-TID中的共享密钥Ks计算出衍 生密钥Ks一NAF,或者在本地找到一个与B-TID对应的Ks—NAF，并采用此密钥 解密携带的加密数据。
由于在GBA—U (基于UICC的通用自引导鉴权框架)的情况下，BSF和Ul; 可能会利用共享密钥Ks衍生出两个密钥，即放在UICC (Universal Integrated Circuit Card,通用集成电路卡)上的衍生密钥Ks int NAF和放在ME (mobile
Equipment,移动设备)上的衍生密钥Ks—ext—NAF。在这种情况下，NAF就需 要与UP:协商好到底采用哪一个密钥进行安全通信。
在U1:':发起业务中，UE侧根据应用所处的位置来决定采用的衍生密钥如 果基于UICC的应用，将采用放在UICC上的密钥Ks—int—NAF;如果基于ME的 应用，将采用放在ME上的密钥Ks—ext—NAF。然后UE将选^^的密钥类型以向 NAF上报应用所处位置的方式告诉NAF。 NAF再根据本地策略，或者BSF的策 略，来判断是否允许终端所选的密钥类型。如果允许，则采用该密钥通信，否 则拒绝UK的请求。
但是在推送业务中，由于NAF向UE发送推送消息之前，不存在与l见的交
Ul':也就不可能通知网络侧其所选的密钥类型。因此现有这种方法不能应用于 GAA推送过程中。

发明内容
本发明要解决的技术问题是提供一种通用鉴权框架推送业务实现方法，以 克服现有技术在GBA—U的情况下，无法适应GAA推送业务的缺点，保证推 送业务的安全。
本发明一种通用鉴权框架推送业务实现方法的一个实施例包括 网络侧确定推送业务密钥及密钥类型；
用户侧与网络侧通信，确定与网络侧一致的推送业务密钥，并使用该推送 业务密钥与网络侧进行通信。
其中，网络侧确定推送业务密钥及密钥类型时，可以由自引导鉴权协议服 务功能实体BSF确定网络应用功能实体NAF需要使用的推送业务密钥及密钥 类型；或者由NAF确定NAF需要使用的推送业务密钥及密钥类型。
用户侧确定与网络侧一致的推送业务密钥时，可以根据用户侧收到的推送
业务消息的需要来选择存储在UICC上的衍生密钥或者存储在ME上的衍生密 钥；还可以依次尝试存储在通用集成电路卡UICC上和存储在移动设备MK上 的衍生密钥，根据尝试结果确定符合要求的衍生密钥；或者用户侧按照应用规 范所规定的密钥选择规则并结合自身能力选择。
由以上本发明提供的技术方案可以看出，本发明在推送业务中，由网络侧 确定符合要求的推送业务密钥及密钥类型，并使用该密钥加密向用户侧发送的 推送业务数据；用户侧选择能够识别网络侧推送业务加密数据的推送业务密 钥，并使用该密钥与网络侧进行通信。在具体实现时，推送业务使用的密钥类 型选4奪^L则可以由应用^见范确定，也可以由BSF运营商或NAF运营商来确定， 还可以由用户和BSF运营商、NAF运营商共同来确定，从而可以方便、灵活 地适应不同应用场景的需要。根据确定的密钥类型来选用相应的衍生密钥作为 推送业务密钥，有效地保证了推送业务的安全。


图1是现有技术中通用鉴权框架结构示意图； 图2是本发明方法第一实施例的实现流程图3是本发明方法中由BSF和NAF共同确定密钥类型的一种实现流程图； 图4是本发明方法中 一种网络侧与用户侧消息交互的流程图； 图5是本发明方法中另 一种网络侧与用户侧消息交互的流程图； 图6是本发明方法第二实施例的实现流程图。
具体实施例方式
本发明在推送业务中，由网络侧选定符合要求的推送业务密钥及密钥类 型，并使用该密钥加密向用户侧发送的推送业务数据；用户侧选择能够识别网
络侧推送业务加密数据的推送业务密钥，并使用该密钥与网络侧进行通信。所
述推送业务密钥即为BSF和UE共享密钥Ks的书f生密钥(Ksjnt—NAI'、或者 Ksjext)—NAF)。由于在GBA—U的情况下，BSF和UE可能会利用共享密钥 Ks衍生出两个密钥，即放在UICC上的衍生密钥Ks—int—NAF和放在MH上的 衍生密钥Ks一ext—NAF。因此，针对这种情况，本发明中推送业务使用的密钥 类型选择规则可以由应用规范确定，也可以由BSF运营商或NAF运营商来确 定，还可以由用户和BSF运营商、NAF运营商共同来确定。
如果密钥选择规则由用户和BSF运营商、NAF运营商共同规定，那么用户 定制某项业务时，可以由用户与网络协商出一种密钥类型，并将协商结果放在 用户签约信息文件中。同时，用户侧的移动设备也可以将这一选择结果加以保 存。
如果用户是跟B SF运营商协商，那么网络侧的密钥选择类型信息可以放在 nss的用户签约文件中，比如可以放在GUSS (通用自引导鉴权框架用户安全 设置)的USS (用户安全设置)中。采用何种密钥进行推送业务，可以由BSF 进行判断后，只将可用的密钥发给NAF ( Ksjnt—NAF或者Ks一(ext)—NAF );也 可以是BSF根据UICC属性，判断GBA的类型后，计算Ks衍生密钥，然后将所 有得到的衍生密钥(Ks—int—NAF和Ks—ext—NAF两个密钥)及用户签约文件中 的密钥选择策略一并发给NAF，由NAF判断选择何种密钥类型进行推送业务。
在这种情况下，用户侧只需按照本地存储的密钥选择类型，选择使用何种 密钥解密推送消息。
如果用户是跟NAF运营商协商，那么NAF需要保存对应于该用户的密钥选 择类型信息，并在向用户推送业务时，直接采用选择好的密钥，同样用户侧只 需按照本地存储的密钥选择类型，选择使用何种密钥解密推送业务消息。
如果密钥选择规则由应用规范规定，则可以规定如果UICC具备GBA功 能，则选择保存在UICC上的密钥；而如果UICC不具备GBA功能，则选择保存
在M1LL的密钥。那么当BSF收到NAF的推送业务密钥请求后，或者根据UICC 属性以及应用规范的规定，判断Ua口需要采用的密钥类型，选择出一种密钥 (MH上的或者UICC上的)，然后向NAF发送所选的密钥；或者是将UICC属性 与两种密钥 一起发送给NAF ，由NAF根据应用规范来选择。
在这种情况下，用户侧完全可以根据自己的UICC属性以及应用规范的规 定来选择使用何种密钥解密推送消息。
如果应用规范没有规定密钥的选择策略，而仅仅是由网络侧BSF运营商或 者NAF运营商来规定，那么可以按照以下方式来选择
1. 网络侧按照用户的UICC属性以及网络运营商或NAF运营商的策略来选 择一个密钥使用后，将在推送消息中发送一个使用的密钥类型的指示。用户侧 收到推送消息后，根据该指示选择一个密钥进行解密。
2. 网络侧按照用户的UICC属性以及网络BSF运营商或NAF运营商的策略 来选择一个密钥使用后，并不向用户发送密钥类型指示信息，而是由用户自己 去尝试。如果是GBAJJ，用户设备将计算出两个密钥，先用其中一个密钥解 密，如果不成功，再换用另一个密钥解密。
3. NAF自己判断要发送的推送消息的解密点及解密端是UICC还是ME。 如果解密点是UICC，就采用存放于UICC上的Ks衍生密钥加密，否则采用存放 于ME上的Ks衍生密钥加密。而用户设备自己也能判断某个推送消息应该由MK 来执行，还是UICC来执行。如果消息是发给ME的，就由ME采用ME上的衍生 密钥来解密，如果消息是发给UICC的，则由UICC釆用UICC上的衍生密钥来 执行解密。
4. 网络侧按照自己的策略选择一种密钥对推送业务数据进行加密后发送 给用户侧。而用户设备事前已经通过某种方式得到网络侧的密钥选择策略，比 如主动下载，或者网络侧业务通知，或者用户与网络签约时，将密钥选择信息 保存在本地等方式。当用户侧收到推送消息后，即按照该策略选择密钥解密推
送消息。例如，将可以接收这种消息的客户端放在符合要求的位置。要求使用
MH上的衍生密钥的，就将客户端放到ME上；需要使用UICC上的衍生密钥的， 就将客户端放到UICC上。由于网络侧的策略有可能会变化，在这种情况下， 用户就需要动态获得网络的当前策略。可以在网络侧策略改变后将策略通知用 户侧，或者定期地向用户发送业务通知，告诉其网络侧的新策略，还可以由用 户定期从网络下载，已达到更新。
5.与用户侧主动发起业务类似，事前根据其它原因将应用客户端放在所 需的位置，再根据应用客户端所在位置决定密钥类型，如果应用基于Mli，则 选择Ml.;上的密钥；如果应用基于UICC,则选择UICC上的密钥。网络侧NAl-' 可以通过以下几种可能的方法获知应用客户端的位置，从而确定可以使用的密 钥类型
(1 )用户申请签约业务时告诉网络侧。该签约信息可以存放在HSS、或 者BSF、或者NAF中。如果根据应用客户端位置选择的密钥不符合NAF或者BSF 运营商的要求，那么将不对该用户发送推送业务。
(2)从应用本身获知。如某种应用只可能在ME上实现，或者只可能在 IJICC上实现。可以将应用在用户侧终端上的位置信息保存在用户的签约文件 中，在需要了解该应用的位置信息时，由BSF读取该用户的签约文件即可得到。
(3 )网络侧在发送第一条推送消息时不携带使用Ks衍生密钥加密数据， 当从用户侧收到响应消息后，再从该响应消息或者应用所在位置的指示信息来 决定使用哪种衍生密钥，然后再发送相应的Ks衍生密钥加密的数据。当然如果 用户侧所指示的密钥类型不符合网络侧要求，那么NAF将不再向用户发送后面 的数据。
为了使本技术领域的人员更好地理解本发明方案，下面结合附图和实施方 式对本发明作进一 步的详细说明。
参照图2，图2示出了本发明方法的第一实施例的实现流程，包括以下步骤
步骤201:当需要进行推送业务时，NAF检查本地是否已经存在与用户侧 相关的推送业务密钥。如果存在，则进到步骤202;否则，进到步骤203。 步骤202:选用本地存储的密钥并确定可以使用的密钥类型。 步骤203: NAF向BSF请求推送业务密钥。
可以在该请求消息中携带需要通信的用户的标识信息、NAF的标识信息 等。其中，用户标识可以是用户的私有标识IMPI (IP多々某体子系统私有用户 身份标识)或永久标识IMSI (International Mobile Subscriber Identifier,国际移 动用户标识)，也可以是能够唯一标识该用户的其他标识信息。
步骤204: BSF判断NAF是否有权进行推送业务。如果没有，则进到步 骤205;否则，进到步骤206。
BSF可以根据用户的签约信息或者NAF运营商与BSF运营商的签约关系 来判断NAF是否有权。
步骤205:拒绝NAF的密钥请求。
上述步骤204和步骤205是可选步骤，也就是说，BSF也可以不用判断 NAl''是否有权进行推送业务。
步骤206: BSF检查本地是否存在可用于计算NAF推送业务密钥的密钥 Ks。如果不存在，则进到步骤207;否则，进到步骤208。
前面已提到，NAF可以在向BSF发送推送业务密钥请求消息时携带用户 标识信息、NAF标识信息，因此，BSF可以根据这些信息检查本地存储的可 用密钥中是否有这些信息对应的，也就是说可以使用的计算NAF推送业务密 钥的密钥Ks。
如果GAApush中Ks不可重用，那么该步骤可以省略。直接进入207。 步骤207: BSF获取新的鉴权向量，计算得到BSF与用户的共享密钥Ks。 本技术领域人员知道，HSS中存储了用户的签约信息，因此，BSF可以根
据收到的4,送业务密钥-清求消息中包含的用户标识/人HSS中获^U于应该用户
的一组鉴权向量，并计算得到共享密钥Ks以及Ks衍生密钥Ks—NA1:或者Ks— (cxt/int) —NAF。
步骤208: BSF计算Ks衍生密钥Ks_NAF/Ks— ( ext/int) —NAF。
由于在GBA—U的情况下，BSF和用户会利用Ks衍生出两个密钥， 一个 放在MI( ( Mobile Equipment,移动设备)的UICC ( Universal Integrated Circuit Card,通用集成电路卡)上，即Ks—int—NAF;另 一个放在ME上，即Ks—ext—N八F。 在这种情况下，就需要确定NAF可以使用的密钥类型，也就是说，确定NAF 应该使用UICC上的衍生密钥，还是应该使用ME上的衍生密钥。
如果BSF能够计算得到两个Ks衍生密钥，则由BSF独自确定或者由BSF 和NAI''共同确定NAF需要使用的密钥类型。当然，在ME不支持GBA—IJ的 情况下，BSF只计算出一个衍生密钥Ks—NAF,也就不存在选用哪一个衍生密 钥的问题。
步骤209: BSF将获取的Ks衍生密钥发送给NAF。
BS1.'还可以同时将AIJTN、 B-TID、密钥有效期等信息发送给NAI'，，也可 以包括计算推送业务密钥的其他参数。
如果由BSF独自确定NAF需要使用的密钥类型，则可以只将选定的Ks 衍生密钥，而且还可以包括其对应的密钥类型发送给NAF。如果由BSF和NAF 共同来确定NAF需要使用的密钥类型，则可以将获取的两个Ks衍生密钥、 BSF指定的密钥选择策略和用户签约信息发送给NAF，使NAF根据该策略及 用户签约信息来确定可以使用的密钥类型。当然，还可以只将获取的两个Ks 衍生密钥发送给NAF，由NAF根据自已的密钥选择策略或者应用规范所规定 的密钥类型并结合用户的能力信息选定可以使用的密钥类型。
当然，也可以是BSF先自己选定采用哪种密钥后，再计算符合要求的Ks
衍生密钥。
选用哪种方式可以根据系统应用环境、终端签约信息、终端能力等来确定。 具体的密钥类型选择方式将在后面详细举例描述。
步骤210: N八F确定可以使用的推送业务密钥及密钥类型。 步骤21NATT向用户侧发送推送消息。
在该消息中，NAF可以将网络侧的密钥选择策略一起发送，还可以包含 采用推送业务密钥加密的数据。
步骤212:用户侧选择符合要求的衍生密钥，该衍生密钥即与网络侧一致 的推送业务密钥，并使用该密钥与网络侧进行通信。
用户侧收到NA1''发送的推送消息后，在利用Ks衍生密钥解密推送业务数 据前需要确定采用何种密钥。比如，可以采用以下方式来选择符合要求的衍生 密钥
(1) 如果推送消息中有密钥类型指示，那么将采用相应密钥对推送业务 数据解密；
(2) 如果应用已经规定首选密钥，并按照先选密钥，后决定解密点位置 的方式来选。用户设备将根据应用规范的规定以及UICC属性(是否支持GBA 功能)来选择符合要求的衍生密钥，并使用该衍生密钥对推送业务数据解密。
(3) 根据应用自身属性决定。如该应用只可能在UICC或者ME上实现， 则可以按照客户端在何处，就采用何处存放密钥的原则来选择符合要求的衍生 密钥，并使用该衍生密钥对推送业务数据解密。。
(4) 若对应于该应用，用户设备已经预先配置了密钥选择信息，那么将
按照配置来选。
(5) 采用自适应方法，即如果是GBA—U，用户设备将计算出两个密钥， 先用其中一个密钥解密，如果不成功，则换另一个密钥解密。
前面4是到，如果BSF上存在或计算得到两个Ks书f生密钥，则可以由BSI: 独自确定或者由BSF和NAF共同确定NAF需要使用的密钥类型。
在本发明中，BSF可以按以下任意一种方式选择NAF可以使用的密钥类
型
(1 )BSF根据用户与网络签约时确定的密钥选择规则确定NAF需要使用 的密钥类型；
(2)BSF根据应用的自身属性确定NAF需要使用的密钥类型。比如，当 应用位于通用集成电路卡UICC上时，则选用存放在UICC上的衍生密钥；当 应用位于移动设备ME上时，选用存放在ME上的衍生密钥。
(3 )BSF根据应用规范中规定的密钥选择规则和用户属性确定NAF需要 使用的密钥类型。。比如，如果应用规范中规定了首选的密钥类型，则优先选 择该规定的首选的密钥类型作为NAF需要使用的密钥类型；如果应用规范中 未确定密钥选择规范，则BSF可以根据应用的自身属性确定NAF需要使用的 密钥类型。
如果由BSF和NAF共同来确定NAF需要使用的推送业务密钥及密钥类
型，同样也可以有多种实现方式。
参照图3，图3示出了其中一种实现流程，包括以下步骤
步骤301: BSF获取与用户侧的共享密钥，并计算该共享密钥的衍生密钥。
步骤302: BSF将计算出的共享密钥的衍生密钥返回给NAF，并在该消息
中携带BSF指定的密钥选择策略和用户签约信息。
BSI;指定的密钥选择策略可以是例如只允许采用Ks—int—NAF,或者两
者都允许，但是首选Ks—int—NAF等策略。
步骤303: NAF根据BSF返回的密钥选择策略和用户签约信息选定可以
使用的密钥类型。
如果BSF没有返回密钥选择策略，NAF将根据自己策略来选定可以使用
的密钥类型。
步骤304:将已选密钥类型的衍生密钥作为NAF需要使用的推送业务密钥。
在上述步骤302中，BSF也可以只将计算出的共享密钥的衍生密钥返回给 NAI''，然后由N八F根据自已的密钥选择策略并结合用户UICC的能力信息选 定可以使用的密钥类型。NAF可以在与用户签约时，得知该用户UICC的能 力；或者NAF从BSF获取该用户的能力信息。
NAI''自己的密钥选择策略可以是例如只允许釆用Ks—int—NAF,或者两 者都允许，但是首选Ks_int—NAF，即如果用户卡能够支持GBA密钥衍生功能， 那么就选择Ks—int_NAF ，否则选择Ks_NAF 。
下面进一步详细iJt明本发明中网络侧与用户侧交互时的消息流程。
参照图4所示网络侧与用户侧消息交互的一个实施例的流程
1. NAF想要向某用户发送推送消息。如果本地还没有推送业务密钥，则 向BSF请求推送业务密钥。请求消息中携带用户标识，NAF—ID (NAF标识) 等信息。其中，用户标识可以是用户的私有标识IMPI或永久标识IMSI,也可 以是其他可以唯一标识该用户的标识。如果NAF已经存在与用户相关的push 业务密钥，那么直接进入步骤4。
2. BSF检查该NAF是否有权进行推送业务。如果NAF无权进行推送业务， 则进行步骤3'; 否则BSF获取Ks , 并利用Ks计算Ks衍生密钥 Ks—(ext/int)—push—NAF 。
首先，BSF查找在本地对应该用户是否存在一个可用的Ks。如果已经存在 一个可用的Ks,便利用该Ks计算衍生密钥Ks—(ext/int)_push—NAF，用作NAF 推送业务密钥。如果不存在，则先获取一组新的鉴权向量，并且利用已有参数 得到Ks，并计算Ks衍生密钥作为NAF推送业务密钥Ks—(ext/int)_push_NAF。然
后，进到步骤3。
3'. BSF向NAF回应拒绝推送业务密钥请求消息。该步骤为可选步骤。
3. BS1'，将B-TID、密钥有效期以及计算得到的NAF推送业务密钥 Ks」cxt/int)—push—NAF,进一步可能包括AUTN、 一起发送^会NAF，还可能包 括用于计算推送业务密钥的其它参数。
BSF可以判断推送业务应该使用哪种Ks衍生密钥保护(尤其在GBA—IJ情 况下)，并只将可用的密钥发给NAF使用。具体可以根据以下方式判断NA1; 应该采用哪种密钥作为推送信息加密密钥
(1) 采用何种密钥已经由用户和网络在签约时协商好了，并放在用户签 约文件里(如在HSS里的用户签约文件里的GUSS中)。那么BSF可以根据签 约信息来判断。
(2) 用户签约信息中具备应用客户端在终端侧所在位置(MF:或UICC) 信息。BS1'，可以按照客户端在何处，就采用何处存放的密钥的原则来选择。
(3) 根据应用自身属性决定。如该应用只可能在UICC (或者)MlUi实 现，BSF可以按照客户端在何处，就采用何处存放密钥的原则来选择。
(4) 应用规范已经规定首选密钥，并按照先选密钥，后决定解密点位置 的方式来选。BSF将根据应用规范的规定以及UICC属性(是否支持GBA功能) 来选择。
BSF也可以不判断推送业务应该使用哪种Ks衍生密钥保护，只将用户签约 信息(如USS)发送给NAF。
4. NAF组成推送消息。同时可以将推送业务数据以Ks衍生密钥加密后一 起发送。至于选择何种密钥有以下几种方式
(1) 如果BSF只返回一种密钥，就采用该密钥加密。
(2) 如果BSF返回两种密钥，并且同时返回密钥选择的策略以及用户签 约信息，那么NAF将根据密钥选择策略以及用户签约信息来选。签约信息可能
是用户与运营商之前已经协商好使用何种密钥，或者协商好的解密点的位置。
(3) 应用规范已经规定首选密钥，并按照先选密钥，后决定解密点位置
的方式来选。NAF将根据应用规范的规定以及UICC属性(是否支持GBA功能)来选。
(4) NAF按照自己策略来选或者本地存储的用户信息来选，还可以结合 UICC属性。UICC属性可以从BSF返回的GUSS中获得。
(5) 应用自身属性决定。如该应用只可能在UICC或者ME上实现，NA1: 可以按照客户端在何处，就采用何处存放密钥的原则来选择。
6. NAF向UE发送推送消息。该消息除了可能包括B-TID 、 NAF—ID以及 在l爪没有有效Ks情况下包括AUTN等信息以外，还可以包括NAF所选Ks衍生 密钥的类型标识。除此之外，还可以包括由所选Ks衍生密钥保护的推送业务数 据。
7. UE收到推送消息后，在利用Ks衍生密钥解密推送数据以前需要确定采 用何种密钥。可以选用以下几种方法确定采用何种密钥
(1) 如果推送消息中有密钥类型指示，那么将采用相应密钥解密。
(2) 如果应用已经规定首选密钥，并按照先选密钥，后决定解密点位置 的方式来选。UK将根据应用规范的规定以及UICC属性(是否支持GBA功能) 来选。
(3) 应用自身属性决定。如该应用只可能在UICC或者ME上实现，BSF 可以按照客户端在何处，就采用何处存放密钥的原则来选才奪。
(4) 若对应于该应用，UE已经预先配置了密钥选择信息，那么将按照配
置来选。
(5) 采用自适应法，即如果是GBA—U,终端将计算出两个密钥，先用其 中一个密钥解密，如果不成功，则换另一个解。
参照图5所示网络侧与用户侧消息交互的另一个实施例的流程
1. NAI'，想要向某用户发送推送消息。如果本地还没有推送业务密钥，则
向BSF请求推送业务密钥。请求消息中携带用户标识，NAF—ID ( NAF标识) 等信息。其中，用户标识可以是用户的私有标识IMPI或永久标识IMSI，也可 以是其他可以唯一标识该用户的标识。如果NAF已经存在与用户相关的push 业务密钥，那么直接进入步骤4。
2. BSI;检查该NAF是否有权进行推送业务。如果NAF无权进行推送业务， 则进行步骤3'; 否贝'J BSF获取Ks ， 并利用Ks计算Ks衍生密钥 Ks—(ext/int)一push一NAF 。
首先，BSF查找在本地对应该用户是否存在一个可用的Ks。如果已经存在 一个可用的Ks ，便利用该Ks计算衍生密钥Ks—(ext/int)_push—NAF,用作NAF 推送业务密钥。如果不存在，则先获取一组新的鉴权向量，并且利用已有参数 得到Ks,并计算Ks衍生密钥作为NAF推送业务密钥Ks—(ext/int)_push—NA1 。然 后，进到步骤3。
当然如果Ks不可以重用，BSF就无须判断是否已有可用的Ks，而是直接取 新的认证向量得到Ks。
3'. BSr'向NAF回应拒绝推送业务密钥请求消息。
3. BSI'，将计算得到的NAF推送业务密钥Ks—(ext/int)_push—NAF—起发送给 NAF,还可能包括密钥有效期和/或用于计算推送业务密钥的其它参数，如 AUTN、 B-TID。
BSl:可以判断推送业务应该使用哪种Ks衍生密钥保护(尤其在GBA—U情 况下)，并只将可用的密钥发给NAF使用。具体可以根据以下方式判断NAF 应该采用哪种密钥作为推送信息加密密钥
(1)采用何种密钥已经由用户和网络在签约时协商好了，并放在用户签 约文件里(如在HSS里的用户签约文件里的GUSS中)，那么BSF可以根据签 约信息来判断。
(2) 用户签约信息中具备应用客户端在终端侧所在位置(Mt:或UICC) 信息。BSF可以按照客户端在何处，就采用何处存放的密钥的原则来选择。
(3) 根据应用自身属性决定。如该应用只可能在UICC (或者)Ml〖上实 现，BSF可以按照客户端在何处，就采用何处存放密钥的原则来选择。
(4) 应用规范已经规定首选密钥，并按照先选密钥，后决定解密点位置 的方式来选。BSF将根据应用规范的规定以及UICC属性(是否支持GBA功能) 来选择。
BSF也可以不判断推送业务应该使用哪种Ks衍生密钥保护，只将用户签约 信息(如USS)发送给NAF。
4. NA1:组成推送消息。该消息不包括由Ks衍生密钥加密或者完整性保护
的数据。
5. 向Ufi发送第一条推送消息。此时，可以将网络侧密钥选择策略一起发 送。该策略可能是NAF自己规定的策略，也可以是BSF规定的策略。可以指明 只能使用某一种密钥，或者是两种都可以。
6. l疋收到推送消息后，验证该消息的合法性，客户端选择支持的密钥类型。
7. UE向网络发送响应消息，并将自身选择的密钥类型(也即客户端解密 点位置)告知NAF。
8. NAF按照UE所选密钥对推送业务数据进行保护或者如果用户侧返回类 型不符合要求，则结束流程。
9. NA1''将加密后的数据发给UE。
10. UE计算得到Ks^f汙生密钥后，采用适当的密钥解密。 参照图6,图6示出了本发明方法第二实施例的实现流程。 在该实施例中，由BSF与UE共同决定push业务的密钥类型。该流程包
括以下步骤
1. NAF想要向某用户发送推送消息。如果本地还没有推送业务密钥，则 向BSF请求推送业务密钥。该消息包括用户的身份标识、自身的NAF—ID等 信息。其中，用户标识可以是用户的私有标识IMPI或永久标识IMSI,也可以 是其他可以唯一标识该用户的标识。如果NAF对密钥类型有自身的要求，该 消息还可进一步包括NAF想要采用的密钥类型。
2~3. BSF收到请求以后，进行相应的处理，主要有
BSF首先从HSS获得一组新的鉴权向量，然后向UE发送推送消息，并 在消息中携带AIJTN， RAND和/或B-TID,还可进一步携带NAF—ID。
另外，BSF还可以根据NAF要求采用的密钥类型决定采用的密钥类型； 如果BS1'，运营商自己也有一定的策略，那么还需要考虑BSF运营商的策略， 决定采用的密钥类型。在这种情况下，该推送消息需要进一步包括所选择的密 钥类型。
4. UH收到推送消息后，根据AUTN和RAND验证网络，并且计算出Ks。
5. 如果UE到BSF有反馈信道，UE向BSF发送响应消息。如果Ul<:不 支持BSF确定的密钥类型，还可通过该响应消息携带UE选择的密钥类型，使 BSF根据U1;的能力来重新确定推送业务的密钥类型或者确定是否向UK发送 Push消息。
6. BSl''向NAF发送计算得到的GBA密钥(Ks—(ext/int)—NAF )。
在GBA—U情况下，可以只发送协商好的密钥类型的密钥给NAF;也可以 将计算得到的两种密钥及BSF和/或UE选择的密钥类型发送给NAF,由NAF
自己选择。
另外，如果步骤5中携带了 UE选择的密钥类型，则BSF还需要判断UH
所选是否符合要求。
7. NA1;采用GBA密钥加密需要发送的推送业务数据。
8. NAF向Ul':发送包含该数据的推送消息，在该消息中还可进一步包括
加密密钥的类型。
9. UE对收到的推送消息采用相应的密钥解密。
虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多 变形和变化而不脱离本发明的精神，希望所附的权利要求包括这些变形和变化 而不脱离本发明的精神。
权利要求
1、一种通用鉴权框架推送业务实现方法，其特征在于，所述方法包括网络侧确定推送业务密钥及密钥类型；用户侧与网络侧通信，确定与网络侧一致的推送业务密钥，并使用该推送业务密钥与网络侧进行通信。
2、 根据权利要求1所述的方法，其特征在于，所述网络侧确定推送业务 密钥及密钥类型的步骤包括由自引导鉴权协议服务功能实体BSF确定网络应用功能实体NAF需要使 用的推送业务密钥及密钥类型；或者由NAF确定NAF需要4吏用的推送业务密钥及密钥类型。
3、 根据权利要求2所述的方法，其特征在于，所述由BSF确定NAF需 要使用的推送业务密钥及密钥类型的步骤包括BSI''选择N八F可以使用的密钥类型，并获取可用于计算NAF推送业务密 钥的密钥Ks、计算Ks衍生密钥；将已选密钥类型的衍生密钥作为NAF需要使用的推送业务密钥； BSF将选择的密钥类型的推送业务密钥发送给NAF。
4、 根据权利要求3所述的方法，其特征在于，所述由BSF确定NAF需 要使用的推送业务密钥及密钥类型的步骤进一步包括BSF将选择的密钥类型信息发送给NAF。
5、 根据权利要求3或4所述的方法，其特征在于，所述BSF选择NAF 可以使用的密钥类型的步骤具体为BSF根据用户与网络签约时确定的密钥选择规则确定NAF需要使用的密 钥类型；或者BSF根据应用的自身属性确定NAF需要使用的密钥类型；或者BSF根据应用规范中规定的密钥选择规则和用户属性确定NAF需要使用 的密钥类型；或者BSF根据用户侧反馈上来的用户侧信息、自身策略、NAF要求的密钥类 型这三者中的任一项或多项来确定NAF需要使用的密钥类型。
6、 根据权利要求5所述的方法，其特征在于，所述BSF根据应用的自身 属性确定NAF需要使用的密钥类型的步骤包括当应用位于通用集成电路卡UICC上时，则选用存放在UICC上的衍生密 钥的类型；当应用位于移动设备ME上时，选用存放在ME上的衍生密钥的类型。
7、 根据权利要求5所述的方法，其特征在于，所述BSF根据应用规范中 规定的密钥选择规则和用户UICC属性确定NAF需要使用的密钥类型的步骤 包括应用规范中未规定密钥选择规则，则BSF根据应用的自身属性确定NAl'' 需要使用的密钥类型。
8、 根据权利要求5所述的方法，其特征在于，BSF通过以下方式获取NAF 要求的密钥类型NAl''向BS1'，请求推送业务密钥，并将NAF要求的密钥类型发给BSF。
9、 根据权利要求3所述的方法，其特征在于，在所述BSF选择NA1<'可 以使用的密钥类型的步骤前还包括BSF向用户侧发送推送消息；用户侧将自身要使用的密钥类型或者应用所在位置通过响应消息反馈给 BS1'。
10、 根据权利要求2所述的方法，其特征在于，所述由NAF确定NAF需 要使用的推送业务密钥及密钥类型的步骤具体为BSF获取与用户侧的共享密钥，并计算该共享密钥的衍生密钥； 将计算出的共享密钥的衍生密钥返回给N AF; NA1:选定可以使用的密钥类型；将已选密钥类型的衍生密钥作为NAF需要使用的推送业务密钥。
11、 根据权利要求10所述的方法，其特征在于，所述将计算出的共享密 钥的衍生密钥返回给NAF的步骤进一步包括BSF在向N八返回衍生密钥的消息中携带BSF指定的密钥选择策略和用 户签约信息。
12、 根据权利要求11所述的方法，其特征在于，所述NAF选定可以使用 的密钥类型的步骤具体为NAI''根据BSF返回的密钥选择策略和用户签约信息选定可以使用的密钥类型。
13、 根据权利要求IO所述的方法，其特征在于，所述NAF选定可以使用 的密钥类型的步骤具体为N八h'根据自已的密钥选择策略并结合用户的能力信息选定可以使用的密 钥类型；或者NAF根据应用规范所规定的密钥类型并结合用户的能力信息选定可以使 用的密钥类型。
14、 根据权利要求13所述的方法，其特征在于， 在用户与NAF签约时，NAF获取用户的能力信息；或者 NAl''从BSF获取用户的能力信息。
15、 根据权利要求IO所述的方法，其特征在于，在所述NAF选定可以使 用的密钥类型的步骤前还包括NAF向用户侧发送推送消息；用户侧将自身要使用的密钥类型或者应用所在位置通过响应消息反馈给 薩'，。
16、 根据权利要求15所述的方法，其特征在于，所述NAF选定可以使用 的密钥类型的步骤具体为NAl''根据用户恻反馈上来的密钥类型信息，并结合网络侧密钥选择策略来选择。
17、 根据权利要求2所述的方法，其特征在于，所述网络侧确定需要使用 的推送业务密钥及密钥类型的步骤进 一 步包括如果NAF还未存在与所述用户侧相关的推送业务密钥，则在确定N八l;需 要使用的推送业务密钥及密钥类型之前，NAF向自引导鉴权功能BSF发送推 送业务密钥请求消息，在该请求消息中携带用户标识和NAF标识。
18、 根据权利要求2所述的方法，其特征在于，所述方法进一步包括 在用户与网络签约时确定密钥选择规则，并将其放在用户的签约文件中。
19、 根据权利要求2所述的方法，其特征在于，所述方法进一步包括 将应用在用户侧终端上的位置信息保存在用户的签约文件中。
20、 根据权利要求1所述的方法，其特征在于，所述方法进一步包括 用户侧获取网络侧使用的密钥类型。
21、 根据权利要求20所述的方法，其特征在于，所述用户侧获取网络侧 使用的密钥类型的步骤具体为由网络侧BSF或者NAF在发送推送消息时将确定的密钥类型通知用户 侧；或者由网络侧BSF或者NAF通过发送业务通知的方式通知用户侧；或者 由用户侧通过主动下载的方式获取网络侧确定的密钥类型；或者 用户与网络签约时，将密钥选择信息保存在本地。
22、 根据权利要求20所述的方法，其特征在于，所述用户侧确定与网络 侧 一致的推送业务密钥的步骤具体为用户侧根椐网络侧所要求使用的密钥类型确定与网络侧一致的推送业务密钥。
23、 根据权利要求20所述的方法，其特征在于，所述用户侧确定与网络 侧一致的推送业务密钥的步骤进一步包括用户侧根据网络侧要求使用的类型并结合自身能力确定密钥类型。
24、 根据权利要求21或22或23所述的方法，其特征在于，所述用户侧 与网络侧通信，确定与网络侧一致的推送业务密钥的步骤包括BSF通过推送消息将用于计算NAF推送业务密钥的鉴权向量发送给用户 侧，并将确定的推送业务密钥及密钥类型发送给NAF;用户侧根据所述鉴权向量计算得到符合所述密钥类型的推送业务密钥。
25、 根据权利要求1所述的方法，其特征在于，所述用户侧确定与网络侧 一致的推送业务密钥的步骤包括当用户侧收到的推送业务消息需要由通用集成电路卡UICC处理时，选择 存储在UICC上的衍生密钥；当用户侧收到的推送业务消息需要由移动设备 Ml;处理时，选择存储在ME上的衍生密钥；或者用户侧依次尝试存储在通用集成电路卡UICC上和存储在移动设备MK上 的衍生密钥，根据尝试结果确定符合要求的衍生密钥；或者用户侧按照应用规范所规定的密钥选择规则并结合自身能力选择。
全文摘要
本发明公开了一种通用鉴权框架推送业务实现方法，所述方法包括网络侧确定推送业务密钥及密钥类型；用户侧与网络侧通信，确定与网络侧一致的推送业务密钥，并使用该推送业务密钥与网络侧进行通信。利用本发明，可以根据实际应用情况，方便、灵活地选择推送业务的密钥类型，使网络侧和用户侧选择符合要求的密钥类型的衍生密钥进行通信。
文档编号H04L9/12GK101102186SQ200610145188
公开日2008年1月9日 申请日期2006年11月17日 优先权日2006年7月4日
发明者杨艳梅 申请人:华为技术有限公司