用于通用引导架构(GBA)的多-X密钥成链

技术领域

本申请一般地涉及数据安全、数据加密、以及数据隐私领域，更具体地，涉及在多设备、多角色、多用户和/或多域(统称为“多-x”)环境中提供端到端安全、加密、身份管理、以及密钥管理的装置、方法、以及计算机可读介质。

背景技术

信息物理系统(cyber-physical system)(CPS)通常用于指由基于计算机的算法控制和/或监视并与互联网及其用户紧密集成的物理系统。在CPS中，物理组件和软件组件可以深度交织在一起，每个组件都在不同的时空尺度上运行、表现出多种不同的行为方式、并且以能够随上下文而变化的各种方式相互交互。CPS的示例包括云计算系统(CCS)、智能电网系统、医疗监视、自主车辆系统、过程控制系统、机器人技术、以及自动驾驶航空电子设备。

机器对机器(M2M)通信(也称为机器型通信(MTC))代表了3GPP生态系统的巨大增长机会。为了支持这种所谓的“物联网”(IoT)，3GPP运营商必须解决以下设备的使用场景：这些设备是高能效的(例如，数年的电池寿命)，在具有挑战性的覆盖条件下(例如室内和室外)可达，并且具有成本效益，使得这些设备可以被大规模部署甚至是一次性使用。对3GPPIoT生态系统的另一个要求是支持大量MTC或M2M设备，每个设备都生成少量数据。在网络中的小区级别，在具有根据3GPP TR 36.888附件A中的假设的每小区住户(household)密度的情况下，预期一个小区中的每个住户最多可以拥有40个MTC设备。

第五代(5G)移动网络的部署即将到来，并且预期IoT构成该5G无线系统的主要部分。预期IoT通过提供网络和数据存储框架需要处理的大量数据来极大地改变各个行业。根据最近的一项调查[1]，IoT将在2020年之前生成约600ZB数据，比2016年生成的数据增长约275％。在这种数据丰富的环境中将变得日益重要的是：确保服务提供商遵守数据隐私法规并防止黑客控制设备、损坏信息、破坏服务或甚至关闭整个关键设备网络。然而，对于这种数据量或数据规模的数据加密和访问控制的要求极具挑战性。

除了大规模的所连接的最终终端和它们预期生成的数据外，多-X设备的新技术使身份和访问管理更加复杂，同时带来了新的安全和隐私挑战。如本文所使用的，“多-X”指对多角色、多用户、多设备和/或多域中的一个或多个的支持。图1示出了示例性多设备场景，其中，用户在单个订阅简档(profile)和/或电话号码下维护多个设备。每个设备利用SIM(订户标识模块)、非SIM或eSIM，它们包含从中导出订户的网络身份的信息并且必须被物理地装载到使用中的特定设备上。如图1所示，一种示例性单订户多设备场景涉及智能电话、智能手表、以及联网汽车，它们都在对网络服务提供商(例如，蜂窝运营商)的单个订阅下工作。

图2示出了示例性多用户场景，其中，单个订阅在多个个体之间被共享(例如家庭计划)，或者单个连接的设备(例如汽车)由多个用户所共享，每个用户具有不同的订阅。在后一种情况下，每个用户具有不同的身份，这要求设备具有在用户简档之间进行适配和切换的能力。

图3示出了示例性多角色场景，其中，单个设备可以承担彼此安全地分离的多个“角色”(也称为“虚拟环境”或“虚拟设备”)。例如，特定设备可以承担单个订户的多个角色(例如，个人角色和业务角色)，同时从网络访问角度来看保持单个订户身份。作为另一个示例，特定设备可以承担与不同订户相关联的角色。图4示出了示例性多域场景，其中，来自不同域的用户可以在不同的订阅身份下共享单个设备。像上面提到的其他示例性场景一样，个体用户的数据的安全至关重要。

这些多-x场景会给身份和访问管理增加显著的复杂性。而且，由这些设备生成的大量数据需要用于管理加密和解密(例如，密钥)以避免瓶颈的有效解决方案。例如，单密钥加密和解密会比没有任何层次或身份逻辑的多个基于时间的密钥(每个密钥在几秒钟的间隔内被应用于少量数据分组)更有效。

还需要用于数据访问控制的进一步新机制，以避免对关键数据的不可信访问或控制。换句话说，在这种环境下，个人数据的保护变得更加重要，特别是考虑到各种法律、法规和各个机构在全球范围内颁布的要求。欧盟(EU)已制定并计划在2018年5月25日实施和执行新的《通用数据保护条例(GDPR)》。GDPR有望保护欧盟内部和外部的个人数据的出口。美国联邦贸易委员会(FTC)也正在调查类似的法规。此外，瑞典个人数据法(Personuppgiftslagen或PuL)定义了类似的法规。通常，所有这些法规都提出了附加要求，使得服务提供商不能收集不需要的个人信息，并且数据收集、存储和处理必须是安全的。用户负责标识哪些数据可以被收集，而服务提供商有权仅在有限的时间段内保留信息。5G和IoT的成功与未来发展将很可能取决于服务提供商采用和遵守这些法规的能力。

当前，公钥基础设施(PKI)通常被用于管理加密密钥。PKI包括角色、策略和过程，以便创建、管理、分发、使用、存储和调用数字证书以及管理公钥加密。一个主要缺点是，PKI需要大型基础设施(例如，认证机构、注册机构、储存库、归档和最终实体)来管理和维护所使用的证书。另外，PKI通常是不可伸缩的(例如，由于其集中配置)，并且不包括用户许可的条款，这使得其更容易妥协。

在类似的上下文中，通用引导架构(GBA)是一种用于用户认证的技术。如3GPP所标准化的，GBA对最终设备进行认证，以将用户的应用连接到网络。GBA使用认证密钥协商协议(AKA)而不是PKI。借助GBA，在引导服务器功能(BSF)与设备之间不共享密钥，而仅共享某些参数来导出密钥。但是，当前的GBA架构有几个缺点。首先，它仅提供端到端(E2E)安全连接。此外，密钥数据库被加密，而不是数据本身被加密。同样，GBA要求用户参与决定应被加密的内容、维护密钥并共享密钥以进行解密。除了上面讨论的一般约束之外，GBA还具有特定于多-x场景和/或应用的多种缺点。

发明内容

本公开的示例性实施例通过经由灵活、可伸缩的单密钥加密/解密管理解决方案在整个网络中提供机密安全的端到端通信来解决这些和其他挑战。示例性实施例能够满足新施行的隐私法规，使用户、运营商和应用/服务提供商能够利用IoT和多-X的全部能力，同时为身份和访问管理提供新的访问控制解决方案。

更具体地，本公开的示例性实施例通过扩展通用引导架构(GBA)为具有身份和密钥管理的多-X提供端到端安全和密钥成链加密。通过提供灵活且可伸缩的单密钥加密/解密管理解决方案，示例性实施例能够满足IoT和多-X场景的大量加密要求，同时提供新的访问控制解决方案，以鉴于新隐私法规来安全地处理所生成和传送的数据。

特定示例性实施例包括由订户设备执行的用于促进移动通信网络的订户与一个或多个服务提供商SP之间的安全通信的方法和/或过程，其中，所述订户与包括设备和简档的任何组合的多个实体相关联。示例性方法和/或过程可以包括：获得与所述订户相关联的安全标识符ID。示例性方法和/或过程还可以包括：基于所述安全ID，建立包括与所述订户相关联的所述多个实体的身份层次。示例性方法和/或过程还可以包括：基于所述安全ID，建立用于一个或多个SP访问由在所述身份层次中包括的所述实体生成的数据的许可。示例性方法和/或过程还可包括：响应于包括所述安全ID的请求，接收能够用于加密数据以发送到特定SP的公钥PK，其中，所述数据是使用与所建立的用于所述特定SP的许可相关联的对应的私钥SK可解密的。示例性方法和/或过程还可以包括：使用所述PK和所述身份层次对所述数据进行加密。

其他示例性实施例包括由服务器执行的用于促进移动通信网络的订户与一个或多个服务提供商SP之间的安全通信的方法和/或过程，其中，所述订户与包括设备和简档的任何组合的多个实体相关联。示例性方法和/或过程可以包括：与订户设备执行认证密钥协商AKA。示例性方法和/或过程还可以包括：导出并存储引导标识符BTID和与所述BTID相关联的多个密钥。示例性方法和/或过程还可以包括：将所述BTID发送到所述订户设备。示例性方法和/或过程还可以包括：接收对所述多个密钥中的第一密钥的第一请求，其中，所述第一请求包括所关联的BTID。示例性方法和/或过程还可以包括：基于确定所关联的BTID与所存储的BTID相匹配，响应于所述第一请求而发送所述第一密钥。

其他示例性实施例包括由服务器执行的用于促进移动通信网络的订户与一个或多个服务提供商SP之间的安全通信的方法和/或过程，其中，所述订户与包括设备和简档的任何组合的多个实体相关联。示例性方法和/或过程可以包括：从订户设备接收包括与所述订户相关联的安全标识符ID的请求。示例性方法和/或过程还可以包括：基于所述安全ID，建立包括与所述订户相关联的所述多个实体的身份层次。示例性方法和/或过程还可以包括：生成与所述订户相关联的公钥PK。示例性方法和/或过程还可以包括：生成与所述身份层次相对应的私钥SK层次。示例性方法和/或过程还可以包括：向在所述身份层次中包括的特定设备或简档提供所述PK。

其他示例性实施例包括由服务器执行的用于促进移动通信网络的订户与一个或多个服务提供商SP之间的安全通信的方法和/或过程，其中，所述订户与包括设备和简档的任何组合的多个实体相关联。示例性方法和/或过程可以包括：从订户设备接收包括与所述订户相关联的安全标识符ID的请求。示例性方法和/或过程还可以包括：基于与所述安全ID相关联的订户信息来认证所述订户。示例性方法和/或过程还可以包括：向所述订户设备发送与所述订户相关联的包括设备和简档的任何组合的实体列表。示例性方法和/或过程还可以包括：从所述订户设备接收用于一个或多个服务提供商SP访问由在所述列表中包括的所述实体生成的数据的许可。示例性方法和/或过程还可以包括：将所接收的许可映射到包括与所述订户相关联的所述实体的身份层次中。

其他示例性实施例包括订户设备(例如，用户设备或UE)和服务器装置，所述服务器装置包括通信收发机、处理器、以及存储计算机可执行指令的存储器，所述计算机可执行指令在由所述处理器执行时将所述订户设备或所述服务器装置配置为执行与本文公开的任何示例性方法和/或过程相对应的操作。

其他示例性实施例包括存储程序指令的非暂时性计算机可读介质，所述程序指令在由订户设备或服务器装置执行时将所述订户设备或所述服务器装置配置为执行与本文公开的任何示例性方法和/或过程相对应的操作。

当然，本公开的实施例不限于以上特征和优点。实际上，本领域技术人员在阅读以下详细描述并在查看附图后将认识到附加特征和优点。

附图说明

以下附图示出了本文公开的实施例的各种示例性方面：

图1示出了示例性多设备场景，其中，用户在单个订阅简档和/或电话号码下维护多个设备；

图2示出了示例性多用户场景，其中，单个订阅在多个个体之间被共享(例如，家庭计划)或者单个连接的设备(例如，汽车)被多个用户所共享；

图3示出了示例性多角色场景，其中，单个个体的多个“角色”均可以与单个设备上的不同简档相关联；

图4示出了示例性多域场景，其中，来自不同域的用户可以在不同的订阅身份下共享单个设备；

图5示出了根据本公开的示例性实施例的在多-x环境中利用GBA架构和基于分层ID的加密的系统的高层图；

图6进一步示出了根据本公开的各种示例性实施例的多个设备可如何被与单个订户或用户相关联；

图7进一步示出了根据本公开的各种示例性实施例的多个角色可如何被与单个订户/用户和单个设备相关联；

图8进一步示出了根据本公开的各种示例性实施例的多个订户或用户可如何被与单个设备相关联；

图9进一步示出了根据本公开的各种示例性实施例的来自不同域的多个订户或用户可如何被与单个设备相关联；

图10示出了根据本公开的一个或多个示例性实施例的示例性多-X密钥成链(MX-KC)架构的图；

图11示出了根据本公开的一个或多个示例性实施例的用于订户初始化的示例性信号流程图；

图12示出了根据本公开的一个或多个示例性实施例的用于密钥成链(KC)初始化的示例性信号流程图；

图13示出了根据本公开的各种示例性实施例的用于上下文感知服务(CAS)初始化的示例性信号流程图；

图14示出了根据本公开的各种示例性实施例的用于上下文感知服务(CAS)更新的示例性信号流程图；

图15示出了根据本公开的各种示例性实施例的用于密钥成链(KC)更新的示例性信号流程图；

图16示出了根据本公开的各种示例性实施例的用于设备初始化的示例性信号流程图；

图17A-C示出了根据本公开的各种示例性实施例的用于部署MX-CAS和MX-KC的三种不同的选项和/或架构的高层图；

图18-21是示出了根据本公开的各种示例性实施例的用于促进移动通信网络的订户与一个或多个服务提供商(SP)之间的安全通信的各种示例性方法和/或过程的流程图，其中，该订户与包括设备和简档的任何组合的多个实体相关联；

图22是示出了可配置为执行本文公开的一个或多个示例性方法和/或过程的订户设备的高层框图；

图23是示出被配置为执行本文公开的一个或多个示例性方法和/或过程的服务器装置的高层框图；

图24示出了根据本公开的各种示例性实施例的可以在示例性通信设备中实现的示例性功能模块或电路架构；以及

图25示出了根据本公开的各种示例性实施例的可以在示例性服务器设备中实现的示例性功能模块或电路架构。

虽然现在将参考附图详细描述本公开，但是本公开是结合说明性实施例来完成的，并且不受附图或所附示例性实施例中所示的特定实施例的限制。

具体实施方式

除了以上讨论的一般约束之外，GBA具有对于多-X场景和/或应用而言特定的各种缺点。例如，GBA需要为多-X生成多个密钥，没有用于子密钥生成的层次，以及仅为特定时间段指派密钥。这种具有多个密钥的大规模加密又会造成可伸缩性瓶颈和低效，以及非常复杂的数据访问控制和信任数据管理。此外，GBA没有提供为每个服务提供商生成特定密钥或解密由不同密钥加密的海量数据的机制。

尽管如此，已经在GBA之上进行了许多工作，重点是协议的基础设施和效率。Sethi等人[7]在他们的提议中描述了如何采用GBA来确保在资源受限设备之间的安全认证和通信，而Ring等人[8]则提出了基于ID的认证。已经提出了一种基于GBA的方法，该方法采用了结合在BSF中的基于令牌的认证来通过移动网络传输电子病历[9]。这种方法允许进行认证，防止令牌伪装，并在与可信服务提供商合作时提供机密性和对中间人(man-in-the-middle)攻击的抵抗力。

类似地，已经提出使用联合身份反向引导机制来动态生成证书，以用于跨异构网络[10]的安全和无缝访问。此方法使用了应用层引导机制来无缝地并自动地促进网络访问层凭据生成。此后，该凭据被用于单程(one-round-trip)EAP认证，从而实现在新网络上进行认证。实验证明了在认证过程、密钥材料(keying material)、部署成本和其他标准方面的工作效率。

其他工作讨论了现有的认证解决方案及其局限性(例如，ISIM认证、GBA、以及使用SMS验证的SIM强认证)，以及基于不同场景(例如SATSA和EAP-SIM、蓝牙、以及SIM软件狗)的SIM认证[11]。此外，已经确定了与电子医疗领域的隐私和成本敏感应用有关的各种问题[12]。例如，在3GPP GBA框架中，始终假设移动运营商是受信任的，但是由于电子医疗领域的安全风险，受信任的BSF应被排除。GBA的替代解决方案通过使用AKA方案并通过构建SMS安全性和USIM应用工具包(SAT)的双重功能来满足电子医疗要求。更具体地说，在USIM和电子医疗服务器中生成另一组密钥。

这些工作都没有解决多身份、多角色、多域、以及访问控制。此外，它们均没有满足即将到来的地区和全球法规，例如GDPR、FTC和PDA。这些法规将对日益复杂的5G和IOT演进技术(其中，个人数据的安全和保护已成为主要设计要求之一)产生重大影响。在安全性的上下文中，在IoT领域已经提出并采用了许多基于加密的访问控制方案。

例如，已经提出了PKI来解决IoT网关的安全问题，IoT网关通过数字证书和PKI数据加密来聚合健康传感器数据[13]。PKI模型使用一对数学上相关的密钥。如果一个密钥被用于加密信息，则只有相关的密钥才能解密该信息。在公钥遭到损坏的情况下，取得私钥仍然在计算上不可行。但是，它依赖于受信机构以便执行加密和解密活动。

已经提出了另一种基于加密的访问控制方案，其被称为基于分层身份的加密(HIBE)([14]-[15])。HIBE具有抗冲突性，并且可以防止选择的密文攻击。加密与解密的消息和复杂性随着层次中级别的数量线性增长。该方案是Boneh-Franklin基于身份的加密(IBE)方案的扩展。通常，IBE是公钥系统，其中，公钥可以是任意字符串，例如电子邮件地址。中央机构使用主密钥将私钥发布给请求私钥的身份。HIBE是对镜像了组织层次的IBE的概括。层次树的级别k处的身份可以向其后代身份发布私钥，但不能解密旨在用于其他身份的消息。

换句话说，HIBE利用根密钥来生成其中结合了ID的低级密钥。消息被用ID元组加密。各种工作([16]-[17])提出了恒定大小的密文，从而降低了解密复杂性，实现了无历史记录的更新，针对内部人员的安全性，以及对解密密钥暴露的抵抗力。HIBE包括七种不同的算法：建立，密钥生成，密钥更新，密钥导出，加密，解密，以及密钥调用。其他各种工作([18]-[21])探讨了HIBE的各个方面，但都没有考虑到多-x用例(包括汽车用例)的特定要求。

基于属性的加密是另一种类型的公钥加密，其中，用户的私钥和密文取决于用户属性(例如，他们居住的国家或他们拥有的订阅的类型)。在这样的系统中，仅当用户密钥的属性集与密文的属性相匹配时，才可以对密文进行解密。ABE已被用于加密数据的细粒度访问控制[22]。尽管如此，由于其公钥性质，ABE依赖于受信机构来执行加密和解密活动。

在大量数据以及对安全数据收集、存储和处理施加的法规的上下文中，以上讨论的先前解决方案均不适合满足多-x用例的所有要求。在这种环境下，满足安全性、认证和授权要求变得极具挑战性。然而，本公开的示例性实施例通过经由灵活、可伸缩的单密钥加密/解密管理解决方案在整个网络中提供安全的端到端通信来应对这些挑战。示例性实施例能够满足新施行的隐私法规，使用户、运营商和应用提供商能够利用IoT和多-X的全部能力，同时为身份和访问管理提供新的访问控制解决方案。

更具体地，本公开的示例性实施例通过扩展通用引导架构(GBA)为具有身份和密钥管理的多-X提供端到端安全和密钥成链加密。通过提供灵活且可伸缩的单密钥加密/解密管理解决方案，示例性实施例能够满足IoT和多-X场景的大量加密要求，同时提供新的访问控制解决方案，以鉴于新隐私法规来安全地处理所生成和传送的数据。

甚至更具体地，示例性实施例使用来自移动网络运营商(MNO)的信息，基于订户/用户来提供设备的分层分类。使用基于时间的身份进一步扩展设备ID，从而促进更好的访问控制。示例性实施例使用来自GBA的密钥来生成加密参数，以及用于加密和解密的单个密钥。单密钥加密/解密允许访问控制和授权，并且许可是由订户针对数据提供的。

图5示出了根据本公开的示例性实施例的在多-X环境中利用GBA架构和基于分层ID的加密的系统的高级图。在顶层(概念上)是三个订户/用户，被标记为订户A(称为“订户A”)、用户B和用户C。如图所示，订户A和用户B是域1的一部分，而用户C是域2的一部分。在下一级是被标记为IMP1-5的各种示例性设备。例如，IMP1和IMPI2表示与单个订户(订户A)相关联的两个设备。IMPI1可以表示智能手机，IMPI2可以表示智能手表和/或个人健身追踪器。类似地，IMPI3可以表示由多个用户共享的汽车(例如小汽车)。下一级是特定设备上的各种简档，每个简档与特定的顶级订户、用户或用户“角色”相关联。在每个简档下方是与该简档相关联的设备应用，在每个应用下方是由应用生成的数据的时间序列，分别为实例1、2、...、N。

图6进一步示出了根据本公开的各种示例性实施例的多个设备可如何被与单个订户或用户相关联。如图所示，设备利用订户位于根处的分层ID。例如，简档A-1(例如，智能手机设备上订户A的简档)的心脏监视器应用可被标识为“订户A/A-1/A-1-1”。该分层ID允许个体设备(或特定的设备简档)被唯一地标识，从而使订户能够严格地定制数据可以被与应用/服务提供商(SP)共享的许可。

图7进一步示出了根据本公开的各种示例性实施例的多个角色可如何被与单个订户/用户和单个设备相关联。如图所示，订户A在智能手机设备IMPI1上使用两个简档或角色。这两个简档(标记为ID A-1和ID A-2)可以分别用于个人用途和业务用途。订户A的每个应用将具有与IMPI1上订户A的每个简档相关联的唯一ID。例如，简档A-2的心脏监视器应用的ID将为“订户A/A-2/A-2-1”，而对于简档A-1，同一应用的唯一ID为“订户A/A/A-1/A-1-1”。

在一些示例性实施例中，分层ID布置可以被进一步扩展以促进对特定时域数据的唯一标识，从而为订户/用户提供对各个数据段提供许可的能力。例如，订户A的心脏监视器(即，简档A-1)在时间T1产生的数据可以由分层ID“订户A/A-1/A-1-1-T1”来标识。同样，在时间1和时间2产生的数据可被标识为“订户A/A-1/A-1-1-T1/A-1-1-T2”，依此类推。

图8进一步示出了根据本公开的各种示例性实施例的多个订户或用户可如何被与单个设备相关联。当多个用户共享一个设备时，该设备将采用与使用该设备的订户相关联的简档。换句话说，物理设备将提供多个“虚拟设备”，每个虚拟设备与访问或使用它的订户/用户/角色的简档相关联。例如，如图所示，对于访问汽车的每个订户/用户/角色，该汽车被分成“虚拟汽车”，即，订户A的简档A-3和用户B的简档B-2。在这种情况下，与订户A相关联的汽车速度计的分层ID将为“订户A/A-3/A-3-1”，而同一物理速度计(当与用户B相关联时)的分层ID将为“用户B/B-2/B-2-1”。

图9进一步示出了根据本公开的各种示例性实施例的来自不同域的多个订户或用户可如何被与单个设备相关联。该场景与图8所示的场景类似，不同之处在于，订户A和用户C(他们共享汽车设备IMPI3的使用)分别来自不同的域1和2。例如，域1和2可以表示不同的移动网络运营商(MNO)。

在示例性实施例中，许可和访问控制可以通过对从订户的所有设备生成的数据进行加密来实现。分层ID提供了用于加密方案的参数。更具体地，各种实施例利用上面讨论的示例性分层ID以及HIBE加密方案，在该方案中，从GBA导出的密钥(被称为Ks)在建立期间被用作输入。通过组合分层标识和HIBE，可以使用相关联的分层ID对来自设备和/或应用的数据进行加密，并将数据发送给服务提供商(SP)。通过基于设备和/或应用的分层ID来生成私钥(SK)，订户/用户给予特定SP可以解密来自哪个设备和/或应用的哪些数据的许可。

该技术涉及以下操作，这些操作中的一个或多个可以在各种示例性实施例中使用：

·建立(Ks)→PK，MSK：生成公钥(PK)参数和主私钥(MSK)。Ks参数可以从GBA引导中导出，并且对于每个订户/用户是唯一的，例如基于与移动网络相关联的订户ID信息。

·KeyGen(MSK，ID1)→SK：获取MSK和ID1(ID的分层列表)以生成供特定SP使用的私钥(SK)。例如，如果订户A给予对来自智能手机、智能手表、心脏监视器应用和汽车的数据的许可，则被用于生成用于SP的SK的分层ID是“订户A/A1/A-2-1/A3”。

·加密(PK，ID1，M)→CT：获取消息(M)、PK、以及与生成消息M的特定应用和/或设备相关联并产生密文(CT)的ID1的分层级别。

·解密(SK，CT)→M：获取SK和CT作为输入，并且基于在SK中结合的ID的访问权限，SP将能够将CT解密为M。

图10示出了根据本公开的实施例的多-X密钥成链(MXKC)的示例性架构的图，其利用GBA组件来解决上述多-X场景和要求。该架构被分成几个模块和/或组件，它们的功能和/或操作可被总结如下：

·MX-KC(1010)：生成层次、私钥、以及加密所需的参数。

·MX-CAS(1020)：充当为设备提供许可的接口(1095)。订户使用MX-CAS向应用/服务提供商(SP)的设备给予许可。MX-CAS还负责将许可映射到MX-KC(1010)所需的参数中。

·BSF(1030)：处理架构的所有组件之间的业务，并负责执行设备(例如1095)和订户(例如订户1090)的引导。

·KMS(1040)：代表订户(1090)存储私钥、管理私钥、以及将私钥分发给SP。

·TAS(1050)：存储简档、订户的设备列表(例如，在XCAP文档中)。

·HSS(1060)：存储引导和TAS所需的设备(1095)信息。

·NAF(1080)：应用服务器，例如，用于业务应用(1085)。

·控件(1070)：外部实体必须通过其与HSS(1060)和TAS(1050)通信的代理。

在各个实施例中，在初始化期间，订户针对该引导操作基于利用GBA来导出Ks。然后，MX-KC使用Ks来初始化自身，以用于生成设备ID的层次、PK(设备用于加密所需的)、以及MSK(用于生成要由SP用于该订户/用户的用户私钥(SK)所需的)。订户使用MX-CAS来建立针对设备的许可，这些许可被映射到参数中，然后被转发给MX-KC。转而，MX-KC生成SP的私钥并将其发送给KMS。

当订户设备和/或应用想要将加密后的数据发送到(例如SP的)业务应用或应用服务器时，订户设备和/或应用可以向MX-KC认证自身，以获得加密所需的PK。设备使用PK及其身份对数据进行加密并将数据发送到业务应用。当SP想要解密所接收的数据时，SP可以向KMS请求SK，并且如果SP具有对该数据的访问特权，则SP将接收到SK并能够解密该数据。这些过程的细节显示在下面的序列图中。

图11示出了根据本公开的各种示例性实施例的用于订户初始化的示例性方法和/或过程的信号流程图。当订户想要首次建立其设备以与MX-KC一起使用时，可以使用该示例性方法和/或过程。例如，该示例性方法和/或过程可以在与订户相关联的“主设备”上被执行。在一些实施例中，基于特定设备对该示例性方法和/或过程的执行，该特定设备可以被标识为“主设备”。

尽管以特定顺序示出了图11所示的操作，但是该顺序是示例性的，并且所示出的操作可以以不同的顺序被执行，以及可被组合和/或划分成具有与图11所示的功能不同的功能的操作。此外，图11中所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，使得它们能够被协同使用以提供益处、优点和/或对以上描述的问题的解决方案。例如，图11所示的示例性方法和/或过程可以与图12-16所示的一种或多种示例性方法和/或过程一起使用。

在操作1110中，订户向MX-KC发送初始化请求，MX-KC用经由引导进行认证的请求向订户进行响应(操作1120)。在操作1130中，订户向BSF发送引导请求，该请求附带了订户的ID(例如，与移动网络相关联的IMS专用用户身份(IMPI))。随后，在操作1140中，BSF使用对用于该订户的认证矢量(AV)的请求将订户ID发送到HSS，只要订户ID有效，HSS就在操作1150中提供该AV。该AV可以包括质询(challenge)(例如，随机数)、预期响应以及能够在认证中使用的密钥。在框1160中，BSF将质询发送到订户，订户在1170中返回响应。如果该响应与预期响应相匹配，则BSF导出引导密钥Ks和相关联的引导标识符(BTID)参数(操作1175)，然后将BTID发送到订户(操作1180)。BSF还保留BTID，BSF稍后可将该BTID用于标识被用于生成各种实体的会话密钥的关联Ks，如下所述。在接收到BTID之后，订户使用该BTID来导出订户自己的引导密钥Ks，以及被用于与MX-CAS和MX-KC进行进一步的安全通信的密钥Ks

下面相对于图12描述了操作1200(密钥成链(KC)初始化)。在KC初始化之后，MX-KC用执行CAS初始化的请求来响应订户。下面相对于图13描述所得到的操作1300(CAS初始化)。

图12示出了根据本公开的各种示例性实施例的用于密钥成链(KC)初始化的示例性方法和/或过程的信号流程图。例如，该示例性方法和/或过程可以被用于建立订户的设备和应用的层次，并根据该层次生成用于加密的参数。尽管以特定顺序示出了操作，但是该顺序是示例性的，并且所示出的操作可以以不同的顺序被执行，以及可被组合和/或划分成具有与图12所示的功能不同的功能的操作。此外，图12中所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，使得它们能够被协同使用以提供益处、优点和/或对上述问题的解决方案。例如，图12所示的示例性方法和/或过程可以与图11和图13-16所示的一种或多种示例性方法和/或过程一起使用。

在操作1210中，订户将初始化请求与ID参数BTID(例如，在操作1175中由BSF导出)一起发送到MX-KC。在操作1220中，MX-KC向BSF发送对要被用于与订户进一步通信的密钥Ks

在操作1260中，MX-KC向TAS请求订户的应用或服务特定的简档。例如，TAS可以由订户的移动网络运营商来供应。MX-KC使用在操作1230中接收的订户ID来标识TAS的特定订户。在操作1270中，TAS用订户的应用或服务特定的简档进行响应，MX-KC在操作1275中使用该简档来生成并存储设备/应用ID的层次。此外，MX-KC生成订户的公钥(PK)和主私钥(MSK)。然后，MX-KC存储这些所生成的参数，以备将来可能使用，如下所述。

图13示出了根据本公开的各种示例性实施例的用于上下文感知服务(CAS)初始化的示例性方法和/或过程的信号流程图。例如，该示例性方法和/或过程可以用于促进针对该订户的任何或所有设备和/或应用的许可设置的初始化。尽管以特定顺序示出了操作，但是该顺序是示例性的，并且所示出的操作可以以不同的顺序被执行，以及可被组合和/或划分成具有与图13所示的功能不同的功能的操作。此外，图13中所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，使得它们能够被协同使用以提供益处、优点和/或对上述问题的解决方案。例如，图13所示的示例性方法和/或过程可以与图11-12和14-16所示的一种或多种示例性方法和/或过程一起使用。

在操作1310中，订户将初始化请求与引导身份BTID一起发送到MX-CAS。在操作1320中，MX-CAS向BSF发送对要被用于与订户进一步通信的密钥Ks

在操作1360中，MX-CAS通过发送与订户相关联的实体列表来响应订户的初始化请求(例如，在操作1310中做出)。可以使用在操作1330中接收的密钥Ks

图14示出了根据本公开的各种示例性实施例的用于上下文感知服务(CAS)更新的示例性方法和/或过程的信号流程图。例如，订户可以使用该示例性方法和/或过程来更新用于相关联设备的许可。由于图14中所示的CAS更新操作与图13中所示的CAS初始化操作(CAS初始化)基本相似，因此对特定操作的上述描述同样适用于图14中相同编号的操作。

图15示出了根据本公开的各种示例性实施例的用于密钥成链(KC)更新的示例性方法和/或过程的信号流程图。尽管以特定顺序示出了操作，但是该顺序是示例性的，并且所示出的操作可以以不同的顺序被执行，以及可被组合和/或划分成具有与图15所示的功能不同的功能的操作。此外，图15中所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，使得它们能够被协作地使用以提供益处、优点和/或对上述问题的解决方案。例如，图15所示的示例性方法和/或过程可以与图11-14和16所示的一种或多种示例性方法和/或过程一起使用。

图15所示的操作1510-1570与图12所示的各个CAS初始化操作1210-1270基本相似，因此，下面将不再对其进行描述。在生成和存储设备/应用ID的更新后的层次之后(操作1575)，MX-KC请求订户执行CAS更新以合并更新后的层次(操作1580)。订户可以使用图14中所示的示例性方法和/或过程来执行这种更新。

图16示出了根据本公开的各种示例性实施例的用于设备初始化的示例性方法和/或过程的信号流程图。例如，该示例性方法和/或过程可用于在(例如，从特定设备)第一次向应用/服务提供商发送数据之前初始化该设备。例如，图16中的示例性方法和/或过程可用于在“主设备”已执行了图11所示的示例性方法和/或过程之后初始化“辅助设备”。

尽管以特定顺序示出了操作，但是该顺序是示例性的，并且所示出的操作可以以不同的顺序被执行，以及可被组合和/或划分成具有与图16所示的功能不同的功能的操作。图16所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，以使得它们能够被协作地使用以提供益处、优点和/或对上述问题的解决方案。例如，图16所示的示例性方法和/或过程可以与图11-15所示的一种或多种示例性方法和/或过程一起使用。

在操作1610中，设备向MX-KC发送对要被用于与SP的NAF进行订户通信的公钥(PK)的请求。在操作1615中，MX-KC使用经由引导进行认证的请求对设备进行响应。在操作1620中，设备向BSF发送引导请求，该引导请求附带有设备ID。随后，在操作1625中，BSF使用对用于该设备的认证矢量(AV)的请求将设备ID发送到HSS，只要设备ID有效，HSS就在操作1630中提供该AV。该AV可以包括质询(例如，随机数)、预期响应以及能够在认证中使用的密钥。在框1635中，BSF将质询发送给设备，设备在1640中返回响应。如果响应与预期的响应相匹配，则BSF导出引导密钥Ks和相关联的引导标识符BTID(操作1642)，然后将BTID发送给设备(操作1645)。在接收到BTID之后，设备使用该BTID来导出设备自己的引导密钥Ks，以及分别可用于与MX-CAS和NAF进行进一步的安全通信的密钥Ks

在操作1650中，设备再次使用BTID参数(在操作1645中接收的)订户标识信息向MX-KC请求公钥(PK)，该公钥可用于加密要被发送给NAF的用户数据。在操作1655中，MX-KC向BSF发送对要被用于与使用在操作1650中接收的BTID来标识的订户设备进行安全通信的密钥Ks

在操作1675中，NAF向BSF请求可用于与用户设备进行通信的密钥Ks

上述示例性实施例的两个主要组件是MX-CAS和MX-KC，它们负责用于加密的许可管理和密钥生成。在各种实施例中，可以根据订户与移动网络操作(MNO)之间的要求和/或协商，在各个位置实现和/或部署这两个组件。

图17A-C示出了根据本公开的各种示例性实施例的用于部署MX-CAS和MX-KC的三种不同的选项和/或架构的高层图。在图17A中，MX-CAS和MX-KC基本上都位于例如在安全的、防篡改的环境中的订户设备中。在这种布置中，以上关于图11-16描述的各种与安全有关的操作可能不是所需的和/或不相关。例如，如果MX-KC和MX-CAS位于订户设备内，则不需要图12中的操作1210-1235、图13中的1310-1335、图14中的1410-1435、图15中的1510-1535、以及图16中的1610-1665。

图17B示出了其中MX-CAS和MX-KC都可以被部署在网关级别(例如，到特定域的网关)的其他示例性实施例。图17C示出了其中MX-CAS和MX-KC都可以被部署在移动网络运营商(MNO)级别(例如，在MNO数据中心中)的其他示例性实施例。其他示例性实施例可以包括图17A-C所示的三个部署选项的组合。

图18示出了根据本公开的各种示例性实施例的用于促进移动通信网络的订户与一个或多个服务提供商(SP)之间的安全通信的示例性方法和/或过程的流程图，其中，该订户与包括设备和简档的任何组合的多个实体相关联。例如，图18所示的示例性方法和/或过程可以由诸如用户设备(UE)之类的订户设备执行。尽管以特定顺序示出了操作，但此顺序是示例性的，并且示出的操作可以按不同的顺序被执行，以及可被组合和/或划分成具有与图18所示的功能不同的功能的操作。虚线指示可选操作。

此外，图18所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，以使得它们能够被协作使用以提供益处、优点和/或对本文描述的问题的解决方案。例如，图18所示的示例性方法和/或过程可以与图19-21所示的一种或多种示例性方法和/或过程一起使用。

该示例性方法和/或过程可以包括框1810的操作，其中，订户设备可以获得与该订户相关联的安全标识符(ID)。在一些实施例中，安全ID包括引导标识符(BTID)，并且获得安全ID包括与引导服务器(BSF)执行认证密钥协商(AKA)并接收BTID。在一些实施例中，这可以包括图11中所示的操作1110至1180或图16中所示的操作1610至1645中的各种操作。例如，与BSF执行AKA可以包括：向BSF发送引导请求；接收来自BSF的认证质询；向BSF发送认证响应；以及接收BTID。

在一些实施例中，该示例性方法和/或过程还可包括框1830的操作，其中，订户设备可基于安全ID来生成多个密钥。

该示例性方法和/或过程还可包括框1820的操作，其中，订户设备可基于安全ID来建立包括与订户相关联的多个实体的身份层次。在一些实施例中，身份层次还包括与每个实体相关联的一个或多个应用。在一些实施例中，身份层次还包括与应用中的至少一部分应用相关联的一个或多个时间段。

在一些实施例中，建立身份层次可以包括：发送包括安全ID的初始化请求，其中，初始化请求是使用基于安全ID可导出的第二密钥来加密的；接收对基于安全ID而生成的多个密钥中的第一密钥的请求；使用第二密钥解密该请求；以及发送包括第一密钥的响应，其中，该响应是使用第二密钥来加密的。在一些实施例中，这些操作可以对应于图12所示的操作1210至1275中的各个操作。

该示例性方法和/或过程还可以包括框1830的操作，其中，订户设备可以基于安全ID来建立用于一个或多个SP访问由在身份层次中包括的实体生成的数据的许可。在一些实施例中，这可以包括建立用于一个或多个SP访问由与每个实体相关联的一个或多个应用生成的数据的许可。在一些实施例中，这可以包括建立用于一个或多个SP访问由应用中的至少一部分应用在一个或多个时间段期间生成的数据的许可。

在一些实施例中，框1830的操作可以包括：发送包括安全ID的请求，其中，该请求是使用基于安全ID可导出的第三密钥来加密的；接收与订户相关联的包括设备和简档的任何组合的实体列表；使用第三密钥来解密该实体列表；将用于一个或多个SP中的每个SP的许可与在该列表中包括的实体相关联；以及发送包括该许可的响应，其中，该响应时使用第三密钥来加密的。在一些实施例中，这些操作可以对应于图13所示的操作1310至1370中的各个操作。

该示例性方法和/或过程还可以包括框1840的操作，其中，订户设备可以响应于包括安全ID的请求而接收能够用于加密数据以发送到特定SP的公钥(PK)，其中，该数据是使用与所建立的用于该特定SP的许可相关联的对应的私钥(SK)可解密的。在一些实施例中，接收可用于加密数据以发送到特定SP的PK可以包括：发送对PK的请求，其中，该请求包括安全ID并且使用基于安全ID可导出的第二密钥来被加密；接收包括PK的响应；以及使用第二密钥来解密该响应。在一些实施例中，这些操作可以对应于图16中所示的操作1650至1665中的各种操作。

该示例性方法和/或过程还可以包括框1850的操作，其中，订户设备可以使用PK和身份层次对数据进行加密。在一些实施例中，该示例性方法和/或过程还可以包括框1860的操作，其中，订户设备可以将由PK加密的数据与安全ID相关联地发送到SP，其中，由PK加密的数据和安全ID还由基于安全ID可导出的第四密钥来加密。

图19示出了根据本公开的各种示例性实施例的用于促进移动通信网络的订户与一个或多个服务提供商(SP)之间的安全通信的另一示例性方法和/或过程的流程图，其中，该订户与包括设备和简档的任何组合的多个实体相关联。例如，图19所示的示例性方法和/或过程可以由服务器(例如，如本文所述的引导服务器(BSF))执行。尽管以特定顺序示出了操作，但此顺序是示例性的，并且示出的操作可以按不同的顺序被执行，以及可以被组合和/或划分成具有与图19所示的功能不同的功能的操作。虚线指示可选操作。

此外，图19所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，以使得它们能够被协作使用以提供益处、优点和/或对本文描述的问题的解决方案。例如，图19所示的示例性方法和/或过程可以与图18、20和21所示的一种或多种示例性方法和/或过程一起使用。

该示例性方法和/或过程可以包括框1910的操作，其中，BSF可以与订户设备执行认证密钥协商(AKA)。在一些实施例中，这可以对应于图11中所示的操作1130至1170或图16中所示的操作1620至1640中的各个操作。该示例性方法和/或过程还可以包括框1920的操作，其中，BSF可以导出并存储引导标识符(BTID)和与BTID相关联的多个密钥。在一些实施例中，这可以对应于图11所示的操作1175或图16所示的操作1642。该示例性方法和/或过程还可以包括框1930的操作，其中，BSF可以将BTID发送到订户设备。在一些实施例中，这可以对应于图11中所示的操作1180或图16中的操作1645。

该示例性方法和/或过程还可包括框1940的操作，其中，BSF可以接收对多个秘钥中的第一秘钥的第一请求，其中，第一请求包括相关联的BTID。该示例性方法和/或过程还可以包括框1950的操作，其中，BSF可以基于确定所关联的BTID与所存储的BTID相匹配来响应于第一请求而发送第一密钥。在一些实施例中，第一请求是从密钥成链(KC)服务器接收的；以及第一密钥被发送到KC服务器。在一些实施例中，这些操作可以对应于图12所示的操作1220至1230、图15所示的操作1520至1530或图16所示的操作1655至1660中的各个操作。

在一些实施例中，该示例性方法和/或过程还可以包括框1960的操作，其中，BSF可以接收对多个秘钥中的第二密钥的第二请求，其中，第二请求包括相关联的BTID。在这样的实施例中，该示例性方法和/或过程还可以包括框1970的操作，其中，BSF可以基于确定所关联的BTID与所存储的BTID相匹配来响应于第二请求而发送第二密钥。在一些实施例中，第二请求是从上下文感知服务(CAS)服务器接收的；以及第二密钥被发送到CAS服务器。在一些实施例中，这些操作可以对应于图13所示的操作1320至1330或图14所示的操作1420至1430中的各种操作。

在一些实施例中，该示例性方法和/或过程还可以包括框1980的操作，其中，BSF可以接收对多个秘钥中的第三密钥的第三请求，其中，第三请求包括相关联的BTID。在这样的实施例中，该示例性方法和/或过程还可以包括框1990的操作，其中，BSF可以基于确定所关联的BTID与所存储的BTID相匹配来响应于第三请求而发送第三密钥。在一些实施例中，第三请求是从与特定SP相关联的网络应用(NAF)服务器接收的；以及第三密钥被发送给NAF服务器。在一些实施例中，这些操作可以对应于图16中所示的操作1675至1680中的各个操作。

图20示出了根据本公开的各种示例性实施例的用于促进移动通信网络的订户与一个或多个服务提供商(SP)之间的安全通信的另一示例性方法和/或过程的流程图，其中，该订户与包括设备和简档的任何组合的多个实体相关联。例如，图20所示的示例性方法和/或过程可以由服务器(例如，如本文所述的密钥成链(KC)服务器)执行。尽管以特定顺序示出了操作，但此顺序是示例性的，并且示出的操作可以按不同的顺序被执行，以及可以被组合和/或划分成具有与图20所示的功能不同的功能的操作。虚线指示可选操作。

此外，图20所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，以使得它们能够被协作使用以提供益处、优点和/或对本文描述的问题的解决方案。例如，图20所示的示例性方法和/或过程可以与图18、19和/或21所示的一种或多种示例性方法和/或过程一起使用。

该示例性方法和/或过程可以包括框2010的操作，其中，KC服务器可以从订户设备接收包括与订户相关联的安全标识符(ID)的请求。在一些实施例中，这可以对应于图12中所示的操作1210或图15中所示的操作1510。在一些实施例中，接收该请求可以包括：从订户设备接收第一初始化请求；发送指示订户设备执行引导的响应；以及从订户设备接收包括安全ID的另一个初始化请求。在一些实施例中，这些操作可以对应于图11所示的操作1110至1120和图12所示的操作1210中的各种操作。

该示例性方法和/或过程可以包括框2020的操作，其中，KC服务器可以基于安全ID来建立包括与订户相关联的多个实体的身份层次。在一些实施例中，建立身份层次还可以包括：接收与订户相关联的包括设备和简档的任何组合的实体列表；以及基于该实体列表来生成身份层次。在一些实施例中，这些操作可以对应于图12中示出的操作1270至1275和图15中示出的操作1570至1575中的各个操作。在一些实施例中，身份层次还包括与每个实体相关联的一个或多个应用。在一些实施例中，身份层次还包括与应用中的至少一部分应用相关联的一个或多个时间段。

在一些实施例中，建立身份层次还可以包括：发送对基于安全ID可导出的多个密钥中的第二密钥的请求，其中，该请求包括安全ID；接收第二密钥和订户身份信息；以及基于订户身份信息来认证订户设备。在一些实施例中，这些操作可以对应于图12所示的操作1220至1235和图15所示的操作1520至1535中的各种操作。

在一些实施例中，建立身份层次还可以包括：向经认证的订户设备发送对多个密钥中的第一密钥的请求，其中，该请求是使用第二密钥来加密的；从经认证的订户设备接收包括第一密钥的响应；以及使用第二密钥来解密响应。在一些实施例中，这些操作可以对应于图12所示的操作1240至1250或图15所示的操作1540至1550中的各个操作。

该示例性方法和/或过程可以包括框2030的操作，其中，KC服务器可以生成与订户相关联的公钥(PK)。在一些实施例中，可以基于第一密钥来生成PK。在一些实施例中，这可以对应于图12所示的操作1275。

该示例性方法和/或过程可以包括框2040的操作，其中，KC服务器可以生成与身份层次相对应的私钥(SK)层次。在一些实施例中，SK层次包括用于一个或多个SP访问由与每个实体相关联的一个或多个应用生成的数据的相应的SK。在一些实施例中，SK层次包括用于一个或多个SP访问由应用中的至少一部分应用在一个或多个时间段期间生成的数据的相应的SK。

在一些实施例中，生成SK层次包括：接收用于一个或多个SP访问由在身份层次中包括的实体生成的数据的许可；以及基于许可和主私钥(MSK)来生成SK层次。在一些实施例中，这些操作可以对应于图13所示的操作1370至1375或图14所示的操作1470至1475中的各种操作。

该示例性方法和/或过程还可以包括框2050的操作，其中，KC服务器可以将SK层次发送到密钥管理系统(KMS)以存储。在一些实施例中，这些操作可以对应于图13所示的操作1390或图14所示的操作1490。

该示例性方法和/或过程可以包括框2050的操作，其中，KC服务器可以向在身份层次中包括的特定设备或简档提供PK。在一些实施例中，向在身份层次中包括的特定设备或简档提供PK可以包括：从第一设备接收对PK的请求，该请求包括安全ID；发送对基于安全ID可导出的多个密钥中的第二密钥的请求，其中，该请求包括安全ID；接收第二密钥；以及向第一设备发送PK，其中，PK是使用第二密钥来加密的。在一些实施例中，这些操作可以对应于图16中所示的操作1650至1665。在一些实施例中，安全ID包括引导标识符(BTID)；对第二密钥的请求被发送到引导服务器(BSF)；以及第二密钥是从BSF接收的。

图21示出了根据本公开的各种示例性实施例的用于促进移动通信网络的订户与一个或多个服务提供商(SP)之间的安全通信的另一示例性方法和/或过程的流程图，其中，该订户与包括设备和简档的任何组合的多个实体相关联。例如，图21所示的示例性方法和/或过程可以由服务器(例如，如本文所述的上下文感知服务(CAS)服务器)执行。尽管以特定顺序示出了操作，但此顺序是示例性的，并且示出的操作可以按不同的顺序被执行，以及可以被组合和/或划分成具有与图21所示的功能不同的功能的操作。虚线指示可选操作。

此外，图21所示的示例性方法和/或过程可以与本文公开的其他示例性方法和/或过程互补，以使得它们能够被协作使用以提供益处、优点和/或对本文描述的问题的解决方案。例如，图21所示的示例性方法和/或过程可以与图18-20所示的一种或多种示例性方法和/或过程一起使用。

该示例性方法和/或过程可以包括框2110的操作，其中，CAS服务器可以从订户设备接收包括与订户相关联的安全标识符(ID)的请求。在一些实施例中，这可以对应于图13所示的操作1310或图14所示的操作1410。

该示例性方法和/或过程还可以包括框2120的操作，其中，CAS服务器可以基于与安全ID相关联的订户信息来认证订户。在一些实施例中，认证订户包括：发送对基于安全ID可导出的第二密钥的请求，其中，该请求包括安全ID；接收第二密钥和订户身份信息；以及基于订户身份信息来认证订户。在一些实施例中，这些操作可以对应于图13所示的操作1320至1335或图14所示的操作1420至1435中的各种操作。

该示例性方法和/或过程还可以包括框2130的操作，其中，CAS服务器可以向订户设备发送与订户相关联的包括设备和简档的任何组合的实体列表。在一些实施例中，被发送给订户设备的实体列表是使用第二密钥来加密的。在一些实施例中，这可以对应于图13所示的操作1360或图14所示的操作1460。

该示例性方法和/或过程还可以包括框2140的操作，其中，CAS服务器可以从订户设备接收用于一个或多个服务提供商(SP)访问由被包括在列表中的实体生成的数据的许可。在一些实施例中，这可以对应于图13所示的操作1370或图14所示的操作1470。在一些实施例中，从订户设备接收的许可是使用第二密钥来解密的。

该示例性方法和/或过程还可以包括框2150的操作，其中，CAS服务器可以将所接收的许可映射到包括与订户相关联的实体的身份层次中。在一些实施例中，映射所接收的许可还包括映射用于一个或多个SP访问由与每个实体相关联的一个或多个应用生成的数据的许可。在一些实施例中，映射所接收的许可还包括映射用于一个或多个SP访问由应用中的至少一部分应用在一个或多个时间段期间生成的数据的许可。在一些实施例中，这可以对应于图13所示的操作1375或图14所示的操作1475。

尽管以上在方法、装置、设备、计算机可读介质和接收机方面描述了各种实施例，但是本领域技术人员将容易理解，这些方法可以由各种系统、通信设备、计算设备、控制设备、装置、非暂时性计算机可读介质等中的硬件和软件的各种组合来体现。图22示出了可根据本文描述的本公开的各种示例性实施例配置的示例性订户设备或用户设备(UE)的框图。例如，图22所示的示例性设备可被配置为执行与图18的流程图所示的操作相对应的操作。

示例性设备2200可以包括处理器2210，处理器2210能够可操作地经由总线2270被连接到程序存储器2220和/或数据存储器2230，总线2270可以包括并行地址和数据总线、串行端口或本领域技术人员公知的其他方法和/或结构。程序存储器2220包括由处理器2210执行的软件代码或程序，该软件代码或程序促进、促使和/或编程示例性设备2200以使用一种或多种有线或无线通信协议进行通信，这些协议包括由3GPP、3GPP2或IEEE标准化的一种或多种无线通信协议，例如通常称为5G/NR、LTE、LTE-A、UMTS、HSPA、GSM、GPRS、EDGE、1xRTT、CDMA2000、802.11WiFi、HDMI、USB、Firewire等的协议，或可以与通信收发机2240、用户接口2250和/或主机接口2260结合使用的任何其他当前或将来的协议。

例如，处理器2210可以执行存储在程序存储器2220中的程序代码，该程序代码对应于由3GPP(例如，针对NR和/或LTE)标准化的MAC、RLC、PDCP和RRC层协议。作为另一示例，处理器2210可以执行存储在程序存储器2220中的程序代码，该程序代码与通信收发机2240一起实现对应的PHY层协议，例如正交频分复用(OFDM)、正交频分多址(OFDMA)、以及单载波频分多址(SC-FDMA)。

程序存储器2220还可以包括由处理器2210执行以控制设备2200的功能(包括配置和控制诸如通信收发机2240、用户接口2250和/或主机接口2260的各种组件)的软件代码。程序存储器2220还可以包括一个或多个应用程序和/或模块，包括体现本文所述的任何示例性方法和/或过程的计算机可执行指令。可以使用任何已知的或将来开发的编程语言(例如，Java、C++、C、Objective C、HTML、XHTML、机器代码和汇编器)指定或编写此类软件代码，只要保留例如由所实现的方法步骤定义的所需功能即可。附加地或替代地，程序存储器2220可以包括远离设备2200的外部存储装置(未示出)，指令可以从该外部存储装置被下载到位于设备2200内或可移除地被耦接到设备2200的程序存储器2220中，从而能够执行这样的指令。

数据存储器2230可以包括用于处理器2210的存储区域，以存储在设备2200的协议、配置、控制和其他功能中使用的变量，包括与本文描述的示例性方法和/或过程相对应的操作或包含与本文描述的示例性方法和/或过程的操作。此外，程序存储器2220和/或数据存储器2230可以包括非易失性存储器(例如，闪存)、易失性存储器(例如，静态或动态RAM)或它们的组合。此外，数据存储器2230可以包括存储器槽，借助该存储器槽可以插入和移除一种或多种格式的可移除存储卡(例如，SD卡、记忆棒、紧凑型闪存等)。

本领域技术人员将认识到，处理器2210可以包括多个单独的处理器(包括例如多核处理器)，每个处理器实现上述功能的一部分。在这种情况下，多个单独的处理器可以共同地被连接到程序存储器2220和数据存储器2230，或者单独地被连接到多个单独的程序存储器和/或数据存储器。更一般而言，本领域技术人员将认识到，设备2200的各种协议和其他功能可以在包括硬件和软件的不同组合的许多不同计算机装置中实现，这些硬件和软件包括但不限于应用处理器、信号处理器、通用处理器、多核处理器、ASIC、固定和/或可编程数字电路、模拟基带电路、射频电路、软件、固件、以及中间件。

通信收发机2240可以包括射频发射机和/或接收机功能，这些功能促进设备2200与支持诸如无线通信标准和/或协议的其他设备进行通信。在一些示例性实施例中，通信收发机2240包括发射机和接收机，它们使得设备2200能够根据由3GPP和/或其他标准机构提出以标准化的各种协议和/或方法来与各种5G/NR网络进行通信。举例来说，此功能性可与处理器2210协同操作以基于OFDM、OFDMA和/或SC-FDMA技术实现PHY层，例如本文相对于其他附图所描述的。

在一些示例性实施例中，通信收发机2240包括LTE发射机和接收机，它们可以促进设备2200根据3GPP发布的标准来与各种LTE、高级LTE(LTE-A)和/或NR网络进行通信。在本公开的一些示例性实施例中，通信收发机2240包括设备2200还根据3GPP标准与各种5G/NR、LTE、LTE-A、UMTS和/或GSM/EDGE网络进行通信所必需的电路、固件等。在本公开的一些示例性实施例中，通信收发机2240包括设备2200根据3GPP2标准与各种CDMA2000网络进行通信所必需的电路、固件等。

在本公开的一些示例性实施例中，通信收发机2240能够使用在非授权频带中工作的无线电技术(诸如使用在2.4、5.6和/或60GHz的区域中的频率进行工作的IEEE802.11WiFi)进行通信。在本公开的一些示例性实施例中，通信收发机2240可以包括能够例如通过使用IEEE 802.3以太网技术进行有线通信的收发机。特定于这些实施例中的每一个实施例的功能可以被与设备2200中的其他电路相耦接或由设备2200中的其他电路来控制，该其他电路诸如执行结合数据存储器2230被存储在程序存储器2220中或被存储在由数据存储器2230支持的程序存储器2220中的程序代码的处理器2210。

用户接口2250可以根据设备2200的特定实施例而采取各种形式，或者可以完全不存在于设备2200中。在一些示例性实施例中，用户接口2250可以包括麦克风、扬声器、可滑动按钮、可按下按钮、显示器、触摸屏显示器、机械或虚拟小键盘、机械或虚拟键盘和/或通常在移动电话上找到的任何其他用户接口特性。在其他实施例中，设备2200可以包括具有更大的触摸屏显示器的平板计算设备。在这样的实施例中，用户接口2250的一个或多个机械特性可被本领域技术人员熟悉的使用触摸屏显示器实现的相当的或功能等效的虚拟用户接口特性(例如，虚拟小键盘、虚拟按钮等)所代替。在其他实施例中，设备2200可以是数字计算设备(例如膝上型计算机、台式计算机、工作站等)，其包括取决于特定示例性实施例而可被集成、拆卸或可拆卸的机械键盘。这样的数字计算设备还可以包括触摸屏显示器。具有触摸屏显示器的设备2200的许多示例性实施例能够接收用户输入，诸如与本文所述或本领域技术人员以其他方式公知的示例性方法和/或过程相关的输入。

设备2200的控制接口2260可以采取各种形式，这取决于设备2200的特定示例性实施例以及设备2200旨在与之进行通信和/或控制的其他设备的特定接口要求。例如，控制接口2260可以包括RS-232接口、RS-485接口、USB接口、HDMI接口、蓝牙接口、IEEE(“火线”)接口、I

本领域技术人员可以认识到以上一系列特性、接口和射频通信标准仅是示例性的，并且不限制本公开的范围。换句话说，设备2200可以包括比图22所示更多的功能，包括例如视频和/或静止图像摄像机、麦克风、媒体播放器和/或记录器等。此外，通信收发机2240可以包括使用附加射频通信标准(包括蓝牙、GPS和/或其他)进行通信所需的电路。此外，处理器2210可以执行被存储在程序存储器2220中的软件代码以控制这种附加功能。

图23是可根据本公开的一个或多个示例性实施例配置的示例性服务器装置的框图。例如，装置2300可被配置为执行本文所述的任何示例性方法和/或过程，例如图19-21所示的那些示例性方法和/或过程。装置2300包括控制器2310，控制器2310经由虚拟交换机(Vswitch)2340被连接到多个处理元件(PE或“处理器”)2330-2333。尽管示出了四个PE和一个Vswitch，但这仅是示例性的，并且可以有利地采用涉及更多(或更少)PE和附加Vswitch的配置。在一些实施例中，PE 2330-2333可被配置为一个或多个虚拟计算机器(VM)，其数量可以与PE 2330-2333的数量相同或不同。

Vswitch 2340还可以促进经由诸如以太网之类的局域网(LAN)功能在各种PE2330-2333(和/或所配置的VM)之间的通信。例如，当新的VM被初始化时，云编排器2320可以向该新的VM分配介质访问控制(MAC)地址。去往/来自VM的所有后续通信可以使用此唯一的MAC地址。示例性的云编排器2320是OpenStack，其中，“Nova”组件预先确定DC中的VM的MAC和互联网协议(IP)地址。装置2300可以经由一个(或多个)网关(诸如网关2370)在外部进行通信。例如，装置2300可以经由网关2370和兼容的对等网关与对等并行计算装置进行通信。在一些实施例中，网关2370可以包括通信收发机2375(例如，千兆以太网收发机、光收发机、无线电收发机等)。

装置2300可以包括可操作地被连接到PE 2330-2333和控制器2310的存储器/存储设备2350。存储器/存储设备2350可以存储各种信息，包括例如可由PE 2330-2333和/或控制器2310执行的程序和/或模块。例如，存储器/存储设备2350可以存储计算机可执行指令，这些计算机可执行指令在被执行时将控制器2310和/或PE 2330-2333配置为执行与上述任何示例性方法和/或过程相对应的操作。作为另一示例，存储器/存储设备2350可以包括软件代码，该软件代码可以促进并且具体地配置装置2300以使用本领域技术人员公知的适当协议来经由网关2370进行通信。

存储器/存储设备2350的一部分也可以用于数据的永久、半永久和/或临时存储，以由控制器2310和/或PE 2330-2333进行进一步处理和/或传送。此外，存储器/存储设备2350的一部分也可以被用于与控制器2310、PE 2330-2333和/或装置2300的任何其他组件有关的配置的永久、半永久和/或临时存储。本领域技术人员将认识到，可以相对于控制器2310和/或PE 2330-2333以各种方式来配置存储器/存储设备2350。例如，多个单独的PE可以共同地被连接到存储器/存储设备2350，或者单独地被连接到包括存储器/存储设备2350的多个单独的存储器。更一般地，本领域技术人员将认识到，装置2300的各种协议和其他功能可以用硬件和软件的多种不同组合来实现，这些硬件和软件包括但不限于应用处理器、信号处理器、通用处理器、多核处理器、ASIC、固定数字电路、可编程数字电路、模拟基带电路、无线电-频率电路、软件、固件、以及中间件。

图24示出了可以在示例性通信设备2400中实现的示例性功能模块或电路架构。例如，示例性通信设备2400可以表示与图22中所示的示例性设备2200基本相似的设备，尽管根据各种功能模块以不同的方式来被配置。如图24所示，设备2400可以包括通信收发机电路2420，其在一些实施例中可以与设备2200的通信收发机2240基本相似。在其他实施例中，收发机电路2420可以具有比收发机2240的特性更多、更少的特性或与收发机2240的特性不同的特性。

另外，设备2400可以包括多个功能模块，在图24中分别标记为2402-2410。尽管示出了五个模块，但这仅是示例性的，使得设备2400可以被配置有更多或更少数量的模块。在各种实施例中，模块2402-2410中的每一个可以包括模拟和/或数字硬件的不同组合、一个或多个处理器、和/或存储计算机可执行指令(例如，可由一个或多个处理器执行)的存储器。此外，包括特定模块的硬件和/或软件不必是互斥的，以使得不同的模块可以(例如，以分时方式)利用同一硬件和/或软件。

不管特定的组合如何，每个模块可被配置为执行一个或多个特定的功能或操作。例如，每个模块可被配置为执行与以上相对于图18示出或描述的操作中的一个(或多个)操作相对应的特定操作。作为更具体的示例，模块2402-2410中的每个模块可被配置为执行图18所示的操作1810-1850中的相应操作。如上所述，设备2400中可以包括其他模块以执行附加的或不同的操作。

图25示出了可以在示例性服务器设备2500中实现的示例性功能模块或电路架构。例如，服务器设备2500可以表示与图23中所示的示例性服务器设备2300基本相似的设备，尽管根据各种功能模块以不同的方式来被配置。如图25所示，服务器设备2500可以包括通信收发机电路2520，其在一些实施例中可以与包括服务器设备2300的网关2370的通信收发机2375基本相似。在其他实施例中，收发机电路2520可以具有比通信收发机2375的特性更多、更少的特性或与通信收发机2375的特性不同的特性。

另外，设备2500可以包括多个功能模块，在图25中分别标记为2402-2510。尽管示出了五个模块，但这仅是示例性的，使得设备2500可以被配置有更多或更少数量的模块。在各种实施例中，模块2502-2510中的每一个模块可以包括模拟和/或数字硬件的不同组合、一个或多个处理器、和/或存储计算机可执行指令(例如，可由一个或多个处理器执行)的存储器。此外，包括特定模块的硬件和/或软件不必是互斥的，以使得不同的模块可以(例如，以分时方式)利用同一硬件和/或软件。

不管特定的组合如何，每个模块可被配置为执行一个或多个特定的功能或操作。例如，每个模块可被配置为执行与以上相对于图19-21示出或描述的操作中的一个(或多个)操作相对应的特定操作。作为更具体的示例，模块2502-2510中的每个模块可被配置为执行图19所示的操作1910-1950中的相应操作。如上所述，设备2500中可以包括其他模块以执行附加的操作，诸如图19所示的操作1960-1980。

作为另一示例，模块2502-2510中的每一个模块可被配置为执行图20中所示的操作2010-2050中的相应操作，以及可以包括附加模块(例如，模块2512)以执行操作2060。作为又一个示例，模块2502-2510中的每一个模块可被配置为执行图21中所示的操作2110-2150中的相应操作。

值得注意的是，受益于前述说明书和关联附图中呈现的教导，本领域技术人员将想到所公开实施例的修改和其他实施例。因此，应当理解，本发明不限于所公开的特定实施例，并且修改和其他实施例旨在被包括在本公开的范围内。尽管本文可以采用特定术语，但是它们仅在一般和描述性意义上使用，而不是出于限制的目的。

本文引用的参考文献包括：

[1]爱立信移动性报告(Ericsson mobility report)。https://www.ericsson.com/en/mobility-report/reports。

[2]欧盟通用数据保护法规(EU general data protection regulation)。[线上]https://www.eugdpr.org/。

[3]FTC隐私和数据安全性(FTC privacy and data security)。[线上]https://www.ftc.gov/reports/privacy-data-security-update-2016。

[4]个人数据保护(Personal data protection)。[线上]

http://www.regeringen.se/contentassets/87382a7887764e9995db186244b557e4/personal-data-protection。

[5]证书认证的优点和缺点(Advantages and disadvantages of certificateauthentication)。[线上]https://www.ssh.com/manuals/server-zosproduct/55/ch06s03s05.html。

[6]A.Jancic和M.Warren，“Pki-优点与障碍(Pki-advantages and obstacles)”，第104–114页，2004年1月。

[7]M.Sethi、P.Kortoi、M.D.Francesco和T.Aura，“资源受限设备的安全和低功耗认证(Secure and lowpower authentication for resource-constrained devices)”，2015年第五届国际物联网会议(IOT)，2015年10月，第30–36页。

[8]J.Ring、K.-K.R.Choo、E.Foo和M.Looi，“一种用于使用基于身份的密码学的sip的新认证机制和密钥协商协议(A new authentication mechanism and keyagreement protocol for sip using identity-based cryptography)”，2006年。

[9]M.Shanmugam、S.Thiruvengadam、A.Khurat和I.Maglogiannis，“为电子医疗应用实现安全的移动访问(Enabling secure mobile access for electronic health careapplications)”，普及健康会议和研讨会，2006年11月，第1-8页。

[10]Y.Targali、V.Choyi和Y.Shah，“使用通用引导系统跨异构网络进行无缝认证(Seamless authentication across heterogeneous networks using genericbootstrapping systems)”，2013年第9届国际无线通信和移动计算会议(IWCMC)，2013年7月，第137-142页。

[11]D.van Thanh、T.Jonvik、B.Feng、D.van Thuan和I.Jorstad，“使用移动电话对互联网应用进行简单的强认证(Simple strong authentication for internetapplications using mobile phones)”，IEEE GLOBECOM 2008-2008IEEE全球电信会议，2008年11月，第1-5页。

[12]J.A.MacDonald，“移动电子医疗应用的认证注意事项(Authenticationconsiderations for mobile ehealth applications)”，2008年第二届医疗普及计算技术国际会议，2008年1月，第64-67页。

[13]C.Doukas、I.Maglogiannis、V.Koufi、F.Malamateniou和G.Vassilacopoulos，“通过IoT移动医疗设备中的pki加密实现数据保护(Enabling dataprotection through pki encryption in IoT m-health devices)”，生物信息学与生物工程(BIBE)，2012IEEE第12国际会议，IEEE，2012年，第25-29页。

[14]J.Horwitz和B.Lynn，“迈向基于分层身份的加密(Toward hierarchicalidentity-based encryption)”，《密码学进展》，EUROCRYPT2002，L。R.Knudsen，编辑。柏林，海德堡：施普林格，柏林，海德堡，2002年，第466-481页。

[15]C.Gentry和A.Silverberg，“基于分层ID的密码学(Hierarchical id-basedcryptography)”，《密码学进展》—ASIACRYPT 2002，Y.Zheng，编辑。柏林，海德堡：施普林格，柏林，海德堡，2002年，第548–566页。

[16]D.Boneh、X.Boyen和E.-J.Goh，“具有恒定大小密文的基于分层身份的加密(Hierarchical identity-based encryption with constant size ciphertext)”，《密码学进展》–EUROCRYPT 2005，R.Cramer，编辑。柏林，海德堡：施普林格，柏林，海德堡，2005年，第440-456页。

[17]Q.Xing、B.Wang、X.Wang、P.Chen、B.Yu、Y.Tang和X.Gao，“无界可调用的具有自适应ID安全性的基于分层身份的加密(Unbounded revocable hierarchical identity-based encryption with adaptive-id security)”，2016年IEEE第18届高性能计算和通信国际会议；IEEE第14届智慧城市国际会议；IEEE第2届数据科学与系统国际会议(HPCC/SmartCity/DSS)，2016年12月，第430-437页。

[18]M.Mahmoody和A.Mohammed，“论基于分层身份的加密的力量(On the power ofhierarchical identity-based encryption)”，《密码学进展》–EUROCRYPT 2016，M.Fischlin和J.-S.Coron，编辑。柏林，海德堡：施普林格柏林海德堡，2016年，第243-272页。

[19]R.M.Daniel、E.B.Rajsingh和S.Silas，“基于分层身份的加密方案及其对计算环境的适用性分析(Analysis of hierarchical identity-based encryption schemesand its applicability to computing environments)”，《信息安全与应用学报》，第36卷，第20–31页，2017。[线上]。来源：http：//www.sciencedirect.com/science/article/pii/S221421261630148X。

[20]C.B.Gentry和A.Silverberg，“基于分层身份的加密和签名方案(Hierarchicalidentity-based encryption and signature schemes)”，2008年，美国专利7,349,538。

[21]J.W.Weber，“用于保护数字媒体的分层加密密钥系统(Hierarchical encryptionkey system for securing digital media)”，2009年1月20日，美国专利7,480,385。

[22]V.Goyal、O.Pandey、A.Sahai和B.Waters，“用于对加密数据进行细粒度访问控制的基于属性的加密(Attribute-based encryption for fine-grained accesscontrol of encrypted data)”，第13届ACM计算机和通信安全会议论文集。Acm，2006年，第89-98页。

[23]A.Lewko和B.Waters，“无边界hibe和基于属性的加密(Unbounded hibe andattribute-based encryption)”，关于加密技术的理论和应用的年度国际会议。施普林格，2011年，第547-567页。

[24]D.Boneh和X.Boyen，“无随机预言的高效选择性ID的基于安全身份的加密(Efficient selective-id secure identity-based encryption without randomoracles)”，《密码学进展》-EUROCRYPT 2004，C.Cachin和J.L.Camenisch，编辑。柏林，海德堡：施普林格，柏林，海德堡，2004年，第223-238页。