CN107852405A - 服务层的内容安全性 - Google Patents

服务层的内容安全性 Download PDF

Info

Publication number
CN107852405A
CN107852405A CN201680039249.0A CN201680039249A CN107852405A CN 107852405 A CN107852405 A CN 107852405A CN 201680039249 A CN201680039249 A CN 201680039249A CN 107852405 A CN107852405 A CN 107852405A
Authority
CN
China
Prior art keywords
content
certificate
described device
security
certificates
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
CN201680039249.0A
Other languages
English (en)
Other versions
CN107852405B (zh
Inventor
维诺德·库马尔·乔伊
约根德拉·C·沙阿
黛尔·N·希德
迈克尔·F·斯塔西尼克
沙米姆·阿克巴尔·拉赫曼
李庆光
陈卓
威廉·罗伯特·弗林四世
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.)
Convida Wireless LLC
Original Assignee
Convida Wireless LLC
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 Convida Wireless LLC filed Critical Convida Wireless LLC
Publication of CN107852405A publication Critical patent/CN107852405A/zh
Application granted granted Critical
Publication of CN107852405B publication Critical patent/CN107852405B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Information Transfer Between Computers (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

针对网络如oneM2M网络中的安全性的现有方法是受限的。例如，只有内容在互相信任的实体之间传输时，该内容才可能受到保护。这里，M2M网络中内容的完整性和保密性受到保护。这样的内容可以是“静止的”，使得所述内容存储于托管节点处。只有获授权的实体可以存储和检索存储于该托管节点处的数据，并且所述数据可以从保密性角度和完整性角度受到保护。

Description

服务层的内容安全性
相关申请的交叉引用
本申请要求2015年7月2日提交的第62/188,141号美国临时专利申请和2015年10月30日提交的第62/248,808号美国临时专利申请的权益，所述美国临时专利申请的全部内容在此以引用的方式并入。
背景技术
典型的通信会话通常涉及也可以被称为节点的两个或更多通信实体(例如，设备，应用等)之间的持久的交互式信息交换。在目前的RESTful方法中，不存在真正的持久连接。相反，通过按需请求和响应消息来执行通信。例如，可以在某个时间点建立通信会话，并且可以基于各种情况(例如，在会话超时之后或当其中一个实体决定终止会话时)在稍后的时间点拆除通信会话。通信会话通常涉及实体之间的多个消息交换，并且通常是有状态的，这意味着通信实体中的至少一个需要保存关于会话历史的信息以使得能够维持通信会话。可以保存的示例信息包含安全性上下文，例如证书、标识符等。通信会话可以作为网络协议栈中的各个层的协议和服务的一部分来实现。作为例子，图1示出了在传输协议层、应用协议层、应用服务层的网络节点之间以及在应用之间建立的通信会话。
机器对机器(M2M)服务层是专门针对为M2M类型的设备和应用提供增值服务的一种类型的应用服务层的示例。例如，M2M服务层可以支持应用编程接口(API)，API提供应用和设备访问由服务层支持的一系列M2M中心功能。示例能力包含但不限于安全性、收费、数据管理、设备管理、发现、供应和连接管理。图2描述了由oneM2M规范指定的公共服务功能(CSF)。
参考图2，所示功能(能力)经由利用由M2M服务层定义的消息格式、资源结构和资源表示的API来提供给应用。M2M网络技术标准化的发展趋势已成为M2M服务层的标准化。M2M服务层的标准化示例包含各种oneM2M规范。
M2M服务层会话是指在M2M服务层实例与M2M应用或另一M2M服务层实例之间建立的通信会话。M2M服务层会话可以由与连接性、安全性、调度、数据、上下文等相关的M2M服务层状态组成。此状态可以由M2M服务层、M2M应用或其组合来维护。M2M服务层会话可以被层叠在一个或多个下层较低层通信会话之上。这样做，可以在不同会话之间共享和利用会话状态(例如，安全性证书、拥塞信息等)。另外，M2M服务层会话可以支持关于较低层会话的持久性，使得M2M服务层会话可以保持并独立于正在建立和拆除的较低层会话来维护。M2M服务层会话可层叠在其上的较低层会话的示例包含但不限于应用协议层会话(例如HTTP或CoAP)和传输协议层会话(例如TCP和/或UDP)，其可以使用例如传输层安全性(对于TCP为TLS)或数据报传输层安全性(对于UDP为DTLS)的协议来保证。
对于当前针对oneM2M服务层安全性的方法，当oneM2M端点以安全方式相互通信时，节点和中间节点之间以逐跳的方式建立安全性关联。每一跳(hop)可以具有独立于其它跳的单独的安全性关联。可以借助于对称密钥，通过使用证书/原始公共密钥，或通过可以由直接过程执行或通过使用设备制造商或服务提供商的服务远程地执行的引导(bootstrapping)过程建立逐跳安全性关联。此外，根据oneM2M安全性解决方案的当前版本，即一个M2M-TS-0003安全性解决方案，“在服务层级，安全性关联建立导致TLS或DTLS会话，其保护在相邻的AE/CSE，即逐跳之间交换的消息。”
图3示出使用对于所涉及的两个通信实体独特且机密的证书借助(D)TLS安全关联的实体之间的逐跳(HbH)安全性关联的示例。如图所示，第一应用实体(AE1)和第一托管公共服务实体(HCSE1)基于由两个实体(AE1、HCSE1)共享的HbH证书(H1)建立安全的(D)TLS连接。类似地，HCSE1和中间节点(IN-CSE1)已经使用H2证书建立了安全的(D)TLS连接。如图所示，使用证书H3建立IN-CSE与第二HCSE(HCSE2)之间的(D)TLS连接，使用证书H4建立第二AE(AE2)与HCSE2之间的安全连接。
仍然参考图3，如果HCSE1想要传送信息给AE2，则首先通过HCSE1与IN-CSE之间的(D)TLS连接来发送信息。所述信息接着在由(D)TLS应用解密后被提取，然后在服务层进行处理，并通过IN-CSE与HCSE2之间的单独的(D)TLS隧道进行重新打包发送。HCSE2处理消息，然后通过HCSE2与AE2之间的不同安全隧道重新传送消息。如图示的示例所示，任何两个HbH实体之间的通信由(D)TLS来保证，因此，可能难以侵犯在实体之间传输的消息的保密性或完整性，因为它们受到(D)TLS连接保护，但是，这些消息在转发到下一跳之前在服务层(SL)正在处理的实体处可能不会受到保护。
现在转向对象安全性措施，对象安全性措施已经在IETF中进行研究和标准化，并且针对各种单点登录解决方案(例如，OpenID)实施。正如IETF RFC 7165“JSON对象签名和加密的用例和要求”所述，“除了网络层或传输层的安全性机制之外，许多因特网应用还需要基于对象的安全性机制。多年来，密码消息语法(CMS)已经提供了基于ASN.1的二进制安全对象格式。随着时间的推移，诸如ASN.1之类的二进制对象编码已经不如基于文本的编码(例如JavaScript对象标注(JSON))那么普遍了。在1)针对完整性/真实性的JSON Web签名，IETF–RFC 7515；2)针对保密性的JSON Web加密，IETF–RFC 7516；3)针对证书表示的JSONWeb密钥，IETF–RFC 7516；以及4)针对算法的JSON Web算法，IETF–RFC 7518中指定了基于JSON的不同的安全性方面。
如上所述，例如，针对oneM2M网络中的安全性的现有方法是受限的。例如，只有内容在相互信任的实体之间传输(非静止)时，内容才可能受到保护。
发明内容
提供本发明内容部分是为了以简化的形式介绍将在以下具体实施方式中进一步描述的一些概念。本发明内容部分不是要标明所要求保护的主题的关键特征或基本特征，也不想限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决本公开的任何部分中提到的任何或全部缺点的限制。
这里解决诸如上述问题的各种缺点。在一个实施例中，保护M2M网络中的内容的完整性和保密性。这样的内容可以是“静止的(at rest)”，使得内容存储于节点或装置处。
在一个实施例中，例如应用实体的装置发送对提供内容保护的一个或多个证书的请求。所述请求可以基于与内容相关联的一个或多个安全性参数。所述装置可以获得一个或多个证书，并使用一个或多个证书来保卫内容。证书可以包括用于对称密钥保密性保护的主密钥。证书可以包括用于完整性保护和保密性保护的证书。所述装置可以加密内容以建立加密的内容。所述装置可以生成与内容相关联的鉴权标签。此外，所述装置可以向托管公共服务实体发送建立含有安全内容和安全性参数的资源的请求。根据一个示例，可以从信任启用功能(例如M2M登记功能)获得证书。托管公共服务实体可能只允许被授权应用建立资源，且托管公共服务实体可能只允许被授权应用检索加密的内容。
在另一实施例中，基于一个或多个安全性要求，所述装置确定一个或多个加密参数。所述装置还可以向内容托管功能发送安全托管请求消息，所述安全托管请求消息可以包含一个或多个加密参数和与其相关联的内容，使得内容托管功能可以使用一个或多个加密参数安全地存储内容。基于一个或多个加密参数，所述装置可以加密内容，使得内容是机密的。在示例中，内容可以由子成分构成，并且节点基于一个或多个加密参数来加密每个子成分，使得每个子成分都是机密的。在另一示例中，内容可以由属性-值对组成，并且节点可以基于一个或多个加密参数对每个值进行加密，使得每个值是机密的。节点还可以计算与内容相关联的鉴权标签，使得内容受到完整性保护。
附图说明
为了促进对本申请的更强的理解，现在参考附图，其中相似的元件用相似的附图标记表示。这些附图不应被解释为限制本申请，而仅仅是说明性的。其中
图1是示出在网络节点之间建立的各种通信会话的示例的图；
图2是示出由oneM2M指定的公共服务功能的图；
图3是示出oneM2M节点以逐跳方式彼此建立安全性关联的示例的调用流程；
图4是示出示例用例的调用流程，其示出了利用网络中的漏洞的恶意实体的示例，所述网络包含应用实体(AE)、托管公共服务实体(HCSE)和中间节点公共服务实体(IN-CSE)；
图5是示出攻击者可利用IN-CSE或HCSE处的漏洞的另一示例用例的调用流程；
图6是描绘根据示例实施例的示例功能和其间的交互的调用流程；
图7描绘包含由成分和子成分组成的内容的示例内容；
图8描绘与示例内容相关联的示例加密参数；
图9描绘与示例内容相关联的示例的客户端专用的加密参数；
图10是示出根据示例实施例的在内容建立和安全性确定功能(CCSDF)和不可信任的内容托管功能(CHF)之间的示例消息传送的调用流程；
图11是示出根据示例实施例的在CCSDF与安全内容托管功能(SCHF)之间的示例消息传送的调用流程；
图12是根据任何示例实施例的用于确定托管内容的位置的示例流程图；
图13示出根据示例实施例的存储在受保护内容存储库(PCS)内的示例受保护内容结构；
图14描绘与内容相关联的示例加密参数；
图15是描绘根据示例实施例的内容专用证书申请的调用流程；
图16是描绘根据示例实施例的客户端专用证书申请的调用流程；
图17是描绘根据示例实施例的内容专用的证书注册的调用流程；
图18是描绘根据另一示例实施例的客户端证书申请的调用流程；
图19是描绘根据示例实施例的第三方证书申请的调用流程；
图20是根据示例实施例的内容检索的调用流程；
图21是示出根据示例实施例的可以由客户端执行的示例安全性核查的流程图；
图22是以本文描述的示例安全功能性示出的来自图2的图；
图23是具有本文描述的示例安全功能的公共服务功能(CSF)的图示；
图24是示出其中内容被表示为oneM2M资源的示例实施例的调用流程；
图25示出根据示例实施例的在CSE处建立的证书标识资源的示例结构；
图26是示出服务启用功能(SEF)驻存于CSE的另一示例实施例的调用流程；
图27示出根据示例实施例的在信任启用功能，特别是机器对机器(M2M)登记功能(MEF)中建立的证书标识资源的示例结构；
图28描绘根据示例实施例的示例访问控制政策的示例结构；
图29示出根据示例实施例的对于受保护内容的示例资源结构；
图30示出根据示例实施例的示例加密参数资源；
图31示出受到完整性保护的管理对象的示例；
图32示出示例安全性政策资源；
图33示出根据示例实施例的可以在CCSDF处提供的示例图形用户界面(GUI)；
图34示出根据示例实施例的可以在SCHF处提供的示例GU；
图35示出根据示例实施例的可以在SEF处提供的示例GUI；
图36A是其中可以实现一个或多个所公开的实施例的示例机器对机器(M2M)或物联网(IoT)通信系统的系统图；
图36B是可以在图36A所示的M2M/IoT通信系统内使用的示例架构的系统图；
图36C是可以在图36A所示的通信系统内使用的示例M2M/IoT终端或网关设备的系统图；
图36D是其中可以体现图36A的通信系统的各方面的示例计算系统的框图；
图37是示出针对资源特定的内容保护的示例实施例的调用流程；以及
图38是示出针对客户端专用的内容保护的示例实施例的调用流程。
具体实施方式
如上所述，针对M2M网络中的安全性的现有方法是受限的。例如，在oneM2M中，内容可能仅在借助于传输层协议(例如，TLS/DTLS)在两个“可信”实体之间“传输”时受到保护。因此，内容在托管于实体时(静止)不受保护。其含义是，内容(对象)保护如果完全执行则必须在应用层完成。这里应认识到，存在与应用内容保护方法相关的问题。例如，应用不提供应用内容保护的统一机制。而且，服务层资源本身不受保护。而且，如果存在应用层保护，则它们可能只提供实际的应用数据保护，而不提供与服务层(SL)相关联的资源。在此进一步认识到，必须针对应用内容保护方法执行用于保护内容的单独的应用层协议，这可能是麻烦的。在某些情况下，为了使服务层能够提供增值服务，内容可能必须处于其未加密的形式。在此还认识到，与oneM2M资源相关联的安全性证书和安全保护的生命周期管理当前并未执行。目前尚未解决处理废弃实体上托管的数据安全性的机制。
如本文所使用，术语“服务层”是指网络服务体系结构内的功能层。服务层通常位于应用协议层(如HTTP，CoAP或MQTT)之上，并为客户端应用提供增值服务。服务层还提供到较低资源层(例如控制层和传输/访问层)的核心网络的接口。服务层支持多种类型的(服务)能力或功能，包含服务定义、服务运行时支持、政策管理、访问控制和服务集群。最近，多个行业标准组织(例如oneM2M)一直在开发M2M服务层以解决与将M2M类型的设备和应用集成到诸如因特网/Web、蜂窝、企业和家庭网络的部署相关的挑战。M2M服务层可以向应用和/或各种设备提供对由服务层支持的一批或一组上述能力或功能的访问，其可以被称为CSE或SCL。一些示例包括但不限于安全性、收费、数据管理、设备管理、发现、供应和连接管理，这些可以由各种应用共同使用。通过利用由M2M服务层定义的消息格式、资源结构和资源表示的API，这些能力或功能对此类各种应用可用。CSE或SCL是这样的功能实体，可以由硬件和/或软件实现，并且提供针对各种应用和/或设备(例如，此类功能实体之间的功能接口)的(服务)能力或功能以便它们使用这样的能力或功能。
为了进一步说明当前的oneM2M解决方案相关的问题，例如，图4和5示出了各自的使用情况。在图4中，显示了对数据/内容隐私的影响，并且图5示出了与没有数据/内容完整性保护和鉴权相关的问题。
具体参考图4，网络400包含四个示例实体：第一应用实体(AE1)、托管公共服务实体(HCES1)、中间节点CSE(IN-CSE)，以及恶意实体，其可能是黑客应用或非恶意功能。在402，AE1在服务层的HCSE1内建立资源，所述服务层存储属性和内容/内容实例。在这个用例中，提供了两个属性作为示例：属性1和属性2。根据示例，在执行402的“建立资源”操作之前，AE1和HCSE1已经彼此相互鉴权并且已经使用安全的通信信道。在某些时刻，在404，恶意实体(如黑客应用)通过IN-CSE利用HCSE1内的漏洞。在某些情况下，黑客应用可能无需通过IN-CSE即可到达HCSE1。在其它情况下，由于IN-CSE上的协议支持(例如，运行的开放端口和服务)的多样性，它可能通过可能利用IN-CSE上的漏洞而成为黑客应用的良好切入点。一旦黑客能够访问HCSE1，它就在步骤406窃取存储于AE1资源内的内容。这可能是典型的攻击，而不需要太高级的技巧。缓解这种攻击的一种方法是加密整个磁盘或者在每个文件的基础上使用加密。然而，内容可能必须在SL处进行处理，并且在通信路径上的传输节点处被解密，因此内容变得易受攻击。另一种缓解技术是使用基于JSON的对象签名和加密机制来保护内容。但目前还没有框架能够使用这种机制来保护SL资源。另一个问题是HCSE1的平台不可信，因此可能无法执行安全的流程。而且，如果根密钥被破解，它将暴露存储于HCSE1上的所有AE的数据。简而言之，应用数据或用户的机密数据的安全性被卸载到用户或应用无法控制的实体，并且平台的可信性是基于用户对SP的信任。另外，当HCSE1被解除委托时，数据可以保留在HCSE1中，并且仅通过基于文件的加密来保护，这可能容易用保护资源的过时操作系统来破解。
因此，总而言之，图4的用例示例性但非限制性地示出，在内容处于静止时在托管实体(例如HCSE)处缺乏保密机制，缺乏隐藏内容甚至对HCSE(例如，不太可靠的HCSE)隐藏内容的机制，因此在将内容传送到客户端时，一旦数据通过TLS/DTLS隧道到达，每一跳(如传输CSE)具有对内容的未加密访问，并且在内容的生命周期中缺乏定期重新循环内容安全性的能力。
现在参考图5所示的用例，网络500包含生成内容的第一应用实体(AE1)、作为消费AE1产生的内容的客户端应用的第二AE(AE2)和第三AE(AE3)。网络还包含托管CSE(HCSE1)和中间节点CSE(IN-CSE)。在示例中，内容托管在HCSE1上，没有任何完整性保护。类似于图4所示的示例用例，攻击者可能利用IN-CSE或HCSE1上的漏洞。在1处，AE1在HCSE1建立资源。例如，攻击者可以在2和3处修改资源和/或资源结构(例如，属性和/或内容)。如图所示，图5示出了攻击者能够对被称为属性1的AE1的属性进行未授权的修改。订阅AE1的资源的AE2在4和5处获得资源的修改副本。在某些情况下，例如，当从AE1获得的资源被AE2用来进行关键决策或操作时，修改可能有重大影响。在6和7处，根据所示的示例，攻击者删除属性2并添加新的属性(属性3和属性4)。因此，在示例中，攻击者不仅要改变资源，还要改变资源的结构。订阅资源的AE3则具有与AE1建立的资源树完全不同的资源树。因此，如图5的示例用例所示，当前的安全性方法可能不对资源提供完整性保护，不对资源的结构提供完整性保护，和/或不对系统关键资源提供完整性保护。
本发明解决诸如上述问题的各种缺点。在一个实施例中，内容的完整性和保密性受到保护。如本文中所使用，除非另外说明，否则术语“内容”是指由机器控制的或人工控制的客户端应用或服务功能(例如，固件、配置参数、政策、上下文、文档等)产生或消费的任何数据。因此，术语“内容”和“数据”在本文中可以互换使用而没有限制。内容可以呈其最原始的形式(例如，温度读数、其它传感器读数等)。在一些情况下，内容可以是具有与其关联的附加元数据的原始数据，或者可以是原始数据和具有元数据的原始数据的组合。内容还可以指代各种信息，例如机器可执行内容(例如，计算机程序、二进制代码、可能已经被编译或解译的可执行机器代码、计算机程序脚本等)、计算机相关配置参数、操作政策(如安全性或服务政策)、多媒体内容(如视频、音频等)、文件，或可能具有特定货币价值、战略价值或知识价值的任何内容。内容也可以被称为对象。
如本文所使用，除非另外说明，否则“鉴权(authentication)”是指建立与实体相关联的标识的置信度的过程。“保密(confidentiality)”通常是指确保只有被授权实体才能够查看数据的过程。如本文所使用，除非另外说明，否则“实体”或“节点”可以指应用、应用的子集、服务启用功能或设备(例如传感器设备)。本文描述的各种技术可以结合硬件、固件、软件或者在适当的情况下其组合来实现。此类硬件、固件和软件可以驻存于位于通信网络的各个节点处的装置中。装置可以单独操作或者彼此组合以实现本文描述的方法。如本文所使用，术语“装置”、“网络装置”、“节点”、“设备”、“实体”和“网络节点”可以互换使用。术语“完整性(integrity)”可以指建立消息或系统没有被未授权实体改变的置信度的过程。物联网(IoT)通常指可唯一识别的对象及其虚拟表示，其可以连接到因特网。如本文所使用，术语生命周期管理是指通过供应、维护和停运阶段来管理与其相关联的数据和证书的机制。
本文使用各种M2M术语。M2M服务层一般是指通过一组应用编程接口(API)和下层网络接口为M2M应用和设备提供增值服务的软件中间件层。M2M服务层跳是指两个M2M服务层之间或M2M服务层与M2M应用之间的M2M服务层通信会话。M2M服务层会话是指在两个或更多通信实体之间建立的通常是有状态的消息交换。如本文所使用，除非另外说明，否则M2M服务层会话端点是指可以是M2M服务层会话通信的源或目的地的逻辑实体。此外，如本文所使用，除非另外说明，否则M2M服务层会话管理器是指为M2M服务层会话管理提供服务的逻辑实体。临时交互号是指可以与会话相关联并且其有效性可以与会话/时间分量相关联的随机值。
通过介绍，这里定义了各种功能和处理机制来实现对内容的安全保护。应该理解，出于示例的目的而命名各种功能，并且可以根据需要来替代地命名功能。内容建立和安全性确定功能(CCSDF)如下所述。CCSDF可以由多个功能组成，并且托管在相同的实体(节点)上，或者分布在可驻于不同管理域上的多个实体(节点)上。内容建立功能(CCF)可以基于收集的数据建立内容。在一些情况下，内容可以是原始数据或信息，并且内容可以包含传感器数据或根据原始数据建立的信息。CCF可以基于内容的子成分来建立内容结构和某种形式的内容结构。安全性确定功能(SDF)可以负责确定与内容相关的安全性要求。SDF可以确定为保护内容所需的安全性等级。例如，SDF可以基于建立的政策来确定内容保护的一般安全性要求。
本文描述了安全内容托管功能(SCHF)。在示例实施例中，SCHF是安全地托管内容的功能。SCHF也可以用作安全政策强制实体并执行访问控制核查。SCHF可以处理、识别并执行必要的加密过程，使能够保护内容。SCHF可以与安全启用功能(SEF)交互以请求和注册适当的证书。在一个实施例中，SEF是提供用于保护和/或访问内容的证书的启用功能。例如，SEF可以作为可信第三方(TTP)的可信中介，以便为客户提供对内容的访问。SEF可以提供并注册适当的内容专用的证书。SEF可以提供并注册适当的客户端专用的证书。
下文根据示例实施例描述安全性参数确定过程(SPDP)。作为示例SPDP的一部分，针对“静止”的特定内容确定正确的安全性参数集。另外，还可以确定内容的生命周期管理。例如，可以查询与静止的内容安全性相关的安全政策。可以处理这些政策从而导出适当的安全性参数。还可以确定和导出生命周期管理参数。
在示例实施例中，CCSDF可以发起安全托管申请过程(SHRP)。在一些情况下，SHRP也可以由SCHF发起。作为申请的一部分，CCSDF可以要求用SCHF安全地托管内容。SCHF可以是零跳(托管于同一平台上)、距离CCSDF一跳(通常优选的方法)或距离CCSDF多跳(两跳或更多跳)。SHRP允许基于一定的信任程度来发现SCHF。在示例实施例中，可以基于安全性要求来请求内容的托管。根据一个实施例，SCHF可以托管安全内容。
下文描述证书申请和注册过程(CRRP)，其可以包含证书申请过程(CQP)和证书注册过程(CGP)。在CQP期间，SCHF可以请求提供用于安全存储内容的适当证书。例如，此过程可以是可选的，因为在某些情况下，SCHF为内容生成适当的证书就足够了。在客户端专用的内容将被保护的示例中，SDP可以请求客户端的证书。例如，可以请求与特定内容相关联的证书。作为进一步的示例，可以基于算法和证书类型来请求证书。也可以要求特定于客户端的证书。作为示例CGP的一部分，用于保护内容的证书集可以与SEF一起发布。例如，出于可扩展性的原因，可以在多个SEF处发布证书。CGP可以提供请求注册与内容相关联的所生成证书的能力；指定待使用的算法、证书类型、可以如何使用证书的机制以及与证书相关联的访问控制政策(ACP)的能力；以及注册供客户端使用的证书的能力。
本文描述了示例安全托管过程(SHP)。作为此过程的一部分，SCHF可以基于来自CCSDF的SHRP消息而托管内容。通过包含用于保存内容的容器/属性的正确集合，内容可以用CCSDF要求的适当格式进行托管。替代地或另外，SCHF可能必须执行适当的加密操作以安全地托管内容。执行的加密操作的类型可以基于与内容相关联的安全性参数。SCHP可以获得并执行适当的加密处理以保护内容。此外，基于SHRP消息，SCHF可以建立被触发的适当的生命周期管理过程，以便更新与内容相关联的安全属性。例如，可以删除内容或使得内容无法访问。
本文描述示例第三方证书申请过程(TPCRP)。在某些情况下，SEF可能必须授权客户端并为其提供必要的证书，以便客户端(第三方)能够访问资源并验证其真实性。TPCRP可以允许任何实体(例如，客户端)基于与内容相关联的标识(内容标识)向SEF或向SCHF请求证书。在示例内容检索过程(CRP)期间，客户端发起请求访问内容的机制。客户端可以从预先配置的信息中获得有关SCHF的信息，或者可以使用DNS-SD或RD动态地发现信息。可以检索安全内容(加密的和/或受到完整性保护的)，包含必要的加密参数。本文还描述内容处理(CP)。在CP期间，想要访问内容的客户端可能希望验证内容的真实性和/或完整性。此外，客户还可能希望验证与内容相关联的内容结构和属性。在一个示例中，客户端可以验证内容的真实性/完整性、内容的子成分以及内容的结构。可以基于提供的加密参数来解密内容。
在示例内容生命周期管理过程(CLMP)中，CCSDF可以任选地发送显式CLMP消息来更新特定内容的生命周期管理。如果作为SHRP的一部分，CCSDF传达了明确的生命周期管理要求，则可以跳过此过程/消息传送。可以刷新证书并且可以周期性地执行加密操作。可以基于解除托管期限清除内容。可以管理与内容相关联的证书，使得重新提供、重新保护或者临时地或永久地移除证书。
总体参考图6，为了抵消上述的各种缺点，如本文所述的那样启用对内容/数据的保护。如本文所述，对数据的保护可以包含确保请求访问数据的实体已经被授权访问数据(也可以包含鉴权)。对数据的保护可以包含对未经授权的实体隐藏(例如，加密)数据，并且对于未经授权的实体而言看起来是不透明的。对数据的保护可以包含检测数据的未经授权的修改。对内容的保护可以包含定期或永久管理内容的生命周期。
在一个实施例中，从子成分(如果需要)建立内容，并且可以基于子成分建立内容的结构。这可以由CCP执行。SDF可以通过评估其子成分的安全性要求对内容保护的安全性要求进行风险评估。在实施例中，识别保护静止内容所需的适当的安全性参数。这可以通过使用SPDP来实现。CRRP可以获得或生成证书，并注册用于内容保护的证书。在示例实施例中，使用SHP以安全的方式托管内容。如本文中所描述，TPCRP可以提供用于向被授权的第三方供应证书以访问内容的能力。
虽然以下描述主要集中于内容的保护，但是将理解，本文描述的证书可以适当地定制，以保护由各种服务启用功能建立、更新、删除和检索的系统资源。
图6-35、37和38(在下文中描述)示出了用于保护内容的方法和装置的各种实施例。在这些图中，示出了由一个或多个节点或装置执行的各种步骤或操作。可以理解的是，这些图中示出的节点和装置可以表示通信网络中的逻辑实体，并且可以用存储于此类网络的节点或装置的存储器中以及执行此类网络的节点或装置的处理器的软件(例如，计算机可执行指令)的形式来实现，其可以包括下文描述的图36A或36B中所示的一般体系结构之一。也就是说，图6-35、37和38中所示的方法可以用存储于网络节点或装置(例如图36C或36D所示的节点或计算机系统)的存储器中的软件(例如，计算机可执行指令)的形式来实现，所述计算机可执行指令在由节点或装置的处理器执行时执行图中所示的步骤。还应理解，这些图中示出的任何传输和接收步骤可以通过节点或装置的通信电路(例如，分别是图36C和36D的电路34或97)在节点或装置的处理器和其执行的计算机可执行指令(例如，软件)的控制下实施。
下文描述可以用软件实现并且连同托管于如用户设备(UE)或服务器上的其它应用一起驻存于实体上的示例功能。这些功能可以驻存于专用硬件实体上，因此贯穿本文，功能、实体、装置和节点这些术语可以互换使用，没有限制。例如，客户端可以是驻存于用户设备上的应用或服务。客户端也可以指驻存于机器上的应用或服务、专用硬件或基于云的应用或服务。客户端也可以是一组应用或服务的一部分，这些应用或服务在平台内或在不同平台上以分布的方式一起工作。客户端通常发起请求以访问内容。客户端发送请求以访问内容的触发器可以由用户、机器、应用或服务发起。
参考图6，内容建立和安全性确定功能(CCSDF)可以由多个功能组成，并且托管于同一个实体(节点)上，或者跨实体(多个节点)分布，这些实体也可以驻存于不同的管理域上。如果这些功能驻存于不同的管理域中，那么在执行事务的功能所在的各个实体之间可能存在信任关系。CCSDF可以是生成内容或使用数据源(例如传感器)来建立内容的实体。在一些情况下，CCSDF和SCHF可以共同托管在同一物理实体(例如，服务器、网关)上。在一个实施例中，内容建立功能(CCF)涉及从各种来源(例如传感器、应用、数据库等)收集数据并建立内容。可以由传感器和应用主动收集或发布数据。CCF负责管理内容建立过程。安全性确定功能(SDF)可以负责确定与内容相关的安全性要求。SDF可以确定为保护内容所需的安全性等级。在本公开中，确定当内容“静止”时与内容相关联的安全性要求。也就是说，本文描述了关于存储的内容安全性的安全性要求和管理。如上所述，CCF和SDF可以在同一节点/实体上执行，或者这些功能可以驻存于不同的节点/实体上。
安全内容托管功能(SCHF)可以托管内容。SCHF也可以用作安全政策实施实体并执行访问控制核查。在一些情况下，SCHF必须具有执行与内容相关联的安全操作(例如，安全政策强制)的必要能力(例如，功能性、计算资源)，并且还具有以安全方式托管内容的资源。安全启用功能(SEF)可以提供用于保护和/或访问内容的证书。SEF可以作为可信中介，例如可信第三方(TTP)，以便为客户端提供内容访问。SEF可能够提供对称证书以及公钥证书。它也可以用作外部鉴权机构(CA)或与外部CA相连接。
如图6所示，涉及提供内容安全性的过程可以被分类为下文标识的各种过程。例如，作为示例内容建立过程(CCP)的一部分，内容的子成分用于建立具有一定关系和结构的组合的内容。示例内容可以由一个或多个属性-值对组成，其中每个属性-值对是子成分。作为示例安全性参数确定过程(SPDP)的一部分，针对“静止”的特定内容确定正确的安全性参数集。另外，还确定内容的生命周期管理。可由CCSDF或SCHF发起安全托管申请过程(SHRP)。在一个示例中，作为请求的一部分，CCSDF请求在SCHF上安全地托管内容。SCHF可以是零跳(托管于同一平台上)、距离CCSDF一跳(通常优选的方法)，或多跳(距离两跳或更多跳)。在CCF、SDF和SCHF实施于同一节点/实体上的示例中，可以在节点/实体内部执行步骤0、1和2，因此可以使用进程内通信执行功能之间的通信。
在示例实施例中，证书申请和注册过程(CRRP)可以包含证书申请过程(CRP)和证书注册过程(CGP)。在CRP期间，SCHF可以请求提供用于安全存储内容的适当证书。此过程可以是可选的，因为在某些情况下，SCHF为内容生成适当的证书就足够了。在客户端专用的内容将被保护的示例中，CCSDF/SDP可以请求客户端的证书。作为CGP的一部分，可以使用SEF发布用于保护内容的证书集。出于可扩展性原因，可以在多个SEF处发布证书。在某些情况下，如果CCSDF能够自行生成证书，那么CCSDF可以只执行CGP。但是，在其它情况下，如果CCSDF无法生成适当的证书，则必须执行完整的CRRP过程。作为示例安全托管过程(SHP)的一部分，SCHF可以基于来自CCSDF的SHRP消息来执行对内容的托管。这里的一个假设是，CCSDF可能已经执行了必要的加密操作，因此内容受到保护，并且基于来自CCSDF的指令，SCHF适当地托管内容。或者，SCHF可能必须执行适当的加密操作以便安全地托管内容。执行的加密操作的类型可以基于与内容相关联的安全性参数。基于SHRP消息，SCHF可以建立适当的生命周期管理过程，所述过程将不得不被触发以更新与内容相关联的安全性属性，并任选地删除内容或使其不可访问。
现在转向第三方证书申请过程(TPCRP)，为了使第三方(例如客户端)访问资源，SEF可能必须授权客户端并为其提供必要的证书，使客户能够解密内容和/或验证内容的完整性/真实性。TPCRP可涉及鉴权和授权以及向第三方(例如客户端)的证书分发。在示例内容检索过程(CRP)中，客户端发起访问内容的请求。客户端可以从预先配置的信息中获得关于SCHF的信息，或者可以使用DNS-SD或RD动态地发现信息。在内容处理(CP)的示例中，想要访问内容的客户可能希望验证内容的真实性和/或完整性。此外，客户端还可能希望验证与内容相关联的内容结构和属性。在保护内容的保密性的情况下，可以作为加密内容发送内容，并且在通过SCHF将内容发送给客户端之前可以解密内容。确定内容是否必须由SCHF解密可以基于与内容相关联的政策和安全性要求。
作为示例内容生命周期管理过程(CLMP)的一部分，CCSDF可以任选地发送显式CLMP消息来更新特定内容的生命周期管理。如果作为SHRP的一部分，CCSDF传达了明确的生命周期管理要求，则可以跳过此过程/消息传送。如果SCHF的本地政策已经预先配置为处理内容的生命周期管理，则也可以跳过此过程/消息传送。SCHF处的政策可以确定必须执行的必要操作，以便更新与内容相关的安全性属性，例如删除或使内容对任何实体不可用。
现在将详细讨论内容建立过程(CCP)。作为此过程的一部分，可以通过CCF使用由数据收集器收集的原始数据(例如，传感器数据)，以建立待用特定结构存储的内容。作为CCP的一部分，根据示例实施例，使用内容的子成分来建立具有特定关系和结构的组合的内容。示例内容可以由一个或多个属性/值对组成，其中每个属性/值对都是子成分。如上所述，为了方便起见，数据或信息或内容通常可以被称为内容，没有限制。内容可以通过全球独特资源标识符来识别，或者可以是本地可识别的。内容可以由在子成分之间具有特定关系结构(例如，分层的或平的网络)的一个或多个子内容(子成分)组成。图7中示出具有其子成分或属性的内容示例。图7描绘具有内容标识符“ABC”并由成分A、成分B和成分C这三个成分组成的内容。成分C又由子成分X和子成分Y这两个子成分组成。
现在转向安全性参数确定过程(SPDP)，根据示例实施例，在SDPD期间，可以是CSSDF的一部分的SDF确定为了保护“静止”的内容所需的适当的安全性要求和参数。如前所述，在CCSDF能够自行生成证书的情况下，CCSDF可以只执行CGP。替代地，如果CCSDF无法生成适当的证书，则可能必须执行完整的CRRP过程。作为确定过程的一部分，CCSDF可以确定，例如但不限于：
·是否必须保护内容防止窃听(保密性/隐私保护)
o保护等级：算法强度、证书类型/大小
·防止未经授权的内容修改-完整性保护
o保护等级：算法强度、摘要/签名长度
·更新保护机制的能力
·安全存储证书/安全操作环境的要求
·与内容相关的终身安全管理
表1：与内容相关的高级安全性要求和参数的示例
上面表1中示出了与内容XYZ(由XYZ-Id标识)、ABC和MNO相关联的高级安全性参数的示例。每个内容都与其相应的安全参数相关联。例如，如图所示，内容XYZ具有“高”的保密性要求，并且要求使用的密钥大小至少为200位。证书强度可以基于加密类型(例如，对称密钥)，因此可以适当地使用用于其它加密类型(例如，公钥)的等效密钥大小。在某些情况下，考虑到内容可能托管于受约束的实体上，可能存在对证书强度的最大大小限制。如所示，示例完整性保护算法是“中等”，并具有>＝256位的MAC长度。内容不必使用安全的环境。关于生命周期管理，根据图示的示例，在10年后内容可被清除或不可访问，并且可以每3年更新一次安全保护。表中仅举例说明了内容保护的可能的高级安全性要求的示例。应理解，为了适应特定的实施方案，可以增加或删除额外的需求。例如，对于某些类型的内容可能不存在与生命周期管理相关的要求。
例如，基于CCF上的本地政策或由内容拥有者/服务提供商提供的政策，可以由SDF处的过程来触发SPDP。基于对某些内容的请求，用于触发SPDP的机制可以是主动的或被动的。可以使用安全特定的政策来执行SPDP，这些政策是基于保护具有国家安全意义或商业价值的敏感数据/内容的最佳实践来提供或实施的。表2给出了SPDP使用的政策的简化示例，但是可以理解，政策可以根据需要改变。
表2：对于SPDP的示例政策
安全值 保密性 完整性 安全环境 生命周期管理
低 低 中 无 无
中 中 高 无 有
高 高 高 有 有
在一些情况下，内容可能由子成分组成，每个子成分都有自身的标识，或者可能存在与内容相关的属性/值。每个子成分或属性/值可以有其自身相应的安全要求。因为所有的子成分(例如，属性/值)被单独保护，所以可以保护整个内容(例如，完整性保护)。
在示例实施例中，SDF基于需求来确定适当的加密参数(CryptoParams)。如果CSSDF托管内容，则CCSDF可以为内容导出所需的安全值。图8描绘了与内容XYZ相关联的加密参数的示例。图8描述了加密/解密算法：使用256位密钥的AES。可以使用密钥导出函数(KDF)生成所述密钥。示例KDF可以具有以下形式：加密秘钥(CK)＝KDF(KeyGenKey,“ContentID”||“RandomValue”||”ConfidentialityKeyGen”)。
可以使用例如密钥哈希消息鉴权码(HMAC-SHA)之类的KDF导出CK。输入参数可以包括由CSSDF用于生成其它密钥的密钥，这里可以将其称为KeyGenKey。另外，输入参数可以包含：可以被假设为在CCSDF的上下文中是独特的内容标识、由SDF生成的随机值，以及字符串“ConfidentialityKeyGen”。如上所述，应理解，CK的生成仅被用作说明目的的示例，并且输入参数可根据需要进行改变以减少冲突。
仍然参考图8，所选完整性/鉴权算法是具有相关联的完整性密钥(IK)的HMAC-SHA-256算法。可以使用与CK类似的方式导出IK，但是输入参数有变化。例如，生成新的随机值，并且可以用“IntegrityKeyGen”字符串替换“ConfidentialtiyKeyGen”。
在示例实施例中，内容被保护，使得只有特定客户端能够访问内容。此外，客户端可能够验证特定SDF已经建立了内容，而且有非常高的保证度所述内容没有被任何其它实体修改。例如，当使用客户端专用的内容保护机制时，使用客户端的数字证书来获得客户端的公钥并使用所述公钥来加密内容可能是优选的。图9描绘了客户端专用的加密参数的示例。如图所示，确定保密性算法是Rivest-Shamir-Addleman(RSA)公钥算法，并且确定密钥为客户端1的公钥，其可以从与客户端1相关联的数字证书中获得。为了获得客户端1的数字证书，例如如果SDF尚不具有数字证书，则可以执行下文描述的证书申请过程。根据示例，确定完整性(数字签名)算法为使用SHA-256摘要的RSA，要使用的签名密钥(IK)是与SDF的数字证书相关联的SDF的私钥，其优选地存储于安全存储装置中。临时交互号(nonce)，例如建立加密参数时的时间/日期、与内容相关联的内容标识和/或元数据，可以用作临时交互号。
在示例情境中，客户端可以是共享证书集的一群客户端。在此类情形中针对保密性使用公钥机制可能不太好，因为每个实体可能必须共享私钥，这会降低安全性。相反，在此情形中，可以针对保密性优选地使用对称密钥机制。或者，对于完整性/鉴权，公钥机制可能是优选的方法。因此，为了可扩展性且为了保持最佳性能，根据一个实施例，保密性算法可以基于对称密钥机制，并且可是使用公钥机制提供内容/内容生成器的完整性/真实性。在一些情况下，可以忽略内容的保密性，但验证内容/内容生成器的完整性/真实性。
例如，如果内容由子成分组成，则每个子成分可以具有其自己的安全参数以及与其相关联的相应的加密参数。例如，可以由属性-值对组成的内容和子成分可以具有它们自己的独特的加密参数。保护每个特定属性-值对所需的计算资源的数量可能是昂贵的，并且在许多情况下，可以保护整个组件而不是单独保护其各个组件。本文描述的机制可以用来从全局内容角度或者从更细粒度的属性-值对的角度来执行对内容的保护，其中与内容相关联的每个子成分可以具有不同的安全要求。应理解，可以使用针对算法和密钥的JWA和JWK使用JSON表示来表示加密参数。
现在转向示例安全托管申请过程(SHRP)，SCHF可以位于与CCSDF相同的实体(节点)上，并且因此SHRP消息可以在这种情况下在内部进行。在某些情况下，当CCSDF和SCHF位于不同的实体时，CCSDF可以用一个或多个SCHF发起SHRP。本文描述了具有单个SCHF的内容托管，然而，可以使用类似的机制托管多个SCHF。SHRP可以由以下子过程组成，例如但不限于安全值计算、发现合适的SCHF和消息传送过程。
关于计算安全值，可以基于作为上述SPDP的一部分确定的SDF和/或加密参数处的本地政策来计算必要的安全值。在某些情况下，安全值的计算可能被卸载到可信第三方(TTP)或SCHF。托管SDF的实体处的本地政策可以基于服务提供商政策、托管SDF的实体的能力(例如，受限设备、正确的固件/软件的可用性等)以及内容类型的组合。术语“保护值(PV)”在此用于表示计算出的安全值。计算出的PV的示例包含加密内容(EC)和鉴权标签(AT)。关于EC，可以对整个内容进行加密，或者可以基于与每个子成分相关联的加密参数对子成分或属性/值对进行加密。在某些情况下，只对属性/值对的“值”成分加密。AT是使用加密参数中针对所述特定内容指定的完整性参数对内容计算的完整性值。如前所述，内容的每个子成分可以具有其自身的独特计算出的AT。
在示例实施例中，通过使用例如AES-Galois模式(AES-GCM)等具有关联数据的鉴权加密(AEAD)机制来实现EC和AT二者。可以在加密参数中明确指定或通过SCHF推断AEAD的使用。可以使用单独的CK、IK或针对保密性和完整性而具有单个密钥来生成EC和AT。而且，在AES-GCM的情况下，AT可以是“额外的鉴权数据”。可以分别借助JWE和JWS使用JSON标注来表示EC和AT。
在示例实施例中，CCSDF可以执行发现过程以便确定托管其内容的正确SCHF。发现过程可涉及查询执行可用服务(例如，DNS-SD、RD)的活动列表的可信实体或其它实体。在一些情况下，CCSDF可以将发现过程卸载到本地托管实体，然后确定合适的SCHF。作为对查询的响应，可以向CCSDF提供关于SCHF的位置信息(例如，URI)或基于最符合安全性参数的特定标准排序的SCHF列表。如果高度可信的SCHF不可用，则可以通过CCSDF执行涉及PV计算的加密操作。如果发现了高度可信的SCHF，可以将PV的计算卸载到SCHF。
现在参考图10，根据示例，网络1000包含CCSDF 1002和执行与CCSDF 1002的安全托管申请(SHR)消息传送的SCHF 1004。应了解，示例网络1000被简化以便于描述所公开的主题，而不是要限制本公开的范围。可以使用其它设备、系统和配置来实现除了或替代例如网络1000的网络之外的本文所公开的实施例，并且所有此类实施例被认为是在本公开的范围内。基于由CCSDF 1002接收到的响应的类型，可以建立适当的消息并生成内容托管在SCHF 1004上可能需要的正确的参数集合。如果SCHF是较不可信实体，可以执行图10中描述的消息。
在步骤0，根据所示实施例，CCSDF 1002生成内容的适当的PV：EC和相关联的AT。在1，CCSDF 1002和所选择的SCHF 1004可以相互彼此鉴权并建立安全通信信道。在2，CCSDF1002向SCHF 1004发送安全托管(SH)请求消息，包含EC、相关联的AT和加密参数(CryptoParams)。在3，根据所示示例，SCHF 1004托管EC、AT和加密参数，并将它们存储在受保护的内容存储库(PCS)中。SCHF 1004可以任选地通过SEF张贴加密参数与内容标识，将在下文进一步描述。在4，一旦EC和PV被托管，就向CCSDF 1002发送可选地含有独特托管ID(H-Id)的成功消息，托管ID可以是指示EC以及AT和加密参数的位置的URI。EC可以托管在一个物理实体上，并且加密参数和AT可以位于不同的可信实体上。
现在参考图11，网络1100包含CCSDF 1102和作为可信实体的SCHF 1004，使得CCSDF 1102可以依赖于可信SCHF 1104来代表它执行加密操作，如图所示。根据示例，CCSDF1102仅向SCHF 1104提供内容和相关联的加密参数。在0处，根据所示示例，CCSDF 1102和SCHF 1104可以相互地彼此鉴权并建立与彼此的安全通信信道。在1处，CCSDF 1102发送SH请求消息，该SH请求消息含有内容(其未被保护)连同相关联的加密参数。另外，还发送指示子成分必须分别受完整性保护的Sub_I标志(Sub_I-flag)。由于SCHF 1104是可信的，并且因为消息是通过安全的通信信道发送的，所以内容和参数在“传输中(in transit)”被保护。如果SCHF 1104距离CCSDF 1102几跳，并且如果消息传送有效载荷要穿过不可信实体，则内容和加密参数必须使用端对端安全机制来保护。在2处，SCHF 1104使用内容上的加密参数来导出EC和相关联的AT。由于Sub_I-flag＝1，因此每个内容的各个子成分也受到完整性保护，并计算适当的AT值。SCHF 1104可以使用SEF的服务以便获得必须使用的证书的正确集合。如果要保护的内容是客户端专用的内容，则这可能是特别必要的。SCHF 1104可以将EC和AT存储在其上。示例安全托管过程的细节将在下文描述。在3处，SCHF 1104向CCSDF1102发送含有“成功”的SH响应。SCH 1104也可以任选地发送托管标识符。
因此，如图10和图11所示，节点(例如，CCSDF)可以包含处理器、存储器和通信电路。节点可以经由其通信电路连接到网络，并且节点还包括存储在节点的存储器中的计算机可执行指令，所述计算机可执行指令在由节点的处理器执行时使节点基于一个或多个安全性要求确定一个或多个加密参数。节点还可以发送安全托管请求消息到内容托管功能(CHF)。安全托管请求消息可以包含一个或多个加密参数和与其相关联的内容，使得内容托管功能可以使用一个或多个加密参数安全地存储内容。基于一个或多个加密参数，节点可以加密内容，使得内容是机密的。或者，内容可以由子成分组成，并且节点可以基于一个或多个加密参数来加密每个子成分，使得每个子成分都是机密的。或者，内容可以由属性-值对组成，并且节点可以基于一个或多个加密参数对每个值进行加密，使得每个值都是保密的。节点还可以计算与内容相关联的鉴权标签(AT)，使得内容受到完整性保护。替代地或另外，内容可以由子成分组成，并且节点可以计算与每个子成分相关联的相应的鉴权标签，使得每个子成分受到完整性保护。
图12示出可以由CCSDF执行以确定内容是否可以在本地托管或在代理服务器上托管的示例性机制。参考图12，根据所示示例，在1处，CCSDF对与内容相关联的安全性要求进行评估。安全性要求可能要求不允许内容在生成内容的实体或域之外进行。它也可能具有对可以托管内容的地理位置的限制(例如，在不同的县、州、国家等存储内容的限制)。还可以执行其它安全评估，例如执行某些安全性功能的效率和能力。在2处，CCSDF对内容是否可以托管在代理服务器上进行评估。在3处，如果内容可以托管在代理服务器上，CCSDF可以获得可能够托管内容的潜在的一个或多个SCHF的列表。CCSDF可能已经配置了以特定优先级排序的潜在SCHF列表，或其从TTP获得列表。在一些情况下，CCSDF可以通过使用发现服务的手段(例如，DNS-SD或oneM2M发现服务)以更加动态的方式发现SCHF。在4处，CCSDF确定SCFH是否符合或超出了内容的要求。在5处，根据所示示例，如果SCFH不符合内容的要求，则SDF确定内容是否可以在CCSDF上本地托管。在6处，如果内容可以在本地托管，则其触发SHP过程。否则，如果CCSDF不具备必要的安全功能(应用、软件、固件、硬件等)，可以中止安全托管过程。任选地，可以执行新的发现过程，或者可以基于更新的发现过程来托管具有较低安全性要求的修改的内容。
现在转向安全托管过程(SHP)，根据示例实施例，以符合安全性要求或与内容相关联的安全性配置文件的方式来处理内容。安全托管可以包含提供访问数据的强有力的鉴权机制、提供稳健的授权机制、提供数据的完整性，和/或提供数据的保密性。以安全方式托管数据的能力可以包括使用安全元素(SE)或可信执行环境(TEE)。在某些情况下，对于受限制的设备所涉及的开销(计算、内存、电池)可能过多。加密证书(例如，密钥/证书/标识)和/或敏感的加密功能可以在SE或TEE内执行。如果实体无法以安全的方式托管数据，则可以使用代理服务器来存储所述数据。信任根(RoT)的使用通常有益，但是本公开不作出关于存在基于硬件或软件的RoT的任何假设。
如上所述，SCHF可以驻存于离CCSDF一跳，或者可以离CCSDF多跳。跳数是指服务层跳数。CCSDF与SCHF可能有或没有直接的信任关系，但可能够建立在已建立的信任层次上，或使用共同的信任根来建立新的信任关系。保证CCSDF与SCHF之间的连接的端到端方法可能是优选的，但是，当端到端安全性机制不可用时，可以使用逐跳安全性。
在示例实施例中，实体可以基于与数据相关联的要求确定将数据本地存储在该实体托管于其上的设备。例如，如果实体确定托管实体能够以安全的方式托管数据，则其对数据执行必要的加密操作，使得数据受到完整性保护和/或受到保密性保护。可以使用适当加密算法和证书来保护数据。下表3提供了保密性保护的密码值的示例。
表3：保密性保护的可能值示例
安全级–保密性 算法 密钥长度 存储要求
低 3-DES 168位 无
中 AES 192位 FDE
高 AES 256位 基于文件
关键 RSA 4096 TEE/SE*
图13描绘了存储于PCS内的受保护内容的示例。图13示出了具有标识符ABC的内容，其具有A、B和C，并且成分C由子成分X和Y组成。基于加密参数和需要被保护的成分的指示，CCSDF计算与内容相关的EC和AT。使用可为独特的证书对成分A和B进行加密。然而，成分C本身可能不包含任何数据，并且可能不受保护，而子成分X、Y经过加密。成分A和B以及结构和整个成分C的完整性数据(AT)受保护(使用成分C-AT)，并且各个子成分X和Y受到保护。计算ABC-AT是为了完整保护内容“ABC”以及内容中的子成分及其关系/结构。
在某些情况下，保护机制繁琐且计算成本高昂，因此可能不适用于受限制的CCSDF。所以，一些操作可能被卸载到可信任的SCHF上。这里描述的用于按照粒度级别保护内容的机制为内容消费提供了很大的灵活性，同时提供了稳健的安全机制。仅被授权访问内容的子成分(例如，子成分X)的客户端可能够验证所述特定子成分的完整性(例如使用成分-X-AT)，而不具有关于其整体内容的任何信息。加密参数的选择和内容保护的粒度可基于正在实施的解决方案的类型(如由服务提供商确定)以及由平台确定的关于CCSDF的本地政策。
在另一示例实施例中，CCDSF可以决定将内容托管到SCHF驻存的代理服务器上。上述发现机制可用于发现安全代理服务器。在某些情境中，受限的CCSDF可能无法将内容托管到完全可信的代理服务器上，因为CCSDF可能无法到达可信的代理服务器。在这种情况下，CCSDF可能不向SCHF(代理服务器)提供加密参数，而是对存储于TTP(例如SEF)上的加密参数提供链接。在示例中，SEF只将加密参数提供给具有适当授权的实体。但是，如果代理服务器是安全的SCHF，那么加密参数可能位于SCHF的安全存储中。以安全方式存储内容的机制可以遵循上述流程。
图14示出CCSDF可以向不太可信的SCHF提供的示例加密参数。可以不提供证书，但是可以提供向SEF注册的证书标识。只有在实体获得授权后，实体才能够从SEF获得证书。因此，即使托管EC的SCHF也无法解密内容，因为它不具有证书，并且可能不是已被SEF授权的实体。
现在转向证书申请和注册过程(CRRP)，CRRP过程可以在SHRP与SHP之间交织，并且可以取决于用于基于CCSDF与CCSDF之间的信任关系或客户端证书在CCSDF或SCHF处的可用性来托管内容的机制。CRRP过程可以在CCSDF与SEF之间或者在SCHF与SEF之间基于正执行安全保护过程的实体来执行。CRRP由证书申请过程(CRP)和证书再生过程(CGP)组成。
关于示例CRP，如果SDF不能够在它被托管于其上的实体内本地生成或获得证书(如证书、密钥)，则SDF可以通过SEF发起CRP。在某些情境中，SDF可能够从物理上更靠近它的TTP实体获得证书。作为一般情境，假设SDF与SEF之间具有信任关系，SEF也可以用作中央证书库。图15示出了由CCSDF用可信SEF发起的CRP，但是相同的调用流程也可以适用于CHF与SEF之间的CRP。
在1处，根据所示示例，在成功鉴权并且在CCSDF与SEF之间建立安全通信信道(在0处)之后，SEF发送证书请求(CR)消息。所述消息可以包含通过示例而非限制的方式给出的以下参数：
·Content-Id[]：内容标识符列表。条目数可以是一个或多个。
·Algorithm_Strength[]:对于每个内容，都有一个对应的Algorithm_Strength。这是可选的，CCSDF可以根据对其自身的强度选择合适的算法
·Credential_Type_Length_Lifetime[]：对于每个内容，提供相应的证书类型、证书有效期的长度和持续时间。对于某一内容，Credential_Type可以是“证书”，而对于另一内容，其可以是请求“对称密钥”。“对称密钥”的证书长度可以是(例如64/128/256位)，而对于Credential_Type＝“证书”，所提供的证书的长度取决于所使用的算法(例如，RSA公钥可能是2048/4096位；而对于ECC，则可能是224/256位)。Lifetime值是证书有效的持续时间，并且可能需要执行类似的CR过程或更新过程。证书的Lifetime可基于表1中描述的“更新安全保护”值。
·Public_Key[]：与内容相关联的公钥列表。应注意，Credential_Type＝“对称密钥”的内容的Public_Key条目可能为空。根据示例，只有那些Credential_Type是“证书”的内容才会有相应的公钥输入。
·R-flag：CCSDF可以使用这个标志来标识它想要向SEF注册这些证书。例如，如果R-flag＝1，则CCSDF正在请求执行CRP和CGP。如果该标志设置为“0”，则只执行证书申请。
·Client-specific：此标志表示消息是否是客户端专用的证书请求。这里设置为“0”，表示它只是内容专用的CR。
仍参照图15，根据所示示例，基于请求，SEF生成正确的证书集。在Credential_Type＝“对称密钥”的情况下，可以使用如上所述借助于KDF的类似机制。SEF可以生成对于所请求的“Lifetime”值是有效的KeyGenKey，并将其提供给CCSDF。然后通过SEF在CDB中针对所述特定内容注册KeyGenKey。或者，SEF可以生成IK和CK，并将其注册到内容并存储在证书数据库(CDB)中。在某些情况下，如果Credential_Type＝“证书”，SEF使用公钥生成由SEF签名的证书，将证书关联到内容标识，并将证书的使用限制为作为请求的一部分提供的有效期值。内容的证书也存储在CDB中。在3处，SEF发送证书列表。在选择相应算法的情况下，也可以与提供注册是否成功的指示的标志一起提供算法列表。作为证书列表的一部分，可以提供指示证书是否是KeyGenKey以及证书的有效性的标志。根据示例，还向CCSDF提供与每个证书相关联的独特证书标识的列表。在4处，CCSDF将有关的证书、证书标识和相关联的使用期限存储到CDB中。如果证书是KeyGenKey，CCSDF可以任选地生成CK、IK，或者可以留待客户端来导出它们。
现在参考图16，描绘了示例客户端专用的CR过程。CCSDF可能会请求客户端专用的证书，例如，如果它请求只有这些客户端才能访问内容。在0处，在CCSDF和SEF相互鉴权之后，在CCSDF与SEF之间建立安全的通信信道。在信道已建立之后，在1处，CCSDF发送含有其证书被请求的客户端列表的CR消息。Credential_Type是正被请求的证书的类型。Credential_Type可以是“证书”或公钥或“对称密钥”。可能优选的是请求与客户端相关联的“证书”或“公钥”而不是“对称密钥”。客户端ID可能与多个客户端关联，而一群客户端共享相同的客户端ID。
在2处，SEF处理请求并查询CDB，并且获得用于特定客户端的正确证书集。如果Credential_Type＝“证书”或“公钥”，则从CDB中获得与所述客户端相关联的那些证书，如图示的示例所示。如果Credential_Type＝“对称密钥”，则SEF只能从CDB获得CK。在某些情况下，可以替代地获得与客户端相关联的KeyGenKey，然后CCSDF使用它来生成CK。在3处，根据所示示例，仅发送与客户端相关联的证书。SEF可以发送每个与客户端关联的证书列表。每个证书可以具有某种类型(公钥、证书或对称密钥)。也可能有一群客户端共享相同的证书。在4处，如果发送的证书是KeyGenKey，那么CCSDF可以根据它为每个客户端生成CK并将证书存储在本地CDB中。如果证书只是与每个客户端关联的“公钥”或“证书”，那么它们可以按原样存储。
为了简单起见，根据示例，客户端证书以及内容专用的证书可以存储在通用CDB内，但是将理解，它们可以存储在单独的DB中，并且它们也可以被托管在不同的管理域内。用于内容专用的CR和客户端专用的CR的SEF可能不同，因此CCSDF与SEF之间的信任关系可能不同。
现在参考图17，CCDSF可以使用如图17所描绘的证书注册过程(CGP)将与内容相关联的证书注册到SEF上。在此描述的类似机制可以由CCDSF使用，以便当使用基于托管内容的代理服务器时，用SCHF或通过SCHF向SEF注册证书。在示例实施例中，只有当内容专用的证书尚未由SEF生成时才需要CGP。在证书由CCSDF或SCHF生成的情况下，可以向SEF注册证书。
仍参考图17，根据所示示例，在1处，CCDSF使用安全通信信道向SEF发送CG请求消息。如上所述，CG请求消息的终点可以是其它SEF或SCHF。作为消息的一部分，可以包含以下参数，通过示例而非限制的方式给出：
·Content-Id[]：内容标识符的列表，假设为全局独特的，或在SEF和CCSDF的域内独特(unique)。可使用额外的消息传送以确保内容正被注册的域内的内容标识的独特性。
·Algorithm[]：用于每个内容的算法列表以及可以执行的操作的类型。例如。每个内容可以具有一个或多个相关联的算法(例如，完整性保护：HMAC-SHA和保密性保护：AES)
·Credential_Type[]：如前所述，这可能是：对称密钥、公钥或证书
·Usage[]：可能是关于如何使用算法和证书的一般准则。在大多数情况下，这可以基于最佳做法且由政策规定，因此可以省略。
·ACP[]：可能被允许、阻止或限制提供证书的实体(客户端)列表。此列表还可以包含一类客户端或基于客户端域信息(例如FQDN)等。
在2处，根据所示示例，SEF验证内容标识是独特的，并且证书(例如在公钥/证书的情况下)与正确的内容标识相关联。可以执行拥有正确私钥的一侧信道验证。一旦核查完成并成功验证，则证书将存储在CDB中。在3处，SEF用注册成功消息进行响应，并且还包含证书标识的列表，所述列表是与向SEF注册的每个证书相关联的独特标识符。
客户端可以与相同的SEF或不同的SEF具有信任关系。在图18中描绘了与客户端证书相关联的CG过程的示例性图示。在1处，根据所示示例，希望向SEF注册其证书的客户端可以发送以下参数，这些参数通过示例而非限制的方式给出：
·Client-Id
·Credential_Type：这是正在注册的证书类型的指示。客户端的首选Credential_Type可以是“公钥”或其“证书”。客户端也可能注册“对称密钥”，它只用于提供保密性保护。
·Credential(s)：客户端可以具有多个证书，并可以向SEF注册各种证书。
·Algorithm：用于证书类型的算法。
·Usage：关于如何使用证书的政策。根据一个示例，此参数被认为是可选的。
·ACP：关于谁/什么可以使用证书的限制列表。这也可以是可选的。
在2处，根据所示示例，SEF验证CG请求并将证书存储在CDB内。在3处，SEF在成功注册证书后向客户端发送“成功”消息。它还发送与每个为客户注册的证书相关联的独特的证书标识。
现在转向示例第三方证书申请过程(TPCRP)，希望验证内容真实性的客户端当其需要能够对加密内容进行解密的能力时可以从SEF请求证书。或者，如果向SCHF注册与内容相关联的证书，并且客户端能够发现SCHF，则客户端可以向SCHF发出CR请求。也可能证书从不在外部进行注册，而是本地存储在内容生成器(例如CCSDF)中。在此类情况下，客户端可以向CCSDF发布CR。可以通过使用常见的服务发现/资源发现机制(例如，DNS-SD、RD消息传送)来发现与SEF、SCHF或CCSDF相关联的URI。不管证书在哪里注册，实体(例如，SEF、SCHF或CCSDF)可能必须自己执行鉴权和授权，或者可以使用TTP服务，所述TTP服务可以代表实体执行以发布证书。ACP可能作为CR过程的一部分提供。鉴权和授权机制的强度可以基于正被请求的内容的类型。图19中示出了示例TPCRP，其中已经向SEF注册证书。如前所述，如果请求的目标是CCSDF或SCHF，则可以使用类似的机制。
参考图19，根据所示示例，在1处，客户端向SEF发送TPCRP请求。所述请求可以包含以下参数，通过示例而非限制的方式给出：
·Content-Id：客户端要请求的内容的标识
·Credential-Id(可选)：如果客户希望收到与内容相关联的特定证书，则其可以使用此参数。在大多数情况下，如果存在证书标识，则可以省略内容标识。但是，在可以使用证书标识来保护多个内容的情况下，可以使用内容标识和证书标识的组合。
·Credential_Type(可选)：在客户端可能无权访问证书标识的情况下，客户端可以请求某种类型的证书(例如公钥或对称密钥)。
·Algorithm(可选)：如果客户端只能执行特定的加密算法(例如AES)，则客户端可以指定它。
在2处，SEF验证客户端满足与内容相关联的ACP(例如，访问证书所需的鉴权/授权等级)，并且如果证书存在于CDB中，则SEF基于内容标识检索证书。如果SEF具有与内容标识相关联的多个证书，并且如果客户端已经提供了证书标识，则SEF检索所述特定证书。如果不存在证书标识，则SEF核查客户端是否在其请求中发送了优选的Credential_Type，如果是，则选择与匹配Credential_Type的内容标识相关联的证书。如果Credential_Type不存在但是已经请求了优选的算法，则SEF可以选择所述特定算法可以使用的证书。在替代实施例中，如果ACP允许这种交易，则SEF可发送与内容标识相关联的所有证书。如图所示，在3处，SEF发送含有证书的响应。
图20示出了示例内容检索过程(CRP)。在1处，根据所示示例，客户端发起CRP请求，并将内容标识作为消息的一部分提供给SCHF。在2处，SCHF可以发起授权核查以确定客户端是否被授权访问内容。如果客户端从SEF获得授权令牌，客户端可以出示授权令牌。如果没有，客户端与SCHF之间可能需要重新授权。在3处，根据所示示例，在验证请求之后，SCHF从PCS中检索EC和关联的AT。在4处，SCHF发送包含EC、AT和加密参数(CryptoParams)的CRP响应消息。加密参数可以任选地由SCHF发送。在某些情况下，SCHF可能不拥有加密参数。在这种情况下，客户端可能使用上述TPCRP预取了加密参数。根据内容和加密参数的类型，某些内容可能不会被加密，因此内容可能以未加密的形式发送。假设在大多数情况下，内容可能受到完整性保护，因此可已经通过SDF导出相应的AT。
在示例实施例中，在客户端检索到EC和关联的AT之后，通过验证内容没有被未授权实体修改并且由合法或可信实体(例如，CCSDF或高度可信的SCHF)产生，并且通过对加密的内容进行解密使得客户端能够消费内容，客户端拥有所述内容。参考图21，示出了描绘完整性/真实性核查以及由客户端执行的解密过程的高级视图的流程图。图21的描述基于图9中所示的客户端专用的加密参数，其中使用客户端的公钥对内容进行加密，并使用SDP的私钥进行完整性保护。在1处，根据所示示例，客户端使用从SCHF检索到的EC，并使用哈希算法(例如，SHA-256)和加密参数内指定的临时交互号来计算EC的哈希。在2处，客户端使用AT并使用公钥算法(例如RSA)和SDF的公钥对AT进行解密，以获得由SDF计算的哈希值。在3处，根据所示示例，将客户端计算的哈希值与SDF生成的解密哈希值进行比较。如果哈希值不匹配，则所述过程停止。在4处，如果哈希值匹配，则客户端通过公钥算法(例如，RSA)使用客户端的私钥对EC进行解密。为了生成加密内容的随机性，假定使用某种形式的补白(padding)。尽管这里给出的示例是基于RSA的加密，但是将理解，实施例不限于此。例如，基于对称密钥的加密算法而非基于公钥的机制可能优选用于加密。在5处，客户端消费内容。
现在转向内容生命周期管理过程(CLMP)的示例，CCSDF和/或SDF可能参与特定内容的内容生命周期管理。可以由CCSDF根据表1中提供的安全性参数中提供的“生命周期”(例如以年计)值发起CLM过程。当基于政策生命周期时段已经达到时，内容可能被删除或变得不可用(例如，通过用随机值混合和填充内容并使用一次性密钥和强加密算法对其进行加密)。“更新安全保护”值(例如以年计)可用于更新与内容相关的安全保护。更新安全保护可以是任选的，在一些情况下，可能使内容暴露于安全性攻击，因此可仅允许可信实体(例如，具有TEE并且基于RoT的平台)执行CLM过程。可以执行新的CRP、CGP、重新托管过程和TPCRP，以生成和注册证书并保护内容。总而言之，生成新的证书、注册、然后使用新证书保护内容，接着将受保护的内容连同新生成的证书一起提供给授权客户，最好使用单独的消费信道。
为了方便起见，此处描述的实施例主要集中在oneM2M架构上，但应该理解，实施例不限于oneM2M。如图22所示，前面描述的一般功能(例如，SEF)可以被并入到oneM2M体系结构中，作为Mca接口上的“安全性”的一部分。在示例中，AE可以并入CCSDF，并且CSE可以实现SCHF。在示例实施例中，SEF被并入到M2M登记功能(MEF)中。可以理解，AE和MEF之间以及CSE和MEF之间存在潜在的信任关系。作为示例而非限制，在下面的表4中提供前面描述的功能和oneM2M实体的总结映射。
表4：通过Mca接口将安全功能映射到oneM2M实体
图23描绘了结合在Mcc接口处提供内容安全性的安全功能的一个示例。作为示例而非限制，表5中提供了前面描述的功能和oneM2M实体的总结映射。
表5：通过Mcc接口将安全功能映射到oneM2M实体
如所示，CSE1可以实现SDF和SCHF。SCHF功能用于以安全的方式存储可能与应用内容或oneM2M系统资源相关的一个或多个oneM2M资源。SCHF可以驻存于数据管理和存储库CSF中，并可以作为其一部分进行管理。SDF可以驻存于安全性CSF内并在其内进行管理。在CSE2处，根据示例，SEF和CLMP功能可以被并入作为安全性CSF的一部分，而主要涉及以安全方式安全地存储证书资源的SCHF可以作为数据管理和存储库的部分并入。上面描述的证书标识资源和加密参数可以是由SCHF存储和管理的适当的资源。
现在参考图24，描绘了根据oneM2M的示例实施例。如图所示，内容可以表示为oneM2M资源，而子成分可以表示在属性和内容实例内。这里假设可以使用基于TLS/DTLS的安全连接来保护服务层连接(跳)。在1处，根据所示示例，要为其建立的资源提供保护的AE1可向M2M登记功能MEF请求适当证书。假设AE1和MEF已经在它们之间相互鉴权并且使用(D)TLS建立了安全通信信道。还假设MEF已经确定AE1已被授权执行此类请求。如果AE1要提供完整性和保密性保护，则可能会明确要求这些证书。或者，如果使用对称密钥机制，则AE1可能仅需要主密钥(如KeyGenKey)。AE1可发送资源建立请求，并与请求一起提供其安全性要求(SecRequirement)。而且，可以提供访问控制政策(ACP)列表，其可以包含授权实体的列表(例如，AE2的标识)。在2处，MEF核查以确保AE1被授权在MEF处建立资源。如果AE1被授权，则MEF生成适当的证书和相关联的证书标识。其可以建立如图25所示的资源结构。在3处，根据所示示例，MEF将证书和证书标识作为响应发送回AE1。或者，AE1可能够执行检索操作以获得证书。例如，证书可以用JSON Web密钥(JWK)格式的形式来表示和发送。
仍参考图24，根据所述示例，在4处，基于加密参数以及由AE1检索到的证书，AE1加密资源以建立EC-R1，并且生成资源的AT(MAC或数字签名)，称为R1-AT。算法的选择以及临时交互号和Id可以基于加密参数内的值。建立的EC-R1可以基于JSON Web加密(JWE)，并且建立的R1-AT可以基于JSON Web签名。例如，可以用JSON Web算法(JWA)标准中规定的形式表示适当的算法。在5处，AE1向托管CSE(H-CSE)发送建立含有加密内容(EC-R1)以及R1-AT和加密参数的资源的请求。在5处的请求可以是注册过程的一部分，或者AE1可能在发送请求之前预先向H-CSE注册。应注意确保CK、IK和KeyGenKey不作为加密参数的一部分提供给H-CSE或向H-CSE公开，因为H-CSE在某些情况下可能不完全可信。然而，例如，如果使用公钥机制，可以提供公钥值或者指向证书或公钥的链接作为加密参数的一部分。在6处，例如，如果AE1被授权在H-CSE处建立资源，则H-CSE托管受保护的内容。在图29中示出为受保护内容建立的示例资源结构。在7处，根据所示示例，客户端(AE2)想要获得受保护资源EC-R1，因此将请求消息发送给H-CSE以检索R1。在8处，H-CSE通过使用与EC-R1相关联的ACP来验证AE2的授权。ACP可能已经根据AE(CCSDF)提供的政策、SP提供的政策或H-CSE处的本地政策建立。在9处，如果AE2通过授权核查，则H-CSE向AE2发送含有EC-R1、R1-AT和加密参数的响应。如上所述，加密参数可能不包含CK、IK或KeyGenKey，因为在某些情况下H-CSE可能不可信。加密参数可能含有公钥或证书或者指向公钥或证书的链接。在10处，AE2从加密参数中提取证书标识。在12处，AE2向MEF发送请求消息。所述请求消息可以含有与R1相关联的证书标识，以使得执行对证书的检索操作。在12处，根据所示示例，MEF基于由AE1建立的ACP来确定AE2已经被授权具备证书。在13处，如果AE2已被授权，则MEF将证书发送到AE2。在14处，AE2使用证书来验证R1的真实性/完整性并对其进行解密。
应理解，以上参考图24描述的实施例也可以适用于Mcc接口(例如，在两个CSE即CSE1与CSE2之间)。在这种情况下，例如，AE1可以由CSE1替代，并且AE2可以由CSE2替代。
因此，参考图24，装置(例如，AE1)可以包含处理器、存储器和通信电路。所述装置可以经由其通信电路连接到网络，并且所述装置可以进一步包括存储在节点的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使所述装置发送对提供内容保护的一个或多个证书的请求。所述请求可以基于与内容相关联的一个或多个安全性参数。所述装置可以获得一个或多个证书，并使用一个或多个证书来保护内容。证书可以包括用于对称密钥保密性保护的主密钥。证书可以包括用于完整性保护和保密性保护的证书。所述装置可以对内容进行加密以建立加密的内容。所述装置可以生成与内容相关联的鉴权标签。此外，如图所示，所述装置可以向托管公共服务实体发送建立含有加密内容和安全性参数的资源的请求。如图所示，根据一个示例，可以从M2M登记功能获得证书。
在图26中示出了SEF驻存于CSE处的替代实施例。参考图26，根据所示实施例，在1处，想要安全地托管资源R1的AE1基于安全性要求生成适当的证书。使用该证书，AE1可以对内容进行加密以建立EC-R1，并且对其做完整性保护以建立R1-AT(其可以是基于已经使用的证书的类型的DS或MAC)。例如，加密的EC-R1可以表示为JSON Web加密。在2处，AE1执行请求使得在执行证书托管服务的CSE处建立证书标识资源。假设在示例中AE和CSE共享相互信任关系。还假设在示例中AE1与CSE之间的通信是在安全通信信道(例如，DTLS、TLS)上执行的。使用安全通信信道，AE1可以向CSE发送AE1所生成并用于对内容进行加密和/或完整性保护的一个或多个证书。在3处，CSE可以确定AE1是否被授权建立资源。例如，CSE可能已经使用(D)TLS在安全通信信道建立过程期间执行了鉴权流程。替代地或另外，服务提供商可能已经在CSE处预先提供了ACP政策。CSE可以任选地使用AE1的公钥来验证AT。CSE可以任选地生成与CSE相关联的独特证书标识。这是可选的，可能由AE1提供。在一些情况下，为了提供域内的独特性以及全局可达性，CSE可以代表AE1生成证书标识。在CSE处建立的证书标识资源可以是图27中示例所示的形式。
仍然参考图26，根据所示的实施例，在4处，CSE将证书标识发送给AE1。在5处，AE1请求建立安全资源R1，其是加密的EC-R1并且使用R1-AT进行完整性保护。因此，根据所示示例，H-CSE从第一应用(AE1)接收第一请求以建立用于托管与第一应用相关联的安全内容的资源。AE1也可以提供必要的加密参数和证书标识。因此，所述请求可以包含由CSE生成的与H-CSE不同的证书标识。证书标识可以是加密参数的一部分，或者可以作为与R1相关联的独立子资源被发送。在示例中，假设AE1和H-CSE已经彼此相互鉴权，并使用TLS或DTLS建立了安全的通信信道。例如，其也可以包含如图28所示的关联的访问控制政策资源。此ACP可以受完整性保护，并且可以基于使用AE1的私钥生成的DS来建立AT。建立的EC-R1可以基于JSON Web加密(JWE)，并且建立的R1-AT可以基于JSON Web签名。可以用JSONWeb算法(JWA)标准中规定的形式表示适当的算法。在6处，H-CSE验证请求并且核查以确保(确定)AE1是否被授权在H-CSE处建立资源。在7处，根据所示示例，H-CSE成功响应。因此，如果示例应用被授权，H-CSE可以托管安全内容。在某些情况下，与H-CSE不同的CSE可以授权应用建立资源。
在8处，客户端(AE2)想要检索R1，因此向H-CSE发送请求如第二请求，以检索R1。因此，H-CSE可从第二应用(AE2)接收访问与AE1相关联的安全内容的第二请求。涉及发现R1的机制超出了本示例的范围，并且假设AE2能够发现R1的安全版本的位置。AE2可能会发现R1的安全性较低的版本，从完整性的角度来看，其保证程度较低。假设在基于DTLS或TLS执行相互鉴权之后通过安全信道发送请求。在9处，根据所示实施例，H-CSE验证是否允许AE2使用由AE1建立的ACP内的信息来执行检索操作的授权。因此，H-CSE可确定AE2是否被授权访问安全内容。在10处，H-CSE发送含有EC-R1、EC-AT和R1-加密参数的响应。因此，如果第二应用被授权访问安全内容，则H-CSE可把安全内容发送给第二应用。可使用例如基于JSON的标注JWE来表示EC-R1，同时可使用JWS来表示EC-AT，可使用JWA来表示R1-加密参数。在11处，如果包含证书标识作为加密参数的一部分，则AE2从其中提取证书标识。在12处，AE2向CSE发送请求消息(如可基于包含在证书标识内的域信息来确定CSE的URI，其中证书标识可具有以下形式：R1xyrtabsffas@CSE.com)以便通过在消息中包含证书标识作为资源标识来执行检索操作。在示例中假设AE2和CSE已经彼此相互鉴权，并使用TLS或DTLS建立了安全的通信信道。可使用例如基于JSON的标注(例如JWK)来发送证书标识。在13处，CSE基于在2处的证书注册过程期间由AE建立的ACP来验证AE2的授权。在14处，如果AE2被授权检索，则CSE通过安全信道将证书发送到AE2。在15处，使用证书，AE2使用R1-AT验证完整性并解密R1。因此，当CSE将与安全内容相关联的一个或多个证书发送到第二应用(AE2)时，可以对安全内容解密。在一些情况下，如上所述，AE2被授权通过AE1的访问控制政策访问安全内容。
应理解，以上参考图26描述的实施例也可以适用于Mcc接口(例如，在两个CSE：CSE1与CSE2之间)。在这种情况下，实体AE1可以由CSE1替代，并且AE2可以由CSE2替代。
因此，参考图26，装置(例如AE1)可以包含处理器、存储器和通信电路。所述装置可以经由其通信电路连接到网络，并且所述装置可以进一步包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的所述处理器执行时使得所述装置基于与内容相关联的安全性要求生成一个或多个证书。如下面详细描述的(如，见图37)，可以通过引导该装置与信任启用功能之间的关联来生成一个或多个证书。所述装置可以使用一个或多个证书来确保内容安全(例如，对内容进行加密)，并且请求托管节点存储安全内容，使得只有授权客户端才能从托管节点检索内容。所述装置还可以使用一个或多个证书来生成鉴权标签。鉴权标签可以指示在托管公共服务实体处托管的内容的完整性和真实性。响应于请求，所述装置可以从公共服务实体接收证书标识。请求可以包含与证书标识相关联的证书，其中该请求寻求证书的注册。在示例实施例中，证书标识对于公共服务实体是独特的。如图所示，如果托管节点确定节点被授权在托管节点建立资源，则所述装置还可以接收成功消息。
根据另一实施例，使用引导(bootstrapping)来产生数据安全性证书。例如，AE可以通过利用引导过程来生成数据安全性证书，所述引导过程使用AE与可信第三实体之间的现有关联，例如M2M登记功能(MEF)、信任启用功能(TEF)或M2M鉴权功能(MAF)。如在此背景下所使用的，将理解，术语“数据安全性”可以指内容安全性或资源安全性。数据也可以指内容的实例。因此，内容实例安全性在本文中通常也可以被称为数据安全性。在某些情况下，TEF是主要用于远程配置数据(例如内容或资源)特定安全证书的MEF的专用实现。因此，除非另外指明，否则术语TEF和MEF可以互换使用而没有限制。
现在参考图37，根据所示实施例，由于AE与TEF之间的引导过程而生成数据/内容安全性证书。在0处，当前在oneM2M规范(TS-0003，版本1)内描述的引导过程可通过使用引导来增强以导出数据安全性证书。如在TS-0003(版本1)中所描述的，AE与MEF/TEF之间共享的证书KpmId/Kpm用于生成会话证书KeId/Ke。证书Ke可以用于在AE与TEF之间生成数据安全性特定的证书。类似地，AE与CSE之间的引导过程可以利用AE与CSE之间的现有安全性关联。安全性关联可以由KpsaId/Kpsa来标识，如在oneM2M TS-0003中所描述。然后用Kpsa代替Ke。类似地，用于建立AE与MEF之间的安全性关联的KmId/Km可以用于生成AE与MEF之间的数据安全性证书。在某些情况下，AE和TEF更可取的方法是生成数据安全性证书。
仍然参考图37，在1处，根据所示示例，通过AE(AE1)生成主密钥。用作密钥生成的一部分的随机值Salt可以在引导过程中被共享，或者可以在引导期间被计算为AE与TEF之间的初始通信的哈希值。Salt可以是在AE1与TEF之间绑定的信道的加密表示。所述信道可以是使用TLS或DTLS建立的安全连接。可被称为登记者的AE1和可被称为登记目标的TEF可使用Ke来生成数据安全性证书。如所示，Ke_AE1-TEF是指AE1与TEF之间关联的Ke。Ke可以是用于生成数据安全性主密钥K_AE1_TEF_data_sec_master的主密钥。或者，如果目标是例如MEF，则Km可以用作用于生成数据安全性主密钥的主密钥。下文提供了使用RFC 5809进行数据安全性密钥生成的示例，其中登记者是AE，且登记目标是TEF：
·K_AE1_TEF_data_sec_master＝HMAC-Hash(Salt,Ke_AE1_TEF)
·T(0)＝空字符串(零长度)
·一旦已生成K_AE1_TEF_data_sec_master，就可以将其用于密钥扩展，以生成独特数据真实性和数据保密性密钥。在一些情况下，如果通过诸如AEAD的算法(例如，AES-CCM或AES-GCM)提供数据真实性和保密性，则仅生成单个密钥
·K_AE1_TEF_data_auth＝T(1)＝HMAC-Hash(K_AE1_TEF_data_sec_master,T(0)|“Data Authenticity and Integrity”|0x01)
·K_AE1_TEF_data_auth密钥被用于提供数据真实性和数据完整性，因此可以被称为数据真实性或数据完整性密钥。
·K_AE1_TEF_data_conf＝T(2)＝HMAC-Hash(K_AE1_TEF_data_sec_master,T(1)|“Data Confidentiality Key”|0x02)。
在某些情况下，可以使用Kpsa_AE1_CSE1(其是AE1与CSE1之间的Kpsa)来代替Ke_AE1_TEF，并且上述过程可以用于生成用于数据安全性保护(例如数据鉴权、完整性和数据保密性)的独特密钥)。如果CSE被AE用作数据安全性证书注册表，则可以使用Kpsa。在某些情况下，可以使用Kpsa_AE1_CSE、Ke_AE_TEF或Km_AE1_MAF作为K_AE1_TEF_data_sec_master密钥，并且可以使用上述过程生成用于数据安全性保护(例如，数据鉴权、完整性和数据保密性)的独特密钥。如果存在某些其他情况，则从Ke_AE1_CSE1、Kpsa_AE1_TEF、Km_AE1_MAF生成会话密钥，然后将其用作生成用于数据真实性和数据保密性的独特密钥的主密钥。在某些其他情况下，与AEAD类算法一起使用时，仅使用从Ke、Kpsa或Kpm生成的单个会话密钥(K_AE1_TEF_data_auth_conf)来提供数据真实性以及数据保密性。
在2处，根据所示示例，由TEF执行类似的密钥生成过程。执行AE1与TEF之间的引导处理的步骤0期间，可以执行算法、密钥生成机制、密钥的类型以及要生成的密钥的数量等的协商。
在3处，AE1生成内容/数据。内容/数据的每个实例可以由数据真实性和数据保密性独特密钥集来保护。在另一示例中，内容的实例(例如内容的所有实例)可以由单个数据真实性密钥和单个数据机密密钥来保护。下文示出示例密钥生成，其中针对可能含有多个内容实例的容器只生成单个数据真实性和单个数据保密性密钥：
·K_AE1_Container-x_data_auth＝HMAC-Hash(K_AE1_TEF_data_auth,“DataAuthenticity and Integrity”|“Container-x”|Nonce or creationTime)，以及
·K_AE1_Container-x_data_conf＝HMAC-Hash(K_AE1_TEF_data_conf,“DataConfidentiality”|“Container-x”|Nonce or creationTime))
或者，对于容器内的每个内容实例，可以生成独特密钥集。下文示出此类实施例的示例：
·K_AE1_ContentInstance-x_data_auth＝HMAC-Hash(K_AE1_TEF_data_auth,“Data Authenticity and Integrity”|“Container-x”|Nonce or creationTime)，以及
·K_AE1_ContentInstance-x_data_conf＝HMAC-Hash(K_AE1_TEF_data_conf,“Data Confidentiality”|“ContentInstance”|Nonce or creationTime)。
可使用以上生成的密钥对内容进行加密和/或完整性保护。为了对内容加密，可以由AE1生成随机IV。随机IV可以与加密算法和内容(数据)一起使用以生成加密内容(EC-R1、加密资源)。
在内容实例被分开加密的一些情况下，每个内容实例可以具有独特保密性密钥，并且每当执行加密过程时可以生成新的IV，从而生成加密的内容实例。因此，每个内容实例可以具有关联的单独的加密内容实例。
为了完整性保护或为了增加内容/数据的真实性，可以使用具有相关联的时间分量的随机临时交互号，以生成与内容相关联的鉴权标签(AT)。在每个内容实例被分开保护的情况下，每个内容实例可以具有关联的AT。为了提供数据真实性，在某些情况下，可能优选的是使用单个密钥来生成每个单独的AT。
如图29所示，加密的内容可以表示为修改的oneM2M容器或<内容实例>资源。或者，所建立的EC-R1可以基于RFC 7516中指定的JSON Web加密(JWE)。所建立的R1-AT可以基于RFC 7515中指定的JSON Web签名。适当的算法可以按JSON Web算法(JWA)标准RFC 7518中指定的形式来表示。
通常，生成和使用的每个密钥可以与独特证书标识相关联。证书标识可由AE1产生或由TEF提供给AE1。在某些情况下，证书标识可以携带内容标识或内容实例标识的特征以及证书的类型。证书标识的示例可以有格式：K_AE1_Container-x_data_conf-Id@TEF.com，其与密钥K_AE1_Container-x_data_conf关联。
继续参考图37，在4处，根据所示实施例，AE1可以向TEF注册证书标识。如图所示，AE1请求建立根据证书标识和关联的访问控制政策标识的证书资源。例如，证书标识可以替代地由TEF提供，以避免与TEF相关的证书标识的冲突。如果通过AE1执行生成的ID的哈希，则可以避免证书标识的冲突。下文示出示例哈希：
·H1＝Hash(K_AE1_Container-x_data_conf-Id)
·Credential-Id＝H1@TEF.com。
在5处，如所示，TEF核查以确保AE1已被授权向TEF注册证书。TEF也可以验证可能已经包括的证书标识和任选的加密参数。然后，TEF可以建立<credential-Id>资源类型并为其填充属性，例如<accessControlPolicy>值。
在6处，根据所示示例，TEF将指示成功建立证书资源的响应发送到AE1。在7处，AE1请求建立安全资源R1，其是加密的EC-R1并且使用R1-AT进行完整性保护。AE1还可以提供加密参数和证书标识。证书标识可以是加密参数的一部分，或者可以作为与R1关联的单独的子资源来发送。在某些情况下，AE1和HCSE已经彼此相互鉴权，并使用TLS或DTLS建立安全的通信信道。请求还可以包含关联的访问控制政策(ACP)资源。此ACP可受到完整性保护。
在8处，H-CSE验证请求并核查以确保AE1已被授权在H-CSE处建立资源。在9处，H-CSE以成功消息进行响应。参考10，在某些时候客户端(AE2)可能想要检索R1。客户端可以向HCSE发送检索R1的请求。在某些情况下，AE2能够发现R1的安全版本的位置。在某些情况下，AE2可能会发现R1的安全性较低的版本，从完整性的角度来看，其保证程度较低。在基于DTLS或TLS执行相互鉴权之后，可以通过安全信道发送请求。AE2可发送对资源R1执行“检索”操作的请求。在11处，根据所示示例，HCSE验证是否允许AE2使用由AE1建立的ACP内的信息来执行检索操作的授权。在12处，HCSE发送含有EC-R1、EC-AT以及R1-加密参数的响应。可使用例如基于JSON的标注(例如JWE)来表示EC-R1，可使用JWS来表示EC-AT，并且可以使用JWA来表示R1-加密参数。或者例如，如果用于加密和完整性保护的算法基于AEAD算法(如AES-GCM或AES-CCM)，则EC-AT和EC-R1都可以表示为JWE。又或者，加密的内容EC-R1和R1-AT可以与适当的加密参数一起表示为oneM2M资源。
在13处，根据所示示例，如果包含证书标识作为加密参数的一部分，则AE2从其提取证书标识。在14处，例如，通过在消息内包含证书标识作为资源标识，AE2向TEF发送请求消息以执行检索操作。AE2和TEF可以彼此相互鉴权，并使用TLS或DTLS建立安全的通信信道。可以使用例如基于JSON的标注(例如JWK)或使用oneM2M资源结构来发送证书标识。AE2也可以从与资源R1(数据)相关联的加密参数中提取Salt或Nonce。AE2也可以发送Salt或Nonce与证书标识来检索资源特定的证书。
在15处，TEF基于在2处的证书注册过程期间由AE1建立的ACP来验证AE2的授权。在16处，如果AE2被授权检索，则TEF计算资源特定的证书，并通过安全信道将其发送到AE2。TEF还可以发送指示如何使用证书的使用信息以及可以使用的关联算法。在某些情况下，AE2可能已经拥有了从HCSE获得的作为加密参数的一部分的使用信息。然而，在容器可含有多个内容实例资源(并且每个资源可与其自身的加密的内容实例、鉴权标签、证书相关联)的其它情况下，TEF可能够提供关于证书如何用于验证内容实例完整性并解密内容实例的额外指导。在发送Salt的示例中，TEF可以生成K_AE1_TEF_data_sec_master，然后可以将其提供给AE2。在示例中，AE2使用K_AE1_TEF_data_sec_master来生成容器特定的或者内容实例特定的证书。可以根据上述机制来实现用于生成K_AE1_TEF_data_auth和K_AE1_TEF_data_conf(以及相关的容器或内容实例特定证书)的机制。在此认识到，提供K_AE1_TEF_data_sec_master的优点在于，只要与K_AE1_TEF_data_sec_master相关联的证书使用期限未到期，AE2就可以不必联系TEF，而不管AE1是否生成新的内容实例。AE2可能够使用作为步骤12中执行的资源检索过程的一部分AE2获得的加密参数根据K_AE1_TEF_data_sec_master生成容器或内容实例特定的证书。在一些情况下，提供K_AE1_TEF_data_sec_master可以使AE2以加密方式访问内容和实例，例如由AE1生成的所有内容和实例。因此，在此认识到，在某些情况下，这种提供不是优选的方法。
在另一个示例实施例中，TEF可以将K_AE1_TEF_data_auth和/或K_AE1_TEF_data_conf提供给AE2，然后AE2生成容器特定的或内容实例特定的证书。在其它情况下，TEF可能仅将容器特定的或内容实例特定的证书提供给AE2。在某些情况下，AE2可能因其具备密钥而不执行任何密钥生成，从而限制了AE2对特定容器或内容实例的加密访问。在某些情况下，对于密钥中的每一个，可能必须向TEF提供相关联的临时交互号，与容器相关联的建立时间、或内容实例。在某些情况下，当AE1在4处执行证书过程的注册时，AE1可以将与证书标识相关联的加密参数包括到TEF中。
从性能和安全性角度来看，这里认识到，TEF的做法可能是只将K_AE1_TEF_data_auth和/或K_AE1_TEF_data_conf提供给AE2。证书可以具有与每个证书相关联的关联有效期。在有效期满后，可能必须生成新的证书。
在17处，根据所示示例，使用证书，AE2使用R1-AT验证完整性，并使用所供应的或生成的容器或内容实例证书来解密R1。
在替代实施例中，节点(例如，AE1)生成客户端专用的“受保护”内容，其可以被保护以供特定客户端(例如，AE2)使用。在oneM2M中，因为AE不直接通信以相互鉴权，所以CSE可以代表AE1执行客户端专用的保护，从而在CSE处生成并托管客户端专用(例如，AE2)的受保护内容。或者，本文所述的其中CSE代表AE1执行安全功能的类似机制可由AE1本身执行，而不必依靠CSE1。现在将讨论图38所示的客户端专用的受保护内容实施例。
如上所述，图38示出了客户端专用的内容保护实施例。参考图38，根据所示实施例，在0处，AE1已经使用(D)TLS与HCSE相互鉴权。类似地，AE2已经使用(D)TLS与HCSE相互鉴权。
在1处，根据所示示例，AE1生成内容(数据)和/或内容实例。此外，AE1希望确保内容受到托管CSE的完整性和/或保密性保护。在2处，AE1请求使用独特客户端专用证书对于每个特定客户端的内容进行完整性和/或保密性保护。在3处，HCSE处理由AE1提供的ACP，并且确定已被授权能够对安全内容执行CRUD操作的客户端(例如，AE2)。HCSE还确定必须生成独特客户端专用(例如，AE2特定)证书。或者，CSE1可以确定ACP，并因此确定授权的客户端。或者在某些情况下，由AE1提供的ACP与由服务提供商提供的ACP结合，以确定被允许对内容执行CRUD操作(特别是“检索”操作)的授权客户。根据示例，假设AE2是经批准的客户端并且已经被AE1授权，则HCSE通过利用根据oneM2M TS-0003规范(版本1)进行远程提供或引导而提供或生成的预共享密钥Kpsa_HCSE_AE2来生成K_HCSE_AE2_data_sec_master。例如，基于RFC 5869，可以使用密钥扩展机制来生成用于数据安全性的主密钥K_HSCE_AE2_data_sec_master：
·K_HCSE_AE2_data_sec_master＝HMAC-Hash(Salt,Kpsa_HCSE_AE2)
·T(0)＝空字符串(零长度)。
在4处，一旦生成K_HCSE_AE2_data_sec_master，其可以用于密钥扩展以生成独特数据真实性和数据保密性密钥。在一些情况下，如果通过诸如AEAD的算法(例如，AES-CCM或AES-GCM)提供数据真实性和保密性，则仅生成单个密钥。例如，可以如下生成密钥：
·K_HCSE_AE2_data_auth＝T(1)＝HMAC-Hash(K_HCSE_AE2_data_sec_master,T(0)|“Data Authenticity and Integrity”|0x01)
·K_HCSE_AE2_data_auth密钥用于提供数据真实性和数据完整性，因此可以被称为数据真实性或数据完整性密钥。
·K_HCSE_AE2_conf＝T(2)＝HMAC-Hash(K_HCSE_AE2_data_sec_master,T(1)|“Data Confidentiality Key”|0x02)。
下文示出密钥生成，其中针对可能含有多个内容实例的容器只生成单个数据真实性和数据保密性密钥，例如：
·K_HCSE_AE2_Container-x_data_auth＝HMAC-Hash(K_HCSE_AE2_data_auth,“Data Authenticity and Integrity”|“Container-x”|Nonce or creationTime)以及
·K_HCSE_AE2_Container-x_data_conf＝HMAC-Hash(K_HCSE_AE2_data_conf,“Data Confidentiality”|“Container-x”|Nonce or creationTime)。
或者，对于容器内的每个内容实例，可以生成独特密钥集，例如如下所示：
·K_HCSE_AE2_ContentInstance-x_data_auth＝HMAC-Hash(K_HCSE_AE2_data_auth,“Data Authenticity and Integrity”|“Container-x”|Nonce or creationTime)以及
·K_HCSE_AE2_ContentInstance-x_data_conf＝HMAC-Hash(K_HCSE_AE2_data_conf,“Data Confidentiality”|“ContentInstance”|Nonce or creationTime)。
又或者，在使用公钥机制的某些情况下，客户端专用的证书可以根据基于标识的加密(IBE)机制。
仍参考图38，在5处，根据所示示例，AE2请求(在某一点)从HCSE“检索”资源R1(容器或内容实例)。在6处，HCSE验证AE2的授权。在7处，HCSE用加密的内容EC-R1、鉴权标签、R1-AT和相关联的加密参数进行响应。在8处，AE2使用加密参数，并提取UsageInfo和“Salt”以生成K_HCSE_AE2_data_sec_master。此外，AE2提取为生成K_HCSE_AE2_data_conf、K_HCSE_AE2_data_auth等所需的临时交互号和其它参数。AE2接着可以生成容器特定的密钥和内容实例密钥，以便验证容器/内容实例内的数据的真实性和完整性，并解密容器内的数据或每个容器实例内包含的数据。
因此，参考图37和38，所示出的节点可以包括处理器、存储器和通信电路。节点可以经由其通信电路连接到网络，并且节点可以进一步包括存储于节点的存储器中的计算机可执行指令，所述计算机可执行指令在由节点的处理器执行时使节点执行所示出和描述的步骤。
图27示出了示例证书标识资源。如图所示，示例证书标识资源本身是使用证书AT进行完整性保护的，证书AT可以由证书标识资源的建立者借助于建立者的证书(例如，AE1的私钥)或由SCHF(例如H-CSE)建立。现在描述示例属性的细节，通过示例而非限制的方式给出：
·credential-Id：它唯一标识域内的证书。它可能是全局独特或局部独特的，一般基于证书的范围。它可能是这样的形式：使用随机但独特的值作为前缀和FQDN作为后缀(例如xyz@credentials.example.com)或呈URI的形式(例如//example.com/credentials/xyz)。
·credential：它由特定于证书的子资源属性组成。所述属性是：
○credetialType：描述证书的类型，即对称密钥或公钥。它也可以指定公钥的类型(例如，RSA或ECC)
○credential：该属性存储实际的证书值(例如对称密钥或公钥)。注意：证书的大小可能取决于证书的类型。如果密钥是公钥，则它可能具有关联：
■publicKeyParams：该参数可以是(例如，使用的曲线的类型、密钥大小)和/或可以基于JWK参数。这可以是任选的。
·accessControlPolicy：基于oneM2M定义的ACP的示例ACP具有三个属性：accessControlOriginators,accessControlOperations和accesControlContexts
·scopeUsage：这一属性定义范围(例如，签名或加密、密钥生成过程)。它也可以提供使用情况，有关证书使用方式。有关使用证书的规则。
·validity：该有效性属性可用于指示与证书相关联的有效期。证书可能需要更新，并且可以根据政策启动CLMP。
·issuer：生成和颁发证书的实体的标识(例如，FQDN)。
·credentials-AT：这一属性可以使用图30中描述的相关联的加密参数子资源来存储关于证书资源计算的AT值(其包含除了证书-AT属性之外的所有属性)。
图28示出受到完整性保护的通用ACP的示例实施例。所示的ACP具有关联AT，如果加密参数指定使用公钥机制，则所述关联AT可以使用AE的私钥生成。还可能建立ACP的任何实体可能够生成经鉴权/受完整性保护的ACP。因此，如果ACP是由CSE建立的，那么所生成的AT是基于CSE的私钥，只要加密参数已要求使用公钥机制。
图29示出使用加密参数资源内描述的加密算法和特定证书(例如，对称密钥)得到保密性保护(EC-contentInfo)的内容实例的示例。它也可以借助于通过公钥机制(例如，内容生成器的私钥)或通过从主密钥(例如KeyGenKey)生成的对称密钥生成的DS或MAC(例如，存储于内容AT属性中)得到完整性保护。
图30中描绘示例的相关加密参数资源。下文提供关于与加密参数资源相关联的示例属性的细节，通过示例而非限制的方式给出：
·cryptoParamsId：这是一个可选属性，可用于唯一地标识与受保护的内容/数据相关联的加密参数。
·confidentiality：这是描述与加密过程相关联的参数的子资源类型。
○algorithm：描述待使用的加密算法(例如，AES-128)
○credential-Id：描述将被用于检索用于加密内容(例如，离心机温度)的证书(例如，密钥)的证书标识，
○initializationVector：其描述将用于对特定算法的内容进行加密/解密的IV。
○scopeUsage：这是可选属性，可以描述证书的使用和范围IV以及为了加密或解密内容/资源的算法。
·integrity：它是描述与完整性保护内容/资源相关联的参数的子资源。属性是：
○digestAlgorithm：用于建立摘要的算法(例如，SHA-1)。
○signingAlgorithm：在公钥的情况下用于对摘要进行数字签名的算法，可以使用适当的算法(例如，RSA)，而在对称密钥的情况下可以使用适当的算法(例如HMAC-SHA-1)。有可能在对称密钥的情况下，用Keyed-Hash-MAC算法(例如，
HMAC-SHA-256)代替摘要算法。这里描述的示例使用公钥机制，但是对于对称密钥可以使用类似的机制。
○credential-Id：描述将被用来检索用于建立与内容/资源相关联的AT的证书(例如，密钥)的证书标识(例如，cred2@verisign.com)。
○nonce，该值用于重放保护，可能含有与建立内容/资源相关的随机生成值或时间/日期。
○scopeUsage：这是任选属性，可以描述证书、临时交互号和算法的使用，以建立内容/资源的AT。
·crtypotoParams-AT：这是使用关联的加密参数子资源由加密参数标识cp_tem_cent_30_20/10/15标识的与加密参数资源相关联的AT。
图31示出针对完整性和真实性保护的<mgmtObj>资源的示例。图32示出示例安全性政策资源。
根据示例实施例，用户可以使用图形用户界面(GUI)来执行与内容安全性相关联的政策和安全性参数配置。或者，代替GUI或者除了GUI之外，可以使用网络接口。图33示出示例用户界面(UI)。例如，UI可以用于但不限于：
·配置与内容安全性有关的安全性政策
·为用户提供以下功能：
○定义内容的成分
○定义内容的结构
·基于内容/内容类型定义安全性要求
·显示用户可能使用的表，使用户能够将安全性要求配置/映射到关联的安全性参数
·配置内容生命周期参数(更具体地说是安全性参数)
·定义用于识别可信SCHF的参数
可以在SCHF处提供各种UI。图34示出可以在SCHF处提供的示例UI，其包括(通过示例而非限制的方式给出)：
·用于配置与内容安全性相关的安全政策的UI
·用于配置内容生命周期参数(更具体而言是安全性参数)的UI
·用于定义用来定义其(SCHF的)可信度的参数的UI。
图35示出可以在SEF处提供的示例UI，通过示例而非限制的方式给出：
·用于配置与内容安全性相关的证书请求和注册相关的安全政策的UI
·用于配置证书相关参数的UI。
应理解，示例用户界面可以用于根据需要监视和控制替代参数。将进一步应理解的是，GUI可以通过各种图表或替代的视觉描绘向用户提供用户感兴趣的各种信息。
图36A是在其中可以实现一个或多个所公开的实施例的示例机器对机器(M2M)、物联网(IoT)或万维网(WoT)通信系统10的图。一般而言，M2M技术为IoT/WoT提供构建块，任何M2M设备、M2M网关或M2M服务平台都可能是IoT/WoT的组件，以及IoT/WoT服务层等。图6-35、37和38中任一图所示的客户端或实体可以包括通信系统的节点，例如图36A-D中所示的通信节点。
如图36A所示，M2M/IoT/WoT通信系统10包含通信网络12。通信网络12可以是固定网络(例如以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息、广播等的内容的多个接入网络。例如，通信网络12可以采用一种或多种信道接入方法，例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、载波FDMA(SC-FDMA)等。此外，通信网络12可以包括其它网络，例如核心网、因特网、传感器网络、工业控制网络、个人区域网络、融合的个人网络、卫星网络、家庭网络或企业网络。
如图36A所示，M2M/IoT/WoT通信系统10可以包含基础设施域和场域。基础设施域是指端到端M2M部署的网络侧，而场域是指通常在M2M网关后面的区域网络。场域和基础设施域都可以包括网络的各种不同的节点，例如，服务器、网关、设备。例如，场域可以包含M2M网关14和终端设备18。可以理解，M2M/IoT/WoT通信系统10中可以按需要包含任何数量的M2M网关设备14和M2M终端设备18。M2M网关设备14和M2M终端设备18中的每一个被配置为经由通信网络12和直接无线链路发送和接收信号。M2M网关设备14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)通过诸如通信网络12的运营商网络或直接无线链路通信。例如，M2M设备18可以收集数据并经由通信网络12或直接无线链路将数据发送到M2M应用20或M2M设备18。M2M设备18还可以从M2M应用20或M2M设备18接收数据。此外，如下所述，可以经由M2M服务层22将数据和信号发送到M2M应用20并从M2M应用20接收数据和信号。M2M设备18和网关14可以经由例如包含蜂窝、WLAN、WPAN(例如Zigbee、6LoWPAN，蓝牙)、直接无线链路和有线的各种网络进行通信。示例性的M2M设备包含但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、连接车、智能电表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门和其它基于执行器的设备、安全设备和智能插座。
参考图36B，所示的在场域中的M2M服务层22为M2M应用20、M2M网关设备14和M2M终端设备18以及通信网络12提供服务。应理解，M2M服务层22可以根据需要与任何数量的M2M应用、M2M网关设备14、M2M终端设备18和通信网络12进行通信。M2M服务层22可以由一个或多个服务器、计算机等实现。M2M服务层22提供应用于M2M终端设备18、M2M网关设备14和M2M应用20的服务能力。M2M服务层22的功能可以通过各种方式来实现，例如作为web服务器、在蜂窝核心网中、在云中等。
类似于图示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和下层通信网络12'提供服务。M2M服务层22'还为场域中的M2M网关设备14和M2M终端设备18提供服务。将理解的是，M2M服务层22'可以与任何数量的M2M应用、M2M网关设备和M2M终端设备进行通信。M2M服务层22'可以通过不同的服务提供商与服务层交互。M2M服务层22'可以由一个或多个服务器、计算机、虚拟机(例如云/计算/存储场等)等来实现。
仍参考图36B，M2M服务层22和22'提供各种应用和行业可以利用一组核心的服务交付能力。这些服务能力使得M2M应用20和20'能够与设备交互并且执行诸如数据收集、数据分析、设备管理、安全性、收费、服务/设备发现等的功能。实质上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并降低了成本和上市时间。服务层22和22'还使得M2M应用20和20'能够通过各种网络12和12'与服务层22和22'提供的服务相结合进行通信。
M2M应用20和20'可以包含各种行业中的应用，例如但不限于交通、健康和保健、联网家居、能源管理、资产跟踪以及保安监察。如上所述，运行在系统的设备、网关和其它服务器上的M2M服务层支持诸如数据收集、设备管理、安全性、收费、位置跟踪/地理围栏、设备/服务发现和传统系统集成的功能，并且将这些功能作为服务提供给M2M应用20和20'。
一般来说，服务层(SL)，例如图36A和36B所示的服务层22和22'，定义了通过一组应用编程接口(API)和下层网络接口来支持增值服务能力的软件中间件层。ETSI M2M和oneM2M体系结构定义了服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在ETSI M2M架构的各种不同的节点中实现。例如，服务层的实例可以在M2M设备(其被称为设备SCL(DSCL))、网关(其被称为网关SCL(GSCL))和/或网络节点(其被称为网络SCL(NSCL))内实现。oneM2M服务层支持一组通用服务功能(CSF)(即服务能力)。一组一个或多个特定类型的CSF的实例被称为公共服务实体(CSE)，其可以驻存于不同类型的网络节点(例如，基础设施节点、中间节点、应用特定的节点)上。第三代合作伙伴计划(3GPP)还定义了机器类型通信(MTC)的架构。在所述体系结构中，服务层及其提供的服务能力作为服务能力服务器(SCS)的一部分来实现。无论是在ETSI M2M体系结构的DSCL、GSCL或NSCL中实施；在3GPPMTC体系结构的服务能力服务器(SCS)中实施；在oneM2M体系结构的CSF或CSE中实施；还是在网络的某个其它节点中实施，都可以在网络中的一个或多个独立节点(包含服务器、计算机和其它计算设备或节点)上执行的逻辑实体(例如，软件，计算机可执行指令等)中实现服务层的实例，或作为一个或多个现有节点的一部分。作为示例，服务层或其组件的实例可以在具有下文描述的图36C或36D所示的一般体系结构的网络节点(例如，服务器、计算机、网关，设备等)上运行的软件的形式来实现。
此外，本文描述的方法和功能可以被实现为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问服务的M2M网络的一部分，例如上述网络和应用管理服务。
图36C是网络节点的示例硬件/软件体系结构的框图，所述节点例如是图6-35、37和38中所示的客户端或实体之一，其可以用作M2M服务器、网关、设备或M2M网络(例如图36A和36B中所示的M2M网络)中的其它节点。如图36C所示，节点30可以包含处理器32、收发器34、传输/接收元件36、扬声器/麦克风38、键区40、显示器/触板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片组50以及其它外设52。节点30还可以包含诸如收发器34和传输/接收元件36的通信电路。应理解，在保持与实施例一致的同时，节点30可以包含前述元件的任何子组合。此节点可以是实现在此描述的与其相关的安全保护和方法的节点。
处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理和/或使得节点30能够在无线环境中操作的任何其它功能。处理器32可以耦合到收发器34，收发器34可以耦合到传输/接收元件36。尽管图36C将处理器32和收发器34描绘为分离的组件，但是应理解，处理器32和收发器34可以一起集成在电子封装或芯片中。处理器32可以执行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或通信。处理器32可以例如在接入层和/或应用层处执行安全操作，例如鉴权、安全密钥协定和/或加密操作。
如图36C所示，处理器32耦合到其通信电路(例如，收发器34和传输/接收元件36)。处理器32通过执行计算机可执行指令可以控制通信电路，以便使节点30经由其所连接的网络与其它节点进行通信。具体而言，处理器32可以控制通信电路以便执行本文(例如，图6-35、37和38)和权利要求中描述的传输和接收步骤。尽管图36C将处理器32和收发器34描绘为分离的组件，但是应该理解，处理器32和收发器34可以一起集成在电子封装或芯片中。
传输/接收元件36可以被配置为向其它节点(包含M2M服务器、网关、设备等等)传输信号或从其接收信号。例如，在一个实施例中，传输/接收元件36可以是被配置为传输和/或接收RF信号的天线。传输/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在实施例中，传输/接收元件36可以是例如被配置为传输和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施例中，传输/接收元件36可以被配置为传输和接收RF和光信号。应该理解，传输/接收元件36可以被配置为传输和/或接收无线或有线信号的任何组合。
另外，尽管在图36C中将传输/接收元件36描绘为单个元件，但是节点30可以包含任何数目的传输/接收元件36。更具体地，节点30可以采用MIMO技术。因此，在实施例中，节点30可以包含用于传输和接收无线信号的两个或更多个传输/接收元件36(例如，多个天线)。
收发器34可以被配置为调制将由传输/接收元件36发射的信号，并且解调由传输/接收元件36接收的信号。如上所述，节点30可以具有多模式功能。因此，收发器34可以包含多个收发器，用于使得节点30能够经由例如UTRA和IEEE 802.11的多个RAT进行通信。
处理器32可以从诸如不可移除存储器44和/或可移动存储器46的任何类型的合适存储器访问信息并将数据存储在存储器中。不可移除存储器44可以包含随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其它类型的存储器存储设备。可移除存储器46可以包含订户标识模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可以从物理上不位于节点30上的存储器(例如在服务器或家用计算机上)访问信息并将数据存储在存储器中。处理器32可以被配置为控制显示器或指示器42上的照明模式、图像或颜色，以反映UE(例如，见GUI 1400)、尤其是下层网络、应用或与UE通信的其它服务的状态。处理器32可以从电源48接收电力，并且可以被配置为向节点30中的其它组件分配和/或控制电力。电源48可以是用于向节点30供电的任何合适的设备。例如，电源48可以包含一个或多个干电池(例如，镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。
处理器32还可以耦合到GPS芯片组50，GPS芯片组50被配置为提供关于节点30的当前位置的位置信息(例如，经度和纬度)。将理解，节点30可以通过任何合适的位置确定方法获得位置信息，同时保持与实施例一致。
处理器32还可以耦合到其让它外设52，外设52可以包含提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外设52可以包含加速度计、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动设备、电视收发机、免提耳机、蓝牙模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器等。
图36D是也可以用于实现网络的一个或多个节点(例如图6-35、37和38所示的客户端或实体)的示例性计算系统90的框图，所述节点可以作为M2M服务器、网关、设备、或M2M网络中的其它节点(诸如图36A和36B中所示)进行操作。计算系统90可以包括计算机或服务器，并且可以主要由计算机可读指令来控制，所述计算机可读指令可以呈软件的形式，无论何处或以何种方式存储或访问此类软件。此类计算机可读指令可以在中央处理单元(CPU)91内执行以使计算系统90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于安全性保护的系统和方法有关的数据。
在操作中，CPU 91提取、解码和执行指令，并通过计算机的主数据传输路径-系统总线80将信息传递给其它资源或从其它资源传递信息。此类系统总线连接计算系统90中的组件，并定义用于数据交换的介质。系统总线80通常包含用于发送数据的数据线、用于发送地址的地址线以及用于发送中断和用于操作系统总线的控制线。此类系统总线80的一个示例是PCI(外设组件互连)总线。
耦合到系统总线80的存储器设备包含随机存取存储器(RAM)82和只读存储器(ROM)93。此类存储器包含允许存储和检索信息的电路。ROM 93一般包含无法轻易被修改的存储数据。存储在RAM 82中的数据可以被CPU 91或其它硬件设备读取或改变。对RAM 82和/或ROM 93的访问可以由存储器控制器92控制。存储器控制器92可以提供地址转换功能，其在指令执行时将虚拟地址转换为物理地址。存储器控制器92还可以提供存储器保护功能，其隔离系统内的过程并将系统过程与用户过程隔离。因此，以第一模式运行的程序只能访问由其自己的进程虚拟地址空间映射的存储器；除非进程之间的存储器共享已经建立，否则它不能访问另一进程的虚拟地址空间中的存储器。
另外，计算系统90可以包含外设控制器83，所述外设控制器83负责将来自CPU91的指令传送到外设，例如打印机94、键盘84、鼠标95和磁盘驱动器85。
由显示器控制器96控制的显示器86用于显示由计算系统90产生的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸板来实现。显示控制器96包含生成被发送到显示器86的视频信号所需的电子组件。
此外，计算系统90可以含有通信电路，例如可以用于将计算系统90连接到外部通信网络(例如图36A和图36B的网络12)的网络适配器97，以使得计算系统90能够与网络中的其它节点进行通信。通信电路单独地或与CPU91一起可用于执行本文和权利要求中所述的传输和接收步骤(例如图6-35、37和38)。
应该理解，这里描述的任何方法和过程可以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式来体现，所述指令在由机器(例如计算机、服务器、M2M终端设备、M2M网关设备等)执行时，执行和/或实现本文描述的系统、方法和过程。具体而言，上述的任何步骤、操作或功能可以此类计算机可执行指令的形式来实现。计算机可读存储介质包含以用于存储信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质，但是此类计算机可读存储介质不包含信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储技术、CD-ROM、数字多功能光盘(DVD)或其它光盘存储、磁带盒、磁带、磁盘存储或其它磁性存储设备，或可用于存储所需信息并可由计算机访问的任何其它物理介质。
在描述本公开的主题的优选实施例时，如附图所示，为了清楚起见，采用了特定的术语。然而，所要求保护的主题不旨在被限制于如此选择的特定术语，并且应该理解，每个特定元件包含以类似方式操作以实现类似目的的所有技术等同物。
以下是可能出现在以上描述中的与服务级别技术有关的缩略词的列表。除非另外指明，否则本文使用的首字母缩写词是指以下列出的相应术语。
ACP 访问控制政策
AE 应用实体
AEAD 具有关联数据的鉴权加密
AES 高级加密标准
AES-GCM AES–Galois模式
Cert 数字证书
CCF 内容建立功能
CCP 内容建立过程
CCSDF 内容建立和安全性确定功能
CDB 证书数据库
CHF 内容托管功能
CLMP 内容生命周期管理过程
CR 证书注册
CGP 证书注册过程
CQP 证书申请过程
CP 内容处理
CRP 内容检索过程
CRRP 证书申请和注册过程
DES 数字加密标准
DS 数字签名
DTLS 数据报传输层安全性
ECC 椭圆曲线密码体制
E2E 端到端
IoT 物联网
IPSec 因特网协议安全性
JWA JSON Web算法
JWE JSON Web加密
JWK JSON Web密钥
JWS JSON Web签名
JWT JSON Web令牌
KDF 密钥导出功能
M2M 机器对机器
MAC 信息鉴权码
MEF M2M登记功能
NTP 网络时间协议
PCS 受保护内容存储库
PKI 公钥基础设施
PSK 预共享密钥
RoT 信任根
RSA Rivest-Shamir-Addleman算法
SCHF 安全内容托管功能
SDF 安全性确定功能
SE 安全元件
SEF 安全启用功能
SESC 服务支持和安全性配置
SHRP 安全托管申请过程
SL 服务层
SP 服务提供商
SPDP 安全性参数确定功能
TEE 可信执行环境
TLS 传输层安全性
TTP 可信第三方
本书面描述使用示例来公开本发明，包括最佳模式，并且还使得所属领域的技术人员能够实践本发明，包括制造和使用任何装置或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括所属领域的技术人员想到的其它示例。如果这样的其它示例具有不与权利要求的字面语言不同的结构要素，或者如果它们包括与权利要求的字面语言无实质区别的等同结构要素，则这样的其它示例意图在权利要求的范围内。

Claims (20)

1.一种包括处理器、存储器和通信电路的装置，所述装置经由其通信电路连接到网络，所述装置还包括存储于所述装置的所述存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的所述处理器执行时使所述装置执行包括下述的操作：
从第一应用接收建立资源的第一请求，该资源用于托管与所述第一应用相关联的安全内容；
确定所述第一应用是否被授权在所述装置建立所述资源；以及
如果所述第一个应用被授权，则托管所述安全内容。
2.根据权利要求1所述的装置，其中所述第一应用被与所述装置分离的公共服务实体授权建立所述资源。
3.根据权利要求2所述的装置，其中所述请求包含由所述公共服务实体生成的证书标识。
4.根据权利要求1所述的装置，所述装置还包括计算机可执行指令，所述计算机可执行指令使所述装置执行包括下述的进一步操作：
从第二应用接收访问所述安全内容的第二请求；
确定所述第二应用是否被授权访问所述安全内容；以及
如果所述第二应用被授权访问所述安全内容，则发送所述安全内容给所述第二应用。
5.根据权利要求4所述的装置，其中当所述公共服务实体向所述第二应用发送与所述安全内容相关联的一个或多个证书时，所述安全内容能被解密。
6.根据权利要求4所述的装置，其中所述第二应用被授权通过所述第一应用的访问控制政策来访问所述安全内容。
7.一种包括处理器、存储器和通信电路的装置，所述装置经由其通信电路连接到网络，所述装置还包括存储于所述装置的所述存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的所述处理器执行时使所述装置执行包括下述的操作：
发送对一个或多个证书的请求，所述证书提供内容的保护，所述请求基于与所述内容相关联的一个或多个安全性参数；
获得所述一个或多个证书；以及
使用所述一个或多个证书来保护所述内容。
8.根据权利要求7所述的装置，其中所述一个或多个证书包括用于对称密钥保密性保护的主密钥。
9.根据权利要求7所述的装置，其中所述一个或多个证书用于完整性保护和保密性保护。
10.根据权利要求7所述的装置，所述装置还包括使所述装置执行下述的进一步操作的计算机可执行指令：
加密所述内容以建立加密的内容。
11.根据权利要求10所述的装置，所述装置还包括使所述装置执行下述的进一步操作的计算机可执行指令：
生成与所述内容相关联的鉴权标签，其中所述鉴权标签指示所述内容的完整性和真实性以用于在托管公共服务实体处托管。
12.根据权利要求10所述的装置，所述装置还包括使所述装置执行下述的进一步操作的计算机可执行指令：
向托管公共服务实体发送建立含有所述加密的内容和所述安全性参数的资源的请求。
13.根据权利要求7所述的装置，其中所述装置是应用实体，并且所述证书是从信任启用功能获得的。
14.根据权利要求13所述的装置，其中被授权获得所述内容的第二应用实体能够从所述信任启用功能获得所述一个或多个证书。
15.一种包括处理器、存储器和通信电路的装置，所述装置经由其通信电路连接到网络，所述装置还包括存储于所述装置的所述存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的所述处理器执行时使所述装置执行包括下述的操作：
基于与内容相关联的安全性要求，生成一个或多个证书；
使用所述一个或多个证书来保护所述内容；以及
发送托管节点存储所述安全内容的请求，使得只有被授权客户端才能从所述托管节点检索所述内容。
16.根据权利要求15所述的装置，所述装置还包括使所述装置执行下述的进一步操作的计算机可执行指令：
用信任启用功能注册所述一个或多个证书。
17.根据权利要求16所述的装置，其中通过引导所述装置与信任执行功能之间的关联来生成所述一个或多个证书。
18.根据权利要求16所述的装置，所述装置还包括使所述装置执行下述的进一步操作的计算机可执行指令：
响应于所述请求，从所述信任启用功能接收证书标识，其中所述请求包括与所述证书标识相关联的证书，并且所述请求寻求所述证书的注册。
19.根据权利要求18所述的装置，其中所述证书标识对于所述公共服务实体是独特的。
20.根据权利要求15所述的装置，所述装置还包括使所述装置执行下述的进一步操作的计算机可执行指令：
如果所述托管节点确定所述装置被授权在所述托管节点建立资源，则接收成功消息。
CN201680039249.0A 2015-07-02 2016-06-30 用于服务层的内容安全性的装置 Active CN107852405B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562188141P 2015-07-02 2015-07-02
US62/188,141 2015-07-02
US201562248808P 2015-10-30 2015-10-30
US62/248,808 2015-10-30
PCT/US2016/040438 WO2017004391A1 (en) 2015-07-02 2016-06-30 Content security at service layer

Publications (2)

Publication Number Publication Date
CN107852405A true CN107852405A (zh) 2018-03-27
CN107852405B CN107852405B (zh) 2021-02-02

Family

ID=56557891

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201680039249.0A Active CN107852405B (zh) 2015-07-02 2016-06-30 用于服务层的内容安全性的装置

Country Status (6)

Country Link
US (4) US10637836B2 (zh)
EP (2) EP4236411A3 (zh)
JP (2) JP6595631B2 (zh)
KR (1) KR102116399B1 (zh)
CN (1) CN107852405B (zh)
WO (1) WO2017004391A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110198318A (zh) * 2019-06-03 2019-09-03 浪潮云信息技术有限公司 一种容器服务用户认证方法
CN110602112A (zh) * 2019-09-19 2019-12-20 四川长虹电器股份有限公司 一种mqtt安全传输数据的方法
CN112543181A (zh) * 2020-11-03 2021-03-23 开放智能机器（上海）有限公司 一种通过网络鉴权安全认证设备的系统和方法

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10129031B2 (en) * 2014-10-31 2018-11-13 Convida Wireless, Llc End-to-end service layer authentication
CA2975151A1 (en) * 2015-03-03 2016-09-09 Purple Deck Media, Inc. A networked computer system for remote rfid device management and tracking
KR102001753B1 (ko) 2015-03-16 2019-10-01 콘비다 와이어리스, 엘엘씨 공개 키잉 메커니즘들을 사용한 서비스 계층에서의 종단간 인증
US10956880B2 (en) * 2015-07-01 2021-03-23 Paypal, Inc. Mixed deployment architecture for distributed services
US10320760B2 (en) * 2016-04-01 2019-06-11 Cisco Technology, Inc. Method and system for mutating and caching content in a content centric network
US10341436B2 (en) * 2016-09-14 2019-07-02 Dell Products L.P. Using cloud storage as temporary cache for backup
US10810185B2 (en) * 2016-09-22 2020-10-20 At&T Intellectual Property I, L.P. Temporary shared storage
US10374809B1 (en) 2016-12-13 2019-08-06 Amazon Technologies, Inc. Digital signature verification for asynchronous responses
JP6719413B2 (ja) * 2017-03-28 2020-07-08 株式会社Ｋｄｄｉ総合研究所 セキュリティゲートウェイ装置、方法、及びプログラム
JP6910824B2 (ja) * 2017-03-28 2021-07-28 Ｎｅｃネッツエスアイ株式会社 情報提供システム及び情報提供方法
US10805349B2 (en) 2017-03-29 2020-10-13 At&T Intellectual Property I, L.P. Method and system to secure and dynamically share IOT information cross multiple platforms in 5G network
CN111034156B (zh) 2017-09-08 2023-02-17 康维达无线有限责任公司 机器对机器通信网络中的自动服务注册
CN107707354A (zh) * 2017-10-16 2018-02-16 广东工业大学 一种基于椭圆曲线加密法的云存储数据验证方法及系统
EP3711274B1 (en) * 2017-12-28 2024-04-24 Siemens Aktiengesellschaft Message queuing telemetry transport (mqtt) data transmission method, apparatus, and system
US10225360B1 (en) 2018-01-24 2019-03-05 Veeva Systems Inc. System and method for distributing AR content
US11018871B2 (en) * 2018-03-30 2021-05-25 Intel Corporation Key protection for computing platform
WO2019211517A1 (en) * 2018-05-03 2019-11-07 Nokia Technologies Oy Method and apparatus for network function messaging
WO2020053480A1 (en) * 2018-09-10 2020-03-19 Nokia Technologies Oy Method and apparatus for network function messaging
US11695761B2 (en) * 2019-06-04 2023-07-04 ZPE Systems, Inc. Secure access of remote device
CN110531961B (zh) * 2019-07-24 2023-05-23 百度在线网络技术（北京）有限公司 智能服务破壳系统及其方法
WO2021087494A1 (en) * 2019-11-03 2021-05-06 Valimail Inc. Centralized secure distribution of messages and device updates
US12010116B2 (en) * 2020-12-03 2024-06-11 ZPE Systems, Inc. Secure access of remote device
US12047488B2 (en) 2021-03-26 2024-07-23 Microsoft Technology Licensing, Llc Tag aggregation and correction to support interleaved encryption and authentication operations on multiple data records
US12074857B2 (en) * 2021-03-26 2024-08-27 Microsoft Technology Licensing, Llc Partial authentication tag aggregation to support interleaved encryption and authentication operations on multiple data records
KR102357954B1 (ko) * 2021-05-13 2022-02-08 아우토크립트 주식회사 V2x 환경을 위한 키와 인증서에 대한 안전하고 자동화된 부트스트래핑 방법 및 장치
US11695772B1 (en) * 2022-05-03 2023-07-04 Capital One Services, Llc System and method for enabling multiple auxiliary use of an access token of a user by another entity to facilitate an action of the user
EP4432141A1 (en) * 2023-03-13 2024-09-18 Mastercard International Incorporated Credential management in a decentralized heterogeneous transaction system
CN116405293B (zh) * 2023-04-07 2023-09-01 光谷技术有限公司 安全运维系统的数据加密存储方法
US11941262B1 (en) * 2023-10-31 2024-03-26 Massood Kamalpour Systems and methods for digital data management including creation of storage location with storage access ID

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030074580A1 (en) * 2001-03-21 2003-04-17 Knouse Charles W. Access system interface
CN101341691A (zh) * 2005-12-22 2009-01-07 微软公司 授权与验证
CN102143134A (zh) * 2010-08-05 2011-08-03 华为技术有限公司 分布式身份认证方法、装置与系统
US20130095459A1 (en) * 2006-05-12 2013-04-18 Bao Tran Health monitoring system
CN103210627A (zh) * 2010-11-15 2013-07-17 交互数字专利控股公司 证书认证和信道绑定
CN103532981A (zh) * 2013-10-31 2014-01-22 中国科学院信息工程研究所 一种面向多租户的身份托管鉴权云资源访问控制系统及控制方法
US20150033312A1 (en) * 2013-07-25 2015-01-29 Convida Wireless, Llc End-To-End M2M Service Layer Sessions
US20150032795A1 (en) * 2013-07-29 2015-01-29 Verizon Patent And Licensing Inc. One touch machine to machine device connection
EP2890073A1 (en) * 2013-12-31 2015-07-01 Gemalto SA System and method for securing machine-to-machine communications

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7356694B2 (en) * 2004-03-10 2008-04-08 American Express Travel Related Services Company, Inc. Security session authentication system and method
US8041677B2 (en) 2005-10-12 2011-10-18 Datacastle Corporation Method and system for data backup
US8402526B2 (en) 2008-05-27 2013-03-19 Open Invention Network Llc System integrating an identity selector and user-portable device and method of use in a user-centric identity management system
US8527950B2 (en) * 2008-08-12 2013-09-03 International Business Machines Corporation Verification of software applications
US20100251353A1 (en) 2009-03-25 2010-09-30 Novell, Inc. User-authorized information card delegation
KR101684753B1 (ko) 2010-02-09 2016-12-08 인터디지탈 패튼 홀딩스, 인크 신뢰적인 연합 아이덴티티를 위한 방법 및 장치
US9736873B2 (en) 2010-06-25 2017-08-15 Interdigital Patent Holdings, Inc. Interface of an M2M server with the 3GPP core network
US20120072848A1 (en) * 2010-09-20 2012-03-22 Sony Corporation System and method for social collection
KR20120067459A (ko) 2010-12-16 2012-06-26 삼성전자주식회사 서비스 제공업체와 이동망 사업자간의 기기간 단말별 서비스 인증 방법 및 장치
EP2814289A4 (en) 2012-02-06 2015-12-16 Samsung Electronics Co Ltd METHOD AND APPARATUS FOR ENABLING THE SLEEP MODE OF A TERMINAL
US9424432B2 (en) * 2012-09-20 2016-08-23 Nasdaq, Inc. Systems and methods for secure and persistent retention of sensitive information
CN105210344B (zh) 2013-05-16 2018-09-18 Lg电子株式会社 在m2m通信系统中的定制和通知方法和用于该方法的设备
JP5973971B2 (ja) * 2013-08-15 2016-08-23 日本電信電話株式会社 マシンツーマシン制御システム及び方法
US10182351B2 (en) 2013-11-29 2019-01-15 Lg Electronics Inc. Method for service subscription resource-based authentication in wireless communication system
US9813400B2 (en) * 2014-11-07 2017-11-07 Probaris Technologies, Inc. Computer-implemented systems and methods of device based, internet-centric, authentication

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030074580A1 (en) * 2001-03-21 2003-04-17 Knouse Charles W. Access system interface
CN101341691A (zh) * 2005-12-22 2009-01-07 微软公司 授权与验证
US20130095459A1 (en) * 2006-05-12 2013-04-18 Bao Tran Health monitoring system
CN102143134A (zh) * 2010-08-05 2011-08-03 华为技术有限公司 分布式身份认证方法、装置与系统
CN103210627A (zh) * 2010-11-15 2013-07-17 交互数字专利控股公司 证书认证和信道绑定
US20150033312A1 (en) * 2013-07-25 2015-01-29 Convida Wireless, Llc End-To-End M2M Service Layer Sessions
US20150032795A1 (en) * 2013-07-29 2015-01-29 Verizon Patent And Licensing Inc. One touch machine to machine device connection
CN103532981A (zh) * 2013-10-31 2014-01-22 中国科学院信息工程研究所 一种面向多租户的身份托管鉴权云资源访问控制系统及控制方法
EP2890073A1 (en) * 2013-12-31 2015-07-01 Gemalto SA System and method for securing machine-to-machine communications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
高同，朱佳佳，罗圣美，孙知信: "M2M功能架构与安全研究", 《计算机技术与发展》 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110198318A (zh) * 2019-06-03 2019-09-03 浪潮云信息技术有限公司 一种容器服务用户认证方法
CN110602112A (zh) * 2019-09-19 2019-12-20 四川长虹电器股份有限公司 一种mqtt安全传输数据的方法
CN112543181A (zh) * 2020-11-03 2021-03-23 开放智能机器（上海）有限公司 一种通过网络鉴权安全认证设备的系统和方法
CN112543181B (zh) * 2020-11-03 2023-05-09 开放智能机器（上海）有限公司 一种通过网络鉴权安全认证设备的系统和方法

Also Published As

Publication number Publication date
US20240121227A1 (en) 2024-04-11
JP2020025278A (ja) 2020-02-13
US10637836B2 (en) 2020-04-28
WO2017004391A1 (en) 2017-01-05
US11240212B2 (en) 2022-02-01
EP4236411A3 (en) 2023-10-04
JP6923611B2 (ja) 2021-08-25
KR102116399B1 (ko) 2020-05-29
JP6595631B2 (ja) 2019-10-23
EP3318037B1 (en) 2023-06-21
EP4236411A2 (en) 2023-08-30
CN107852405B (zh) 2021-02-02
JP2018523933A (ja) 2018-08-23
US20200287876A1 (en) 2020-09-10
US20220109660A1 (en) 2022-04-07
KR20180025923A (ko) 2018-03-09
EP3318037A1 (en) 2018-05-09
US11811740B2 (en) 2023-11-07
US20170005999A1 (en) 2017-01-05

Similar Documents

Publication Publication Date Title
CN107852405A (zh) 服务层的内容安全性
Yazdinejad et al. Blockchain-enabled authentication handover with efficient privacy protection in SDN-based 5G networks
US10601594B2 (en) End-to-end service layer authentication
CN107409137B (zh) 用于使用应用专用网络接入凭证到无线网络的受担保连通性的装置和方法
US11736304B2 (en) Secure authentication of remote equipment
CN107534658A (zh) 使用公钥机制在服务层的端对端认证
Oktian et al. BorderChain: Blockchain-based access control framework for the Internet of Things endpoint
TW201216734A (en) Method and apparatus for trusted federated identity
CN105429962B (zh) 一种通用的面向加密数据的中间网络服务构建方法与体系
Shen et al. Toward data privacy preservation with ciphertext update and key rotation for IoT
US20190173880A1 (en) Secure node management using selective authorization attestation
Rizzardi et al. Analysis on functionalities and security features of Internet of Things related protocols
Faisal et al. Cyber security and key management issues for internet of things: Techniques, requirements, and challenges
KR102118556B1 (ko) 프라이빗 블록체인 기반 개인정보 관리 서비스 제공 방법
US11848763B2 (en) Secure ad-hoc deployment of IoT devices in a secure peer-to-peer data network
Santos Secure Wifi Portals in WIFI4EU Environment
Barnickel Authentication and identity privacy in the wireless domain
Heikkinen Applicability of Host Identities in Securing Network Attachment and Ensuring Service Accountability
Primc Naslavljanje overovljenih identitet

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant