CN111201529A

CN111201529A - 用于ocf设备和受信任平台的安全配置文件

Info

Publication number: CN111201529A
Application number: CN201880062814.4A
Authority: CN
Inventors: E·卡布雷; N·赫尔德-谢拉; N·M·史密斯
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-01-24
Filing date: 2018-09-28
Publication date: 2020-05-26
Also published as: US20220303123A1; WO2019147311A1; DE112018006935T5

Abstract

本文讨论了用于为物联网(IoT)设备和受信任平台建立安全配置文件的各个系统和方法，包括在OCF规范设备部署中。在示例中，一种用于装载对象设备以与安全配置文件一起使用的技术，包括：接收对执行与设备平台相关联的设备的所有者转移方法的请求；验证与对象设备相关联的证明证据，该证明证据由使用制造商嵌入式密钥产生的证书进行签名，其中密钥从设备平台的受信任硬件组件提供；以及基于证明证据执行对象设备的设备供应，因为设备供应使对象设备使用与制造商嵌入式密钥绑定的安全配置文件。

Description

用于OCF设备和受信任平台的安全配置文件

优先权要求

本申请要求2018年1月24日提交的题为“用于OCF设备和受信任平台的安全配置文件(SECURITY PROFILES FOR OCF DEVICES AND TRUSTED PLATFORMS)”美国临时专利申请第62/621,376号的优先权的权益，该申请通过引用整体结合于此。

技术领域

本文所描述的实施例总体上涉及数据通信和互连的设备网络，并且具体涉及用于在物联网(IoT)设备与设备网络之间建立连接并实现功能的技术。

背景技术

IoT设备是可以在网络上通信的物理对象或虚拟对象，并且可以包括传感器、致动器、和其他输入/输出组件，诸如以从现实世界环境中收集数据或执行动作。例如，IoT设备可包括嵌入或附接到日常物品(诸如，建筑物、车辆、包裹等)的低功率设备，以提供对这些物品的附加水平的人工感官知觉。最近，IoT设备已变得越来越流行，因此使用这些设备的应用已经激增。

已经提出了各种标准来更有效地互连和操作IoT设备和IoT网络用例。这些包括由诸如电气和电子工程师协会(IEEE)之类的团体分发的通信标准的专业化、以及由诸如开放连接基金会(OCF)之类的团体分发的应用交互架构和配置标准的专业化。

附图说明

在附图中(这些附图不一定是按比例绘制的)，同样的数字可描述不同视图中的类似组件。具有不同的字母后缀的相同的数字可表示类似组件的不同实例。在所附附图的图中通过示例的方式而非限制性地图示出一些实施例，其中：

图1图示根据示例的用于通过链路而耦合到相应的网关的各个物联网(IoT)网络的域拓扑；

图2图示根据示例的云计算网络，该云计算网络与在该云计算网络的边缘处作为雾设备操作的IoT设备的网状网络进行通信；

图3图示根据示例的在受信任平台上托管的OCF设备的配置和操作；

图4图示根据示例的用于在受信任平台中使用设备的设备一致性过程的流程图；

图5图示根据示例的用于使用受信任平台的平台一致性的过程的流程图；

图6图示根据示例的用于受信任平台中的设备的受信任引导顺序的流程图；

图7图示根据示例的用于受信任平台中的设备的受信任的或经证明的设备装载的过程的流程图；

图8图示根据示例的用于受信任平台中的设备的设备到设备(device-to-device)操作的流程图；

图9图示了根据示例的用于装载对象设备以与安全配置文件一起使用的方法的流程图。

图10图示根据示例的网络的框图，该网络图示大量IoT设备之间的通信；以及

图11图示出示例IoT处理系统架构的框图，在该示例IoT处理系统架构上可执行本文中所讨论的技术(例如，操作、过程、方法和方法论)中的任何一种或多种。

具体实施方式

在以下描述中，公开了用于使用受信任平台来支持各个IoT设备之间的安全配置文件的方法、配置、和相关的设备。在示例中，适用于涉及公钥基础设施(PKI)组件的OCF设备配置，此类平台可以启用OCF设备和服务的部署，这些OCF设备和服务利用通用根证书授权机构(CA)(例如，由OCF或另一个受信任的组织所拥有或操作的CA)所产生的证书，同时通过使用安全配置文件和相关联的证明来确保证书的有效性。

如本文所讨论，受信任平台的使用和配置可以涉及受信任计算组(TCG)技术的各个方面以及将TCG特征并入OCF或类似的IoT网络部署中。以下技术使OCF设备可以(诸如通过使用TCG平台证书链接到OCF信任声明)绑定到TCG合规的平台。进一步地，使用该受信任平台可以使得能够在各个OCF设备之间直接建立信任，并且可以对发布的电子结果进行合规性测试。

可以使用以下技术，例如，以使标准或监督组织能够对捕获一致性测试的状态的文档进行签名。然后，组织可以标识组织正在使用哪个信任锚，并将此信息传递给相关的装载工具(OBT)和服务。

以下技术还使组织能够通过使用公共区块链来发布组织已经选择哪个CA。网络部署使用的OBT可以查询区块链，以可靠地找到最新发布的信任锚。如果在组织及其选择的根之间的CA层级结构中找到的密钥中的任何一个密钥已被破坏，则信誉好的组织会将信任锚撤消消息发布到区块链，从而使包含信任锚的先前提交的块无效。

另外，本技术的进一步扩展可以利用针对公共密钥基础设施(PKI)证书的TCG规范，以将平台信任声明链接到由该组织(例如，由OCF组织)维持的设备质量声明。这些和其他技术益处可以在OCF内以及像IoT网络部署之类的产品中实现。

在示例中，本技术和配置可以集成传统的和高度受约束的受信任环境的各方面，以支持信任锚策略的存储，其中对存储的访问取决于在受信任的环境中安全启动的证书路径验证代码或逻辑的执行。此类受信任的环境包括，但不限于，TCG受信任的平台模块(TPM)、英特尔安全保护扩展(SGX)、英特尔管理引擎(ME)、英特尔虚拟化技术(VT-X)、英特尔受信任的执行技术(TXT)、英特尔存储器控制器、英特尔3D交叉点或Optane存储器、英特尔存储器加密技术、英特尔SMI传输监控器(STM)、ARM TrustZone或其他硬件安全模块。

同样在示例中，本技术和配置可以实现(诸如由OCF规范定义的)网络装载工具的使用，以利用信任环境机制用于确保信任锚策略。

同样在示例中，本技术和配置可以使高度受约束的平台能够代表网络所有者执行网络装载职责。

同样在示例中，本技术和配置可以使受信任环境(包含证书路径验证代码/逻辑)和安全存储器(包含信任锚策略)的网格能够被一致地供应。本技术和配置还可提供允许每个网状平台应用相同的信任锚策略的效果。

同样在示例中，本技术和配置使用信任锚策略以及定义网络装载和网络扩展标准的其他策略来使具有信任锚策略的任何网络节点能够装载其他非成员节点。从以下讨论中，在各种IoT网络部署中可用的这些以及其他技术益处是显而易见的。

图1图示用于通过链路而耦合到各个网关的各个IoT网络的示例域拓扑。IoT支持部署，其中，大量计算设备互连至彼此并互连至因特网，以在非常低的级别上提供功能和数据采集。因此，如本文中所使用，IoT设备可包括执行功能(诸如感测或控制，等等)、与其他IoT设备和范围更广的网络(诸如因特网)进行通信的半自主设备。

IoT设备常在存储器、尺寸或功能方面受限，从而允许部署较大数量的设备，以实现与较少数量的较大设备类似的成本。然而，IoT设备可以是智能电话、膝上型设备、平板设备、或PC、或其他较大的设备。而且，IoT设备可以是虚拟设备，诸如智能电话或其他计算设备上的应用。IoT设备可包括IoT网关，这些IoT网关用于将IoT设备耦合至其他IoT设备并耦合至云应用，以进行数据存储、过程控制，等等。

IoT设备的网络可包括商用和家用自动化设备，诸如，给水系统、配电系统、管道控制系统、工厂控制系统、灯开关、恒温器、锁、相机、警报、运动传感器，等等。IoT设备可以是通过远程计算机、服务器和其他系统可访问的，从而例如控制系统或访问数据。

因特网和类似网络的未来增长可涉及非常大量的IoT设备。相应地，在本文中讨论的技术的情境中，用于此类未来联网的大量创新将解决所有这些层无障碍地增长、发现并制造能访问的经连接资源以及支持隐藏并分隔经连接资源的能力的需求。可使用任何数量的网络协议和通信标准，其中，每种协议和标准被设计成解决特定的目标。此外，协议是支持无论地点、时间或空间而进行操作的人类能访问服务的结构的部分。创新包括：服务交付和相关联的基础结构，诸如，硬件和软件；安全增强；以及基于在服务水平和服务交付协议中指定的服务质量(QoS)条款的服务提供。如将理解的那样，使用诸如在图1和图2中介绍的那些IoT设备和网络的IoT设备和网络在包括有线和无线技术的组合的异构连接性网络中呈现出大量新挑战。

图1具体提供可用于包括IoT设备104的大量IoT网络的域拓扑的简化图，其中IoT网络156、158、160、162通过主干链路102耦合至相应的网关154。例如，大量IoT设备104可与网关154通信，并且可通过网关154彼此通信。为了简化该图，不是每个IoT设备104或通信链路(例如，链路116、122、128或132)都被标记。主干链路102可包括任何数量的有线或无线技术(包括光学网络)，并且可以是局域网(LAN)、广域网(WAN)或因特网的部分。另外，此类通信链路促进IoT设备104与网关154两者之间的光学信号路径，包括使用促进各种设备的互连的复用/解复用组件。

网络拓扑可包括任何多种类型的IoT网络，诸如，利用网络156使用蓝牙低能量(BLE)链路122而提供的网状网络。可能存在的其他类型的IoT网络包括：用于通过IEEE802.11

链路128与IoT设备104通信的无线局域网(WLAN)网络158；用于通过LTE/LTE-A(4G)或5G蜂窝网络与IoT设备104通信的蜂窝网络160；以及低功率广域(LPWA)网络162，例如，与由LoRa联盟颁布的LoRaWan规范兼容的LPWA网络；或低功率广域网(LPWAN)网络上的IPv6，其与由互联网工程任务组(IETF)颁布的规范兼容。进一步地，各个IoT网络可使用任何数量的通信链路与外部网络提供商(例如，层2或层3提供商)通信，这些通信链路诸如，LTE蜂窝链路、LPWA链路、或基于IEEE 802.15.4标准的链路(诸如，

)。各个IoT网络也可伴随着各种网络和网际应用协议(诸如，受约束的应用协议(CoAP))的使用来操作。各个IoT网络还可与协调器设备集成，这些协调器设备提供链路链，该链路链形成经链接的设备和网络的集群树(cluster tree)。

这些IoT网络中的每一个IoT网络可为新技术特征(诸如，如本文中所描述的那些技术特征)提供机会。改善的技术和网络可实现设备和网络的指数式增长，包括将IoT网络用到“雾(fog)”设备或系统中。随着此类改善技术的使用增长，可在无需直接的人类干预的情况下开发IoT网络以实现自管理、功能进化和协同。改善的技术甚至可使IoT网络能够在没有集中式受控的系统的情况下运作。相应地，本文中描述的改善的技术可用于远超当前实现方式地使网络管理和操作功能自动化并增强网络管理和操作功能。

在示例中，IoT设备104之间的(诸如，骨干链路102上的)通信可受分散化系统保护以进行认证、授权和记账(AAA)。在分散化AAA系统中，可跨互连的异构网络基础结构实现分布式支付、信贷、审计、授权和认证系统。这允许系统和网络迈向自主操作。在这些类型的自主操作中，机器甚至可订立人力资源合约，并且与其他机器网络商议伙伴关系。这可允许针对概括的计划服务水平协议实现共同目标和均衡的服务交付，并且实现提供计量、测量、可追溯性和可跟踪性的解决方案。新供应链结构和方法的产生可在没有任何人类参与的情况下使大量服务能够被产生，被挖掘价值以及坍塌。

此类IoT网络可进一步通过将感测技术(诸如，声、光、电子通信量、面部和模式识别、嗅觉、或振动)集成到IoT设备之间的自主组织中而进一步被增强。对传感系统的集成可允许对于针对合同服务目标、基于编排和QoS的分群以及资源融合的服务交付的系统性和自主的通信和协调。基于网络的资源处理的单独的示例包括以下示例。

网状网络156例如可由执行串联式数据-信息变换的系统来增强。例如，包括多链路网络的处理资源的自形成的链能以高效的方式分布原始数据向信息的变换、在资产和资源之间进行区分的能力以及对每一者的相关联的管理。此外，可插入基于基础结构和资源的恰当组件的信任和服务索引以改善数据完整性、质量、保证，并递送数据置信度的度量。

WLAN网络158例如可使用执行标准转换的系统以提供多标准连接性，从而实现使用不同协议进行通信的IoT设备104。进一步的系统可提供跨多标准基础结构的无缝的互连接性，该多标准基础结构包括可见的因特网资源和隐藏的因特网资源。

蜂窝网络160中的通信例如可由卸载数据的系统、将通信延伸至更远程的设备的系统或卸载数据的系统和将通信延伸至更远程的设备的系统两者来增强。LPWA网络162可包括执行非网际(IP)至IP互连、寻址和路由的系统。进一步地，IoT设备104中的每一个可包括用于与那个设备进行广域通信的适当的收发机。进一步地，每个IoT设备104可包括用于使用附加的协议和频率进行通信的其他收发机。关于图10和图11中所描绘的IoT处理设备的通信环境和硬件进一步讨论了这一点。

在又进一步的示例中，可以利用网络158、网络160、网络162或其他实体来实现网络虚拟化和基于虚拟化/基于软件的功能管理的各方面，包括软件定义的网络(SDN)。例如，SDN可以提供基于软件的可编程网络，该基于软件的可编程网络将控制平面与数据平面分离，以使网络和网络功能更加灵活、敏捷可缩放，并且对网络设备、供应商和服务提供商的依赖性更低。SDN特征的其他用例可能涉及动态网络配置、监视以及虚拟化和动态系统中网络功能的抽象，以获得冗余、控制、和改善的性能。

最终，可装备IoT设备的集群以与其他IoT设备以及与云网络通信。这可允许IoT设备在多个设备之间形成自组织(ad-hoc)网络，从而允许它们充当可被称为雾设备、雾平台或雾网络的单个设备。下面进一步参考图2来讨论该配置。

图2图示了与在联网的场景中作为雾平台操作的IoT设备(设备202)的网状网络进行通信的云计算网络。IoT设备的网状网络可被称为雾网络220，该雾网络220从在云200的边缘处操作的设备的网络建立。为了简化该图，没有对每个IoT设备202进行标记。

雾网络220可被认为是大规模地互连的网络，其中数个IoT设备202例如通过无线电链路222与彼此进行通信。雾网络220可以建立可被视为位于IoT边缘设备与云或数据中心之间的水平资源平台、物理资源平台、或虚拟资源平台。在一些示例中，雾网络可以通过分层计算、联合计算、或分布式计算、存储、和网络连接操作来支持垂直隔离的、对等待时间敏感的应用。然而，雾网络也可以用于在边缘和云处以及边缘和云之间分发资源和服务。因此，在本文档中对“边缘”、“雾”、和“云”的引用不一定是离散的或彼此排他性的。

作为示例，该雾网络220可使用由开放连接性基金会^TM(OCF)发布的互连规范来促进。该标准允许设备发现彼此并建立通信以用于互连。也可使用其他互连协议，包括例如，最优链路状态路由(OLSR)协议、或至移动自组织联网的更好方式(B.A.T.M.A.N)路由协议、或OMA轻量型M2M(LWM2M)协议，等等。

尽管在本示例中展示三种类型的IoT设备202：网关204、数据聚合器226、以及传感器228，但可以使用IoT设备202和功能的任何组合。网关204可以是提供云200与雾网络220之间的通信的边缘设备，并且还可为从传感器228获得的数据(诸如，运动数据、流数据、温度数据等)提供后端处理功能。数据聚合器226可从任何数量的传感器228收集数据，并执行后端处理功能以用于分析。结果、原始数据或这两者可通过网关204传递至云200。传感器228可以是例如能够既收集数据又处理数据的完整的IoT设备202。在一些情况下，传感器228在功能上可能更受限制，例如收集数据并允许数据聚合器226或网关204处理该数据。

来自任何IoT设备202的通信可以沿着IoT设备202中的任何设备之间的方便路径(例如，最方便的路径)传递以到达网关204。在这些网络中，互连的数目提供了大量冗余，这允许即使在损失数个IoT设备202的情况下也维持通信。此外，网状网络的使用可允许使用功率非常低或位于距基础结构一定距离的IoT设备202，因为连接到另一个IoT设备202的范围可能比连接到网关204的范围小得多。

从这些IoT设备202提供的雾网络220可以被呈现给云200中的设备(诸如，服务器206)作为位于云200的边缘处的单个设备，例如，作为设备或平台操作的雾网络。在该示例中，来自雾平台的警报可以被发送而不被识别为来自雾网络220内的特定IoT设备202。以此方式，雾网络220可被视为分布式平台，该分布式平台提供计算和存储资源以执行处理或数据密集型任务(诸如，数据分析、数据聚合和机器学习，等等)。

在一些示例中，可以使用命令性编程风格来配置IoT设备202，例如，每个IoT设备202具有特定功能和通信伙伴。然而，形成雾设备的IoT设备202能以声明性编程风格配置，从而允许IoT设备202重新配置它们的操作和通信，诸如，响应于条件、查询和设备故障来确定所需的资源。作为示例，来自位于服务器206处的用户关于由IoT设备202监测的装备子集的操作的查询可以导致雾网络220设备选择回答该查询所需的IoT设备202，诸如，特定的传感器228。随后，在由雾网络220设备继续发送到服务器206以回答该查询之前，可以通过传感器228、数据聚合器226、或网关204的任何组合来聚合并分析来自这些传感器228的数据。在该示例中，雾网络220中的IoT设备202可以基于查询来选择使用的传感器228，诸如添加来自流量传感器或温度传感器的数据。进一步地，如果IoT设备202中的一些不可操作，则雾网络220中的其他IoT设备202可以提供类似的数据(如果可用的话)。

在OCF架构中，现实物理世界中的实体(例如，温度传感器)被表示为资源。与实体的交互(例如RESTful交互)是通过资源表示实现的，资源表示使用遵循表示状态传输(REST)架构的操作。由此，实体作为资源被公开，每个实体都具有其唯一标识符(URI)和支持接口，这些接口实现其资源上的RESTful操作。客户端发起服务器上的RESTful操作。客户端是发起者，服务器是响应者。任何设备都可以充当客户端来发起RESTful操作，或者任何其他设备都可以充当服务器。因此，在许多情况下，设备作为客户端或服务器的角色可以互换。根据定义，公开资源的任何设备都是服务器。每个RESTful操作均包含理解操作上下文所需的所有信息，并由通用操作(例如创建(CREATE)、检取(RETRIEVE)、更新(UPDATE)、删除(DELETE)和通知(NOTIFY)(CRUDN))的集合支持。

如本文中所讨论，可结合使用各种OCF服务(包括DOTS(也称为DOXS，设备所有者转移服务))来实现以下技术。在进一步的示例中，可以结合装载工具(OBT)来实现以下技术。在OCF实现的上下文中，OBT是可为特定设备建立所有权并帮助使该设备在该网络内进入操作状态的特定的IoT网络中的逻辑实体。例如，典型的OBT可以实现DOXS、AMS(访问管理服务)、和CMS(凭证管理服务)功能。

在OCF规范的一些实现方式中，可以利用公钥基础设施(PKI)组件，该公钥基础设施(PKI)组件要求OCF设备和服务从通用根CA(例如，由OCF或另一个受信任的组织拥有/操作的CA)。此类PKI方法可能会对硬件供应商引入不期望的安全问题和操作问题。例如，如果OCF根CA密钥被损坏，则可能导致硬件供应商或制造商不得不召回OCF兼容的产品。以下技术和配置在OCF IoT部署的上下文中可用，以在此PKI方法的上下文中提供安全性。

利用以下技术，在OCF建立用于安全操作的通用OCF根CA基础设施的情况下，OCF设备的供应商可以将OCF信任锚嵌入他们制造的平台中，并获得嵌入式制造密钥的制造商证书。OCF PKI方法的目标之一是将OCF合规性扩展包括在证书中。这可以用于确保签名的合规性声明不容易被伪造；此类合规性扩展也可以由装载工具验证，并且可以被标准化/可互操作。这些目标可以通过使用当前描述的平台配置来维持。

如以下讨论中所使用，OCF设备是指OCF定义的功能的逻辑表示；平台是指用于托管OCF设备的环境。因此，尽管当前的OCF规范可能未明确或完全定义“平台”，但对受信任平台和安全配置文件的以下使用为附加的安全定义和验证提供了可能性。

具有当前的和提出的OCF设备的PKI实现方式(或类似IoT设备部署)的安全挑战中的一些包括：

a)OCF设备是软件(不是受信任硬件平台)。OCF合规性声明未指定平台环境；并且作为结果，较不可信的平台可能会托管相同的OCF设备软件。作为安全后果，较不可信的OCF设备看来同样可信。

b)多个OCF设备可以由同一平台托管。结果，装载工具将观察到用于多个装载事件的制造密钥的重新使用。使用同一制造密钥装载多个设备是攻击签名。作为安全后果，装载工具具有冲突的(可解释的)要求。

c)非OCF功能可以由托管OCF设备的平台托管，并且制造证书必须用于OCF功能和非OCF功能两者。不同的生态系统应就平台信任属性达成一致。作为安全后果，迷惑的代表(deputy)可能会利用误解的信任语义。

为了解决这些安全顾虑，本技术和配置引入了托管可互操作的受信任平台中的OCF设备。作为一个示例，受信任计算组(TCG)以下列形式定义可互操作的受信任平台的规范：(a)TPM–利用制造密钥嵌入、存储、使用(也称为“证明”)和信任；(b)受信任微控制器单元(MCU)–适用于MCU环境的受信任特征；(c)证明协议–对网络对等方的可信度证明；(d)受信任平台与软件的绑定；以及(e)可扩展的证书配置文件：(例如，TPM(也称为认可密钥)凭证–制造密钥与TPM或T-MCU的绑定、平台属性凭证–TPM/T-MCU与平台的绑定、或捕获信任的证书扩展和质量属性)。

TCG规范已被业界广泛采用。例如，主要的计算机ODM、OEM、OSV、和ISV递送了TCG合规性的产品、和由许多现有CA发布的TCG凭证。多种开源软件实现方式可用。利用当前描述的配置，OCF部署可以适于与符合TCG的合规性平台相互操作。

图3图示根据示例的受信任平台300上托管的OCF设备的配置和操作。在该示例中，平台330可以包括(例如，由平台属性证书实例中的TCG特征(诸如TPM、T-MCU)实现的)TCG平台凭证334、与到合规性文档342的链接。如所示，平台330可操作以确定各个证书的有效性，并使装载工具310能够继续使用有效的设备证书。此外，在示例中，对于每个OCF设备(332)实例，可存在对应的平台证书334，其中第一平台凭证可以引用第一OCF设备文档(例如，第一文档342)，并且第二平台凭证可以引用第二OCF设备文档(例如，第二文档)。两个平台证书可以引用同一认可密钥证书336(EK证书)。

如所示，平台330的TCG平台凭证334链接到许多平台特性，诸如标识符、配置、数据值、和安全声明。这些特性进而链接到从组织网站340(诸如OCF网站)提供的文档342。诸如设备供应商、设备类型、和合规性状态之类的信息被维持在签名文档344中。该签名文档344由受信任组织(诸如OCF)签名。同样如所示，诸如安全声明之类的信息可以在签名文档344的合规性状态中提供；平台配置信息也可以在签名文档344中提供。

相对于通用根CA，在平台330内操作的TCG“验证器”不是高度受约束的。相反，即使平台所有者出于其他原因已经管理了平台，TCG特征(例如，TPM、T-MCU)也可以用于评估平台和认可密钥凭证、信任声明、质量声明。另外，与其他信任属性相比，TCG CA的信任锚列表很小。

在此配置中，装载工具310也不是“高度受约束的”。相反，装载工具310针对各个设备实现所有定义的所有者转移方法322(例如，如OCF规范中所定义)、维持平台330的“拥有的”列表314和受信任的OCF设备332、向新设备供应324本地凭证(例如，通过使用本地CA312)和ACL、管理OCF设备生命周期的许多方面、以及可以甚至由多个根CA认证。

利用图3的配置，信任锚供应对于IoT设备部署是可行的，因为可以通过使用IETF信任锚管理协议(RFC 5934)来实现。信任锚供应将OCF认可的信任锚保持为最新；OCF规范还可以定义其他有意义的默认值。另外，OCF设备332可以将多个根存储在安全的读写存储器中。平台供应商可以嵌入此类信息，如果他们选择。

除了图3中描绘的操作之外，可以利用各个操作顺序来实现设备一致性、平台一致性、受信任的引导、受信任/经证明的装载、以及设备操作，如以下流程图所讨论。

图4图示了用于在受信任平台中使用设备的设备一致性的示例过程的流程图。具体地，在图4的示例中，此过程描述了供应商必须执行的步骤，以便为受信任平台上托管的设备创建“质量声明”。评估实验室可以对评估结果进行签名，并且可以拥有以与本发明可能引用的任何其他CA不同的CA为根的签名密钥/证书路径。

给定在受信任平台上运行的OCF设备软件(如以下所讨论的由图5所定义)，设备一致性评估测试实验室可以标识IoT设备所遵循的“安全配置文件”。

在示例中，用于设备一致性的过程(例如，如图4所描绘)可以包括：

操作410：IoT设备定义文件和软件被加载在受信任平台(诸如，TCG定义的平台)上。

操作420：IoT设备和平台连接到一致性测试设施和测试套件，该测试套件评估对验证套件的一致性和合规性。此类设施和测试套件称为评估实验室。

操作430：评估实验室构建电子文档(例如JSON、XML、HTML、ASN.1等)，这些电子文档包含合规性结果并标识设备和平台的属性。(这些不需要标识实例，而是标识类型或模型)。

操作440：评估实验室使用数字签名和签名文件(诸如证书(例如RFC5280)、属性证书(例如RFC3281)、签名文档(例如，RFC8152、受约束的RESTful环境的对象安全性(OSCORE)互联网草案、RFC5652)、或清单对评估结果进行数字签名。

操作450：评估实验室结果被发布(例如，公布到网站、发布到证书中和/或贡献给公共区块链)。

操作460：可以发布评估实验室公共签名密钥(如在操作450中所执行)，或将其存储在由信任锚终止的证书链中。

图5图示用于使用受信任平台的平台一致性的示例过程的流程图。具体而言，在图5的示例中，该过程描述了平台供应商为了在平台配置中建立信任所遵循的操作(大部分由TCG建立)。此类平台配置可以包括受信任平台模块(TPM)或受信任MCU(TMCU)，其中TPM/TMCU具有制造商嵌入式密钥，也称为“EK”。TPM/TMCU供应商可以获得以与任何其他CA不同的CA为根的EK证书/证书路径。平台属性证书(PAC)可以由受信任的平台供应商发布，并且可以具有以与任何其他CA不同的CA为根的证书路径。

在示例中，用于平台一致性的过程(例如，如图5所描绘)可以包括：

操作510：受信任平台(诸如TCG定义的平台)由平台供应商、评估实验室(例如，通用标准)、或其他安全评估组织或实体进行评估。

操作520：平台供应商构造平台属性凭证(诸如TCG PAC)，该平台属性凭证包含平台配置引用(例如，硬件组件(例如，供应商、模型、和版本)的URI、软件组件(例如，供应商、模型、版本)、和平台质量保证引用(例如，托管公共文档的评估实验室/描述使用哪种受信任的平台定义评估了哪些软件的签名文档的URI))。

操作530：平台供应商使用公开了公钥的密钥对来对PAC进行签名(如先前操作中所讨论)。

操作540：可以发布评估实验室公共签名密钥(如在操作530中所执行)，或将其包含在由信任锚终止的证书链中。

图6图示用于受信任平台中的设备的示例受信任引导顺序的流程图。具体而言，图6的流程图示出了“受信任引导”顺序(这是行业术语)，该顺序示出了引导过程，该引导过程包括可以加载OCF设备软件640和配置文件的IoT设备加载器630。该过程可以在将执行传递到软件入口点之前测量(到一个或多个平台配置寄存器(PCR)的)软件和配置文件。进一步地，该过程可针对每个相应阶段测量到PCR。

在示例中，用于受信任的引导顺序(例如，如图6所示)的过程可以包括启动IoT引导加载器、IoT平台系统软件加载器、和IoT设备软件加载器的迭代过程、以及加载器和此类软件编码到相应平台配置寄存器(PCR)的测量。如所示，受信任的引导顺序可以开始于IoT固件(引导)加载器610，该IoT固件(引导)加载器610用于加载(1)IoT平台固件和系统软件加载器660。这随后是到IoT平台系统软件加载器620的执行流程(2)，该IoT平台系统软件加载器620用于加载(3)IoT平台系统软件和设备软件加载器650。这随后是到IoT设备软件加载器630的执行流程(4)，该IoT设备软件加载器630加载(5)IoT设备软件640并将执行传递到该软件的入口点。执行流程(6)利用IoT设备软件640继续进行。

如图6的示例所示，组成受信任平台的各个组件及受信任平台托管的IoT设备相互“绑定”。此处的绑定以IoT设备软件640的受信任加载的形式证明。在一些受约束的环境中，可能只存在一个由固件、系统软件、和设备软件组成的混合映像。这将受信任的引导顺序合并成更少的操作，但是(多个)PCR仍然包含受信任的和经证明的装载所需的测量(如下文参考图7所讨论)。

图7图示用于受信任平台中的设备的受信任或经证明的设备装载的示例过程的流程图。具体而言，图7中描绘的过程示出涉及希望被装载的新设备的OBT装载步骤，该希望被装载的新设备具有以被设备一致性过程声明为有效的一个或多个安全配置文件进行操作的权利(例如，如上文所讨论的如图4所描绘)。

在示例中，用于受信任或经证明的设备装载的过程(例如，如图7所描绘)可以包括：

操作705：受信任平台执行安全或受信任引导，该安全或受信任引导在其被加载时测量平台固件、系统软件和IoT设备软件。

操作710：IoT网络装载工具(OBT)连接到IoT平台并请求证明证据。

操作715：受信任平台使用平台嵌入式制造密钥(例如，TPM EK或AIK)和PAC证书对PCR中的引导/加载测量进行签名。

操作720：OBT验证PCR和PAC，包括到由网络所有者供应的信任锚的证书路径。这包括对制造(mfg)密钥的验证(该密钥可能遵循单独的证书路径)。

操作725：OBT使用PAC中的URI链接获得可用的签名文档；并验证文档签名和链(其可以遵循单独的证书路径)。

操作730：OBT使用PAC中的URI链接获得可用的签名文档；并验证文档签名和链(其可以遵循单独的证书路径)。

操作735：OBT获得网络所有者的信任锚，该信任锚终止每个证书链(所有者通过从任何公共资源中进行读取并评估公钥的合法性来完成此过程)。

操作740：OBT验证IoT设备评估实验室分配给评估结果的IoT设备安全配置文件。

操作745：OBT从设备支持的配置文件中选择安全配置文件，并使用OBT所选择的配置文件来设置(配置)设备以进行操作。

操作750：OBT发布授权设备以根据一个或多个受支持的安全配置文件进行操作的本地凭证或角色。

操作755：OBT更新指示其在设备引导时转变到哪个安全配置文件的设备资源。

操作760：OBT或设备关闭连接。

图8图示了用于受信任平台中的设备的示例设备到设备操作的流程图。具体而言，图8中所描绘的过程示出了其中IoT客户端请求访问由IoT服务器托管的资源的场景，其中该资源仅在服务器在特定安全配置文件下操作的情况下才可访问。

在此场景中，客户端供应(由OBT或本地CA发布的)凭证，该凭证授权客户端在特定的安全配置文件下操作。服务器试图转变到预期的安全配置文件，并尝试满足请求。本地OBT/CA可以发布本地证书或角色证书，其中证书路径可以由CA终止，其他任何图都不能用来终止该路径。OBT和(多个)IoT服务器使用网络所有者供应的“信任锚策略”，该策略用于终止在装载操作和设备到设备操作期间使用的各种证书链。

在示例中，用于受信任或经证明的设备装载的示例过程可以包括以下顺序：

操作810：IoT客户端请求访问IoT服务器设备；并供应声明安全配置文件的凭证。

操作820：IoT服务器验证IoT客户端凭证和安全配置文件授权。

操作825：进行标识客户端是否在所请求的配置文件下可操作的判定。如果尚未在所请求的配置文件下操作，则在830处进行到所请求的安全配置文件的转变。然后在840处完成该连接。

操作845：进行在当前安全配置文件中显示可用的资源ACL是否是可用的判定。如果这是可用的，则在操作850处，处理客户端请求。

图9图示了用于装载对象设备以与安全配置文件一起使用的示例方法的流程图900。如图所示，从装载工具设备的角度图示了流程图900的操作，该装载工具设备进行操作以将相应的新的(主题)设备装载到设备平台(例如，OCF平台)的使用上。将理解，在一些示例中，这些操作可以分布在多个实体或行为者之间，并且可以使用本文的示例中所讨论的替代安全方法中的任一种来修改此类操作。

流程图900开始于在910处的操作，以接收(例如，在装载工具设备处)执行与设备平台相关联的对象设备的所有者转移方法(例如，作为装载操作的一部分)的请求。这随后在920处具有获得与对象设备相关联的证明证据的操作，以及在930处验证证明证据的操作。在示例中，证明证据由设备平台提供，并且证明证据由使用制造商嵌入式密钥产生的证书签名。进一步地，可以从设备平台的受信任的硬件组件提供制造商嵌入的密钥，因为设备平台操作受信任的硬件并且包括操作和硬件的相关信任证明信息。

流程图900继续进行在940处的操作以(诸如利用从本地证书授权机构发布的本地凭证)供应对象设备。在示例中，本地证书授权机构由装载工具设备操作。同样在示例中，本地凭证指示绑定到制造商嵌入式密钥的安全配置文件的经验证的使用。然后，流程图900继续进行在950处的操作以将对象设备转变为使用指定的安全配置文件。在示例中，这包括将对象设备的资源更新为与安全配置文件相关联的值，使得在设备供应完成时对象设备被转变为使用安全配置文件。在示例中，这还可包括装载工具设备维护设备平台的所拥有和受信任的设备的列表，诸如更新列表以包括对象设备。

流程图900结束于960处的操作，以完成对对象设备的设备供应，因为对象设备被配置为伴随着安全配置文件的使用来操作。最后，利用对象设备(以及在网络平台和任何定义的网络域中)的后续操作可以包括安全配置文件的验证。

在进一步的示例中，根据开放连接基金会(OCF)标准系列的规范来配置和/或操作装载工具设备、设备平台、和/或对象设备。进一步地，根据受信任的计算组(TCG)标准系列的规范来配置和/或操作受信任硬件组件、装载工具设备、以及设备平台和/或对象设备的其他方面。

在进一步的示例中，对象设备执行用于对对象设备操作的设备软件的受信任引导顺序，并且证明证据包括设备平台对受信任引导顺序的验证。同样在进一步的示例中，制造商嵌入式密钥与信任锚相关联，使得通过使用信任锚管理协议来管理信任锚。同样在进一步的示例中，制造商嵌入式密钥被链接到证书链，并且证书链由信任锚终止，使得证明证据包括信任锚。同样在进一步的示例中，制造商嵌入式密钥与设备平台的平台属性凭证相关联，并且平台属性凭证包括在第三方数据源上可公开验证的平台信息。在又进一步的示例中，验证可以包括查询区块链以确认链接到制造商嵌入式密钥的信任锚，或者查询区块链以搜索针对链接到制造商嵌入式密钥的信任锚的信任锚撤销。信任锚撤销的标识可能导致对象设备使用另一个安全配置文件。

在特定示例中，本文所讨论的技术可以在OCF部署中作为(例如，设备装载期间的)安全配置文件分配的一部分来实现。OCF设备可能根据OCF安全配置文件已被评估。可以从制造商的证书、OCF网络服务器、或其他公共储存库访问评估结果。DOTS审查评估结果以确定OCF设备被授权拥有哪些OCF安全配置文件，并利用最适合网络所有者预期的网络分割策略的评估的安全配置文件的子集来配置设备。以下各段落参考OCF资源和资源性质提供了关于可能的实现方式的其他细节。

在示例中，本文讨论的技术可以被并入被称为“安全配置文件蓝色(SecurityProfile Blue)”的安全配置文件中。“安全配置文件蓝色”在制造商为包含制造商嵌入式密钥的平台发布平台证书时使用。使用受信任计算组(TCG)定义的证书扩展来预期与可互操作的受信任平台的兼容性。网络所有者评估制造商供应的证书和属性数据，以确定在装载时为OCF设备配置的适当的OCF安全配置文件。OCF设备可以满足多个OCF安全配置文件。网络所有者可以使用安全配置文件作为网络分区标准来配置网络部署。

OCF“安全配置文件蓝色”预期了生态系统，其中平台供应商可以不同于OCF设备供应商，并且其中平台供应商可以实现受信任的平台，该受信任的平台可符合定义受信任平台的行业标准。OCF安全配置文件蓝色指定了用于将平台与(多个)OCF设备链接以及用于引用由OCF一致性操作产生的质量保证标准的机制。当OCF设备被装载到网络中时，网络所有者评估这些数据。基于该评估，网络所有者确定在OCF设备操作期间应该应用哪个安全配置文件。可以考虑使用OCF安全配置文件蓝色评估所有OCF设备类型。

在示例中，OCF安全配置文件蓝色定义了以下质量保证：OCF一致性标准应要求供应商证明一致的OCF设备被托管在满足OCF安全配置文件蓝色安全保证以及安全性和隐私功能要求的一个或多个平台上。在示例中，OCF安全配置文件蓝色将质量保证功能定义为：将OCF一致性测试和安全配置文件合规性的结果发布到OCF网站；并且OCF一致性测试和安全配置文件合规性的结果由OCF拥有的签名密钥进行数字签名。

在示例中，OCF安全配置文件蓝色定义以下各项的质量保证：应该以最低FIPS140-2级别1或通用标准EAL级别1评估实现加密服务提供商功能和安全存储功能的平台。应该以最低的通用标准EAL级别1评估实现受信任平台功能的平台。

在示例中，OCF安全配置文件蓝色定义了以下各项安全性和隐私功能：(多个)OCF设备应使用加密服务提供商(CSP)使用的加密算法。CSP功能应包括加密算法、随机数生成、安全时间。(多个)OCF设备应使用安全存储提供商以用于加密密钥存储。(多个)OCF设备应对所传送的数据使用AES128等效的最低保护，并应使用平台托管的CSP以获得加密算法功能。(多个)OCF设备应对所存储的数据使用AES128等效的最低保护，并应使用平台托管的安全密钥存储功能。(多个)OCF设备应使用平台安全存储提供商保护/oic/sec/cred资源。(多个)OCF设备应使用平台安全存储功能来保护信任锚(也称为定义受信任CA和固定证书的策略)。OCF装载(又称为DOTS)应使用网络所有者授权的信任锚终止制造商证书的证书路径验证。OCF装载(也称为DOTS)应检查制造商证书路径中所有证书的证书撤销状态。(多个)OCF设备应检查证书撤销状态以获得本地颁发的证书。

在示例中，OCF安全配置文件蓝色定义了针对平台的安全性和隐私功能。托管(多个)OCF设备的平台应遵循IEEE802.1AR或TCG受信任平台模块(TPM)规范来实现平台标识符。托管(多个)OCF设备的平台可以实现TCG定义的受信任平台安全声明扩展：

tBBSecurityAssertions ATTRIBUTE::＝{

WITH SYNTAX TBBSecurityAssertions

ID tcg—at-tbbSecurityAssertions

}

托管(多个)OCF设备的平台可以实施TCG定义的平台配置声明扩展：

platformConfiguration ATTRIBUTE::＝{

WITH SYNTAX PlatformConfiguration

ID tcg-at-platformConfiguration-v1

}

在示例中，OCF设备供应商将/oic/sec/sp资源的受支持的_配置文件(supported_profiles)属性和活动的_配置文件(active_profile)属性的制造商默认值设置为“oic.sec.sp.unspecified”。当设备转变到“重置设备状态(RESET Device State)”时，默认值被重新声明。当设备处于以下设备状态中的一者时：RFOTM、RFPRO、SRESET，OCF设备允许/oic/sec/sp_update资源排他地更新。

在示例中，DOTS利用由设备作为OCF一致性测试的一部分获得的OCF安全配置文件值的子集来更新/oic/sec/sp_update资源的supported_profiles属性。DOTS可以通过检查由OCF设备通过选择“credusage”属性值为“oic.sec.cred.mfgcert”的凭证来供应的制造商证书来定位一致性结果。DOTS可以进一步通过访问与平台、OCF设备类型以及相应的平台和OCF设备供应商相对应的公知的OCF网站URI来定位一致性结果。DOTS可以基于本地策略来(从通过OCF一致性测试评估的那些安全配置文件中)选择安全配置文件的子集。

在示例中，DOTS利用最正确地描绘网络所有者的预期网络分段策略的值来更新/oic/sec/sp_update资源的当前_配置文件(current_profile)属性。CMS可以使用安全配置文件值(例如“oic.sec.sp.blue”)发布角色凭证，以指示网络所有者的意图以根据安全配置文件对网络进行分割。CMS在发布角色凭证时检索/oic/sec/sp资源的supported_profiles属性，以选择与设备的受支持安全配置文件相符的角色名称。如果CMS基于安全配置文件来发布角色凭证，则AMS应该供应包括(多个)角色指定的访问控制条目。

同样在示例中，OCF设备使用oic.sec.sp资源以显示网络所有者授权哪些OCF安全配置文件以及当前正在运行哪些OCF安全配置文件。可以通过oic.sec.sp资源和oic.sec.sp_update资源的属性来提供安全配置文件资源定义。例如，安全配置文件资源定义可以通过/oic/sec/sp资源的oic.sec.sp属性的值(在R和RW访问模式中)来提供，该安全配置文件资源定义指示一组受支持的安全配置文件、以及当前活动的安全配置文件。

也可能发生前述平台、安全性和隐私功能、认证要求、安全配置文件以及OCF规范或其他IoT网络部署中的实现方式的变体。

在各个示例中，以上参考图3至图9描述的操作和功能可以由示例形式为电子处理系统的IoT设备机器来体现，根据示例实施例，在该电子处理系统中可以执行指令集或指令序列以使得该电子处理系统执行本文讨论的方法中的任何一种。所述机器可以是IoT设备或IoT网关，包括由个人计算机(PC)、平板PC、个人数字助理(PDA)、移动电话或智能手机、或能够(相继或以其他方式)执行指定要由该机器要采取的动作的指令的任何机器的各方面所体现的机器。

进一步地，虽然在以上的示例中只描述和引用单个机器，但是此类机器也应该被视为包括单独地或联合地执行一组(或多组)指令以执行此处所讨论的方法中的任何一个或多个的机器的任何集合。进一步地，这些示例和与基于处理器的系统类似的示例应被视为包括由处理器、处理器的集合、或处理电路(例如，以计算机形式的机器、IoT处理设备等)控制或操作、以单独地或联合地执行指令来执行在此所讨论的方法论中的任何一种或多种的一个或多个机器的任何集合。因此，在各个示例中，用于处理(例如，处理、控制、生成、评估等)的适用装置可以通过此类处理电路来具体化。

图10图示云计算网络或与数个物联网(IoT)设备通信的云1000的图。云1000可表示因特网，或者可以是局域网(LAN)、或广域网(WAN)，诸如，用于公司的专属网络。IoT设备可包括按各种组合分组的任何数量的不同类型的设备。例如，交通控制组1006可包括沿城市中的街道的IoT设备。这些IoT设备可包括停车灯、交通流监视器、相机、天气传感器，等等。交通控制组1006或其他子组可通过有线或无线链路1000(诸如LPWA链路、光学链路，等等)与云1008通信。进一步地，有线或无线子网1012可允许IoT设备诸如通过局域网、无线局域网等等来彼此通信。IoT设备可使用另一设备(诸如网关1010或1028)来与远程位置(诸如云1000)通信；IoT设备也可使用一个或多个服务器1030来促进与云1000或与网关1010的通信。例如，一个或多个服务器1030可充当中间网络节点以支持在局域网之间的局部边缘云或雾实现。而且，所描绘的网关1028可在诸如具有各种IoT设备1014、1020、1024的云-网关-许多边缘设备配置中操作，各种IoT设备1014、1020、1024对于云1000中的资源的分配和使用是受约束的或动态的。

IoT设备的其他示例组可包括远程气象站1014、本地信息终端1016、警报系统1018、自动化柜员机1020、警报面板1022或移动车辆(诸如，应急车辆1024或其他车辆1026)，等等。这些IoT设备中的每一个可与其他IoT设备、与服务器1004、与另一IoT雾设备或系统(未示出但在图2中描绘)、或与其中的组合通信。这些IoT设备的组可部署在各种住宅、商业和工业设定(包括私有环境或公共环境两者)中。

如从图10可见，数个IoT设备可通过云1000进行通信。这可允许不同的IoT设备自主地请求信息或将信息提供给其他设备。例如，IoT设备的组(例如，交通控制组1006)可从可在没有人类干预的情况下提供预报的远程气象站的组1014请求当前的天气预报。进一步地，可由自动化柜员机1020向应急车辆1024警告盗窃在进行中。当应急车辆1024朝自动化柜员机1020行进时，它可访问交通控制组1006以请求清空该位置，例如，通过在足够的时间内亮起红灯以阻止交叉路口处的交叉交通流，以使应急车辆1024能够畅通无阻地进入该交叉路口。

IoT设备的集群(诸如，远程气象站1014或交通控制组1006)以与其他IoT设备以及与云1000进行通信。这可允许IoT设备在多个设备之间形成自组织网络，从而允许它们充当单个设备，该单个设备可被称为雾设备或系统(例如，如上文中参照图2所描述)。

图11是可存在于IoT设备1150中用于实现本文中描述的技术的组件的示例的框图。IoT设备1150可包括在上文公开内容中的示例中示出或在上文公开内容中引用的组件的任何组合。这些组件可被实现为IC、IC的部分、分立电子器件，或其他模块、逻辑、硬件、软件、固件或其适用于IoT设备1150中的组合，或作为以其他方式被并入在更大的系统的机架内的组件。另外，图11的框图旨在描绘IoT设备1150的组件的高级视图。然而，可省略所示出的组件中的一些组件，可存在附加的组件，并且所示出的组件的不同布置可在其他实现方式中发生。

IoT设备1150可包括处理器1152形式的处理电路，该处理电路可以是微处理器、多核处理器、多线程处理器、超低电压处理器、嵌入式处理器，或其他已知的处理元件。处理器1152可以是芯片上系统(SoC)的部分，在该SoC中，处理器1152和其他组件被形成到单个集成电路或单个封装中，诸如，来自英特尔的爱迪生^TM(Edison^TM)或伽利略^TM(Galileo^TM)SoC板。作为示例，处理器1152可包括基于

架构酷睿^TM(Core^TM)的处理器(诸如，Quark^TM、Atom^TM、i3、i5、i7或MCU类处理器)、或可从加利福尼亚州圣克拉拉市的

公司获得的另一此类处理器。然而，可使用任何数量的其他处理器，诸如，可从加利福尼亚州桑尼威尔市的超微半导体公司(AMD)获得的处理器、来自加利福尼亚州桑尼威尔市的MIPS技术公司的基于MIPS的设计、许可自ARM控股有限公司的基于ARM的设计，或从上述各公司的客户、被许可方或采纳方获得的处理器。处理器可包括诸如以下单元：来自

公司的A5-A10处理器、来自高通

技术公司的骁龙^TM(Snapdragon^TM)处理器或来自德州仪器公司的OMAP^TM处理器。

处理器1152可通过互连1156(例如，总线)来与系统存储器1154通信。任何数量的存储器设备可被用来提供给定量的系统存储器。作为示例，存储器可以是根据联合电子器件工程委员会(JEDEC)设计的随机存取存储器(RAM)，诸如，DDR或移动DDR标准(例如，LPDDR、LPDDR2、LPDDR3或LPDDR4)。在各种实现方式中，单独的存储器设备可以是任何数量的不同封装类型，诸如单管芯封装(SDP)、双管芯封装(DDP)或四管芯封装(Q17P)。在一些示例中，这些设备可以直接焊接到主板上，以提供较低轮廓的解决方案，而在其他示例中，设备被配置为一个或多个存储器模块，这些存储器模块进而通过给定的连接器耦合到主板。可使用任何数量的其他存储器实现方式，诸如，其他类型的存储器模块，例如，不同种类的双列直插存储器模块(DIMM)，包括但不限于microDIMM(微DIMM)或MiniDIMM(迷你DIMM)。

为了提供对信息(诸如，数据、应用、操作系统等)的持久性存储，存储1158可经由互连1156而耦合至处理器1152。在示例中，存储1158可经由固态盘驱动器(SSDD)来实现。可用于存储1158的其他设备包括闪存卡(诸如，SD卡、microSD卡、xD图片卡，等等)和USB闪存驱动器。在低功率实现中，存储1158可以是与处理器1152相关联的管芯上存储器或寄存器。然而，在一些示例中，存储1158可使用微硬盘驱动器(HDD)来实现。进一步，附加于或替代所描述的技术，可将任何数量的新技术用于存储1158，诸如，阻变存储器、相变存储器、全息存储器或化学存储器，等等。

组件可通过互连1156进行通信。互连1156可包括任何数量的技术，包括工业标准架构(ISA)、扩展ISA(EISA)、外围组件互联(PCI)、外围组件互联扩展(PCIx)、PCI快速(PCIe)或任何数量的其他技术。互连1156可以是例如在基于SoC的系统中使用的专属总线。其他总线系统可被包括，诸如I2C接口、SPI接口、点对点接口、功率总线，等等。

互连1156可将处理器1152耦合至网状收发机1162，以便例如与其他网状设备1164通信。网状收发机1162可使用任何数量的频率和协议，诸如，IEEE 802.15.4标准下的2.4千兆赫兹(GHz)传输，使用如由

特别兴趣小组定义的

低能量(BLE)标准、或

标准，等等。为特定的无线通信协议配置的任何数量的无线电可用于到网状设备1164的连接。例如，WLAN单元可用于根据电气和电子工程师协会(IEEE)802.11标准实现Wi-Fi^TM通信。另外，例如根据蜂窝或其他无线广域协议的无线广域通信可经由WWAN单元发生。

网状收发机1162可使用用于不同范围的通信的多种标准或无线电来进行通信。例如，IoT设备1150可使用基于BLE的或另一低功率无线电的本地收发机与接近的(例如，在约11米内的)设备通信以节省功率。更远的(例如，在约50米内的)网状设备1164可通过ZigBee或其他中间功率的无线电而被联络到。这两种通信技术能以不同的功率水平通过单个无线电发生，或者可通过分开的收发机而发生，分开的收发机例如使用BLE的本地收发机以及使用ZigBee的分开的网状收发机。

无线网络收发机1166可被包括，以经由局域网协议或广域网协议来与云1100中的设备或服务通信。无线网络收发机1166可以是遵循IEEE802.15.4或IEEE 802.15.4g标准等的LPWA收发机。IoT设备1150可使用由Semtech和LoRa联盟开发的LoRaWAN^TM(长距离广域网)在广域上通信。本文中所描述的技术不限于这些技术，而使可与实现长距离、低带宽通信(诸如，Sigfox和其他技术)的任何数量的其他云收发机一起使用。进一步地，可使用其他通信技术，诸如，在IEEE 802.15.4e规范中描述的时分信道跳。

除了针对如本文中所述的网状收发机1162和无线网络收发机1166而提及的系统之外，还可使用任何数量的其他无线电通信和协议。例如，无线电收发机1162和1166可包括使用扩展频谱(SPA/SAS)通信以实现高速通信的LTE或其他蜂窝收发机。进一步地，可使用任何数量的其他协议，诸如，用于中速通信和供应网络通信的

网络。

无线电收发机1162和1166可包括与任何数量的3GPP(第三代合作伙伴计划)规范(尤其是长期演进(LTE)、长期演进-高级(LTE-A)和长期演进-高级加强版(LTE-A Pro))兼容的无线电。可以注意到，可选择与任何数量的其他固定的、移动的或卫星通信技术和标准兼容的无线电。这些可包括例如任何蜂窝广域无线通信技术，其可包括例如第5代(5G)通信系统、全球移动通信(GSM)无线电通信系统、通用分组无线电服务(GPRS)无线电通信技术、或GSM演进(EDGE)增强数据速率无线电通信技术、UMTS(通用移动电信系统)通信技术，除了上面列出的标准外，任何数量的卫星上行链路技术都可以用于无线网络收发机1166，包括例如符合由ITU(国际电信联盟)或ETSI(欧洲电信标准协会)发布标准的无线电等。本文中所提供的示例因此可被理解为适用于各种现有的和尚未制定的各种其他通信技术。

网络接口控制器(NIC)1168可被包括以提供到云1100或到其他设备(诸如网状设备1164)的有线通信。有线通信可提供以太网连接，或可基于其他类型的网络，诸如控制器区域网(CAN)、本地互连网(LIN)、设备网络(DeviceNet)、控制网络(ControlNet)、数据高速路+、现场总线(PROFIBUS)或工业以太网(PROFINET)，等等。附加的NIC 1168可被包括以允许到第二网络的连接，例如，NIC 1168通过以太网提供到云的通信，并且第二NIC 1168通过另一类型的网络提供到其他设备的通信。

鉴于从设备到另一组件或网络的适用通信类型的多样性，设备使用的适用通信电路可以包括组件1262、1266、1268或1270中的任何一个或多个或由组件1262、1266、1268或1270中的任何一个或多个来具体化。因此，在各个示例中，用于通信(例如，接收、传送等)的适用装置可由此类通信电路来具体化。

互链路1156可将处理器1152耦合至外部接口1170，该外部接口1170用于连接外部设备或子系统。外部设备可包括传感器1172，诸如加速度计、水平传感器、流量传感器、光学光传感器、相机传感器、温度传感器、全球定位系统(GPS)传感器、压力传感器、气压传感器，等等。外部接口1170可进一步用于将IoT设备1150连接至致动器1174(诸如，电源开关、阀致动器、可听见声音发生器、视觉警告设备等)。

在一些任选的示例中，各种输入/输出(I/O)设备可存在于IoT设备1150内，或可连接至IoT设备1150。例如，显示器或其他输出设备1184可被包括以显示信息，诸如传感器读数或致动器位置。输入设备1186(诸如，触摸屏或键区)可被包括以接受输入。输出设备1184可包括任何数量的音频或视觉显示形式，包括：简单视觉输出，诸如二进制状态指示器(例如，LED)；多字符视觉输出；或更复杂的输出，诸如显示屏(例如，LCD屏)，其具有从IoT设备1150的操作生成或产生的字符、图形、多媒体对象等的输出。

电池1176可为IoT设备1150供电，但是在其中IoT设备1150被安装在固定位置的示例中，该IoT设备1150可具有耦合至电网的电源。电池1176可以是锂离子电池、金属-空气电池(诸如锌-空气电池、铝-空气电池、锂-空气电池)，等等。

电池监视器/充电器1178可被包括在IoT设备1150中以跟踪电池1176的充电状态(SoCh)。电池监视器/充电器1178可用于监视电池1176的其他参数以提供失效预测，诸如电池1176的健康状态(SoH)和功能状态(SoF)。电池监视器/充电器1178可包括电池监视集成电路，诸如来自线性技术公司(Linear Technologies)的LTC4020或LTC2990、来自亚利桑那州的凤凰城的安森美半导体公司(ON Semiconductor)的ADT7488A、或来自德克萨斯州的德州仪器公司的UCD90xxx族的IC。电池监视器/充电器1178可通过互连1156将电池1176上的信息传递至处理器1152。电池监视器/充电器1178也可包括允许处理器1152直接监视电池1176的电压或来自电池1176的电流的模数(ADC)转换器。电池参数可被用于确定IoT设备1150可执行的动作，诸如传输频率、网状网络操作、感测频率，等等。

功率块1180或耦合至电网的其他电源可与电池监视器/充电器1178耦合以对电池1176充电。在一些示例中，功率块1180可用无线功率接收机代替，以便例如通过IoT设备1150中的环形天线来无线地获得功率。无线电池充电电路(诸如来自加利福尼亚州的苗比达市的线性技术公司的LTC4020芯片，等等)可被包括在电池监视器/充电器1178中。所选择的特定的充电电路取决于电池1176的尺寸，并因此取决于所需的电流。可使用由无线充电联盟(Airfuel Alliance)颁布的Airfuel标准、由无线电力协会(Wireless PowerConsortium)颁布的Qi无线充电标准、由无线电力联盟(the Alliance for WirelessPower)颁布的Rezence充电标准等等执行充电。

存储1158可包括用于实现本文中公开的技术的软件、固件或硬件命令形式的指令1182。虽然此类指令1182被示出为被包括在存储器1154和存储1158中的代码块，但是可以理解，可用例如被建立到专用集成电路(ASIC)中的硬连线电路替换代码块中的任一个。

在示例中，经由存储器1154、存储1158或处理器1152提供的指令1182可具体化为非暂态机器可读介质1060，该非暂态机器可读介质1060包括用于指示处理器1052执行IoT设备1150中的电子操作的代码。处理器1152可通过互连1156访问非暂态机器可读介质1160。例如，非暂态机器可读介质1160可由针对图11的存储1158所描述的设备来具体化，并且可包括特定的存储单元，诸如光盘、闪存驱动器或任何数量的其他硬件设备。非暂态机器可读介质1160可包括用于指示处理器1152执行例如像参照上文中描绘的操作和功能的(多个)流程图和(多个)框图而描述的特定的动作顺序或动作流的指令。

在又一特定示例中，处理器1252上的指令1288(单独地或与机器可读介质1260的指令1288结合)可以配置受信任执行环境(TEE)1290的执行或操作。在示例中，TEE 1290作为处理器1252可访问的保护区域来操作，以用于指令的安全执行和对数据的安全访问。例如，可以通过使用

软件防护扩展(SGX)或

硬件安全扩展、

管理引擎(ME)或

融合安全可管理性引擎(CSME)来提供TEE 1290的各种实现方式以及处理器1252或存储器1254中伴随的安全区域。安全强化、硬件信任根、和受信任或受保护操作的其他方面可以通过TEE 1290和处理器1252在设备1250中实现。

在进一步的示例中，机器可读介质也包括任何有形介质，该有形介质能够存储、编码或携带供由机器执行并且使机器执行本公开方法中的任何一种或多种方法的指令，或者该有形介质能够储存、编码或携带由此类指令利用或与此类指令相关联的数据结构。术语“机器可读介质”因此可包括但不限于固态存储器、光学介质和磁介质。机器可读介质的特定示例包括非易失性存储器，作为示例，包括但不限于：半导体存储器设备(例如，电可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)和闪存设备；诸如内部硬盘及可移除盘之类的磁盘；磁光盘；以及CD-ROM和DVD-ROM盘。可使用传输介质，经由网络接口设备，利用数个传输协议中的任何一种协议(例如，HTTP)，进一步通过通信网络来传输或接收由机器可读介质具体化的指令。

应当理解，在本说明书中所描述的功能单元或能力可被称为或标记为组件或模块，从而特别强调其实现的独立性。此类组件可由任何数量的软件或硬件形式具体化。例如，组件或模块可被实现为硬件电路，该硬件电路包括：定制的超大规模集成(VLSI)电路或门阵列，诸如逻辑芯片、晶体管之类的现成的半导体，或其他分立组件。组件或模块也可被实现在可编程硬件器件(诸如现场可编程门阵列、可编程阵列逻辑、可编程逻辑器件等等)中。组件或模块也能以软件来实现，以供由各种类型的处理器执行。可执行代码的所标识的组件或模块可以例如包括计算机指令的一个或多个物理或逻辑块，其例如可被组织成例如对象、过程、或函数。然而，所标识的组件或模块的可执行对象不必在物理上在一起，而是可包括存储在不同位置中的不同指令，当这些指令在逻辑上结合在一起时，包括组件或模块，并且针对该组件或模块实现所声称的目的。

实际上，可执行代码的组件或模块可以是单条指令或许多条指令，并且甚至可以分布在若干不同的代码段上，分布在不同的程序之间，以及跨若干存储器设备或处理系统而分布。具体而言，所描述的过程的一些方面(诸如代码重写和代码分析)可发生在与代码部署在其中的处理系统(例如，在嵌入在传感器或机器人中的计算机中)不同的处理系统(例如，在数据中心中的计算机中)上。类似地，操作数据在此可被标识并图示在组件或模块内，并且能以任何合适的形式被具体化并被组织在在任何合适类型的数据结构内。操作数据可以被收集为单个数据集，或者可分布在不同位置上(包括分布在不同的存储设备上)，并且可以至少部分地仅作为电子信号而存在于系统或网络上。组件或模块可以是无源或有源的，包括用于执行所需功能的代理。

当前所描述的方法、系统和设备实施例的附加示例包括下列非限制性的配置。下列非限制性示例中的每一个示例可以独立存在，或可以与以下所提供的或遍及本公开的其他示例中的一个或更多示例按照任何排列或组合进行结合。

示例1是一种设备，包括：通信电路；处理电路；以及存储器设备，该存储器设备包括存储在其上的指令，其中，该指令由处理电路执行时将处理电路配置成执行以下各项操作，包括：接收用于执行对象设备的所有者转移方法的请求，该对象设备与设备平台相关联；验证与对象设备相关联的证明证据，该证明证据由设备平台提供，其中，证明证据由使用制造商嵌入式密钥产生的证书签名，其中，制造商嵌入式密钥是从设备平台的受信任硬件组件提供的；以及基于证明证据执行对象设备的设备供应，其中，设备供应使对象设备使用与制造商嵌入式密钥绑定的安全配置文件。

在示例2中，示例1的主题包括：维持设备平台的所拥有的和受信任的设备的列表，该列表包括对象设备。

在示例3中，示例1-2的主题包括以下主题，其中，执行设备供应包括进一步的操作，该操作包括：向对象设备供应来自本地证书授权机构的本地凭证，该本地证书授权机构由设备操作，其中本地凭证指示与制造商嵌入式密钥绑定的安全配置文件的经验证的使用。

在示例4中，示例1-3的主题包括以下主题，其中，执行设备供应包括进一步的操作，该操作包括：将对象设备的资源更新为与安全配置文件相关联的值，其中，对象设备在完成设备供应时转变为使用安全配置文件。

在示例5中，示例1-4的主题包括以下主题，其中制造商嵌入式密钥与信任锚相关联，其中通过使用信任锚管理协议来管理信任锚。

在示例6中，示例1-5的主题包括以下主题，其中制造商嵌入式密钥链接到证书链，其中证书链由信任锚终止，并且其中证明证据包括信任锚。

在示例7中，示例1-6的主题包括以下主题，其中制造商嵌入式密钥与设备平台的平台属性凭证相关联，并且其中平台属性凭证包括在第三方数据源上可公开验证的平台信息。

在示例8中，示例1-7的主题包括，查询区块链以确认链接到制造商嵌入式密钥的信任锚。

在示例9中，示例8的主题包括：查询区块链以搜索针对链接到制造商嵌入式密钥的信任锚的信任锚撤销；以及基于标识信任锚撤销来使对象设备使用另一安全配置文件。

在示例10中，示例1–9的主题包括以下主题，其中对象设备执行用于对对象设备操作的设备软件的受信任引导顺序，并且其中证明证据包括由设备平台对受信任引导顺序的验证。

在示例11中，示例1–10的主题包括以下主题，其中设备是装载工具，并且其中设备和设备平台根据开放连接基金会(OCF)标准系列的规范来配置。

在示例12中，示例1–11的主题包括以下主题，其中受信任硬件组件和设备根据受信任计算组(TCG)标准系列的规范来配置。

示例13是一种用于使用由装载工具设备执行的操作来装载对象设备以与安全配置文件一起使用的方法，该方法包括：接收用于执行对象设备的所有者转移方法的请求，该对象设备与设备平台相关联；验证与对象设备相关联的证明证据，该证明证据由设备平台提供，其中，证明证据由使用制造商嵌入式密钥产生的证书签名，并且其中，制造商嵌入式密钥是从设备平台的受信任硬件组件提供的；以及基于证明证据执行对象设备的设备供应，其中，设备供应使对象设备使用与制造商嵌入式密钥绑定的安全配置文件。

在示例14中，示例13的主题包括：维持设备平台的所拥有的和受信任的设备的列表，该列表包括对象设备。

在示例15中，示例13-14的主题包括以下主题，其中，执行设备供应包括进一步的操作，该操作包括：向对象设备供应来自本地证书授权机构的本地凭证，该本地证书授权机构由设备操作，其中本地凭证指示与制造商嵌入式密钥绑定的安全配置文件的经验证的使用。

在示例16中，示例13-15的主题包括以下主题，其中，执行设备供应包括进一步的操作，该操作包括：将对象设备的资源更新为与安全配置文件相关联的值，其中，对象设备在完成设备供应时转变为使用安全配置文件。

在示例17中，示例13-16的主题包括以下主题，其中制造商嵌入式密钥与信任锚相关联，其中通过使用信任锚管理协议来管理信任锚。

在示例18中，示例13-17的主题包括以下主题，其中制造商嵌入式密钥链接到证书链，其中证书链由信任锚终止，并且其中证明证据包括信任锚。

在示例19中，示例13-18的主题包括以下主题，其中制造商嵌入式密钥与设备平台的平台属性凭证相关联，并且其中平台属性凭证包括在第三方数据源上可公开验证的平台信息。

在示例20中，示例13-19的主题包括：查询区块链以确认链接到制造商嵌入式密钥的信任锚。

在示例21中，示例20的主题包括：查询区块链以搜索针对链接到制造商嵌入式密钥的信任锚的信任锚撤销；以及基于标识信任锚撤销来使对象设备使用另一安全配置文件。

在示例22中，示例15-21的主题包括以下主题，其中对象设备执行用于对对象设备操作的设备软件的受信任引导顺序，并且其中证明证据包括由设备平台对受信任引导顺序的验证。

在示例23中，示例15-22的主题包括以下主题，其中装载工具设备和设备平台根据开放连接基金会(OCF)标准系列的规范来操作。

在示例24中，示例23的主题包括以下主题，其中受信任硬件组件和设备平台根据受信任计算组(TCG)标准系列的规范来配置。

示例25是一种包括指令的机器可读存储介质，其中，指令被计算设备的处理电路执行时使处理电路执行示例13至24中的任一项的操作。

示例26是一种装备，包括：用于接收用于执行对象设备的所有者转移方法的请求的装置，该对象设备与设备平台相关联；用于验证与对象设备相关联的证明证据的装置，该证明证据由设备平台提供，其中，证明证据由使用制造商嵌入式密钥产生的证书签名，并且其中，制造商嵌入式密钥是从设备平台的受信任硬件组件提供的；以及用于基于证明证据执行对象设备的设备供应的装置，其中，设备供应使对象设备使用与制造商嵌入式密钥绑定的安全配置文件。

在示例27中，示例26的主题包括：用于维持设备平台的所拥有的和受信任的设备的列表的装置，该列表包括对象设备。

在示例28中，示例26-27的主题包括：用于向对象设备供应来自本地证书授权机构的本地凭证的装置，该本地证书授权机构由设备操作，其中本地凭证指示与制造商嵌入式密钥绑定的安全配置文件的经验证的使用。

在示例29中，示例26-28的主题包括：用于将对象设备的资源更新为与安全配置文件相关联的值的装置，其中，对象设备在设备供应完成时被转变为使用安全配置文件。

在示例30中，示例26-29的主题包括以下主题，其中制造商嵌入式密钥与信任锚相关联，其中通过使用信任锚管理协议来管理信任锚。

在示例31中，示例26-30的主题包括以下主题，其中制造商嵌入式密钥链接到证书链，其中证书链由信任锚终止，并且其中证明证据包括信任锚。

在示例32中，示例26-31的主题包括以下主题，其中制造商嵌入式密钥与设备平台的平台属性凭证相关联，并且其中平台属性凭证包括在第三方数据源上可公开验证的平台信息。

在示例33中，示例26-32的主题包括：用于查询区块链以确认链接到制造商嵌入式密钥的信任锚的装置。

在示例34中，示例33的主题包括：用于查询区块链以搜索针对链接到制造商嵌入式密钥的信任锚的信任锚撤销的装置；以及用于基于标识信任锚撤销来使对象设备使用另一安全配置文件的装置。

在示例35中，示例26-34的主题包括以下主题，其中对象设备执行用于对对象设备操作的设备软件的受信任引导顺序，并且其中证明证据包括由设备平台对受信任引导顺序的验证。

在示例36中，示例26-35的主题包括以下主题，其中装备和设备平台根据开放连接基金会(OCF)标准系列的规范来操作。

在示例37中，示例26–36的主题包括以下主题，其中受信任硬件组件和设备平台根据受信任计算组(TCG)标准系列的规范来配置。

示例38是适于执行示例1至示例37中任一项的操作的IoT服务平台。

示例39是开放连接基金会(OCF)设备，该设备根据OCF规范被配置为服务器、客户端、或中间设备，包括用于实现示例1至示例37中任一项的操作的装置。

示例40是适于执行示例1至示例37中任一项调用的操作的设备所有者转移服务管理服务。

示例41是物联网(IoT)网络拓扑，该IoT网络拓扑包括适于对示例1至示例37中的任一项的操作执行通信的各个通信链路。

示例42是包括用于执行示例1至示例37中的任一项操作的各个设备和设备通信介质的网络。

示例43是包括用于执行示例1至示例37中的任一项操作的装置的装备。

示例44是用于执行示例1至示例37中的任一项操作的系统。

上文的这些示例中以及在参考图3至图9描述的特定实施例中描述的操作和功能可应用于各种网络设置，诸如IoT网络、边缘网络、雾网络、云网络及其所有混合。这些示例和配置的操作和功能可以以分布式方式发生，包括在分布式网络环境中，其中功能的一个方面由第一IoT边缘设备或边缘网络执行，功能的另一方面由雾网络或平台执行，并且功能的又另一方面由云设备或系统执行。如上文的示例和配置中所建议的，可以采用遵循这些共享的、分布式、或分组原理的进一步的组合。因此，将显而易见的是，本文所描述的功能可以是可操作的，以在上文示例和配置以及类似变型的许多置换内工作。

在以上具体实施方式中，可将各特征组合在一起以使本公开流畅。然而，权利要求可以不陈述本文中所公开的每一特征，因为实施例的特征可以是所述特征的子集。进一步地，实施例可包括比特定示例中所公开的那些特征更少的特征。因此，所附权利要求书由此被结合到具体实施方式中，一项权利要求作为单独的实施例而独立存在。

Claims

1.一种设备，包括：

通信电路；

处理电路；以及

存储器设备，所述存储器设备包括存储在其上的指令，其中，所述指令由所述处理电路执行时将所述处理电路配置成执行以下各项操作，包括：

接收用于执行对象设备的所有者转移方法的请求，所述对象设备与设备平台相关联；

验证与所述对象设备相关联的证明证据，所述证明证据由所述设备平台提供，其中，所述证明证据由使用制造商嵌入式密钥产生的证书签名，其中，所述制造商嵌入式密钥是从所述设备平台的受信任硬件组件提供的；以及

基于所述证明证据执行所述对象设备的设备供应，其中，所述设备供应使所述对象设备使用与制造商嵌入式密钥绑定的安全配置文件。

2.如权利要求1所述的设备，其特征在于，所述操作进一步包括：

维持所述设备平台的所拥有的和受信任的设备的列表，所述列表包括所述对象设备。

3.如权利要求1所述的设备，其特征在于，执行设备供应包括进一步的操作，所述操作包括：

向所述对象设备供应来自本地证书授权机构的本地凭证，所述本地证书授权机构由所述设备操作，其中所述本地凭证指示与制造商嵌入式密钥绑定的所述安全配置文件的经验证的使用。

4.如权利要求1所述的设备，其特征在于，执行设备供应包括进一步的操作，所述操作包括：

将所述对象设备的资源更新为与所述安全配置文件相关联的值，其中，所述对象设备在完成所述设备供应时转变为使用所述安全配置文件。

5.如权利要求1所述的设备，其特征在于，所述制造商嵌入式密钥与信任锚相关联，其中所述信任锚通过使用信任锚管理协议来管理。

6.如权利要求1所述的设备，其特征在于，所述制造商嵌入式密钥被链接到证书链，并且所述证书链由信任锚终止，并且其中所述证明证据包括所述信任锚。

7.如权利要求1所述的设备，其特征在于，所述制造商嵌入式密钥与所述设备平台的平台属性凭证相关联，并且其中所述平台属性凭证包括在第三方数据源上可公开验证的平台信息。

8.如权利要求1所述的设备，其特征在于，所述操作进一步包括：

查询区块链以确认链接到所述制造商嵌入式密钥的信任锚。

9.如权利要求8所述的设备，其特征在于，所述操作进一步包括：

查询所述区块链以搜索针对链接到所述制造商嵌入式密钥的所述信任锚的信任锚撤销；以及

基于标识所述信任锚撤销来使所述对象设备使用另一安全配置文件。

10.如权利要求1所述的设备，其特征在于，所述对象设备执行用于对所述对象设备操作的设备软件的受信任引导顺序，并且其中所述证明证据包括由所述设备平台对所述受信任引导顺序的验证。

11.如权利要求1所述的设备，其特征在于，所述设备是装载工具，并且其中，所述设备和所述设备平台是根据开放连接基金会(OCF)标准系列的规范来配置。

12.如权利要求1所述的设备，其特征在于，所述受信任硬件组件和所述设备根据受信任计算组(TCG)标准系列的规范来配置。

13.一种用于使用由装载工具设备执行的操作来装载对象设备以与安全配置文件一起使用的方法，所述方法包括：

接收用于执行所述对象设备的所有者转移方法的请求，所述对象设备与设备平台相关联；

验证与所述对象设备相关联的证明证据，所述证明证据由所述设备平台提供，其中，所述证明证据由使用制造商嵌入式密钥产生的证书签名，并且其中，所述制造商嵌入式密钥是从所述设备平台的受信任硬件组件提供的；以及

14.如权利要求13所述的方法，其特征在于，进一步包括：

15.如权利要求13所述的方法，其特征在于，执行设备供应包括进一步的操作，所述操作包括：

16.如权利要求13所述的方法，其特征在于，执行设备供应包括进一步的操作，所述操作包括：

17.如权利要求13所述的方法，其特征在于，所述制造商嵌入式密钥与信任锚相关联，其中所述信任锚通过使用信任锚管理协议来管理。

18.如权利要求13所述的方法，其特征在于，所述制造商嵌入式密钥被链接到证书链，并且所述证书链由信任锚终止，并且其中所述证明证据包括所述信任锚。

19.如权利要求13所述的方法，其特征在于，所述制造商嵌入式密钥与所述设备平台的平台属性凭证相关联，并且其中所述平台属性凭证包括在第三方数据源上可公开验证的平台信息。

20.如权利要求13所述的方法，其特征在于，所述操作进一步包括：

查询区块链以确认链接到所述制造商嵌入式密钥的信任锚。

21.如权利要求20所述的方法，其特征在于，所述操作进一步包括：

查询所述区块链以搜索针对链接到所述制造商嵌入式密钥的信任锚的信任锚撤销；以及

22.如权利要求13所述的方法，其特征在于，所述对象设备执行用于对所述对象设备操作的设备软件的受信任引导顺序，并且其中所述证明证据包括由所述设备平台对所述受信任引导顺序的验证。

23.如权利要求13所述的方法，其特征在于，所述装载工具设备和所述设备平台根据开放连接基金会(OCF)标准系列的规范来操作。

24.如权利要求23所述的方法，其特征在于，所述受信任硬件组件和所述设备平台根据受信任计算组(TCG)标准系列的规范来配置。

25.一种包括指令的机器可读存储介质，其特征在于，所述指令被计算设备的处理电路执行时使所述处理电路执行权利要求13至24中的任一项的操作。

26.一种装备，包括：

用于接收用于执行对象设备的所有者转移方法的请求的装置，所述对象设备与设备平台相关联；

用于验证与所述对象设备相关联的证明证据的装置，所述证明证据由所述设备平台提供，其中，所述证明证据由使用制造商嵌入式密钥产生的证书签名，并且其中，所述制造商嵌入式密钥是从所述设备平台的受信任硬件组件提供的；以及

用于基于所述证明证据执行所述对象设备的设备供应的装置，其中，所述设备供应使所述对象设备使用与制造商嵌入式密钥绑定的安全配置文件。

27.如权利要求26所述的装备，其特征在于，进一步包括：

用于维持所述设备平台的所拥有的和受信任的设备的列表的装置，所述列表包括所述对象设备。

28.如权利要求26所述的装备，其特征在于，进一步包括：

用于向所述对象设备供应来自本地证书授权机构的本地凭证的装置，所述本地证书授权机构由所述设备操作，其中所述本地凭证指示与制造商嵌入式密钥绑定的所述安全配置文件的经验证的使用。

29.如权利要求26所述的装备，其特征在于，进一步包括：

用于将所述对象设备的资源更新为与所述安全配置文件相关联的值的装置，其中，所述对象设备在完成所述设备供应时转变为使用所述安全配置文件。

30.如权利要求26所述的装备，其特征在于，所述制造商嵌入式密钥与信任锚相关联，其中所述信任锚通过使用信任锚管理协议来管理。

31.如权利要求26所述的装备，其特征在于，所述制造商嵌入式密钥被链接到证书链，并且所述证书链由信任锚终止，并且其中所述证明证据包括所述信任锚。

32.如权利要求26所述的装备，其特征在于，所述制造商嵌入式密钥与所述设备平台的平台属性凭证相关联，并且其中所述平台属性凭证包括在第三方数据源上可公开验证的平台信息。

33.如权利要求26所述的装备，其特征在于，进一步包括：

用于查询区块链以确认链接到所述制造商嵌入式密钥的信任锚的装置。

34.如权利要求33所述的装备，其特征在于，进一步包括：

用于查询所述区块链以搜索针对链接到所述制造商嵌入式密钥的信任锚的信任锚撤销的装置；以及

用于基于所述信任锚撤销来使所述对象设备使用另一安全配置文件的装置。

35.如权利要求26所述的装备，其特征在于，所述对象设备执行用于对所述对象设备操作的设备软件的受信任引导顺序，并且其中所述证明证据包括由所述设备平台对所述受信任引导顺序的验证。

36.如权利要求26所述的装备，其特征在于，所述装备和所述设备平台根据开放连接基金会(OCF)标准系列的规范来操作。

37.如权利要求26所述的装备，其特征在于，所述受信任硬件组件和所述设备平台根据受信任计算组(TCG)标准系列的规范来配置。