CN113596828A - 端对端服务层认证 - Google Patents

端对端服务层认证 Download PDF

Info

Publication number
CN113596828A
CN113596828A CN202110936616.XA CN202110936616A CN113596828A CN 113596828 A CN113596828 A CN 113596828A CN 202110936616 A CN202110936616 A CN 202110936616A CN 113596828 A CN113596828 A CN 113596828A
Authority
CN
China
Prior art keywords
entity
message
certificate
authentication
service layer
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
CN202110936616.XA
Other languages
English (en)
Other versions
CN113596828B (zh
Inventor
维诺德·库马尔·乔伊
黛尔·N·希德
卡坦利纳·M·姆拉丁
王重钢
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
Priority to CN202110936616.XA priority Critical patent/CN113596828B/zh
Publication of CN113596828A publication Critical patent/CN113596828A/zh
Application granted granted Critical
Publication of CN113596828B publication Critical patent/CN113596828B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • 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/0464—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 using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
    • 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/0478—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 applying multiple layers of encryption, e.g. nested tunnels or encrypting the content with a first key and then with at least a second key
    • 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
    • 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/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • 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
    • 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)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

本公开涉及端对端服务层认证。使用在具有不同能力(例如预处理、存储器等)并且具有非先验安全关联的实体之间执行端对端认证的各种机制。完成安全提供和配置过程，使得可以将适当的安全证书、功能、作用域和参数提供给实体。开发将安全证书分发给其它实体、然后其它实体能使用证书来在服务层或会话层并且使用直接或委托模式执行端对端认证的机制。

Description

端对端服务层认证
本分案申请是2015年10月30日递交的题为“端对端服务层认证”的中国专利申请NO.201580067913.8的分案申请。
相交申请的交叉引用
本申请要求2014年10月31日提交的U.S.临时申请序列号No.62/073,578的优先权，其全部内容通过引用并入于此。
背景技术
机器对机器(M2M)技术允许设备使用有线和无线通信系统来彼此更直接地进行通信。M2M技术使得能够进一步实现物联网(IoT)，一种唯一可识别物体的系统以及在诸如互联网的网络上进行通信的这些物体的虚拟表示。IoT可以促进与甚至平凡的诸如杂货店中的产品的日常物体的通信，并且从而通过提高对这些物体的了解来减少成本和浪费。例如，商店可以通过能够与可能在库存中或者可能已被出售的物体进行通信或从其获取数据来维持非常精确的库存数据。如将理解，IoT具有包括数百万个设备的潜力。
图1A是图示出示例性oneM2M功能架构100的图。发展中的oneM2M标准定义了如图1A-B中所图示的被称作“公共服务实体(CSE)”的服务层。该服务层的目的在于提供能够由不同的诸如电子保健、车队管理和智能家庭的“垂直”M2M孤岛系统和应用利用的“水平”服务。CSE支持四个参考点。Mca参考点与应用实体(AE)接口对接。Mcc参考点与同一服务提供商域内的另一CSE对接，且Mcc’参考点与不同的服务提供商域中的另一CSE对接。Mcn参考点与底层网络服务实体(NSE)对接。NSE向CSE提供底层网络服务，诸如设备管理、位置服务和设备触发。CSE包含被称作“公共服务功能(CSF)”的多个逻辑功能，诸如“发现”、“数据管理&储存库”。
图1B是图示oneM2M架构的发展中的CSF的图。
oneM2M实现以下类型的节点：应用服务节点(ASN)、应用专用节点(ADN)、中间节点(MN)以及基础设施节点(IN)。
应用服务节点(ASN)是包含一个CSE并且包含至少一个AE的节点。物理映射的示例是驻留在M2M设备中的ASN。
应用专用节点(ADN)是包含至少一个AE并且不包含CSE的节点。物理映射的示例是驻留在受限M2M设备中的ADN。
中间节点(MN)是包含一个CSE并且包含零个或更多个AE的节点。物理映射的示例是驻留在M2M网关中的MN。
基础设施节点(IN)是包含一个CSE并且包含零个或更多个AE的节点。物理映射的示例是驻留在M2M服务基础设施中的IN。
目前，当oneM2M终端节点希望以安全方式彼此通信时，节点和中间节点以逐跳方式彼此建立安全关联。可以借助对称密钥、使用证书或通过可以由直接过程或借助基础设施执行的引导过程建立逐跳安全关联。同时，TS-0003-安全解决方案文档声称：“在服务层级，安全关联建立导致TLS或DTLS会话，其保护在相邻AE/CSE之间交换的消息，即，逐跳。可以提供需要保护其信息交换的隐私免受非信任中间节点损害的AE以支持它们之间的直接安全关联。”
发明内容
使用各种执行具有不同能力(例如处理、存储器等)并且不具有先验安全关联的实体之间的端对端认证的机制。完成安全提供和配置过程，使得可以将适当的安全证书、功能、作用域和参数提供给实体。使用将安全证书分发给其它实体，然后其它实体能使用证书来在服务层处执行端对端认证并且使用直接或委托模式的机制。
提供该发明内容以简化的方式介绍在下文的详细描述中进一步描述原理的选择。该概述不旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用来限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任一部分中提到的任一或所有缺点的局限。
附图说明
从结合附图以示例的方式给出的下述描述可获得更详细的理解，其中：
图1A-B是oneM2M服务层的图。
图2是图示端对端(E2E)安全阶段的图。
图3A-B是图示实体A和实体B之间的示例E2E操作的图。
图4A-B是图示oneM2M实施例的图。
图5A-B是图示安全证书请求和提供(SCRP)阶段的图。
图6A-B是图示第三方证书请求阶段的图。
图7A-B图示AE1请求对在CSE3上托管的远程资源的更新操作的E2E认证。
图8A-B是图示使用委托模式方法的在服务层处的E2E认证的图。
图9是图示使用委托模式的在会话层(DTLS/TLS)处执行的E2E认证的图。
图10是图示使用直接模式的在会话层处的E2E认证的图。
图11A-B是图示组认证的图。
图12是图示一个实施例的界面的图。
图13是示出针对端对端消息认证的MAC的创建的图。
图14是图示一个实施例的引导过程的图。
图15A-B是图示与AE的资源表示关联和具有属性逐跳安全证书和端对端证书的<securityParameters>资源结构的图。
图16A-C是图示实体配置文件、设备配置文件和安全配置文件的资源表示的图。
图17是图示借助对称密钥的端对端消息认证和完整性校验的图。
图18是图示借助在作为彼此远离的多个服务层跳的两个实体AE2和CSE1之间的对称密钥机制的端对端消息认证和完整性校验以及消息机密性两者的图。
图19是图示借助在通过信任的或不太可信的或甚至不可信的中间跳来回移动的作为彼此远离的多个服务层跳的两个实体AE2和CSE1之间的对称密钥机制的端对端消息认证和完整性校验以及消息机密性两者的图。
图20是图示实体AE1发起与CSE或服务提供的注册过程并且包括对逐跳和/或端对端安全提供适当的安全证书的图。
图21A是示例机器对机器(M2M)或物联网(IoT)通信系统的图，其中，可实现IoT事件管理系统和方法的一个或多个公开的实施例。
图21B是在图21A中所示的M2M/IoT通信系统内可使用的示例架构的系统图。
图21C是在图21A中所示的通信系统内可使用的示例M2M/IoT终端或网关设备的系统图。
图21D是其中可体现图21A的通信系统的方面的示例计算系统的框图。
具体实施方式
当前oneM2M规范仅提供逐跳认证，因此，不能由托管资源的实体明确地认证请求在远程托管的服务/资源上执行CRUD(创建、检索、更新、删除)操作的实体。问题包括：
·托管资源的实体不能完全地认证正尝试在资源上执行操作的实体，因为目标实体仅能够认证离它一跳的实体，因此，不能容易地实施访问控制。
·因为逐跳机制，任何中间实体(例如，MN-CSE、IN-CSE)可能能够代表其它中间实体模仿消息。
·由于打算使用(D)TLS保护逐跳机制，在每一跳将必须建立(D)TLS会话，在会话/服务层导致每一跳处的完整性保护和认证以及每一跳处的可能加密和解密，因此，还导致另外的操作开销。仅由每一跳中包含的2个实体完成安全提供和安全关联建立过程。
图2是图示端对端(E2E)安全阶段的图。执行端对端认证过程可能需要下述步骤：
图2的步骤1示出服务使能和安全配置过程。在该步骤，实体A 202与服务使能功能(SEF)204建立关联。建立的关联可以是带内或带外，还可以包含建立关联之前的相互认证过程。作为关联建立过程的一部分，SEF 204识别由实体A 202 202请求或提供的服务的性质。同时，还由SEF 204识别由实体A 202要求或请求的安全需求和特征。简单地说，实体A202的安全配置文件(SP)以及(可选地)隐私配置文件(PP)从实体A 202获得，或由SEF确定/推断和创建或从第三实体获得。基于部署情形，每一实体可以具有不同的SP(其可以由唯一SP-ID识别)以及(可选地)由PP-ID识别的关联PP。
图2的步骤2示出安全证书提供过程。基于识别的SP和相应的安全需求和特征，为实体A 202提供适当的安全证书。发布给实体A 202的安全证书由它使用来执行想与其建立安全关联的实体的认证。此外，创建可以被提供有实体的E2E证书的授权实体的列表。在某些情形下，在安全证书提供过程期间，仅将生成安全证书所需的播种(seeding)材料提供给实体A 202。播种材料还可以与证书引导过程一起使用，以便生成适当的端对端安全(端对端消息认证、端对端消息机密性)证书。引导过程可以基于存在于下层(例如网络层/MAC层)处的安全关联或基于与高层(例如应用层或服务层)的现有安全关联。在不存在现有的安全关联的一些情况下，那么必须在生成端对端安全证书前执行新鲜(fresh)引导过程(例如基于GBA、MEF)。
图2的步骤3示出第三方证书请求过程。还可以为另一实体N提供由实体A 202建立的安全证书，以便可以在实体N 208和实体A 202之间建立安全关联，使得实体N 208能访问由实体A 202提供的服务/资源，且反之亦然。仅对授权被提供证书的那些实体提供证书。
图2的步骤4示出端对端认证过程：在该步骤中，实体A 202和实体N 208可以在直接两个实体之间或(可选地)借助另一个实体(例如SEF)实现，来执行端对端认证过程。
理解到执行图2所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图2所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图2所示的步骤。还理解到可以通过在节点的处理器及其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图2所示的任何发送和接收步骤。
服务使能和安全配置(SESC)过程
在SCSC步骤期间，SEF 204确定将适合于实体A的工作的适当的安全需求和特征。可以由SEF 204基于由实体提供的SP和PP确定安全需求和特征。可以使用一些推断过程创建或由实体明确地提供或由建立该系统的个人(例如管理员)配置SP以及(可选地)PP。
Figure BDA0003213446000000071
表1：实体A的示例安全配置文件(SP)
表1中描绘示例SP，其可以作为SESC过程的一部分由实体提供给SEF 204。替选地，可以基于由实体提供的服务类型，由SEF推断SP。在其它情况下，SP可以由特定实体的管理员配置，其然后由SEF从第三方(诸如服务/网络提供商)的服务器提取。
设备能力 值
处理能力 900MHz
RAM 500Kb
闪存 1MB
电池 5.0微-W/MHz
无线能力 蓝牙，WiFi
睡眠模式 睡眠/深度睡眠
安全环境 是
信任平台模块(TPM) 否
OS/版本 安卓/Kitkat
表2：实体A的示例设备配置文件(DP)
实体A 202可以提供其上托管实体的设备配置文件(DP)。表2描绘由实体202提供给SEF 204的、或(如果在与实体202相同的设备上实现SEF 204)由SEF通过查询设备的操作系统获得的示例DP。替选地，SEF 204可以从第三实体获得DP。
实体配置文件 值
服务类 健康护理
服务类型 实时
影响 关键(生命危险)
安全级 高
隐私级 高
表3：实体A的示例实体配置文件(EP)
实体202还可以另外将实体配置文件(EP)或应用配置文件(AP)提供给SEF 204。在该文档的剩余部分，可以可互换地使用术语EP和AP。在表3中描绘示例EP/AP。替选地，SEF204可以推断EP或从第三实体获得EP。实体是属于“健康护理”的应用，提供“实时”服务和具有“关键”影响，要求“高”安全性和“高”隐私。在某些情况下，SEF可以仅使用EP和DP以直接确定SP或安全需求。
实体配置文件 值
服务类 智能家居
服务类型 近实时
影响 低
安全级 中
隐私级 低
表4：实体B的示例EP
表4描绘另一实体(实体B)的示例AP或EP。该实体是属于智能家居的应用，具有如果该系统将要失败则被认为“低”的影响，并且具有“中”安全配置文件和“低”隐私影响。
SEF 204可以使用SP、DP和EP，以便确定适合于实体202的安全需求。可以通过使用在SP和/或DP和/或EP内提供的信息的组合，执行确定安全需求的推断过程。当任一配置文件不存在时，那么SEF204使用基于其有权访问的配置文件的最佳判断。在SEF 204可能无权访问配置文件的情况下，其可以从第三实体获得配置文件。为了SEF204确定适当的安全需求且因此确定安全特征，最低程度上可以要求对EP和DP的访问。然后，SEF 204可以使用EP和DP来创建SP。如果实体202能够提供SP或SEF 204能够获得，那么SEF 204将能够创建更细粒度的安全需求列表。对SEF 204来说，有权访问实体A 202的SP、DP和EP以便其能确定非常详细的安全需求是理想的。
基于由实体提供的上述信息，可以确定适当的安全需求。SEF 204可以基于由SP高亮的所需的安全、由DP提供的设备能力和由实体借助EP提供的服务类型的组合，选择适当的安全需求。
Figure BDA0003213446000000091
表5：由用于实体A的SEF推断的安全需求类似地，在表6中示出由实体B的SEF推断的安全需求。
Figure BDA0003213446000000101
表6：由用于实体B的SEF推断的安全需求在表7中示出详细安全特征。
Figure BDA0003213446000000102
Figure BDA0003213446000000111
表7：实体B的详细安全特征
因此，可以适当地选择仅提供要求“低”安全性的服务，然后安全功能、选择的算法和密钥大小的低功率、低存储器的设备。例如，选择的消息认证机制可以是具有160位密钥的HMAC-SHA1，而将为具有更高处理和存储器并且要求更高安全性的实体提供可以与HMAC-SHA2机制一起使用的256位密钥。按顺序或优先级由SEF推断或由实体A 202提供的安全需求的列表：
·消息认证和/或信令/控制消息的完整性
ο支持的算法：HMAC-SHA2(优选)
ο密钥长度：256/512/1024…
·数据机密性
ο支持的算法：AES、DES....
ο密钥长度：128/256/512…
·数据完整性：必需
·认证机制：
ο对称密钥和/或
ο证书和/或
ο引导过程
·支持未认证用户的能力
·支持协议：EAP/IPSec/(D)TLS/JWT
·认证：直接/委托/部分委托法
在SESC过程结束时，SEF 204具有实体的完整的配置文件和能力。具有实体的能力的知识，帮助SEF 204确定必须实施的适当的安全措施和特征以便保护实体的工作、由实体提供的数据和服务和与实体的通信。SEF 204维护实体的能力表。在SEF处维护的示例表如下：
表8：每一实体支持的安全特征和功能安全证书提供(SCP)过程
SCP过程可以包含安全证书请求过程和安全证书提供过程的步骤。
可以由实体或由SEF 204代表实体发起安全证书请求过程过程。基于由实体提供的能力和/或服务类型，向优选在受信第三方(TTP)上托管的密钥推导功能(KDF)206请求适当的安全证书，以及另外地其它的配置参数。实体和TTP之间的认证是可选的。SEF 204可以执行KDF 206的角色，然而，从可扩展观点看，可以由不同的实体执行TTP/KDF 206。如果SEF204正代表实体A 202请求证书，SEF 204可以与TTP/KDF 206相互认证。
在安全证书提供过程中，KDF 206生成密钥，并且描述如何使用密钥和什么目的(MAC，加密，在哪一层将应用保护以及将包括的相关参数等)、如何使用密钥的作用域和其被用于的上下文，以及(可选地)可以生成的新的ID以及将使用的推荐算法。TTP/KDF 206维护可以类似如下所示的表：
Figure BDA0003213446000000131
表9：与每一实体的安全关联和证书关联
上下文ID、关联密钥和其它关联参数和作用域被提供给请求实体或SEF 204。关联参数可以指示可以被包括为安全过程(例如认证过程)的一部分的安全信息。建立的每一安全上下文具有有效生命期，在此之后可以更新上下文或创建新的上下文。上下文ID可以被用来识别证书(密钥、算法等)以及关联作用域和参数。
第三方证书请求过程
在第三方证书请求步骤中，需要与另一实体(诸如实体A 202)执行端对端认证的实体N 208请求密钥材料、与密钥相关联的作用域、可以用来证实消息认证的参数和其它信息，使得可以创建E2E安全关联。可选地，可以使用TTP/KDF 206认证请求实体，并且还确定是否授权向实体提供E2E密钥。此后，TTP和/或KDF 206将被称为TTP。可以为实体提供上下文ID、URI、端口#、关联密钥、作用域和关联参数。可以裁剪生成的密钥以进一步适合两个终端实体。可选地，可以发生密钥生成过程的另一级。在实体N，可以使用想创建和维护安全关联的实体维护下述参数：
Figure BDA0003213446000000141
表10：将与每一实体一起使用的认证机制，作用域和参数
在上表中，能观察到为了实体N 208与实体A 202执行E2E认证，可以提供上下文ID(实体A-上下文1)，其可以是可选参数。
上下文ID：可以被用来识别将用于建立E2E认证的安全特征/参数。上下文ID被用来识别E2E安全证书以及关联作用域和参数。可以随机或使用加密过程来生成上下文ID。上下文ID可以被用作实体或事务的临时标识。
资源ID：其是实体的标识(例如实体的URI或域名，IP@等)，实体N想要通过该标识创建EE认证过程和关联。
端口#：在会话层E2E认证的情况下，可以可选地提供端口#。
协议：在服务层E2E的情况下，协议仅指示将使用的消息认证算法(例如HMAC-SHA2)，而在会话层的情况下，协议指示协议(可以是DTLS或TLS或任一其它协议)。这不限于仅是会话或服务层并且可以包含与应用层(例如安全RTP)相关联的协议或其它低层协议，诸如IPSec、EAP等。
参数：指示可以被用来提供密钥所有/消息认证的证据的值(例如Nonce、时间、随机质询等)。
认证类型：确定在其上可以执行认证的层。这些包括可以在服务、会话、网络、MAC层处执行的认证。本公开对服务和会话层处的认证机制感兴趣。
与实体A 202相关联的端对端证书可以由TTP被提供给第三方(称为实体N)，或所需密钥材料被提供给实体N 208，以便实体N 208能够生成被用来校验或提供实体A 202和实体N 208之间的端对端安全保护(即，端对端消息认证、端对端消息机密性、端对端数据机密性和端对端数据完整性)的适当安全证书。在表引用中提供可以生成的证书的类型的列表：
Figure BDA0003213446000000151
生成密钥材料
采用KDF 206的TTP可以执行实体N 208的认证，在此之后且如果已经授权实体N，可以为实体N提供适当的EntityA_EntityN(实体A_实体N)特定的端对端密钥。将由实体A202预先提供的预配置的EntityA_EntityN特定密钥提供给实体N 208。如果已经提供了Ke2e_EntityA_master，那么TTP生成适当的Ke2e_EntityA_EntityN特定密钥并且将它们提供给实体N 208。替选地，TTP仅将Ke2e_EntityA_EntityN密钥提供给实体N 208以及向实体N 208提供必要的播种材料，使得实体N 208能够生成用于实体N 208的安全保护所需的各种密钥。生成的各种密钥可以是在本文献内被称为E2E_MAC_Key的用于消息认证的Ke2e_EntityA_EntityN_msg_auth、用于消息机密性的Ke2e_EntityA_EntityN_msg_conf、用于提供数据机密性的Ke2e_EntityA_EntityN_data_conf和用于提供端对端数据完整性的Ke2e_EntityA_EntityN_data_auth。
注意：在某些图中，端对端Ke2e_EntityA_EntityN_msg_auth和Ke2e_EntityA_EntityN_msg_auth通常被称为KpsaE2E。
基于由实体A 202和TTP执行的认证过程，可以由实体A 202和TTP生成Ke2e_EntityA_master。Ke2e_EntityA_master可以是在实体A202和TTP之间执行的引导过程的结果。此外，Ke2e_EntityA_master可以是绑定到认证的信道和用于在实体A 202和TTP之间执行认证(例如TLS或DTLS或GBA)的认证信道。引导过程：可以使用诸如GBA的引导机制以推导出可以与每一实体对相关联的Ke2e密钥。可以使用GBA通过TTP认证从E2E观点看想要认证实体的实体(例如实体A)。作为使用GBA过程认证实体A的结果生成的主(master)E2E密钥可以是下述形式：
Ke2e_EntityA_master:148735880652C65238B432A....(256位)
基于实体A 202和TTP之间的成功相互认证，由实体A 202和TTP引导生成Ke2e_EntityA_master。
将由TTP生成和提供的实体特定密钥或播种材料提供给每一终端实体，使得能生成实体特定的端对端密钥。生成端对端密钥的示例机制如下所示：
Ke2e_EntityA_EntityB＝HMAC-SHA256(Ke2e_EntityA_master,"引导过程"||Entity_B-ID||Random 1)
Ke2e_EntityA_EntityC＝HMAC-SHA256(Ke2e_EntityA_master,"引导过程"||Entity_C-ID||Random2)
Ke2e_EntityA_EntityN＝HMAC-SHA256(Ke2e_EntityA_master,"引导过程"||Entity_N-ID||Random3)
可以由实体A和实体N使用密钥扩展机制以便生成分别用于对实体A和实体N之间的消息提供端对端消息可靠性和端对端消息机密性的关联Ke2e_EntityA_EntityN_msg_auth和Ke2e_EntityA_EntityN_msg_conf。提供用于端对端密钥的密钥扩展的示例：
Ke2e_EntityA_EntityN_msg_auth＝HMAC-Hash
(Ke2e_EntityA_EntityN_master,T(0)|"E2E消息认证密钥"|0x01)
Ke2e_EntityA_EntityN_msg_conf＝HMAC-Hash(
Ke2e_EntityA_EntityN_master,T(l)|"E2E消息机密性密钥"|0x02)
如果使用基于单个密钥的AEAD加密过程，那么仅生成上述密钥中的一个。
服务层：服务层处的E2E认证，其中，仍然可以使用逐跳保护机制，但此外，使用E2E消息发端认证。此外，可以在服务层处保护被视为具有安全重要性的信息和参数。可以借助JSON Web签名(JWS)提供保护。中间节点仅可以处理元数据。可以由E2E JSON Web签名基于用作消息认证码(MAC)密钥的E2E密钥来保护元数据完整性，并且使用JSON格式(诸如JSONWeb签名)来表示元数据。使用加密算法(诸如认证加密)和算法的关联数据(AEAD)类(诸如AES-CCM和AES-GCM)能提供端对端可靠性和消息机密性两者。识别关联数据被用于提供和校验消息可靠性。关联数据可以由消息报头组成，在要求消息机密性的情况下不加密消息报头。替选地，可以使用未由任何中间节点变更的整个消息用来创建消息认证码。如前所述，消息报头的子集(称为消息的元数据)可以被用作AEAD算法内的关联数据，然后，其被用于计算MAC。还可以使用其它手段生成MAC并且使用专用手段表示MAC。与用来生成MAC的机制和消息收发内的MAC的表示无关，通过利用与时间组件相关联的Nonce或创建消息的时间与Nonce(可能是时间相关的非常大的随机值)两者的组合，可以防止未由中间节点变更或移除的整个消息遭受重放攻击。替选地，在签名创建过程期间，或代替时间与Nonce一起使用，可以使用每一消息的每次发送消息时递增的序列号。替选地，与时间和Nonce一起包括消息的序列号以用于重放保护。例如，可以如下推导签名或MAC或认证标签(Auth_Tag)：
MAC＝HMAC-SHA-256(Ke2e_EntityA_EntityN_msg_auth,"E2E_ServiceLayerMAC"||原始数据||时间||Nonce)
或：
MAC＝HMAC-SHA-256(Ke2e_EntityA_EntityN_msg_auth,"E2E_ServiceLayerMAC"||原始数据||消息序列号||Nonce)
代替仅“原始数据”，可以使用完整消息或与消息相关联的元数据。
Ke2e_EntityA_EntityN_msg_auth：提供给请求E2E认证的实体的密钥。在此隐含实体A和实体N之间的端对端消息认证。通常，对称密钥由两个实体(例如实体A 202和实体N208)共享。在公开密钥机制的情况下，Ke2e_EntityA_EntityN_msg_auth可以是用在签名消息(仅对签名实体已知)中并且由其它实体使用包含公开密钥的证书校验的私密密钥(也称为E2E_DS_Key：端对端数字签名密钥)。在无证书公开密钥机制的情况下，必须为终端实体提供向其执行E2E认证的实体的公开密钥。在替选实施例中，可以使用公开密钥机制来推导属性上对称并且由实体共享的Ke2e_EntityA_EntityN_msg_auth。
原始数据：该数据包含有关原始请求的信息，该数据可以被视为实际消息的元数据，也可以包含有关实际消息的发起方的信息。假定“原始数据”未由任何中间节点变更。原始数据可以包含在消息报头内包含的信息的子集，即，发起方Id、目的地Id、资源Id、操作类型和会话Id。
时间：可以是可选的，并且提供何时创建原始消息的时间戳。
Nonce：与时间分量相关联以及与会话相关联并且防止重放攻击的随机值。
序列号(Seq#)：这是识别消息的唯一数。在一些情况下，Seq#可以与会话Id相同。
会话层：使用借助DTLS或TLS的E2E认证。这将旁路逐跳安全机制。将相互认证终端实体，并且建立安全关联。这可以在真E2E方式(直接)或委托方式中，在实体之间完成。
端对端认证过程
可以以真实E2E方式或以委托或部分委托方式执行E2E认证过程。基于由实体提供或选择的作用域，可以使用下述执行E2E认证过程：
对称密钥：如前所述，可以为请求E2E认证证书的实体提供将被用于执行E2E认证的对称密钥、作用域和参数。在直接或委托情况下，对称密钥可以被用于服务层E2E或会话层E2E认证。一旦提供作用域和关联参数，那么实体可以相应地使用密钥。可以定期地重新生成E2E认证密钥(Ke2e_EntityA_EntityN_msg_auth)。类似地，基于与每一证书相关联的生命期，可以定期地生成Ke2e_EntityA_master。
基于证书/公开密钥：提供的证书可以基于以证书的形式表示的公开密钥或仅公开/私密密钥、基于标识的加密或基于公开密钥机制的其它机制。可以使用用于认证的证书，使用认证Diffie-Hellman过程，在实体之间生成用于会话层认证的E2E认证密钥(ke2e)。
委托安全机制vs直接安全机制
如果实体要求“高完整性”或“更高保证度”以用于认证，那么处理需求也成比例地更高，且如果实体的能力(例如存储器/处理)有限，实体可以选择以委托方式执行安全功能。实体可以将认证和其它安全功能委托给受信第三方(例如SEF 204)来执行更复杂的安全功能(例如，E2E认证、安全存储、正向加密)。执行委托认证的其它优点是委托代理(例如SEF)能够将多个E2E认证组合在一起。
如果实体能够独自执行E2E认证和其它安全操作，实体可以选择独自执行直接认证而无需委托。SEF 204可以基于设备能力或服务需求(例如减少信令和其它操作开销)，自行选择委托的选项。当委托安全功能部分时，使用混合方法，而是直接执行其它安全功能。
图3A-B是图示实体A 202和实体B 302之间的示例E2E操作的图：
在图3A-B的步骤1中，实体A 202和SEF1 204(例如具有预先提供的相互信任的第一跳实体)建立通过使能的安全通信认证的(D)TLS隧道。使用该安全隧道，发生服务使能安全配置(SESC)过程，其中，创建实体A的配置文件，且确定安全需求。
在图3A-B的步骤2中，实体A 202可以可选地请求在其自身和实体中的授权列表(例如实体B 302、实体C…实体N)之间建立E2E密钥。该请求由实体A 202发送到SEF1 204，以及SEF1 204可以将该请求发送到TTP/KDF 206。替选地，SEF1 204可以请求使用TTP 206创建E2E密钥，无需来自实体A的明确消息。在那种情况下，SEF1 204将确定将被提供有E2E密钥的实体的授权列表。替选地，如果在实体A 202和TTP 206之间存在信任关系，实体A202可以将密钥请求和实体的授权列表直接发送到TTP/KDF 206。为实体A 202提供TTP证书或预先提供TTP和实体A 202之间的共享密钥是可能的。应注意到TTP206必须具有证书以便直接认证实体A 202，对那一情形，不必依赖SEF1 204来工作。
在图3A-B的步骤3中，基于实体A 202的能力、作用域，TTP生成Ke2e_EntityA_master并且与实体A 202相关联。如果从SEF1发起证书请求，那么生成的主密钥可以是Ke2e_SEF1_master并且与SEF1204相关联。还生成有关如何使用密钥的另外的参数以及识别密钥和密钥用途的上下文ID。可选地，TTP可以以下述方式使用主密钥来生成作为E2E实体特定的密钥的E2E对称密钥。
a.例如：Ke2e_EntitiyA_EntityB_master＝(Ke2e_EntityA_master,"实体B ID||参数")
其中，实体B ID是由实体A 202或SEF1提供的实体B的标识(例如实体B的URI)
Ke2e_EntityA_EntityB_master：是被用来向实体B认证实体A 202的E2E对称密钥，或反之亦然。
在图3A-B的步骤4中，TTP将包括实体A的E2E主密钥以及(可选地)E2E实体特定的对称密钥的列表的密钥提供给SEF1 204。SEF1204可以将密钥转发到实体A 202。替选地，如果SEF1 204进行请求，那么密钥被存储在SEF1 204处并且不转发到实体A 202。这适用于当SEF1 204代表实体A 202执行委托认证时。
在图3A-B的步骤5中，实体(例如实体B 302)与SEF2 304执行SESC过程。在一些情况下，SEF1 204和SEF2 304可以是相同的，且如果如此，可以省略E2E认证过程或简化密钥请求，而不必包含TTP。
在图3A-B的步骤6中，实体B 302请求TTP以请求将被用于与实体A 202通信的E2E对称密钥。可选地，可以直接通过使用TTP认证实体B 302，或替选地，TTP基于(D)TLS连接信任SEF2 304。在替选实施例中，SEF2 304可以代表实体B向TTP请求。在另一实施例中，SEF2304可以请求对自身特定的E2E实体，在这种情况下，可以由TTP使用更动态地密钥生成机制。
在图3A-B的步骤7中，TTP确定已经由实体A 202授权实体B 302以提供实体A的E2E密钥。然后，TTP 206将E2E实体特定的密钥(Ke2e_EntityA_EntityB_master)转发到SEF2304，SEF2 304将其转发到实体B 302。如果SEF2 304提供委托认证，替选地，SEF2 304可以存储密钥。对委托认证，由TTP提供的密钥可以是：Ke2e_EntityA_SEF2_master。实体A 202未授权SEF2 304，然而，TTP可以生成SEF2特定的密钥并且提供参数内的适当信息以指示其刚刚正使用委托认证。在这种情况下，实体A 202将使用提供给它的主密钥以及提供的参数，推导SEF2特定的密钥。
在图3A-B的步骤8中，可以基于在密钥提供过程期间提供的参数和E2E实体特定的密钥，使用MAC或JSON Web签名(JWS)或能够证明消息发起方认证的任何其它手段，保护在会话层上发生的任何消息收发和执行的相应操作(例如创建、检索、更新或删除)。
应理解到执行在图3A-B的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图3A-B所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图3A-B所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图3A-B所示的任何发送和接收步骤。
实施例
本公开中所述的机制适用于包含认证的环境，并且特别地，包含被认为受限的实体(例如IoT/M2M设备)的E2E认证的环境。然而，其不限于仅IoT设备，并且可以用于其中受信实体可以确定适当的安全特征、功能和证书以除了将受限设备从执行复杂安全功能中释放之外，还整体上减轻包含在系统中的消息收发开销的情况。下述子章节中所述的实施例涉及oneM2M规范。在此，提议将SEF 204托管在托管CSE处。在一些情况下，CSE还可以提供TTP/KDF 206支持，但从可扩展性观点看，TTP/KDF 206可以托管在M2M服务提供商CSE处或作为具有如在本公开中所述的附加功能性的证书机构。
图4A-B是图示oneM2M实施例的图。oneM2M定义由oneM2M服务层支持的能力，其被称为能力服务功能(CSF 404)。oneM2M服务层被称为能力服务实体(CSE 402)。在一个实施例中，如图4A所示，所提出的服务使能功能204可以被托管在作为oneM2M CSF的CSF408中。如图18B所示，密钥递送功能206可以被托管在作为oneM2MCSF的CSF 412中。
服务使能和服务配置(SESC)
SESC可以包括图5A-B中所示的安全证书请求和提供阶段(SCRP)，其中，实体CSE3502请求建立E2E认证证书。E2E证书可以由其它实体使用，以便与CSE3 502执行E2E认证。消息收发详情：
图5A-B的步骤0是用于建立逐跳认证证书的密钥提供步骤。可以基于当前的oneM2M规范执行该步骤。这可以离线执行。作为密钥提供步骤的结果，为CSE3 502和托管CSE(HCSE)504提供对称密钥(Kpsa1)。
在图5A-B的步骤1中，CSE3 502和HCSE 504将Kpsa1用作用于认证的基础，建立DTLS连接。
在图5A-B的步骤2中，作为DTLS认证的一部分，建立会话密钥。
在图5A-B的步骤3中，CSE3 502发送指示需要创建oneM2M资源的“创建请求”消息和用于创建E2E证书的请求。由DTLS会话密钥保护创建请求消息。CSE3 502提供能使用E2E证书的授权实体的列表。
在图5A-B的步骤4中，HCSE 504通过使用DTLS会话密钥，校验消息的起源是否确实来自AE1。
在图5A-B的步骤5中，作为CSE3 502的托管CSE的HCSE 504基于如在oneM2M规范中制定的机制，创建CSE3 502的资源。此外，基于CSE3 502的能力(如在上文所述，其可以在服务使能过程期间推断或获得)，HCSE 504创建基于设备的能力适当的E2E证书的请求。还提供用于安全证书的使用的作用域和可以使用的参数。作用域可以是服务层/会话层E2E认证，参数包括可以用于重放保护的信息、用于消息认证的信息(例如消息或元数据的发起方的真实身份等)。
在图5A-B的步骤6中，使用预建立的安全证书(PSK)，在HCSE504和TTP/KDF 206之间建立TLS会话。
在图5A-B的步骤7中，使用安全TLS隧道，将对证书、作用域、使用和参数的请求从HCSE 504发送到TTP。
在图5A-B的步骤8中，基于由HCSE 504提供的设备能力信息，TTP生成如由HCSE请求的适当证书。如果设备能力低，那么与适当的密钥大小一起，选择适当的算法(例如，HMAC-SHA1或3DES或其它低资源需求算法)。证书连同作用域、参数被存储在数据库中。生成的证书可以被称为“Ke2e_CSE3_master”密钥并且具有与之相关联的适当的密钥句柄/上下文ID。在CSE3 502与TTP具有直接连接的情况下，可以由TTP将Ke2e_CSE3_master直接转发到CSE3 502。可以使用在CSE3 502和TTP之间建立的(D)TLS连接传输密钥。
在图5A-B的步骤9中，然后将证书与必需的作用域和参数一起转发到HCSE 504。
在图5A-B的步骤10中，HCSE 504将证书连同其它相关信息转发到CSE3 502。
在图5A-B的步骤11中，校验从HCSE 504接收的消息。
在图5A-B的步骤12中，将证书连同作用域和参数存储在密钥库中。
应理解到执行图5A-B所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图5A-B所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图5A-B所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图5A-B所示的任何发送和接收步骤。
图20图示实体AE1 602发起与CSE或服务提供的注册过程并且包括提供用于逐跳和/或端对端安全的适当安全证书。可以基于与AE1602相关联的DP、SP和/或EP，确定适当的证书。
在图20的步骤1中，AE1 602发起与CSE1 604的连接请求。连接请求可以是注册请求。
在图20的步骤2中，CSE1 604不具有配置文件、与AE1 602相关联的参数，因此，在步骤3中，从IN-CSE 2002请求订阅配置文件。
在图20的步骤4中，IN-CSE 2002将与AE1 602相关联的M2M订阅配置文件发送到CSE1 604。
在图20的步骤5中，CSE1 604向可以位于服务或网络提供商网络外的SP储存库2004请求SP。在图20的步骤6中，包含与AE1 602相关联的AE1_SP的响应被发送到CSE1 604。
在图20的步骤7中，CSE1 604可以从DP/EP储存库2006请求AE1_DP、与AE1 602和/或AE1_EP相关联的DP、与AE1 602相关联的EP或AP。在步骤8中，将包含AE1_DP和/或AE1_EP的响应发送到CSE1 604。
在图20的步骤9中，基于SP、DP和/或EP，CSE1 604确定安全需求的适当集合，且因此确定用于确保与AE1 602的通信的关联安全特征和参数。
在图20的步骤10中，CSE1 604基于由CSE1 604执行的评估，向M2M登记功能(TTP/KDF)请求适当的安全证书。证书请求可以是明确或隐含的，并且可以提供粒度安全需求或较低粒度需求。
在图20的步骤11中，M2M登记功能(MEF)2008发起与AE1 602的引导过程并且生成适当的引导会话证书。
在图20的步骤12中，MEF 2008生成与AE1 602相关联的CSE1特定的端对端证书(Ke2e_AE1_CSE1_master)并且将其提供给CSE1604。MEF 2008可以替选地生成Kpsa_AE1_CSE1并且将其提供给CSE1604。此外，MEF 2008还可以提供与证书相关联的使用信息(Usagelnfo)和上下文信息(Contextlnfo)。
在图20的步骤13中，根据策略以及使用信息和上下文信息，AE1602生成CSE1特定的端对端证书：Ke2e_AEl_CSEl_master，且还可以生成相关的Ke2e_AEl_CSEl_msg_auth和/或Ke2e_AEl_CSEl_msg_conf证书。AE1 602可以替选地生成被用于逐跳安全的Kpsa_AEl_CSEl。
在图20的步骤14中，如果CSE1 604未由MEF 2008提供Ke2e证书并且仅被提供Ke2e_AEl_CSEl_master和用于生成端对端证书所需的播种材料，CSE1 604生成Ke2e_AEl_CSEl_msg_auth和/或Ke2e_AEl_CSEl_msg_conf。
应理解到执行在图20的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图20所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图20所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图20所示的任何发送和接收步骤。
第三方证书请求阶段
在下图中图示出其中想要检索由另一实体(例如CSE3 502)托管的资源且想要请求该其它实体的E2E证书的实体(例如AE1 602)的实施例。图6A-B是图示第三方证书请求阶段的图。
假定在每一实体处，AE1 602、CSE1 604和TTP 206均被提供在如由oneM2M规范规定的密钥库内存储的对称密钥。还可以设想为AE1602仅预提供TTP 206的E2E证书，其然后被用来获得用于在AE和托管CSE之间建立逐跳关联的证书。消息收发详情如下：
在图6A-B的步骤1中，AE1 602使用Kpsa1与CSE1 604建立DTLS安全关联。
在图6A-B的步骤2中，每一实体彼此认证并且建立会话密钥。
在图6A-B的步骤3中，AE1 602发送针对由CSE3 502托管的资源的“检索请求”消息和可选的E2E证书请求消息。E2E证书请求可以是可选的，因为CSE1 604可以确定是否需要E2E认证证书。
在图6A-B的步骤4中，在DTLS隧道内转发检索请求消息并且由CSE1 604校验消息的起源。
在图6A-B的步骤5中，CSE1 604基于AE1 602的能力创建对CSE3502的证书、作用域和参数的请求。
在图6A-B的步骤6中，CSE1 604使用PSK与TTP建立TLS连接。
在图6A-B的步骤7中，还可以提供用于CSE3的证书、作用域、参数，以及(可选地)AE1的优选的安全能力的请求。
在图6A-B的步骤8中，如果AE1 602在SCRP阶段期间由实体CSE3 502授权，并且处于授权实体的列表中，那么基于对CSE3证书的请求，TTP检索与CSE3 604相关联的证书。
在图6A-B的步骤9中，使用TLS隧道，将CSE3 604的证书连同其它相关信息(诸如作用域、参数)发送到CSE1。在执行委托认证的情况下，CSE1可以可选地存储证书。
在图6A-B的步骤10中，CSE1将检索响应消息连同CSE的证书和关联信息发送到AE1。
在图6A-B的步骤11中，由AE1校验消息。
在图6A-B的步骤12中，AE1 602将CSE3的证书和关联参数存储在密钥库内。
应理解到执行在图6A-B的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图6A-B所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图6A-B所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图6A-B所示的任何发送和接收步骤。
在图14中图示并且在此描述基于引导过程的实施例。要求远程提供主证书和主证书标识符或提供的安全连接密钥(Kpsa)和提供的安全连接密钥标识符(KpsaId)的AE或CSE被称为登记方。登记方将与其建立安全关联的AE或CSE被称为登记方B。登记方将与其建立共享密钥的AE或CSE或M2M认证功能(MAF)被称为登记目标。oneM2M系统支持预提供的对称登记方密钥，其是被预提供给登记方和M2M登记功能(MEF)以用于那些实体的相互认证的对称密钥。类似地，可以在登记方和MEF处提供基于证书的机制或原始公开密钥。登记方和MEF应在信任证书中的公开校验密钥前校验彼此的证书。在安全握手内，M2M登记功能使用其私密签名密钥来创建会话参数的数字签名，且登记方使用M2M登记功能的公开校验密钥来校验数字签名。随后反转角色：登记方创建数字签名并且M2M登记功能校验它。替选地，使用基于GBA的提供机制。在这种情况下，由GBA引导服务器功能(BSF)执行MEF的角色。该框架使用3GPP或3GPP2对称密钥来认证登记方和MEF(也称为GBA BSF)。由3GPP TS 33.220和3GPP2S.S0109-A规定详情。
登记方和M2M登记功能被预提供有引导证书，实体将用引导证书来向其它实体认证自身。用于该预提供的机制可以由管理员执行、在工厂自动化、使用设备管理方功能或使用诸如如由全球平台(Global Platform)规定的信任服务管理方(TSM)的机制。建立被称为Kpsa的“用于M2M安全建立的提供的证书”及其关联标识符KpsaId、被称为Km的“主证书”及其关联的“主证书标识符”KmId的过程遵循如在oneM2M的TS-0003规范内的章节8.3.1.2中所述的机制。一旦已经生成了Km和/或Kpsa，那么可以使用该“主证书”以生成E2E证书。规范描述执行下述的机制：引导证书配置、引导指令配置、引导登记握手、登记密钥生成和集成到关联安全握手过程。在本公开中，提出添加另外的过程，被称为“生成端对端证书”。
提出通过至少提供下述参数：内容信息、标签和Salt，使用为登记目标或MAF提供生成端对端证书的能力的机制，增强“登记阶段”。内容信息为登记目标提供具有有关待生成的证书的类型、待遵循的机制或标准的足够信息，以能够生成端对端证书等。示例证书的类型可以是端对端消息认证证书、端对端数据安全证书、关于证书可以是公开或对称密钥的信息、密钥长度、待遵循的算法/协议等。标签基于如由RFC 5809或RFC 5246或RFC 5705或任何其它标准密钥导出功能和密钥扩展所述的用途，提供用于生成那些证书所需的信息。可以由登记方直接提供或由MEF向登记目标提供上下文信息和标签。Salt是被用作密钥生成机制的一部分的随机值。优选方法是在初始消息期间，登记方将Salt提供给登记目标，作为登记阶段的一部分。Salt还可以是基于登记方和登记目标之间的初始通信计算的hash值。
作为“生成端对端证书”过程的一部分，登记方和登记目标将Kpsa_AE_CSE用作主密钥，生成端对端证书，以便生成端对端主密钥Ke2e_AE_CSE_master。替选地，如果目标为MAF，那么Km将被用作用于生成端对端主密钥的主密钥。提供如下使用RFC 5809的端对端密钥生成的示例。
Ke2e_AE_CSE_master＝HMAC-Hash(Salt,Kpsa_AE_CSE)
T(0)＝空串(零长度)
Ke2e_AE_CSE_msg_auth＝T(l)＝HMAC-Hash(Ke2e_AE_CSE_master,T(0)|"E2E消息认证密钥"|0x01)
Ke2e_AE_CSE_message_confidentialtiy＝T(2)＝HMAC-Hash(Ke2e_AE_CSE_master,T(l)|"E2E消息机密性密钥"|0x02)
类似地，由登记目标和登记方生成数据机密性和数据完整性密钥。基于在登记方和登记目标(例如AE和CSE特定端对端密钥)之间共享的唯一Enrollee-EnrolmentTarget_Ke2e_master，由每一登记方和相关的登记目标重复该过程。在一些情况下，对登记方仅生成Ke2e_master，其可以由多个登记目标共享并且由MEF提供给登记目标，其然后对终端实体的每一个生成唯一端对端密钥。
在某些情况下，Kpsa/Km可以被用作Ke2e_master，以及上述过程被用来生成端对端安全保护(即，消息认证、消息完整性、数据完整性和数据机密性)的每一个的唯一密钥。
在某些其它情况下，仅单个密钥(Kpsa或Km)被用于消息认证、消息、消息机密性、数据完整性、数据机密性、密钥生成密钥等。
在某些其它情况下，从Kpsa或Km生成会话密钥，其然后被用于生成端对端安全保护机制(即，消息认证、消息机密性、数据完整性和数据机密性)的每一个的唯一密钥。
在某些其它情况下，仅从Kpsa或Kpm生成的单个会话密钥被用于提供端对端消息认证、机密性、数据完整性和数据机密性。
在某些其它情况下，MEF将Ke2e_master或下述密钥的集合或子集提供给登记目标或MAF，即，Ke2e_AE_CSE_msg_auth、Ke2e_AE_CSE_msg_conf、Ke2e_AE_CSE_data_auth、Ke2e_AE_CSE_data_conf和Ke2e_key_generation。
图15A-B分别提供与AE的资源表示关联和具有下述属性的<securityParameters>资源结构：逐跳安全证书和端对端证书。图16A-C描绘之前所述的实体配置文件、设备配置文件和安全配置文件的资源表示。
E2E认证阶段
在E2E认证阶段期间，基于早先在密钥生成阶段期间确定的作用域，可以在应用、服务、会话或其它层执行认证。同时，可以在直接模式或使用委托模式，执行认证。
使用直接模式在服务层处的E2E认证
图7A-B图示其中AE1 602请求对在CSE3 502上托管的远程资源的更新操作的E2E认证。该图图示使用直接模式的服务层E2E认证。
所示的机制遵循非常接近oneM2M规范。消息收发详情：
在图7A-B的步骤1中，AE1 602使用Kpsal1与CSE1 604建立DTLS连接。
在图7A-B的步骤2中，AE1 602发送请求以在CSE3 502上托管的资源上执行更新操作。AE1 602使用在如上所述的第三方证书请求阶段期间先前获得的E2E认证密钥(Ke2e_CSE3_AEl_msg_auth)，创建消息认证码(MAC)。基于所提供的包括将使用的算法、将用来提供起源认证的参数、重放保护等的作用域，创建MAC。MAC被提供为请求消息的一部分并且使用DTLS隧道保护。
在图7A-B的步骤3中，使用由oneM2M规范规定的机制，处理该请求。
在图7A-B的步骤4中，一旦该请求被处理，将响应发送到AE1。
在图7A-B的步骤5中，CSE1 604使用Kpsa2，创建与下一跳CSE2702的DTLS连接。
在图7A-B的步骤6中，CSE1 604创建递送资源请求消息并且将其连同由AE1 602包括的MAC转发到下一跳CSE2 702。
在图7A-B的步骤7中，在CSE2处，处理该请求。CSE2处理递送请求数据来提交CSE3的URI和其它相关信息。
在图7A-B的步骤8中，将响应发送到CSE1 604。
在图7A-B的步骤9中，CSE2 702使用Kpsa3，与CSE3 502建立DTLS连接。
在图7A-B的步骤10中，下一跳CSE2 702创建递送资源请求消息并且将其连同AE包括的MAC转发到下一跳CSE3。
在图7A-B的步骤11中，CSE3 502校验消息起源。
在图7A-B的步骤12中，CSE3 502校验包括在与AE1 602相关联的消息中的MAC。如果CSE3 502不具有E2E证书(KpsaE2E)，CSE3502可以从TTP获得主密钥，然后，基于AE1的身份生成E2E密钥。CSE3 502还使用参数(例如Nonce/时间戳)校验还未重放消息，并且校验已经将AE1 602校验为原始消息的发起方以及确实由AE1计算和插入MAC。
在图7A-B的步骤13中，由CSE3 502将对该请求的响应提供回CSE2 702。
替选地，可以在直到已经执行直到13的步骤后，发出步骤4和8的消息。一旦CSE2702从CSE3 502接收到响应(消息13)，CSE2向CSE1 604发送响应(步骤8的消息)以及CSE 1向实体发送响应(步骤4的消息)。
应理解到执行在图7A-B的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图7A-B所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图7A-B所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图7A-B所示的任何发送和接收步骤。
使用委托模式的在服务层处的E2E认证
图8A-B图示使用委托模式方法，在服务层处的E2E认证。如参考图7A-B所述的直接模式和在此所述的方法之间的主要区别在于CSE1 604(托管CSE)代表AE1 602执行E2E认证。CSE1 604代表AE1 602执行前述第三方证书请求处理。同时，稍微变型的实施例在于作用域信息建立使用JSON Web信令(JWS)/JSON Web令牌表示而不是MAC。使用的参数与用于MAC计算的参数类似，表示基于JWT和上述的安全提供过程期间同意。消息收发详情与参考图7A-B所述的那些详情非常类似，除了下述消息：
在图8A-B的步骤1中，请求消息不包含MAC，因此，不能以E2E方式认证AE1 602。
图8A-B的步骤3-5与先前所述的情形类似。
在图8A-B的步骤6中，CSE1 604创建与MAC类似的JWS，以便终端实体CSE3 502能够认证CSE1 604。在此，在执行认证中委托CSE1 604代表AE1 602。JWS包括在请求消息中。使用从TTP获得的Ke2e_AEl_CSEl_msg-aut，计算JWS。
图8A-B的步骤7-9与先前所述的情形类似。
在图8A-B的步骤10中，以逐跳模式，将包含JWS的请求消息转发到CSE3 502。
在图8A-B的步骤11中，CSE3 502校验其是消息的目标。
在图8A-B的步骤12中，CSE3 502校验由CSE1 604代表AE1 602发送原始请求。通过校验JWS并且其未被重放，校验发起方的确为CSE1 604。
应理解到执行在图8A-B的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图8A-B所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图8A-B所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图8A-B所示的任何发送和接收步骤。
图17描述图示借助在借助在通过信任的或不太可信的或甚至不可信的中间跳的来回移动的作为彼此远离的多个服务层跳的两个实体AE2和CSE1 604之间的对称密钥机制的端对端消息认证和完整性校验的实施例。客户端应用(AE2)想要在另一应用实体(602)的资源上执行更新操作。由于资源被托管在托管CSE(CSE1 604)上，AE2已经被预提供资源的位置或使用发现服务以便发现资源位置(/CSE1/R-ID)。CSE1 604想要确保仅授权的实体能够在AE1资源上执行创建、检索、更新、删除或通知操作中的任何一个。为了CSE1 604能够确保仅授权实体能够执行CRUD操作，CSE1 604可以通过校验消息的发起方拥有的密钥要求认证消息的来源是授权的并且消息被完整性保护。在创建消息的准备中，AE2必须或从TTP获得适当的消息认证密钥Ke2e_AE2_CSEl_msg_auth，或由被提供给它或使用上述“第三实体证书请求过程”使用引导过程生成的端对端主密钥Ke2e_AE2_CSEl_master生成密钥。除密钥外，获得、生成为了AE2能够生成能由CSE1 604使用的正确认证标记以便校验AE2消息的可靠性和机密性而要求的上下文信息、用途信息和标签或将其提供给AE2。AE2从密钥库选择适当的证书，用于执行端对端认证。
在图17的步骤1中，AE2使用Kpsa_AE2_CSE2以便在其自身和CSE2 702之间建立(D)TLS连接。连接建立过程遵循在版本1的TS-0003oneM2M规范中描述的机制。
在图17的步骤2中，AE1 602生成被用来在CSE1 604上托管的AE1的资源(识别为/CSE/R-ID)上执行“更新”操作的oneM2M“请求”消息。由M2M-Request-ID 1唯一地识别请求消息。AE2使用消息报头信息，也被称为OriginData，生成认证标记(Auth_Tag)或消息认证码(MAC)。替选地，整个消息被用作输入以便创建Auth_Tag。下述信息可以被用作Auth_Tag生成的一部分。
Auth_Tag＝HMAC-SHA-256(Ke2e_AE2_CSEl_msg_auth,"消息报头"|Nonce|时间)
替选地，Auth_Tag＝HMAC-SHA-256(Ke2e_AE2_CSEl_msg_auth,"整个消息"|Nonce|时间)
在Auth_Tag的生成中可以包括Nonce、时间或两者。在某些情况下，两个均可以被排除，因为被认为对每一会话唯一的M2M-Request-ID被包括在每一消息内。优选使用整个消息以用于计算Auth_Tag，替选地，可以使用消息报头用于生成Auth_Tag。然而，如果消息内的某些组件可能由中间实体(诸如CSE2 702)变更，那么仅可以使用能被用来保证消息的可靠性和意图的消息的那些组件。必须被完整性保护的消息的绝对必要的组件是：来自字段，“fr”；到字段，“to”；操作字段，“op”；资源ID，“res-id”(如果不同于“to”字段)；和会话标识符，“M2M-Request-ID”。如果存在被包括在消息中的“data(数据)”，也保护其完整性。如前所述，优选方法是对整个消息进行完整性保护，然而，在某些实施方式中，为了路由目的，一些组件被中间实体合理地变更，在这些情况下，必须确保仅那些未被中间实体变更组件的组件，但同时能够提供AE2的请求的可靠性以及完整性。
在图17的步骤3中，AE2创建可以为oneM2M消息收发变更的基于JSON的表示(JSONWeb签名)，用于携带Auth_Tag以及被用来创建Auth_Tag的安全属性。JWS将包括下述安全属性：“cred-id”，其是证书ID，被用来标识证书或密钥，其在这种情况下是Ke2e_AE2_CSEl_msg_auth-ID；算法“alg”；用来计算Auth_Tag，“HMAC-SHA-256”；有效载荷“payload”，其包括消息或消息报头以及数据；和签名，“sig”，其是Auth_Tag/MAC。替选地，可以由在简明二进制对象表示(CBOR)对象签名和加密标准中描述的机制使用基于CBOR的表示代替base64。oneM2M消息“Request”
在图17的步骤4中，如果在CSE1 604和CSE2 702之间不存在现有的(D)TLS连接，根据oneM2M规范，将Kpsa_CSE2_CSEl用作对称密钥，在CSE1 604和CSE2 702之间建立(D)TLS连接。
在图17的步骤5中，将由AE2创建的消息转发到CSE1 604。如果用于签名的算法是基于公开密钥的机制，那么，CSE2 702能够在将其转发到CSE1 604前认证该消息，但在此使用对称密钥的情况下，基于在AE2和CSE2 702之间存在的信任和基于(D)TLS连接建立的安全关联，隐含消息的认证，预期该消息来自受信AE2。CSE2 702将该消息转发到CSE1 604，无需变更主消息报头。在消息报头被CSE2 702变更的情况下，CSE2 702生成消息报头的副本并且连同安全属性被包括为数据的一部分。在AE2已经使用整个消息以便创建安全属性(JWS)的情况下，那么CSE2 702在将其转发到CSE1 604前，将整个消息连同头部和安全属性(JWS)复制到数据有效载荷部分中。在步骤4建立的(D)TLS连接上，将该消息由CSE2 702发送到CSE1 604。
在图17的步骤6中，CSE1 604校验其是否为消息的目标。使用安全属性(JWS)，使用证书ID(cred-id)以校验正确的证书并且从安全密钥库(例如，诸如SIM卡的安全元件)提取它，确定适当的上下文信息和用途参数。基于确定安全类型(签名)的上下文信息、涉及的实体等以及用途(Nonce的算法、可用性等)，校验消息是否具有正确的特性集，然后使用Ke2e_AE2_CSEl_msg_auth密钥连同该消息，该消息可以是由AE2 1102原始发送的整个消息，或消息的消息报头或元数据，并且使用可能存在的Nonce连同上下文信息，以及将参数作为输入提供到在这种情况下正好为HMAC-SHA-256的JWS内识别的“alg”中，并且生成Generated_Auth_Tag。CSE1 604校验Generated_Auth_Tag是否与包含在JWS内的Auth_Tag相同，如果是，AE2的消息被认证。随后CSE1 604检查以判断是否已经授权AE2 1102在AE1资源上执行“更新”操作。
在图17的步骤7中，如果授权AE2 1102执行“更新”操作，那么CSE1 604更新由R-ID识别的AE1资源。CSE1 604创建响应消息并且使用与在图17的步骤2中由AE2使用的过程类似的过程，以生成不同的Auth_Tag2。推荐每次使用新的Nonce并且将其包括为JWS的一部分，且不重用现有的Nonce。包括所有安全属性(例如，Nonce、Auth-Tag2、证书ID、消息或消息报头或消息的元数据)以便创建JWS。
在图17的步骤8中，如果在AE1 602和CSE1 604之间不存在现有的(D)TLS连接，通过基于oneM2M技术规范TS-0003版本1使用共享对称密钥Kpsa_AEl_CSEl，创建新的(D)TLS连接。
在图17的步骤9中，CSE1 604将指示“更新”AE1的资源“R-ID”的“通知”消息发送到AE1 602。该消息在图17的步骤8中建立的安全(D)TLS连接上发送。
在图17的步骤10中，在创建如在图17的步骤7中所述创建的响应消息后，CSE1 604在步骤4中建立的安全(D)TLS连接上，将消息发送到CSE2 702。如果该连接不存在，那么，必须创建新的(D)TLS连接，与在图17的步骤4中创建的(D)TLS连接类似。可以与图17的步骤8并行地发送消息10，然而，在某些关键情况下，可以比图17的步骤10更早地执行步骤8。
在图17的步骤11中，如果公开密钥机制被用于生成JWS，通过检验JWS内的数字签名，CSE2 702可以校验从CSE1 604接收的消息的可靠性/完整性。由于使用对称密钥，CSE2702使用隐含的信任，因为在安全的(D)TLS连接上接收该消息并且在图17的步骤1中建立的安全的(D)TLS连接上将该消息转发到AE2 1102。如上所述，如果有效的(D)TLS连接不存在，那么必须使用Kpsa_AE2_CSE2对称密钥和使用在oneM2M技术规范TS-0003版本1中所述的机制，在CSE2 702和AE2 1102之间建立新的(D)TLS连接。
在图17的步骤12中，AE2 1102校验JWS内的Auth_Tag2并且使用如在图17的步骤6中所述的机制，认证消息。使用的安全属性不同于步骤6中的安全属性，然而，过程是相同的。
应理解到执行在图17的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图17所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图17所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图17所示的任何发送和接收步骤。
图18描述图示借助在通过信任的或不太可信的或甚至不可信的中间跳来回移动的作为彼此远离的多个服务层跳的两个实体AE2 1102和CSE1 604之间的对称密钥机制的端对端消息认证和完整性校验以及消息机密性的实施例。客户端应用(AE2 1102)想要在另一应用实体(AE1 602)的资源上执行更新操作。由于资源托管在托管CSE(CSE1604)上，AE21102已经被预提供资源的位置或使用发现服务以便发现资源位置(/CSE1/R-ID)。CSE1 604想要确保仅授权的实体能够在AE1资源上执行创建、检索、更新、删除或通知操作中的任何一个。为了CSE1 604能够确保仅授权的实体能够执行CRUD操作，CSE1 604可以通过校验消息的发起方拥有的密钥，要求认证消息的来源是被授权的并且消息被完整性保护。此外，要求数据和消息收发被机密性保护。在创建消息的准备中，AE2 1102必须或从TTP分别获得适当的消息认证Ke2e_AE2_CSEl_msg_auth以及消息机密性密钥和Ke2e_AE2_CSEl_msg_conf，或由向其提供的或使用上述“第三方证书请求过程”使用引导过程生成的端对端主密钥Ke2e_AE2_CSEl_master生成该密钥。替选地，可以使用单个Ke2e_AE2_CSEl_msg_auth_conf用于消息认证和消息机密性两者并且使用基于认证的加密和关联数据(AEAD)的加密机制(例如AES-CCM,AES-GCM)。除密钥外，获得、生成为了AE2 1102能够生成能由CSE1 604使用的正确认证标记，以便校验AE2消息的可靠性和机密性而要求的上下文信息、用途信息和标签或将其提供给AE2 1102。并且为了确定适当算法、将在其上操作的模式、以及初始化向量(IV)的要求等的机密性，AE2 1102从密钥库选择适当的证书，用于执行端对端消息认证和消息机密性，因此，选择Ke2e_AE2_CSEl_msg_auth_conf密钥。
在图18的步骤1中，AE2 1102使用Kpsa_AE2_CSE2以便在其自身和CSE2 702之间建立(D)TLS连接。连接建立过程遵循在版本1的TS-0003oneM2M规范中所述的机制。
在图18的步骤2中，AE1 602生成用于在CSE1 604上托管的AE1的资源(识别为/CSE/R-ID)上执行“更新”操作的oneM2M“请求”消息。由M2M-Request-ID 1唯一地识别该请求消息。AE2 1102使用消息报头信息，也被称为OriginData，生成认证标记(Auth_Tag)或消息认证码(MAC)。替选地，整个消息被用作输入以创建Auth_Tag。如前所述，优选方法是完整性保护整个消息，然而，在某些实施方式中，为路由目的，可能由中间实体合理地变更一些组件，在这些情况下，必须确保未被中间实体变更但同时能够提供可靠性和AE2请求的完整性的仅那些组件。被用于oneM2M层路由的消息或消息报头或元数据未被加密并且被分类为关联数据(AAD)。AAD可以是完整性保护的。消息报头或元数据是用于指定“AAD”值的良好候选。
Auth_Tag＝HMAC-SHA-256(Ke2e_AE2_CSEl_msg_auth_conf,AAD|Nonce|时间)
AAD被指定整个消息报头，或替选地，AAD可以被指定为消息的消息报头或元数据的子集。
在Auth_Tag的生成中可以包括Nonce、时间或两者。在某些情况下，两个均可以被排除，因为被认为对每一会话唯一的M2M-Request-ID被包括在每一消息内。优选使用整个消息以用于计算Auth_Tag，替选地，可以使用消息报头用于生成Auth_Tag。然而，如果消息内的某些组件可能由中间实体(诸如CSE2 702)变更，那么仅可以使用能被用来保证消息的可靠性和意图的消息的那些组件。必须被完整性保护的消息的绝对必要的组件是：来自字段，“fr”；到字段，“to”；操作字段，“op”；资源ID，“res-id”(如果不同于“to”字段)；和会话标识符，“M2M-Request-ID”。根据上下文信息和用途参数(例如加密算法、加密模式和IV…)，包括数据有效载荷的剩余消息可以被加密。
在步骤3，AE2 1102创建可以可以为oneM2M消息收发进行变更和裁剪的基于JSON的表示(JSON Web加密表示(JWE))，用于携带Auth_Tag连同用来创建Auth_Tag的安全属性以及加密的消息和数据。JWE将包括下述安全属性：“cred-id”，其是用于识别证书的证书ID；和密钥，在这种情况下是Ke2e_AE2_CSEl_msg_auth-ID。替选地，如果使用单独的消息认证密钥和单独的消息机密性密钥，那么均应当发送关联的证书ID。使用的算法“alg”“AES-CCM”(举例来说)；有效载荷，“payload”，其包括消息或消息报头连同数据；和签名“sig”，其是Auth_Tag/MAC。此外，使用的初始化向量“iv”，以及基于加密过程生成的密文“ciphertext(密文)”也被包括为JWE的一部分。替选地，可以由在简明二进制对象表示(CBOR)对象签名和加密标准中描述的机制使用基于CBOR的表示代替base64。生成包含消息报头的oneM2M消息“请求”和表示为JWE的安全属性。
在图18的步骤4中，如果在CSE1 604和CSE2 702之间不存在现有的(D)TLS连接，根据oneM2M规范，将Kpsa_CSE2_CSEl用作对称密钥，在CSE1 604和CSE2 702之间建立(D)TLS连接。
在图18的步骤5中，将由AE2 1102创建的消息转发到CSE1 604。如果用于签名的算法是基于公开密钥的机制，那么，CSE2 702能够在将其转发到CSE1 604前认证该消息，但在此，由于使用对称密钥，基于在AE2 1102和CSE2 702之间存在的信任和基于(D)TLS连接建立的安全关联，隐含消息的认证，预期该消息来自受信AE2 1102。CSE2 702将该消息转发到CSE1 604，无需变更主消息报头。在消息报头被CSE 2702变更的情况下，CSE2 702生成消息报头的副本并且连同安全属性被包括为数据的一部分。在AE2 1102已经使用整个消息以创建安全属性(JWE)的情况下，那么CSE2 702在将其转发到CSE1 604前，将整个消息连同头部和安全属性(JWE)复制到数据有效载荷部分中，以使得保存所有必要的消息报头信息，使得能由接收方(例如CSE1)适当地构建Auth_Tagl。在图18步骤4建立的(D)TLS连接上，将该消息由CSE2 702发送到CSE1。
在图18的步骤6中，CSE1 604校验其是否为消息的目标。使用安全属性(JWE)，CSE1604使用证书ID以便校验正确的证书并且从安全密钥库(例如，诸如SIM卡的安全元件)提取它们，确定适当的上下文信息和用途参数。在单独的密钥被用于消息认证和消息机密性的情况下，将必须从密钥库提取两个密钥。使用JWE信息“alg”以及“cred-id”，CSE1 604能够确定AEAD是否被用于安全保护，且如果是，可以仅检索由cred-id识别的单个关联证书。基于确定安全类型(签名、加密)的上下文信息、涉及的实体等以及用途(Nonce的算法、可用性等)，校验消息是否具有正确的特性集，识别AAD、IV、Nonce和其它参数并且使用Ke2e_AE2_CSEl_msg_conf密钥以便解密“密文”并且提取“plaintext(明文)”，其可以包含消息和数据有效载荷。CSE1604使用该消息或消息的消息报头或元数据或使用已经被识别为AAD的信息，以计算Generated_Auth Tag。在一些实施方式中，由AE2 1102原始发送的整个消息，或消息的消息报头或元数据，并且使用可能存在的Nonce连同上下文信息，以及将参数作为输入提供到在这种情况下正好为AES-CCM的JWE内识别的“alg”中，并且生成Generated_Auth_Tag。CSE1 604校验Generated_Auth_Tag是否与包含在JWS内的Auth_Tag相同，且如果是，AE2的消息被认证。随后CSE1604检查以判断是否已经授权AE2 1102在AE2 602资源上执行“更新”操作。
在图18的步骤7中，如果授权AE2 1102执行“更新”操作，那么CSE1 604更新由R-ID识别的AE1资源。
在步骤8v，如果在AE1 602和CSE1 604之间不存在现有的(D)TLS连接，通过基于oneM2M技术规范TS-0003版本1使用共享对称密钥Kpsa_AEl_CSEl，创建新的(D)TLS连接。
在图18的步骤9中，CSE1 604将指示“更新”AE1的资源“R-ID”的“通知”消息发送到AE1 602。该消息在步骤8中建立的安全(D)TLS连接上发送。
在图18的步骤10中，CSE1 604创建响应消息并且使用与在图18的步骤2中由AE21102使用的过程相同的过程以生成不同的Auth_Tag2、加密消息和JWE。推荐每次使用新的Nonce和IV并且将其包括为JWE的一部分，并且不重用现有的Nonce。可以包括所有的安全属性(例如Nonce、Auth-Tag2、Credential-ID、识别为AAD的消息或消息的消息报头或元数据、IV和密文)以创建JWE2。
在图18的步骤11中，CSE1 604在步骤4中建立的安全(D)TLS连接上，将消息发送到CSE2 702。如果该连接不存在，那么，必须创建新的(D)TLS连接，与在图18的步骤4中创建的(D)TLS连接类似。可以与步骤8并行地发送消息10，然而，在某些关键情况下，可以比图18的步骤10更早地执行图18的步骤8。
在图18的步骤12中，如果公开密钥机制被用于生成JWE，通过检验JWE内的数字签名，CSE2 702可以校验从CSE1 604接收的消息的可靠性/完整性。由于在此使用对称密钥，CSE2 702使用隐含的信任，因为在安全的(D)TLS连接上接收该消息并且在步骤1中建立的安全的(D)TLS连接上将该消息转发到AE2 1102。如上所述，如果有效的(D)TLS连接不存在，那么必须使用Kpsa_AE2_CSE2 702对称密钥和使用在oneM2M技术规范TS-0003版本1中所述的机制，在CSE2 702和AE2 1102之间建立新的(D)TLS连接。
在图18的步骤13中，在使用图18的步骤6所述的类似机制解密消息后，AE2 1102校验JWE内的Auth_Tag2。使用的安全属性不同于图18的步骤6中的安全属性，然而，过程是相同的。
图19描述图示借助在借助在通过信任的或不太可信的或甚至不可信的中间跳的来回移动的作为彼此远离的多个服务层跳的两个实体AE2 1102和CSE1 604之间的对称密钥机制的端对端消息认证和完整性校验以及消息机密性的实施例。客户端应用(AE2 1102)想要在另一应用实体(AE1 602)的资源上执行更新操作。由于资源托管在托管CSE(CSE1604)上，AE2 1102已经被预提供资源的位置或使用发现服务以发现资源位置(/CSE1/R-ID)。CSE1 604想要确保仅授权的实体能够在AE1 602资源上执行创建、检索、更新、删除或通知操作中的任何一个。为了CSE1 604能够确保仅授权的实体能够执行CRUD操作，CSE1604可以通过校验消息的发起方拥有的密钥要求认证消息的来源是授权的并且保证消息完整性。此外，要求数据和消息收发的机密性被机密性保护。在创建消息的准备中，AE2 1102必须或从TTP分别获得适当的消息认证Ke2e_AE2_CSEl_msg_auth以及消息机密性密钥Ke2e_AE2_CSEl_msg_conf，或由向其提供的或使用上述“第三方证书请求过程”使用引导过程生成的端对端主密钥Ke2e_AE2_CSEl_master生成该密钥。替选地，可以使用单个Ke2e_AE2_CSEl_msg_auth_conf用于消息认证和消息机密性两者并且使用基于认证的加密和关联数据(AEAD)的加密机制(例如AES-CCM、AES-GCM)。除密钥外，获得、生成为了AE2 1102能够生成能由CSE1604使用的正确认证标记，以便校验AE2消息的可靠性和机密性而要求的上下文信息、用途信息和标签或将其提供给AE2 1102。并且为了确定适当算法、将在其上操作的模式、以及初始化向量(IV)的要求等的机密性，AE2 1102从密钥库选择适当的证书，用于执行端对端消息认证和消息机密性，因此，选择Ke2e_AE2_CSEl_msg_auth_conf密钥。
不同于不存在用于执行AE2 1102和CSE2 702之间的基于(D)TLS的安全连接建立的密钥的前一情形，相反，可用的证书被用于使用基于对象的安全模型在服务层提供AE21102和CSE2 702之间的消息认证。Ke2e_AE2_CSE2_msg_auth可以被称为端对端密钥或逐跳证书，两种方式之一均不重要，证书的用途和上下文才重要。用途和上下文信息提供有关将如何使用证书的指南。在第三方证书请求过程期间，可以从TTP获得或提供用途和上下文信息。在实体注册过程期间，TTP可以基于从服务提供商或实体获得的SP、DP和/或EP，获得或推断适当的用途和上下文信息以及相关的安全需求和特征。机制是通过使用包含在M2M订阅配置文件内的参考链接，从IN-CSE 2002获得SP、DP和/或EP。
应理解到执行在图18的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图18所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图18所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图18所示的任何发送和接收步骤。
在图19的步骤1中，AE2 1102不使用逐跳认证和安全通信建立机制。AE1 602生成用于在CSE1 604上托管的AE1的资源(识别为/CSE/R-ID)上执行“更新”操作的oneM2M“请求”消息。由M2M-Request-ID 1唯一地识别该请求消息。AE2 1102使用消息报头信息，也被称为OriginData，生成认证标记(Auth_Tag)或消息认证码(MAC)。替选地，整个消息被用作输入以创建Auth_Tag。如前所述，优选方法是完整性保护整个消息，然而，在某些实施方式中，为路由目的，可能由中间实体合理地变更一些组件，在这些情况下，必须确保未被中间实体变更但同时能够提供可靠性和AE2请求的完整性的仅那些组件。被用于oneM2M层路由的消息或消息报头或元数据未被加密并且被分类为关联数据(AAD)。AAD可以是完整性保护的。消息报头或元数据是用于指定“AAD”值的良好候选。
Auth_Tag＝HMAC-SHA-256(Ke2e_AE2_CSEl_msg_auth_conf,AAD|Nonce|时间)
AAD被指定整个消息报头，或替选地，AAD可以被指定为消息的消息报头或元数据的子集。
在Auth_Tag的生成中可以包括Nonce、时间或两者。在某些情况下，两个均可以被排除，因为被认为对每一会话唯一的M2M-Request-ID被包括在每一消息内。优选使用整个消息以用于计算Auth_Tag，替选地，可以使用消息报头用于生成Auth_Tag。然而，如果消息内的某些组件可能由中间实体(诸如CSE2 702)变更，那么仅可以使用能被用来保证消息的可靠性和意图的消息的那些组件。必须被完整性保护的消息的绝对必要的组件是：来自字段，“fr”；到字段，“to”；操作字段，“op”；资源ID，“res-id”(如果不同于“to”字段)；和会话标识符，“M2M-Request-ID”。根据上下文信息和用途参数(例如加密算法、加密模式和IV…)，包括数据有效载荷的剩余消息可以被加密。
在图19的步骤2，AE2 1102创建可以可以为oneM2M消息收发进行变更和裁剪的基于JSON的表示(JSON Web加密表示(JWE))，用于携带Auth_Tag连同用来创建Auth_Tag的安全属性以及加密的消息和数据。JWE将包括下述安全属性：“cred-id”，其是被用于识别证书的证书ID；和密钥，在这种情况下其是Ke2e_AE2_CSEl_msg_auth-ID。替选地，如果使用单独的消息认证密钥和单独的消息机密性密钥，那么均应当发送关联的证书ID。使用的算法“alg”“AES-CCM”(举例来说)；有效载荷，“payload”其包括消息或消息报头连同数据；和签名“sig”，其是Auth_Tag/MAC。此外，使用的初始化向量“iv”以及基于加密过程生成的密文“密文”也被包括为JWE的一部分。替选地，可以由在简明二进制对象表示(CBOR)对象签名和加密标准中描述的机制使用基于CBOR的表示代替base64。生成包含消息报头的oneM2M消息“请求”和表示为JWE的安全属性。
此外，AE1 602使用Ke2e_AE2_CSE2_msg_auth并且生成新的Nonce和生成包括内部安全性/JWE1参数的有关请求消息的Auth_Tag2。外部Auth_Tag2被用于与CSE2 702认证。AE2 1102基于在具有可由其证书ID Ke2e_AE2_CSE2_msg_auth-ID识别的关联证书Ke2e_AE2_CSE2_msg_auth提供的上下文信息和用途信息中提供的指南，生成包含Auth_Tag2(MAC)的JWS1。由AE2 1102创建的消息被转发到CSE1 604。
在图19的步骤3，CSE2 702使用在接收的消息内包含的JWS1信息以基于来自密钥库的证书ID连同用途信息和上下文信息，获得相关的证书。CSE2 702使用Nonce、Ke2e_AE2_CSE2_msg_auth和消息/消息报头，生成Auth_Tag，并且将其与包含在JWS1内的Auth_Tag比较，如果它们匹配，暗指已经认证过AE2的消息，并且如果已经授权AE21102发送该消息，那么CSE2 702处理请求消息。CSE2 702从该消息去除JWS1/MAC。
在图19的步骤4，CSE2 702生成JWS2或MAC并且将其追加到请求消息。使用Ke2e_CSE2_CSEl_msg_auth key，连同新生成的Nonce、消息或消息报头或元数据，并且基于与证书/密钥相关联的上下文信息和用途信息，生成JWS2内的Auth_Tag。CSE2 702将JWS2/MAC追加到请求消息并且将其发送到CSE1 604。必须注意到在存在通过仍然有效的(D)TLS连接创建的逐跳安全关联的情况下，那么可以在该安全连接上发送请求消息，而不是生成JWS2/MAC。可以基于服务提供商策略、设备能力等，确定使用(D)TLS而不是对象安全(例如使用JWS)。在不要求消息机密性的情况下，那么可以优选使用对象安全。在某些情况下，即使要求消息和数据机密性，策略可以规定使用JWE而不是(D)TLS，因为服务层可能能够提供安全服务，而不依赖于下层安全，或由于(D)TLS可能计算上和/或空间上更密集的性能原因。
在图19的步骤5，CSE1 604校验其是否为消息的目标。使用外部安全属性(JWS2/MAC)，CSE1 604使用相关证书ID以便识别正确的证书并且从密钥库(例如，诸如SIM卡的安全元件)提取它们，确定适当的上下文信息和用途参数。在这种情况下，在JWS2中检索Ke2e_CSE2_CSEl_msg_auth连同Nonce，并且使用消息或消息报头或消息的元数据，CSE1 604生成Generated_Auth_Tag并且将其与JWS2/MAC内的Auth_Tag比较，如果匹配，那么CSE1 604确认该消息是通过受信CSE1 604发送的。
CSE1 604丢弃外部JWS2/MAC并且处理内部安全属性/JWE1。从JEW1内，CSE1 604获得证书ID，在单独的密钥被用于消息认证和消息机密性两者的情况下，将必须基于证书ID从密钥库提取两个密钥。使用JWE信息“alg”以及“cred-id”，CSE1 604能够确定AEAD是否被用于安全保护，且如果是，可以仅检索由cred-id识别的单个关联证书。基于确定安全类型(签名、加密)的上下文信息、涉及的实体等以及用途(Nonce的算法、可用性等)，校验消息是否具有正确的特性集，识别AAD、IV、Nonce和其它参数并且使用Ke2e_AE2_CSEl_msg_conf密钥以便解密“密文”并且提取“明文”，其可以包含消息和数据有效载荷。CSE1 604使用该消息或消息报头或消息的元数据或使用已经被识别为AAD的信息，以计算Generated_AuthTag。在一些实施方式中，由AE2 1102原始发送的整个消息，或消息报头或消息的元数据，并且使用可能存在的Nonce连同上下文信息，以及将参数作为输入提供到在这种情况下正好为AES-CCM的JWE内识别的“alg”中，并且生成Generated_Auth_Tag。CSE1 604校验Generated_Auth_Tag是否与包含在JWE内的Auth_Tag相同，且如果是，AE2的消息被认证。
在图19的步骤6，CSE1 604然后校验以查看已经是否授权AE21102在AE1 602资源上执行“更新”操作。如果授权AE2 1102执行“更新”操作，那么CSE1 604更新由R-ID识别的AE1 602资源。
在图19的步骤7，CSE1 604准备将指示在AE1的资源上执行更新操作的“通知”消息发送到AE1 602。如果在AE1 602和CSE1 604之间不存在现有的(D)TLS连接，或如果在CSE1604和AE1 602之间不存在用于执行逐跳安全关联的证书，或如果策略规定不使用借助(D)TLS的逐跳安全关联，那么使用借助JWS的对象安全机制用来提供消息认证。CSE1 604基于与Ke2e_CSEl_AEl_msg_auth密钥相关联的上下文信息和用途信息，使用新生成的Nonce连同所述消息、消息报头或消息的元数据，生成JWS3/MAC。JWS3/MAC被追加到由CSE1 604生成的“通知”请求消息并且被发送到AE1 602，指示“更新”AE1的资源“R-ID”。如果策略规定借助(D)TLS的逐跳安全将被用于确保CSE1 604和AE1 602之间的通信，那么可以通过使用基于oneM2M技术规范TS-0003版本1需要被提供或生成的共享对称密钥Kpsa_AEl_CSEl，创建(D)TLS连接。“通知”消息可以在安全连接上被发送，而不是使用对象安全机制。
在图19的步骤8，AE1 602校验JWS3/MAC并且认证“通知”消息。
在图19的步骤9，CSE1 604创建响应消息，其是对由AE2 1102发送的请求消息的响应。CSE1 604使用与在步骤2中由AE2 1102使用的过程类似的处理，使用在AE2 1102和CSE1604之间关联的Ke2e_AE2_CSEl_msg_auth_conf以生成Auth_Tag2、加密的消息和JWE2。安全属性/JWE2被追加到消息报头或AAD。推荐每次使用新的Nonce和IV并且将其包括为JWE的一部分，并且不重用现有的Nonce。可以包括所有的(例如Nonce、Auth-Tag2、证书ID、识别为AAD的消息或消息的消息报头或元数据、IV和密文)以创建JWE2。可选地，CSE1 604还生成用来将消息认证提供给CSE2 702的外部JWS4/MAC(Auth_Tag)。通过使用Ke2e_CSE2_CSEl_msg_auth连同先前所述的适当参数，生成JWS4。
在图19的步骤10，CSE1 604将响应消息连同JWS4/MAC发送到CSE2 702。如果策略要求在CSE1 604和CSE2 702之间建立(D)TLS连接，那么可以在安全连接上发送响应消息并且跳过生成JWS4。
在图19的步骤11，CSE2 702可以通过校验JWS4校验从CSE1 604接收的消息的可靠性/完整性并且从该消息去除JWS4/MAC。然后，CSE2 702使用Ke2e_AE2_CSE2_msg_auth和如上所述的其它参数(例如新的Nonce、消息或消息报头或消息的元数据、上下文信息和其它参数)，生成Auth_Tag并且将Auth_Tag合并在JWS5上。
在图19的步骤12，AE2 1102通过使用如在图19的步骤5中所述的类似机制，使用响应消息上的Ke2e_AE2_CSE2_msg_auth密钥，校验JWS5并且认证还包括安全属性/JWE2的响应消息。因此，AE2 1102确定响应消息是通过受信CSE2 702转发的。
AE2 1102丢弃外部JWS5/MAC并且处理内部安全属性/JWE2。从JEW2内，AE2 1102获得证书ID，在单独的密钥被用于消息认证和消息机密性两者的情况下，将必须基于证书ID从密钥库提取两个密钥。使用JWE信息“alg”以及“cred-id”，AE2 1102能够确定AEAD是否被用于安全保护，如果是，可以仅检索由cred-id识别的单个关联证书。基于确定安全类型(签名、加密)的上下文信息、涉及的实体等以及用途(Nonce的算法、可用性等)，校验消息是否具有正确的特性集，识别AAD、IV、Nonce和其它参数并且使用Ke2e_AE2_CSEl_msg_conf密钥以便解密“密文”并且提取“明文”，其包含消息和数据有效载荷。AE2 1102使用该消息或消息报头或消息的元数据或使用已经被识别为AAD的信息，以便计算Generated_Auth Tag。在一些情况中，由CSE1 604原始发送的整个消息，或消息的消息报头或元数据，并且使用可能存在的Nonce连同上下文信息，以及将参数作为输入提供到在这种情况下正好为AES-CCM的JWE内识别的“alg”中，并且生成Generated_Auth_Tag。AE2 1102校验Generated_Auth_Tag是否与包含在JWE内的Auth_Tag相同，且如果是，AE2的消息被认证。
应理解到执行在图19的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图19所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图19所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图19所示的任何发送和接收步骤。
使用委托模式的在会话层的E2E认证
图9图示使用委托模式在会话层(DTLS/TLS)处执行的E2E认证。与上述使用的方法类似，除了在此通过在两个E2E实体(CSE1 604和CSE3 502)之间建立单独的会话层连接执行认证。CSE1 604和CSE3502使用在请求消息内携带的E2E认证MAC执行基于DTLS或TSL的认证而不是执行逐跳认证。消息收发详情：
图9的步骤1-4，与参考图8A-B的消息收发机制类似、
图9的步骤5，CSE1 604使用KpsaE2E，CSE3 502建立DTLS连接。作为参数提供过程的一部分，CSE1 604能够获得应当被用于在CSE1 604和CSE3 502之间建立E2E DTLS的CSE3502的URI和端口#。
图9的步骤6，在DTLS隧道内，将来自CSE1 604的请求消息转发到CSE3 502。在此，CSE3经由从CSE1 604的DTLS隧道，被假定为另一下一跳。
图9的步骤7，CSE3 502校验消息发起方信息，其在此正好为CSE1604。
应理解到执行在图9的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图9所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图9所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图9所示的任何发送和接收步骤。
使用直接模式，在会话层处的E2E认证
图10图示使用直接模式在会话层处的E2E认证，以及不同于在前所述的机制，AE1602基于从TTP获得的与CSE3 502相关联的证书，与CSE3 502建立直接DTLS连接。使用URI、端口#和AE ID，适当地配置资源。CSE3 502校验是否消息的发起方。
应理解到执行在图10的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图10所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图10所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图10所示的任何发送和接收步骤。
组认证
可以基于由那些实体提供的能力和功能性分组实体。设想提供相同类型的服务的每一实体可以借助“服务标识”被识别，或在oneM2M的情况下，被识别为在M2M服务提供商域内唯一的或甚至全局唯一的“应用标识”。
情形1：可以以多种方式执行组认证：
ο与每一组相关联的唯一组密钥
ο在服务使能和安全配置过程期间提供
ο属于同一组的所有实体共享相同E2E组密钥
οE2E使用可以在提供阶段预提供的组认证密钥，认证彼此
ο在认证后，可以推导组会话密钥并且在由组管理员(例如CSE)提供的组成员之间共享
情形2：无唯一组密钥，但唯一E2E认证密钥(减少E2E消息收发)——委托认证的特殊情形
ο可以由组管理员(例如托管CSE)管理组
ο所有组成员注册到托管CSE
ο组的每一成员具有唯一E2E认证密钥
ο如在前文章节中所述，使用唯一E2E认证密钥，通过远程CSE或任何其它实体，认证组成员
情形3：混合模式
ο由预先被提供有其自己的组管理员密钥(GM密钥)的组管理员管理组
ο所有组成员注册到组管理员
ο组的每一成员具有唯一E2E认证密钥
ο组管理员将GM密钥用作用于初始组认证的E2E组密钥
ο用于每一实体的唯一E2E认证密钥被用于另外的多因子/多层认证
ο组的新成员可以使用E2E组密钥来获得它们的唯一E2E密钥，或可以在服务使能和安全配置过程期间提供。
ο
组认证过程可以包括：
ο对将用于该组的共用安全参数，在组管理员和组成员之间协商
ο对将用于组的新的/未来成员的证书，在组管理员和TTP之间协商和撤消组成员信息和相关证书
在图11A-B中图示其中不提供组密钥，但在委托认证模式情形中在两个实体之间使用唯一E2E密钥的组认证的实施例。由组管理员(例如CSE1 604)管理组。描述相关步骤：
图11A-B的步骤1-6遵循前面章节中所述的机制。
在图11A-B的步骤7中，基于基于消息收发的目标推断的信息，CSE1创建包括消息2的相关部分连同(使用与实体A相关联的Kpsa_E2E1生成的)MAC1以及消息6的相关部分连同(使用与实体B相关联的Kpsa_E2E2生成的)MAC2的合并消息。
图11A-B的步骤8与在前章节中所述相同。
在图11A-B的步骤9中，CSE1 604使用KpsaE2E，与CSE3 502(目标)创建(D)TLS连接。
图11A-B的步骤10，将在步骤7创建的合并消息在(D)TLS连接上由CSE1 604安全地发送到CSE3 502。
图11A-B的步骤11，CSE3 502通过校验发起方或消息，校验存在从两个实体(AE1602和CSE1 102)发起的两个服务层消息，由此校验各自的MAC，并且还确保还未重放消息。
应理解到执行在图11A-B的步骤中所示的步骤的实体是可以以在诸如图21C或图21D所示的网络节点或计算机系统的存储器中存储并且在其处理器上执行的软件(例如计算机可执行指令)的形式实现的逻辑实体。即，图11A-B所示的方法可以以在网络节点(诸如图21C或图21D所示的节点或计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式实现，该计算机可执行指令当由节点的处理器执行时，执行图11A-B所示的步骤。还理解到可以在节点的处理器和其执行的计算机可执行指令(例如软件)的控制下，由节点的通信电路实现图11A-B所示的任何发送和接收步骤。
界面
诸如图形用户界面(GUI)的界面能被用来帮助用户控制和/或配置有关端对端授权的功能性。图12是图示允许用户选择和配置端对端认证，包括配置服务使能功能和密钥递送功能的界面1202的图。用户界面1202能被用来在M2M设备/网关/服务器处配置/显示端对端安全策略和相关安全参数。应理解到能使用如下文所述的图21C-D所示的那些显示器，生成界面2102。
示例M2M/IoT/WoT通信系统
图21A是其中可实现一个或多个公开的实施例的示例机器间(M2M)、物联网(IoT)或万物网(WoT)通信系统10的图。一般地，M2M技术提供了用于IoT/WoT的构建块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台可以是IoT/WoT的组件或节点以及IoT/WoT服务层等。通信系统10可以用来实现公开的实施例的功能，并且可以包括功能性和逻辑实体，诸如服务使能功能204和304，密钥递送功能206，受信第三方，CSE 402、502、504、604、704和2002，CSF 408和412，AE1 602，AE2 1102，SP储存库2004，DP/EP储存库2006，MEF 2008，和产生用户界面1202的逻辑实体。
如图21A中所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、Fiber、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可由向多个用户提供诸如语音、数据、视频、消息、广播等内容的多个接入网构成。例如，通信网络12可采用一个或多个信道接入法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。此外，通信网络12可包括其它网络，诸如核心网络、因特网、传感器网络、工业控制网络、个域网、融合个人网络、卫星网络、家庭网络或企业网。
如图21A中所示，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终端设备18和网关14可经由包括蜂窝式、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)的各种网络、直接无线电链路以及线缆进行通信。
示例M2M终端设备18包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康监视器、灯、恒温器、器具、车库门及其它基于致动器的设备、安全设备以及智能插座。
参考图21B，场域中的所示M2M服务层22为M2M应用20、M2M网关设备14以及M2M终端设备18和通信网络12提供服务。通信网络12可以用来实现公开的实施例的功能，并且可以包括功能和逻辑实体，诸如服务使能功能204和304，密钥递送功能206，受信第三方，CSE402、502、504、604、704和2002，CSF 408和412，AE1 602，AE2 1102，SP储存库2004，DP/EP储存库2006，MEF 2008，和产生用户界面1202的逻辑实体。可由一个或多个服务器、计算机、设备、虚拟机(例如，云/计算/存储群等)等来实现M2M服务层22，包括例如下面所述的图21C和21D中所示的设备。将理解的是M2M服务层22可按需与任何数量的M2M应用、M2M网关设备14、M2M终端设备18和通信网络12通信。M2M服务层22可由网络的一个或多个节点实现，其可包括服务器、计算机、设备等。M2M服务层22提供应用于M2M终端设备18、M2M网关14以及M2M应用20的服务能力。可用多种方式来实现M2M服务层22的功能，例如作为网络服务器、在蜂窝式核心网络中、在云中等。
类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12'提供服务。M2M服务层22'还为场域中的M2M网关设备14和M2M终端设备18提供服务。将理解的是M2M服务层22'可与任何数量的M2M应用、M2M网关和M2M设备通信。M2M服务层22'可通过不同的服务提供商与服务层相交互。M2M服务层22'可由网络的一个或多个节点实现，其可包括服务器、计算机、设备、虚拟机(例如，云计算/存储群等)等。
还参考图21B，M2M服务层22和22'提供了不同应用和垂直可以利用的核心的一组核心服务递送能力。这些服务能力使得M2M应用20和20'能够与设备相交互并执行诸如数据收集、数据分析、设备管理、安全、计费、服务/设备发现等功能。本质上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并减少了成本和上市时间。服务层22和22'还使得M2M应用20和20'能够通过与服务层22和22'提供的服务相连接的各种网络12和12'进行通信。
可将本申请的方法实现为服务层22和22'的一部分。服务层22和22'是通过应用编程界面(API)和底层联网界面的集合来支持增值服务能力的软件中间件层。ETSI M2M和oneM2M两者都使用可包含本申请的连接方法的服务层。ETSI M2M的服务层被称为服务能力层(SCL)。可在M2M设备(其中将其称为设备SCL(DSCL))、网关(其中将其称为网关SCL(GSCL))和/或网络节点(其中将其称为网络SCL(NSCL))内实现SCL。oneM2M服务层支持公共服务功能(CSF)(即服务能力)的集合。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以在不同类型的网络节点(例如基础设施节点、中间节点、应用特定节点)上托管。此外，可以将本申请的连接方法实现为M2M网络的一部分，其使用面向服务架构(SOA)和/或面向资源架构(ROA)来接入诸如本申请的连接方法的服务。
在某些实施例中，可与公开的系统和方法相结合地使用M2M应用20和20'。M2M应用20和20'可包括与UE或网关相交互的应用，并且还可与其它公开的系统和方法相结合地使用。
在一个实施例中，可在由如图21B中所示的M2M节点,诸如M2M服务器、M2M网关或M2M设备托管的M2M服务层实例内托管诸如服务使能功能204和304、密钥递送功能206、受信第三方、CSE 402、502、504、604、704和2002、CSF 408和412、AE1 602、AE2 1102、SP储存库2004、DP/EP储存库2006、MEF 2008的逻辑实体，和产生用户界面1202的逻辑实体。例如，诸如服务使能功能204和304、密钥递送功能206、受信第三方、CSE 402、502、504、604、704和2002、CSF 408和412、AE1 602、AE2 1102和产生用户界面1202的逻辑实体的逻辑实体可以包括包括在M2M服务层实例内的单独服务能力或者作为现有服务能力内的子功能。
M2M应用20和20'可包括在各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全和监控。如上所述，跨越系统的设备、网关、服务器及其它节点运行的M2M服务层支持诸如数据收集、设备管理、安全、计费、位置跟踪/地理围栏、设备/服务发现、以及传统系统集成的功能，并将这些功能作为服务提供给M2M应用20和20'。
一般地，服务层22和22'定义了通过应用编程界面(API)和底层联网接口的集合来支持增值服务能力的软件中间件层。ETSI M2M和oneM2M架构两者都定义了服务层。ETSIM2M的服务层称为服务能力层(SCL)。可在ETSI M2M架构的多种不同节点中实现SCL。例如，可在M2M设备(其中，将其称为设备SCL(DSCL))、网关(其中，将其称为网关SCL(GSCL))和/或网络节点(其中，将其称为网络SCL(NSCL))内实现服务层的实例。oneM2M服务层支持公共服务功能(CSF)(即服务能力)的集合。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以在不同类型的网络节点(例如基础设施节点、中间节点、应用特定节点)上托管。第三代合作伙伴计划(3GPP)还定义了用于机器类型通信(MTC)的架构。在该架构中，服务器及其提供的服务能力被实现为服务能力服务器(SCS)的一部分。无论体现在ETSI M2M架构的DSCL、GSCL或NSCL中，3GPP MTC架构的服务能力服务器(SCS)中，oneM2M架构的CSF或CSE中还是网络的某个其它节点中，服务层的实例都可被实现为在网络中的一个或多个独立节点(包括服务器、计算机及其它计算设备或节点)上或者作为一个或多个现有节点的一部分执行的逻辑实体(例如，软件、计算机可执行指令等)。作为示例，可以在具有下面描述的图21C或图21D中所示的通用架构的网络节点(例如，服务器、计算机、网关、设备等)上运行的软件的形式实现服务层或其组件的实例。
此外，可以将诸如服务使能功能204和304、密钥递送功能206、受信第三方、CSE402、502、504、604、704和2002、CSF 408和412、AE1 602、AE2 1102和产生用户界面1202的逻辑实体的逻辑实体实现为M2M网络的一部分，其使用面向服务架构(SOA)和/或面向资源架构(ROA)来接入本申请的服务。
图21C是诸如M2M设备18、M2M网关14、M2M服务器等的M2M网络节点30的示例硬件/软件架构的框图。节点30可以执行或包括诸如服务使能功能204和304、密钥递送功能206、受信第三方、CSE 402、502、504、604、704和2002、CSF 408和412、AE1 602、AE2 1102、SP储存库2004、DP/EP储存库2006、MEF 2008的逻辑实体和产生用户界面1202的逻辑实体。设备30可以是M2M网络的一部分，如图21A-B中所示，或非M2M网络的一部分。如图21C中所示，M2M节点30可包括处理器32、不可移动存储器44、可移动存储器46、扬声器/扩音器38、小键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片集50及其它外设52。节点30还可包括通信电路，诸如收发机34和发送/接收元件36。将认识到的是M2M节点30可包括前述元件的任何子组合，而仍与实施例保持一致。此节点可以是实现本文所述的SMSF功能的节点。
处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。一般地，处理器32可执行存储在节点的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令以便执行节点的各种所需功能。例如，处理器32可执行信号编码、数据处理、功率控制、输入/输出处理和/或使得M2M节点30能够在无线或有线环境中操作的任何其它功能。处理器32可运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。例如，处理器32还可执行诸如在接入层和/或应用层处的诸如认证、安全密钥协议和/或密码操作的安全操作。
如图21C中所示，处理器32被耦合至其通信电路(例如，收发机34和发送/接收元件36)。通过计算机可执行指令的执行，处理器32可以控制通信电路以使节点30经由其被连接到的网络来与其它节点通信。特别地，处理器32可控制通信电路以执行在本文和权利要求中描述的发送和接收步骤。虽然图21C将处理器32和收发机34描绘为分离的组件，但将认识到的是可将处理器32和收发机34一起集成在电子封装或芯片中。
发送/接收元件36可被配置成向其它M2M节点(包括M2M服务器、网关、设备等)发送信号或从其接收信号。例如，在实施例中，发送/接收元件36可以是被配置成发送和/接收RF信号的天线。发送/接收元件36可支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在实施例中，发送/接收元件36可以是被配置成发送和/或接收IR、UV或可见光信号的发射器/探测器。在另一实施例中，发送/接收元件36可被配置成发送和接收RF和光信号两者。将认识到的是发送/接收元件36可被配置成发送和/或接收无线或有线信号的任何组合。
另外，虽然发送/接收元件36在图21C中被描绘为单个元件，但M2M节点30可包括任何数量的发送/接收元件36。更具体地，M2M节点30可采用MIMO技术。因此，在实施例中，M2M节点30可包括用于发送和接收无线信号的两个或更多发送/接收元件36(例如，多个天线)。
收发器34可被配置成调制将提供发送/接收元件36发送的信号并解调将由发送/接收元件36接收到的信号。如上所述，M2M节点30可具有多模式能力。因此，例如，收发器34可包括用于使得M2M节点30能够经由诸如UTRA和IEEE 802.11的多个RAT进行通信的多个收发器。
处理器32可从任何类型的适当存储器(诸如不可移动存储器44和/或可移动存储器46)访问信息并在其中存储数据。例如，如上所述，处理器32可将会话上下文存储在其存储器中。不可移动存储器44可包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、或任何其它类型的存储器存储设备。可移动存储器46可包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可从在物理上不位于M2M节点30上(诸如在服务器或家用计算机上)的存储器访问信息以及在其中存储数据。处理器32可被配置成控制显示器或指示器42上的照明图案、图像或色彩以反映M2M服务层会话迁移或共享的状态，或从用户获得输入，或者向用户显示关于节点的会话迁移或共享能力或设置的信息。在另一示例中，显示器可示出关于会话状态的信息。本公开定义了oneM2M实施例中的RESTful用户/应用API。可在API的顶部上将可在显示器上示出的图形用户界面分层，以允许用户经由本文所述的底层服务层会话功能来交互式地建立并管理E2E会话或其迁移或共享。
处理器32可从电源48接收电力，并且可被配置成向M2M节点30中的其它组件分配和/或控制电力。电源48可以是用于对M2M节点30供电的任何适当设备。例如，电源48可包括一个或多个干电池(例如，镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。
处理器32还可被耦合到GPS芯片集50，其被配置成提供关于M2M节点30的当前位置的位置信息(例如，经度和纬度)。将认识到的是M2M节点30可通过任何适当的位置确定方法来获取位置信息，而仍与实施例保持一致。
处理器32可进一步被耦合到其它外设52，其可包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外设52可包括加速度计、电子指南针、卫星收发器、传感器、数字式照相机(用于照片或视频)、通用串行总线(USB)端口、振动设备、电视收发器、免提耳机、
Figure BDA0003213446000000641
模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等。
图21D是还可用来实现M2M网络的一个或多个节点(诸如M2M服务器、网关、设备或其它节点)的示例计算系统90的框图。计算系统90可包括计算机或服务器，并且可主要由可以以软件的形式的计算机可读指令来控制，无论在哪里或通过何种手段来存储或访问此类软件。计算系统90可以执行或包括诸如服务使能功能204和304、密钥递送功能206、受信第三方、CSE 402、502、504、604、704和2002、CSF 408和412、AE1 602、AE2 1102、SP储存库2004、DP/EP储存库2006、MEF 2008和产生用户界面1202的逻辑实体的逻辑实体。计算系统90可以是M2M设备、用户设备、网关、UE/GW或任何其它节点，包括例如移动核心网络的节点、服务层网络应用提供商、终端设备18或M2M网关设备14。此类计算机可读指令可在诸如中央处理单元(CPU)91的处理器内被执行以促使计算系统90进行工作。在许多已知工作站、服务器以及个人计算机中，中央处理单元91由被称为微处理器的单片CPU实现。在其它机器中，中央处理单元91可包括多个处理器。协处理器81是不同于主CPU 91的可选处理器，其执行附加功能或协助CPU 91。CPU 91和/或协处理器81可接收、生成以及处理与用于E2E M2M服务层会话的公开系统和方法有关的数据，诸如接收会话证书并基于该会话证书进行认证。
在操作中，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，其负责将CPU 91的指令通信给诸如打印机94、键盘84、鼠标95以及磁盘驱动器85的外设。
由显示器控制器96控制的显示器86被用来显示由计算系统90生成的视觉输出。此类视觉输出可包括文本、图形、动画图形以及视频。可用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸板来实现显示器86。显示器控制器96包括生成被发送到显示器86的视频信号所需的电子组件。
此外，计算系统90可包含通信电路，例如网络适配器97，其可用来将计算系统90连接到外部通信网络，诸如图21A和图21B的网络12，以使得计算系统90能够与网络的其它节点通信。
用户设备(UE)能是由终端用户用来通信的任何设备。能是手持电话、具有移动宽带适配器的手提电脑或任何其它设备。例如，UE能被实现为图21A-B的M2M终端设备或图21C的设备30。
应理解的是可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式来体现本文所述的任何或所有系统、方法以及过程，该指令在被诸如M2M网络的节点(包括例如M2M服务器、网关、设备等)的机器执行时执行和/或实现本文所述的系统、方法和过程。具体地，可以以此类计算机可执行指令的形式实现上文所述的任何步骤、操作或功能，包括网关、UE、UE/GW或移动核心网络、服务层或网络应用提供商的任何节点的操作。可以以存储在计算机可读存储介质上的计算机可执行指令的形式体现诸如服务使能功能204和304、密钥递送功能206、受信第三方、CSE 402、502、504、604、704和2002、CSF 408和412、AE1 602、AE2 1102、SP储存库2004、DP/EP储存库2006、MEF 2008和产生用户界面1202的逻辑实体的逻辑实体。计算机可读存储介质包括以用于信息存储的任何非临时(即，有形或物理)方法或技术实现的易失性和非易失性、可移动和不可移动介质两者，但是此类计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储技术、CD-ROM、数字多功能磁盘(DVD)或其它光盘存储、磁带盒、磁带、磁盘存储器或其它磁存储器件、或者可以用来存储期望信息且可以由计算机访问的其它有形或物理介质。
在描述本公开的主题的优选实施例时，如图中所示，为了明了起见而采用特定术语。然而，要求保护的主题并不意图局限于这样选择的特定术语，并且应理解的是每个特定元件包括以类似方式操作以实现类似目的的所有技术等价物。
本书面描述使用示例来公开本发明，包括最佳模式，并且还使得本领域的技术人员能够实施本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可以取得专利的范围由权利要求定义，并且可包括本领域的技术人员想到的其它示例。如果此类示例具有不同于权利要求的字面语言的元件或者如果其包括与权利要求的字面语言无实质性差别的等价元件，则此类其它示例意图落入权利要求的范围内。

Claims (14)

1.一种用于使得要通过网络发送的消息安全的服务层方法，所述方法包括：
由第一实体从所述网络上的受信第三实体请求第一证书，所述第一证书要用于第一应用实体和目标实体对所述消息的端对端认证，
其中，第一实体在所述网络的第一装置上实现，并且所述目标实体在所述网络的另一个装置上实现；
其中，在通过所述网络的穿过第一实体和目标实体之间的一个或多个中间实体的路径上发送所述消息；
从所述网络上的所述受信第三实体接收第一证书；
由第一实体基于第一证书和与所述消息相关联的至少一些信息生成用于认证所述消息的认证码；
由第一实体经由在第一实体和第一中间服务层实体之间建立的安全隧道向到所述目标实体的所述路径上的第一中间服务层实体发送所述消息和所述认证码，所述安全隧道是使用与第一证书不同的证书建立的；
其中，此后所述消息和所述认证码沿着所述路径从中间服务层实体向中间服务层实体安全地发送，直到所述消息和所述认证码到达所述目标实体为止，并且其中沿着所述路径从一个中间服务层实体到下一个中间服务层实体的每个发送都是使用与第一证书不同并与在任何其他中间服务层实体对之间使用的证书不同的证书而安全化的；以及
其中，在接收到所述消息和所述认证码时，所述目标实体在所述目标实体处使用所述认证码和第一证书来认证所述消息。
2.如权利要求1所述的方法，其中，在所述目标实体处认证所述消息包括：
使用所述认证码验证在所述目标实体处接收到的所述消息是从第一实体发起的。
3.如权利要求2所述的方法，其中，在所述目标实体处认证所述消息还包括：
使用所述认证码验证在所述目标实体处接收到的所述消息的完整性。
4.如权利要求1所述的方法，其中，所述认证码包括以下项中的一个或多个：
所述消息的至少一部分；
第一证书；
nonce；和
创建所述消息时的时间戳。
5.如权利要求1所述的方法，其中，针对第一证书的向所述第三实体的请求包括所述目标实体的标识符。
6.如权利要求1所述的方法，其中，所述目标实体在从所述中间服务层实体中的给定的中间服务层实体接收所述消息和所述认证码之前，从所述受信第三实体接收第一证书。
7.如权利要求1所述的方法，其中，所述目标实体在从所述中间服务层实体中的给定的中间服务层实体接收所述消息和所述认证码之后，从所述受信第三实体请求第一证书。
8.一种在网络的第一装置上实现的第一实体，所述第一实体包括处理器和存储有指令的存储器，所述指令在由处理器执行时，使得要从第一实体向在所述网络的相应的其他装置上实现的多个实体中的目标实体发送的消息安全化，所述指令在由处理器执行时，使得第一实体实现包括以下操作的方法：
由第一实体从所述网络上的受信第三实体请求要用于第一实体和所述目标实体对所述消息的端对端认证的第一证书，
其中，在通过所述网络的穿过第一实体和目标实体之间的一个或多个中间服务层实体的路径上发送所述消息；
从所述网络上的所述受信第三实体接收第一证书；
由第一实体基于第一证书和与所述消息相关联的至少一些信息生成用于认证所述消息的认证码；
由第一实体经由在第一实体和第一中间服务层实体之间建立的安全隧道向到所述目标实体的所述路径上的第一中间服务层实体发送所述消息和所述认证码，所述安全隧道是使用与第一证书不同的证书建立的；
其中，此后所述消息和所述认证码沿着所述路径从中间服务层实体向中间服务层实体安全地发送，直到所述消息和所述认证码到达所述目标实体为止，并且其中沿着所述路径从一个中间服务层实体到下一个中间服务层实体的每个发送都是使用与第一证书不同并与在任何其他中间服务层实体对之间使用的证书不同的证书而安全化的；以及
其中，在接收到所述消息和所述认证码时，所述目标实体在所述目标实体处使用所述认证码和所述第一证书来认证所述消息。
9.如权利要求8所述的第一实体，其中，在所述目标实体处认证所述消息包括：
使用所述认证码验证在所述目标实体处接收到的所述消息是从第一实体发起的。
10.如权利要求9所述的第一实体，其中，在所述目标实体处认证所述消息还包括：
使用所述认证码验证在所述目标实体处接收到的所述消息的完整性。
11.如权利要求8所述的第一实体，其中，所述认证码包括以下项中的一个或多个：
所述消息的至少一部分；
第一证书；
nonce；和
创建所述消息时的时间戳。
12.如权利要求8所述的第一实体，其中，针对第一证书的向所述第三实体的请求包括所述目标实体的标识符。
13.如权利要求8所述的第一实体，其中，所述目标实体在从所述中间服务层实体中的给定的中间服务层实体接收所述消息和所述认证码之前，从所述受信第三实体接收第一证书。
14.如权利要求8所述的第一实体，其中，所述目标实体在从所述中间服务层实体中的给定的中间服务层实体接收所述消息和所述认证码之后，从所述受信第三实体请求第一证书。
CN202110936616.XA 2014-10-31 2015-10-30 端对端服务层认证 Active CN113596828B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110936616.XA CN113596828B (zh) 2014-10-31 2015-10-30 端对端服务层认证

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462073578P 2014-10-31 2014-10-31
US62/073,578 2014-10-31
CN201580067913.8A CN107005569B (zh) 2014-10-31 2015-10-30 端对端服务层认证
PCT/US2015/058368 WO2016114842A1 (en) 2014-10-31 2015-10-30 End-to-end service layer authentication
CN202110936616.XA CN113596828B (zh) 2014-10-31 2015-10-30 端对端服务层认证

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201580067913.8A Division CN107005569B (zh) 2014-10-31 2015-10-30 端对端服务层认证

Publications (2)

Publication Number Publication Date
CN113596828A true CN113596828A (zh) 2021-11-02
CN113596828B CN113596828B (zh) 2024-08-16

Family

ID=55949061

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201580067913.8A Active CN107005569B (zh) 2014-10-31 2015-10-30 端对端服务层认证
CN202110936616.XA Active CN113596828B (zh) 2014-10-31 2015-10-30 端对端服务层认证

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201580067913.8A Active CN107005569B (zh) 2014-10-31 2015-10-30 端对端服务层认证

Country Status (6)

Country Link
US (2) US10129031B2 (zh)
EP (1) EP3213488A1 (zh)
JP (2) JP6508688B2 (zh)
KR (1) KR102021213B1 (zh)
CN (2) CN107005569B (zh)
WO (1) WO2016114842A1 (zh)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6390618B2 (ja) * 2013-07-19 2018-09-19 ソニー株式会社 コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム
US9704355B2 (en) 2014-10-29 2017-07-11 Clover Network, Inc. Secure point of sale terminal and associated methods
CN108476236B (zh) * 2015-12-30 2021-08-03 康维达无线有限责任公司 物联网数据的基于语义的内容规范
US11388174B2 (en) 2016-02-29 2022-07-12 Secret Double Octopus Ltd System and method for securing a communication channel
US10229285B2 (en) * 2016-03-22 2019-03-12 International Business Machines Corporation Privacy enhanced central data storage
US11157641B2 (en) * 2016-07-01 2021-10-26 Microsoft Technology Licensing, Llc Short-circuit data access
US10212590B2 (en) * 2016-08-16 2019-02-19 Lg Electronics Inc. Method and apparatus for authenticating device in wireless communication system
EP3516840B1 (en) * 2016-09-21 2021-06-23 Telefonaktiebolaget LM Ericsson (PUBL) Methods and apparatus for communication
KR101831604B1 (ko) * 2016-10-31 2018-04-04 삼성에스디에스 주식회사 데이터 전송 방법, 인증 방법 및 이를 수행하기 위한 서버
JP6806543B2 (ja) * 2016-11-25 2021-01-06 キヤノン株式会社 権限検証システムおよびリソースサーバー、認証サーバー、権限検証方法
US10560476B2 (en) * 2017-02-22 2020-02-11 International Business Machines Corporation Secure data storage system
WO2018170391A1 (en) * 2017-03-17 2018-09-20 Convida Wireless, Llc Distributed transaction management in a network service layer
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
US10404810B2 (en) 2017-06-20 2019-09-03 Futurewei Technologies, Inc. Session layer communications using an ID-oriented network
WO2019009928A1 (en) * 2017-07-05 2019-01-10 Intel Corporation ESTABLISHING CONNECTIONS BETWEEN IDO DEVICES USING AUTHENTICATION TOKENS
EP3432539B1 (de) * 2017-07-20 2020-12-23 Siemens Aktiengesellschaft Verfahren zum aufbau eines kommunikationskanals zwischen einer servereinrichtung und einer clienteinrichtung
CN110234112B (zh) * 2018-03-05 2020-12-04 华为技术有限公司 消息处理方法、系统及用户面功能设备
WO2019177636A1 (en) * 2018-03-16 2019-09-19 Leviton Manufacturing Co., Inc. Apparatus, system and method for associating a device to a user of a service
US11398900B2 (en) * 2018-06-21 2022-07-26 Oracle International Corporation Cloud based key management
EP3821562A4 (en) * 2018-07-12 2022-03-23 Nokia Technologies Oy SECURITY MANAGEMENT FOR UNAUTHORIZED REQUESTS IN A COMMUNICATION SYSTEM WITH SERVICE-BASED ARCHITECTURE
US10326797B1 (en) * 2018-10-03 2019-06-18 Clover Network, Inc Provisioning a secure connection using a pre-shared key
US11233637B2 (en) * 2018-10-18 2022-01-25 Secret Double Octopus Ltd System and method for validating an entity
CN109286639A (zh) * 2018-11-29 2019-01-29 郑静 一种基于RESTful架构的电子认证兼容控制系统及使用方法
KR20200079776A (ko) * 2018-12-26 2020-07-06 펜타시큐리티시스템 주식회사 oneM2M 환경에서 하드웨어 보안 모듈을 이용한 인증 방법 및 장치
US11520299B2 (en) * 2019-03-30 2022-12-06 Honeywell International Inc. Shared data center based industrial automation system for one or multiple sites
WO2021087494A1 (en) * 2019-11-03 2021-05-06 Valimail Inc. Centralized secure distribution of messages and device updates
EP4184978A4 (en) * 2020-07-30 2023-08-30 Huawei Technologies Co., Ltd. COMMUNICATION METHOD AND DEVICE
WO2022069056A1 (en) * 2020-10-02 2022-04-07 Huawei Technologies Co., Ltd. Protection of sensitive user data in communication networks
CN115348046A (zh) * 2021-05-13 2022-11-15 华为技术有限公司 一种报文传输方法及装置
US11979396B2 (en) 2021-05-19 2024-05-07 Bank Of America Corporation Information security system and method for machine-to-machine (M2M) security and validation
US11941266B2 (en) 2021-10-20 2024-03-26 Samsung Electronics Co., Ltd. Resource isolation in computational storage devices

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102106135A (zh) * 2008-06-16 2011-06-22 艾利森电话股份有限公司 经由中间节点发送媒体数据
CN103392319A (zh) * 2010-12-30 2013-11-13 交互数字专利控股公司 针对通信切换场景的认证和安全信道设置
CN103460738A (zh) * 2011-03-23 2013-12-18 交互数字专利控股公司 用于使网络通信安全的系统和方法
US20140129838A1 (en) * 2012-11-02 2014-05-08 Young Jin Kim Method and apparatus for resilient end-to-end message protection for large-scale cyber-physical system communications

Family Cites Families (119)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5689565A (en) 1995-06-29 1997-11-18 Microsoft Corporation Cryptography system and method for providing cryptographic services for a computer application
AU7072096A (en) 1995-09-25 1997-04-30 Motorola, Inc. Method and apparatus for relaying digitally signed messages
US6145079A (en) 1998-03-06 2000-11-07 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary to perform electronic services
CN1276612C (zh) 1999-09-07 2006-09-20 索尼公司 信息发送系统、设备、方法和信息接收设备、方法
GB2357226B (en) * 1999-12-08 2003-07-16 Hewlett Packard Co Security protocol
GB2357227B (en) * 1999-12-08 2003-12-17 Hewlett Packard Co Security protocol
US20020087862A1 (en) 2000-01-07 2002-07-04 Sandeep Jain Trusted intermediary
US20020007453A1 (en) 2000-05-23 2002-01-17 Nemovicher C. Kerry Secured electronic mail system and method
US7203837B2 (en) 2001-04-12 2007-04-10 Microsoft Corporation Methods and systems for unilateral authentication of messages
US6703923B2 (en) * 2001-04-18 2004-03-09 Thomson Licensing S.A. Apparatus for providing security on a powerline-modem network
US7590684B2 (en) 2001-07-06 2009-09-15 Check Point Software Technologies, Inc. System providing methodology for access control with cooperative enforcement
JP2003085321A (ja) 2001-09-11 2003-03-20 Sony Corp コンテンツ利用権限管理システム、コンテンツ利用権限管理方法、および情報処理装置、並びにコンピュータ・プログラム
JP3826782B2 (ja) 2001-12-12 2006-09-27 ソニー株式会社 データ伝送システム、情報処理装置および方法、記録媒体、並びにプログラム
JP3931710B2 (ja) 2002-03-22 2007-06-20 ヤマハ株式会社 サーバ装置、通信端末装置、配信システム及び配信プログラム
US7321969B2 (en) 2002-04-26 2008-01-22 Entrust Limited Secure instant messaging system using instant messaging group policy certificates
DE60314871T2 (de) 2002-05-24 2008-03-13 Telefonaktiebolaget Lm Ericsson (Publ) Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters
US20060106836A1 (en) 2002-06-07 2006-05-18 Madoka Masugi Data processing system, data processing device, data processing method, and computer program
JP3791464B2 (ja) 2002-06-07 2006-06-28 ソニー株式会社 アクセス権限管理システム、中継サーバ、および方法、並びにコンピュータ・プログラム
US20040043756A1 (en) * 2002-09-03 2004-03-04 Tao Haukka Method and system for authentication in IP multimedia core network system (IMS)
US7458095B2 (en) * 2002-11-18 2008-11-25 Nokia Siemens Networks Oy Faster authentication with parallel message processing
US7506368B1 (en) * 2003-02-13 2009-03-17 Cisco Technology, Inc. Methods and apparatus for network communications via a transparent security proxy
US7421732B2 (en) * 2003-05-05 2008-09-02 Nokia Corporation System, apparatus, and method for providing generic internet protocol authentication
US7171555B1 (en) * 2003-05-29 2007-01-30 Cisco Technology, Inc. Method and apparatus for communicating credential information within a network device authentication conversation
WO2004112347A1 (en) * 2003-06-18 2004-12-23 Telefonaktiebolaget Lm Ericsson (Publ) Method, system and apparatus to support hierarchical mobile ip services
US20060264202A1 (en) 2003-07-11 2006-11-23 Joachim Hagmeier System and method for authenticating clients in a client-server environment
US7401217B2 (en) 2003-08-12 2008-07-15 Mitsubishi Electric Research Laboratories, Inc. Secure routing protocol for an ad hoc network using one-way/one-time hash functions
US7568098B2 (en) 2003-12-02 2009-07-28 Microsoft Corporation Systems and methods for enhancing security of communication over a public network
US20050154889A1 (en) * 2004-01-08 2005-07-14 International Business Machines Corporation Method and system for a flexible lightweight public-key-based mechanism for the GSS protocol
US7613923B2 (en) 2004-02-25 2009-11-03 Watchguard Technologies, Inc. Method and apparatus for controlling unsolicited messaging in real time messaging networks
US7467399B2 (en) * 2004-03-31 2008-12-16 International Business Machines Corporation Context-sensitive confidentiality within federated environments
US7437558B2 (en) 2004-06-01 2008-10-14 Cisco Technology, Inc. Method and system for verifying identification of an electronic mail message
US8340283B2 (en) 2004-06-30 2012-12-25 International Business Machines Corporation Method and system for a PKI-based delegation process
GB0416479D0 (en) * 2004-07-23 2004-08-25 Hewlett Packard Development Co Delegation protocol
CN100574185C (zh) * 2005-01-07 2009-12-23 华为技术有限公司 在ip多媒体业务子系统网络中保障媒体流安全性的方法
EP1681826A1 (en) 2005-01-12 2006-07-19 Abb Research Ltd. Method of authenticating multicast messages
US7774830B2 (en) 2005-03-14 2010-08-10 Microsoft Corporation Access control policy engine controlling access to resource based on any of multiple received types of security tokens
US20060294366A1 (en) * 2005-06-23 2006-12-28 International Business Machines Corp. Method and system for establishing a secure connection based on an attribute certificate having user credentials
US20060294383A1 (en) 2005-06-28 2006-12-28 Paula Austel Secure data communications in web services
US7596225B2 (en) * 2005-06-30 2009-09-29 Alcatl-Lucent Usa Inc. Method for refreshing a pairwise master key
US20070079382A1 (en) 2005-09-15 2007-04-05 Ufuk Celikkan Authorizing computer services
US7954139B1 (en) * 2005-11-30 2011-05-31 At&T Intellectual Property Ii, Lp Arrangements for efficient authentication of service request messages
WO2007063420A2 (en) * 2005-12-01 2007-06-07 Nokia Corporation Authentication in communications networks
CN101001245B (zh) 2006-01-10 2010-04-14 华为技术有限公司 一种边界网关协议中更新信息的验证方法
KR101009330B1 (ko) * 2006-01-24 2011-01-18 후아웨이 테크놀러지 컴퍼니 리미티드 모바일 네트워크를 기반으로 하는 엔드 투 엔드 통신에서의 인증을 위한 방법, 시스템 및 인증 센터
US20070220598A1 (en) * 2006-03-06 2007-09-20 Cisco Systems, Inc. Proactive credential distribution
US20090063851A1 (en) * 2006-03-20 2009-03-05 Nijdam Mark J Establishing communications
US8583929B2 (en) * 2006-05-26 2013-11-12 Alcatel Lucent Encryption method for secure packet transmission
EP2041910A4 (en) * 2006-07-06 2013-05-22 Apple Inc WIRELESS ACCESS POINT SECURITY FOR MULTIHOP NETWORKS
US7865717B2 (en) 2006-07-18 2011-01-04 Motorola, Inc. Method and apparatus for dynamic, seamless security in communication protocols
US7499547B2 (en) * 2006-09-07 2009-03-03 Motorola, Inc. Security authentication and key management within an infrastructure based wireless multi-hop network
US8578159B2 (en) * 2006-09-07 2013-11-05 Motorola Solutions, Inc. Method and apparatus for establishing security association between nodes of an AD HOC wireless network
JP4866802B2 (ja) * 2006-09-11 2012-02-01 Ｋｄｄｉ株式会社 セキュリティ最適化システムおよびセキュリティ最適化方法
US8555335B2 (en) 2006-11-01 2013-10-08 Microsoft Corporation Securing distributed application information delivery
US8418241B2 (en) * 2006-11-14 2013-04-09 Broadcom Corporation Method and system for traffic engineering in secured networks
US8539559B2 (en) * 2006-11-27 2013-09-17 Futurewei Technologies, Inc. System for using an authorization token to separate authentication and authorization services
US8082446B1 (en) 2006-11-30 2011-12-20 Media Sourcery, Inc. System and method for non-repudiation within a public key infrastructure
US9055107B2 (en) * 2006-12-01 2015-06-09 Microsoft Technology Licensing, Llc Authentication delegation based on re-verification of cryptographic evidence
JP4892011B2 (ja) 2007-02-07 2012-03-07 日本電信電話株式会社 クライアント装置、鍵装置、サービス提供装置、ユーザ認証システム、ユーザ認証方法、プログラム、記録媒体
US9319220B2 (en) * 2007-03-30 2016-04-19 Intel Corporation Method and apparatus for secure network enclaves
CA2587239A1 (en) 2007-05-02 2008-11-02 Kryptiva Inc. System and method for ad-hoc processing of cryptographically-encoded data
FR2916592B1 (fr) * 2007-05-25 2017-04-14 Groupe Des Ecoles De Telecommunications(Get)-Ecole Nat Superieure Des Telecommunications(Enst) Procede de securisation d'echange d'information,dispositif, et produit programme d'ordinateur correspondant
US8200959B2 (en) 2007-06-28 2012-06-12 Cisco Technology, Inc. Verifying cryptographic identity during media session initialization
US8667151B2 (en) * 2007-08-09 2014-03-04 Alcatel Lucent Bootstrapping method for setting up a security association
US8086843B2 (en) 2007-09-24 2011-12-27 International Business Machines Corporation Performing cryptographic provider failover
US20090099860A1 (en) 2007-10-15 2009-04-16 Sap Ag Composite Application Using Security Annotations
US20090138711A1 (en) 2007-11-21 2009-05-28 Dennis Heimbigner Sender Email Address Verification Using Reachback
US9178696B2 (en) * 2007-11-30 2015-11-03 Telefonaktiebolaget L M Ericsson (Publ) Key management for secure communication
US8516133B2 (en) * 2008-02-07 2013-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for mobile device credentialing
CA2621147C (en) 2008-02-15 2013-10-08 Connotech Experts-Conseils Inc. Method of bootstrapping an authenticated data session configuration
US7966652B2 (en) * 2008-04-07 2011-06-21 Safemashups Inc. Mashauth: using mashssl for efficient delegated authentication
US7945774B2 (en) * 2008-04-07 2011-05-17 Safemashups Inc. Efficient security for mashups
US8661252B2 (en) 2008-06-20 2014-02-25 Microsoft Corporation Secure network address provisioning
US8386767B2 (en) * 2008-08-15 2013-02-26 Telefonaktiebolaget L M Ericsson (Publ) Methods and systems for bootstrapping security key information using session initiation protocol
US9137138B2 (en) 2008-11-28 2015-09-15 Stephen W. NEVILLE Method and system of controlling spam
US8374352B2 (en) 2009-04-13 2013-02-12 The Hong Kong University Of Science And Technology Context-free protocol for enforcing data forwarding in wireless ad hoc networks
WO2011040847A1 (en) * 2009-10-01 2011-04-07 Telefonaktiebolaget L M Ericsson (Publ) Sending protected data in a communication network
DE102009051383A1 (de) * 2009-10-30 2011-05-12 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum sicheren Übertragen von Daten
US8881257B2 (en) * 2010-01-22 2014-11-04 Interdigital Patent Holdings, Inc. Method and apparatus for trusted federated identity management and data access authorization
TW201741925A (zh) * 2010-04-12 2017-12-01 內數位專利控股公司 啟洞程序中階段控制釋放
US8887246B2 (en) * 2010-06-22 2014-11-11 Telefonaktiebolaget L M Ericsson (Publ) Privacy preserving authorisation in pervasive environments
US8631466B2 (en) * 2010-08-03 2014-01-14 Interdigital Patent Holdings, Inc. Machine to-machine (M2M) call flow security
WO2012021662A2 (en) * 2010-08-10 2012-02-16 General Instrument Corporation System and method for cognizant transport layer security (ctls)
US20130227663A1 (en) * 2010-10-08 2013-08-29 Telefonica S.A. Method, a system and a network element for ims control layer authentication from external domains
KR101766681B1 (ko) * 2011-02-08 2017-08-09 삼성전자주식회사 통신시스템에서 단말의 프로파일을 제공하기 위한 시스템 및 방법
US8769288B2 (en) * 2011-04-22 2014-07-01 Alcatel Lucent Discovery of security associations
US8644510B2 (en) * 2011-05-11 2014-02-04 Alcatel Lucent Discovery of security associations for key management relying on public keys
US10044713B2 (en) * 2011-08-19 2018-08-07 Interdigital Patent Holdings, Inc. OpenID/local openID security
US9203613B2 (en) * 2011-09-29 2015-12-01 Amazon Technologies, Inc. Techniques for client constructed sessions
US9053332B2 (en) 2012-03-07 2015-06-09 Google Technology Holdings LLC Policy for secure packet transmission using required node paths and cryptographic signatures
WO2013165605A1 (en) * 2012-05-02 2013-11-07 Interdigital Patent Holdings, Inc. One round trip authentication using single sign-on systems
US9137740B2 (en) 2012-09-10 2015-09-15 Spectrum Bridge, Inc. System and method for providing network access to electronic devices using bandwidth provisioning
CN104620632B (zh) * 2012-09-12 2018-08-21 Lg 电子株式会社 用于在无线通信系统中请求有关特定资源的特定权利获得的方法和设备
CN102916811B (zh) * 2012-10-18 2015-04-15 中国科学院信息工程研究所 一种多元实体身份凭证信息存储方法
WO2014088340A1 (ko) * 2012-12-05 2014-06-12 엘지전자 주식회사 무선 통신 시스템에서 접근 권한 인증을 위한 방법 및 장치
CN103051726A (zh) * 2012-12-28 2013-04-17 杨涛 基于rsu的vanet安全信息聚合传输系统及方法
US9015482B2 (en) 2012-12-28 2015-04-21 Nok Nok Labs, Inc. System and method for efficiently enrolling, registering, and authenticating with multiple authentication devices
KR101723322B1 (ko) * 2013-01-24 2017-04-18 제트티이 (유에스에이) 인코포레이티드 기기간 서비스 계층과 전송 네트워크 간 통신
US9866391B1 (en) 2013-01-30 2018-01-09 Amazon Technologies, Inc. Permissions based communication
EP2961122B1 (en) * 2013-02-19 2021-08-11 LG Electronics Inc. Method for modifying m2m service setting and apparatus therefor
US9203832B2 (en) * 2013-03-12 2015-12-01 Cable Television Laboratories, Inc. DTCP certificate authentication over TLS protocol
FR3004046B1 (fr) * 2013-03-28 2015-04-17 Commissariat Energie Atomique Procede et dispositif pour former un reseau sans fil securise a faibles ressources
FR3004041B1 (fr) * 2013-03-28 2015-04-17 Commissariat Energie Atomique Procede et dispositif d'etablissement de cles de session
WO2014165747A1 (en) * 2013-04-05 2014-10-09 Interdigital Patent Holdings, Inc. Securing peer-to-peer and group communications
US9424421B2 (en) 2013-05-03 2016-08-23 Visa International Service Association Security engine for a secure operating environment
CN103297963B (zh) * 2013-05-10 2016-06-22 北京邮电大学 基于无证书的m2m隐私保护和密钥管理的方法和系统
WO2014200292A1 (ko) * 2013-06-12 2014-12-18 엘지전자 주식회사 M2m 시스템에서 위치 측정 방법 및 이를 위한 장치
EP3014803B1 (en) 2013-06-25 2019-09-25 Nokia Technologies Oy A method and apparatus for anonymous and trustworthy authentication in pervasive social networking
JP6013988B2 (ja) 2013-07-18 2016-10-25 日本電信電話株式会社 データ収集システム、データ収集方法、ゲートウェイ装置及びデータ集約プログラム
US9032213B2 (en) 2013-07-25 2015-05-12 Fujitsu Limited Data distribution path verification
EP3025525B1 (en) * 2013-07-25 2018-12-12 Convida Wireless, LLC End-to-end m2m service layer sessions
US9397990B1 (en) * 2013-11-08 2016-07-19 Google Inc. Methods and systems of generating and using authentication credentials for decentralized authorization in the cloud
EP2890073A1 (en) * 2013-12-31 2015-07-01 Gemalto SA System and method for securing machine-to-machine communications
US20160014674A1 (en) * 2014-07-10 2016-01-14 Lg Electronics Inc. Method for location based access control in wireless communication system and apparatus therefor
US9883320B2 (en) * 2014-07-21 2018-01-30 Lg Electronics Inc. Method for processing request message in wireless communication system and apparatus therefor
WO2016068548A1 (ko) * 2014-10-28 2016-05-06 엘지전자 주식회사 무선 통신 시스템에서 통지 메시지를 처리하기 위한 방법 및 이를 위한 장치
KR102001753B1 (ko) * 2015-03-16 2019-10-01 콘비다 와이어리스, 엘엘씨 공개 키잉 메커니즘들을 사용한 서비스 계층에서의 종단간 인증
US9923721B2 (en) 2015-06-22 2018-03-20 Intel IP Corporation Key agreement and authentication for wireless communication
CN107852405B (zh) * 2015-07-02 2021-02-02 康维达无线有限责任公司 用于服务层的内容安全性的装置
US11102122B2 (en) * 2015-08-04 2021-08-24 Convida Wireless, Llc Internet of things end-to-end service layer quality of service management

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102106135A (zh) * 2008-06-16 2011-06-22 艾利森电话股份有限公司 经由中间节点发送媒体数据
CN103392319A (zh) * 2010-12-30 2013-11-13 交互数字专利控股公司 针对通信切换场景的认证和安全信道设置
CN103460738A (zh) * 2011-03-23 2013-12-18 交互数字专利控股公司 用于使网络通信安全的系统和方法
US20140129838A1 (en) * 2012-11-02 2014-05-08 Young Jin Kim Method and apparatus for resilient end-to-end message protection for large-scale cyber-physical system communications

Also Published As

Publication number Publication date
EP3213488A1 (en) 2017-09-06
CN107005569B (zh) 2021-09-07
KR102021213B1 (ko) 2019-09-11
US10129031B2 (en) 2018-11-13
US20190123909A1 (en) 2019-04-25
US10601594B2 (en) 2020-03-24
CN113596828B (zh) 2024-08-16
JP2019146196A (ja) 2019-08-29
WO2016114842A1 (en) 2016-07-21
US20170012778A1 (en) 2017-01-12
JP2017539139A (ja) 2017-12-28
CN107005569A (zh) 2017-08-01
KR20170076773A (ko) 2017-07-04
JP6508688B2 (ja) 2019-05-08

Similar Documents

Publication Publication Date Title
CN107005569B (zh) 端对端服务层认证
US11240212B2 (en) Content security at service layer
US10880294B2 (en) End-to-end authentication at the service layer using public keying mechanisms
US11824643B2 (en) Security lifecycle management of devices in a communications network

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