促进大规模物联网供应

无论您是要设计新设备还是为 IoT 改造现有设备，您都需要考虑 IoT 配置，将 IoT 设备联机到云服务。物联网配置设计需要做出影响用户体验和安全的决策，用于配置数字身份、云端点和网络凭据的网络调试和凭据配置机制，以便设备可以安全地连接到云。

为了大规模执行 IoT 配置，客户通常会构建和维护定制的工具和软件应用程序，这些工具和软件应用程序可以通过跨越多个问题域的设备支持的协议推送所需的凭据。 IoT 配置域包括：

• 网络调试，为客户提供定义上下文特定参数的机制；
• 凭据配置，将凭据和配置分配给物理设备；和
• 云配置，用于设置支持身份验证、授权和设备管理的云端配置数据。

为了获得出色的客户用户体验，所有这三个配置域都必须协调一致。

例如，移动运营商在移动电话用户第一次连接时提供配置数据和策略设置。这是一个简单且易于理解的过程，对于移动设备用户来说不需要太多时间，其中 SIM 卡代表设备身份。对于试图配置数百万个 IoT 设备的客户，尤其是原始设备制造商 (OEM) 而言，情况变得非常不同且具有挑战性。

在本文中，您将能够了解如何避免或减轻与您自己的 IoT 部署相关的风险，并通过简短示例了解通过 Amazon Web Services (AWS) 等云平台提供的 IoT 服务如何帮助您实现您的 IoT 配置目标。

在需要时进行网络调试的方法

最终，您的 IoT 设备连接到作为 IoT 解决方案中心的中央服务并与之通信。要到达该中心，您的 IoT 设备必须加入网络媒体。介质可以是硬线（如以太网）或无线电传输（如 Wi-Fi）。根据介质的不同，您需要有人告诉设备它必须加入什么介质才能成功到达集线器。例如，对于蜂窝网络，您不需要告诉设备要加入的网络，因为这已由 SIM 卡定义。另一方面，要加入 Wi-Fi 网络，您需要知道 Wi-Fi 接入点名称和密码，并能够将这些详细信息告诉设备。我们将重点介绍需要配置才能加入网络的设备。

客户已经使用多种不同的机制来加入物联网网络。今天大多数人都有智能手机，大多数智能手机都有蓝牙，因此通过蓝牙进行配置已经变得普遍。然而，这并不是建立联系的唯一方式。物联网设备上的一些 Wi-Fi 模块足够智能，可以自己成为接入点，您可以在其中开发一个简单的网页，允许用户输入更大的网络配置。对于非消费者设备，通过串行或 microSD 进行配置仍然很常见。借助智能手机应用程序进行蓝牙配置已成为常态。这些智能手机应用程序还可以为设备云配置提供帮助，您将在本文稍后介绍。

大规模提供设备凭据的方法

整个行业的设备凭据配置流程仍然高度分散，短期内无法实现融合。大多数物联网集中式系统强烈建议或要求使用传输层安全性 (TLS) 1.2 连接来进行加密传输，这在最近而且可能被雄辩地称为传输中加密。今天，大多数物联网部署使用公钥基础设施 (PKI)，因此本文的其余部分假设使用 PKI。无论如何，每个设备都必须拥有自己唯一的识别私钥和证书。

要创建与云（或服务端点）的会话，TLS 1.2 需要私钥和 x.509 证书（或凭据）。 注意：Java Web Tokens 或 JWT 等一些技术也面临类似的挑战，但不会在此处讨论。 私钥就像您的 DNA 一样，只能为单个设备所知，这意味着它不得与其他设备共享。 x.509 证书类似于驾驶执照，由可验证的证书颁发机构 (CA) 通过提供证书签名请求 (CSR) 颁发。提供 CSR 与向您所在国家/地区的护照签发机构提交带有指纹的出生证明和其他通过测试的证明作为获得护照的证明并没有太大不同。在整篇文章中，我们将 x.509 证书称为凭证，并假设设备具有唯一的私钥。

TLS 1.2 的详细信息超出了本文的范围，但我们只会为您提供足够的信息，以便您了解为什么设备必须保护私钥。在 TLS 1.2 连接过程中，会发生一系列交换来证明设备是其身份的私钥的所有者。您的设备必须证明它是尝试用于身份验证的 x.509 证书的真正所有者。为了让 IoT 服务在您的设备连接时信任设备凭据，您需要手头有该私钥。现在您可以意识到，如果不法分子掌握了该密钥，那么安全模型就会崩溃。不惜一切代价保护物联网城堡的钥匙！

与大多数部署物联网的人一样，您必须决定如何大规模配置这些凭证。简要回顾一下，每台设备都必须：

• 代表设备的唯一、不可变的私钥。理想情况下，为了防止并行攻击和其他高级攻击，私钥应该受到物理保护并且不能加载到主程序内存中。
• 与您的应用程序或 IoT 服务相关的凭据。

私钥和凭证供应的选择因物流而异，有些与云供应脱节，有些则依赖于云供应。

• 集成电路安全模块（通常具有加密功能），无论是独立的还是参与系统级封装 (SiP)、系统级模块 (SoM) 或系统级芯片 (SoC) 设计的，有以下行为之一：

• • 具有手动配置或自生成私钥或信任根的安全模块。
  • 除了上一项之外，安全模块还提供预配置 x.509 证书形式的凭据。

• 订户身份模块 (SIM)、嵌入式 SIM (eSIM) 和集成 SIM (iSIM) 技术提供硬件，设计人员将其用作与蜂窝网络通信的蜂窝身份。凭据供应通常取决于移动网络运营商 (MNO) 提供商、移动虚拟网络提供商 (MVNO) 或第三方。如果您使用蜂窝模块进行通信，这是您的选择。
• 在制造过程中与硬件安全模块 (HSM) 一起为设备闪存段提供定制的自动化设备凭据，该段可能具有特殊的安全闪存。
• 将私钥和凭据手动配置到特殊的安全安全闪存（或非安全闪存，通常在原型设计期间，但不建议用于队列配置）。

由于加密要求，TLS 1.2 的执行是一项计算密集型活动，这反过来会影响计算组件的选择，尤其是在您的设计中使用微控制器时。专用 IC 通常包括加密例程，可减轻主机处理器对 TLS 1.2 操作应用周期的负担，同时确保私钥不会加载到主内存中。

您对硬件采用的方法取决于您的硬件设计。为硬件设计选择一个优雅的解决方案当然可以简化大规模配置，但需要在硬件设计生命周期的早期选择组件，因为它会影响计算、加密模块、数学协同处理和闪存的其他组件设计选择。当然，对于大规模设备，您不会想要手动配置，而且趋势表明，从制造、运营和客户体验的角度来看，预先配置的设备产生的摩擦最小。

物联网设备配置需要云和设备编排

成功的 IoT 设备配置需要云和设备配置编排，这会影响硬件和软件设计以及您在整个设备生命周期中管理设备的方式。

从 IoT 服务的角度来看，您将需要一个与您的凭证供应选择保持一致的流程来创建相关的配置对象。当设备连接到 IoT 服务时，IoT 服务必须能够识别设备（身份验证）、启用特定设备操作（授权）以及在特定上下文中操作和管理设备（设备管理）。

对于身份验证，IoT 服务必须具有凭证的指纹，因此当设备连接并将凭证发送到 IoT 服务时，IoT 服务可以将物理连接与配置对象相关联。对于 AWS IoT，您注册您的凭证，使 IoT 服务能够识别传入连接。 TLS 握手要求设备有权访问私钥（IoT 服务不能）确保凭据已从带有私钥的设备发送。这就是为什么保护设备上的私钥如此重要。

对于授权，IoT 服务必须将规则应用于授予最低 IoT 服务访问权限的连接。最低物联网服务访问意味着设置限制设备仅使用其履行其运营义务所需的资源。例如，AWS 客户创建与凭证配置对象相关的 IoT 策略。

对于设备管理，您需要将元数据应用于配置对象，以干净地指定设备或队列的组或聚合。有了物联网，我们将需要管理数千、数万和数百万台设备。单独管理每个设备是不切实际的。提前计划将元数据应用于您的设备配置，因为改造或重构可能会很痛苦。对于 AWS IoT，您可以创建推动 IoT 设备管理实践的事物类型和事物组配置对象。

大规模设备云配置的方法

不能说每个 IoT 部署在设备配置方面有所不同，但硬件供应商、IoT 应用程序和操作环境之间存在足够的差异，以驱动一组强大的机制，这些机制将影响您对正确机制的决定。一般来说，有三种方式：批量注册、按需注册和懒惰注册。以下所有方法都希望每个物联网设备都拥有或将拥有自己唯一的私钥和证书对。

批量注册

通过批量注册，您希望向 IoT 服务注册的一组凭据在设备部署到现场之前就已经知道了。获得凭据列表后，您可以将凭据引导到批量注册过程。批量注册过程会注册凭据，然后还将凭据与 IoT 服务中的相关管理对象进行协调，用于管理 IoT 队列。批量注册可能需要定制，但物联网服务提供商通常会向客户提供批量注册流程。例如，AWS 提供 AWS IoT Bulk 注册流程作为 AWS IoT Core 服务的一部分，并使用 AWS SDK 进行自定义处理。一个名为 ThingPress 的开源项目处理特定的导入用例。

按需注册

通过按需设备注册，在设备部署到现场之前，您不知道具有配对凭据的物理设备集。设备部署到现场后，您将打开设备电源。通过按需，连接子例程确定对凭证颁发者的引用是否已在 IoT 服务中注册。只要物联网服务有一个强大的机制来验证您实际上是发行人的所有者，这意味着您手头有发行人身份（在 PKI 中，发行人的私钥），您可以放心，发行人提供凭据。然后子程序自动注册凭证并创建相关的管理对象。例如，AWS 有两种按需设备注册机制，名为 Just-In-Time-Provisioning (JITP)，它使用预配模板，而 Just-In-Time-Registration (JITR) 提供可以完全自定义的机制。

延迟注册

使用延迟注册，在部署到现场之前，物理设备集和配对凭证都不是已知的。在这种情况下，设备具有已知的、不可变的身份（通常是受保护的私钥），物联网服务可以确认该身份，而无需将私有身份转移到设备之外。

今天，有三种惰性注册机制：通过声明、通过授权的移动设备和通过授权的身份列表。在第一种情况下，设备将声明发送给凭证颁发者，颁发者使用令牌进行响应，然后设备使用令牌进行直接 Web 服务 API 调用以颁发证书。在第二种情况下，设备与手机协同工作，其中手机使用移动凭据，如用户名和密码，发行者用令牌响应，手机将令牌发送到设备，设备使用进行直接 API 调用的令牌。在第三种情况下，授权列表可以是公钥列表，设备使用 CSR 对 IoT 服务进行直接 API 调用。然后将从 CSR 派生的公钥与授权列表进行比较，然后在匹配存在时将证书提供给设备。例如，AWS Fleet 配置提供基于声明和智能手机的配置机制，开源项目 IoT Provisioning Secret-Free 提供使用声明的延迟注册机制，AWS 合作伙伴 1nce 通过 AWS Marketplace 提供简化的蜂窝配置体验。

选择适合您的设备配置

选择适合您的设备配置意味着找到与您的硬件设计、软件设计、制造和设备生命周期操作相一致的设备凭据和设备云配置实践。硬件设计定义了您如何定义和存储单个设备身份和凭证文件。软件设计影响设备授权。制造影响创建和存储或识别秘密的条件，影响授权指纹如何反映到物联网服务中。

您决定如何对物理硬件进行凭证配置，这反映了在进行产品设计时通常提前很久决定的硬件设计，为特定类型的云配置流程创建了一个基本的支点。此外，如果您不是自己制造，那么您将使用合同制造商来构建您的产品。合同制造有很多好处，但制造过程的许多方面都不受您的控制，其中包括在制造线上创建设备机密，例如私钥和证书。生产过剩、克隆和其他攻击媒介等风险可以直接与受雇的合同制造商相关，这意味着您需要有很多信任才能在晚上轻松入睡。

如果您没有为您的 IoT 机群管理私有 CA，那么预配置的凭据可能适合您。预先配置的凭证可能需要额外支付一些费用，但我们已经看到它们显着降低了运营成本。如果您需要管理自己的私有 CA，那么一些硬件公司会提供预先配置的凭据，其中配置是在流片时完成的，这意味着合同制造商将不知道设备上的任何秘密。否则，您可能希望倾向于惰性配置，其中设备在设备上具有不可变的私钥或可复制的自生成私钥，并且可以参与 IoT 服务以在经过某种级别的证明后部署凭据。如果您不幸遇到设备上没有不可变私钥的情况，那么您仍然可以将私钥和凭据直接提供给闪存，但非常不推荐这样做。

与硬件设计相比，软件设计更加灵活，可以在整个设备开发甚至生命周期中更改（想想无线固件更新）。每当您向客户运送一批新设备时，您都需要依靠设备云配置流程。与软件设计一样，供应设计可能需要基于不断发展的软件需求的灵活性。所需的配置和定制广度推动了您在部署新的或额外的设备队列时将使用的设备云配置流程。

设备生命周期操作要求将推动设备云配置所需的灵活性水平。更具体地说，虽然 AWS IoT 设备云配置的大多数流程都支持自动创建管理对象（例如事物类型和事物组），但如果您的流程在注册期间还需要任何自定义互操作性，您可能需要考虑 Just-In-Time-允许更深入定制的配置。

最后，在查看设备生命周期时，请考虑设备在其整个使用过程中改变人类所有者的机会。虽然私钥方面的设备身份可能不会改变，但有机会弃用先前所有者的证书以将设备移至“出厂状态”。当新的人类所有者将设备委托给新网络并使用移动应用程序进行配置时，此时可能需要提供新的证书。然后生命周期机制需要伴随这些要求。

结论

在本文中，我们讨论了您今天可能会看到的 IoT 配置情况。同样，您已经目睹了许多选择，这取决于您要实现的目标以及您希望客户享受的结果。与所有事物一样，安全性是配置的基础，这从每台设备都有自己独特且可识别的私钥和证书对开始。您选择的凭证配置方法为您的设备云配置选择创建了该枢轴点。如果您正在进行新设计，您将需要仔细研究强化的硬件安全解决方案，例如安全元件和安全飞地，从而简化设备云配置。如果您正在改进或改造现有设计，您的选择可能看起来更加有限，但您仍然可以选择让您的设备以 IoT 容量连接。最后，通过示例和轶事，您可以见证 AWS IoT 提供了与我们的芯片合作伙伴解决方案完美搭配的设备云配置解决方案。现在是时候开始构建安全地委托和配置的物联网设备了！