CN102204305A - 家用节点b设备以及安全协议 - Google Patents

家用节点b设备以及安全协议 Download PDF

Info

Publication number
CN102204305A
CN102204305A CN2009801375859A CN200980137585A CN102204305A CN 102204305 A CN102204305 A CN 102204305A CN 2009801375859 A CN2009801375859 A CN 2009801375859A CN 200980137585 A CN200980137585 A CN 200980137585A CN 102204305 A CN102204305 A CN 102204305A
Authority
CN
China
Prior art keywords
tre
authentication
sgw
network
auth
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN2009801375859A
Other languages
English (en)
Other versions
CN102204305B (zh
Inventor
I·查
Y·C·沙阿
A·U·施米特
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Publication of CN102204305A publication Critical patent/CN102204305A/zh
Application granted granted Critical
Publication of CN102204305B publication Critical patent/CN102204305B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent

Abstract

本发明公开了家用节点B或家用演进型节点B(H(e)NB)设备和方法。该H(e)NB包括可信环境(TrE)和接口，其中所述接口包括无防护接口、加密防护接口以及硬件防护接口。H(e)NB包括用于H(e)NB与外部网络部件之间通信的安全/认证协议，其中所述外部网络部件包括安全网关(SGW)。

Description

家用节点B设备以及安全协议
技术领域
本发明涉及无线通信。
背景技术
第三代合作伙伴项目(3GPP)长期演进(LTE)计划的目标是开发出用于LTE设置和配置的全新技术、全新架构以及全新方法，以便以更低的成本来为更快的用户体验和更丰富的应用及服务提供改进的频谱效率、缩短的等待时间以及更好的无线电资源使用率。作为这些工作的一部分，3GPP为LTE网络引入了家用演进型节点B(H(e)NB)的概念。3GPP还设想了用于宽带码分多址(WCDMA)的家用NB(HNB)。在本申请中，以下将会使用首字母缩写词H(e)NB来指示H(e)NB和HNB。
H(e)NB在住宅和小型办公室之类的极小服务区域中提供针对LTE服务的用户接入(还可以提供WCDMA、全球移动通信系统(GSM)EDGE无线电接入网络(GERAN)以及其他蜂窝服务)。无论用户是个人还是组织，其都能在需要该服务的区域中部署H(e)NB。此外，对于H(e)NB的强制性认证以及托管方的可选认证来说，用于H(e)NB与安全网关(SGW)之间的认证协议的框架同样也已引入。该协议为设备和托管方认证以及以后在H(e)NB与SGW以及其他核心网络实体(例如归属位置寄存器(HLR)和认证授权计费(AAA)服务器)之间进行的所有其他加密通信(凭借IPSec)提供了基本框架。
在H(e)NB认证上下文中还引入了某些因特网密钥交换v2(IKEv2)参数，例如“支持多重认证(MULTIPLE_AUTH_SUPPORTED)”和CERTREQ，这些参数是作为用于表明SGW能够支持各种可能性(通过与HeNB选择或是进行协商来确定究竟是哪个)的能力的指示符而被引入的。但是，使用这些参数将会导致在选择哪一种认证的最终选择结果方面出现很多“不确定的”状况。
在上述协议中，很多安全威胁是已经确定的，一般来说，这些威胁针对的是执行协议的设备和装置。所考虑的这些威胁包括但不局限于：借助弱认证算法的暴力攻击对于H(e)NB认证令牌的危害；本地物理侵入对于H(e)NB认证令牌的危害；将有效认证令牌插入被操纵的H(e)NB；用户克隆H(e)NB认证令牌；H(e)NB首次网络接入时受到中间人攻击；使用欺诈软件来引导(boot)H(e)NB(“刷机(re-flash)”)；欺诈性的软件更新/配置变更；以物理方式篡改H(e)NB；窃听其他用户的通用陆地无线电接入网络(UTRAN)或演进型UTRAN(E-UTRAN)用户数据；假扮其他用户；在未报告的情况下改变H(e)NB位置；软件模拟H(e)NB；H(e)NB之间的业务量隧道效应；调制解调器/路由器中的防火墙配置错误；针对H(e)NB的拒绝服务攻击；针对核心网络的拒绝服务攻击；使用活动网络服务弱点来损害H(e)NB；将用户网络ID泄露给H(e)NB的所有者；H(e)NB配置错误；接入控制列表(ACL)配置错误或ACL损害；无线电资源管理篡改；假扮有效H(e)NB；在闭合用户群组(CSG)上提供无线电接入服务；H(e)NB向网络通告错误位置；对外部时间资源进行操纵；以及针对H(e)NB的环境/边信道攻击。
此外还提出了将位置信息用于H(e)NB认证。可以使用以下三种位置信息之一或是其任何组合来对H(e)NB定位：固定接入线路位置(例如H(e)NB的回程端口的IP地址)；关于包括3G和2G小区在内的宏小区的信息；以及H(e)NB中的全球定位系统(GPS)。
在这里还引入了用于位置注册(或认证)的步骤以及用于以位置为基础的认证的后续步骤。但是，这些方法存在若干不足，其中包括在H(e)NB获取的位置信息有可能会在发送到网络之前在设备内部以不安全的方式处理。
在LTE和其他无线通信系统中部署H(e)NB会引入安全问题，为了实现成功的执行过程，这些安全问题必须加以解决。同样，用于具有可信环境和可选托管方模块(HPM)的H(e)NB的认证协议也是必需的，其中在某些实施例中，所述协议是可以在UICC上实施的。
发明内容
在这里公开了一种家用节点B和/或家用演进型节点B(H(e)NB)设备以及安全/认证协议。该H(e)NB包括可信环境(TrE)以及用于H(e)NB与外部网络部件之间的通信的安全/认证协议，其中所述外部网络部件包括安全网关(SGW)。此外，在这里还公开了在TrE与H(e)NB之间使用的接口，其中所述接口包括无防护接口、加密防护接口以及硬件防护接口。所公开的认证方法包括SGW与H(e)NB之间的信令协定。
一般来说，SGW向H(e)NB指示该H(e)NB除了设备认证之外是否还需要执行托管方认证。SGW还向H(e)NB指示该H(e)NB是否需要执行基于证书的认证或是基于可扩展认证协议-认证密钥协定(EAP-AKA)的认证。在一个实施例中，SGW通过使用MULTIPLE_AUTH_SUPPORTED而在IKE_SA_INIT响应中指示认证类型，H(e)NB在带有MULTIPLE_AUTH_SUPPORTED和“另一个认证跟随(ANOTHER_AUTH_FOLLOWS)”参数的IKE_AUTH请求中指示认证类型，并且SGW在IKE_SA_INIT响应中使用CERTREQ参数来指示设备认证类型。在另一个实施例中，与发送用于设备认证的信息相结合，H(e)NB使用IKEv2协议来向SGW指示由TrE执行的设备完整性检查的结果，由此使用通用协议来实现设备验证和设备认证。
附图说明
更详细的理解可以从以下结合附图举例给出的描述中得到，其中：
图1是示例系统架构；
图2是家用演进型节点B(H(e)NB)的示例功能框图；
图3是H(e)NB中的可信环境(TrE)的示例接口配置；
图4是H(e)NB中的可信环境(TrE)的另一个示例接口配置；
图5是用于确定认证类型的示例流程图；
图6是用于基于简档的认证的示例流程图；
图7是显示示例安全协议的关系图；
图8(A)和8(B)是用于可扩展认证协议-认证密钥协定(EAP-AKA)的示例信号图；
图9是关于设备认证的示例流程图；
图10(A)和10(B)是关于设备和托管方认证的示例流程图；
图11是关于三向绑定的示例流程图；
图12是关于双向绑定的示例流程图；以及
图13是使用IKEv2协议对设备认证、设备完整性检查以及设备验证进行组合的示例流程图。
具体实施方式
下文引用的术语“无线发射/接收单元(WTRU)”包括但不局限于用户设备(UE)、移动站、固定或移动订户单元、寻呼机、蜂窝电话、个人数字助理(PDA)、计算机或是其他任何能在无线环境中工作的用户设备。下文引用的术语“基站”包括但不局限于节点B、站点控制器、接入点(AP)或是其他任何能在无线环境中工作的接口设备。
在这里公开的是用于为无线通信部署家用演进型节点B以及家用节点B(统称为H(e)NB)的系统和架构、对H(e)NB与安全网关(SGW)之间的认证信令的描述、以及可以用于建立无线通信的认证方法。
图1是一个用于部署H(e)NB 110的示例安全系统架构100。H(e)NB 110经由SGW 130来接入运营商的核心网络120。在与H(e)NB 110执行相互认证的过程中，SGW 130代表的是运营商的核心网络120。这种相互认证有可能需要得到认证服务器或公钥基础设施(PKI)的支持。H(e)NB 110与SGW 130之间的回程140有可能是不安全的，并且在H(e)NB 110与SGW 130之间可以建立安全隧道，以便保护在回程链路140中传送的信息。H(e)N 110经由空中接口来与WTRU 150进行通信。
图2显示的是H(e)NB 200的示例实施方式的功能框图。H(e)NB 200包括可信环境(TrE)210，并且可选地与托管方模块(HPM)215相连接或通信(统称为“连接”)。其中举例来说，HPM 215可以用通用集成电路卡(UICC)来实现。
TrE 210进一步包括一个安全运行环境212以及安全存储区214。此外，TrE 210还连接到主处理单元(MPU)/应用处理器220、一个或多个通用移动通信系统(UMTS)蜂窝调制解调处理器225、包括电源单元和本地接口在内的外设230、定位设备240、一个或多个非UMTS蜂窝或非蜂窝调制解调处理器245、以及时钟和时间设备250。这里列举的组件是说明性的，并且H(e)NB 200可以包括其中所有或某些组件以及其他组件。
MPU 220进一步连接到一个或多个UMTS蜂窝调制解调处理器225、外设230、定位设备240、一个或多个非UMTS蜂窝或非蜂窝调制解调处理器245、以及时钟和时间设备250。此外，MPU 220还可以连接到HPM 215。定位设备240进一步连接到时钟和时间设备250以及一个或多个UMTS蜂窝调制解调处理器225。此外，一个或多个UMTS蜂窝调制解调处理器225还连接到功率放大器(PA)/射频(RF)模块260，所述模块则转而连接到一个或多个天线单元270。HPM 215也可以连接到一个或多个UMTS蜂窝调制解调处理器225。正如所公开的那样，HPM 215还可以被包含在H(e)NB 200中。当HPM 215被包含时，该HPM 215会为托管方(在其位置处对H(e)NB 200进行托管的实体)提供基于认证密钥协定(AKA)的认证服务。HPM 215可以代表UMTS移动网络运营商来执行托管方认证。
TrE 210在物理上和逻辑上是绑定于H(e)NB 200的，它充当了H(e)NB 200内部的可信实体，并且为H(e)NB 200提供锚点。安全存储区214为密钥、秘密和其他敏感数据及程序提供安全存储区。安全运行环境212则向UMTS网络提供了一个用于对H(e)NB 200执行AKA和基于证书认证的环境，并且提供了SGW认证以及由此提供了UMTS网络认证。安全运行环境212允许TrE 210执行这里公开的多个任务。
举个例子，TrE 210执行其他安全敏感操作，例如经由UMTS和其他接口的数据和业务量加密及解密，并且运行安全敏感程序和数据操作，所有这些都是代表MPU 220并独立于MPU 220进行的。此外，TrE 210还可以执行所有那些与以安全方式经由SGW来向网络指示其自身、其他任何组件或是其对H(e)NB 200的操作的有效性相关的任务。
TrE 210还可以执行验证操作，在该操作中，TrE 210检查其自身以及剩余H(e)NB 200的有效性(真实性和/或完整性)，并且这其中包含了MPU 220、HPM 215(当被包含时)、一个或多个蜂窝和非蜂窝调制解调器225和245以及其他外设230和接口的硬件和软件(包括程序和数据)。当TrE 210通过其有效性检查检测到无效组件或子实体时，它会执行一组安全有效的封锁(关于其自身以及剩余的H(e)NB)200和/或报告(在封锁之前向网络报告)操作。
TrE 210还可以保护程序以及包括证书在内的数据，并且由此验证一个或多个位置/定位设备以及时钟和定时设备，这些全都是在H(e)NB 200能被网络授权或者在放行H(e)NB 200来与网络建立可操作连接之前强制进行的。它还可以为安全敏感数据或程序执行任何安全敏感设备管理以及空中传送(OTA)任务。它可以保护、监视和执行用于H(e)NB 200和/或其个体组件/子实体或是其自身的安全策略或安全控制措施。它还可以建立和保持(包括拆除)其与H(e)NB 200和/或网络实体内部的任何其他组件之间的安全信道，其中所述网络实体可以是HPM、SGW、认证中心(AuC)或家用位置寄存器(HLR)等等。更进一步，它还可以存储、保护、提取、更新以及安全地提供(向H(e)NB 200内部的其他组件)需要传递给此类组件的任何数据，以便用于内部安全操作或是包括与SGW进行的回程通信(包括哪些用于设备和/或托管方认证的通信)在内的外部通信。
从图2中可以明显看出，TrE 210需要与若干个H(e)NB功能构建组块进行交互，以便安全性地执行预期功能，例如认证。为了建立必要连接，TrE 210应该可以访问与H(e)NB 200内部的此类功能和资源相对应的各种接口。TrE 210的这些接口通常是TrE 210的功能，它们是在TrE 210的安全启动进程中初始化的，并且假设它们是正常工作的。在这些前提下，在这里可以就TrE 210的安全属性而对其进行分析，以便建立关于H(e)NB 200的安全有效的设计。
在一个实施方式中，TrE接口具有三个宽泛的安全类别，其中包括无防护接口、加密防护接口(安全信道)以及硬件防护接口。
无防护接口有助于那些在TrE 210与H(e)NB 200中没有被假设成不会受到篡改和/或窃取的一般资源之间进行的通信。应该指出的是，无防护接口仍然可以使那些受到TrE 210加密防护的数据被访问，例如在TrE 210拥有相关密钥材料并将后者存入安全存储器的时候。
加密防护接口(安全信道)是由提供加密通信的安全协议保护的。此外，它们还可以建立一条提供对与TrE 210通信的实体进行附加认证的安全信道，以及该安全信道还提供附加的预期功能，例如消息认证。
硬件防护接口提供的是针对攻击的物理防护，例如针对边信道攻击的措施。
H(e)NB 200实施方式考虑了与特定TrE接口配置选择相关的各个方面。当通信实体没有对所传递的数据提供保护时，这时可以选择无防护接口。这其中的一个示例可以是在通信协议中使用的瞬时秘密。当与TrE 210通信的资源需要对所传递的信息进行明文访问并且当其可以对信息提供某些保护时，可以选择加密保护接口。硬件防护接口通常会将TrE 210连接到硬件安全资源，以便保持整个系统的防护等级。
图3显示的是H(e)NB 300中的TrE 310的接口配置的一个实施方式。在本示例中，TrE 310采用的是薄配置，这意味着其自身内部的功能相对有限，其中这些功能包括使用认证部分(AUTH)和结果(RES)模块312来计算用于UMTS认证密钥协定的可扩展认证协议方法(EAP-AKA)RES以及AUTH参数，以执行设备验证的能力，以及使用H(e)NB 300的验证功能314来执行验证的能力。然后，TrE 310会与驻留在H(e)NB 300上的其他功能或资源相对接。某些接口是硬件防护的，某些是通过软件防护来保护的，其他接口则是无防护的。在这里假设处于TrE 310外部并且经由硬件防护接口或加密防护接口而与TrE 310对接的这些资源和功能本身应该是受保护的资源和功能。如果没有对这些资源和功能进行保护，那么TrE 310几乎没有理由在有防护的接口上与之对接。
在必要时，TrE 310将会构建只能被TrE 310访问的特殊硬件防护资源320，例如安全存储器322、密码功能引擎324以及(在需要时可以是物理性的)随机数生成器326。这些特殊的硬件防护资源可以称为TrE 310的可信根(RoT)。这些资源必须经由硬件防护接口328访问，以便确定TrE 310自身的可信赖性，尤其是启用TrE 310和H(e)NB 300的安全启动过程。H(e)NB 300的其他功能构建组块可以具有各种安全属性，并且可以经由安全信道330而被访问。举例来说，随机生成器模块332、随机参数控制器334、WTRU认证资源336、H(e)NB认证340、IP堆栈342以及主机平台模块340是经由加密防护接口或安全信道330而被访问的。诸如时间资源362和位置确定364之类的敏感信息360是经由加密防护接口或安全信道330访问的。在这种情况下可以选择与某些硬件防护措施相结合。此外，无防护接口370还与非敏感资源375以及通用资源相连，例如用存储容量380来扩展TrE 410的存储器。正如这里描述的那样，接口的安全性需要有可能发生变化，而TrE则必须适应每种接口类型并与之交互。
图4显示的是具有TrE 410的H(e)NB 400的另一个接口配置。在该实施方式中，TrE 410采用的是在其内部包含硬件加密资源的较厚配置，其中举例来说，所述硬件加密资源可以是密码加密引擎415、随机数生成器417以及安全存储器419。更进一步，TrE 410还包括借助因特网密钥交换(IKEv2)来执行设备认证的完整能力，其中举例来说，所述认证是使用IKEv2堆栈422、设备认证424以及H(e)NB验证模块426完成的。TrE 410还可以借助模块428来支持WTRU的AKA过程。应该指出的是，在本描述中，IKEv2协议是用于例证目的，并且其他协议也是可以使用的，例如传输层安全性(TLS)、宽带论坛技术要求(TR)069、开放移动联盟(OMA)设备管理(DM)协议或是用于TLS扩展的某些适当的因特网工程任务组(IETF)请求意见(RFC)，但是所述协议并不局限于此。
在本实施方式中，随机生成器模块432、随机参数控制器434、主机平台模块450以及诸如时间资源462和位置确定464之类的敏感信息460同样是经由加密防护接口或安全信道430而被访问的。此外，无防护接口470还与非敏感资源475以及通用资源相连，例如扩展TrE的存储容量480。
在另一个实施方式中，接口具有两种宽泛的类型，其中一种是有防护的，另一种则是无防护的。举个例子，在图3和4中被描述成是硬件防护接口或加密防护接口的那些接口可以被简单地视为有防护接口，而被描述成是无防护接口的那些接口则可以被简单地视为无防护接口。
如这里所述，为了强制认证H(e)NB以及可选地认证托管方，在H(e)NB与SGW之间引入了一个认证协议。现在将要描述一种使用了这里论述的TrE能力的认证选择方法。
因特网密钥交换版本2(IKEv2)可以作为基础框架而被用于H(e)NB与核心网络之间的安全通信(包括那些用于认证的通信)。IKEv2在H(e)NB与SGW之间建立安全关联(SA)，并使可以用于在这两个实体之间建立IPSec隧道的安全密钥可用。此外，IKEv2还可以用于H(e)NB与托管方的组合认证。
IKEv2是用于执行相互认证以及建立并保持安全关联(SA)的IPSEc的一个组件。在H(e)NB的上下文中，“安全网关隧道的端点”是随时可用的。因此，在作为端点的H(e)NB与SGW之间，继而发生的IKEv2步骤包括：第一阶段(IKE_SA_INIT)，其中包括对IKE_SA的安全参数进行协商以及发送随机现时(nonce)和Diffie-Hellman值，以及包含请求/响应步骤的第二阶段(IKE_AUTH)，其中所述请求/响应步骤包括标识的传输和为认证报头(AH)和/或封装安全净荷(ESP)设置SA。
在这里规定了至少两个不同的认证行为，其中一个是对H(e)NB设备自身进行认证(称为设备认证)，另一个则是对托管方进行认证(称为托管方认证)。设备认证是强制性的。它可以通过使用可扩展认证协议-认证密钥协定(EAP-AKA)或证书来完成。托管方认证可以使用托管方模块(HPM)来完成。在完成托管方认证时，该认证可以在与设备认证相分离的情况下完成，或者该认证也可以通过使用用于设备认证和托管方认证的步骤而以一种复合的方式完成。更进一步，H(e)NB的ID和HPM的ID可以是物理或逻辑绑定的，并且在这里引入了用于此类绑定的可能协议。
一般来说，所公开的第一种方案是认证协议信令方案，其中SGW向H(e)NB指示除了设备认证之外，所述H(e)NB是否还需要执行托管方认证。SGW还向H(e)NB指示该H(e)NB是否需要执行基于证书的认证或是基于EAP-AKA的认证。SGW在IKE_SA_INIT响应中使用MULTIPLE_AUTH_SUPPORTED参数来指示认证类型，并在IKE_SA_INIT响应中使用CERTREQ参数来指示设备认证类型。H(e)NB则使用MULTIPLE_AUTH_SUPPORTED以及ANOTHER_AUTH_FOLLOWS参数来在IKE_AUTH请求中指示认证类型。
如这里所述，当在从SGW到H(e)NB的不同IKEv2响应中发送MULTIPLE_AUTH_SUPPORTED和CERTREQ参数时，它们应该被解释成是对于H(e)NB的需求或请求。很明显，SGW实际“确定”使用哪一种认证方法并且随后将其作为一个需求或请求发送到H(e)NB。这样做将会使选择过程中的请求和响应配对的可能组合产生清楚明确的结果。应该指出的是，该参数还应该被隐含解释成是SGW能力的指示符，这是因为如果SGW不支持所指示的选定方法，则不发送所指示的选定方法。
如这里所述，H(e)NB将会具有强制性的设备认证以及可选的托管方(HP)认证。这两种认证可以采用不同的方式完成，并且在实践中，所部署的产品(H(e)NB和SGW)既可以支持强制性认证，也可以同时支持可选和强制性认证。由此有必要具有一种用于为连接到运营商网络(经由SGW)的指定H(e)NB选择认证类型的方法。由于SGW执行运营商策略，因此，由SGW做出并指示给H(e)NB的选择是权威的。
在关于认证选择方法的一个实施方式中，该方法采取了：1)借助证书或EAP-AKA的设备认证，以及2)用于EAP-AKA的托管方认证。所给出的方法的实施方式假设使用了IKEv2多验证处理。
如下所述，强制性设备认证和可选的托管方认证是在H(e)NB中进行的。该认证既可以通过基于证书的解决方案来完成，也可以通过EAP-AKA来完成。这样做将会导致产生两种认证方法与有可能需要认证的两个实体的如下组合：1)使用证书的设备认证，没有HP认证；2)使用EAP-AKA的设备认证，没有HP认证；3)使用证书的设备认证，使用证书的HP认证；4)使用EAP-AKA的设备认证，使用证书的HP认证；5)使用证书的设备认证，使用EAP-AKA的HP认证；以及6)使用EAP-AKA的设备认证，使用EAP-AKA的HP认证。如果为该实施方式假设的是可以为HP认证选择EAP-AKA，则可以不考虑认证组合3和4。
参考图5公开的是一种用于确定在H(e)NB 505与SGW 510之间执行设备认证还是同时执行设备和HP认证的方法500。该方法500是根据一个实施方式的一种基于IKEv2的验证过程。在一开始，H(e)NB 505向SGW 510发送IKE_SA_INIT请求消息(515)。SGW 510则发送IKE_SA_INIT响应消息(520)。如果IKE_SA_INIT响应消息不包含MULTIPLE_AUTH_SUPPORTED，那么H(e)NB 505将会明白无法进行多个认证。由此，只有设备认证是可以使用基于证书或EAP-AKA的认证进行的。
H(e)NB 505发送IKE_AUTH请求消息(525)。SGW 510确定该IKE_AUTH请求消息是否包含MULTIPLE_AUTH_SUPPORTED和ANOTHER_AUTH_FOLLOWS。如果IKE_AUTH请求消息不包含所述指定值，则意味着只有设备认证能够执行。如果存在指定值，则设备和HP认证都是可以进行的。
在这里还参考图5公开了一种用于确定设备认证类型是基于证书的还是基于EAP-AKA的方法。H(e)NB 505确定IKE_SA_INIT响应中的CERTREQ的可用性(520)。如果在针对H(e)NB 505的IKE_SA_INIT响应中存在CERTREQ，则意味着SGW 510支持基于证书的设备认证，并且它还有可能支持基于EAP-AKA的认证。如果从SGW 510到H(e)NB 505的IKE_SA_INIT响应中没有CERTREQ，则意味着SGW 510支持基于EAP-AKA的认证。
基于证书的设备认证还可以由SGW 510通过确定从H(e)NB 505到SGW 510的IKE_AUTH请求(525)是否包含AUTH来执行。如果存在AUTH，则意味着将要执行基于证书的设备认证，否则意味着将要执行基于EAP-AKA的认证。与这里提示的一样，托管方(HP)认证使用EAP-AKA。
在认证选择方法的一个实施方式中，认证机制的选择使用了这里论述的原理。H(e)NB应该支持使用证书或EAP-AKA的设备认证。实际上，选择以上两种方法(也就是基于证书的设备认证方法或基于EAP-AKA的设备认证方法)中的哪种方法的决定是作为特定于部署的决定选择的。H(e)NB可以支持为设备认证使用证书或EAP-AKA以及为托管方认证使用EAP-AKA的组合认证。即使SGW同时支持这两种认证机制，它也可以根据运营商策略来拒绝其中一种机制。SGW向H(e)NB明确指示它是需要H(e)NB同时执行设备认证和托管方认证，还是只需要执行设备认证，以及它是需要H(e)NB执行基于证书的设备认证，还是基于EAP-AKA的设备认证。
基于上述准则，在下表1-4中论述了认证选择方法。所述表格的内容涉及认证方法选择的最终结果。表1-4概述了依照一个实施方式的认证方法选择。在这些表格中，M_A_S是MULTIPLE_AUTH_SUPPORTED；I_S_I是IKE_SA_INIT；A_A_F是ANOTHER_AUTH_FOLLOWS。
表1表示的是H(e)NB响应于四个不同的SGW IKE_SA_INIT响应而在IKE_AUTH请求消息中返回AUTH、MULTIPLE_AUTH_SUPPORTED以及ANOTHER_AUTH_FOLLOWS的方案。在范例1中，SGW发送一个带有MULTIPLE_AUTH_SUPPORTED和CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息则相当于执行基于证书的设备认证以及基于EAP-AKA的托管方认证。在范例2中，SGW发送一个具有MULTIPLE_AUTH_SUPPORTED而没有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息则相当于一个错误状况，在这种状况中，SGW需要的是基于EAP-AKA的设备认证和基于EAP-AKA的托管方认证，但是H(e)NB是用一个基于证书的设备认证来响应的。如果发生这种情况，SGW的最终决定结果应该取决于运营商策略。在范例3中，SGW发送只具有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息则相当于一个错误状况，在这种状况中，SGW只请求了基于证书的认证，但是H(e)NB尝试用设备认证和托管方认证来响应。如果发生这种情况，SGW最终决定结果应该取决于运营商策略。在范例4中，SGW发送一个没有MULTIPLE_AUTH_SUPPORTED或CERTREQ的IKE_SA_INIT。H(e)NB请求消息则相当于一个错误状况，在这种状况中，SGW只需要H(e)NB执行基于EAP-AKA的设备认证，但是H(e)NB的响应是同时执行设备和托管方认证。如果发生这种情况，SGW决定的结果应该取决于运营商策略。
表1
Figure BPA00001332073000151
表2代表的是这样一个方案，其中H(e)NB响应于四个不同的SGW IKE_SA_INIT响应而在IKE_AUTH请求消息中返回了MULTIPLE_AUTH_SUPPORTED和ANOTHER_AUTH_FOLLOWS，但却没有返回AUTH。在范例5中，SGW发送一个具有MULTIPLE_AUTH_SUPPORTED和CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW消息需要的是基于证书的设备认证，但是H(e)NB却通过遗漏AUTH来指示其不支持基于证书的设备认证。如果发生这种情况，则SGW的决定结果应该依赖于运营商策略。在范例6中，SGW发送一个具有MULTIPLE_AUTH_SUPPORTED而没有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息相当于执行基于EAP-AKA的设备和托管方认证。在范例7中，SGW发送一个只具有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW只需要H(e)NB用证书执行设备认证，但是H(e)NB却尝试同时执行设备认证和托管方认证。如果发生这种情况，SGW最终决定的结果应该取决于运营商策略。在范例8中，SGW发送一个没有MULTIPLE_AUTH_SUPPORTED或CERTREQ的IKE_SA_INIT。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW只需要H(e)NB执行基于EAP-AKA的设备认证，但是H(e)NB却尝试同时执行设备和托管方认证。如果发生这种情况，SGW决定的结果应该取决于运营商策略。
表2
Figure BPA00001332073000161
表3代表的是这样一个方案，其中H(e)NB响应于四个不同的SGW IKE_SA_INIT响应而在IKE_AUTH请求消息中返回了AUTH，但却没有返回MULTIPLE_AUTH_SUPPORTED和ANOTHER_AUTH_FOLLOWS。在范例9中，SGW发送一个具有MULTIPLE_AUTH_SUPPORTED和CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW需要的是基于证书的设备认证以及托管方认证，但是H(e)NB尝试的仅仅是基于证书的设备认证。如果发生这种情况，SGW的决定结果应该取决于运营商策略。在范例10中，SGW发送一个具有MULTIPLE_AUTH_SUPPORTED而没有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW需要的是基于EAP-AKA的设备认证以及基于EAP-AKA的托管方认证，但是H(e)NB仅仅尝试执行基于证书的设备认证。如果发生这种情况，SGW的决定结果应该取决于运营商策略。在范例11中，SGW发送一个只具有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息则通过执行基于证书的设备认证来做出响应。在范例12中，SGW发送一个没有MULTIPLE_AUTH_SUPPORTED或CERTREQ的IKE_SA_INIT。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW需要H(e)NB执行基于EAP-AKA的设备认证，但是H(e)NB却尝试执行基于证书的设备认证。如果发生这种情况，则SGW的决定结果应该依赖于运营商策略。
表3
表4代表了这样一种方案，其中H(e)NB响应于四个不同的SGW IKE_SA_INIT响应而在IKE_AUTH请求消息中没有返回AUTH、MULTIPLE_AUTH_SUPPORTED以及ANOTHER_AUTH_FOLLOWS。在范例13中，SGW发送具有MULTIPLE_AUTH_SUPPORTED和CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW需要的是基于证书的设备认证以及托管方认证，但是H(e)NB却尝试执行基于EAP-AKA的设备认证。如果发生这种情况，SGW的决定结果应该取决于运营商策略。在范例14中，SGW发送一个具有MULTIPLE_AUTH_SUPPORTED而没有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息相当于一个错误状况，在这种状况中，SGW同时需要基于EAP-AKA的设备认证和给予EAP-AKA的托管方认证，但是H(e)NB却仅仅尝试执行基于EAP-AKA的设备认证。如果发生这种情况，SGW的决定结果应该取决于运营商策略。在范例15中，SGW发送一个只具有CERTREQ的IKE_SA_INIT响应。H(e)NB请求消息对应于一个错误状况，在这种状况中，SGW需要H(e)NB执行基于证书的设备认证，但是H(e)NB却尝试执行基于EAP-AKA的设备认证。如果发生这种情况，SGW的决定结果应该取决于运营商策略。在范例16中，SGW发送一个没有MULTIPLE_AUTH_SUPPORTED或CERTREQ的IKE_SA_INIT。H(e)NB请求消息相当于执行基于EAP-AKA的设备认证。
表4
Figure BPA00001332073000191
范例1、6、11和16将会导致产生有效的需求/响应配对。而所有其他范例则会导致产生错误状况，在这种情况下，SGW的决定结果应该依赖于运营商策略。此外，该策略决定也可以基于SGW对于H(e)NB的认证能力的了解。例如，基于H(e)NB在IKE_SA_INIT请求消息中提供的H(e)NBID，SGW可以从存储了H(e)NB认证信息简档的H(e)NB认证信息服务器中得到H(e)NB的认证能力简档，例如H(e)NB的认证类型。该SGW可以根据认证简档来决定请求基于证书的设备认证还是基于EAP-AKA的认证。H(e)NB认证信息服务器未必是作为物理服务器实施的，而是可以与其他设备同处一地的。
参考图6，该图显示的是使用了来自H(e)NB认证信息服务器605的简档信息的方法600的一个实施方式。SGW 610应该根据从H(e)NB 615接收的H(e)NB身份(1)来从H(e)NB认证信息服务器605中取出认证简档(2和3)。然后，SGW 610根据H(e)NB 615认证简档( )来确定所要请求的是哪一种设备认证(4)。SGW 610发送一个IKE_SA_INIT响应(5)。
如果认证类型暗示只应该执行“纯设备认证”，那么SGW 610将会接受来自H(e)NB 615的IKE_AUTH请求(6)。所述SGW 610会将AUTH响应消息发送到H(e)NB 615，并且继续执行认证过程(7a)。
如果认证类型暗指应该执行“设备和HP认证”，那么SGW 610会发送一个带有“认证拒绝”消息的IKE_AUTH响应，以便指示H(e)NB 615在先前的IKE_AUTH请求消息(6)之后使用另一个用于托管方验证的IKE_AUTH请求消息(7b)。对于认证拒绝消息来说，其用途仅仅是指示H(e)NB 615跟进托管方认证，而不意味着SGW 610将会丢弃在先前的IKE_AUTH请求消息中(6)获取的设备认证相关信息。取而代之的是，在H(e)NB 615以具有用于托管方认证的认证信息的另一个IKE_AUTH来跟随设备认证IKE_AUTH请求之后，SGW610保持来自先前IKE_AUTH请求消息(6)的信息，并且使用该信息来向H(e)NB 615发送最终认证成功(或拒绝)消息。SGW 610将会根据SGW 610检索到的H(e)NB 615的认证简档来执行7a和7b。
对于H(e)NB认证来说，下列认证是必需的。首先，H(e)NB设备与运营商网络的相互认证是必需的。使用保存在TrE中的证书的认证方法应该在TrE内部运行。这种相互认证应该包括(或是紧密绑定于)平台完整性验证(即TrE属性)。相互验证的两个部分具有以下属性：1)H(e)NB的身份由网络认证，用于该认证的证书应该保存在H(e)NB的TrE中；以及2)运营商网络的身份(例如用SGW表示)是由H(e)NB的TrE认证的，并且该认证既可以对运营商网络进行一般认证，也可以对H(e)NB联系的特定SGW进行认证。SGW的身份可以由TrE通过在从SGW发送的消息中识别附属于SGW的私有密钥的使用情况来认证，其中由于该私有密钥是保持在TrE可以查阅的SGW证书中的，因此，该私有密钥是为TrE所知的。TrE可以安全地存储和处理这个SGW证书。所述SGW证书可以在来自SGW的适当IKEv2消息内部被发送至TrE。所述TrE可以用根证书预先配置，随后安全地存储和处理根证书，并且使用它来核对SGW证书。作为替换，TrE可以与外部证书机构(例如在线证书状态协议(OCSP)服务器)取得联系，以便核对SGW证书。
在合适的时候，由运营商网络实施的托管方认证也是必需的。托管方的身份是由运营商网络认证的。该认证可以采用两种方式来执行：1)托管方认证是以包含在H(e)NB的独立托管方模块(HPM)中的证书为基础的，并且在相互认证时作为附加步骤来执行；或者2)托管方的认证与设备认证是捆绑在一起的，也就是说，在相互认证之后将没有附加的认证步骤。如果不存在托管方(例如由运营商自身来提供H(e)NB)，那么后一种认证未必是相关的。
虽然当前的基本安全协议顾及了H(e)NB与核心网络之间包含设备和托管方认证的安全通信，但是当前的协议存在某些问题，这使得它们只支持关于H(e)NB或是其内部的(可选)HPM的“认证”信息，但却几乎不支持其他信息。由于H(e)NB很有可能在相对不安全的物理环境(例如人们的家中)中工作，因此，使用已知秘密的“认证”未必满足需要，并且安全协议有可能需要明确使用关于TrE和/或H(e)NB或是其任何组件的“预期状态”的信息，以此作为用于接入SGW的组成步骤。这个步骤被称为设备验证过程。
特别地，除了H(e)NB设备ID(H(e)NB_E1)以及托管方ID(H_ID)之外，将IKEv2用于H(e)NB与SGW之间的认证和安全关联建立的安全协议不包含其他任何信息。虽然这些ID在TrE和可选的HPM内部分别是受到安全保护的，但就验证而言，它们的存在(以及完整性)未必能够使得所验证的H(e)NB可以为其与核心网络的交互所信任。
相应地，在这里公开了安全协议或方法的实施方式。
在一个实施方式中，强制性设备认证(以及可选的托管方认证)的先决条件是由TrE在引导时间以及有可能在运行时间(调度型或事件驱动型)执行的完整的引导和系统状态达成。
在另一个实施方式中，在IKE_INIT阶段期间或是该阶段之后，H(e)NB在一个或多个恰当的IKEv2净荷(例如CP或V净荷，或是通知(N)消息)中发送用于表明其作为平台的可信度的信息。此类信息可以包括证书或声明，其中所述证书或声明描述的是TrE、H(e)NB或是包括HPM在内的任何组件(组合)的预计状态，其中这些组件甚至包括未能通过TrE或是H(e)NB的其他组件执行的本地完整性检查处理的一系列组件。该信息可以用一个在TrE内部得到保护的私钥来签名。
在另一个实施方式中还可以分发能够借助CA或TTP(例如TrE或H(e)NB制造商/供应商)核对的证书(通过H(e)NB将其经由SGW发送到HLR/AAA，或是通过架设HLR/AAA从带外处理中将其获取)。此类证书将会为保持在TrE内部的私钥确认公钥。由此，通过使用私钥，可以表示TrE或H(e)NB的其他部分是完好无损的。在IKEv2交换期间，H(e)NB还可以向核心网络指示应该验证H(e)NB的哪些组件的真实性或完整性。TrE可以使用特定于组件的密钥来签名和保证特定组件的有效性。如果用于TrE或H(e)NB的其他部分的证书或声明是协议自身携带的，那么可以使用诸如CP和V之类的IKEv2参数来传递该信息。作为替换，此类信息也可以在从H(e)NB到SGW的IKE_AUTH请求消息的通知(N)字段中传送。该字段还可以包括关于进程、实体和/或由TrE或H(e)NB的其他部分执行的任何设备验证以及完整性检查的结果的信息。此外，借助SK{}机制所进行的防护同样是可以考虑的。
在另一个实施方式中，通过证书(预先分发或是在协议时间交换)或是通过显性消息传递(可以保护其完整性和秘密性)，H(e)NB向SGW并且经由SGW向核心网络指示关于TrE自身的信息，该信息有利于核心网络评定通信类型、接入、以及H(e)NB可以保证的应用权限。此外，该信息也可以包含在IKEv2中，并且在适当的现有参数上传送。
在另一个实施方式中，为H(e)NB的组合认证以及设备验证所使用的可以是一个不同于IKEv2的通信协议。关于此类协议的示例可以包括但不局限于：传输层安全性(TLS)、宽带论坛技术要求(TR)069、开放移动联盟(OMA)设备管理(DM)协议、或是用于TLS扩展的某些适当的因特网工程任务组(IETF)请求意见(RFC)，其中设备认证和设备验证消息可以用一种组合方式来指示。
根据所公开的认证协议实施方式，作为先决过程的一部分或是作为先决过程，TrE可以在该TrE与H(e)NB的其他部分之间建立安全信道，其中所述其他部分包括MPU、HPM(如果包含的话)、蜂窝调制解调处理器、非蜂窝调制解调处理器、位置/定位设备、和/或时钟/定时设备。然后，安全信道建立证据将会从H(e)NB经由SGW传递到HLR/AAA，其中所述传递是在使用了受TrE保护的密钥的加密保护下进行的。然后，作为用于H(e)NB和/或托管方认证的先决条件或是先决条件的一部分，HLR/AAA可以使用该信息来评估H(e)NB的可信度。
在另一个实施方式中，TrE可以用于为H(e)NB或是其任何组件定义和实施某种特定的系统状态，其中所述组件包括HPM、位置/定位设备或是用于针对应用或业务服务器的应用层通信接入的时钟/定时设备。同样，H(e)NB也可以被“引导”并使用IKEv2而与HLR/AAA实现“网络级安全关联”，其后则会安全地引导TrE以及在安全引导的TrE的监督下引导H(e)NB的其他任何部分。但是在这之后，在允许对特定应用服务器进行服务级认证之前，TrE也有可能会在运营商或服务供应商的安全策略的指引下为其自身和/或H(e)NB的其他任何部分执行附加的“系统状态”检查。此类服务可以包括OAM服务以及用于更新H(e)NB位置和/或参考定时的服务。
在图7的关系图所显示的另一个实施方式中，安全协议还可以包括可供HLR/AAA 710或核心网络实体评定H(e)NB 705的可信度并确定其接入权利(用于网络和应用接入)，其中所述实体充当的是可信计算联盟(TCG)可信网络连接(TNC)策略决定点(PDP)。然后，充当TCG TNC策略执行点(PEP)的SGW 715将会实施访问控制策略。由此，H(e)NB 705将会充当TCG TNC访问请求方(AR)。
在另一个实施方式中，在安全协议、例如用于认证的安全协议的上下文中，充当TNC AR的H(e)NB通过自身或是通过来自SGW或HLR/AAA的请求来提供完整性量度。然后，这些完整性量度将会经由SGW转发到HLR/AAA，其中HLR/AAA充当的是TCG TNC PEP。一旦评定从H(e)NB接收的完整性量度是否满足所需要的“信任等级”，则HLR/AAA将会确定授予H(e)NB的网络接入等级。该“等级”可以包括服务范围、带宽、业务类型和总量、用于H(e)NB的应用接入和/或经由H(e)NB而与核心网络通信的任何WTRU等等的粒度组合。然后，策略决定将会从HLR/AAA转发到SGW，该SGW随后则会充当TNC PEP并实施访问控制策略，其中所述策略来自对许可给H(e)NB的访问进行管理的HLR/AAA。图7中还示出了用于该示例架构的相关TNC说明(例如，IF-M、IF-IMC、IF-IMV、IF-TNCCS、IF-T和IF-PEP)。
作为设备和/或托管方认证协议的一部分，H(e)NB的位置以及H(e)NB操作的“事件描述或日志”是用一个本地时间戳(例如TrE和/或H(e)NB的安全引导历史的时间戳版本)来公开的，其中该时间戳是由H(e)NB自身的定时功能提供的，并且是作为从H(e)NB经由SGW传送到HLR/AAA的信息的一部分而被包含的。此类位置信息和/或标有时间戳的“事件描述或日志”信息是用在TrE内部受到保护的密钥加密的。然后，HLR/AAA将会评定H(e)NB的可信度，其中所述评定不但借助于H(e)NB_EI或HPM_ID，而且还借助于包含了H(e)NB的一个或多个位置的信息，和/或涉及H(e)NB且标有时间戳的“事件描述和/或日志”。
对上文中公开的安全协议来说，可以使用CP、V或通知消息(N)之类的适当的IKEv2净荷来在H(e)NB与核心网络(以及SGW)之间传送附加信息。
现在参考图8(A)和8(B)，该图显示的是基于EAP-AKA的认证的示例信号图。图8(A)和8(B)的认证协议使用了TrE的强安全属性，以便支持用于H(e)NB 805且以EAP-AKA为基础的设备认证协议的整体安全性。应该指出，为了实施设备认证，用字母(例如A、B、C等等)标引的步骤包含了在TrE 810与H(e)NB 805的其他功能之间进行的交互。
作为设备认证的先决条件，H(e)NB 805需要向SGW 820确认其自身是一个可信任的平台(0)。H(e)NB 905根据其TrE 810来安全地提供关于H(e)NB 805的平台有效性的加密防护证据，然后，H(e)NB 805将其转发到SGW 820。SGW 820评估所述证据，并且确定H(e)NB 805是否可信到能够允许其继续执行设备认证。
H(e)NB 805向SGW 820发送一个IKE_SA_INIT请求(1)。SGW 820发送一个IKE_SA_INIT响应(2)。H(e)NB 805通过将IKE_SKA_INIT响应转发到TrE 810来从TrE 810请求HNB_ID(A)。TrE 810则检查IKE_SKA_INIT响应的完整性并从HNB_ID中构造IDi(B)。所述TrE 810向H(e)NB 805发送IDi净荷和状态(例如声明TrE 810完成从HNB_ID中构成IDi的处理)(C)。
H(e)NB 805将IDi净荷发送到SGW 820，并且开始协商子安全关联(child security association)(3)。在这里将会忽略AUTH，以便向SGW 820告知H(e)NB 805希望执行EAP认证。如果需要动态配置H(e)NB 805的远程IP地址，则在该消息中传送配置净荷。此外，H(e)NB 805还从SGW 820那里请求一个证书。应该指出的是，通过IDi净荷给出的网络地址标识符(NAI)来选择的用户简档将会实施认证选择处理(证书、EAP-AKA或是证书-EPA-AKA-多重认证)。
SGW 820向AAA服务器830发送带有空的EAP属性值配对(AVP)的认证请求消息，其中该消息包含了在IKE_AUTH请求消息中接收的身份(4)。如有必要，AAA服务器830应该从HSS/HLR 840或其它认证实体取回设备简档和认证矢量(5)。然后，AAA服务器830将会启动认证质询(challenge)(6)。
SGW 820向H(e)NB 805发送一个IKE_AUTH响应(7)。在这里将会包含从AAA服务器830接收的EAP信息(EAP请求/AKA质询(EAP_Request/AKA_Challenge))，以便开始借助IKEv2的EAP过程。如果H(e)NB的TrE 810需要根据SGW 820的证书来认证SGW 820，则在该消息中向H(e)NB 805发送SGW 820的身份、证书以及用于保护先前消息的AUTH参数(在IKE_SA_INIT交换中)。
供SGW 820认证和计算针对所述认证质询的响应所需要的材料将被转发给TrE 810(D)。TrE 810从RAND、AUTN中计算RES，并且如果H(e)NB 805需要根据SGW 820的证书来对SGW 820进行认证，那么它还会可选的对认证参数进行检查(E)。当SGW 820认证成功时，TrE 810会将RES连同一个可选的状态消息一起递送到H(e)NB 805。
H(e)NB 805对该认证质询做出响应(8)。IKEv2信息中的唯一净荷(除了报头之外)是EAP消息。SGW 820将EAP响应/AKA质询(EAP_Response/AKA_Challenge)消息转发到AAA服务器830(9)。当所有检查全都成功时，AAA服务器830会向SGW 820发送包含了EAP成功和密钥材料的认证应答(10)。该密钥材料应该包括在认证过程中产生的主会话密钥(MSK)。
MSK应该被SGW 820用来产生AUTH参数，以便认证IKE_SA_INIT阶段消息(11)。EAP成功消息经由IKEv2而被转发到H(e)NB 805。并且该EAP成功消息将被转发到TrE 810(G)。TrE 810使用其自身的MSK副本作为输入来产生AUTH参数，以便认证第一IKE_SA_INIT消息(H)。然后，TrE 810会将AUTH转发到H(e)NB 805(I)。
H(e)NB 805构造IKE_AUTH请求，并且将其连同AUTH参数一起发送到SGW 820(13)。然后，SGW 820对从H(e)NB 805接收的AUTH的正确性进行检查，并且计算AUTH参数，其中该参数将会认证第二IKE_SA_INIT消息。如果H(e)NB 805曾经通过CFG_REQUEST请求远程IP地址，那么SGW 820应该在配置净荷(CFG_REPLY)中发送所指派的远程IP地址。然后，AUTH参数将会连同配置净荷、安全关联以及剩余的IKEv2参数一起发送至H(e)NB 805，并且IKEv2协商终止(14)。
如果SGW 820发觉用于H(e)NB 805的旧IKE SA已经存在，那么它会删除该IKE SA，并且会向H(e)NB 805发送带有Delete净荷的INFORMATIONAL交换，以便删除H(e)NB 805中的旧的IKE SA(15)。
在另一个实施方式中，用于设备认证的协议可以基于参考图9所示的证书。基于IKEv2证书的相互认证是根据RFC-4306因特网密钥交换(IKEv2)协议执行的。该证书处理和简档可以依附于指定规范，但是由于实施正式证书注册和撤销处理的复杂度很高，并且有可能可以使用更为简单的替换方案，因此，在这里未必需要实施证书注册和证书撤销，其中举例来说，所述更简单的替换方案可以是使用黑名单或白名单来处理那些因为期限届满或设备证书的其他问题而无法通过认证检查的设备。应该指出的是，图9中用字母标引的步骤(如A、B、C、……)包括为了设备认证而在TrE 910与H(e)NB 905之间进行的交互。
作为基于EAP-AKA的设备认证的先决条件，H(e)NB 905需要向SGW 920证明其自身是一个值得信赖的平台(0)。H(e)NB 905依靠其TrE 910来提供关于H(e)NB 905的平台有效性的加密防护证据，然后，H(e)NB905将这个证据转发到SGW 920。SGW 920对该证据进行评估，并且确定H(e)NB 905是否足够可信，以便允许其继续执行设备认证。
H(e)NB 905向SGW 920发送一个IKE_SA_INIT请求(1)。SGW 920则会发送IKE_SA_INIT响应，以便从H(e)NB 905那里请求一个证书(2)。H(e)NB 905通过向TrE 910转发IKE_SKA_INIT响应来从TrE 910那里请求HNB_ID(A)。TrE 910则会检查IKE_SKA_INIT响应的完整性，从HNB_ID中构成IDi，提取设备CERT，并且使用设备CERT来计算AUTH(B)。该TrE 910向H(e)NB 905发送IDi、AUTH、CERT以及状态(例如声明TrE 910完成了从HNB_ID中构成IDi的处理，计算AUTH的处理，检索CERT的处理等等)(C)。
H(e)NB 905发送IDi净荷，并且开始协商子安全关联(3)。所述H(e)NB 905还会发送AUTH净荷、自己的证书、以及一个要求从SGW 920得到证书的请求。如果需要动态配置H(e)NB 905的远程IP地址，那么还会在该消息中发送配置净荷。对于借助在IDi净荷中给出的网络地址标识符(NAI)来选择的用户简档来说，该用户简档将会实施认证选择处理(证书、EAP-AKA、或是证书-EPA-AKA-多重认证)。
SGW 920对从H(e)NB 905接收的AUTH的正确性进行检查，并且计算AUTH参数，其中所述参数将会认证第二IKE_SA_INIT消息(4)。该SGW 920对从H(e)NB 905接收的证书进行核实。SGW 920将AUTH参数及其证书连同配置净荷、安全关联以及剩余的IKEv2参数一起发送到H(e)NB 905，并且IKEv2协商终止(5)。如果H(e)NB 905曾经通过CFG_REQUEST请求了远程IP地址，则在配置净荷(CFG_REPLY)中指派所述远程IP地址。
H(e)NB 905将SGW 920的证书转发到TrE(910)(D)。TrE 910使用其安全存储的根证书来核对SGW 920的证书(E)。更进一步，H(e)NB也会验证SGW 920的证书。TrE 910将SGW CERT核对状态转发给HeNB 905(F)。如果SGW 920发觉用于H(e)NB 905的旧IKE SA已经存在，那么它会删除所述IKE SA，并且向H(e)NB 905发送带有Delete净荷的INFORMATIONAL交换，以便删除H(e)NB 905中的旧IKE SA(6)。
在这里可以使用一种在基于证书的设备认证之后继之以托管方认证的组合认证，其中在所述组合认证中，TrE和HPM(例如UICC)必须与剩余的H(e)NB进行交互，并且SGW可被利用。特别地，TrE可以保护HPM产生或接收的任何信息，以便对托管方或设备进行认证。更进一步，TrE可以与HPM建立一条安全信道，由此，HPM在认证协议期间接收或发送的任何信息都可以受到该安全信道的保护。
图10(A)和(B)显示的是基于EAP-AKA以及证书的组合认证的信号图的实施方式。在图10(A)和(B)中，用字母(例如A、B、C、......)标引的步骤包含了为了实施该组合认证过程而在TrE 1010与包括HPM 1050在内的H(e)NB 1005的其他功能之间执行的交互。
该信号流程显示了在H(e)NB 1005与SGW 1020之间进行的基于证书的相互认证，继而则是在H(e)NB 1005与AAA服务器1030之间进行的EAP-AKA AUTH交换。在一开始，H(e)NB 1005向SGW 1020发送一个IKE_SA_INIT请求(1)。SGW 1020则发送IKE_SA_INIT响应，以便从H(e)NB 1005那里请求一个证书(2)。所述SGW 1020通过包含MULTIPLE_AUTH_SUPPORTED净荷来表明其支持多重认证。
H(e)NB 1005开始协商子安全关联(3)。首先，H(e)NB 1005请求TrE 1010构成IDi净荷(从HeNB_EI中)，并且进行计算以及将加密封装向其进行转发：
SK{SA，TSi，TSr，IDi＝NAI，IDr，CP(CFG_REQUEST)，AUTH，CERTREQ，CERT，N(MULTIPLE_AUTH_SUPPORTED)，N(ANOTHER_AUTH_FOLLOWS)}
H(e)NB 1005向SGW 1020转发IKE_AUTH请求，其中该请求包括报头(HDR)以及加密净荷SK{...}。所述加密净荷包含了AUTH净荷、H(e)NB 1005自身的证书以及一个要求从SGW 1020得到证书的请求。如果需要动态配置H(e)NB 1005的远程IP地址，则在该消息中会传送配置净荷。H(e)NB 1005通过包含MULTIPLE_AUTH_SUPPORTED和ANOTHER_AUTH_FOLLOWS属性来表明其支持多重认证以及其希望执行第二认证。对于借助在IDi净荷中给出的网络地址标识符(NAI)来选择的用户简档来说，该用户简档将会实施认证选择处理(证书，EAP-AKA，或是证书-EPA-AKA-多重认证)。
SGW 1020对从H(e)NB 1005接收的AUTH的正确性进行检查，并且计算用于认证第二IKE_SA_INIT消息的AUTH参数(4)。该SGW 1020对从H(e)NB 1005接收的证书进行核实。并且该SGW 1020会将AUTH参数及其证书发送到H(e)NB 1005(5)。
H(e)NB 1005将加密净荷SK{IDr，AUTH，SGW Certi}转发到TrE 1010，所述TrE 1010解密该净荷，并且提取IDr、AUTH以及SGW Certi。然后，TrE 1010使用其存储的根证书来核对SGW 1020的证书(6)。更进一步，H(e)NB 1005也可以验证SGW 1020的证书，这是因为该证书是受运营商控制的。
H(e)NB 1005请求TrE 1010形成另一个IKE_AUTH请求消息的加密部分，其中AUTH将被省略，以便向SGW 1020告知H(e)NB 1005希望执行EAP认证(7)。所述加密部分是SK{IDi＝NAI，IDr}。然后，H(e)NB1005将会准备一个报头(HDR)，并且向SGW 1020发送HDR、SK{IDi＝NAI，IDr}。
SGW 1020向AAA服务器1030发送带有空的EAP AVP的认证请求消息，其中该消息包含了在IKE_AUTH请求消息中接收的身份(8)。AAA服务器1030则应该从家用订户服务器/家用位置寄存器1040中取回用户简档和认证矢量(9)。所述AAA服务器1030将会启动认证质询(10)。
SGW 1020向H(e)NB 1005发送IKE_AUTH响应(11)。在这里将会包含从AAA服务器1030接收的EAP消息(EAP_Request/AKA_Challenge)，以便开始借助IKEv2的EAP过程。如果H(e)NB 1005需要根据SGW 1020的证书来认证SGW 1020，则在该消息中包含SGW 1020的身份、SGW证书以及用于保护其发送给H(e)NB 1005的先前消息(在IKE_SA_INIT交换中)的AUTH参数。
TrE 1010通过首先交换安全关联(SA)来建立一条连至HPM 1050的安全信道。然后，作为建立安全信道的结果，TrE 1010以及HPM 1050将会绑定到使用RAND和AUTN的认证会话。随后，TrE 1010会向HPM 1050转发一个认证质询(A)。
HPM 1050计算AKA响应(RES)(B)。该HPM 1050将会经由该安全信道来向TrE 1010发送AKA响应(RES)(C)。
H(e)NB 1005对所述认证质询做出响应(12)。IKEv2消息中的唯一净荷(除了报头之外)是EAP消息，其中该消息包含了由HPM 1050计算、然后由TrE 1010借助IKEv2加密并且随后转发至H(e)NB 1005的RES。如果H(e)NB 1005需要根据SGW 1020的证书来认证SGW 1020，那么H(e)NB 1005将会检查认证参数。
SGW 1020向AAA服务器1030转发EAP_Response/AKA_Challenge消息(13)。当所有检查全都成功时，AAA服务器1040会向SGW 1020发送包含了EAP成功和密钥材料的认证应答(14)。该密钥材料应该包含在认证过程中产生的MSK。并且所述MSK应该被SGW 1020用于产生AUTH参数，以便认证IKE_SA_INIT阶段消息(15)。所述EAP成功消息将会经由IKEv2转发至H(e)NB 1005(16)。
H(e)NB 1005向TrE 1010转发经过加密的EAP成功消息(即SK{EAP Success message})(17)。TrE 1010则应该采用其自身的MSK副本作为输入来产生用于认证第一IKE_SA_INIT消息的AUTH参数。所述AUTH参数通过借助IKEv2加密而被从TrE 1010发送到H(e)NB 1005。该H(e)NB 1005则向SGW 1020发送经过加密的AUTH参数。
SGW 1020解密并检查从H(e)NB 1005接收的AUTH的正确性，并且计算用于认证第二IKE_SA_INIT消息的AUTH参数(18)。如果H(e)NB 1005曾经通过CFG_REQUEST向其请求远程IP地址，则SGW 1020应该在配置净荷(CFG_REPLY)中发送所指派的远程IP地址。然后，AUTH参数将会连同配置净荷、安全关联以及剩余的IKEv2参数一起被发送到H(e)NB 1005，并且IKEv2协商终止。
如果SGW 1020发觉用于H(e)NB 1005的旧IKE SA已经存在，那么它会删除所述IKE SA，并且向H(e)NB 1005发送带有Delete净荷的INFORMATIONAL交换，以便删除H(e)NB 1005中的旧IKE SA(19)。
在认证过程中还可以使用绑定H(e)NB TrE，HPM以及H(e)NB自身的处理。在这里给出了某些假设。在这里假设大多数设备都具有唯一ID。举个例子，H(e)NB_EI是由H(e)NB的制造商指派的，TrE_ID是由TrE的制造商指派的，HPM_ID则是由HPM的制造商指派的。此外还应该理解，代表运营商核心网络的SGW会与H(e)NB执行相互认证。并且众所周知，HLR/AAA服务器包含了用于H(e)NB的家用位置寄存器(HLR)以及认证中心。所述HLR保存了关于与每一个HPM_ID相对应的H(e)NB_EI和TrE_ID的记录，由此可以通过使用其相应ID、也就是TrE_ID、H(e)NB_EI以及HPM_ID来表示TrE、H(e)NB以及HPM之间的绑定关系。所述AAA服务器则会根据这些记录来执行绑定认证。
在这里公开了用于绑定这三个ID的方法的一个实施方式。H(e)NB向SGW转发H(e)NB_EI、TrE_ID以及(可选的)HPM_ID。SGW则向HLR/AAA服务器转发它从H(e)NB接收的H(e)NB_EI。HLR/AAA服务器发现其记录中具有的与H(e)NB_EI相对应的TrE_ID以及HPM_ID。如果在HLR的记录中发现的TrE_ID和HPM_ID与从H(e)NB接收的相同，则可以确定该H(e)NB是绑定到TrE和HPM的合法设备。
就下述协议所传达的认证声明可信度而言，所有敏感数据全都可以仍旧由TrE和HPM保护。特别地，H(e)NB的认证秘密代表了H(e)NB和H(e)NB_EI的绑定认证，并且它可以安全地保存在TrE中。TrE也可以安全地存储TrE_ID。此外，HPM_ID以及相应的认证秘密还可以安全地保存在HPM中并由HPM处理。安全信道可以用于将这个来自TrE或HPM的数据传送到SGW。
图11示出的是三向绑定认证的一个实施方式。在一开始，TrE 1110检索其安全保持的TrE_ID和H(e)NB_EI(1)。然后，TrE 1110使用AKA RAND和AUTN来与HPM 1120建立安全信道(2)。该TrE 1110从HPM 1120请求并接收HPM_ID(3)。所述HPM_ID经由安全信道发送并受其保护(4)。然后，TrE 1110将TrE_ID、H(e)NB_EI以及HPM_ID转发到SGW 1130(5)。
SGW 1130将TrE_ID、H(e)NB_EI以及HPM_ID转发到HLR/AAA 1140(6)。在接收到这些ID之后，HLR/AAA 1140的HLR部分搜索与TrE_ID以及HPM_ID相对应的H(e)NB_EI(7)。然后，HLR/AAA 1140的AAA部分使用与TrE_ID以及HPM_ID相对应的H(e)NB_EI来核实它从SGW 1130接收的H(e)NB_EI(8)。之后，HLR/AAA 1140的HLR部分向SGW 1130发送关于TrE 1110和HPM 1120的绑定认证(9)。接下来，SGW 1130将关于TrE 1110和HPM 1120的绑定认证转发到TrE 1110(10)。TrE 1110则经由安全信道来向HPM 1120转发关于HPM 1120的绑定认证。
当TrE与H(e)NB紧密整合(例如TrE是H(e)NB上的一个芯片等等)的时候，由于TrE在物理上绑定于H(e)NB_EI，因此，这时不必显性地将TrE绑定到H(e)NB。在这种情况下，在H(e)NB与HPM之间可以实现双向绑定。实际上，在这种情况下，H(e)NB的身份可以通过认证TrE的身份来认证，也就是说，H(e)NB_EI与TrE_ID是完全相同的。
图12显示了双向绑定认证的一个实施方式。在一开始，TrE 1210检索其安全保持的H(e)NB_EI(1)。应该指出的是，H(e)NB_E1与TrE_ID是相同的。TrE 1210使用AKA RAND和AUTN来与HPM 1220建立安全信道(2)。接下来，TrE 1210请求并且在安全信道中接收来自HPM的HPM_ID(4)。然后，TrE 1210将H(e)NB_EI和HPM_ID转发到SGW 1230(5)。
SGW 1230将H(e)NB_EI和HPM_ID转发到HLR/AAA 1240(6)。然后，HLR/AAA 1240的HLR部分搜索与HPM_ID相对应的H(e)NB_EI(7)。之后，HLR/AAA 1240的AAA部分通过比较它从SGW1230接收的H(e)NB_EI以及在其记录中与HPM_ID相对应的H(e)NB_EI来核实它从SGW 1230接收的H(e)NB_EI(8)。然后，HLR/AAA 1240的HLR部分向SGW 1230发送关于TrE 1210以及HPM 1220的绑定认证(在这种情况下，这种处理与验证H(e)NB是等价的)(9)。接下来，SGW 1220将关于TrE 1210(等价于H(e)NB)和HPM 1220的绑定认证转发到H(e)NB的TrE 1210(10)。TrE 1210则在安全信道的保护下将关于HPM 1220的绑定认证转发到HPM 1220(11)。
图13显示了以组合方式执行认证和设备验证的方法的一个实施方式。在本实施方式中，IKEv2协议被用于组合设备验证和设备认证。但是，用于设备或装置认证的其他协议包括但不局限于传输层安全性(TLS)、安全超文本传输协议(HTTPS)、OMA DM、TR069、……。
在一开始，H(e)NB 1310的TrE执行安全引导，并且检查H(e)NB 1310的完整性(1)。然后，H(e)NB 1310启动IKEv2会话，并且向SGW 1320发送一个IKE_SA_INIT请求消息，其中该消息包括HDR、SA(安全关联)、KE(Diffie-Hellman密钥元素)以及Ni(发起方现时值(initiator nonce))(2)。一旦接收到这个信号，SGW 1320向H(e)NB 1310发送一个IKE_SA_INIT响应，其中该响应包含了HDR、SA、KE、Nr(应答现时值)以及CERTREQ(它是一个关于设备证书的请求)(3)。现在，通过在两端使用KE，H(e)NB 1310和SGW 1320中的每一个都产生密码密钥，以便在IKEv2会话期间保护进一步的消息交换的机密性和完整性。
然后，H(e)NB 1310向SGW 1320发送一个IKE_AUTH请求消息，其中该消息的机密性和完整性是受Diffie-Hellman生成密钥保护的(4)。该消息的内容包括不被保护的HDR(报头)和受保护的部分，其中所述受保护的部分包括：SA(安全关联)、TSi(发起方的业务选择器)、TSr(应答方的业务选择器)、IDi(它是采用了NAI格式的H(e)NB 1310的ID)、IDr(它是SGW 1320的ID)、以及CP(配置参数)、用于指示由H(e)NB 1310执行的设备完整性检查的进程或结果的通知消息、由H(e)NB 1310的TrE作为表明H(e)NB保持了有效设备证书的证据来计算的AUTH参数、CERTREQ(它是一个要求用于服务器端认证的服务器端证书的请求)、以及CERT(它是SGW 1320用以认证H(e)NB 1310的设备证书)。
一旦接收到这个消息，SGW 1320将会提取设备完整性检查数据(VAL_DATA)，并且将其发送到验证实体1330(5)，随后，该实体使用所转发的VAL_DATA及其可能具有的其他任何参考信息来评定H(e)NB 1310的可信度或完整性(6)，如果它从设备完整性的角度评定该H(e)NB 1310是正确的，则向SGW 1320发回一个验证响应信号(7)。一旦接收到来自验证实体1330的肯定验证响应，则SGW 1320可以核实它从H(e)NB 1310接收的H(e)NB证书(CERT)，并且检查它是否可以认证H(e)NB 1310(8)。如果可以的话，则SGW 1320可以发送一个IKE_AUTH响应消息，其中该响应包含了HDR(不被保护的报头)以及受保护的部分，所述受保护的部分包括AUTH(关于其自身的服务器端认证的证据)、CP、SA、TSi以及TSi)(9)。
作为替换，用于检查SGW 1320与验证实体1330之间的VAL_DATA的步骤可以在SGW 1320核实了H(e)NB的证书、认证了H(e)NB 1310以及向H(e)NB 1310发送了IKE_AUTH响应消息之后进行。
一旦接收到IKE_AUTH响应消息，则H(e)NB 1310可以使用它从SGW 1320接收的服务器CERT来进行核实(10)。
TrE还可以确保将位置信息用于H(e)NB认证的处理的安全性。首先，H(e)NB的TrE可以通过执行若干种功能来保护位置信息处理的安全性，其中所述功能包括认证过程中的检索、存储、保护及使用。更具体地说，由这里描述的定位方法认证的任何位置信息都可以采用一种可信赖的方式存储和处理。这意味着此类信息可以在H(e)NB的TrE的保护下存储和处理。更具体地说，H(e)NB的TrE可以从此类信息来源接收加密防护位置信息。并且它还可以安全地解码此类加密位置信息。更进一步，在存储时，它可以非常安全地保护位于TrE或是在外部使用TrE内部安全存储的密钥进行了密码保护的位置信息。TrE可以提取保持在TrE内部或是来自外部存储器的位置信息。在将位置信息转发给SGW之前，它可以通过对其进行加密来保护位置信息。此外它还可以将加密位置信息转发给SGW，以便将其包含在设备认证协议中。
同时，在位置注册(或认证)处理或位置验证处理期间，在将位置信息传送给HLR时，H(e)NB的TrE可以使用密码保护装置来保护H(e)NB发送给HLR的位置信息的完整性和/或机密性。它还可以提供关于H(e)NB从HLR接收的任何加密防护位置相关信息的安全密码处理，这其中包括解密和完整性检查。用于H(e)NB上的这些用途的任何密码密钥都可以由H(e)NB的TrE保护。此外，H(e)NB的TrE还可以确保H(e)NB内部那些与获取、存储和处理敏感位置信息的处理相关的功能的真实性，并且可选地确保这些功能的完整性。
在这里公开了根据所选择的特定位置信息来实施位置注册和位置认证的实施方式。
H(e)NB可以经由某些接入设备(例如DSL调制解调器、电缆调制解调器、家用路由器等等)而与IP网络相连，并且可以具有宽带接入供应商提供的IP地址。通过绑定宽带接入网络的物理端口以及地理信息，运营商可以定位该H(e)NB。
在初始注册了H(e)NB位置信息之后，所指派的IP地址、用户标识以及设计IP地址的位置信息将会保存在网络数据库中。核心网络(CN)可以通过查询数据库来获取IP地址、与IP地址绑定的一个或多个端口号、和/或地址信息(甚至是经度和纬度)。该位置检查机制包括1)注册H(e)NB位置信息；以及2)验证H(e)NB位置)。
位置注册是在H(e)NB首次通电以及通过IP回程连接到核心网络的时候进行的。在一开始，H(e)NB向HLR发送一个请求消息，其中在这个消息中携带了它的IP地址。然后，HLR向网络数据库发送一个携带了接收到的IP地址的位置信息查询消息。根据该IP地址，数据库通过查询表格来获取上述H(e)NB的接入线位置信息，例如与IP地址绑定的端口号乃至经度和纬度(如果可用的话)。然后，HLR根据所获取的信息来确定H(e)NB的位置。之后，HLR注册这个H(e)NB的位置。然后，HLR会在针对H(e)NB的响应消息中做出答复。在位置注册之后，HLR可以将所述位置存储为H(e)NB简档的一个属性，由此将其视为位置判断判据。
位置认证是在H(e)NB每次向接入网络发出请求的时候进行的。因此，在这里没有必要进行注册。在一开始，H(e)NB向HLR发送一个带有其IP地址的接入请求消息。在传送此类IP地址时，H(e)NB的TrE可以自身保护的密码密钥来保护此类IP地址的完整性和/或置信度。所有密码加密处理都可以在TrE内部进行。
一旦接收到H(e)NB的IP地址，则HLR首先检查IP地址的完整性，如果它进行检查，则通过再次查询数据库来获取位置信息。然后，HLR认证它从H(e)NB获取的接入线位置信息是否对应于它从自身的数据库中为同一H(e)NB检索的位置信息。如果相同，则HLR在其数据库中保持H(e)NB的现有位置。
HLR使用响应消息中的位置认证结果来答复H(e)NB。如果从H(e)NB新获取的接入线位置信息不与H(e)NB简档中的相匹配，则HLR返回一个拒绝H(e)NB接入的H(e)NB接入响应消息，并且将“无效位置”指示为原因值。如果接入线位置信息匹配，则HLR返回一个允许H(e)NB接入的H(e)NB接入响应。
虽然H(e)NB的位置可以使用位置认证来确定，但是IP地址欺诈攻击仍旧是可能的。例如，当H(e)NB被重新定位到另一个区域时，代理服务器有可能采用与合法注册的相同的IP地址。然后，就位置而言，此类代理服务器有可能将其自身诊断成是所述合法H(e)NB。
在以上任何一个由H(e)NB从HLR接收信息或消息的步骤中，如果此类信息是用密码保护的，那么此类信息或消息的解密和完整性检查是在H(e)NB TrE内部通过使用受H(e)NB TrE保护的密钥来执行的。
现在将要公开的是一个基于相邻宏小区的实施方式。为了根据宏小区信息来进行定位，在宏小区的覆盖范围中必须安装H(e)NB，其中所述H(e)NB具有3G或2G接收机，并且能够切换到接收机工作状态，以便扫描与H(e)NB相邻的宏3G或2G小区。基于宏小区的位置锁定机制与上文中的机制相似，但是该位置信息是用关于宏小区的信息的格式给出的，其中举例来说，所述信息可以是公共陆地移动网络(PLMN)ID、位置区域信息(LAI)或小区ID。
初始步骤是注册H(e)NB位置信息。在H(e)NB通电之后，它会扫描相邻的宏小区。然后，H(e)NB向HLR发送H(e)NB请求消息。该消息携带的是诸如相邻宏小区的位置区域和小区ID之类的信息。H(e)NB的TrE可以使用自身保护的密钥来保护此类位置区域和小区ID信息的完整性和/或置信度。所有密码加密处理都可以在TrE内部进行。HLR则将相邻宏小区的小区ID注册为H(e)NB简档属性，并且向H(e)NB发送H(e)NB响应消息。
接下来的步骤是认证H(e)NB的位置。H(e)NB向HLR发送一个接入请求消息。该消息携带了相邻宏小区的未知区域和小区ID之类的信息。在将此类位置信息和小区ID信息传送给HLR时，H(e)NB的TrE可以使用受其自身保护的密钥来保护所述信息的完整性和/或置信度。HLR将相邻宏小区的信息与已存储的H(e)NB简档相比较，以便确定是否允许H(e)NB经由绑定的小区或位置区域连接到网络。如果相邻宏小区的信息不与H(e)NB简档相匹配，则HLR返回一个拒绝H(e)NB接入的H(e)NB接入响应消息，并且将“无效位置”指示为原因值。如果相邻宏小区的信息与H(e)NB简档相匹配，则HLR返回一个允许H(e)NB接入的H(e)NB接入响应。
在以上任何一个由H(e)NB从HLR接收信息或消息的过程中，如果任何此类信息都是用密码加密保护的，那么此类信息或消息的解密和完整性检查既可以在H(e)NB TrE内部执行，也可以使用受H(e)NB TrE保护的密钥来执行。
宏小区具有大面积覆盖范围。因此，仅仅使用小区信息未必满足某些使用范例的精确需求。而使用IP地址与宏小区信息的组合则可以提高精确度。
在这里公开了一个基于IP地址与相邻宏小区的组合的实施方式。初始步骤是H(e)NB位置信息注册。H(e)NB向HLR发送一个请求消息，其中在所述请求消息中携带了其地址和相邻小区ID。在将IP地址和小区ID传送到HLR时，H(e)NB的TrE可以使用其自身保护的密码密钥来对这些信息的完整性和/或置信度进行密码保护。所有密码处理可以在TrE内部进行。
然后，HLR向固定网络数据库发送一个带有所接收的IP地址的位置信息查询消息。根据该IP地址，HLR查询数据库，以便获取与H(e)NB IP地址绑定的接入线位置信息。根据接入线位置信息以及相邻宏小区ID，HLR确定H(e)NB的家用区域。该HLR将这个H(e)NB的接入线位置信息连同接收到的小区ID一起作为H(e)NB属性来加以保存。
接下来的步骤是认证H(e)NB位置。HLR接收来自H(e)NB的接入请求消息，其中该消息带有其IP地址以及周围宏小区的小区ID。根据新的IP地址，HLR再次查询数据库，以便获取接入线位置信息。然后，HLR确定新获取的接入线位置信息与已存储的是否相同，并且还判定接收到的小区ID是否与已存储的轩昂同。如果这二者都是相同的，则不改变H(e)NB位置。接下来，HLR会在接入响应消息中向H(e)NB答复位置认证结果。
在以上任何一个由H(e)NB接收来自HLR的信息或消息的过程中，如果此类信息是用密码保护的，则可以在H(e)NB TrE内部通过使用受H(e)NB TrE保护的密钥来执行此类信息或消息的解密和完整性检查。
应该指出的是，即使H(e)NB移动到另一个未注册地址，H(e)NB仍旧可以被定位在相同的宏小区。该方案可以提高位置认证方案的安全性。
在这里公开了一个基于全球定位系统(GPS)的实施方式。当H(e)NB内置了GPS能力时，其位置信息可以借助H(e)NB内部的GPS来获取，随后则可以在接入请求期间被从H(e)NB发送到CN。但是，在某些室内环境中，GPS未必正常工作。
H(e)NB的TrE可以使用其自身保护的密钥来对发送给HLR的任何GPS位置信息的完整性和/或置信度进行密码保护。H(e)NB的TrE可以使用在TrE内部受到保护的密钥来安全地处理所述H(e)NB从HLR接收的任何加密防护信息或消息的所有密码保护处理。
基于GPS的位置认证方法的安全性同样是可以使用防篡改或篡改明显的GPS设备来保护，尤其是将GPS功能隔离在单独芯片的情况下。举例来说，在这里可以使用安全性增强的GPS芯片。
在另一个实施方式中，H(e)NB的TrE还可以以周期性间隔和/或在发生某个预定事件时安全地存储“上一个已知良好位置”。这种“上一个已知良好位置”是经过网络运营商的位置服务器证明的位置信息。一旦重新引导H(e)NB，则H(e)NB的TrE可以查找已存储的“上一个已知良好位置”，并且将其与它新近从其位置识别方法中获取的位置相比较。然后，TrE可以使用该比较的结果来自动确定H(e)NB的位置是否有可能发生了变化。此外，TrE还可以将该结果报告给网络上的位置服务器。
现在论述的是H(e)NB位置策略选项和配置。使用哪一种方法取决于多个因素，例如运营商需要的安全性等级和精确度等级，H(e)NB能力，现有宏覆盖。通过应用策略，有助于确定所要使用的方法。在这里建议的是在H(e)NB中预先配置策略以及H(e)NB自动适应该策略。用于位置认证方法的任何安全策略都可以从H(e)NB的TrE内部管理。
如果单独使用IP地址，那么安全性未必是足够的。在某些室内环境中，GPS未必正常工作，并且它还增加了H(e)NB的成本。考虑到可行性和安全需求，在这里可以设想基于IP地址和相邻宏小区的位置锁定机制。这种方法可以在策略列表上被排在首位。如果没有宏小区覆盖，则可以根据策略中的偏好顺序来使用其他方法。由于GPS增加了成本并且并非在所有H(e)NB内部都安装了GPS，因此，基于GPS的定位方法在偏好顺序中的位置可能较低。如表5所示，不同的情境和策略组合以及未显示的其他组合都是可以存在的。
表5
 情景/情境  策略
 存在宏小区并且安全需求高  IP地址+宏小区
 不存在宏小区  IP地址
 存在宏小区并且精确度需求低  宏小区
 在H(e)NB中安装了GPS  GPS信息+IP地址
 在H(e)NB中安装了GPS并且宏小区存在  GPS信息+IP地址+宏小区
实施例
1.一种家用节点B/家用演进型节点B(H(e)NB)，其中包括可信环境(TrE)。
2.如实施例1所述的H(e)NB，包括：H(e)NB功能模块。
3.如前述任一实施例所述的H(e)NB，包括：介于TrE与H(e)NB功能模块之间的接口，该接口被配置成提供多个安全性等级。
4.如前述任一实施例所述的H(e)NB，其中TrE被配置成与H(e)NB功能模块进行交互，以便提供安全性和认证。
5.如前述任一实施例所述的H(e)NB，其中安全性和认证包括TrE或H(e)NB认证以及附条件的托管方认证中的至少一项。
6.如前述任一实施例所述的H(e)NB，其中TrE包括用于确保密钥、秘密、敏感数据和程序中的至少一项的安全的存储区域。
7.如前述任一实施例所述的H(e)NB，其中TrE包括一个安全运行环境，用于执行关于TrE或H(e)NB中的至少一个的基于认证密钥协议(AKA)和证书为基础的认证中的至少一项。
8.如前述任一实施例所述的H(e)NB，其中TrE包括一个安全运行环境，该安全运行环境执行与向网络至少安全指示的有效性的处理相关的安全性敏感操作。
9.如前述任一实施例所述的H(e)NB，其中安全运行环境保护并验证H(e)NB的位置。
10.如前述任一实施例所述的H(e)NB，其中在验证了位置的条件下提供网络授权。
11.如前述任一实施例所述的H(e)NB，包括：用于为托管方提供基于认证密钥协定(AKA)的认证的托管方模块(HPM)，其中HPM与TrE相连。
12.如前述任一实施例所述的H(e)NB，其中HPM是用通用集成电路卡(UICC)实现的。
13.如前述任一实施例所述的H(e)NB，其中TrE被配置成验证H(e)NB的设备完整性，并且向安全网关(SGW)传送与设备认证指示相结合的完整性指示。
14.如前述任一实施例所述的H(e)NB，其中TrE被配置成支持多重认证。
15.如前述任一实施例所述的H(e)NB，其中TrE被配置成支持相互认证。
16.如前述任一实施例所述的H(e)NB，其中TrE被配置成根据H(e)NB、TrE以及附条件的托管平台的记录和标识来执行绑定认证。
17.如前述任一实施例所述的H(e)NB，其中TrE被配置成执行位置锁定，其中位置锁定包括H(e)NB位置信息注册和/或H(e)NB位置信息认证。
18.如前述任一实施例所述的H(e)NB，其中位置信息是以相邻宏小区为基础的。
19.如前述任一实施例所述的H(e)NB，其中位置信息是以IP地址为基础的。
20.如前述任一实施例所述的H(e)NB，其中位置信息是以IP地址和宏小区为基础的。
21.如前述任一实施例所述的H(e)NB，其中位置信息是以全球定位系统为基础的。
22.如前述任一实施例所述的H(e)NB，其中认证类型是用IKEv2协议的IKE_AUTH请求来指示的。
23.如前述任一实施例所述的H(e)NB，其中IKE_AUTH请求中的预定参数表示基于证书的H(e)NB或TrE认证或是基于可扩展认证协议-认证密钥协定(EAP-AKA)的H(e)NB或TrE认证之一。
24.如前述任一实施例所述的H(e)NB，其中附条件的托管方认证是使用可扩展认证协议-认证密钥协定(EAP-AKA)来执行的。
25.如前述任一实施例所述的H(e)NB，其中用于H(e)NB功能模块、TrE以及网络之间交互的协议包括下列各项中的至少一项：因特网密钥交换(IKEv2)、传输层安全性(TLS)、宽带论坛技术需求(TR)069、或开放移动联盟(OMA)设备管理(DM)。
26.一种结合网络来认证家用节点B/家用演进型节点B(H(e)NB)的方法，包括：启动针对网络的安全接入。
27.如实施例26所述的方法，包括：接收第一需求，其中该需求表示设备认证或是设备认证及托管方认证。
28.如实施例26～27中任一实施例所述的方法，包括：接收第二需求，其中该需求是基于证书的认证或可扩展认证协议-认证密钥协定(EAP-AKA)认证之一。
28.如实施例26～28中任一实施例所述的方法，包括：使用第一参数来进行响应，其中该第一参数支持设备认证或是设备认证及托管方认证之一。
30.如实施例26～29中任一实施例所述的方法，包括：使用第二参数来进行响应，其中该第二参数支持基于证书的认证或EAP-AKA认证之一。
31.如实施例26～30中任一实施例所述的方法，包括：如果第一需求和第二需求匹配第一参数和第二参数，则使用第一需求和第二需求来执行认证。
32.如实施例26～31中任一实施例所述的方法，包括：根据使用H(e)NB身份检索的认证简档来接收对第一参数响应的接受。
33.如实施例26～32中任一实施例所述的方法，包括：根据使用H(e)NB身份检索的认证简档来接收对第一参数响应的拒绝。
34.如实施例26～33中任一实施例所述的方法，包括：使用支持托管方认证的另一个第一参数来做出响应。
35.如实施例26～34中任一实施例所述的方法，包括：向网络提供表明了至少可信环境(TrE)或H(e)NB的平台可信度或预期状态中的至少一项的信息。
36.如实施例26～35中任一实施例所述的方法，其中该信息是用在TrE内部得到保护的私钥来签名的。
37.如实施例26～36中任一实施例所述的方法，其中该信息被网络用于确定针对网络和应用的接入权限。
38.如实施例26～37中任一实施例所述的方法，包括：向网络提供关于平台有效性的TrE加密防护证据。
39.如实施例26～38中任一实施例所述的方法，包括：TrE检查第一和第二需求的完整性。
40.如实施例26～39中任一实施例所述的方法，包括：TrE向网络转发身份信息。
41.如实施例26～40中任一实施例所述的方法，包括：使用TrE和托管方模块(HPM)来执行托管方认证，其中该TrE保护HPM信息并且与HPM安全通信。
42.如实施例26～41中任一实施例所述的方法，包括：使用TrE或H(e)NB的至少一个标识值以及HPM的一个标识值来绑定TrE、H(e)NB和HPM。
43.如实施例26～42中任一实施例所述的方法，其中用于H(e)NB功能模块、TrE以及网络之间交互的协议包括下列各项中的至少一项：因特网密钥交换(IKEv2)、传输层安全性(TLS)、宽带论坛技术需求(TR)069、或开放移动联盟(OMA)设备管理(DM)。
44.一种用于结合网络来认证家用节点B/家用演进型节点B(H(e)NB)的方法，包括：在可信环境(TrE)中安全存储H(e)NB位置信息。
45.如实施例44所述的方法，包括：经由TrE来向网络安全发送所存储的H(e)NB位置信息。
46.如实施例44～45中任一实施例所述的方法，包括：在TrE中安全地存储H(e)NB的上一个已知良好位置。
47.如实施例44～46中任一实施例所述的方法，包括：使用TrE将所存储的“上一个已知良好地址”与新获取的位置信息进行比较。
48.如实施例44～47中任一实施例所述的方法，包括：TrE向网络上的位置服务器指示比较的结果。
49.如实施例44～48中任一实施例所述的方法，其中用于H(e)NB功能模块、TrE以及网络之间交互的协议包括下列各项中的至少一项：因特网密钥交换(IKEv2)、传输层安全性(TLS)、宽带论坛技术需求(TR)069、或开放移动联盟(OMA)设备管理(DM)。
虽然在特定组合的优选实施例中描述了本发明的特征和部件，但是这其中的每一个特征和部件都可以在没有优选实施例中的其他特征和部件的情况下单独使用，并且每一个特征和部件都可以在具有或不具有本发明的其他特征和部件的情况下以不同的组合方式来使用。本发明提供的方法或流程图可以在由通用计算机或处理器执行的计算机程序、软件或固件中实施，其中所述计算机程序、软件或固件以有形方式包含在计算机可读存储介质中，关于计算机可读存储介质的实例包括只读存储器(ROM)、随机存取存储器(RAM)、寄存器、缓冲存储器、半导体存储设备、诸如内部硬盘和可移动磁盘之类的磁介质、磁光介质以及CD-ROM碟片和数字多用途光盘(DVD)之类的光介质。
举例来说，适当的处理器包括：通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何一种集成电路(IC)和/或状态机。
与软件相关的处理器可用于实现射频收发信机，以便在无线发射接收单元(WTRU)、用户设备、终端、基站、无线电网络控制器或是任何一种主机计算机中加以使用。WTRU可以与采用硬件和/或软件形式实施的模块结合使用，例如相机、摄像机模块、视频电路、扬声器电话、振动设备、扬声器、麦克风、电视收发信机、免提耳机、键盘、Bluetooth
Figure BPA00001332073000481
模块、调频(FM)无线电单元、液晶显示器(LCD)显示单元、有机发光二极管(OLED)显示单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器和/或任何一种无线局域网(WLAN)或超宽带(UWB)模块。

Claims (35)

1.一种家用节点B/家用演进型节点B(H(e)NB)，该H(e)NB包括：
可信环境(TrE)；
H(e)NB功能模块；以及
介于所述TrE与所述H(e)NB功能模块之间的接口，该接口被配置成提供多个安全性等级；
其中所述TrE被配置成与所述H(e)NB功能模块进行交互，以便提供安全性和认证，
其中安全性和认证包括TrE或H(e)NB认证以及附条件的托管方认证中的至少一项。
2.根据权利要求1所述的H(e)NB，其中所述TrE包括：
用于确保密钥、秘密、敏感数据和程序中的至少一项的安全的存储区域；以及
安全运行环境，用于执行所述TrE或H(e)NB中的至少一者的基于认证密钥协议(AKA)和证书中的至少一者的认证。
3.根据权利要求1所述的H(e)NB，其中所述安全运行环境执行与向网络安全地指示至少所述TrE的有效性相关的安全性敏感操作。
4.根据权利要求1所述的H(e)NB，其中所述安全运行环境保护并验证所述H(e)NB的位置。
5.根据权利要求4所述的H(e)NB，其中在验证了位置的条件下提供网络授权。
6.根据权利要求1所述的H(e)NB，该H(e)NB还包括：
用于为托管方提供基于认证密钥协定(AKA)的认证的托管方模块(HPM)，其中所述HPM与所述TrE相连。
7.根据权利要求6所述的H(e)NB，其中所述HPM是用通用集成电路卡(UICC)实现的。
8.根据权利要求1所述的H(e)NB，其中所述TrE被配置成验证所述H(e)NB的设备完整性，并且向安全网关(SGW)传送与设备认证指示相结合的完整性指示。
9.根据权利要求1所述的H(e)NB，其中所述TrE被配置成支持多重认证。
10.根据权利要求1所述的H(e)NB，其中所述TrE被配置成支持相互认证。
11.根据权利要求1所述的H(e)NB，其中所述TrE被配置成根据H(e)NB、TrE以及附条件的托管平台的记录和标识来执行绑定认证。
12.根据权利要求1所述的H(e)NB，其中所述TrE被配置成执行位置锁定，其中位置锁定包括H(e)NB位置信息注册和/或H(e)NB位置信息认证。
13.根据权利要求12所述的H(e)NB，其中位置信息是以相邻宏小区为基础的。
14.根据权利要求12所述的H(e)NB，其中位置信息是以IP地址为基础的。
15.根据权利要求12所述的H(e)NB，其中位置信息是以IP地址和宏小区为基础的。
16.根据权利要求12所述的H(e)NB，其中位置信息是以全球定位系统为基础的。
17.根据权利要求1所述的H(e)NB，其中认证类型是用IKEv2协议的IKE_AUTH请求来指示的。
18.根据权利要求1所述的H(e)NB，其中IKE_AUTH请求中的预定参数表示下列之一：基于证书的H(e)NB或TrE认证、或基于可扩展认证协议-认证密钥协定(EAP-AKA)的H(e)NB或TrE认证。
19.根据权利要求1所述的H(e)NB，其中所述附条件的托管方认证是使用可扩展认证协议-认证密钥协定(EAP-AKA)来执行的。
20.根据权利要求1所述的H(e)NB，其中用于所述H(e)NB功能模块、所述TrE以及网络之间交互的协议包括下列各项中的至少一项：因特网密钥交换(IKEv2)、传输层安全性(TLS)、宽带论坛技术需求(TR)069、或开放移动联盟(OMA)设备管理(DM)。
21.一种结合网络来认证家用节点B/家用演进型节点B(H(e)NB)的方法，该方法包括：
启动对网络的安全接入；
接收第一需求，其中该需求表示下列之一：设备认证、或设备认证及托管方认证；
接收第二需求，其中该需求表示下列之一：基于证书的认证、或可扩展认证协议-认证密钥协定(EAP-AKA)认证；
使用第一参数来进行响应，其中该第一参数支持下列之一：设备认证、或设备认证及托管方认证；
使用第二参数来进行响应，其中该第二参数支持下列之一：基于证书的认证、或EAP-AKA认证；以及
在所述第一需求和所述第二需求与所述第一参数和所述第二参数相匹配的条件下，使用所述第一需求和所述第二需求来执行认证。
22.根据权利要求21所述的方法，该方法还包括：
根据使用H(e)NB身份检索的认证简档来接收对所述第一参数响应的接受。
23.根据权利要求21所述的方法，该方法还包括：
根据使用H(e)NB身份检索的认证简档来接收对所述第一参数响应的拒绝。
24.根据权利要求21所述的方法，该方法还包括：
使用支持托管方认证的另一个第一参数来做出响应。
25.根据权利要求21所述的方法，该方法还包括：
向所述网络提供表明了至少可信环境(TrE)或所述H(e)NB的平台可信度或预期状态中的至少一项的信息。
26.根据权利要求25所述的方法，其中所述信息是用在所述TrE内部得到保护的私钥来签名的。
27.根据权利要求25所述的方法，其中所述信息被所述网络用于确定针对该网络和应用的接入权限。
28.根据权利要求21所述的方法，该方法还包括：
向所述网络提供平台有效性的TrE加密防护证据。
29.根据权利要求21所述的方法，该方法还包括：
TrE检查所述第一需求和所述第二需求的完整性；以及
所述TrE向所述网络转发身份信息。
30.根据权利要求21所述的方法，该方法还包括：
使用所述TrE和托管方模块(HPM)来执行托管方认证，其中该TrE保护HPM信息并且与所述HPM安全地通信。
31.根据权利要求21所述的方法，该方法还包括：
使用所述TrE或H(e)NB的至少一个标识值以及所述HPM的一个标识值来绑定所述TrE、所述H(e)NB和所述HPM。
32.根据权利要求21所述的方法，其中用于H(e)NB功能模块、TrE以及网络之间交互的协议包括下列各项中的至少一项：因特网密钥交换(IKEv2)、传输层安全性(TLS)、宽带论坛技术需求(TR)069、或开放移动联盟(OMA)设备管理(DM)。
33.一种用于结合网络来认证家用节点B/家用演进型节点B(H(e)NB)的方法，该方法包括：
在可信环境(TrE)中安全地存储H(e)NB位置信息；以及
经由所述TrE来向所述网络安全地发送所存储的H(e)NB位置信息。
34.根据权利要求33所述的方法，该方法还包括：
在所述TrE中安全地存储所述H(e)NB的上一个已知良好位置；
使用所述TrE将所存储的“上一个已知良好地址”与新获取的位置信息进行比较；以及
所述TrE向所述网络上的位置服务器指示所述比较的结果。
35.根据权利要求33所述的方法，其中用于所述H(e)NB、所述TrE以及所述网络之间交互的协议包括下列各项中的至少一项：因特网密钥交换(IKEv2)、传输层安全性(TLS)、宽带论坛技术需求(TR)069、或开放移动联盟(OMA)设备管理(DM)。
CN200980137585.9A 2008-09-24 2009-09-21 家用节点b设备以及安全协议 Expired - Fee Related CN102204305B (zh)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US9982808P 2008-09-24 2008-09-24
US61/099,828 2008-09-24
US10605008P 2008-10-16 2008-10-16
US61/106,050 2008-10-16
US11009208P 2008-10-31 2008-10-31
US11025508P 2008-10-31 2008-10-31
US61/110,255 2008-10-31
US61/110,092 2008-10-31
PCT/US2009/057683 WO2010036611A1 (en) 2008-09-24 2009-09-21 Home node-b apparatus and security protocols

Publications (2)

Publication Number Publication Date
CN102204305A true CN102204305A (zh) 2011-09-28
CN102204305B CN102204305B (zh) 2014-07-16

Family

ID=41479624

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200980137585.9A Expired - Fee Related CN102204305B (zh) 2008-09-24 2009-09-21 家用节点b设备以及安全协议

Country Status (9)

Country Link
US (2) US8307205B2 (zh)
EP (2) EP3193524A1 (zh)
JP (1) JP5390619B2 (zh)
KR (2) KR101287309B1 (zh)
CN (1) CN102204305B (zh)
AR (1) AR073672A1 (zh)
CA (1) CA2738372A1 (zh)
TW (2) TWI466553B (zh)
WO (1) WO2010036611A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109729523A (zh) * 2017-10-31 2019-05-07 华为技术有限公司 一种终端联网认证的方法和装置
CN109901533A (zh) * 2014-08-11 2019-06-18 费希尔-罗斯蒙特系统公司 用于在过程控制系统中使用的方法和设备
CN111090865A (zh) * 2019-12-17 2020-05-01 支付宝(杭州)信息技术有限公司 一种密钥授权方法和系统
US11385608B2 (en) 2013-03-04 2022-07-12 Fisher-Rosemount Systems, Inc. Big data in process control systems
US11886155B2 (en) 2015-10-09 2024-01-30 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009045972A1 (en) 2007-09-30 2009-04-09 Wms Gaming, Inc. Distributing information in a wagering game system
US8307205B2 (en) 2008-09-24 2012-11-06 Interdigital Patent Holdings, Inc. Home node-B apparatus and security protocols
CN101772020B (zh) * 2009-01-05 2011-12-28 华为技术有限公司 鉴权处理方法和系统、3gpp认证授权计费服务器及用户设备
US8693642B2 (en) * 2009-04-16 2014-04-08 Alcatel Lucent Emergency call handling in accordance with authentication procedure in communication network
US20110030035A1 (en) * 2009-07-31 2011-02-03 Chih-Hsiang Wu Method of managing authorization of private node b in a wireless communication system and related device
WO2011023223A1 (en) * 2009-08-25 2011-03-03 Nokia Siemens Networks Oy Method of performing an authentication in a communications network
CN102026149B (zh) * 2009-09-14 2015-08-12 中兴通讯股份有限公司 一种m2m设备归属网络运营商变更的方法和系统
US8953529B2 (en) * 2009-12-01 2015-02-10 Spidercloud Wireless, Inc. Method, system and device for high speed uplink packet access scheduling
CN102143489A (zh) * 2010-02-01 2011-08-03 华为技术有限公司 中继节点的认证方法、装置及系统
SG184853A1 (en) 2010-04-12 2012-11-29 Interdigital Patent Holdings Staged control release in boot process
CN101827344B (zh) * 2010-04-19 2016-02-24 中兴通讯股份有限公司 一种紧急呼叫的处理方法和装置
US8690682B1 (en) * 2010-05-26 2014-04-08 Wms Gaming, Inc. Browser based wagering game systems and configuration
US9385862B2 (en) 2010-06-16 2016-07-05 Qualcomm Incorporated Method and apparatus for binding subscriber authentication and device authentication in communication systems
US8839373B2 (en) * 2010-06-18 2014-09-16 Qualcomm Incorporated Method and apparatus for relay node management and authorization
US8516551B2 (en) * 2010-07-28 2013-08-20 Intel Corporation Providing a multi-phase lockstep integrity reporting mechanism
WO2012019167A1 (en) 2010-08-06 2012-02-09 Wms Gaming, Inc. Browser based heterogenous technology ecosystem
US9345973B1 (en) 2010-08-06 2016-05-24 Bally Gaming, Inc. Controlling wagering game system browser areas
US20130139242A1 (en) * 2010-08-20 2013-05-30 Zte Corporation Network Accessing Device and Method for Mutual Authentication Therebetween
US8839397B2 (en) * 2010-08-24 2014-09-16 Verizon Patent And Licensing Inc. End point context and trust level determination
US8898759B2 (en) 2010-08-24 2014-11-25 Verizon Patent And Licensing Inc. Application registration, authorization, and verification
CN102045355B (zh) * 2010-12-20 2013-01-16 西安西电捷通无线网络通信股份有限公司 一种适合tcg可信网络连接架构的平台鉴别实现方法
MX2013008150A (es) * 2011-01-14 2013-09-13 Nokia Siemens Networks Oy Soporte de autenticacion externo sobre una red no confiable.
JP2012168865A (ja) * 2011-02-16 2012-09-06 Toshiba Corp メモリシステム
CN102801545B (zh) * 2011-05-25 2015-12-09 华为技术有限公司 配置信息的获取方法和设备
TWI428031B (zh) * 2011-10-06 2014-02-21 Ind Tech Res Inst 區域網協存取網路元件與終端設備的認證方法與裝置
US20130121322A1 (en) * 2011-11-10 2013-05-16 Motorola Mobility, Inc. Method for establishing data connectivity between a wireless communication device and a core network over an ip access network, wireless communication device and communicatin system
US9930187B2 (en) 2013-01-31 2018-03-27 Nokia Technologies Oy Billing related information reporting
CN105706390B (zh) * 2013-10-30 2020-03-03 三星电子株式会社 在无线通信网络中执行设备到设备通信的方法和装置
US9179436B1 (en) 2014-08-22 2015-11-03 Cisco Technology, Inc. System and method for location reporting in an untrusted network environment
US9825937B2 (en) 2014-09-23 2017-11-21 Qualcomm Incorporated Certificate-based authentication
US9843928B2 (en) 2014-10-30 2017-12-12 Motorola Solutions, Inc. Method and apparatus for connecting a communication device to a deployable network without compromising authentication keys
US20160364553A1 (en) * 2015-06-09 2016-12-15 Intel Corporation System, Apparatus And Method For Providing Protected Content In An Internet Of Things (IOT) Network
CN108029012B (zh) * 2015-09-11 2020-06-16 华为技术有限公司 配置文件处理方法、配置文件处理装置、用户终端及eUICC
US10588019B2 (en) * 2016-05-05 2020-03-10 Qualcomm Incorporated Secure signaling before performing an authentication and key agreement
US10212590B2 (en) * 2016-08-16 2019-02-19 Lg Electronics Inc. Method and apparatus for authenticating device in wireless communication system
KR102424358B1 (ko) * 2017-11-30 2022-07-22 삼성전자주식회사 통신 서비스를 제공하는 방법 및 전자 장치
CN110049578B (zh) * 2018-01-17 2021-08-03 华为技术有限公司 无线连接修改方法、设备及系统
US11068600B2 (en) * 2018-05-21 2021-07-20 Kct Holdings, Llc Apparatus and method for secure router with layered encryption

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060018470A1 (en) * 2004-07-09 2006-01-26 Nokia Corporation Managing traffic keys during a multi-media session
WO2006047425A2 (en) * 2004-10-25 2006-05-04 Intrado, Inc. System and method for unilateral verification of caller location information
US20060112267A1 (en) * 2004-11-23 2006-05-25 Zimmer Vincent J Trusted platform storage controller
US20070042754A1 (en) 2005-07-29 2007-02-22 Bajikar Sundeep M Security parameter provisioning in an open platform using 3G security infrastructure
US8468361B2 (en) * 2005-09-21 2013-06-18 Broadcom Corporation System and method for securely provisioning and generating one-time-passwords in a remote device
US8139521B2 (en) 2005-10-28 2012-03-20 Interdigital Technology Corporation Wireless nodes with active authentication and associated methods
BRPI0621127A2 (pt) * 2005-12-22 2011-11-29 Interdigital Tech Corp método e aparelhos para segurança de dados e implementação de requerimento de repetição automática em sistema de comunicação sem fio
CN101444063B (zh) 2006-05-09 2013-02-06 交互数字技术公司 用于无线设备的安全时间功能
EP2177010B1 (en) 2006-12-13 2015-10-28 Quickplay Media Inc. Mobile media platform
TWI493952B (zh) * 2006-12-27 2015-07-21 Signal Trust For Wireless Innovation 基地台自行配置方法及裝置
EP2127300B1 (en) 2007-01-26 2018-04-18 InterDigital Technology Corporation Method and apparatus for securing location information and access control using the location information
US8072953B2 (en) * 2007-04-24 2011-12-06 Interdigital Technology Corporation Wireless communication method and apparatus for performing home Node-B identification and access restriction
EP2760238B1 (en) 2007-04-30 2016-07-27 InterDigital Technology Corporation A home (e)node-b with new functionality
CN101400153B (zh) 2007-09-27 2013-01-16 北京三星通信技术研究有限公司 用户设备通过hnb接入系统直接通信的方法
CN101136826B (zh) * 2007-09-30 2011-01-05 中兴通讯股份有限公司 一种通过核心网控制终端接入家庭基站覆盖区域的方法
CN101500233A (zh) * 2008-01-31 2009-08-05 华为技术有限公司 寻呼方法、家用基站、家用基站网关和通信系统
US9913206B2 (en) * 2008-03-21 2018-03-06 Interdigital Patent Holdings, Inc. Method and apparatus for searching for closed subscriber group cells
US20090262704A1 (en) * 2008-04-18 2009-10-22 Amit Khetawat Method and Apparatus for Establishment of Asynchronous Transfer Mode Based Bearer Connection between a Network Controller and Core Network
US8307205B2 (en) 2008-09-24 2012-11-06 Interdigital Patent Holdings, Inc. Home node-B apparatus and security protocols

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11385608B2 (en) 2013-03-04 2022-07-12 Fisher-Rosemount Systems, Inc. Big data in process control systems
CN109901533A (zh) * 2014-08-11 2019-06-18 费希尔-罗斯蒙特系统公司 用于在过程控制系统中使用的方法和设备
CN109901533B (zh) * 2014-08-11 2022-04-01 费希尔-罗斯蒙特系统公司 用于在过程控制系统中使用的方法和设备
US11886155B2 (en) 2015-10-09 2024-01-30 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
CN109729523A (zh) * 2017-10-31 2019-05-07 华为技术有限公司 一种终端联网认证的方法和装置
CN109729523B (zh) * 2017-10-31 2021-02-23 华为技术有限公司 一种终端联网认证的方法和装置
US11432150B2 (en) 2017-10-31 2022-08-30 Huawei Technologies Co., Ltd. Method and apparatus for authenticating network access of terminal
CN111090865A (zh) * 2019-12-17 2020-05-01 支付宝(杭州)信息技术有限公司 一种密钥授权方法和系统

Also Published As

Publication number Publication date
KR20110058908A (ko) 2011-06-01
US8826020B2 (en) 2014-09-02
EP2351396B1 (en) 2017-03-01
CN102204305B (zh) 2014-07-16
KR101508576B1 (ko) 2015-04-08
CA2738372A1 (en) 2010-04-01
JP2012503945A (ja) 2012-02-09
EP2351396A1 (en) 2011-08-03
US8307205B2 (en) 2012-11-06
WO2010036611A1 (en) 2010-04-01
TW201018265A (en) 2010-05-01
US20130046980A1 (en) 2013-02-21
KR101287309B1 (ko) 2013-07-23
US20100125732A1 (en) 2010-05-20
KR20110084334A (ko) 2011-07-21
JP5390619B2 (ja) 2014-01-15
TWI466553B (zh) 2014-12-21
AR073672A1 (es) 2010-11-24
EP3193524A1 (en) 2017-07-19
TW201313040A (zh) 2013-03-16

Similar Documents

Publication Publication Date Title
CN102204305B (zh) 家用节点b设备以及安全协议
CN102844764B (zh) 启动过程中的阶段性控制释放
US9392453B2 (en) Authentication
RU2464729C2 (ru) Способ аутентификации мобильных устройств, подключенных к фемтосоте, действующей согласно многостанционному доступу с кодовым разделением каналов
EP2208330B1 (en) Method and apparatuses for determining whether femtocell is authorized to provide wireless connectivity to a mobile unit
CN103716797A (zh) 执行wtru的确认的方法以及设备
US20060094401A1 (en) Method and apparatus for authentication of mobile devices
CN108880813B (zh) 一种附着流程的实现方法及装置
CN101822082A (zh) 用于uicc和终端之间安全信道化的技术
CN103210627A (zh) 证书认证和信道绑定
Han et al. An efficient handover authentication mechanism for 5G wireless network
Zheng et al. Trusted computing-based security architecture for 4G mobile networks
Rajavelsamy et al. Towards security architecture for home (evolved) nodeb: challenges, requirements and solutions
Kahya et al. Formal analysis of PKM using scyther tool
van den Broek et al. Femtocell security in theory and practice
Bodhe et al. Wireless LAN security attacks and CCM protocol with some best practices in deployment of services
Lei et al. 5G security system design for all ages
Prakash et al. EPMOS based secure mobile communication in LTE/SAE networks
Chen et al. RDAP: Rapid deployment authentication protocol between mobile devices and femtocells
Evans Secure 3G user authentication in ad-hoc serving networks
Ntantogian et al. Security Architectures for B3G Mobile Networks

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1161498

Country of ref document: HK

C14 Grant of patent or utility model
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1161498

Country of ref document: HK

CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20140716

Termination date: 20170921

CF01 Termination of patent right due to non-payment of annual fee