CN101822082B

CN101822082B - 用于uicc和终端之间安全信道化的技术

Info

Publication number: CN101822082B
Application number: CN2008801103417A
Authority: CN
Inventors: I·查; C·V·拉蒂; Y·C·沙阿; L·J·古乔内; A·U·施米特; N·孔茨
Original assignee: InterDigital Technology Corp
Current assignee: InterDigital Technology Corp
Priority date: 2007-10-05
Filing date: 2008-10-06
Publication date: 2013-06-12
Anticipated expiration: 2028-10-06
Also published as: KR20100075603A; WO2009046400A1; TWI429254B; TW200917781A; AR068682A1; CN103001940A; US8503376B2; US20090209232A1; CN102857912A; JP5432156B2; JP2011501908A; EP2210436A1; KR20100083840A; CN101822082A; KR101084938B1; TW201014314A

Abstract

本发明涉及无线通信系统。3G UMTS移动电话系统依赖于受保护的智能卡，该智能卡称为UMTS集成电路卡(UICC)，可提供UMTS用户身份模块(USIM)应用以作为用来保护3G移动终端和UMTS无线网络(或者UTRAN)之间的通信路径的各种安全性措施的基础或者根本。公开一种方法，通过该方法UICC与终端交换信息，诸如内部密钥中心(IKC 1250)和引导服务器功能(BSF 1270)，允许特定用于应用和网络应用功能(NAF)的多个本地密钥(Ks_local)用来认证，以及加密和解密消息的进程。

Description

用于UICC和终端之间安全信道化的技术

技术领域

本申请涉及无线通信。

背景技术

UMTS蜂窝无线通信系统第七版本中，标准制订机构第三代合作计划(3GPP)已经起草了技术规范TS33.220-780来加强现存的认证和密钥协议(AKA)进程。TS33.220中描述的较新的AKA进程明确了涉及含有UMTS集成电路卡(UICC)和归属位置寄存器/归属用户系统(HLR/HSS)的无线接收/发送单元(WTRU)的进程。

图1示出了期望用于AKA进程的网络元件和其各自的接口。引导服务器功能(BSF)是网络元件的一部分，处于移动网络控制器(MNO)的控制下，且与WTRU和HSS一起参与带有基于UICC增强的通用引导架构(GBA)(GBA_U)，以建立网络和WTRU之间的共享机密。网络应用功能(NAF)是用作网络元件的一部分，且使用GBA建立的共享机密用以驱动密钥从而保护WTRU和NAF之间的通信路径。引导服务器功能(BSF)使用用户位置功能(SLF)来获得归属用户系统(HSS)的详情，其中当BSF没有被预先定义的HSS配置或者管理时，所述HSS包括所需的用户特定数据。HSS存储了所有用户安全设置(USS)，用户具有UICC上的多个IP多媒体服务身份模块(ISIM)或者用户服务身份模块(USIM)应用。HSS可包括与一个或多个私有身份成映射的一个或者多个GBA用户安全设置(GUSS)。Ub是指WTRU和BSF之间的参考点。WTRU和BSF之间相互的认证过程在这些参考点上发生，会话密钥基于3GPP AKA架构引导。Ua是带有应用协议的NAF和WTRU之间的参考点，且作为在Ub参考点上的HTTP摘要AKA的结果，Ua是通过基于WTRU和BSF之间达成协议的机密材料来得出(derive)密钥从而被保证安全的。Zn是NAF和BSF之间的参考点，且被NAF使用来从BSF获得密钥材料(在之前的Ub上的HTTP摘要AKA协议中同意的)和特定应用的USS。Zh是BSF和HSS之间的参考点，是由BSF使用来从HSS检索认证信息和GUSS。Dz是BSF和SLF之间的参考点，是由BSF使用来检索包括用户特定信息的HSS的名称。

在TS 33.220中讨论两个过程。第一个是UICC增强的GBA(GBA_U)进程，以及第二个是安全结合(SA)进程。

在GBA_U进程中，UICC和BSF相互认证，并且通过从UICC和HLR/HSS之间共享的用户认证密钥K中得出称为GBA_U密钥的密钥Ks来对其进行建立。

参见图2，用于GBA_U的步骤如图所示，且在下面进一步地描述。在步骤S1，ME向BSF发送HTTP请求用以初始化GBA_U进程。ME在HTTP请求的用户名参数字段中插入用户身份(临时IP多媒体私有身份(TMPI)或者IP多媒体私有身份(IMPI))。在步骤S2，BSF从HLR/HSS(在Zh参考点上)获取认证向量(AV＝RAND‖AUTN‖XRES‖CK‖IK)和GBA用户安全设置(GUSS)，其中AUTN＝SQN_MS⊕[AK]‖AMF‖MAC。BSF然后计算MAC^*(＝MAC⊕Trunc(SHA-1(IK)))。MAC用来保护RAND和AUTN的完整性。BSF在步骤S3将RAND和AUTN^*(＝SQN xor AK‖AMF‖MAC^*)转发给ME，且在HTTP401未授权的WWW-认证：摘要信息中存储XRES，CK和IK。在步骤S4，ME在HTTP401未授权WWW-认证：摘要信息中将接收到的RAND和AUTN^*转发给UICC。在步骤S5，UICC运行AKA算法，即计算IK和XMAC，然后UICC校验AUTN(即SQN⊕AK‖AMF‖MAC)来验证挑战是来自认证的网络；UICC还计算CK和RES。这将导致在BSF和UICC中会话密钥CK和IK的建立，其中Ks＝CK‖IK。在步骤S6，UICC将RES转发给ME。在步骤S7，ME将另一个HTTP请求发送给BSF，该BSF包含使用RES计算的摘要AKA响应。在步骤S8，通过比较接收到的RES和XRES，BSF验证UE的认证，以及在步骤S9，创建Ks＝CK‖IK和引导事务标识符(B-TID)。在步骤S10，BSF发送回包括B-TID和密钥寿命的200OK消息，来指示认证的成功。在步骤S11，ME发送B-TID和密钥寿命给UICC。在步骤S12，UICC存储Ks＝CK‖IK，B-TID和密钥寿命。

在GBA_U进程的最后，如图2中所描述的，如果在例如安全性结合阶段的稍后的阶段中需要的化，UICC和BSF处于能够分别使用它们都必须得出的Ks——网络接入功能(NAF)特定的密钥Ks_ext_NAF和Ks_int_NAF的状态。这些获得的密钥Ks_ext_NAF和Ks_int_NAF稍后将用于保证Ua参考点的安全。Ks_ext_NAF在UICC中作为Ks_ext_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)而被计算，Ks_int_NAF在UICC中作为Ks_int_NAF＝KDF(Ks，″gba-u，RAND，IMPI，NAF_Id)而被计算，NAF_Id＝NAF的FQDN‖Ua安全性协议标识符的。KDF是如TS 33.220-780附录B中指定的密钥得出功能。

在Ks在GBA_U进程中建立后，安全性结合进程出现在NAF和WTRU之间。该进程的目的是用于WTRU和NAF来确定是否使用GBA密钥(Ks_int_NAF和/或Ks_ext_NAF)。默认地，Ks_ext_NAF用于在随后得出将被用来加密WTRU和NAF之间的分组的密钥流。但是，如果使用Ks_int_NAF或者Ks_int_NAF和Ks_ext_NAF，那么将在安全性进程中对此达成协议。应当注意这种协议将否定默认的选择。同样，密钥选择指示还可在特定应用USS中明确指定。

参见图3，图中描述了安全性结合步骤，在开始通信之前，WTRU(ME)校验Ks(GBA_U建立的)是否存在并且通用，以及如果不存在，则GBA_U被初始化来创建Ks。如果Ks是有效且通用的，则在步骤S1，ME从UICC检索B-TID，并且UICC得出Ks_int/ext_NAF密钥。在步骤S2，ME将B-TID作为应用请求的一部分发送给NAF。在步骤S3，ME发送认证请求(incl.B-TID and NAF-ID)给BSF，以在Zn参考点上发送对应于B-TID的密钥。在步骤S4，BSF得出Ks_int_NAF和Ks_ext_NAF。如果NAF是GBA_U，在步骤S4，它将输送两个密钥，否则它仅将Ks_ext_NAF随其他一些信息例如引导时间、密钥寿命等一起提供。如果USS从BSF返回，则NAF浏览USS来检验是否存在密钥选择指示，其中在存在的情况下USS中指示的密钥将被使用，并且NAF将存储所述密钥。在步骤S7，NAF向WTRU发送应用应答，以指示NAF现在拥有密钥Ks_ext/int_NAF。

近来，3GPP TS 33.110-700提出了UICC和终端之间的平台和特定应用密钥Ks_local的建立。该密钥用来由UICC和终端使用以保证它们之间的信道安全。

在终端是UICC支持装置的一部分的情况下的参考点的结构如图4所示。图4的网络元件与图1中所示的相同，除了提供UICC主机设备。在UICC和终端之间建立Ks_local的协议流如图5中所示。在步骤S1，终端通过从UICC获取B-TID和相应的寿命来校验有效的Ks密钥是否存在于UICC中。如果在UICC中没有存在可用的有效Ks，则终端将请求GBA引导过程来建立BSF和UICC之间的Ks密钥。然后，终端校验是否存在有效的Ks_int_NAF，如果存在，则终端请求UICC来检索用于对应于NAF密钥中心的NAF_ID的B-TID值。如果终端没有NAF_ID，则在步骤S2请求UICC来检索该值。在步骤S3，UICC返回对应于NAF密钥中心的B-TID和NAF_ID。在步骤S4，终端和NAF密钥中心用基于终端和NAF密钥中心之间的相互认证的证书，建立HTTP类型隧道。在步骤S5，终端在隧道上发送“服务请求”消息以请求密钥Ks_local和可变值RANDx的建立，所述消息的有效载荷包括B-TID、终端标识符(Terminal_ID)、智能卡标识符(ICCID)、UICC应用的应用标识符(UICC_appli_ID)和终端应用的应用标识符(Terminal_appli_ID)。当期望特定平台密钥而不是特定应用密钥时，参数UICC_appli_ID和Terminal_appli_ID将等于静态ASCII编码的字符串“platform”。在步骤S6，NAF密钥中心确定终端ID/ICCID是否不是黑名单或者密钥建立过程是否允许用以目标应用。如果不满足这些条件，NAF密钥中心以合适的误码进行回应，并且中断与终端的TLS连接。随后在步骤S6，NAF密钥中心联系BSF，并在信任请求(该请求的目的是请求BSF来返回相关的密钥Ks_int_NAF和Ks_ext_NAF。应当注意Ks_local仅从Ks_int_NAF中产生)中发送B-TID和其自身的NAF_ID。在步骤S7，BSF得出Ks_int_NAF和Ks_ext_NAF，向NAF密钥中心返回这些密钥和相关信息，诸如引导时间、密钥寿命等。然后在步骤S8，NAF密钥中心生成为了在UICC中使用的合适的16个八比特组(octet)的计数器限值，并且为了在终端中使用而将密钥寿命与得出的密钥Ks_local相关联。然后从Ks_int_NAF中得出Ks_local，其中使用的密钥获取功能(KDF)如下：

Ks_local＝KDF(Ks_int_NAF，B-TID，Terminal_ID，ICCID，Terminal_appli_ID，UICC_appli_ID，RANDx，计数器限值)

然后在步骤S9，NAF密钥中心在步骤S4中建立的HTTPS隧道上将Ks_local与B-TID、密钥寿命和计算器限值一起传送到终端。在步骤S10，终端在其自己的存储器中存储Ks_local和相关参数，诸如密钥寿命、ICCID、Terminal_appli_ID、和UICC_appli_ID。在步骤S11，终端请求UICC来生成Ks_local，并将密钥材料(NAF_ID，Terminal_ID，Terminal_appli_ID，UICC_appli_ID，RANDx和计数器限值)与依次被截取为16个八比特组＝128个比特的MAC(＝HMAC-SHA-256[Ks_local，NAF_ID‖Terminal_ID‖ICCID‖Term_appli_ID‖UICC_appli_ID‖RANDX‖计数器限值])一起发送给它。在步骤12，UICC检索Ks_int_NAF和B-TID，并生成Ks_local＝KDF(Ks_int_NAF，B-TID，Terminal ID，ICCID，Terminal_appli_ID，UICC_appli_ID，RANDx，计数器限值)。UICC计算依次被截取为16个八比特组＝128个比特的MAC′＝(HMAC-SHA-256[Ks_local，NAF_ID‖Terminal_ID‖ICCID‖Terminal_appli_ID‖UICC_appli_ID‖RANDX‖计数器限值])。计算的MAC′与接收到的MAC进行比较。如果MAC′和MAC不匹配，则在步骤S13将失败消息发送回终端。如果MAC和MAC′之间匹配，则在UICC中存储Ks_local和相关参数诸如Terminal_ID，Terminal_appli_ID，UICC_appli_ID和计数器限值。在步骤S13，UICC将使用Ks_local和依次截取为16个八比特组的MAC算法HMAC-SHA-256创建的“VerificationSuccessful”(验证成功)消息返回到终端。

图5描述了UICC和终端之间的密钥的建立。来自TS33.110v7.2.0的本地密钥建立进程依赖于HTTPS隧道的建立(见图5中的步骤S4)。在TS33.110v7.2.0中，指定HTTPS隧道是使用用户证书建立的，该用户证书对在随后设置隧道时使用的公钥进行验证。最新的3GPP规范TS33.221v7.0.0指出了这种用户证书是使用图6中描述的步骤建立的。

图6中的序列图描述了当使用公钥加密标准(PKCS)#10与HTTP摘要认证时的证书请求。在步骤S1，WTRU向公钥构架(PKI)入口发送空的HTTP请求。在步骤S2，PKI入口使用包含www-认证报头的HTTP响应代码401“未认证”来发送认证挑战响应。报头指示WTRU来使用HTTP摘要认证。WTRU通过使用作为用户名从BSF收到的引导事务标识符(B-TID)和NAF特定会话密钥Ks_NAF来计算授权报头值，从而生成HTTP请求。如果证书请求为了密钥proof-of-origin需要无线身份模块(WIM)应用的额外确保，WTRU生成包含密钥proof-of-origin生成所需的参数的WIM挑战请求。在步骤S4，WTRU发送HTTP请求给PKI入口，并在该请求中包括WIM机会请求。在步骤S5，充当NAF的PKI入口接收请求，通过使用B-TID从BSF获取NAF特定会话密钥，使用Ks_NAF计算相应的摘要值，以及在认证报头将计算的值与接收的值进行比较来验证认证报头。如果验证成功，且需要WIM应用的额外确保，则PKI入口可使用PKI入口特定用户安全性设置来计算WIM挑战响应。在步骤S6，PKI入口发送回包含随后的PKCS#10请求的生成所需的附加参数的WIM挑战响应。PKI入口可以使用会话密钥Ks_NAF来对该响应进行完整性保护和认证。在步骤S7，WTRU生成PKCS#10请求，且在步骤S8，WTRU使用HTTP摘要请求将该PKCS#10请求发送至PKI入口。在私钥存储于WIM应用中的情况下，ME从WIM应用请求AssuranceInfo，并且如果WIM应用提供AssuranceInfo的话，便将其包括在PKCS#10请求中。注册(enrollment)请求将遵循PKCS#10证书注册格式。OMA ECMA脚本规范中定义了在请求中增加AssuranceInfo。AssuranceInfo为密钥处理提供出处证明(Proof of Origin)。(例如识别WIM应用且提供密钥存储在其中的证据)。WTRU可指示认证响应所期望的格式：证书、指向证书的指针(如URL)，或者完全证书链(即从颁发的证书到相应的根证书)。WTRU向PKI入口发送证书注册的HTTP请求。注册请求应当如下：

POST<base URL>？response＝<indication>[other URL parameters]

HTTP/1.1

Content-Type:application/x-pkcs10

其中<base URL>标识服务器/程序。标签<indication>用来向PKI入口指示WTRU的期望响应类型。可能的值是：仅用于用户证书的“单一”，用于指向用户的指针的“指针”或者用于完全证书链的“链”。进一步地，其他的URL参数是附加的或者是可选的参数。在步骤S9，PKCS#10请求由PKI入口处理。如果PKI入口是认证授权(CA)，则证书是在PKI入口生成的。如果PKI入口仅是注册授权(RA)，而不是CA，PKCS#10请求转发给使用任何可用协议的CA，例如IETF RFC 2797中指定的CMC，或者IETF RFC 2510和IETF RFC 2511中指定的CMP。在这种情况下，在PKCS#10请求已经处理且证书已经创建后，新的证书返回到PKI入口。在任何一种情况下，在S10，PKI入口生成包含证书或者OMA无线PKI规范(WPKI)的条款7.4定义的指向证书的指针，或者从颁发的证书至根证书的完全证书链的HTTP响应。如果HTTP响应包含用户证书本身，则基于64编码，且可以如下来标定：

HTTP/1.1 200OK

Content-Type:application/x-x509-user-cert

-----开始证书-----

-----结束证书-----

如果HTTP响应包含指向证书的指针，则应当使用OMA WPKI的子条款7.3.5中定义的CertResponse架构，且且可以如下来标定：

HTTP/1.1 200OK

Content-Type:application/pkix-pkipath

-----开始证书响应-----

-----结束证书响应-----

如果HTTP响应包含PkiPath结构中定义下的完全证书链，且应当基于64编码：

HTTP/1.1 200OK

Content-Type:application/pkix-pkipath

用于证书链的content-type报头值是“application/pkix-pkipath”。如果证书或者指向该证书的指针发送给WTRU，则PKI端口可使用会话密钥Ks_NAF来对该响应进行完整性保护和认证。如果完全证书链发送给WTRU，则PKI入口应使用完整性保护并认证该响应。当WTRU接收用户证书或者指向用户证书的URL时，在步骤S11，将被存储在本地证书管理系统中。

现有技术的问题

GBA_U进程和安全性结合进程具有隐私问题，这是因为在这两个进程中，在UICC和终端之间的安全本地信道或者终端和BSF(或者NAF)之间的安全信道形成之前，UICC和终端会在它们之间的开放信道上交换很多参数，同样的情况也会出现在终端和网络(BSF、NAF)之间。例如，诸如AUTN和RAND的参数从BSF至UICC的传输是开放信道上的明文。UICC和BSF之间的完整性保护被分别提供给认证信息(AUTN)和通过使用消息认证码(MAC)(和期望的MAC(XMAC))和用户响应(RES)(和期望的RES(XRES))来充当现时(即在安全工程中仅使用一次的数或比特流)的随机数(RAND)。但是，由于信道是开放的，就会有窃听、引起隐私问题的风险以及由于密码分析而将K最终暴露的风险。

现有技术还包括由于会话密钥的开放信道传送引起的问题。在UICC内部得出(在得出过程中使用Ks或者Ks_NAF)的会话密钥从UICC传送给终端，以供终端随后在会话加密或者解密使用，而且该过程在不安全的信道上执行。因此，窃听代理可以截取会话密要，并且对在终端和网络之间交换的消息进行加密或者解密。在该事件中，很多随后需要在终端和NAF密钥中心之间建立HTTPS隧道以供后者得出并传送(从NAF密钥中心)本地密钥(Ks_local)的过程，例如用户证书建立，将会有被破坏的风险。由于本地密钥本身是在HTTPS隧道上传输的，因此会话密钥被破坏将引起本地密钥被破坏。随后，如果本地密钥在重置或者电话启动后保持不变，当本地密钥在UICC和终端之间的加密信息传输中使用，所有这些通信都会有风险。

本地密钥建立中的问题

TS 33.110-720中的建立Ks_local的过程具有以下问题：

1)由多个OTA连接导致低效率-终端必须穿过空中GBA_U进程来建立Ks密钥。为了尝试建立得出自Ks的Ks_local，其中Ks本身基于UICC和HSS之间共享的用户密钥(K)Ks_local，TS33.110提出，UICC和终端之间的Ks_local的密钥建立过程再次遵循无线协议，以及每一个指定应用的NAF都被用于该信道。由于标准允许多个不同的本地密钥以这种方式生成，其中每一个都特定的用于不同NAF，因此如果想要建立多个这种密钥，必须经过很多OTA过程。

2)信息隐私问题-很多参数的值是在UICC和终端之间的开放信道上传输的，例如NAF_ID、终端ID、Terminal_appli_ID、UICC_appli_ID、RANDx和计数器极值。这些参数中的部分如果被暴露将会导致隐私风险。

3)在NAF密钥中心和终端之间的HTTPS隧道中-在3GPP TS33.110 V7.2.0中(见图5，步骤S4和S5)，隧道应使用基于证书的相互认证来创建，并应当用于从NAF密钥中心至终端的密钥材料和Ks_local的传输。用户证书可颁发给终端或者在UICC中运行的应用。用于建立用户证书的私钥和公钥可存在于UICC中或者在终端上。在多种这类情况下，由于需要在UICC和终端之间的不安全信道上传送这些敏感信息，如私钥或者公钥或者用户证书或者Ks_ext_NAF密钥，因此存在有安全性弱点。一些方案和与这些方案相关的弱点在下文中描述：

图7-9示出了三(3)种不同的用户证书建立进程的方案。

在方案A1中，如图7所示，私钥/公钥对位于终端。UICC通过HTTP会话同PKI(＝NAF)建立用户证书。假定GBA/GBA_U过程已经发生，Ks_NAF/Ks_ext_NAF密钥出现在UICC上。在方案A1的当前方案中存在缺陷。最值得注意的，在步骤S5，终端不得不在开放信道上向UICC发送用于验证的公钥。另外，在步骤S11，UICC在开放信道上向终端发送用户证书(用于HTTPS会话)。

在方案A2中，如图8所示，私钥/公钥对位于终端。终端通过HTTP会话同PKI(＝NAF)建立用户证书。假定GBA/GBA_U过程已经发生，Ks_NAF/Ks_ext_NAF密钥如步骤S1所示出现在UICC上。在方案A2的当前方案中存在缺陷。最值得注意的，在步骤S1，UICC在开放信道上向终端发送Ks_ext_NAF(其中终端需要在用户证书会话中验证HTTP摘要)。

在方案A3中，如图9所示，私钥/公钥对位于终端。终端通过HTTP会话历经步骤S1-S11同PKI(＝NAF)建立用户证书。假定GBA/GBA_U过程已经发生，Ks_NAF/Ks_ext_NAF密钥如步骤S1所示出现在UICC上。在步骤S1，终端在由会话密钥Kss保证安全在OTA信道上用PKI(＝NAF)接收Ks_ext_NAF。应当注意，这样假定标准中存在变化，即Ks_ext_NAF从PKI(NAF)发送至终端。然而，在方案A3的当前方案中存在缺陷。当前，终端使用任何会话密钥，从而如步骤S0所示，Ks不得不在当前电话架构下由UICC在开放信道上发送至终端。这就意味着窃听者可以截取会话密钥，且解密任何消息(包括用户证书进程消息)。这种缺陷(会话密钥的清楚传输)是普遍问题，甚至能够影响第一AKA进程。如图10-11中示出本地密钥建立进程的两种(2)不同的方案。

在方案B1中，如图10中所示，私钥/公钥对位于终端。在步骤S4，终端使用进程A中建立的用户证书来建立HTTPS隧道(TS 33.110)。在方案A3的当前方案中存在缺陷。最值得注意的，在步骤S10，终端在开放信道上发送用于证书的公钥给UICC。而且，在步骤S12，UICC在开放信道上发送用户证书(用于HTTPS会话)给终端。

在方案B2中，如图11所示，私钥/公钥对位于UICC。在步骤S5，终端使用进程A中建立的用户证书来建立HTTPS隧道(TS 33.110)。但是，在方案B1中有着与当前方案相关的缺点。最值得注意的，在UICC和终端之间没有安全信道。而且，攻击者可截取用户证书和密钥(由于密钥在开放信道上由UICC发送给终端，如步骤S4所示)，这引起HTTPS隧道泄密。另外，Ks_local被透露给攻击者，见步骤S13。

发明内容

3G UMTS移动电话系统依赖于被称为UMTS集成电路卡(UICC)的受保护的智能卡，该智能卡提供UMTS用户身份模块(USIM)应用以作为用来保护3G移动终端和UMTS无线网络(或者UTRAN)之间的通信路径的各种安全性措施的基础或者根本

UICC与终端(ME)和引导服务器功能(BSF)交换信息，其中多个特定用于应用和网络应用功能(NAF)(Ks_local)的本地密钥被用于得出用来加密UICC和终端(ME)之间的本地信道的密钥，其中所述本地密钥本身由特定NAF密钥(Ks_int/ext_NAF)的多个实例得出，消除在空中(OTA)过程从而为每个NAF得出密钥。在此提出的方法使得能够得出本地密钥，与“整体”(bulk)进程中的多个NAF进行安全性关联，以及减轻额外OTA连接的需要。

在此提出的另一个概念是内部密钥中心(IKC)的使用。IKC是无线发射/接收单元(WTRU)中的可信实体，该可信实体具有与外部NAF功能中的一些相类似的功能，直到获得中间密钥材料以及最终的Ks_local。

为IKC提出了几种可选的实施方式。在一种实施方式中，IKC用作终端，IKC是可信的，且能复制NAF密钥中心功能，以及提供功能(如OTA通信性能)和Ks_local的生成所需的数据。在另一种实施方式中，IKC用作可信实体，该可信实体位于ME中但与终端分离，并且能够用作NAF密钥中心的代理。

还提出了基于可信计算的方法，一起来保护IKC的完整性和使用，使得IKC能够安全充当诸如NAF这样的外部网络的代理或者替换。

附图说明

从以下关于优选实施方式的描述中可以更详细地理解本发明，这些实施方式是以实例的方式给出的，并且可以结合附图被理解，其中：

图1示出了用于涉及BSS的引导的参考模型；

图2示出了描述使用基于UICC的增强的GBA_U引导进程的流程图；

图3示出了在GBA_U实施后进行安全性结合的进程；

图4示出了终端是UICC主机设备的一部分的参考模型；

图5示出了UICC和终端之间的密钥的建立；

图6示出了使用带有HTTP摘要认证的PKCS#10的证书请求；

图7示出了方案A1中的用户证书进程；

图8示出了方案A2中的用户证书进程；

图9示出了方案A3中的用户证书进程；

图10示出了方案B1中的本地密钥建立进程；

图11示出了方案B2中的本地密钥建立进程；

图12a示出了安全无线通信系统的实例框图；

图12b示出了UIICC和HLR/HSS共享K_UH的情况；

图13示出了UICC和IKC共享对称机密密钥K_{sym_UI}的实施方式；

图14示出了由IKC执行的用于正确K_IH识别的进程，以及随后TLS-PSK隧道建立；

图15示出了由BSF执行的用于正确K_IH识别的进程，以及随后TLS-PSK隧道建立；

图16示出了本公开中描述的WTRU和NAF之间的安全性结合；

图17示出了UICC和终端之间的Ks_local建立进程；

图18示出了MTM保护IKC、密钥以及IKC处理的数据的完整性的方法；

图19示出了MTM连接在终端和IKC之间的系统。

规范中使用的缩写

3GPP 第三代合作伙伴计划

AK 匿名密钥；计算为AK＝f5_K(RAND)

AKA 认证和密钥协议

AUTN 认证令牌

AV 认证向量

B-TID 引导事务标识符

BSF 引导服务器功能

CA 证书授权

CK 密码密钥

FQDN 完全合格域名

GAA 通用认证架构

GBA 通用引导架构

GBA_ME 基于ME的GBA

GBA_U 带有基于UICC增强的GBA

GUSS GBA用户安全性设置

HLR 归属位置寄存器

HSS 归属用户服务器

HTTP 超文本传输协议

ICCID 集成电路卡标识

IK 完整性密钥

IKC 内部密钥中心

IMPI IP多媒体私有身份

KDF 密钥得出功能

K 用户认证密钥(TS33.105第5.1.7.1节)

Ks_IKC_NAF 提出的密钥，该密钥在BSF计算，并将被用作用来在

UICC和IKC之间为IKC和终端之间的安全本地信道得

出本地密钥的密钥材料，

Ks_ext_NAF GBA_U中得出的密钥

K_IH 本发明中IKC和HLR/HSS之间的预先共享的密钥

K_{sym_UI} UICC和IKC之间的预先共享的对称密钥

K_UH 本发明中UICC和HLR/HSS之间预先共享的密钥

Ks_IKC_NAF 在UICC和BSF得出，将被用于NAF特定Ks_local的得出

Ks_int_NAF 保留在UICC上的GBA_U中得出的密钥

Ks_local 得出密钥，该密钥在终端和UICC之间共享

MAC 消息认证码

MAC_NAF 本发明中NAF生成的MAC(在Part 2)

MAC_IKC 本发明中IKC生成的MAC(在Part 3)

MAC_UICC 本发明中UICC生成的MAC(在Part 3)

MAC_{UICC_SA} 本发明中NAF生成的MAC(在Part 2)

MNO 移动网络运营商

MTM 移动可信模块

NAF 网络应用功能

NAI 网络接入标识符

OTA 空中

PKI 公钥架构

RAND 随机挑战

RANDx IKC生成的用于Ks_local得出的随机挑战

RANDy IKC生成的用于Ks_IKC_NAF得出的随机挑战

RES 用户响应

SLF 用户位置功能

SQN 序列号

T_IB IKC和BSF之间的TLS类型隧道

T_UI IKC和IKC之间的TLS类型隧道

TCG 可信计算组

TLS 传输层安全性

TMPI 临时IP多媒体私有身份

USS 用户安全性设置

UE 用户设备

USIM 用户服务身份模块

XMAC 用于认证和密钥协议的期望MAC

XRES 期望的用户响应

具体实施方式

下文涉及的术语“无线发射/接收单元(WTRU)”包括，但并不限于用户设备(UE)、移动站、固定或移动用户单元、寻呼机、无线电话、个人数字助理(PDA)、计算机或者能在无线环境下操作的任何其它类型的用户设备。下文涉及的术语“基站”包括但并不限于节点B、站点控制器、接入点(AP)或者能在无线环境下操作的任何其它类型的接口设备。在下面的详细描述中，术语ME是与终端同义的，并且这些术语是可交换的。UE是用来共同识别UICC和终端(或者ME)的合并。可信移动电话与终端同义，但是在TGC中可信，电话与终端同义。远程装置识别UE，其中UICC和用于UICC的读卡器没有处在包含UE的相同的物理封装中，但是通过远程连接与UE连接，例如USB电缆、无线连接及类似。

描述了一种新的方法来解决现有技术中的问题，并且增强现有进程的安全性和效率，例如GBA_U、安全性结合和特定用于NAF的本地密钥Ks_local的建立。该方法是基于以下假定或者需求的。

假定如下：

1.内部密钥中心(IKC)，作为WTRU中的实体被提供，具有与外部NAF密钥中心相似的功能。

a.在以下考虑的实施方式中，IKC还用于ME的通信功能(到网络和UICC)。在这点上，IKC可被当作具有外部NAF密钥中心的其它功能的终端。

b.IKC的假定功能的详情是如下描述的。

2.IKC和HLR/HSS可能在建造或者销售时就具有规定的预先共享机密K_IH。

a.引导服务功能(BSF)假定能安全地从HLR/HSS检索K_IH。

b.K_IH用来建立IKC和BSF之间的传输层安全性预先共享密钥(TLS-PSK)隧道，在此后称之为隧道T_IB。

3-A.UICC和HLR/HSS共享密钥K_UH，不同于UICC和HLR/HSS已经在它们之间为现有的GBA_U进程共享的用户机密K。

a.BSF假定能够安全地从HLR/HSS检索K_UH。

b.BSF还假定能够将该密钥K_UH安全地、加密的并使用TLS-PSK隧道T_IB转发到IKC。

c.一旦将K_UH从BSF传送到IKC，那么K_UH可被用来建立UICC和IKC之间的TLS-PSK隧道，在下文中，称之为隧道T_UI。隧道T_UI具有短暂的安全性寿命，从而仅可用于有限时间。

3-B.作为3A的可替换方案，UICC和HLR/HSS共享密钥K_UH，UICC和IKC假定被预先规定为带有预先共享的对称密钥K_{sym_UI}，这种规定是在制造或者销售时提供。

4-A.UICC可使用共享密钥K_UH加密和解密消息。

4-B.采用3B假定，UICC可使用共享对称密钥K_{sym_UI}加密和解密消息。

5-A.IKC可使用共享密钥K_UH加密和解密消息。

5-B.采用3B假定，IKC可使用预先共享对称密钥K_{sym_UI}加密和解密消息。

6.UICC和BSF均可得出一个或多个密钥Ks_IKC_NAF，每一个特定用于每一个NAF，且用于生成NAF特定密钥Ks_local。

7.IKC和BSF均可以交换密钥材料用于每一个OTA应用响应交换中的多个NAF。

8.在接收到IKC的标识信息(下文称为ICK_ID)后，BSF可识别已经历史上认证过的或者期望来认证的UICC_ID，并且使用这些可能的多个UICC_ID来识别对应于认证过的或者期望来认证的UICC_ID的多个可能准确的密钥{K_UH}。BSF还可以将集合{K_UH}中的一个、多个或者所有的都同时或者顺序发送给IKC，并且允许IKC来测试这些密钥中的哪一个可以与主UICC一起使用。

9.移动可信模块(MTM)满足TGG移动可信模块规范v0.1和与它相关的位于WTRU中的软件堆栈；UE是满足TGG可信移动电话参考架构规范的规定的可信的移动电话。MTM是用于创建、检验和验证IKC和UICC的状态，并且还用于安全存储IKC处理用以GBA_U、安全性结合和安全本地密钥建立进程的密钥和数据。

内部密钥中心(IKC)

在一种实施方式中，IKC是终端的一部分，能够使用3G空中接口，并最终实现与BSF在空中通信。在一种可替换的实施方式中，IKC是独立于终端的实体。IKC是可信组件，其完整性和可信度可被WTRU中的MTM验证。MTM在一种实施方式中是终端(或者WTRU)的一部分。在具有MTM和IKC作为终端(或者WTRU)一部分的实施方式中，无线连接可由有线连接替代。IKC具有加密能力来建立IKC自身和UICC之间的TLS类型隧道，以及与BSF之间的TLS类型隧道。隧道用来保护在GBA_U过程和安全性结合，还有在UICC和终端之间的安全信道建立过程中交换的信息的完整性和机密性。IKC能够与BSF建立TLS-PSK隧道。BSF假定能够与IKC支持这种隧道。在我们提出的版本中第一部分和第二部分中，IKC执行终端需要来执行现有技术的GBA_U和安全性结合过程的功能，以及需要用来创建和使用两个TLS隧道的功能，一个隧道在IKC和UICC之间，另一个在IKC和BSF之间。在我们的技术的第三部分，IKC执行的功能类似于外部NAF密钥中心执行的功能。这些功能包括：1)生成计数器限值；2)生成一对或者多对随机数RANDx和RANDy，每一个特定用于NAF，且用来得出NAF特定的Ks_local；3)使用KDF得出Ks_local；以及4)在IKC是独立于终端的实体的情况下，将Ks_local转发给终端。

图12a示出了根据上述假定配置的安全无线通信系统的示例性框图。无线通信系统包括WTRU 1200。WTRU 1200包括终端1210、调制解调器1220和无线电(RF)单元1230。终端1210包括移动可信模块(MTM)1240和内部密钥中心(IKC)1250。IKC单元1250被配置为与外部UICC 1260进行通信。RF单元1230被配置为与引导服务器功能(BSF)1270在空中接口1275上通信。BSF 1270与HLR/HSS 1280通信，并且可选地，与其他网络应用功能(NAF)(未示出)通信。

使用IKC过程的改进的密钥得出和安全性结合(SA)被划分为三部分，如下所述：

过程第一部分(部分-1)使用与图12所示的第一种实施方式一致的改进的GBA_U进程。在现有方法上的一个改进是现在该进程在新提出的在WTRU中的实体IKC 1250的控制下在两个TLS类型信道上执行。参见图12，在步骤S1，IKC 1250发送建立IKC 1250和BSF 1270之间的TLS-PSK隧道的请求。请求消息包括IKC 1250_ID作为有效载荷。接下来，在步骤S2，BSF 1270从HSS/HLR检索预先共享密钥(K_IH和K_UH)。K_IH用来建立IKC1250和BSF 1270之间的TLS-PSK隧道，而K_UH是用来建立UICC 1260和IKC 1250之间的隧道。IKC 1250和BSF1270之间的TLS-PSK隧道(T_IB)在步骤S3建立，采用基于预先共享的机密(K_IH)的相互认证。在步骤S4，BSF 1270在隧道T_IB上发送K_UH给IKC 1250。在步骤S5，UICC 1260和IKC1250使用基于预先共享的密钥(K_UH)的相互认证来建立TLS-PSK隧道(T_UI)。发生GBA_U，导致在UICC 1260和BSF 1270都建立Ks。最后，在GBA_U过程结束时在BSF1270(参见S7a)和UICC1260(参见S7b)上建立Ks＝CK‖IK。NAF_ID还在UICC 1260上按如下构造：NAF_Id＝NAF‖Ua安全性协议标识符的FQDN。在该过程中，UICC 1260假定与HLR/HSS 1280共享密钥K_UH。

作为替换方案，图13描述了被修改的GBA_U的步骤，其中UICC 1260与IKC 1250直接共享预先规定的对称密钥K_{sym_UI}(参见S4)。仅仅对那些不同于图12的步骤进行描述。在步骤S2，仅将共享密钥K_IH提供给BSF 1270。图13的步骤S4使用K_{sym_UI}建立了TLS-PSK隧道。图13的步骤S5与图12的步骤S6相同。图13中步骤S6a和步骤S6b与图17中的步骤S7a和步骤S7b相同。图13这种可替换的进程具有缺点，UICC 1260和IKC 1250直接共享预先规定的密钥K_{sym_UI}的需求可以导致在特定的UICC 1260和特定的IKC 1250之间创建不必要的强烈“绑定”，从而UICC 1260的上述可在不同类型的装置中装载的携带性变得更难实施或者管理。

如图12所示的过程，BSF 1270被配置为收集对应于UICC 1260的多个密钥{K_UH}(如果需要的话)，其中HLR/HSS 1280可能已经通过连接到或者期望连接到给定的IKC 1250对所述UICC有所了解。BSF 1270能够发送多个密钥，且IKC 1250随后可以同UICC 1260执行挑战响应类型密钥验证过程，直到识别出正确的密钥K_UH。该过程的一种实施方式如图14中所描述。将仅描述不同于图13的步骤，在步骤S2，向BSF 1270提供了K_IH和多个密钥{K_UH}。IKC 1250请求(步骤S5)并且然后从UICC 1260接收(步骤S6)nonce‖hash(K_UH⊕nonce)。计算每一个K_UH(步骤S7)以找到正确的K_UH来与UICC 1260建立TLS-PSK隧道T_UI。

如图14所描述的进程的可替换方案，我们提出了密钥验证技术，其中IKC 1250没有从BSF 1270接收到所有的可能密钥K_UH。而是，IKC 1250从UICC 1260接收到证据密钥K_UH(参见图15，步骤S4和S5)，并且将其传递给BSF 1270(步骤S6)，BSF 1270然后执行该过程来识别可能的密钥集合{K_UH}中的正确密钥，如图15的步骤S6所示。正确的K_UH传递给IKC 1250(步骤S7)以用于同UICC 1260建立TLS-PSK隧道。该方法相比在图14中描述的方法具有很多优点，BSF 1270不会冒多个候选密钥OTA公开的风险。

在图12b中描述的TLS-PSK隧道建立进程中，IKC 1250_ID的初始信息从IKC 1250传送到BSF 1270当前只在物理层保护上执行(即被UIA和UEA会话密钥保护)。如果，如之前所描述的，这种会话密钥易受到窃听，那么IKC 1250-ID也会变得易受到窃听，导致隐私的公开。

可在图14中采用可选的步骤来保护IKC 1250的身份，其中IKC 1250和BSF 1270使用基于公钥的IKC 1250_ID的加密和解密，还使用TLS-PSK隧道建立进程中交换的其他信息。以证书为基础的方法容易出现安全性风险且难以解决，为了代替这种方法，有人提出，IKC 1250和BSF 1270可以使用迪菲-海尔曼(DH)密钥交换过程来建立各自的公钥。实际上，IKC 1250可获得数量为相当大的数目n的很多个不同的公钥，并且从中选择一个，其中这些密钥从网络上广播。DH密钥交换协议可用于该目的。

通信者将该协议在公钥集合中应用来计算公共索引，诸如a。为了完成这个过程，首先，网络和IKC 1250就公知的两个值达成一致：非常大的质数p以及域F_p的乘法群F_p ^*的生成元g。然后网络选择随机数RAND_i，计算

g_{{RAND}_{i}} &equiv; g^{{RAND}_{i}} \mod p,

并且发送

给IKC 1250(1≤RAND_i≤p-2)。IKC 1250然后计算随机数FRESH，计算g_FRESH≡g^FRESH mod p，并且发送g_FRESH给网络(1≤FRESH≤p-2)。然后，网络计算

k &equiv; g_{FRESH}^{{RAND}_{i}} \mod p .

最后，IKC 1250计算

k^{'} &equiv; g_{{RAND}_{i}}^{FRESH} \mod p .

很简单地示出了k≡k′mod p。已经计算了k(0≤k＜p)的IKC 1250和网络通过简单地对k模n的方式来减小k从而可以计算共钥的机密索引a。即，a≡k mod n。使用所述公钥k_a，所述共钥对应于索引a的，IKC 1250加密包括IKC 1250_ID的消息，并且网络使用对应k_a的密钥来解密消息。

IKC 1250_ID的机密性被获取，这是因为网络是RAND_i的单独处理器，并且IKC 1250是FRESH的单独处理器，仅这两个信息参入者能计算k。攻击者没有这两个被离散算法问题的计算不可行性所保护的随机值。

消息机制与公钥集合的分发相关。可轻易成为小区广播消息结构的一部分。但是，还需要其它消息机制来用于从网络至IKC 1250的

传输，以及从IKC 1250至网络的值g_FRESH的传输。这些机制优选地包括用于上述定义的公共值p和g的网络/IKC 1250协议进程。

关于传送多个密钥的网络，所述密钥为向IKC 1250指定的K_UH，可使用反复相互(挑战响应)认证进程，对每一个密钥使用一个，直到获得成功的K_UH。如果对所有的密钥认证均失败，则UICC 1260被拒绝。

上述描述的公钥的DH交换还可以作为TLS-PSK隧道建立进程的一部分来执行。在这种情况下，IKC 1250_ID将被包括在TLS-PSK握手进程中从IKC1250至BSF1270的初始交换消息中。应当注意用于TLS-PSK扩展的RFC4279允许四个不同的加密组用于DH TLS-PSK进程，这是：

1.TLS_DHE_PSK_WITH_RC4_128_SHA

2.TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA

3.TLS_DHE_PSK_WITH_AES_128_CBC_SHA

4.TLS_DHE_PSK_WITH_AES_256_CBC_SHA

由于现有的RC4算法的加密强度问题，只有分别带有3DES、AES128或者AES256的后3个加密组可以使用。

部分-2：NAF和UE之间的安全性结合

第二部分是安全性结合进程，由于使用了两个(2)TLS-PSK隧道来确保UICC 1260和IKC 1250之间以及IKC 1250和BSF 1270之间信息交换的安全，因此该进程优于现有技术中具有相同名称的进程。其他的改进是在IKC 1250和BSF 1270的帮助下，UICC 1260可与整体密钥建立机制中的多个NAF建立密钥。

参见图16，示出了第二部分的详细步骤。在步骤S1，IKC 1250校验在UICC 1260上是否存在通用且有效的Ks，如果是，则IKC 1250在已经建立的隧道(T_UI)上从UICC 1260检索B-TID和NAF_ID(或者其他NAF的身份，利用该身份UICC 1260希望来建立安全性结合)。UICC 1260还在步骤S1中得出Ks_int/ext_NAF密钥。如果Ks不存在或者无效，GBA_U初始化用以建立Ks。在步骤S2，IKC 1250在隧道T_IB上将NAF_Ds和B-TID转发给BSF 1270。在步骤S3，BSF 1270将认证请求发送给期望的NAF(出于简单，在图16中仅示出了一个NAF)。在步骤S4，BSF 1270从NAF接收认证响应。如果NAF被认证，则在步骤S5，BSF 1270得出NAF特定密钥(Ks_int/ext_NAF)。在步骤S6，BSF 1270将Ks_int/ext_NAF密钥与引导时间和密钥寿命一起转发给所有的NAF。在步骤S7，每一个NAF发送给BSF1270用于指示接收到Ks_int/ext_NAF、密钥寿命和引导时间的应答消息。在步骤S8，BSF 1270将这些消息聚集，并且将整体安全性相关消息在TLS-PSK隧道T_IB上发送给IKC 1250，该消息包含多个MAC_NAF，每个MAC_NAF对应于特定的NAF，其中已经在步骤S5-S7中建立了用于所述NAF的Ks_int/ext_NAF。对于每一个MAC_NAF消息，MAC_NAF＝HMAC-SHA-256(Ks_ext_NAF‖Ks_int_NAF‖NAF_ID‖GUSS)对每一个NAF都被截取为16个八比特组。在步骤S9，IKC 1250在TLS-PSK信道T_UI上将在步骤S8中从BSF 1270接收到的该整体安全性结合消息转发给UICC 1260。在步骤S10，UICC 1260为每一个NAF计算特定用于该NAF的MAC_{UICC_SA}，从而MAC_{UICC_SA}＝被截取为16个八比特组的HMAC-SHA-256(Ks_ext_NAF‖Ks_int_NAF‖NAF_ID‖GUSS)。在步骤S11，整体安全性结合响应消息由UICC 1260创建，其中包括了UICC 1260和所有NAF之间的安全性结合的成功和/或失败。对于任何一个NAF，当MAC_IKC与其对应的MAC_{UICC_SA}不匹配时，会探测到失败。该失败是由字符串指示的，例如，“security associationfailure”||NAF_ID。当MAC_IKC与其对应的MAC_{UICC_SA}匹配时，则会探测到成功。该成功响应包含使用密钥Ks_int/ext_NAF和截取为16八比特组的MAC算法HMAC-SHA-256的ASCII-编码的字符串“Security AssociationSuccessful”的消息认证码(MAC)。在步骤S11，整体安全性结合响应消息在T_UI和T_IB隧道上经由IKC 1250发送给BSF 1270。在步骤S12，BSF 1270向每一个NAF发送特定用于该NAF的安全性结合尝试的失败或者成功状态。在步骤S13，所有接收到成功状态的NAF存储密钥(Ks_int/ext_NAF)、引导时间和相关的密钥寿命。

部分-3：终端和UICC 1260之间的密钥建立(Ks_local)

第三部分是UICC和终端之间的本地密钥建立的进程。与现有技术相比该部分的优点是：两个TLS-PSK隧道的使用保证了UICC 1260和IKC 1250之间以及IKC 1250和BSF 1270之间的信息交换的安全。第二，UICC 1260和终端，在IKC 1250和BSF 1270的帮助下，建立多个本地密钥，每一个特定用于不同的NAF，而不需终端像现有技术中所需要的那样与不同的外部NAF密钥中心建立多个OTA连接。

图17示出了第三部分的详细步骤，在步骤S1，IKC 1250检查在UICC1260上是否存在通用且有效的Ks。如果存在的话，则IKC 1250从UICC 1260检索B-TID和一个或多个NAF_ID。当没有通用的或者有效的Ks时，则初始化新的GBA_U进程来建立Ks，在其后，IKC 1250从UICC 1260检索B-TID和一个或多个NAF_ID。需要用于上述过程的在UICC 1260和IKC 1250之间的所有的信息交换都在TLS-PSK隧道T_UI上提供。在步骤S2，IKC 1250向BSF 1270发送对一个或多个密钥Ks_IKC 1250_NAF的应用请求，每一个对应于被请求的NAF的NAF_ID。IKC 1250还将B-TID，以及一个或多个NAF_ID与对应的RANDy现时一起在TLS-PSK隧道T_IB上发送。BSF 1270计算一个或多个IKC 1250密钥Ks_IKC 1250_NAF，每一个特定用于每一个被请求的NAF，其中Ks_IKC 1250_NAF＝KDF(Ks_int_NAF，RANDy)。然后，在步骤S3，BSF 1270向IKC 1250发送包含所有Ks_IKC 1250_NAF密钥的和其各自(NAF-特定)密钥寿命的应用响应。在步骤S4，IKC 1250生成计数器限值值(每一个专用于被请求的NAF中的一个相关的NAF)，并且得出一个或多个本地密钥Ks_local，其中Ks_local＝KDF(Ks_IKC 1250_NAF，B-TID，Terminal_ID，ICCID，Terminal_appli_ID，UICC_appli_ID，RANDx，计数器限值)。应当注意到，在本地密钥是平台特定密钥的情况下，UICC_appli_ID和Terminal_appli_ID八比特组字符串设置为等于静态的ASCII编码的字符串“platform”。在步骤S5，IKC 1250在隧道T_UI上发送应用请求消息给UICC 1260，请求UICC 1260来创建专用于NAF_ID的Ks_local。该请求的有效载荷包括NAF_ID、Terminal_ID、Terminal_appli_ID、UICC_appli_ID、RANDx、RANDy、以及计数器限值值。该终端还包括MAC_IKC，该MAC_IKC计算为MAC_IKC＝被截取为16个八比特组的HMAC-SHA-256(Ks_local，NAF_ID‖Terminal_ID‖ICCID‖Term_appli_ID‖UICC_appli_ID‖RANDx‖RANDy‖计数器限值)。应当注意，在这是平台特定密钥的情况下，UICC_appli_ID和Terminal_appli_ID八比特组字符串被设置为与静态ASCII-码字符串“platform”相等。UICC 1260检索与接收到的NAF_ID相关的B-TID和Ks_int_NAF，首先根据Ks_IKC 1250_NAF＝KDF(Ks_int_NAF，RANDy)得出Ks_IKC 1250_NAF，然后得出Ks_local，其中Ks_local＝KDF(Ks_IKC 1250_NAF，B-TID，Terminal_ID，ICCID，Terminal_appli_ID，UICC_appli_ID，RANDx，计数器限值)。在步骤S6，UICC1260通过计算MAC_UICC＝截取为16八比特组的HMAC-SHA-256(Ks_local，NAF_ID‖Terminal_ID‖ICCID‖Term_appli_ID‖UICC_appli_ID‖RANDx‖RANDy‖计数器限值)，并将其与MAC_IKC比较，来验证从终端接收到的MAC_IKC 1250值。如果MAC_UICC不等于MAC_IKC，UICC 1260终止密钥协议进程，并且返回MAC验证失败消息，以响应Ks_local得出请求。如果MAC_UICC＝MAC_IKC，则UICC 1260存储Ks_local和与其相关的参数(Terminal_ID，Terminal_appli_ID，UICC_appli_ID and the Ks_local计数器限值)。在步骤S7，UICC 1260使用密钥Ks_local和被截取为16个八比特组的MAC算法HMAC-SHA-256来发送包含ASCII码的字符串“verificationsuccessful”的MAC的Ks_local得出响应。在步骤S8，IKC 1250存储Ks_local和密钥寿命。对于每一个NAF重复步骤S4至S8，其中为所述每一个NAF都请求了本地密钥Ks_local。

在上面描述的方法中，在可替换的实施方式中，预先共享的密钥K_UH和K_IH不是直接使用的，而是用作预先共享的机密，实际共享的密钥是从这些预先共享的机密得出出来的。得出的共享密钥可以更新，即它们可以变为会话密钥。在这种方式下，即使从K_UH或者K_IH得出的会话密钥被泄露，机密本身仍然可以受到保护。

参见上面描述的TLS-PSK隧道，使用预先共享的机密的认证加密的其他方法可作为替换方案。一个可替换的实施方式在远程认证拨入用户服务(RADIUS)上合并可扩展认证协议(EAP)的使用。这种可替换的方法可应用于以下进一步描述的新提出的协议中的所有三部分。

另外，在上面描述的过程中，TLS无需隧道技术即可使用，即TLS仅用于加密和认证，而不用于授权。

普适于上面描述的方法的要求如下，预先共享的密钥或者从预先共享的密钥得出的会话密钥用来保护GBA_U、安全性结合，以及本地密钥生成进程仅用于本地密钥Ks_local第一次生成的情况。如果在本文提出的机制的保护下生成本地密钥Ks_local，并确保其存在于UICC 1260和终端上(甚至在关闭电话或者移除UICC之后)，且如果在NAF密钥中心维持Ks_local(用于管理目的)，则当以后三个进程即GBA_U、安全性结合或者本地密钥得出进程中的任何一者再次发生时，不需要在以后对提出的过程进行重复。这是因为在这种情况下，已经生成的且安全存储的本地密钥Ks_local可替代在本公开中提出的预先共享的密钥来使用，以保护在原始、未修改的进程(GBA_U、安全性结合和本地密钥得出)实例(inst)中的，以及NAF密钥中心的信息流的完整性和机密性。

上述提出的新的方法经过稍稍的修改还可应用于，使UICC1260主机设备和远程设备之间的信道安全的现存协议。

使用MTM来保证IKC 1250的安全

为了执行提出的有关增强型GBA_U、安全性结合以及用于UICC 1260和终端之间的安全信道的本地密钥的建立的方法，移动可信模块(MTM)可在移动电话(UE)上使用，以保护内部密钥中心(IKC 1250)和其处理和操作的数据的完整性。

图18描述了MTM 1240怎样用于节4.3中描述的被修改的GBA_U进程(部分-1)。MTM 1240首先用来在IKC 1250继续进行GBA_U进程之前验证IKC 1250的完整性。MTM 1240还用来在其自身内(在安全的非易失性NVRAM下)或者通过保护加密密钥来安全存储，该加密密钥用于对IKC1250和BSF 1270之间以及IKC 1250和UICC 1260之间的隧道所需要的的密钥进行加密。MTM 1240还用来生成用作TLS-PSK隧道中的现时的随机数。

如上述描述的Part 1(GBA_U)进程相似，上述提出的Part-2(安全性结合)和Part 3(本地密钥生成)也能通过使用相似方式的MTM 1240来加强。MTM 1240用来：在每一个进程之前验证IKC 1250的完整性；保证安全、进行存储以及允许IKC 1250来检索密钥和IKC 1250生成的或者从其他例如UICC 1260和BSF 1270的实体接收到的其他敏感材料；并且生成用于每一个进程的现时的随机数。

图19示出了MTM 1240与终端和IKC 1250一起使用的情况。当IKC1250独立于被认为比IKC 1250信任度低或者安全的终端时，MTM 1240还可用来验证终端的完整性。这使得终端能安全地检索并随后使用UICC 1260和IKC 1250之间以及UICC 1260和终端之间得出的本地密钥Ks_local。参见图19，使用在UICC 1260和KC 1250之间得出的密钥Ks_local(见第三部分的结尾)，IKC 1250将Ks_local安全地存储于MTM 1240或者在MTM1240加密保护下安全地存储。从Ks_local得出的任何平台特定或者应用特定密钥也被MTM 1240以相同的方式安全地存储。在终端(不同于IKC 1250)可以使用Ks_local或者从其得出的任何密钥之前，在步骤S1，终端向IKC1250请求使用本地密钥。在步骤S2，IKC 1250请求MTM 1240来验证终端的完整性。在步骤S3，MTM 1240验证终端的完整性。仅在终端的完整性被MTM 1240对于终端和IKC 1250验证之后(在步骤S3和S4)，IKC 1250授权MTM 1240来释放被终端请求的用于终端和UICC 1260之间的通信的密钥(在步骤S5)。在步骤S6，MTM 1240释放本地密钥给终端。在步骤S7，终端使用本地密钥来建立与UICC 1260的安全信道。

提出的方案的一些优点如下所述。图19步骤S2、S3和S4允许IKC 1250和BSF 1270之间的密钥和密钥材料的整体传输和处理，其中一个以上NAF的材料可用于交换，并且处理来得出特定用于NAF的Ks_local，从而减少所需的OTA进程的数量，如果多个NAF的Ks_local的得出是根据现有技术执行。第二，由于使用了两个TLS-PSK隧道，UICC 1260和IKC 1250之间以及IKC 1250和BSF 1270之间的信息交换的完整性和机密性现在都得到了保护。这将减轻现有技术由于上述问题带来的隐私和潜在安全性危险。这不仅对本地密钥的建立有利还对于GBA_U和安全性结合进程有利。第三，分开的共享的机密K_UI和K_IH(任何一者都不可追踪到已存在的用户机密K)的使用，将隧道效应的进程与UICC 1260和HLR/HSS 1280共享的用户密钥分开，这减少了安全性风险，因为潜在的K_UI和K_IH密钥的破坏不会泄露用户机密。第四，IKC 1250的使用增加了安全性，这是因为IKC 1250是可信实体，其可信度是由MTM 1240在WTRU 1200上保护的(可被证实和证明的)。由于本地密钥(Ks_local)和密钥材料由可信的IKC 1250处理，并且还因为IKC 1250还能使用MTM 1240的安全存储能力来保持信息，以及MTM 1240的保护能力，例如用于创建RANDx和RANDy的随机数生成器，整个处理的安全性被增强。最后，使用MTM 1240来验证IKC 1250(以及当IKC 1250和终端是分开的实体时的终端)的完整性，来安全存储密钥和密钥材料，以及安全地生成用作现时的随机数，增加了建立本地密钥的进程(Part-1至Part-3)安全性和可信性，并且还使得终端能够仅在本地密钥的完整性被MTM 1240验证后，使用IKC 1250和UICC 1260生成的本地密钥。

虽然本发明的特征和元素在优选的实施方式中以特定的结合进行了描述，但每个特征或元素可以在没有所述优选实施方式的其他特征和元素的情况下单独使用，或在与或不与本发明的其他特征和元素结合的各种情况下使用。本发明提供的方法或流程图可以在由通用计算机或处理器执行的计算机程序、软件或固件中实施，其中所述计算机程序、软件或固件是以有形的方式包含在计算机可读存储介质中的，关于计算机可读存储介质的实例包括只读存储器(ROM)、随机存取存储器(RAM)、寄存器、缓冲存储器、半导体存储设备、内部硬盘和可移动磁盘之类的磁介质、磁光介质以及CD-ROM碟片和数字多功能光盘(DVD)之类的光介质。

举例来说，恰当的处理器包括：通用处理器、专用处理器、传统处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何一种集成电路(IC)和/或状态机。

与软件相关联的处理器可以用于实现射频收发信机，以在无线发射接收单元(WTRU)、用户设备、终端、基站、无线电网络控制器或是任何一种主机计算机中加以使用。WTRU可以与采用硬件和/或软件形式实施的模块结合使用，例如相机、摄像机模块、视频电路、扬声器电话、振动设备、扬声器、麦克风、电视收发信机、免提耳机、键盘、蓝牙

模块、调频(FM)无线电单元、液晶显示器(LCD)显示单元、有机发光二极管(OLED)显示单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器和/或任何一种无线局域网(WLAN)模块或超宽带(UWB)模块。

实施例

1、一种建立安全通信的方法，该方法包括：

A)请求内部密钥中心(IKC)和引导服务器功能(BSF)之间的TLS-PSK隧道；

B)从归属用户系统/归属位置寄存器(HSS/HLR)检索多个预先共享密钥；

C)在IKC和BSF之间建立TLS-PSK隧道；

D)在所述隧道上从所述BSF传输多个预先共享密钥中的至少一个给所述IKC；

E)在UICC和所述IKC之间建立TLS-PSK隧道；以及

F)在UICC和BSF之间建立至少一个用户认证密钥。

2、根据前述实施例中的任一项所述的方法，该方法还包括：

直接与所述IKC共享预先规定的对称密钥。

3、根据前述实施例中的任一项所述的方法，该方法还包括：

发送多个密钥给所述IKC；以及

同UICC进行确认直到识别正确的密钥。

4、根据前述实施例中的任一项所述的方法，其中所述确认包括：

挑战响应类型密钥确认。

5、根据前述实施例中的任一项所述的方法，该方法还包括：

从所述UICC接收预先共享密钥的证据；

发送所述证据给所述BSF；和

从所述多个预先共享密钥中识别正确的密钥。

6、根据前述实施例中的任一项所述的方法，该方法还包括：

接收请求消息，其中所述请求消息将IKC标识符包括为有效载荷。

7、根据前述实施例中的任一项所述的方法，其中预先共享密钥用来在所述IKC和BSF之间建立TLS-PSK隧道。

8、根据前述实施例中的任一项所述的方法，其中预先共享密钥用来在所述UICC和所述IKC之间建立隧道。

9、根据前述实施例中的任一项所述的方法，该方法还包括：

所述UICC构造NAF标识符。

10、根据前述实施例中的任一项所述的方法，其中所述IKC和所述BSF基于公钥对IKC标识符进行加密和解密。

11、根据前述实施例中的任一项所述的方法，该方法还包括：

从多个不同的公钥中选择，其中公钥是从网络广播的。

12、根据前述实施例中的任一项所述的方法，其中使用Diffie-Hellman密钥交换协议。

13、一种在公钥集合中计算公共索引的方法，该方法包括：

网络和IKC对两个值达成协议，其中所述两个值包括质数p和生成元g；

所述网络选择随机数(RAND_i)；

计算

g_{{RAND}_{i}} &equiv; g^{{RAND}_{i}} \mod p;

所述网络发送

给所述IKC(1≤RAND_i≤p-2)；

所述IKC计算随机数(FRESH)，其中g_FRESH≡g^FRESH mod p；

发送g_FRESH给所述网络(1≤FRESH≤p-2)；

所述网络计算

k &equiv; g_{FRESH}^{{RAND}_{i}} \mod p;

以及

所述IKC计算

k^{'} &equiv; g_{{RAND}_{i}}^{FRESH} \mod p .

14、根据前述实施例中的任一项所述的方法，该方法还包括：

加密包含IKC标识符的消息。

15、根据前述实施例中的任一项所述的方法，该方法还包括：

在所述TLS-PSK隧道建立进程中交换所述公钥。

16、根据前述实施例中的任一项所述的方法，该方法还包括：

用于TLS-PSK的TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA加密组，其中所述TLS-PSK能够执行DH密钥交换协议。

17、根据前述实施例中的任一项所述的方法，该方法还包括：

用于TLS-PSK的TLS_DHE_PSK_WITH_AES_128_CBC_SHA，其中所述TLS-PSK能够执行DH密钥交换协议。

18、根据前述实施例中的任一项所述的方法，该方法还包括：

用于TLS-PSK的TLS_DHE_PSK_WITH_AES_256_CBC_SHA，其中所述TLS-PSK能够执行DH密钥交换协议。

19、一种用于安全性结合的方法，该方法包括：

在UICC和IKC之间，以及IKC和BSF之间交换信息，其中所述UICC、IKC和BSF使用TSL-PSK隧道来保证交换安全。

20、根据前述实施例中的任一项所述的方法，该方法还包括：

在所述UICC上检验有效的用户认证密钥。

21、根据前述实施例中的任一项所述的方法，该方法还包括：

检索NAF的身份数据，所述UICC要与该NAF在已经建立的隧道(TUI)上建立自UICC的安全性结合。

22、根据前述实施例中的任一项所述的方法，该方法还包括：

所述UICC得出多个NAF特定密钥。

23、根据前述实施例中的任一项所述的方法，该方法还包括：

初始化带有基于UICC的增强的通用引导架构(GBA_U)，用以建立用户认证密钥。

24、根据前述实施例中的任一项所述的方法，该方法还包括：

在所述多个隧道中的一者上从所述IKC向BSF传送所述身份数据。

25、根据前述实施例中的任一项所述的方法，该方法还包括：

向至少一个NAF发送认证请求。

26、根据前述实施例中的任一项所述的方法，该方法还包括：

在所述BSF上从所述NAF接收至少一个认证响应。

27、根据前述实施例中的任一项所述的方法，该方法还包括：

BSF得出多个NAF特定密钥。

28、根据前述实施例中的任一项所述的方法，该方法还包括：

从所述BSF向多个NAF转发引导时间、密钥寿命和多个NAF特定密钥。

29、根据前述实施例中的任一项所述的方法，该方法还包括：

从所述NAF向所述BSF发送应答消息，该应答消息指示接收到所述NAF特定密钥、密钥寿命和引导时间。

30、根据前述实施例中的任一项所述的方法，该方法还包括：

从BSF向所述IKC发送整体安全性结合连接消息，其中所述整体安全性结合消息包括多个NAF消息认证码(MAC_NAF)，每一个对应一个特定NAF。

31、根据前述实施例中的任一项所述的方法，该方法还包括：

所述IKC将从BSF接收到的所述整体安全性结合消息转发给所述UICC。

32、根据前述实施例中的任一项所述的方法，该方法还包括：

在UICC上计算专用于NAF的MAC_{UICC_SA}。

33、根据前述实施例中的任一项所述的方法，该方法还包括：

所述UICC创建整体安全性结合响应消息。

34、根据前述实施例中的任一项所述的方法，该方法还包括：

如果MAC_IKC与对应的用于NAF的MAC_{UICC_SA}不匹配，则在会话中探测失败。

35、根据前述实施例中的任一项所述的方法，该方法还包括：

如果MAC_IKC与其对应的MAC_{UICC_SA}匹配，则探测成功。

36、根据前述实施例中的任一项所述的方法，该方法还包括：

使用NAF特定密钥和MAC算法发送成功响应。

37、根据前述实施例中的任一项所述的方法，该方法还包括：

经由IKC在多个隧道上向所述BSF发送所述整体安全性结合响应消息。

38、根据前述实施例中的任一项所述的方法，该方法还包括：

由所述BSF向所述NAF指示安全性结合尝试的失败或者成功状态。

39、根据前述实施例中的任一项所述的方法，该方法还包括：

在所述NAF上接收成功状态；以及

存储所述NAF特定密钥、引导时间和相关的密钥寿命。

40、一种用于在终端和UMTS集成电路卡(UICC)之间建立密钥的方法，该方法包括：

使用两个TLS-PSK隧道以安全方式交换信息。

41、根据前述实施例中的任一项所述的方法，该方法还包括：

所述内部密钥中心(IKC)在所述UICC上识别至少一个有效用户认证密钥的存在；以及

从所述UICC上检索引导事务标识符和至少一个网络应用功能(NAF)标识符。

42、根据前述实施例中的任一项所述的方法，该方法还包括：

用UICC基础的增强(GBA_U)进程初始化通用引导架构，来建立所述至少一个用户认证密钥；和

从所述UICC上检索引导事务标识符和至少一个NAF标识符。

43、根据前述实施例中的任一项所述的方法，该方法还包括：

在TLS-PSK隧道上发送在所述UICC和IKC之间交换的信息。

44、根据前述实施例中的任一项所述的方法，该方法还包括：

从所述IKC向引导服务器功能(BSF)发送对至少一个IKC密钥的应用请求，每一个对应于被请求的NAF的NAF标识符；以及

所述IKC将所述引导事务标识符和至少一个NAF标识符与IKC生成的用于Ks_IKC_NAF(RANDy)现时的多个相应的随机挑战一起发送。

45、根据前述实施例中的任一项所述的方法，该方法还包括：

计算至少一个IKC密钥，每个IKC密钥特定用于每个被请求的NAF。

46、根据前述实施例中的任一项所述的方法，该方法还包括：

向所述IKC发送包括至少一个IKC密钥和密钥寿命的应用响应。

47、根据前述实施例中的任一项所述的方法，该方法还包括：

所述IKC生成至少一个计数器限值值；和

得出至少一个本地密钥。

48、根据前述实施例中的任一项所述的方法，该方法还包括：

所述IKC在隧道TUI上向所述UICC发送应用请求消息；

请求所述UICC创建专用于NAF标识符的本地密钥，其中所述请求包含所述NAF标识符、终端标识符、终端应用标识符、UICC应用标识符和计数器限值值。

49、根据前述实施例中的任一项所述的方法，其中所述终端还包括：

计算MAC_IKC。

50、根据前述实施例中的任一项所述的方法，该方法还包括：

所述UICC检索Ks_int_NAF和与接收到的NAF标识符相关的引导标识符。

51、根据前述实施例中的任一项所述的方法，该方法还包括：

基于所述int_NAF密钥得出IKC-NAF密钥，以及得出RANDy。

52、根据前述实施例中的任一项所述的方法，该方法还包括：

UICC得出本地密钥，其中所述本地密钥确定为IKC-NAF密钥、引导事务标识符、终端标识符、集成电路卡识别(ICCID)、终端应用标识符、UICC应用标识符、RANDx和计数器限值的函数。

53、根据前述实施例中的任一项所述的方法，该方法还包括：

UICC验证从终端接收到的MAC_IKC值。

54、根据前述实施例中的任一项所述的方法，该方法还包括：

UICC终止密钥协议过程；以及

返回MAC验证失败消息来响应本地密钥得出请求。

55、根据前述实施例中的任一项所述的方法，该方法还包括：

所述UICC存储本地密钥和相关的参数；以及

所述UICC使用本地密钥和MAC算法发送包括ASCII码字符串的MAC的本地密钥得出响应。

56、根据前述实施例中的任一项所述的方法，该方法还包括：

所述IKC存储本地密钥和密钥寿命。

57、根据前述实施例中的任一项所述的方法，该方法还包括：

从本地密钥得出实际共享的密钥；以及

更新所述得出的共享密钥。

58、根据前述实施例中的任一项所述的方法，该方法还包括：

认证和加密在远程认证拨入用户服务上合并可扩展认证协议。

59、一种使用内部密钥中心安全通信的方法，该方法包括：

在移动电话(UE)上使用移动可信模块(MTM)来保证密钥安全。

60、根据前述实施例中的任一项所述的方法，该方法还包括：

所述IKC在所述MTM中存储本地密钥。

61、根据前述实施例中的任一项所述的方法，该方法还包括：

存储由MTM从本地密钥得出的任何平台或应用特定密钥。

62、根据前述实施例中的任一项所述的方法，该方法还包括：

在使用本地密钥之前，终端请求所述IKC使用本地密钥。

63、根据前述实施例中的任一项所述的方法，该方法还包括：

所述IKC请求所述MTM来验证终端的完整性。

64、根据前述实施例中的任一项所述的方法，该方法还包括：

MTM验证终端的完整性。

65、根据前述实施例中的任一项所述的方法，该方法还包括：

所述IKC授权所述MTM来释放由终端请求的用于它本身与UICC之间的通信的多个密钥。

66、根据前述实施例中的任一项所述的方法，该方法还包括：

从所述MTM释放至少一个本地密钥给终端。

67、根据前述实施例中的任一项所述的方法，该方法还包括：

所述终端发送本地密钥来与UICC建立至少一个安全信道。

68、根据前述实施例中的任一项所述的方法，该方法由所述UICC执行。

69、根据前述实施例中的任一项所述的方法，该方法由所述BSF执行。

70、根据前述实施例中的任一项所述的方法，该方法由无线发射/接收单元(WTRU)执行。

71、根据前述实施例中的任一项所述的方法，该方法由基站执行。

72、根据前述实施例中的任一项所述的方法，该方法由所述IKC执行。

Claims

1.一种由无线发射/接收单元WTRU使用的用于建立安全通信的方法，该方法包括：

在内部密钥中心IKC与UMTS集成电路卡UICC之间建立安全隧道，该安全隧道被配置成使得在GBA_U进程和本地密钥建立进程期间能够安全通信，其中所述IKC是位于所述WTRU上的可信本地实体，其中所述IKC与所述UICC之间的所述安全隧道是使用成功认证的预共享密钥集合建立的传输层安全性预共享密钥TLS-PSK隧道；以及

通过经由所述IKC与所述UICC之间建立的安全隧道执行所述GBA_U进程和所述本地密钥建立进程来在所述UICC与所述IKC之间建立安全信道。

2.根据权利要求1所述的方法，其中在所述IKC与所述UICC之间建立所述安全隧道包括：

建立所述IKC和引导服务器功能BSF之间的另一安全隧道；以及

经由所述IKC与所述BSF之间的所述安全隧道来接收第一密钥，其中所述IKC与所述UICC之间的所述安全隧道是使用所述第一密钥建立的。

3.根据权利要求2所述的方法，其中所述IKC与所述BSF之间的所述安全隧道是传输层安全性预共享密钥TLS-PSK隧道。

4.根据权利要求1所述的方法，其中所述IKC与所述UICC之间的所述安全隧道是使用共享机密建立的。

5.根据权利要求4所述的方法，其中所述共享机密在所述IKC和所述UICC中被预先提供。

6.一种在无线发射/接收单元WTRU使用的用于建立安全通信的设备，该设备包括：

用于在内部密钥中心IKC与UMTS集成电路卡UICC之间建立安全隧道的装置，该安全隧道被配置成使得在GBA_U进程和本地密钥建立进程期间能够安全通信，其中所述IKC与所述UICC之间的所述安全隧道是使用成功认证的预共享密钥集合建立的传输层安全性预共享密钥TLS-PSK隧道，以及

用于通过经由所述IKC与所述UICC之间建立的安全隧道执行所述GBA_U进程和所述本地密钥建立进程来在所述UICC与引导服务器功能BSF之间建立安全信道的装置。

7.根据权利要求6所述的设备，其中所述设备还包括：

用于建立所述IKC和所述BSF之间的安全隧道的装置；以及

用于经由所述IKC与所述BSF之间的所述安全隧道来接收第一密钥的装置，其中所述IKC与所述UICC之间的所述安全隧道是使用所述第一密钥建立的。

8.根据权利要求7所述的设备，其中所述IKC与所述BSF之间的所述安全隧道是传输层安全性预共享密钥TLS-PSK隧道。

9.根据权利要求6所述的设备，其中所述IKC与所述UICC之间的所述安全隧道是使用共享机密建立的。

10.根据权利要求9所述的设备，其中所述共享机密在所述IKC和所述UICC中被预先提供。