万维物联网 (WoT) 架构

4.1.1 消费者

在消费者空间中有多个资产从连接中受益。灯和空气净化器可以根据房间占用情况而被关闭。 窗户百叶可以基于天气情况和场合自动地关闭。能源和其它资源消耗可以基于使用模式和预测而被充分利用。

本节中消费者使用案例包含智能家居使用案例。

图 1 展示了一个智能家居的例子。在这个案例中，网关通过相应的本地通信协议（比如 KNX, ECHONET, ZigBee, DECT ULE 和 Wi-SUN）连接边缘设备，比如传感器，摄像机和家电。 多个网关可以存在于一个家庭中，每一个网关可以支持多个本地协议。

网关可以通过 internet 被连接到云端，而一些设备可以直接被连接到云端。 服务运行在云端，并从边缘设备上收集数据和分析数据，然后通过边缘设备和其它用户体验设备向用户提供价值。

智能家居为消费者带来利益，比如远程访问和控制，语音控制和家庭自动化。智能家居还可以使设备厂商监控和远程维护设备。 智能家居可以实现增值服务，比如能源管理和安全监护。

4.1.2 产业

本节中的产业用例适用于不同垂直产业。
由于应用场景的重叠性质，不同的垂直领域有相似的用例。

4.1.2.1 例子: 智能工厂

图 2 展示了一个智能工厂的例子。在这个例子中，基于工业通信协议(比如，PROFINET, Modbus, OPC UA TSN, EtherCAT, 或 CAN)区域级，点和线控制器使不同的工厂设备自动化。 工业边缘设备从各种各样的控制器那里收集选中的数据，并让这些数据被云后端的服务可使用。例如，通过仪表盘进行远程监控或分析它以做预防型维护保养。

智能工厂需要对连接的制造设备和制造的产品一样的高级监控。 他们受益于机器故障的预测和早期发现异常以防止昂贵的宕机时间和维护付出。

此外，监控连接的制造设备和生产设施环境中是否存在有毒气体，过度的噪音或高温，可以提高工人的安全性并降低发生事件或事故的风险。

实时监控和生产设备的 KPI 计算有助于发现产率问题和优化供应链。

4.1.3 物流与运输

监控车辆，燃料费用，维护需求和分配有助于优化车队的充分利用。

可以追踪运输途中的货物，以确保运输货物的品质及环境稳定。这对于维护从仓库到冷藏卡车再到交付的冷链的完整性特别有用。

集中监控和管理库存在仓库和货场可以预防缺货和过多库存的情况。

4.1.4 公共设备

自动读取住宅和 C&I (商业和工业) 电表，并进行计费，可以不断了解资源消耗和潜在瓶颈。

监视分布式可再生能源发电设备的状况和输出可优化分布式能源。

监视和远程控制分配设备有助于自动化分配过程。

对发电和配电基础设施的持续监控正在改善现场公用事业人员的安全。

4.1.5 油和气

海洋平台的监测，管道的泄漏检测和预测以及储罐和水库中的液位监测和控制，有助于提高劳动者和环境的工业安全性。

通过各种储罐和输送管道/卡车自动计算分布式库存，可以改善计划和资源优化。

4.1.6 保险

对高价值资产（如互连结构，车队车辆等）进行主动性资产监控，可以降低由于预测和事件早期侦测不足而造成的严重破坏和高成本的风险。

通过使用追踪和自定义保险策略可以提供基于使用情况的保险。

预测性天气监控并将车队车辆重新编排到车库，可以降低由于冰雹，树木倾倒而造成的损失。

4.1.7 工程建设

监控工业安全可降低安全隐患的风险。在施工现场进行资产监控可以放松损坏和丢失。

4.1.8 农业

土壤状况监测并为浇水，施肥以及监测农产品状况制定最佳计划，可以优化农产品的质量和产量。

4.1.9 健康服务

临床试验数据的收集和分析有助于获取对新领域的见解。

远程患者监视可降低老年人和住院后患者受到未检测到的危险情况的风险。

4.1.10 环境监测

环境监视通常依赖于许多分布式传感器，这些传感器将其测量数据发送到公共网关，边缘设备和云服务。

监测空气污染，水污染和其它环境风险因素（例如细尘，臭氧，挥发性有机化合物，放射性，温度，湿度）以检测关键的环境状况可以防止无法恢复的健康或环境破坏。

4.1.11 智慧城市

监测桥梁，水坝，防洪堤，隧道的材料状况，劣化，振动可发现维修工作并防止重大损坏。监控高速公路并提供适当的路标，可确保优化交通流量。

智能停车可以优化并跟踪停车位的使用情况和可用性，并自动进行计费/预订。

基于存在检测，天气预报等对路灯的智能控制可降低成本。

可以监视垃圾容器以优化废物管理和垃圾收集路线。

4.1.12 智慧建筑

监控整个建筑物的能源使用有助于优化资源消耗并减少浪费。

监视建筑物中的设备，如HVAC，电梯等，及早解决问题，可提高居住者的满意度。

4.1.13 联网汽车

监视操作状态，预测服务需求可优化维护需求和成本。通过通知紧急道路和交通状况的预警系统，可以提高驾驶员的安全性。

4.1.13.1 联网汽车示例

图 3 展示了一个联网汽车的示例。在这种情况下，网关通过CAN连接到汽车部件，并通过专有接口连接到汽车导航系统。云中运行的服务收集从汽车部件推送的数据，并分析来自多辆汽车的数据以确定交通模式。在这种情况下，网关还可以使用云服务来获取交通数据并将其通过汽车导航系统显示给驾驶员。

4.2.1 设备控制器

第一个用例是一个本地设备被一个用户操作远程控制器控制，如图4 描述。 一个远端控制器可以直接通过本地家庭网络访问电子设备。在本案例中，远端控制器可以通过浏览器或原生应用程序来实现。

在这种模式下，至少一个设备（如电子设备）具有服务器角色，该服务器角色可以接受来自其它设备的请求并对其进行响应，有时还启动机器操作。 其它设备（与远程控制器类似）具有客户端角色，该角色可以发送带有请求的消息，比如读取传感器值或者打开设备。而且，为了发送一个设备的当前状态和事件通知， 该设备可能具有客户端角色，可以发送消息给其它设备，它同时还拥有服务器角色。

4.2.2 物到物

图5 展示了一个直接物到物的交互案例。 场景如下：传感器检测到房间环境的变化，如文档超过阀值，并发送一个诸如“打开”的控制消息到电器。传感器单元可以发送一些触发消息到其它设备。

在这个案例中，当两个具有服务器角色的设备连接时，至少一个设备还必须具有一个客户端角色来发送消息给其它设备以激活或通知。

4.2.3 远程访问

这个用例包含如图6 所示的一个移动远程控制器（比如，在智能手机上）。远程控制器可以在不同的网络连接和协议中进行切换，比如，在移动网络和家庭网络中，使用的协议比如 Wi-Fi 和蓝牙。 当控制器在家庭网络时，它是一个被信任的设备，不需要额外的安全性或访问控制。当它在被信任的网络的外面时，额外的访问控制和安全机制必须被应用以确保信任关系。 注意，在这种情况下，网络连接可能会在不同的网络访问点或蜂窝基站之间切换而改变。

在这种模式下，远程控制器和电子设备具有客户端和服务器角色，如图4中相关场景所示。

4.2.4 智能家居网关

图 7 展示了一个使用智能家居网关的用例。网关位于家庭网络和 Internet 之间。它管理房间内的电器，并能够通过 Internet 从远端控制器接受命令，比如，从上一个用例中所示的智能手机。 它也是设备的虚拟表示。智能家居网关通常还提供代理和防火墙功能。

在这种模式下，家庭网关同时有客户端和服务器角色。当远程控制器启动电子设备时，它可以以客户端角色连接到电子设备，并以服务器角色连接到远程控制器。 当电子设备向远程控制器发出消息时，网关相对于电子设备扮演着服务器角色，并且充当远端控制器的客户端角色。

4.2.5 边缘设备

边缘设备或边缘网关类似于智能家居网关。我们使用该术语表示边缘网关执行的其它任务。 然而，在图 8中的家庭网关主要是在公有网络和可信任网络直接建立桥接，边缘设备拥有本地计算能力， 并且通常在不同协议之间进行桥接。边缘设备通常被用在工业解决方案中，其中它们可以对连接的设备和传感器提供的数据进行预处理，过滤和聚合。

4.2.6 数字孪生

数字孪生是一种虚拟表示法，即存在于云服务器或边缘设备上的一个设备或者一组设备的模型。它可以用来表示可能不连续在线的真实设备， 或者在将新应用程序和服务器部署到真实设备之前对其进行仿真。

数字孪生可以对单个设备建模，或者可以以组合设备的虚拟表示形式聚合多个设备。

数字孪生可以被以不同的方式来实现，具体取决于是被是否已经连接到云，或者是否连接到网关（网关本身已经连接到云）。

4.2.6.1 云端设备

图 11 展示了一个电子设备直接连接到云的例子。云镜像了设备，并扮演着数字孪生，可以从远端控制器（比如，智能手机）接受命令。 经授权的控制器可以放在任何地方，因为数字孪生是全球可触达的。

4.2.6.2 传统设备

图12展示了一个传统电子设备不能直接连接到云的案例。在这里，需要一个网关来中继连接。网关工作如下：

• 物理和逻辑视图中各种传统通信协议的集成商
• 通往 Internet 的防火墙
• 隐私过滤器，可以替代真实的图像和（或）语音，并在本地记录数据
• 本地代理，以防网络连接中断
• 发生火灾警报和类似事件时再本地运行的紧急服务

云镜像了网关和所有已连接的设备，并扮演数字孪生，与网关一起在云中管理它们。此外，云可以接收从位于任何地方的远程控制器（比如，智能手机）发出的命令。

4.2.7 多云

典型的物联网部署包含许多设备(数千)。没有一个标准化的机制，针对特定云的固件更新管理将需要大量工作，并阻碍了物联网的更广泛应用。

用于描述设备和设备类型的标准化机制的主要好处是能够将设备部署到不同的云环境，而无需在设备软件/固件级别进行自定义，即将云特定代码安装到设备。 这意味着该解决方案足够灵活，能够以允许在多种 IoT 云环境中启动和使用设备的方式描述设备。

这推动了物联网设备的采用，因为它可以轻松使用现有部署中的设备，以及将现有设备从一个云迁移到另一个云。

4.2.8 跨域协作

图 13 展示了一个跨域协作的案例。在这种情况下，每个系统都涉及其它域中的其它系统，比如智慧工厂和智慧城市一起，智慧城市和智慧家居一起。这种系统类型被叫做“共生”生态系统， 如[IEC-FOTF] 中所示。 有两种协作模式：直接协作和间接协作。在直接协作模式中，系统和其它系统以端对端的方式直接交换信息。在间接协作模式中， 系统通过一些协作平台交换信息。为了维护和迹象这种协作，每个系统提供其功能和接口的元数据，并让自己适配于其它系统。

8.8.1 本地 WoT API

开发人员可能选择不使用WoT脚本API来实现Servient的原因有多种。 这可能是由于内存或计算资源不足所致，因此开发人员无法使用所需的软件堆栈或功能全面的脚本引擎。 或者，为了支持其用例（例如，专有通信协议），开发人员可能必须使用仅通过特定编程环境或语言才能使用的特定功能或库。

在这种情况下，仍然可以使用WoT 运行时， 但是使用替代的面向应用程序的接口而不是WoT 脚本 API公开了等效的抽象和功能。 除后者外，§ 8. Abstract Servient Architecture中的所有块描述也适用于图28。

8.8.2 已存在设备的事物描述

通过为这些设备或服务创建事物描述，还可以将现有的物联网设备或服务集成到 W3C Web of Things 中并将其用作事物。 这样的TD可以手动创建，也可以通过工具或服务创建。 例如，TD可以由提供自动翻译另一种依赖于生态系统的机器可读格式提供的元数据的服务生成。 但是，仅当目标设备使用的协议可以使用协议绑定来描述时，才可以这样做。 这些需求在§ 6.6协议绑定中给出。 前面的大部分讨论还暗示，事物提供了自己的事物描述。 尽管这是一种有用的模式，但不是强制性的。 特别是，可能无法修改现有设备以直接提供其自己的事物描述。 在这种情况下， 必须使用诸如目录之类的服务或某些其它外部且独立的分发机制来单独提供事物描述。

9.2.1 消费者和事物在同一个网络

在最简单的互连拓扑中，如图30所示，消费者和事物位于同一网络上，无需任何中介即可直接相互通信。 这种拓扑出现的一个用例是，当消费者是业务流程服务或网关上运行的某些其它IoT应用程序，而事物是与传感器或执行器接口的设备时。 但是，客户端/服务器的关系很容易逆转。 客户端可以是消费者角色的设备，用于访问在网关或云中作为Thing运行的服务。

如果事物位于云中，而消费者位于本地网络中（请参见图1中一个智能家居用例）， 实际的网络拓扑可能会更复杂，例如需要NAT遍历并不允许某些形式的发现。 在这种情况下，稍后讨论的更复杂的拓扑之一可能更合适。

9.2.2 消费者和事物通过中介而连接

一个中介在网络上同时扮演事物和消费者的角色， 并且同时支持暴露的事物和可消费的事物的软件抽象及其WoT 运行时。 中介可以用于在设备和网络之间进行代理，也可以用于数字孪生。

9.2.2.1 中介扮演着一个代理

中介的一个简单应用是Thing的代理。 当中介充当代理时，它具有与两个单独的网络或协议的接口。 这可能涉及实现其它安全机制，例如提供TLS端点。 通常，代理不会修改交互集，因此，由中介暴露的TD将具有与可消费的TD一样的交互，但是会修改连接元数据。

为了实现此代理模式，中介获取事物的TD并创建一个可消费的事物。 它创建Thing的代理对象，作为具有相同交互自解释性的软件实现。 然后，它使用新标识符为代理对象创建TD，并可能使用新的通信元数据（协议绑定）和（或）新的公开安全元数据创建TD 。 最后，根据此TD创建一个暴露的事物，中介将通过适当的发布机制通知其他消费者或 TD 的中介。

9.2.3 从云服务中控制本地网络中的设备

在智能家居用例中，通常会监视连接到家庭网络的设备（传感器和家用电器）， 并且在某些情况下，还可以通过云服务对其进行控制。 设备连接到的家庭网络和云之间通常有一个NAT设备。 NAT设备转换IP地址并经常提供防火墙服务，从而选择性地阻止连接。 本地设备和云服务只能在可以成功通过网关时相互通信。

一个典型的结构中，在采用了 ITU-T 建议 Y.4409/Y.2070 [Y.4409-Y.2070]， 如图32所示。 在这种结构中，既有本地中介，也有远程中介。 本地中介将来自多个Thing的交互自解释性聚合到一个（一组）暴露的事物中， 这些事物可以全部映射到一个通用协议（例如，HTTP，所有交互都映射到一个具有公共基本服务器并使用的单个URL命名空间一个端口）。 这提供了远程中介用一个简单的方法来访问所有的事物背后的NAT设备， 假设本地中介已经使用了可以穿越NAT设备的聚合协议，并且具有某种方法可以将该服务公开给Internet（STUN，TURN，DyDNS等）。 另外，本地中介可以充当Thing代理， 因此，即使所连接的事物各自使用不同的协议（HTTP，MQTT，CoAP等）和（或）不同的生态系统约定， 暴露的事物也可以使它们融合一个单一的协议，这样消费者就不必知道事物使用的各种协议。

在图32中， 有两个客户端连接到远程中介，该客户端聚合了位于NAT边界后面的服务，并可以提供其它协议转换或安全服务。 特别是，本地中介可能位于容量有限的网络上，并且使该服务直接提供给所有用户可能不可行。 在这种情况下访问本地中介只能提供给远程中介。 远程中介然后实现更通用的访问控制机制，还可以执行缓存或限制操作以保护消费者免受过多流量的侵害。 这些消费者还将使用适合于开放Internet的单个协议（例如HTTPS）与中介进行通信，这使客户端的开发更加简单。

在这种拓扑中，消费者与事物之间具有NAT和防火墙功能， 但是本地和远程中介一起工作建立所有通信通道以通过防火墙，因此消费者与事物无需了解防火墙。 配对的中介还通过提供访问控制和流量管理来保护家用设备。

在更困难的情况下，NAT和防火墙穿越可能无法完全如图所示。 特别是，ISP可能不支持公开访问的地址，或者STUN / TURN和（或）DyDNS可能不受支持或不可用。 在这种情况下，中介可以替代性地反转它们之间的客户端/服务器角色以建立初始连接（本地中介首先连接到云中的远程中介）， 然后这对中介可以建立隧道（例如使用，一种使用TLS保护连接的安全WebSocket）。 然后，可以使用该隧道对中介之间的所有通信使用自定义协议进行编码。 在这种情况下，仍然可以使用标准端口通过HTTPS进行初始连接，并且从本地中介到远程中介的连接与普通浏览器/Web服务器交互相同。 这应该能够穿越大多数家庭防火墙，并且由于连接是传出的，因此网络地址转换不会造成任何问题。 但是，即使需要自定义隧道协议，远程中介仍可以将此自定义协议转换回标准外部协议。 该连接消费者和事物不需要知道它。 也可以将此示例扩展为用例，其中事物和消费者都可以在NAT边界的任一侧进行连接。 但是，这还需要在两个中介之间建立双向隧道。

9.2.4 使用事物目录进行发现

一旦可以通过云上的服务监视或控制本地设备（可能还有服务）， 便可以在其上构建各种其它服务。例如，云应用程序可以基于对收集到的数据的分析来更改设备的运行状况。

但是，当远程中介是为客户端应用程序提供服务的云平台的一部分时， 客户端需要能够通过例如访问已连接设备的目录来查找设备信息。 为简化起见，在下图中，我们假定所有本地设备都实现为事物，所有云应用程序都实现为Consumers。 为了使实现为事物的本地设备的元数据可用于云应用程序，可以将它们的元数据注册到Thing Directory服务。 该元数据专门用于修改以反映公共安全元数据的本地设备的TD以及远程中介提供的通信元数据（协议绑定）。 然后，客户端应用程序可以通过查询Thing Directory获得与本地设备通信以实现其功能所需的元数据。

在图中未显示的更复杂的情况下，可能还会有充当事物的云服务。 这些事物还可以在事物目录中注册自己 。 由于事物目录是Web服务，因此它应该通过NAT或防火墙设备对本地设备可见，并且甚至可以为其接口提供自己的TD。 然后，充当消费者的本地设备可以通过事物目录在云中发现事物， 并直接或通过本地中介（例如，如果需要协议转换）连接到事物。

9.2.5 跨多域的服务到服务的连接

各自基于不同物联网平台的多个云生态系统可以协同工作，以构成一个更大的系统级生态系统。 在先前讨论的云应用程序生态系统的结构的基础上，下图显示了两个相互连接以组成系统的生态系统。 考虑以下情况：一个生态系统（即下面的消费者A）中的客户需要使用另一生态系统（即下面的事物B）中的服务器。 实现这种跨生态系统应用程序-设备集成的机制不止一种。 下面说明了两种机制，每种机制都使用一个图表来说明如何实现。

9.2.5.1 通过事物目录同步进行连接

在图34中，两个事物目录同步信息， 这使消费者A可以通过 事物目录A获得事物B的信息。 如前几节所述，远程中介B维护事物B的影子实现。 通过获取此影子设备的TD，消费者A可以通过远程中介B使用事物B。

9.2.5.2 通过代理同步进行连接

在图 35中，两个远程中介会同步设备信息。 当事物B的影子在远程中介B内创建，影子的TD同时同步到远程中介A。 远程中介A反过来创建它拥有的事物B的影子，并通过事物目录A 注册 TD。 利用这种机制，事物目录之间的同步不是必需的。

10.1.1 事物描述私有安全数据风险

TD被设计为仅携带公开安全元数据。 TD的生产者必须确保没有私有安全数据包括在 TDs 中。 应严格区分公开安全元数据和私有安全数据。 TD仅应包含公开安全元数据，让消费者知道并且仅当获得授权时，他们才能作为系统访问而需要做什么。 反过来，授权应基于单独管理的私人信息。

TD规范中定义的内置TD安全方案有意不支持私有安全数据的编码 。 但是，存在可能会误用其它字段（例如，人类可读的描述）来对该信息进行编码的风险， 或者可能会通过对此类信息进行编码的扩展机制来定义和部署新的安全方案。

缓解:

TD和将在TD中使用的扩展的创建者必须确保TD中仅存储公共安全元数据。

10.1.2 事物描述个人身份信息风险

事物描述可能包含各种类型的个人身份信息。 即使不是明确的，也可以使用TD及其与可识别人员的关联来推断有关该人员的信息。 例如，可以确定其位置的移动设备暴露的可指纹TD的关联可能是跟踪风险。 即使无法识别特定的设备实例，由TD表示的设备的类型在与人关联时也可能构成个人信息。 例如，医疗设备可以用于推断用户患有医疗状况。

通常，应尽可能限制TD中的个人身份信息。 但是，在某些情况下，这是无法避免的。 TD中可能同时存在直接和不可理解的PII，这意味着应像对待其它形式的PII一样对待TD。 它们应以安全的方式存储和传输，应仅提供给授权用户，应仅在有限的时间内缓存，应要求将其删除，仅应在用户同意的情况下用于提供它们的目的，并且否则，他们应满足使用PII的所有要求（包括任何法律要求）。

缓解:

TD中PII的存储应尽可能减少。 即使在TD中没有明确的PII，也可能存在跟踪和标识隐私风险。 为了最大程度地降低这种风险，通常应将TD视为包含PII，并与其它PII一样接受相同的管理政策。 它们仅应提供给授权的消费者。对于特定用例不必要的信息，无论何时都不应在TD中公开。 例如，如果用例不需要，则也不应包括TD中的显式类型和实例标识信息。即使用例需要，也可以将跟踪风险降到最低，应尽可能使用分布式标识符和有限范围标识符，而不是全局唯一标识符。 在某些使用情况下，也可以省略其它形式的信息，例如人类可读的描述，以减少指纹风险。

10.1.3 事物描述通信元数据风险

WoT绑定模板必须正确支持底层采用的安全机制，物联网平台该平台被认为有资格与WoT使用。 由于大规模部署IoT所需的网络交互自动化，因此操作者需要确保以符合其安全策略的方式公开和使用事物。

缓解:

TD创建者应尽可能使用WoT绑定模板中提供的经过审查的通信元数据。 为WoT绑定模板未涵盖的物联网生态系统生成TD时 ，请确保满足物联网平台的所有安全要求。

10.2.1 跨脚本安全和隐私风险

在基本的WoT设置中，在WoT运行时内部运行的所有脚本被制造商认为是受信任的，已分发的， 因此，没有必要在每个正在运行的脚本实例之间执行严格的隔离。 但是，根据设备功能，部署用例场景和风险级别，可能需要这样做。 例如，如果一个脚本处理了敏感的与隐私相关的PII数据并经过了良好的审核，则可能希望将其与其余脚本实例分开，以最大程度地减少数据泄露的风险，以防万一同一系统内的其它脚本被获取。 在运行时受到损害。另一个示例是在单个WoT设备上不同租户的相互共存。在这种情况下，每个WoT运行时实例将托管一个不同的租户，将它们之间相互隔离是必要的。

缓解:

当脚本处理与隐私相关的数据或其它关键安全数据时 ，WoT运行时应隔离脚本实例及其数据。 同样， 如果WoT设备具有多个租户，则WoT运行时实现应执行WoT运行时实例及其数据的隔离。 可以使用设备上可用的平台安全性机制在WoT运行时中执行这种隔离。 有关更多信息，请参见WoT安全和隐私指南规范[WOT-SECURITY]的“ WoT Servient单租户”和“ WoT Servient多租户”部分。

10.2.2 物理设备直接访问安全性和隐私风险

如果脚本可以使用直接暴露的本机设备接口，则在脚本受到威胁或发生故障的情况下，可能会损坏基础物理设备（以及可能被包围的环境）。 如果此类接口的输入缺乏安全检查，则可能会将基础物理设备（或环境）置于不安全状态。

缓解:

WoT运行时应避免直接暴露本地设备接口给脚本开发者。 相反，WoT运行时实现应提供用于访问本机设备接口的硬件抽象层。 此类硬件抽象层应拒绝执行可能会使设备（或环境）进入不安全状态的命令。 另外，为了减少脚本遭到破坏时对物理WoT设备的损害，重要的是要根据特定脚本的功能最大程度地减少特定脚本公开或可访问的接口数量。

10.3.1 配置和更新安全风险

如果WoT运行时实施支持制造后配置，或自身，脚本或任何相关数据（包括安全凭证）的更新，则它可能是主要的攻击媒介。 攻击者可以尝试在更新或供应过程中修改任何上述元素，或者直接直接供应攻击者的代码和数据。

缓解:

制造后配置或脚本更新，WoT运行时本身或任何相关数据应以安全的方式进行。 可以在WoT安全和隐私准则规范[WOT-SECURITY]中找到一组有关安全更新和制造后配置的建议。

10.3.2 安全凭证存储安全性和隐私风险

通常，WoT运行时需要存储提供给WoT设备以在网络中运行的安全凭证。 如果攻击者可以破坏这些凭据的机密性或完整性，那么它就可以获取对资产的访问权，模拟其它WoT事物，设备或服务，或者发起拒绝服务（DoS）攻击。

缓解:

WoT 运行时应该安全地存储任何配置的安全证书，保证其完整性和保密性。 如果在单个启用了WoT的设备上有多个租户，则WoT 运行时实现应保证隔离每个租户提供的安全凭证。 此外，为了最大程度地降低供应的安全凭证受到威胁的风险，WoT 运行时实现不应公开任何用于脚本的API来查询预配置的安全证书。 此类凭据（或使用它们但不公开它们的更好的抽象操作）应该只能由使用它们的协议绑定实现访问。