使用AWS物联网平台管理与保护物联网设备的安全

黑客入侵物联网设备的能力比黑客的技能更能说明这些设备的安全级别：在大多数情况下，受影响的产品缺乏最基本的安全措施。也就是说，基本安全在概念上很简单，但其实现需要在系统中的每个节点上小心注意以避免漏洞。

Microchip Technology的预构建安全解决方案允许开发人员实现零接触设备配置围绕亚马逊网络服务（AWS）物联网服务构建的物联网应用程序。

安全要求

物联网连接设备的世界为黑客提供了丰富的奖励，旨在控制，破坏或破坏工业，运输，健康和紧急服务等领域的关键应用。物联网开发人员越来越多地通过加密设备与其主机之间的通信来解决传输中数据的安全问题。然而，数据加密仅代表端到端安全要求的一部分。

安全IoT应用程序还依赖于安全身份验证，以确保已知设备与可信主机通信。设备或主机身份缺乏保证为攻击者利用中间人攻击控制数据流敞开了大门。在这些攻击中，坏的actor将自己表示为可信的终端设备，以便将损坏的数据流插入到应用程序中。或者，攻击者错误地将自己称为控制物联网设备的已知主机。

虽然他们破解加密的能力是这些方法的核心，但真正的损害在于他们作为授权实体侵入自己的能力。进入可信赖的网络，可能带来所有潜在的伤害。因此，物联网应用程序适用于更加复杂的服务平台，可以在广泛的层面上解决安全问题。

使用安全的云平台

亚马逊网络服务（AWS）物联网平台提供全面的环境它将安全性作为一项基本功能，因为它满足物联网应用的各种功能需求。作为各种AWS服务的专用前端，AWS IoT位于物联网设备及其应用之间，使用基于消息的架构来保护和管理物联网设备（图1）。

图1：Amazon Web Services物联网平台将物联网设备与广泛的AWS服务系列连接起来，利用AWS安全机制在物联网之间执行相互身份验证设备和AWS平台。 （图像来源：Amazon Web Services）

当消息从IoT终端设备到达时，开发人员定义的规则会启动涉及代表IoT应用程序工作的其他AWS服务的相应操作。反过来，IoT应用软件与基于云的设备阴影交互，这些阴影维持相应物理IoT设备的最后已知状态。即使物理设备暂时脱机，此阴影也可确保物联网应用程序的持续运行。此服务模型依赖于一组复杂的安全机制，旨在识别可信实体并控制其对可用资源的访问。

AWS安全模型的核心是身份和访问管理（IAM）策略。这些说明允许哪些设备，用户或服务访问IoT网络，AWS环境或应用程序中的哪些特定资源。在很大程度上，该安全模型的成功取决于对请求访问特定资源的实体（用户，设备或服务）的可靠认证。如果不良行为者能够欺骗安全系统将其作为完全信任的用户进行身份验证，那么访问权限规则所带来的障碍就会有效解除。

与一般Web访问一样，AWS使用公钥基础结构（PKI）密钥和标准X.509证书。实际上，AWS安全服务使用Web用户熟悉的身份验证模型。对于安全的Web链接，Web浏览器依赖于基础机制，例如传输层安全性（TLS）服务，它们在建立安全通信之前检查站点证书以验证主机服务器。更敏感的基于Web的应用程序通过客户端身份验证补充主机身份验证，使用用户浏览器中的客户端证书来确认用户的身份。

这种相互身份验证的部署在一般Web使用中仍然相对较少，因为很少用户愿意或能够采取获取自己的客户端证书所需的步骤，并使用这些证书配置他们的浏览器。然而，相互认证是减少坏人可用的攻击面的关键。实际上，AWS IoT服务需要在物联网设备和AWS云之间进行相互身份验证。如果在一般Web使用中难以进行相互身份验证，则会给物联网开发人员带来重大挑战。

要在物联网设备中实现相互身份验证，开发人员需要克服多个障碍。除了处理密钥和证书获取的物流外，开发人员还需要安全地存储这些机密，不会有未经授权的访问。此外，物联网设备还需要能够以不受渗透影响的方式执行加密算法，同时保持物联网设备的整体性能。

与AWS合作开发，预先配置“通用”Microchip ATECC508A CryptoAuthentication设备的版本满足这些要求，为设计人员构建AWS IoT设备提供了简单的插入式解决方案。

专用加密

专为安全认证而创建ATECC508A IC将基于硬件的PKI算法和安全存储结合在一起，通过物理，电气或软件方式抵御攻击。该器件通过其I 2 C接口连接到设计的主机CPU。然后，主机CPU使用简单的命令集来执行加密，更新存储的证书以及访问其他ATECC508A功能。实际上，ATECC508A在内部生成私钥并安全存储它们，无需进行片外密钥管理。由于集成加密引擎可以在同一芯片内使用安全数据，因此加密机密码永远不会暴露在可能被截获的外部总线上。

在卸载主机处理器的加密执行时，ATECC508A不仅增强安全性，但它不会影响性能。使用ATECC508A进行设计可以比仅使用软件的TLS实现更快地实现TLS连接。在基准测试中，基于ATECC508A的系统完成TLS连接的速度比使用高性能ARM®Cortex®-M0处理器 1 的纯软件实现平均快5倍。

< p> ATECC508A为物联网设计人员提供了巨大的好处，但在其通用形式中，它基本上仍然是认证应用的空白板块。虽然设备在内部生成私钥，但它需要开发组织获取并加载受信任的X.509证书。证书构建在信任层次结构上，其中根证书签署主机和客户端上使用的证书。构建此信任层次结构是安全系统和应用程序的基础。然而，对于开发人员而言，证书生成和注册的详细后勤代表了一个重要的复杂因素。更糟糕的是，当生产单元使用单独的根证书或不同的证书链时，原型或预生产系统的证书生成可能只是浪费时间。预先配置的ATECC508A为在预生产设计中使用AWS IoT平台的工程师提供了更简单的解决方案。

使用预先配置的ATECC508A器件，设计人员只需将器件放入其设计中即可实现认证。通过I 2 C端口将其连接到主机MCU。这些器件采用8引脚UDFN（ATECC508A-MAHAW-S）和8引脚SOIC（ATECC508A-SSHAW-T）版本，预先配置了必要的客户端证书，并预先配置为可与AWS IoT配合使用。开发人员可以将设备焊接到他们自己的设计中，并使用应用程序编程接口（API）与AWS IoT进行交互。这些API位于其目标系统上托管的AWS软件开发工具包（SDK）库中。

或者，他们可以使用Microchip AT88CKECC-AWS-XSTK AWS零接触配置套件评估器件（图2） ）。

图2：Microchip Technology AT88CKECC-AWS-XSTK AWS Zero Touch Provisioning Kit提供围绕SAM G MCU板（中心），ATECC508A-xxxAW器件板（左），ATWINC1500-XSTK RF板构建的完整无线物联网设计（右）和ATOLED1-XPRO显示板，带有按钮和开关，用于模拟物联网事件（下图）。 （图片来源：Microchip Technology）

该套件与用于ATECC508的ATCRYPTOAUTH-XPRO加密评估板一起提供完整的物联网设计原型，包括ATSAMG55-XPRO SAM G MCU板，ATWINC1500-XSTK RF板，ATOLED1-XPRO板，带有显示，按钮和开关，用于模拟物联网数据事件。

零接触配置

无论是使用自定义原型还是入门套件，开发人员只需将设备插入设计即可与ATECC508A-xxxAW实施AWS相互认证。当设备首次与AWS IoT连接时，ATECC508A-xxxAW的优势变得明显。

在初始连接时，ATECC508A-xxxAW设备与AWS IoT交互以自动完成AWS即时注册（JITR）流程，用于唯一标识AWS IoT中的每个IoT设备。此外，物联网开发人员可以将这种零接触配置概念扩展到基于这些预先配置的ATECC508A版本的设计之外。

通常用于IT网络环境，零接触配置（ZTP）允许网络设备部署到无需用户干预即可继续在启动时，网络识别新的网络设备并授权其与网络的连接，就像AWS JITR自动配置预先配置的IoT设备一样。对于预计包含大量设备的物联网应用，ZTP代表了一个特别重要的概念。使用Microchip AT88CKECC-AWS-XSTK入门套件，开发人员可以使用AWS JITR更好地了解证书配置和ZTP背后的详细信息。特别是，开发人员可以使用AWS的无服务器Lambda服务探索定制软件的使用，以满足ZTP过程的独特要求。

除上述IoT设计硬件外，入门套件还附带Microchip AT88CKECCROOT root模块实用程序和AT88CKECCSIGNER签名模块实用程序。根和签名者模块每个都带有一个USB加密狗，分别包含根密钥和签名密钥。

使用入门工具包，开发人员通过USB将AT88CKECC-AWS-XSTK和模块连接到他们的PC，应该运行入门套件软件包。入门工具包应用程序向用户介绍在AWS IoT上注册证书的详细信息。它使用上面提到的root和signer模块来表示最终将在制造期间使用的实际根证书和签名证书的角色。对于生产单元，Microchip制造工厂中会出现类似的过程，其中“空白”ATECC508A使用基于开发组织自己的信任根构建的证书进行配置（图3）。

图3：虽然Microchip针对AWS IoT预先配置了ATECC508A-xxxAW系列，但为客户设计生产的设备将使用此类工具作为AT88CKECCSIGNER签名者模块，用于创建基于开发组织信任根的自定义设备证书。 （图像来源：Microchip Technology）

Microchip支持带有软件包的入门套件，该套件可将操作和与AWS IoT的交互减少到一些简单的软件调用。例如，示例应用程序中的主例程调用aws_demo_tasks_init（），它会启动与入门工具包中的每个硬件组件关联的一系列单独任务。

开发人员可以利用示例代码集为AWS IoT应用程序创建自己的基于ATECC508的设计。事实上，该套件基于相同的CryptoAuthLib C语言，作为ATECC508软件支持的标准软件包提供。入门工具包只是将更高级别的调用转换为对CryptoAuthLib库的“at”例程的一系列低级调用（清单1）。

/**

* brief通过I2C向ATECC508A发送命令数组。

*

* param [in] tx_buffer要发送的缓冲区

* return ATCA_SUCCESS成功

*/

uint8_t aws_prov_send_command（uint8_t * tx_buffer）

{

uint8_t status = ATCA_SUCCESS;

uint8_t cmd_index;

uint16_t rx_length;

uint16_t execution_time = 0;

uint8_t * cmd_buffer;

ATCADevice _gDevice = NULL;

ATCACommand _gCommandObj = NULL ;

ATCAIface _gIface = NULL;

do {

<代码>

if（tx_buffer == NULL）

break;

/*从TX缓冲区收集命令信息。 */

if（aws_prov_get_commands_info（tx_buffer，＆amp; cmd_index，＆amp; rx_length）！= ATCA_SUCCESS）

break;

cmd_buffer =（uint8_t *）malloc（tx_buffer [0] + 1）;

memcpy（＆amp; cmd_buffer [1]，tx_buffer，tx_buffer [0]）;

/*初始化每个对象。 */

_gDevice = atcab_getDevice（）;

_gCommandObj = atGetCommands（_gDevice）;

_gIface = atGetIFace（_gDevice）;

/*获取命令执行时间。 */

execution_time = atGetExecTime（_gCommandObj，cmd_index）;

if（（status = atcab_wakeup（））！= ATCA_SUCCESS）

break;

/*发送命令。 */

if（（status = atsend（_gIface，（uint8_t *）cmd_buffer，tx_buffer [0]））！= ATCA_SUCCESS）

< p> break;

。

。

。

} while（0）;

退货状态;

}

清单1：入门套件软件包基于标准ATECC508 CryptoAuthLib C库构建，使用一系列CryptoAuthLib“at”调用实现更高阶的功能，例如从MCU向ATECC508A发送命令。 （代码来源：Microchip Technology）

对于在自定义环境中工作的开发人员，CryptoAuthLib提供了一个定义良好的体系结构，可将硬件依赖性隔离到硬件抽象层（HAL）中（图4）。通过修改HAL例程，开发人员可以构建对其独特操作环境的支持。

图4：多层CryptoAuthLib架构将硬件依赖关系分离为硬件抽象层，简化了将库移植到不同操作环境的过程。 （图像来源：Microchip Technology）

结论

相互身份验证为设备，用户和服务之间的通信提供了最安全的方法，并且已成为AWS IoT中的一项要求。然而，相互认证的实施对物联网设备部署提出了重大挑战。它的成功取决于有效配置具有安全通信协议的知识产权的物联网设备的有效方法。

Microchip预先配置的ATECC508器件消除了实现相互认证的传统障碍，并为开发人员提供了直接的解决方案为AWS IoT设计的物联网应用程序。使用这些设备，开发人员可以实施ZTP，消除物联网设备部署中的人工干预，而不是依赖于物联网设备的自动识别和注册。