申请/专利权人：康维达无线有限责任公司

申请日：2016-03-16

公开（公告）日：2020-11-17

公开（公告）号：CN107534658B

主分类号：H04L29/06(20060101)

分类号：H04L29/06(20060101);H04L9/32(20060101);H04L29/08(20060101);H04W4/70(20180101);H04W12/06(20090101);H04W84/18(20090101);G06F21/64(20130101)

优先权：["20150316 US 62/133,839"]

专利状态码：失效-未缴年费专利权终止

法律状态：2023.03.03#未缴年费专利权终止;2018.01.26#实质审查的生效;2018.01.02#公开

摘要：在机器对机器物联网环境中，使用预先提供的逐跳凭证、唯一生成的逐跳凭证、和或公钥证书，经由直接或委托中间协商，实现由多跳分开的设备的端到端认证，由此可以经由单跳通信发现远程资源和服务，并且然后可以使用适合于资源和终端设备的服务和能力的安全协议，建立与远程资源的安全通信，此后在没有产生逐跳转换的开销或风险的情况下直接实施通信。

主权项：1.一种用于端对端认证的装置，包括处理器、存储器和通信电路，所述装置经由其通信电路连接到通信网络，所述存储器中存储有计算机可执行指令，其特征在于，所述计算机可执行指令当由所述装置的所述处理器执行时，使所述装置：a.从消息发起者接收对于注册由所述消息发起者提供的服务的请求；b.注册服务类型，所述服务类型与由所述消息发起者提供的所述服务有关；c.基于所述服务类型确定安全性特征集合，所述安全性特征集合与所述服务类型或者由所述消息发起者提供的所述服务有关；d.注册所述安全性特征集合；e.注册所述消息发起者的公钥；f.从多跳传输接收者接收凭证请求；g.根据访问控制策略评估所述凭证请求；以及h.当所述访问控制策略允许通过所述多跳传输接收者访问注册的服务类型时，向所述多跳传输接收者提供包括所述消息发起者的所述公钥的对于所述凭证请求的响应。

全文数据：使用公钥机制在服务层的端对端认证[0001]相关申请的交叉引用[0002]本申请要求2015年3月16日提交的，题为“End-to-endAuthenticationattheServiceLayerUsingPublicKeyingMechanisms”的美国临时申请Νο·62133,839的优先权，其全部内容在此引入以供参考。背景技术[0003]机器对机器Μ2Μ和物联网（IoT网络部署可以支持在托管Μ2ΜΙοΤ应用和服务的诸如Μ2ΜΙοΤ服务器、网关和设备的节点上操作的Μ2ΜΙοΤ服务层，诸如oneM2M、ETSIΜ2Μ和01^〇^21。在例如：〇116]\121-了5-0001功能架构¥-1.6.1、〇116]\12145-0003安全解决方案¥-1.〇.1、传输层安全TLS协议版本1.2、IETF-RFC5246、数据报传输层安全DTLS版本1.2、IETF-RFC6347,和用于网际协议的安全架构（IPSec、IETF-RFC4301中描述这些类型的操作。发明内容[0004]描述了服务启用和安全配置（SESC方法。这涉及识别可由M2M网络中的实体使用的安全性特征、关联的属性和参数的正确集合，以便可以建立安全通信。这些步骤要求识别实体的能力和实体提供的服务，并确定安全性特征。例如，如果实体不提供“关键”服务，则可以避免昂贵的E2E认证过程。然而，如果由实体提供的服务或信息被认为是“关键的”，因此要求E2E认证，则可能要求关键服务涉及的任何消息来以E2E方式认证。在本文档中描述了作出此决定的机制。服务启用功能（SEF可以可选地指示仅要求E2E认证，从而避免昂贵的逐跳HbH安全连接。类似地，SEF可以可选地指示其也执行凭证注册表CR功能。SEF还可以可选地提供到可以从其请求凭证的CR的链接或指示其位置。[0005]描述了安全凭证请求注册过程SCRP。这涉及请求可以以动态方式用于E2E认证的公钥凭证。该过程还可以涉及将凭证登记到凭证注册表。还描述了服务层处的动态凭证注册请求即服务CRaaS，以及可以包括重新提供凭证的凭证的生命周期管理。[0006]描述了第三方凭证请求TPRC方法。这包括由实体请求第三方凭证的机制。假定已经评估了接入控制权限，可以为可以要求对消息发起者进行E2E认证的任何实体提供可以被用于E2E认证的E2E凭证。凭证请求可以通过隐式手段来执行，由此凭证和关联的参数可以用作资源的一部分。替选地，凭证请求可以通过显式手段来执行，由此可以从受信任的第三方TTP获取凭证。[0007]描述了端对端认证过程E2EAP。这包括执行E2E消息发起者的认证的机制以及以委托或未委托方式执行认证的能力。E2E认证可以涉及单向认证或双向E2E认证。例如，描述了用于创建可以被用来创建可用于执行E2E认证的元数据的“消息发起者信息”的机制。在委托模式下，实体将E2E认证机制卸载到信任的实体。在本公开中所述的机制适用于涉及认证的环境，并且更具体地适用于被认为受约束的实体（例如，I〇TM2M设备）的E2E认证。然而，该过程不限于仅IoT设备。其能被用在信任的实体可以确定适当的安全性特征、功能和凭证的情况下，以便除了使受约束的设备免于执行复杂的安全性功能之外，还可以整体上减轻系统中所涉及的消息收发开销。本文所述的机制也可以被用来以E2E方式提供服务层消息的机密性和完整性。[0008]提供该发明内容以采用简化的方式介绍在下文的具体实施方式中进一步描述的原理的选择。该发明内容不旨在标识所要求的主题的关键特征或必要特征，也不旨在用来限制所要求主题的范围。此外，所要求的主题不限于解决在本公开的任一部分中提到的任一或所有优点的局限。附图说明[0009]从结合附图以示例的方式给出的下述描述可获得更详细的理解，其中：[0010]图1示出实现为在网络协议栈中的各个层中的协议和服务的一部分的通信会话。[0011]图2示出示例公共服务功能公共服务实体CSE。[0012]图3示出逐跳安全关联的示例。[0013]图4示出示例M2M情形。[0014]图5示出不能认证消息的发起者的问题。[0015]图6示出IN-CSE恶意地创建较新消息并转发到注册员CSE的问题。[0016]图7示出端对端安全认证步骤的示例集合。[0017]图8示出示例服务启用和安全配置SESC请求响应消息收发。[0018]图9示出示例高级凭证请求过程。[0019]图10示出可以被提供给应用实体AE或CSE的密钥的示例JavaScript对象表示法JSON表示。[0020]图11示出示例第三方凭证请求TPCR处理流程。[0021]图12是示出用于创建数字签名的示例高级机制的流程图。[0022]图13示出委托实体DE的示例单向E2E认证过程。[0023]图14示出包括服务启用功能SEF和凭证注册表CR功能的示例安全公共服务功能CSE。[0024]图15示出向CSE注册的示例，其中，服务启用和安全配置SESC功能驻留在注册员CSERCSE处。[0025]图16示出由信任的第三方TTP提供逐跳凭证的示例。[0026]图17示出AE资源的示例结构。[0027]图18示出逐跳凭证提供之后的AE资源。[0028]图19示出AE从凭证注册表CR请求E2E公钥凭证的示例。[0029]图20示出用E2E公钥凭证更新AE资源的示例。[0030]图21示出托管CR功能的RCSE的示例。[0031]图22示出使用隐式手段，向第三方分发凭证的示例。[0032]图23示出通过使用直接模式的AE的传感器消息的E2E认证的示例。[0033]图24示出使用委托模式的E2E认证的示例。[0034]图25示出在直接模式在由致动器的系统或应用的E2E认证的示例。[0035]图26示出由RCSE代表致动器的系统或应用的E2E认证的示例。[0036]图27示出将E2E数字签名添加到oneM2M消息的示例。[0037]图28示出多个E2E认证的示例。[0038]图29是其中可实现一个或多个公开的实施例的示例机器对机器M2M、物联网IoT或万物网WoT通信系统的系统图。[0039]图30是在图29中所示的M2MIoTWoT通信系统内可使用的示例架构的系统图。[0040]图31是在图29和30中所示的通信系统内可使用的诸如M2MIoTWoT设备、网关或服务器的示例通信网络节点的系统图。[0041]图32是其中可实施图29和30的通信系统的节点的示例计算系统的框图。具体实施方式[0042]本文档描述了在具有不同能力（例如，不同的处理能力，存储器大小等并且没有先前的安全关联的实体之间执行端对端认证的机制。描述安全性提供和配置过程，以便可以向实体提供适当的基于公钥的安全性凭证、功能、作用域和参数。还开发了向其他实体请求和分发安全性凭证的机制，然后其他实体能使用凭证在服务层执行端对端认证。[0043]描述了服务启用和安全配置（SESC方法。这涉及到识别可由M2M网络中的实体使用的安全性特征、关联的属性和参数的正确集合，以便可以建立安全通信。这些步骤要求识别实体的能力和实体提供的服务，并确定安全性特征。例如，如果实体不提供“关键”服务，则可以避免昂贵的E2E认证过程。然而，如果由实体提供的服务或信息被认为是“关键的”，因此要求E2E认证，则可能要求关键业务所涉及的任何消息收发来以E2E方式认证。本文档描述了作出此决定的机制。[0044]作为SESC过程的一部分，SEF可以可选地指示仅要求E2E认证，从而避免昂贵的逐跳HbH安全连接。类似地，SEF也可选地指示它还执行CR功能。此外，SEF可选地提供到请求凭证的CR的链接或指示其位置。[0045]描述了安全凭证请求注册过程SCRP。这涉及以动态方式请求可用于E2E认证的公钥凭证。该过程还涉及向凭证注册表注册凭证。描述了在服务层的动态凭证注册请求即服务CRaaS。描述了凭证的生命周期管理，其中可以包括重新提供凭证。[0046]描述了第三方凭证请求TPRC过程。这包括实体请求第三方凭证的机制。假定已经评估了接入控制权限，可以为可以要求对消息发起者进行E2E认证的任何实体提供可用于E2E认证的E2E凭证。凭证请求可以通过隐式手段来执行，由此凭证和关联的参数可以用作资源的一部分。相反，凭证请求可以通过显式手段来执行，由此凭证可以从TTP获取。[0047]描述了端对端认证过程E2EAP。描述了用于执行E2E消息发起者身份认证的机制。说明了在委托或非委托模式中执行认证的能力。E2E认证可以涉及单向认证或双向E2E认证。描述了用于创建可用于创建随后被用于执行E2E认证的元数据的“消息发起者信息”的机制。在委托模式下，实体将E2E认证机制卸载到信任的实体。[0048]本文所述的机制适用于涉及认证且更具体地涉及被认为受约束的实体例如，某些I〇TM2M设备）的E2E认证的环境。然而，应当理解到，本文所述的系统和方法是不限于仅IoT设备。只要信任的实体可以确定适当的安全性特征、功能和凭证，则能使用这些系统和方法，以便除了使受约束的设备免于执行复杂的安全性功能外，还能整体上减轻系统中所涉及的消息收发开销。尽管本文中的说明性示例通常涉及消息发起者的E2E认证，但本文所述的机制可以被用于以E2E方式提供服务层消息的机密性和完整性。[0049]通信会话[0050]典型的通信会话通常涉及在两个或更多个通信实体例如，设备、应用等之间的信息的持续交互交换。然而，通过当前的RESTful方法，不存在真正持久的连接，但存在按需请求响应消息。在某个时间点建立通信会话，并且基于各种情况例如在会话超时后或当其中一个实体决定终止会话时在稍后的时间点拆散。通信会话通常涉及实体之间交换多个消息，并且通常是有状态的，意味着至少一个通信实体需要保存关于会话历史的信息，以能够维持通信会话例如，诸如凭证，标识符等的安全上下文）。通信会话可以被实现为网络协议栈中各个层的协议和服务的一部分。作为示例，图1示出在传输协议层、应用协议层、应用服务层的网络节点之间和应用之间建立的通信会话。[0051]应用服务层[0052]M2M服务层是专门针对为M2M类型设备和应用提供增值服务的一种应用服务层的示例。例如，M2M服务层能支持对由服务层提供的M2M中心能力的集合提供应用和设备访问的应用编程接口（API。若干示例包括安全性、计费、数据管理、设备管理、发现、配置和连接管理。图1图示由〇neM2M规范指定的公共服务功能CSF。[0053]经由使用由M2M服务层定义的消息格式、资源结构和资源表示的API，使这些功能能力可用于应用。M2M网络技术标准化的增长趋势一直是M2M服务层的标准化。示例包括oneM2MTS-0001功能架构V-1.6.1。[0054]M2M服务层会话[0055]M2M服务层会话是在M2M服务层实例与M2M应用或另一M2M服务层实例之间建立的通信会话。[0056]M2M服务层会话能由与连接性、安全性、调度、数据、上下文等相关的M2M服务层状态组成。该状态能由M2M服务层、M2M应用或两者保持。[0057]能在一个或多个底层的下层通信会话的顶部分层M2M服务层会话。这样做，能在不同会话之间共享和利用会话状态例如，安全性凭证、拥塞信息等）。此外，M2M服务层会话能支持关于下层会话的持久性，使得M2M服务层会话能持续并且被保持，与下层会话建立和拆除无关。[0058]能在其顶部分层M2M服务层会话的下层会话的一些示例包括但不限于可以使用诸如传输层安全性（用于TCP的TLS或数据报传输层安全性用于UDP的DTLS的协议来保护的应用协议层会话例如，HTTP或CoAP和传输协议层会话例如，TCP和或UDP。[0059]oneM2M服务层安全性[0060]目前，当oneM2M端点以安全的方式彼此通信时，节点和中间节点以逐跳方式彼此建立安全关联。每一跳AE〈-CSE或CSE〈-CSE具有单独的安全关联并且彼此独立。可以借助对称密钥、使用证书或可由直接过程或借助基础设施执行的引导过程来建立逐跳安全关联。此外，〇neM2M-TS_0003安全解决方案-V-1.0.1规定：“在服务层级，安全关联建立导致保护在相邻AECSE之间交换的消息的TLS或DTLS会话，即逐跳”。[0061]图3突出强调使用对涉及的两个通信实体唯一且机密的凭证借助DTLS安全关联的实体之间的逐跳HbH安全关联。可以看出，AEl和RCSEl基于由两个实体AE1、RCSE1共享的HbH凭证Hl创建安全⑶TLS连接。类似地，RCSEl和IN-CSEl已经使用H2凭证建立安全⑶TLS连接，H3被用于创建IN-CSE和RCSE2之间的⑶TLS连接，类似地，H4被用于创建AE2和RCSE2之间的安全连接。[0062]如果RCSEl希望向AE2传送信息，则首先通过RCSEl和IN-CSE之间的⑶TLS连接发送该信息。然后在服务层处理该信息，接着通过IN-CSE和RCSE2之间的较新⑶TLS通道重新打包和发送。RCSE2处理该消息，然后通过RCSE2和AE2之间的不同安全通道重新通道传送消息。如所看到的，任何两个HbH实体之间的通信受⑶TLS保护，因此破坏实体之间传输的消息的机密性或完整性极其困难，因为它们受到⑶TLS连接的保护。因此，破坏传输中的消息极其困难，但在经由安全连接转发到下一跳之前，在处理该消息的节点处，消息不受保护。[0063]表1-缩写[0066]IoT和安全性术语[0067]认证者:执行认证过程以便认证另一实体的实体，使得可以向该实体提供对应用、服务、资源或网络的访问。[0068]被认证者:请求访问资源、应用、服务或网络并在认证者认证过程中的实体。[0069]认证:建立与实体相关联的身份的置信度的过程。[0070]机密性:确保仅被授权实体能够查看数据的过程。[0071]实体:应用、应用子集、服务启用功能、设备例如、传感器设备）。[0072]端对端认证:为实体提供验证作为消息的一部分提供的另一个实体的身份的能力。通信实体被假定为多跳远。认证可以是双向或单向的。[0073]完整性:消息或系统未被未授权的实体变更的置信度或建立置信度的过程。[0074]IoT:将唯一可识别的对象及其虚拟表示连接到互联网。[0075]M2M服务层:通过应用编程接口（API和底层联网接口的集合，支持用于M2M应用和设备的增值服务的软件中间件层。[0076]M2M服务层跳:两个M2M服务层之间或M2M服务层与M2M应用之间的M2M服务层通信会话。[0077]M2M服务层会话:通常本质上是有状态的两个或更多个通信实体之间建立的消息交换。[0078]M2M服务层会话端点:可以是M2M服务层会话通信的源或汇点的逻辑实体。[0079]M2M服务层会话管理器:为M2M服务层会话管理提供服务的逻辑实体。[0080]Nonce:可以与会话相关联，并且其有效性可以与会话时间分量相关联的随机值。[0081]示例解决的挑战[0082]服务提供商使用服务层功能，利用传感器、应用实体和致动器来为客户提供诸如远程消防控制的服务。其中远程M2M系统可被用于检测、动作两者以及用于缓解、并且可能具有与我们在此描述的安全性要求相似的安全性要求的各种用例（盗窃检测、监控工业系统和净化等）。在图4中图示示例情形。传感器1-4经由服务层消息收发提供可以经由中间节点传送到应用的传感器数据。基于传感器数据的应用又反过来可以触发致动器执行一些动作。[0083]—种用例，其中家庭配备有烟雾检测传感器，其被用于触发火灾检测和扑灭服务公司的警报。在公司的系统处理传感器信息，并且可以基于该警报，推断烟是由于烹饪、有人吸烟、还是不良烟雾传感器。该系统还使用家庭或邻居家等中的其他传感器以便确定是否真的是火灾，此外，还可以使用其他传感器以便确定火灾是是A级火灾还是其他类型的火灾。如果是电气火灾，则不得接通喷水器系统。然后，系统可以在控制喷水系统的致动器被接通之前，触发控制电力断开的致动器。或者在工业环境中，可以使用某些化学物质，还可以基于人宠物是否困在家建筑物内，确定使用的方法。[0084]从安全的视角，更准确地说从认证的视角一一这是本文档的重点，系统应用）必须确保实际上是由实体例如烟雾报警器触发烟雾报警器的指示，该系统与该实体具有信任关系，并且能够以高确信度验证该消息的确源于该特定传感器。从致动器的视角，致动器需要知道接通喷水器的信息源自与其具有信任关系的系统应用），这意味着喷水器系统能够认证该系统应用）。[0085]目前的oneM2M规范仅提供逐跳安全机制。由烟雾传感器使用oneM2M消息收发发送的烟雾报警器不能被系统应用认证为源自具有高确信度的传感器。在服务层从传感器以逐跳方式将消息传送到该系统的实体可能能够改变消息类型。当实际上是“C级火灾”时，中间实体有可能改变消息以指示火灾类型是“A级火灾”（例如由于燃烧纸的通常火灾）。该实体可能是恶意的，但在一些情况下会具有一些错误代码，因此没有适当地发送消息。如果从系统应用到致动器的消息被中间实体修改，则可能产生灾难性的后果。[0086]oneM2MTS-0003安全解决方案V-1.0.1仅提供逐跳认证，因此远程主机未显式认证请求在远程托管服务层资源上执行创建检索更新删除通知操作的实体。远程主机可以是托管资源的实体或者创建资源的实体。此外，希望认证原始消息发起者的实体无法以高确信度执行认证。如前所述，破坏在任何两个HbH实体之间传送的消息的机密性或完整性是极其困难的，然而，这不能阻止受损实体将假冒信息发送到另一个所谓“信任的”实体，一种中间人攻击，但更准确地说，是假冒攻击。由于缺乏这种验证能力，终端实体无法验证该消息是源于正确的实体。这种损害可能是由恶意或非恶意机制例如，坏代码、配置问题等）引起的。[0087]图5示出实体AEl创建在RCSEl处托管的资源并且另一实体AE2想要订阅该资源的情形。AE2发送订阅资源的请求，但是，RCSEl不知道订阅该资源的实际请求实际上是否源自AE2。从AE2到其下一跳（例如，IN-CSE以及从IN-CSE到RCSE1可以使用HbH机制保护订阅的消息，然而，由于仅在每一跳执行HbH认证，RCSEl可能不能验证IN-CSE或任何其他实体是否已经创建了自己的消息以及IN-CSE是否伪装成AE2。类似地，当RCSEl向AE2发送“通知”消息时，AE2不能以高确信度验证“通知”消息实际来自RCSEl。[0088]在图6中示出实体AEl，其执行用于更新向其注册员CSERCSEl注册的资源的操作。RCSEl向可能已订阅与AEl相关联的资源的实体发送通知消息。该通知可以经由IN-CSE，以逐跳方式从RCSEl转发到RCSE2。在此假定IN-CSE可能已经被恶意或非恶意实体损害，因此IN-CSE不是转发指示“更新”的通知，而是发送“删除”通知。损害可能涉及利用系统上存在的漏洞和或引起窃取HbH凭证和或对在IN-CSE上运行的代码的未经授权的更改，和或修改配置参数等。在第三跳，在IN-CSE在服务层进行处理之后，由于使用逐跳安全关联来保护消息并且经由安全DTLS连接传输，因此RCSE2将一直信任该消息。因此，即使源自受损的实体的消息也会被信任，因为它在安全通道内传输。此外，IN-CSE能够自行创建许多消息，并且假冒AE或甚至RCSE1。由于托管资源或负责创建资源或负责基于对资源的更新执行动作的实体只能认证紧邻它的跳，因此不能通过高确信度认证源自远离该实体1跳以上的任何消息。[0089]托管资源的实体不能完全认证正尝试对资源执行操作的实体，因为目标实体仅能够认证远离它一跳的实体。因此，可能不容易执行访问控制，因为终端实体不能够以高确信度验证谁实际发起消息。从终端实体的视角，由于缺少E2E认证机制，只有转发器被认证。[0090]因为逐跳机制，任何中间实体IN-CSE能够代表其他中间实体假冒消息。[0091]由于将使用⑶TLS保护逐跳机制，所以在每一跳处将必须建立DTLS会话，在每一跳处的完整性保护和认证以及在每一跳处的可能的加密和解密可以涉及在资源受限的中间节点上的大量安全相关开销例如，消息收发开销以及加密操作开销）。[0092]为了使实体能够认证可能超过一跳远的另一个实体，将要求为被称为认证者的认证实体提供给与被认证者将被认证的实体相关联的凭证。[0093]参考图7,如果可以是应用的实体N认证者）想要认证来自可以是传感器的实体A被认证者）的消息，则必须为实体N提供给实体A的公钥凭证。然而，分发凭证还不足，还需要提供关于将如何从加密过程使用凭证的信息，更准确地说，将如何执行消息认证的作用域。作用域可以定义消息头部或消息头部的子集，或消息的部分，或甚至将被用来创建认证标签的整个消息本身，以及密钥大小、数字签名的长度、是否必须使用随机值等。此外，考虑到从资源和计算角度看，一些如果不是全部实体可能受限，还必须有机制来选择和提供适合于与该实体例如，被认证者）一起使用的适当的公钥凭证和关联的作用域。必须设置被认证者凭证到认证者的凭证分配，并且必须确保凭证和作用域也适用于认证者。如果从计算角度来看适合的正确类型的凭证不可获得，则可以执行备用认证机制，其中，将E2E认证委托给可能具有更高计算资源的另一实体，或者替选地，可以导出适用于认证者和被认证者两者的较新的凭证。除了认证者和被认证者之外，还要求其他功能，诸如服务启用功能SEF和凭证注册表CR，以便执行E2E认证过程。[0094]SEF的作用是为实体提供用于安全的正确的策略集、将被启用的安全性特征、待生成提供的凭证的类型、可以被使用的密码算法和协议的类型以及和其他补充配置参数和作用域，以启用安全操作。SEF基于实体提供的服务类型来确定正确的安全性特征集，且因此必须了解实体的服务能力。此外，SEF在确定正确的安全性特征集时可以考虑设备能力例如，电池、计算和存储器）。在某些实施例中，SEF可以提供机制以便通过可选地与设备管理服务器交互来为实体提供用于启用安全功能的正确的应用包集。[0095]CR可以作为另一个实体的一部分驻留在同一M2MSP网络内，并且CR的主要作用是为实体提供适当的凭证和关于可以如何使用凭证的上下文以及作用域。SEF和CR功能可以被实现为驻留在作为M2M服务提供商（SP网络的一部分的不同实体上的功能，或者可以驻留在网络中的单个实体上。替选地，CR可选地连接到可以属于并驻留在M2MSP网络之外的信任的第三方实体上的另一个CR或证书机构CAXR的作用是提供与本地或全局标识相关联的正确的凭证集。[0096]在替代实施例中，还可以存在可以代表实体认证者:实体N执行认证的委托实体DE。在此简要描述在基于公钥凭证在服务层处启用E2E认证中可以包含的各个步骤的高级描述。[0097]端对端认证可以需要如图7所示的以下步骤。[0098]步骤1服务启用和安全配置SESC:在该步骤，实体A与服务启用功能（SEF建立关联。SEF可能需要了解由实体A提供的服务类型，因此选择适合于实体A的安全性特征。此外，SEF在确定正确安全性特征集中可以考虑设备能力（例如，电池、计算和存储器）。在此假设实体N已经预先通过其自己的SEF执行了SESC过程。SESC过程的一个主要目标是在SEF处注册由实体A请求或提供的服务类型。此外，还由SEF识别实体A要求或请求的安全需求和特征。SEF可以由例如M2M服务提供商或由实体A的制造商或由应用提供商设备管理器DM托管。在某些情况下，如果已经为实体预先提供了适合的安全性特征和功能以及管理特征功能的使用的关联的策略，那么可以跳过SESC过程。已经提供的安全性特征和功能可以不限于仅端对端安全性特征。在这种情况下，只执行步骤2-4。[0099]步骤2是安全性凭证注册请求过程SCRP。基于作为步骤1的一部分已被识别的安全性要求和特征，或者在已经预先提供安全性特征的情况下，实体A注册其公钥凭证，或由CR由适合的公钥凭证提供。注册的凭证是可应用于E2E认证的凭证。在注册凭证的情况下，其可以是原始公钥或可以具有关联的公钥证书例如，X.509的公钥。当CR发布证书时，则在某些情况下，CR可以使用其他网络实体例如，CA以便发布可能全局可接受的公钥证书。发布的凭证可以是证书，或者该过程可以仅包括在本地CR内或向与实体A可以具有信任关系的外部CA注册原始公钥凭证。信任关系也可以是基于SP与CRCA的信任关系的可传递信任关系。实体A可以使用发布给实体A的原始公钥凭证来基于数字签名，担保源认证更合适的消息源认证和不可否认性。可以设想到也可以使用SEF来促进步骤2。[0100]步骤3是第三方凭证请求过程TPCRP:向授权实体分发凭证包括第三方实体执行凭证请求或隐式凭证提供过程。可以基于可以以访问控制列表、基于属性的访问控制、基于角色的访问控制或动态授权机制为基础的访问控制策略，确定被授权接收实体的E2E凭证的实体的确定。例如实体N的实体也可以被提供由实体A注册或者被提供给实体A的公共凭证，以便可以在实体N和实体A之间建立安全关联，使得实体N能够以安全方式访问由实体A提供的服务，或反之亦然。实体N可以将公钥凭证用于认证源自实体A的消息。[0101]步骤4a是端对端认证过程E2EAP:在SESC、SCRP和TPCRP步骤后，实体N在该步骤中，基于在TPCRP期间，由实体N获得或提供给实体N的凭证，执行实体A的消息的E2E认证。[0102]步骤4b是使用委托模式的E2EAP:在替代方案中，实体N可以将认证过程委托给信任的第三实体例如，DE，以便代表它认证源自实体A的消息。[0103]服务启用和安全配置SESC过程[0104]在该过程期间，SEF确定适合于由实体提供或请求的服务和资源的适当的安全性要求和特征。安全性要求和特征可以使用一些推断过程确定，或由实体明确提供，或由可能正建立该系统的管理员配置。实体可以是认证者或被认证者，并且基于角色，可以确定适当的安全性特征。可以使用由实体提供的信息，诸如提供的设备类型能力和服务类型资源，以确定对安全性要求的推断。设备类型能力可以包括:处理功率、存储器、功耗、和或使用的无线电技术例如，带宽限制）。所提供的服务类型提供可以与安全性要求和安全性评级有关，并且包括:数据的完整性例如，高）、消息发起者认证例如，高）、不可否认性例如，高）、和或机密性例如，低）。实体可以以安全的方式向SEF提供安全性要求和评级，以及设备能力和服务类型。[0105]图8示出SESC请求响应消息收发的示例调用流。在消息1中，实体A请求使用SEF发起的SESC进程。作为消息的一部分，实体A提供其设备类型、唯一设备IDDID或能力或两者，以及可选的安全能力，并且还可以提供实体提供的服务应用的列表。[0106]在步骤2中，SEF在接收到请求后，基于其能力（例如，设备、安全性确定可能适合于实体A的安全性特征属性和关联的参数的列表。然后，基于实体A提供的服务应用类型，SEF可以选择安全性特征和关联的的属性和参数的窄列表。此外，还可以由SEF确定关于如何使用特征的策略、与属性相关联的寿命等。替选地，SEF可以创建可由实体A使用的特征的优先级列表。[0107]消息3是来自SEF的响应，其包括安全性特征以及关联的属性和参数以及策略。SEF还可以指示以下标志和或数据：回避HbH安全性例如，仅使用E2E安全性或使用HbH和E2E两者或仅使用HbH，SEF是否也执行CR功能，以及CR的位置或URI。[0108]在步骤4中，实体A可以可选地拒绝安全性策略和或属性以及关联的参数。[0109]在消息5中，实体A可以进入安全性属性协商过程，直到同意属性和相应参数为止可选步骤）。协商可以基于在消息3中获得的信息或与消息3中获得的信息无关。[0110]选择适合的安全性特征和关联的属性参数可以主要基于设备的能力（例如，设备、安全性），其次基于由实体提供的服务类型。例如，一种仅提供要求“低”安全性功能的服务、所选择的算法和密钥大小的低功耗、低内存设备可以是通过选择计算上不太密集的操作，使用低内存占用和不耗尽电池资源的设备。例如，对具有有限能力的实体，所选择的数字签名可以是具有2048位密钥的256字节，而对具有更多处理和存储器并且要求更高确保消息认证的实体提供可以与SHA-256机制更安全的算法一起使用的4096位密钥。[0111]替选地，实体可以提供明确的安全性要求的列表，并将其发送到SEF以供批准和配置。替选地，如果使用适当的安全性属性和参数预先配置实体，则可以跳过SESC过程。表2是安全性要求的示例列表：[0112]表2-示例安全性参数[0113][0114]替选地，终端实体——实体N——可能能够请求M2MSP或更具体地说，SEF包括用于源自实体A的消息的E2E凭证。[0115]在SESC过程结束时，SEF具有实体的完整的简档和能力。了解实体的能力，有助于SEF确定必须实施以保护实体的运作的适合的安全措施。SEF维护实体的能力的表。表3是在SEF处维护的类型的示例。[0116]表3:在SEF处和每一实体处维护的用于每一实体例如实体A和B的支持的安全性特征和功能[0117][0118]表3示出已经被分配待使用的安全性特征类型和凭证类型的实体实体A和B的示例列表。对每一安全性特征，可以存在关联的值参数，其可以指示待使用的协议算法，关联的密钥凭证大小和杂项信息。由于指定实体B设置更强的加密算法协议，实体B可以提供更关键的消息收发和或信息，并且可能具有更多的计算资源。实体B还具有使用E2E手段认证的能力。[0119]SEF还可以向实体提供相同的服务和指示，诸如：SEF是否执行CR功能的指示;如果SEF不提供CR功能，CR的位置或URI;是否避免HbH安全性以节省资源并且仅使用E2E认证的指示。[0120]委托VS直接安全机制[0121]基于公钥的认证机制可能导致更高的计算成本，因此可能不适合于具有较低计算资源存储器，处理）的某些设备。在这些情况下，可以将认证或认证的验证委托给信任的实体例如，DE。[0122]对要求有关实体或资源的真实性的高确信度的系统，可以避免委托，而是使用“直接”机制。在直接机制中，为实体提供公钥凭证，该凭证可由该实体使用来创建数字签名或验证数字签名。如果实体能够自行执行E2E认证和其他安全操作，则实体可以选择在无需委托的情况下自行执行直接认证。SEF可以基于实体提供或使用的设备能力或服务要求（例如，减少信令或其他操作开销来自行选择代表实体的委托的项。也可以采用混合方法。这是当委托安全性功能的一部分，而直接执行其他安全性功能。该实体可能可以使用终端实体执行加密解密，而由DE代表它执行端对端的认证例如，SEF，或反之亦然）。[0123]安全性凭证请求注册程序SCRP[0124]SCRP过程可以涉及由实体或由SEF代表该实体发起的安全性凭证请求过程。基于由该实体提供或请求的能力和或服务类型，从优选地在信任的第三方上托管的凭证注册表CR请求适合的安全性凭证、以及附加地其他配置参数。强烈建议在处理SCRP请求之前，执行实体和CR之间的认证，其中实体可能不具有任何凭证，，并且如果实体和CR属于同一信任的域的某些情况下，则认证是可选的。替选地，CR功能可以被托管在SEF上，然而，从可扩展性的视角，可以由诸如TTP的不同实体执行CR功能。CR可以生成公钥凭证，并提供可以如何使用凭证的作用域，以及待使用的推荐的算法等。然后，CR直接或可选地经由SEF将生成的凭证转发到实体。由CR生成的凭证可以是例如公钥证书（例如，X.509证书）或原始公钥没有证书）。[0125]图9示出SCRP过程，其中，实体A通过CRCA请求安全性凭证。在步骤0中，可以经由实体A和CRCA之间的消息收发来进行双向认证。在某些情况下，认证是可选的，特别是在实体A不具有任何凭证和或如果CRCA位于同一安全域内的情况下。在所有其他情形中，认证步骤可以是强制的。无论是否发生认证，均可以建立保护完整性和机密性的安全连接（例如，使用Diffie-HelIman机制）。[0126]在消息1中，实体A请求具有本地作用域的证书，并且通过在步骤1中建立的安全通道进行请求。凭证的类型和作用域可以基于先前已经执行的SESC过程。替选地，实体A可以请求原始公钥，而不需要证书。[0127]在步骤2中，CR处理该请求并生成公钥私钥对。如果请求是对本地作用域，则CR可以创建被指定到实体A的标识的证书，以及公钥，并且使用CR的私钥签名证书。如果作用域是全局的，则CR可以将公钥发送给CA，并请求发布证书，其中CA生成的证书、签名证书并且将其发送给CR。假设CA比CR具有更全局的作用域。[0128]在消息3中，CR以安全的方式将证书以及私钥发送到实体A。[0129]私钥以安全的方式被提供给实体，并且可以使用另一信道。可以设想某些格式被用于发布凭证。公钥加密标准PKCS协议可以被用于请求和配置过程。替选地，可以使用例如JSONWeb密钥JWK结构，将公钥凭证从CR传送到实体。实体可以请求将以之分发凭证的格式，或者可以在凭证由CR提供给实体前使用SCRP请求响应消息来协商。[0130]替选地，在安全性凭证注册过程中，实体可以生成凭证（公钥私钥对），然后请求将凭证注册到CR。作为注册过程的结果，与实体相关联的私钥仍然在实体上，然而，公钥由实体发送以便使用公钥加密标准例如，PKCS向CR注册。应确保私钥以安全的方式被存储例如，存储在实体上的的安全要素:SIMUICCTEE内）。此外，与实体相关联的关联的唯一标识被包括为凭证请求的一部分。注册过程可以涉及多个往返消息。在过程结束时，生成证书并将其提供给实体，或原始公钥被注册在注册表中并且与实体A相关联的唯一ID相关联。[0131]表4:与每一实体上下文相关联的安全性凭证[0132][0133]实体例如，应用或设备或服务器可以请求一个或多个凭证或者向CR注册一个或多个凭证。实体可以将凭证用于各种上下文。实体可以基于旨在如何使用凭证来定义上下文。上下文在实体内可能是唯一的，并且当与实体相关联时，其在CR域内必须是唯一的。因此，没有两个上下文能够具有相同的标识并且因此具有相同的公钥。当实体向CR注册其凭证时，CR必须确保实体内的上下文是唯一可识别的，并且如果在CR域内存在唯一可识别的实体，那么公钥凭证是唯一的，并且可以成功地向CR注册。[0134]在实体请求凭证的情况下，可以向请求实体提供实体ID例如，URI、上下文ID、关联的密钥以及其他关联的参数和“作用域”。“作用域”可以提供有关加密过程的类型的详细信息。作用域可以包括正使用的算法的类型、可以使用的参数、被用于推导DSMAC的“头部”信息（消息原始信息详情）、标签信息例如，“GBA标签”）、关于是否必须使用新鲜度信息的信息等。作用域还可以包括可以认证何种类型的消息。例如，“通知”消息可以被认为对于应用是非关键的，并且可以选择不向所有通知消息提供认证标签，而可以为所有“更新”消息提供认证标签。SEF可以能够基于由实体A提供的服务的能力和类型来定制E2E认证的作用域。替选地，可以由实体向CR发送包含实体ID、以及可选地上下文ID的请求。认证参数可以指示当实体创建认证标签例如，数字签名）时，可以包括为安全过程的一部分的安全信息例如，认证过程）。所建立的每个安全上下文都有有效生命期，在该有效生命期后，可以更新上下文或创建一个新的上下文。[0135]在图10中示出使用JavaScript对象表示法JSON提供给实体2的密钥的示例表不。[0136]第三方凭证要求TPCR过程[0137]在该步骤中，执行另一个实体例如，实体A或实体B的端对端认证所需的实体N可以请求证书或公开密钥材料、与密钥关联的作用域、可用于演示消息认证的参数例如数字签名）、和其他信息，使得可以执行E2E认证。请求实体N可以与CR双向认证，并且在实体A的公钥凭证证书或原始公钥被发布到实体N前，可选地执行实体N的授权。在某些情况下，由于凭证是公共凭证，因此跳过实体N的认证。除了由CR认证实体N外，CR还可以检查以验证是否已经授权实体N来获得与实体A相关联的凭证。如果成功地认证实体N并且被认为被授权，则为实体N提供实体A的凭证、上下文IDURI、端口#、关联的密钥、作用域和关联的参数。[0138]图11图示描绘TPCR过程的调用流。在消息0中，CR向实体通告凭证请求服务。[0139]在步骤1中，实体N和CR执行双向认证。如果实体N和CR之间存在信任关系，则此步骤是可选的。[0140]在消息2中，实体N通过包括实体A的ID例如，实体A的URI来发送请求实体A的凭证的TPCR，以便获得实体A的E2E公钥凭证、参数、作用域等。[0141]在步骤3中，CR可以执行可选的访问控制检查，以查看实体N是否确实被授权以获得实体A的公共凭证。[0142]在消息4中，CR向实体N发送实体A的公钥凭证例如，证书、原始公钥和关联的作用域以及所需的参数。[0143]在实体N处，可以维持有关在TPCR过程完成后想要创建和维持安全关联的实体例如，实体A的下述参数：[0144]表5:将与每一实体一起使用的认证机制、作用域和参数[0145][0146]在表5中，为了使实体N对实体A执行E2E认证，可以向其提供:实体ID、上下文ID、认证类型、端口号、认证协议、凭证、协议、有效期和各种关联的参数。[0147]实体ID信息可以指代作为应用、设备、服务器软件程序等的实体。使用资源标识符，在服务提供商域内唯一可识别的任何东西可被给予实体ID。[0148]上下文ID信息可以被用来标识其中可以使用凭证的实体内的上下文。可以定义上下文，但不限于签名操作例如，计算数字签名或加密操作或任何其他密码操作。[0149]认证信息的类型确定其上可以执行认证的层。这些包括可以在服务、会话、网络、MAC层执行的认证。对本公开对服务和会话层的认证机制感兴趣；[0150]在会话层E2E认证的情况下，可以可选地提供端口号。[0151]认证协议信息可以指示其中可以使用凭证的协议的选择。这可以是可选的。例如，对具有有限计算或存储器资源的实体，公钥凭证不能被用于加密目的。[0152]凭证信息可以包括类型（例如，E2E、RSA以及实际凭证例如公钥或整个证书）[0153]协议信息可以是可以或必须使用的特定协议，诸如TLS、DTLS、IPSec或ΕΑΡ。协议信息还可以包括关于可以使用的验证类型的信息，例如使用数字签名、MAC或JWS。[0154]有效性信息可以与每一凭证有关。例如，每个凭证可以与由其有效的天数例如，秒分天等或凭证到期的日期表示的生命期相关联。[0155]参数可以包括可被用于提供密钥占有消息认证的证明的值。其中仍可以使用逐跳保护机制的服务层处的E2E认证可以另外包含E2E数字签名。另外，也可以在服务层处保护本质上被认为是机密的信息和参数。消息完整性保护和或消息认证可以通过JSONWeb签名（JWS或通过JSONWeb加密JWE来提供。中间节点只能处理元数据或可路由数据。元数据可以由使用与用于E2E安全性的公钥相关联的私钥创建的E2EJSONWeb签名保护完整性和认证。替选地，未被任何中间节点修改的整个消息可被用于创建表示整个消息的数字签名DS的JSONWeb签名或JSONWeb加密JWE。签名DS或JWS也可以使用其他方法生成并且使用专有机制表示。不管用于生成签名的机制和在消息收发中签名的表示，通过使用与时间分量相关联的Nonce随机值或时间和Nonce两者的组合，可使未被中间节点修改去除的整体消息免受重放攻击。例如，可以使用私钥导出签名，由CR提供给请求E2E认证的实体，或由实体生成并且以安全的方式本地存储。[0156]类似地，可以使用发起者信息来认证消息的发起者。如果正确的消息信息集被用于创建元数据，那么它不仅可用于认证消息的发起者的E2E认证，还可以认证消息的“意图”。消息的意图可以指示消息的来源发起者）、消息的目的地接收者）、消息的类型、消息可以触发的操作类型和对其执行操作创建、删除、更新、检索、通知）的资源例如，传感器资源）。假设“发起者信息”没有被任何中间节点修改。当消息未被中间节点修改时，“发起者信息”可以包括整个消息。与发起者信息相关联的示例参数可以包括:具有与消息的来源发起者相关联的标识符的“fr”（来自）字段、指示消息的目的地的“to”字段，以及指示要执行的操作的类型的“op”字段，例如创建、检索、更新、删除或通知;指示唯一资源标识或资源类型的“res-ID”字段、指示唯一会话的“session-ID”字段。会话ID可以是顺序次序的数字或随机值例如，Nonce，并且可以或可以不与时间分量例如，NTP相关联。[0157]参数可以包括安全性参数。例如，安全性参数可以包括一个或多个随机值、Nonce，或时间参数，诸如创建原始消息时的时间戳。可以使用Nonce将事件唯一地与会话相关联。另外，安全性参数可以包含有关如何使用密码套件的类型、待使用的凭证等的信息。[0158]安全性参数可以包括会话层的指示。使用通过DTLS或TLS的E2E认证。这将绕过逐跳安全机制。终端实体将被双向认证并且建立安全关联。这可以以真正的E2E方式直接或委托模式在实体之间完成。E2E公钥可以被用于使用诸如HTTPSCoAPS的应用层协议，在两个端点之间认证。[0159]端对端认证过程E2EAP[0160]E2E认证过程可以以直接E2E方式或以委托或部分委托混合方式来执行。E2E认证可以涉及或可以不涉及双向E2E认证，并且只能以E2E方式进行单向认证。在许多情况下，E2E认证可以仅涉及实体N认证者认证另一实体，即实体A被认证者），或反之亦然。根据用例和SESC过程，可以确定可能需要E2E双向认证。本文档中所述的机制能被用来执行双向E2E认证以及单向E2E认证。在这种情况下，实体A表现为被认证者以及认证者两者。类似地，实体N执行被认证者以及认证者的作用。在这种情况下，假设实体N可以预先执行SESC和SCRP过程，并且实体A已经执行了TPCR过程。为了解释E2E认证的概念，在本文档中仅详细地描述单向认证，因为对执行双向认证执行类似的过程，并且在这些情况下，实体A和实体N在执行SESC、SCRP、TPCR过程中的作用相反。对于文档的其余部分，术语E2E认证是指消息的发起者的单向或双向认证，和或消息的实际意图的认证或整个消息的认证。[0161]基于由实体提供或选择的作用域，可以通过验证JWSJWE中的数据信号，执行E2E认证过程。例如，可以使用基于证书的机制，由此，所提供的凭证可以基于以证书的形式表示并且仅由被授权的实体用于适用的上下文的公钥。希望建立E2E安全关联的实体可以基于与该证书相关联的公钥，使用用于认证的证书和消息认证。可以预先提供或在与CR的E2E认证过程期间（在TPCR阶段期间）获得证书。替选地，公钥可以由实体向另一实体注册并与特定上下文相关联。可以使用随机句柄Nonce询问实体，以便验证拥有私钥。在某些情况下，询问可以是是可选的，但是可以使用生成的唯一随机句柄Nonce由消息的发起者和签名提供新鲜度信息。[0162]执行源自另一实体的消息的E2E认证的实体可以在TPCR阶段期间获得适合的E2E凭证。此外，实体还可以获得其他相关信息，诸如作用域。作为认证过程的一部分，实体可以检查以基于作用域信息查看使用认证标签期望保护何种消息例如创建、更新、删除等）。当接收到消息时，实体检查以查看与该资源相关联的作用域信息，并获得在TPCR过程中本地存储的适当凭证，或从TTP明确获取。基于作用域信息和证书以及消息原始信息或原始消息的消息意图（例如，元数据），实体计算DS或认证标签。其将认证标签与作为消息一部分发送的认证标签比较，如果有任何差异，则可以丢弃该消息。[0163]图13是图示由DE代表实体N对实体A的消息的单向认证的示例调用流。实体A发送还包含认证标签1例如，DS或MAC的消息1。该消息可以包含可选标志1，指示该消息具有认证标签，其能被用于消息发起者认证目的。[0164]在步骤2,已经由实体N授权以代表实体N执行消息认证的DE可以使用隐式机制或通过执行TPCR过程显式地获得实体A的公钥凭证。然后，DE验证认证标签UDE可以基于标志1，决定执行认证。在非委托模式下，实体N自行验证认证标签1，并跳过消息3。[0165]DE将消息3转发到实体N。消息3可以包括指示从E2E角度看是否成功地认证消息发起者的标志2。[0166]在步骤4中，实体N验证标志，并且基于该标志，处理该消息。[0167]示例实施例[0168]本文所述的实施例主要集中在oneM2M架构上。先前所述的常用功能（例如，SEF、CR可以并入到oneM2M架构中作为“安全性”CSF的一部分，并且在图14中示出。[0169]如在前章节所述，E2E认证过程可以需要4个步骤。在某些实施方式实施例中，可以基于所涉及的实体和实体之间的信任关系以及所使用的协议来组合或优化这些步骤。下文描述使用服务层例如，〇neM2M的解决方案的高级描述：[0170]服务启用和安全配置SESC[0171]SESC功能可以被托管在公共服务实体CSE上。在oneM2M注册过程之前，可以在应用实体和CSE之间执行SESCAESC功能可以可选地被托管在驻留在服务提供商域内的实体上，并且在这种情况下，AE与在M2M服务提供商（SP网络上托管的实体执行SESC过程。可以由TTP，例如，信任启用器功能（TEF、M2M登入功能MEF或M2M认证功能MAF执行SESC过程。作为常规〇neM2M注册过程的结果，用于逐跳安全性的适当的凭证可以被提供给AE和CSE。作为SESC过程的一部分，执行适当的凭证、作用域和参数的识别。可以在SESC过程期间以及如果注册员CSE也执行SESC功能，执行E2E凭证提供和注册过程。[0172]图15示出向CSE注册的示例，其中，服务启用和安全配置SESC功能驻留在注册员CSERCSE处。在步骤0中，为AEl提供可以被配置的凭证，以便可以与注册员CSERCSE配对并且向其注册，其遵循在当前〇neM2M规范中描述的机制。AEl的配置可以通过借助⑶I、web界面或来自控制台的界面，将例如RCSE的共享秘密放入AE中来执行。任意多个AE最初可以与RCSE共享相同的秘密。或者，可以使用一次性密码来配对RCSE和AE。替选地，可以使用AE证书，以便通过证书或公钥与RCSE认证，或反之亦然。替选地，RCSE和AE可以借助Diffie-HeIIman过程使用安全连接。[0173]在步骤1，然后通过RCSE导出唯一的逐跳HbH凭证并且提供给AEl，或者通过CSE将密钥材料提供给AEl，以便提供逐跳凭证。仅AEl和RCSE共享新提供的凭证。基于AE提供的服务类型，可以向AE提供适合的凭证基于第5.1节中讨论的判据）以及可能与凭证一起使用的适当上下文和参数。在该步骤期间，可能存在协商过程以便生成或导出可由两个实体RCSE以及AE1均接受的凭证，因此，可能需要在RCSE和AEl之间的任一方向中传送的一个以上消息，直到两个实体同意所选凭证为止。基于AEl提供的（基于设备、安全能力导出的）要求，在该阶段，RCSE还可以提供E2E凭证。替选地，可以在SCRP阶段提供E2E公钥凭证，或替选地，可以在步骤3提供E2E公钥凭证。[0174]在步骤2中，AEl和RCSE使用HbH凭证创建安全的DTLS通道。[0175]在步骤3中，AEl使用安全通道执行注册过程。[0176]替选地，SESC过程由TTP例如，TEF、MEF、MAF执行，并且逐跳凭证的提供由TTP被提供给AE和注册员CSE。此外，SEF可以在确定正确的安全性特征集合中考虑设备能力（例如，电池、计算和存储器）JTP也可以由TTP将E2E公钥凭证提供给AE，TTP可能托管CR。[0177]图16示出由信任的第三方TTP提供逐跳凭证的示例。在步骤0中，RCSE使用RCSE和TTP之间的预先提供的凭证，与TTP认证。在步骤1中，AEl基于AEl和TTP之间预先提供的凭证与TTP认证。[0178]在步骤2,TTP使用与两个实体的安全连接来提供将在RCSE和AEl之间共享的逐跳凭证。可能已经基于根据RCSE和TTP之间的认证和根据AE1和TTP之间的认证导出的凭证来引导凭证。例如，可以然后导出唯一逐跳HbH凭证并且由TTP提供给AEl以及给RCSEt^AEl和RCSE共享新提供的凭证。基于由AE提供的服务类型基于在第5.1节讨论的判据），可以向AE1和RCSE提供适当的凭证以及可以与凭证一起使用的适当的上下文和参数。基于由AE1提供的要求，RCSE可以在该阶段提供E2E凭证。替选地，可以在SCRP阶段提供E2E公钥凭证。[0179]在步骤3，AE1和RCSE使用HbH凭证，创建安全〇TLS通道。在步骤4，AE1使用安全通道执行注册过程。[0180]图17图示基于已经提供的HbH凭证，已经被添加到资源结构的资源类型“安全性参数securityParameters”的高级资源结构。可能存在与适用于可以使用安全性参数的上下文的资源相关联的O-N个这样的“安全性参数”。[0181]图18图示在提供HbH凭证之后的AE资源。HbH凭证由以下各项识别=CredentialID属性、以及可用于描述凭证类型（例如，公钥或PSKHbH的credentialCharacteristics、将与凭证一起使用的算法、用于签名或加密的作用域、凭证特定参数例如，密钥、公钥参数）和可能具有如已经或将要使用的Nonce随机值、时间分量、期望使用的元数据信息的分量的等的组件的miseeIlaneousParams等。[0182]安全性凭证请求注册过程SCRP[0183]SCRP过程主要集中在用于端对端认证的公钥凭证的请求和或注册中。本文所述的SCRP过程主要关注AE的E2E凭证。然而，可以使用类似的过程来执行用于CSE的SCRP以通过TTP或CSE的RCSE执行SCRP。[0184]图19示出AE从凭证注册表CR请求E2E公钥凭证的示例。在步骤0中，CR可以使用oneM2M服务层提供凭证提供服务。该CR可以向CSE宣告是服务。RCSE也可以可选地订阅该服务。CR可以可选地在RCSE创建资源，但是资源可以仅向CRCSE提供关于CR和可达性链接的信息，而不提供完整的CR功能。[0185]在步骤I，AEl使用HbH凭证与注册员CSERCSE建立DTLS连接。如果现有的（DTLS连接存在，则不建立新连接。[0186]在步骤2,AEl在RCSE创建资源，如果且还未存在的话。只要提供了E2E凭证，AEl期望在某些时候更新资源。[0187]在步骤3，AE1通过查询RCSE来发现由CR提供的服务，并且获得关于可达性和由CR提供的服务的信息。[0188]在步骤4，AE1向CR资源订阅，使用CR请求创建资源。这可以是为AEl定制的子资源，并且CR可以维护与已经请求了SCRP过程的每个AE相关联的多个子资源。CR提供将由AEl使用的安全性参数列表，以便注册请求凭证。[0189]在步骤5，AE1使用其公钥更新资源。可选地，可以使用AEl的私钥签名该消息。[0190]在步骤6，CR可选地验证签名是否存在，并且在验证所有所需的检查后，可以发出数字证书。CR可以通知AEl何时创建了该证书并且提供给AEl。[0191]在步骤7，AEl可以通过所提供的凭证和参数，更新RCSE上的资源。可选地，RCSE可以在步骤5更新RCSE上的AE1资源。[0192]只要在RCSE，通过安全性参数更新了AEl资源，资源可以采取图20所示的形式。[0193]替选地，CR功能可以被托管在RCSE或HCSEJE能够向RCSE请求证书或注册公钥凭证，如图21所示。[0194]在图21的步骤1，AE1使用HbH凭证，与RCSE建立DTLS连接。如果存在现有的DTLS连接，贝1J不会建立新连接。[0195]在步骤2，RCSE可以提供实现CR功能的凭证提供服务。RCSE可以向其他CSE宣告〈Annc是服务。要求凭证请求服务的AE发现由RCSE托管的服务。AEl发现RCSE提供CR服务。[0196]在步骤3，AE1请求使用CR创建资源。这可以是为AEl定制的子资源，并且CR可以维护与请求SCRP过程的每个AE相关联的多个子资源。CR提供将由AEl使用的安全性参数列表，以便注册请求凭证。[0197]在步骤4，AE1使用其公钥更新资源。可选地，可以使用AEl的私钥签名消息。[0198]在步骤5，CR可以验证签名（这可以是可选的），并且在验证所有所需的检查后，可以发出数字证书。CR可以通知AEl何时创建了证书并且将其提供给AE1。[0199]第三方凭证请求程序[0200]可以以隐式手段或显式地分发或提供凭证。作为包含资源的检索过程的结果，可以隐式地分发凭证，其中，凭证是资源的属性。在显式过程中，凭证不可用作RCSE处托管的资源的属性，但凭证可以托管在另一TTP服务器可以是服务提供商的一部分上，其中，希望获得其的AE将必须明确请求凭证。[0201]图22图示将凭证隐式分发给第三方。[0202]在步骤0，AE1请求使用其RCSE1创建资源。基于该请求，RCSE1创建资源。基于该请求和基于在SESC过程期间执行的分析，提供适当的E2E凭证。[0203]在步骤1，RCSE1使用由CSERCSE1和RCSE2共享的HbH凭证，建立与RCSE2的DTLS连接。[0204]在步骤2，RCSE1向RCSE2宣告AE1资源的可用性。[0205]在步骤3，AE2使用在AE2和RCSE2之间共享的HbH凭证，建立与RCSE2的安全DTLS连接。[0206]在步骤4，AE2执行资源发现操作并获得关于宣告的资源AEl的信息。[0207]在步骤5，AE2请求检索与AEl的E2E凭证相关联的AEl子资源。[0208]在步骤6，在执行相关的访问控制检查后，其中，由RCSE2或RCSE1执行检查，则为AE2提供AEl的E2E凭证。[0209]端对端认证流程[0210]可以以直接模式或经由委托模式执行E2E认证过程。在直接模式下，可以是消息的来源和汇点的两个终端实体可以自行执行E2E认证。对任一实体的资源约束可以要求在更资源丰富的实体上执行某些公钥操作。因此，在控制喷水器系统的致动器的情况下，E2E认证可以由诸如致动器实际向其注册的RCSE的实体来执行，而不是在致动器AE本身上执行认证。因此，第三方凭证请求将必须由RCSE而不是AE执行。可以在RCSE处指示与资源相关联的、指示可以使用委托模式或直接模式来认证消息的属性。[0211]图23示出其中传感器AE1、AE2和AE3以规则或不规则的间隔产生传感器消息并更新由他们的RCSEl托管的各自的资源的情况。这些传感器可以或可以不执行类似的操作，并且能设想由不同的RCSE托管。为简单起见，图示了所有的AE被注册到同一的RCSE1。已经订阅了AEl、AE2和AE3的“订阅”资源的AE4可以已经在订阅授权过程或TPCR阶段期间被预先提供它们各自的E2E公钥凭证，或者可以被明确地提供。[0212]AEl发送指示操作（例如，请求更新资源）的消息，消息已经由AEl使用其私钥数字地签名。必须使用与该资源相关联的适合的元数据和安全性参数。为了简单起见，数据信号在此表示用于E2E认证的数字签名，而Hl、H2...表示与逐跳安全关联相关联的数字签名或MAC。可以将数字签名DSl、和可选地可以是与AEl和RCSEl之间关联的HbH凭证相关联的MAC或DS的Hl发送为⑶TLS消息的一部分。Hl是可选的，因为RCSE可能能够使用DSl来认证AEl，因此Hl可能是是冗余的。然而，如果Hl基于对称密钥，并且RCSEl不希望自行执行公钥凭证验证，则也可以包括HlACSEl将消息转发到IN-CSE，并且包括元数据、DSl和H4，其可以是用于由IN-CSE并且基于与RCSEl和IN-CSE相关联的HbH凭证来认证RCSEl的DS或MAC。可选地，使用的元数据可以是可以被使用的整个消息，或者使用的元数据可以是用于认证的关联数据。类似地，IN-CSE将消息包括原始元数据、DS1和H7转发到RCSE2ACSE2在认证临时消息发起者IN-CSE时，RCSE2向AE4发送包含消息、元数据、DSl和HlO的通知。AE4通过验证HlO认证RCSE2，然后开始处理元数据或整个消息，并且使用在订阅过程期间获得的信息来确定安全性参数以及将用在认证AEl中的算法、凭证等。AE4使用AEl的公钥来验证DSl，并且如果成功，AE4使用已经由AEl更新的内容，否则该消息被拒绝。类似地，AE4使用AE2的公钥认证来自AE2的消息以验证DS2，并且使用AE3的公钥验证来自AE3的消息以验证DS3。[0213]在消息到达RCSE2或AE4之前，RCSEl、IN-CSE或任何其他中间实体可以被授权来认证AElDSl。由于公钥凭证是可公开获得的并且通常不需要授权，所以任何实体能够认证消息，假定策略允许发生这种认证，简单地说，中间实体必须被授权以执行这种认证。因此，如果RCSEl或IN-CSE确定来自AEl的DSl已经认证失败，则RCSE1IN-CSE可以基于管理RCSE1IN-CSE操作的策略来丢弃该消息。替选地，可以转发消息，然而，指示消息认证失败的标志可以由RCSE1IN-CSE添加到消息上，然后转发到RCSE2AE4。由于标志指示消息认证失败，RCSE2和或AE4可以可选地跳过处理DS。[0214]图24图示RCSEl代表AEl、AE2和AE3作为将被AE4认证的实体的情况。在RCSEl处对AE1、AE2和AE3注册的资源可以指示这些资源以委托模式运行，并且在向第三方阶段的凭证分发期间，可以包括与RCSEl相关联的信息和安全性参数。因此，想要认证来自AEl的消息的任何实体必须知道AEl以委托模式运行，并且负责源自AEl的消息的真实性的实体已被委托或卸载到RCSEl。因此，必须为认证实体例如，AE4提供RCSEl的相关公钥凭证和安全性参数。[0215]AE1向RCSE1发送可能使用AE1和RCSE1的共享安全关联保护的消息，该消息可以包括Hl，其可以是为HbH安全性的在AEl和RCSEl之间关联的MAC或DS。一旦RCSEl使用Hl认证AE1，则RCSE创建消息的数字签名（使用整个消息或消息的元数据），其可以包括来自来自AEl的原始消息的可选元数据以及其消息的可选元数据，以及使用其私钥以及适当的安全性参数，并且将消息转发到IN-CSEt3IN-CSE遵循如前所述的类似的过程，以及验证H7并且将消息转发到AELAE4基于在订阅过程中获得的信息，意识到消息可能源自AEl，但由RCSEl签名。AE4可以使用来自AE1的可选的元数据或整个消息和RCSE1的公钥以及所需的安全性参数来认证消息。AE4可以使用来自由RCSEl创建的消息的元数据或整个消息以便认证AEl，以及可选地，包括来自AEl以及来自RCSEl两者的元数据以便由代理认证AE1。[0216]图25示出由致动器使用直接模式的系统或应用的E2E认证。假设AE被预先提供应用AE4的公钥凭证。来自应用的动作消息可以是致动器例如，喷洒系统开始动作例如喷水或任何其它化合物）。动作消息可以是与致动器相关联的资源相关的更新消息或与应用相关联的资源的改变的通知的组合。无论是否发起动作，可以认证发起该动作的消息是否实际上源自系统应用AE4的验证。[0217]AE4使用其私钥以及关联的安全性参数，创建消息的数字签名（例如，用于向AEl传送消息的DS1。使用安全DTLS通道将消息转发到RCSE2,并且可以可选地包括与HbH凭证相关联的MACHl。RCSE2认证Hl可选），并且替代地可以认证DSl，并且将消息转发至丨jIN-CSE。IN-CSE通过验证H4来认证RCSE2，并且将消息转发到RCSElICSEl认证H7，并且将消息转发至IJAElJEl基于策略和关联的订阅信息，基于上下文和安全性参数以及在订阅或TPCR期间已经预先提供的AE4的公钥，通过使用包含的消息的元数据或基于整个消息，执行AE4的E2E认证。类似地，AE2和AE3使用AE4的公钥来验证显然具有不同的签名的他们各自的信息。[0218]图26图示认证的委托模式，其中，由RCSEl代表AEl以及AE2和AE3验证和认证数字签名。AE4的公钥与安全性参数一起使用，以便RCSEl分别验证DSl、DS2和DS3。[0219]示例实施例[0220]本部分描述了基于oneM2M规范的详细实施例，并且在图27中示出关联的图示。假设默认情况下，在两个通信实体之间使用HbH安全保护例如⑶TLS。也可以是AE和另一AE之间的跳数为多个，因此，可以借助多个丽-CSEIN-CSE跳跃多个信任的域。其中委托模式以及未委托E2E模式的实施例的消息收发细节：[0221]在步骤1，AE1请求在RCSEl创建资源。基于适当的检查，RCSEl注册并托管与RCSEl相关联的资源。[0222]在步骤2，AE2可以请求订阅AEl资源。基于RCSEl或服务提供商的策略，可以要求使用其公钥凭证认证AE2。作为订阅消息的请求的一部分，AE2包括可以基于为E2E认证定义的作用域通过使用其私钥、可选元数据或整个消息以及关联的参数创建的消息的数字签名。[0223]如果使用元数据而不是整个消息，组成消息元数据Ml的参数或属性由AE2创建和使用。这些至少包括以下参数或其等同物：[0224]fr=AE2-ID；[0225]to=RCSEl-ID；[0226]res-id=resource_IDl;[0227]〇p=“订阅”；[0228]sessionid=随机值I可选地，还有时间分量）。[0229]也可以将其它参数包括为消息元数据的一部分。在某些情况下，其中中间跳不修改消息，可以完全避免消息元数据，或者可以仅包括参数或头部信息的子集，或者在创建数据信号中使用整个消息。在示例DS创建过程中：[0230]Ml=AE1-IDIIRCESl-IDIIresource-IDlIΓ订阅”II随机值1;[0231]Hash_Meta_DataHI=Hash_AlgorithmMl;以及[0232]DSl=Public_Key_Encryption_AlgorithmHI，AE1_私钥）〇[0233]替选地，整个消息可被用于生成DS。[0234]在步骤3，基于RCSEl处的策略，意识到将必须执行“订阅”消息的Ε2Ε认证。RCSEl处理可选的元数据，并且如果尚未提供它，则获取ΑΕ2的公钥，然后根据与凭证相关联的作用域，如果使用元数据，则RCSEl以下述方式处理DSl;如果整个消息用于生成DS，则可以使用类似的机制。当整个消息被用于创建DS时，D-H1、M1和C-Hl的计算可以由整个消息的DS的解密来代替：[0235]Decrypted_HlD-Hl=Public_Key_Encrytion_AlgorithmDS,AEl-PublicKey；以及[0236]Computed_Hash_Meta_DataC-Hl=Hash_AlgorithmMl〇[0237]如果D-Hl==C-Hl，则认证消息发起者和消息。[0238]在步骤4中，RCSEl创建“通知”消息并且包括适当的消息和可选的元数据M2和关联的数字签名（DS2，并且转发到目的地为AE2的消息。使用前述机制，可以创建M2,并且可以如下计算DS2:[0239]fr=RCSEl-ID；[0240]to=AE2-ID；[0241]res-id=resource_IDl;[0242]op=“通知”；[0243]sessionid=随机值2;[0244]M2=RCES1-IDIIAEl-IDIIresource-IDlIΓ通知”II随机值2;[0245]Hash_Meta_DataH2=Hash_AlgorithmM2;以及[0246]DS2=Public_Key_Encryption_AlgorithmH2,RCSEl-私钥）〇[0247]在整个消息用于创建DS2的情况下，则用整个消息的散列替代Hash_Meta_Data，H2〇[0248]在步骤5,使用前述类似的机制，使用在元数据被用在创建DS2中的消息元数据M2、RCSE1的公钥并且基于作用域信息，AE2验证DS2。如果AE2不能验证DS2,因此不能认证RCSEl，则可以丢弃“通知”消息。[0249]在图28中示出另一实施例，其中，终端实体能够以真正的E2E方式认证源自彼此的消息。类似于图27所示的调用流，但是这里AE2想要认证来自AEl的、可能已经触发了来自RCSEl的通知消息的原始消息。[0250]在图28的步骤I，AE2订阅在RCSEl处托管的资源。AE2提供消息元数据Ml以及关联的DS1，使用AE2的私钥、Ml并且基于为使用密码操作定义的作用域计算。[0251]在步骤2，RCSE1通过使用AE2的公钥和M1并且基于定义的作用域来验证由AE2发送的DS1。[0252]在步骤3，AE1可以对在RCSEl上托管的资源执行更新操作。通过基于消息元数据M2或整个消息创建数字签名并且用AEl的私钥对其进行签名，可以认证执行更新操作的消息传递。AEl可以使用以下过程来创建DS:[0253]fr=AEl-ID；[0254]to=RCSEl-ID;[0255]res-id=resource_IDl;[0256]〇p=“更亲jf”；[0257]sessionid=随机值2;[0258]M2=AE1-IDIIRCSEl-IDIIresource-IDlIΓ更新”II随机值2;[0259]Hash_Meta_DataH2=Hash_AlgorithmM2；[0260]DS2=Public_Key_Encryption_AlgorithmH2，AE1_私钥）；和[0261]AEl将更新消息连同M2和对应的DS2发送到RCSE1。在使用整个消息来生成DS2的情况下，省略M2、H2的计算，并且将整个消息用于生成DS2而不是H2。[0262]在步骤4，RCSE1可以可选地使用AEl的公钥以及M2和基于作用域参数认证消息。如果不能认证消息，则可以丢弃更新消息。如果验证了DS，则RCSEl可以可选地为其创建的通知消息创建消息元数据M3，并使用RCSEl的私钥对其进行数字签名并创建DS3ACSEl可以可选地发送M2DS2以及M3DS3两者作为通知消息的一部分。[0263]在步骤5，AE2使用RCSEl的公钥来认证和校验DS3，从而认证通知消息，并且可以使用AEl的公钥以便验证DS2，从而认证初始更新消息确实由AEl发送。[0264]本文所述的各种技术可以结合硬件、固件、软件或在适合的情况下以其组合来实现。这些硬件、固件和软件可以驻留在位于通信网络的各个节点处的设备中。设备可以单独地操作或彼此结合操作来实现本文所述的方法。如本文所使用的，可以互换使用术语“装置”、“网络装置”、“节点”、“设备”和“网络节点”。[0265]图29是其中可实现一个或多个公开的实施例的示例机器间M2M、物联网（IoT或万物网WoT通信系统10的图。一般地，M2M技术提供了用于IoTWoT的构建模块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台可以是IoTWoT的组件或节点以及IoTWoT月艮务层等。图3-9、11-13、15、16、18、19和21-28的任何一个所示的客户端、代理或服务器设备的任何一个可以包括诸如图2、4，和14所示的通信系统的节点。[0266]如图29中所示，M2MIoTWoT通信系统10包括通信网络12。通信网络12可以是固定网络例如，以太网、光纤、ISDN、PLC等或无线网络例如，WLAN、蜂窝等或者异构网络的网络。例如，通信网络12可由向多个用户提供诸如语音、数据、视频、消息传递、广播等内容的多个接入网构成。例如，通信网络12可采用一个或多个信道接入法，诸如码分多址CDMA、时分多址TDMA、频分多址FDM、正交FDMAOFDMA、单载波FDMASC-FDM等。此外，通信网络12可包括其它网络，诸如例如核心网络、因特网、传感器网络、工业控制网络、个域网、融合个人网络、卫星网络、家庭网络或企业网。[0267]如图29中所示，M2MIoTWoT通信系统10可包括基础结构域和场域。基础结构域指代端对端M2M部署的网络侧，以及场域指代通常在M2M网关后面的区域网。场域和基础结构域两者可包括网络的多种不同的节点（例如，服务器、网关、设备等）。例如，场域可包括M2M网关14和设备18。将认识到的是可根据期望在M2MI〇TW〇T通信系统10中包括任何数量的M2M网关设备14和M2M设备18J2M网关设备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包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康健身监视器、灯、恒温器、器具、车库门及其它基于致动器的设备、安全设备以及智能插座。[0268]参考图30，场域中的所示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服务器、在蜂窝式核心网络中、在云中等。[0269]类似于所示的M2M服务层22,在基础结构域中存在M2M服务层22’J2M服务层22’为基础结构域中的M2M应用20’和底层通信网络12’提供服务。M2M服务层22’还为场域中的M2M网关设备14和M2M设备18提供服务。将理解的是M2M服务层22’可与任何数量的M2M应用、M2M网关和M2M设备通信。M2M服务层22’可通过不同的服务提供商与服务层相交互。M2M服务层22’可由网络的一个或多个节点实现，其可包括服务器、计算机、设备、虚拟机例如，云计算存储群等等。[0270]还参考图30，M2M服务层22和22’提供了不同应用和领域可以利用的核心的核心服务递送能力集。这些服务能力使得M2M应用20和20’能够与设备相交互并执行诸如数据收集、数据分析、设备管理、安全、计费、服务设备发现等功能。本质上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并减少了成本和上市时间。服务层22和22’还使得M2M应用20和20’能够通过与服务层22和22’提供的服务相连接的各种网络12和12’进行通信。[0271]M2M应用20和20’可以包括在各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪、以及安全和监控。如上所述，跨越系统的设备、网关、服务器及其它节点运行的M2M服务层支持诸如例如数据收集、设备管理、安全、计费、位置跟踪地理围栏、设备服务发现以及传统系统集成的功能，并将这些功能作为服务提供给M2M应用20和20’。[0272]一般地，诸如图29和30所示的服务层22和22’的服务层定义了通过应用编程界面API和底层联网接口的集合来支持增值服务能力的软件中间件层。ETSIM2M和oneM2M架构两者都定义了服务层。ETSIM2M的服务层称为服务能力层SCL。可在ETSIM2M架构的多种不同节点中实现SCL。例如，可在M2M设备其中，将其称为设备SCLDSCL、网关其中，将其称为网关SCLGSCL和或网络节点其中，将其称为网络SCLNSCL内实现服务层的实例。oneM2M服务层支持公共服务功能（CSF即服务能力）的集合。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体CSE，其可以在不同类型的网络节点（例如基础结构节点、中间节点、应用特定节点）上托管。第三代合作伙伴计划（3GPP还定义了用于机器类型通信MTC的架构。在该架构中，服务器及其提供的服务能力被实现为服务能力服务器SCS的一部分。无论实施在ETSIM2M架构的DSCUGSCL或NSCL中、在3GPPMTC架构的服务能力服务器SCS中、在oneM2M架构的CSF或CSE中还是在网络的某个其它节点中，服务层的实例都可被实现为在网络中的包括服务器、计算机及其它计算设备或节点的一个或多个独立节点上或者作为一个或多个现有节点的一部分执行的逻辑实体例如，软件、计算机可执行指令等）。作为示例，可以在具有下面描述的图31或图32中所示的通用架构的网络节点例如，服务器、计算机、网关、设备等上运行的软件的形式实现服务层或其组件的实例。[0273]此外，本文所述的方法和功能可以实现为使用面向服务架构SOA和或面向资源架构ROA的M2M网络的一部分以接入服务。[0274]图31是诸如可以操作为诸如图29和30所示的M2M网络中的M2M服务器、网关、设备或其他节点的图3-9、11-13、15、16、18、19和21-28中所示的客户端、服务器或代理中的一个的示例硬件软件架构的框图。如图31中所示，节点30可包括处理器32、不可移动存储器44、可移动存储器46、扬声器扩音器38、小键盘40、显示器、触摸板和或指示器42、电源48、全球定位系统GPS芯片集50及其它外设52。节点30还可包括通信电路，诸如收发器34和发送接收元件36。将认识到的是M2M节点30可包括前述元件的任何子组合，而仍与实施例保持一致。此节点可以是实现本文所述的端对端认证的方面的节点。[0275]处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器DSP、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路ASIC、现场可编程门阵列FPGA电路、任何其它类型的集成电路IC、状态机等。一般地，处理器32可执行存储在节点的存储器例如，存储器44和或存储器46中的计算机可执行指令以便执行节点的各种所需功能。例如，处理器32可执行信号编码、数据处理、功率控制、输入输出过程和或使得节点30能够在无线或有线环境中操作的任何其它功能。处理器32可运行应用层程序例如，浏览器和或无线电接入层RAN程序和或其它通信程序。例如，处理器32还可执行诸如在接入层和或应用层处的诸如认证、安全密钥协议和或密码操作的安全操作。[0276]如图31中所示，处理器32被耦合至通信电路（例如，收发器34和发送接收元件36。处理器32通过计算机可执行指令的执行可控制通信电路以便促使节点30经由其被连接到的网络来与其它节点通信。特别地，处理器32可控制通信电路以便执行在本文例如图3-9、11-13、15、16、18、19和21-28和权利要求中描述的发送和接收步骤。虽然图31将处理器32和收发器34描绘为单独组件，但将认识到的是可将处理器32和收发器34—起集成在电子封装或芯片中。[0277]发送接收元件36可被配置成向包括M2M服务器、网关、设备等的其它节点发射信号或从其接收信号。例如，在实施例中，发送接收元件36可以是被配置成发送和或接收RF信号的天线。发送接收元件36可支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在实施例中，发送接收元件36可以是被配置成发送和或接收IR、UV或可见光信号的发射器探测器。在另一实施例中，发送接收元件36可被配置成发送和接收RF和光信号两者。将认识到的是发送接收元件36可被配置成发送和或接收无线或有线信号的任何组合。[0278]另外，虽然发送接收元件36在图31中被描绘为单个元件，但节点30可包括任何数量的发送接收元件36。更具体地，节点30可采用MMO技术。因此，在实施例中，节点30可包括用于发送和接收无线信号的两个或更多个发送接收元件36例如，多个天线）。[0279]收发器34可被配置成调制将提供发送接收元件36发送的信号并解调将由发送接收元件36接收到的信号。如上所述，节点30可具有多模式能力。因此，例如，收发器34可包括用于使得节点30能够经由诸如UTRA和IEEE802.11的多个RAT进行通信的多个收发器。[0280]处理器32可从诸如不可移动存储器44和或可移动存储器46的任何类型的适当存储器访问信息并在其中存储数据。例如，如上所述，处理器32可将会话上下文存储在其存储器中。不可移动存储器44可包括随机存取存储器RAM、只读存储器Φ0Μ、硬盘或任何其它类型的存储器存储设备。可移动存储器46可包括订户身份模块SM卡、记忆棒、安全数字SD存储卡等。在其它实施例中，处理器32可从在物理上不位于节点30上诸如在服务器或家用计算机上）的存储器访问信息以及在其中存储数据。处理器32可被配置成控制显示器或指示器42上的照明图案、图像或色彩以反映M2M服务层会话迀移或共享的状态，或从用户获得输入，或者向用户显示关于节点的会话迀移或共享能力或设置的信息。在另一示例中，显示器可示出关于会话状态的信息。[0281]处理器32可从电源48接收电力，并且可被配置成向节点30中的其它组件分配和或控制电力。电源48可以是用于对节点30供电的任何适当设备。例如，电源48可包括一个或多个干电池例如，镍镉NiCd、镍锌NiZn、镍金属氢化物NiMH、锂离子Li离子等）、太阳能电池、燃料电池等。[0282]处理器32还可被耦合到GPS芯片集50,其被配置成提供关于节点30的当前位置的位置信息例如，经度和炜度）。将认识到的是节点30可通过任何适合的位置确定方法来获取位置信息，而仍与实施例保持一致。[0283]处理器32可进一步被耦合到其它外设52,其可包括提供附加特征、功能和或有线或无线连接的一个或多个软件和或硬件模块。例如，外设52可包括加速度计、电子指南针、卫星收发器、传感器、数字式照相机（用于照片或视频）、通用串行总线（USB端口、振动设备、电视收发器、免提耳机、Bluetooth⑧模块、调频FM无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等。[0284]图32是还可用来实现可以操作为诸如图29和30所示的M2M网络中的M2M服务器、网关、设备或其他节点的网络的一个或多个节点的诸如图3-9、11-13、15、16、18、19和21-28所示的客户端、服务器或代理的示例计算系统90的框图。计算系统90可包括计算机或服务器，并且可主要由可以以软件的形式的计算机可读指令来控制，无论在哪里或通过何种手段来存储或访问此类软件。此类计算机可读指令可在诸如中央处理单元CPU91的处理器内被执行以促使计算系统90进行工作。在许多已知工作站、服务器以及个人计算机中，中央处理单元91由被称为微处理器的单片CPU实现。在其它机器中，中央处理单元91可包括多个处理器。协处理器81是不同于主CPU91的可选处理器，其执行附加功能或协助CPU9UCPU91和或协处理器81可接收、生成以及处理与用于E2EM2M服务层会话的公开系统和方法有关的数据，诸如接收会话凭证并基于该会话凭证进行认证。[0285]在操作中，CPU91获取、解码并执行指令，并经由计算机的主数据传输路径、系统总线80来向和从其它资源传输信息。此类系统总线连接计算系统90中的组件，并且定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断且用于控制系统总线的控制线。此类系统总线80的示例是PCI外围部件互连总线。[0286]被耦合到系统总线80的存储器包括随机存取存储器RAM82和只读存储器ROM93。此类存储器包括允许存储和检索信息的电路。ROM93—般包含不能被轻易被修改的存储数据。存储在RAM82中的数据可被CPU91或其它硬件设备读取或改变。对RAM82和或ROM93的访问可由存储器控制器92来控制。存储器控制器92可提供在指令被执行时将虚拟地址转换成物理地址的地址转换功能。存储器控制器92还可提供将系统内的进程隔离并将系统进程从用户进程隔离的存储器保护功能。因此，在第一模式下运行的程序仅可访问由其自身进程虚拟地址空间映射的存储器;其不能访问另一进程的虚拟地址空间内的存储器，除非已经建立了进程之间的存储器共享。[0287]另外，计算系统90可包含外设控制器83,其负责将指令从CPU91传送到诸如打印机94、键盘84、鼠标95以及磁盘驱动器85的外设。[0288]由显示器控制器96控制的显示器86被用来显示由计算系统90生成的视觉输出。此类视觉输出可包括文本、图形、动画图形以及视频。可用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸板来实现显示器86。显示器控制器96包括生成被发送到显示器86的视频信号所需的电子组件。[0289]此外，计算系统90可包含通信电路，例如网络适配器97,其可用来将计算系统90连接到外部通信网络，诸如图29和图30的网络12，以使得计算系统90能够与网络的其它节点通信。可以单独地或结合CPU31使用通信电路来执行例如图3-9、11-13、15、16、18、19和21-28中和权利要求中所述的本文的发送和接收步骤。[0290]本文的图3-9、11-13、15、16、18、19和21-28、其描述和权利要求示出用于实现端对端认证功能的方法和装置的各种实施例。在这些图中，示出由一个或多个客户端、服务器和或代理执行的各种步骤或操作。应当理解到，这些图中所示的客户端、服务器和代理可以表示通信网络中的逻辑实体，并且可以以存储在这些网络的节点的存储器中并且在其处理器上执行的软件即计算机可执行指令的形式实现，其可以包括如本文所述的图29或30中所示的通用架构之一。也就是说，图3-9、11-13、15、16、18、19和21-28中所示的方法和权利要求可以以软件、即存储在诸如图31或图32所示的节点或计算机系统的网络节点的存储器中的计算机可执行指令的形式实现，当由节点的处理器执行该计算机可执行指令时，执行附图中所示的步骤。还应当理解到，这些图中所示的任何发送和接收步骤可以由在节点的处理器和及其执行的计算机可执行指令例如软件）的控制下由通信电路例如，分别为图31和32的电路34或97执行。[0291]应理解到，可以以存储在计算机可读存储介质上的计算机可执行指令（S卩，程序代码）的形式来实施本文所述的任何或所有系统、方法以及过程，该指令在被诸如包括例如M2M服务器、网关、设备等的M2M网络的节点的机器执行时执行和或实现本文所述的系统、方法和过程。具体地，上述的步骤、操作或功能的任何一个可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于信息存储的任何非瞬时（即，有形或物理方法或技术实现的易失性和非易失性介质、可移动和不可移动介质两者，但是此类计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、R0M、EEPR0M、闪存或其它存储技术、CD-ROM、数字多功能磁盘DVD或其它光盘存储、磁带盒、磁带、磁盘存储器或其它磁存储器件、或者可以用来存储期望信息且可以由计算机访问的其它有形或物理介质。[0292]本书面描述使用示例来公开本发明，包括最佳模式，并且还使得本领域的技术人员能够实施本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可以取得专利的范围由权利要求定义，并且可包括本领域的技术人员想到的其它示例。如果此类示例具有与权利要求的字面语言没有不同的元件或者如果其包括与权利要求的字面语言具有非实质性差别的等价元件，则此类其它示例意图落入权利要求的范围内。

权利要求：1.一种装置，包括处理器、存储器和通信电路，所述装置经由其通信电路连接到通信网络，所述装置进一步包括存储在所述装置的所述存储器中的计算机可执行指令，所述计算机可执行指令当由所述装置的所述处理器执行时，使所述装置：a.从消息发起者接收消息的多跳传输，其中通过第一中间实体接收所述传输，并且其中所述多跳传输包括由所述消息发起者生成的所述消息的数字签名；以及b.使用所述消息发起者的公钥和由所述消息发起者生成的所述消息的所述数字签名，认证所述消息发起者。2.如权利要求1所述的装置，其中，所述计算机可执行指令进一步使所述装置从信任的第三方获得所述消息发起者的所述公钥。3.如权利要求1所述的装置，其中，所述多跳传输来自与所述消息发起者分开的源实体，并且其中，所述多跳传输不包含由所述源实体生成的数字签名。4.如权利要求1所述的装置，其中，所述多跳传输进一步包括由所述第一中间实体生成的数字签名，并且其中，所述计算机可执行指令进一步使所述装置使用所述第一中间实体的公钥和由所述第一中间实体生成的所述签名，认证所述第一中间实体。5.如权利要求1所述的装置，其中，所述传输进一步包括由多个中间实体的每一个生成的数字签名，并且其中，所述计算机可执行指令进一步使所述装置使用所述公钥和由所述多个中间实体的每一个生成的所述数字签名，认证所述多个中间实体的每一个。6.如权利要求1所述的装置，其中，所述计算机可执行指令进一步使所述装置基于所述消息发起者的所述认证来确定是否将所述多跳传输转发到目的地实体。7.如权利要求6所述的装置，其中，所述计算机可执行指令进一步使所述装置：a.使用所述目的实体的公钥认证所述目的地实体；以及b.基于所述目的地实体的认证，确定是否将第一多跳传输转发到目的地实体。8.如权利要求1所述的装置，其中，所述多跳传输包括逐跳凭证，并且其中，所述计算机可执行指令进一步使所述装置检查所述逐跳凭证。9.一种方法，包括：a.通过第一中间实体，从消息发起者接收多跳传输，其中，所述多跳传输包括由所述消息发起者生成的数字签名；以及b.使用所述消息发起者的公钥和由所述消息发起者生成的所述数字签名，认证所述消息发起者。10.如权利要求9所述的方法，进一步包括从信任的第三方获得所述消息发起者的所述公钥。11.如权利要求9所述的方法，其中，所述多跳传输来自与所述消息发起者分开的源实体，并且其中，所述多跳传输不包含所述源实体的数字签名。12.如权利要求9所述的方法，其中，所述多跳传输进一步包括由所述第一中间实体生成的所述消息的数字签名，所述方法进一步包括使用所述第一中间实体的公钥和由所述第一中间实体生成的所述消息的所述数字签名，认证所述第一中间实体。13.如权利要求9所述的方法，其中，所述传输进一步包括包含由多个中间实体的每一个生成的数字签名的多个消息，所述方法进一步包括使用所述公钥和由所述多个中间实体的每一个生成的所述数字签名，认证所述多个中间实体。14.如权利要求9所述的方法，进一步包括基于所述消息发起者的所述认证，通过验证由所述消息发起者生成的所述数字签名，确定是否将所述多跳传输转发到目的地实体。15.如权利要求14所述的方法，进一步包括：a.使用由所述消息发起者生成的所述数字签名和所述目的实体的公钥，认证所述目的地实体；以及b.基于所述目的地实体的所述认证，确定是否将第一多跳传输转发到目的地实体。16.如权利要求9所述的方法，其中，所述多跳传输包括逐跳凭证，所述方法进一步包括检查所述逐跳凭证。17.—种装置，包括处理器、存储器和通信电路，所述装置经由其通信电路连接到通信网络，所述装置进一步包括存储在所述装置的所述存储器中的计算机可执行指令，所述计算机可执行指令当由所述装置的所述处理器执行时，使所述装置：a.注册和存储第一安全性处理能力参数集，所述第一安全性处理能力参数集对应于第一网络实体，其中，所述第一实体与所述装置分开;以及b.在请求时，将所述第一安全性处理能力参数集提供给第二网络实体，其中，所述第一实体与所述装置分开。18.如权利要求17所述的装置，其中，所述第一安全性处理能力参数集包括可用处理器功率、可用功率、可用存储器、可用无线带宽、消息完整性机制、认证机制、不可否认机制、机密性机制或支持的安全性协议。19.如权利要求17所述的装置，其中，所述安全性参数包括安全性凭证。20.如权利要求17所述的装置，其中，所述计算机可执行指令进一步使所述装置将仅需要端到端认证告知所述第二实体。

百度查询： 康维达无线有限责任公司 使用公钥机制在服务层的端对端认证

免责声明
1、本报告根据公开、合法渠道获得相关数据和信息，力求客观、公正，但并不保证数据的最终完整性和准确性。
2、报告中的分析和结论仅反映本公司于发布本报告当日的职业理解，仅供参考使用，不能作为本公司承担任何法律责任的依据或者凭证。

阅读全文 双屏查看 官方信息 专利公告 收藏专利 下载PDF 下载WORD