Take Zero-Touch Approach Lock Down IoT Device 采用零接触方式锁定物联网设备
The demonstrated ability of hackers to penetrate IoT devices says more about the level of security of these devices than the skill of the hackers: in most cases, the affected products lack the most basic security provisions. That said, basic security is simple conceptually, but its implementation requires careful attention at every node in a system to avoid vulnerabilities.
黑客入侵物联网设备的能力比黑客的技能更能说明这些设备的安全性：在大多数情况下，受影响的产品缺乏最基本的安全措施。也就是说，基本安全在概念上很简单，但是它的实现需要在系统中的每个节点上仔细关注以避免漏洞。
A pre-built security solution from
一个预先构建的安全解决方案 Microchip Technology allows developers to implement zero-touch device provisioning in IoT applications built around the Amazon Web Services (AWS) IoT service.
允许开发人员在围绕亚马逊网络服务（AWS）物联网服务构建的物联网应用中实施零接触设备配置。
Security requirements {#article}
A world of IoT connected devices presents a rich prize to hackers intent on controlling, disrupting, or corrupting critical applications in industry, transportation, health, and emergency services, among others. Increasingly, IoT developers are addressing the safety of data in transit by encrypting communications between devices and their hosts. Yet, data encryption represents only a portion of the requirements for end-to-end security.
物联网连接设备的世界为黑客提供了丰厚的奖励，旨在控制，破坏或破坏工业，运输，健康和紧急服务等关键应用。物联网开发人员越来越多地通过加密设备与其主机之间的通信来解决传输中数据的安全问题。然而，数据加密仅代表端到端安全性要求的一部分。
A secure IoT application also depends upon secure authentication to ensure that known devices communicate with trusted hosts. The lack of assurance in device or host identity leaves an open door for attackers to take control of the data stream using man-in-the-middle attacks. In these attacks, bad actors represent themselves as trusted end devices in order to insert corrupted data streams into an application. Alternatively, attackers falsely represent themselves as known hosts to take control of IoT devices.
安全的IoT应用程序还依赖于安全身份验证，以确保已知设备与可信主机通信。设备或主机身份缺乏保证为攻击者利用中间人攻击控制数据流敞开了大门。在这些攻击中，坏的actor将自己表示为可信的终端设备，以便将损坏的数据流插入到应用程序中。或者，攻击者错误地将自己表示为控制IoT设备的已知主机。
Although their ability to break encryption lies at the heart of these approaches, the real damage lies in their ability to intrude themselves as authorized entities into trusted networks with all the potential harm that might entail. Consequently, IoT applications lend themselves to more sophisticated service platforms that address security on a broad level.
虽然他们破解加密的能力是这些方法的核心，但真正的损害在于他们将自己作为授权实体侵入可信网络的能力，并带来可能带来的所有潜在伤害。因此，物联网应用程序适用于更复杂的服务平台，可以在广泛的层面上解决安全问题。
Use a secure cloud platform
Amazon Web Services (AWS) IoT platform provides a comprehensive environment that embeds security as a fundamental capability as it serves the diverse functional requirements of IoT applications. As a specialized front end to diverse AWS services, AWS IoT sits between the IoT device and its application, using a message-based architecture to secure and administer IoT devices (Figure 1).
亚马逊网络服务（AWS）物联网平台提供了一个全面的环境，将安全性作为基本功能嵌入其中，因为它满足物联网应用的各种功能需求。作为各种AWS服务的专用前端，AWS IoT位于物联网设备及其应用之间，使用基于消息的架构来保护和管理物联网设备（图1）。
Figure 1: The Amazon Web Services IoT platform connects IoT devices with the broad family of AWS services, leveraging AWS security mechanisms to perform mutual authentication between IoT devices and the AWS platform. (Image source: Amazon Web Services)
As messages arrive from IoT end devices, developer-defined rules initiate appropriate actions involving other AWS services that work on behalf of the IoT application. In turn, the IoT application software interacts with cloud-based device shadows that maintain the last known state of the corresponding physical IoT devices. This shadowing ensures continued operation of the IoT application, even if the physical devices momentarily go offline. This service model depends upon a sophisticated set of security mechanisms that are designed to identify trusted entities and control their access to available resources.
当消息从IoT终端设备到达时，开发人员定义的规则会启动涉及代表IoT应用程序工作的其他AWS服务的相应操作。反过来，IoT应用软件与基于云的设备阴影交互，这些阴影维持相应物理IoT设备的最后已知状态。即使物理设备暂时脱机，此阴影也可确保物联网应用程序的持续运行。此服务模型依赖于一组复杂的安全机制，这些机制旨在识别可信实体并控制其对可用资源的访问。
At the heart of the AWS security model are identity and access management (IAM) policies. These spell out which devices, users, or services are permitted to access which specific resources within the IoT network, AWS environment, or the application. To a large extent, the success of this security model hinges upon reliable authentication of the entity (user, device, or service) requesting access to a particular resource. If bad actors are able to fool the security system into authenticating them as fully trusted users, the barriers presented by access rights rules effectively dissolve.
AWS安全模型的核心是身份和访问管理（IAM）策略。这些说明允许哪些设备，用户或服务访问IoT网络，AWS环境或应用程序中的哪些特定资源。在很大程度上，该安全模型的成功取决于对请求访问特定资源的实体（用户，设备或服务）的可靠认证。如果不良行为者能够欺骗安全系统将其作为完全信任的用户进行身份验证，那么访问权限规则所带来的障碍就会有效地消失。
As with general web access, AWS uses public key infrastructure (PKI) keys and standard X.509 certificates. In fact, AWS security services use an authentication model familiar to web users. For secure web links, web browsers rely on underlying mechanisms such as transport layer security (TLS) services that check site certificates to authenticate the host server prior to establishing secure communications. More sensitive web-based applications supplement host authentication with client authentication, using a client certificate in the user’s browser to confirm the user’s identity.
与一般Web访问一样，AWS使用公钥基础结构（PKI）密钥和标准X.509证书。实际上，AWS安全服务使用Web用户熟悉的身份验证模型。对于安全的Web链接，Web浏览器依赖于基础机制，例如传输层安全性（TLS）服务，它们在建立安全通信之前检查站点证书以验证主机服务器。更敏感的基于Web的应用程序通过客户端身份验证补充主机身份验证，使用用户浏览器中的客户端证书来确认用户的身份。
Deployments of this kind of mutual authentication remain relatively rare in general web usage because few users are willing or able to take the steps needed to acquire their own client certificates and provision their browsers with those certificates. Yet, mutual authentication is key to reducing the attack surfaces available to bad actors. In fact, the AWS IoT service requires mutual authentication between an IoT device and the AWS cloud. If mutual authentication is difficult in general web usage, it presents significant challenges to IoT developers.
在一般的Web使用中，这种相互认证的部署仍然相对较少，因为很少有用户愿意或能够采取获取他们自己的客户端证书所需的步骤并为他们的浏览器提供这些证书。然而，相互认证是减少坏人可用的攻击面的关键。实际上，AWS IoT服务需要在物联网设备和AWS云之间进行相互身份验证。如果在一般Web使用中难以进行相互身份验证，则会给物联网开发人员带来重大挑战。
To implement mutual authentication in IoT devices, developers need to overcome multiple hurdles. Besides dealing with the logistics of key and certificate acquisition, developers need to store those secrets securely with no possibility of unauthorized access. In addition, the IoT device needs the ability to execute encryption algorithms in a way that remains immune to penetration, all the while maintaining the overall performance of the IoT device.
要在物联网设备中实现相互身份验证，开发人员需要克服多个障碍。除了处理密钥和证书获取的物流外，开发人员还需要安全地存储这些秘密，不会有未经授权的访问。此外，物联网设备需要能够以一种不受渗透影响的方式执行加密算法，同时保持物联网设备的整体性能。
Developed in collaboration with AWS, pre-configured versions of the “generic” Microchip
与AWS合作开发的”通用”Microchip预配置版本 ATECC508A CryptoAuthentication device meets these requirements, providing a simple drop-in solution for designers building devices for AWS IoT.
CryptoAuthentication设备满足这些要求，为设计人员构建AWS IoT设备提供了简单的插入式解决方案。
Dedicated crypto
Created specifically for secure authentication, the ATECC508A IC combines hardware-based PKI algorithms and secure storage in a design that resists attack through physical, electrical, or software means. The device connects through its I^2^C interface to a design’s host CPU. The host CPU then uses a simple command set to perform encryption, update the stored certificate, and access other ATECC508A functions. In fact, the ATECC508A internally generates private keys and stores them securely, eliminating the need for off-chip key management. Because the integrated crypto engine works with secure data within the same chip, the crypto secrets are never exposed on the external bus where they might be intercepted.
ATECC508A IC专为安全认证而设计，将基于硬件的PKI算法和安全存储结合在一起，通过物理，电气或软件方式抵御攻击。该设备通过其I ^ 2 ^ C接口连接到设计的主机CPU。然后，主机CPU使用简单的命令集来执行加密，更新存储的证书以及访问其他ATECC508A功能。实际上，ATECC508A在内部生成私钥并安全存储它们，无需进行片外密钥管理。由于集成加密引擎与同一芯片内的安全数据一起工作，因此加密秘密永远不会暴露在可能被截获的外部总线上。
In offloading crypto execution from the host processor, the ATECC508A not only enhances security, but it does so without compromising performance. Designs using the ATECC508A can achieve TLS connections significantly faster than software-only TLS implementations. In benchmark tests, ATECC508A-based systems completed TLS connections more than five times faster on average than software-only implementations using a high performance ARM® Cortex®-M0-based processor^1^.
在从主处理器卸载加密执行时，ATECC508A不仅增强了安全性，而且在不影响性能的情况下实现了这一点。使用ATECC508A进行设计可以比仅使用软件的TLS实现更快地实现TLS连接。在基准测试中，基于ATECC508A的系统完成TLS连接的速度比使用高性能ARM®Cortex®-M0处理器的纯软件实现平均快5倍^ 1 ^。
The ATECC508A offers substantial benefits for IoT designers, but in its generic form it remains essentially a blank slate for authentication applications. Although the device internally generates private keys, it requires development organizations to acquire and load trusted X.509 certificates. Certificates build on a hierarchy of trust, where root certificates sign certificates used on hosts and clients. Building this trust hierarchy is fundamental to secure systems and applications. For developers, however, the detailed logistics of certificate generation and registration represents a significant complication. Worse, certificate generation for prototypes or pre-production systems can simply be a waste of time when production units use a separate root certificate or a different chain of certificates. A pre-configured ATECC508A provides a simpler solution for engineers using the AWS IoT platform in pre-production designs.
ATECC508A为物联网设计人员提供了巨大的好处，但在其通用形式中，它基本上仍然是认证应用的空白板块。虽然设备在内部生成私钥，但它需要开发组织获取和加载受信任的X.509证书。证书构建在信任层次结构上，其中根证书签署主机和客户端上使用的证书。构建此信任层次结构是安全系统和应用程序的基础。然而，对于开发人员而言，证书生成和注册的详细后勤代表了一个重要的复杂因素。更糟糕的是，当生产单元使用单独的根证书或不同的证书链时，原型或预生产系统的证书生成可能只是浪费时间。预先配置的ATECC508A为在预生产设计中使用AWS IoT平台的工程师提供了更简单的解决方案。
Using the pre-configured ATECC508A devices, designers can implement authentication simply by dropping the device into their designs and connecting it to their host MCU through an I^2^C port. Available in 8-lead UDFN (
使用预先配置的ATECC508A器件，设计人员只需将器件放入其设计并通过I ^ 2 ^ C端口连接到主机MCU即可实现验证。提供8引脚UDFN（ ATECC508A-MAHAW-S ) and 8-lead SOIC (
) and 8-lead SOIC ( ATECC508A-SSHAW-T ) versions, the devices are pre-provisioned with the necessary client certificates and pre-configured to work with AWS IoT. Developers can solder the device into their own designs and interact with AWS IoT using application programming interfaces (APIs). These APIs reside within the AWS software development kit (SDK) libraries hosted on their target system.
）版本，设备预先配置了必要的客户端证书，并预先配置为使用AWS IoT。开发人员可以将设备焊接到他们自己的设计中，并使用应用程序编程接口（API）与AWS IoT进行交互。这些API位于其目标系统上托管的AWS软件开发工具包（SDK）库中。
Alternatively, they can evaluate the device using the Microchip
或者，他们可以使用Microchip评估器件 AT88CKECC-AWS-XSTK AWS zero-touch provisioning kit (Figure 2).
AWS零接触配置套件（图2）。
Figure 2: The Microchip Technology AT88CKECC-AWS-XSTK AWS Zero Touch Provisioning Kit provides a complete wireless IoT design built around a SAM G MCU board (center), ATECC508A-xxxAW device board (left), ATWINC1500-XSTK RF board (right), and ATOLED1-XPRO display board with buttons and switches to mimic IoT events (bottom). (Image source: Microchip Technology)
Along with
Along with ATCRYPTOAUTH-XPRO Crypto eval boards for the ATECC508, the kit provides a complete IoT design prototype, comprising the
用于ATECC508的加密评估板，该套件提供了完整的物联网设计原型，包括 ATSAMG55-XPRO SAM G MCU board,
SAM G MCU board, ATWINC1500-XSTK RF board, and the
RF board, and the ATOLED1-XPRO board with display, buttons, and switches used to simulate IoT data events.
带有显示，按钮和开关的电路板，用于模拟物联网数据事件。
Zero-touch provisioning
Whether working from a custom prototype or the starter kit, developers can implement AWS mutual authentication with the ATECC508A-xxxAW by simply plugging the device into a design. The advantages of the ATECC508A-xxxAW become evident the first time the device connects with AWS IoT.
无论是使用自定义原型还是入门套件，开发人员都可以通过简单地将设备插入设计中来实现与ATECC508A-xxxAW的AWS相互认证。当设备首次与AWS IoT连接时，ATECC508A-xxxAW的优势变得明显。
On initial connection, the ATECC508A-xxxAW device interacts with AWS IoT to automatically complete the AWS just-in-time registration (JITR) process that uniquely identifies each IoT device within AWS IoT. Additionally, IoT developers can extend this concept of zero-touch provisioning beyond designs based on these pre-configured ATECC508A versions.
在初始连接时，ATECC508A-xxxAW设备与AWS IoT交互以自动完成AWS实时注册（JITR）流程，该流程可唯一标识AWS IoT中的每个IoT设备。此外，物联网开发人员可以将这种零接触配置概念扩展到基于这些预先配置的ATECC508A版本的设计之外。
Commonly used in IT network environments, zero-touch provisioning (ZTP) allows network equipment deployments to proceed without user intervention. At startup, the network identifies new network equipment and authorizes its connection to the network, just as AWS JITR automatically provisions pre-configured IoT devices. For IoT applications expected to encompass massive numbers of devices, ZTP represents a particularly important concept. Using the Microchip AT88CKECC-AWS-XSTK starter kit, developers can gain a better understanding of the details behind certificate provisioning and ZTP using AWS JITR. In particular, developers can explore the use of custom software using AWS’s serverless Lambda service to address unique requirements for the ZTP process.
零触摸配置（ZTP）通常用于IT网络环境，允许在无需用户干预的情况下继续进行网络设备部署。在启动时，网络识别新的网络设备并授权其与网络的连接，就像AWS JITR自动配置预先配置的IoT设备一样。对于预计包含大量设备的物联网应用，ZTP代表了一个特别重要的概念。使用Microchip AT88CKECC-AWS-XSTK入门套件，开发人员可以使用AWS JITR更好地了解证书配置和ZTP背后的详细信息。特别是，开发人员可以使用AWS的无服务器Lambda服务探索定制软件的使用，以满足ZTP流程的独特需求。
Along with the IoT design hardware mentioned above, the starter kit comes with the Microchip
与上面提到的物联网设计硬件一起，入门套件随Microchip一起提供 AT88CKECCROOT root module utility and
根模块实用程序和 AT88CKECCSIGNER signer module utility. The root and signer modules each come with a USB dongle that contains root keys and signing keys, respectively.
签名者模块实用程序。根和签名者模块每个都带有一个USB加密狗，分别包含根密钥和签名密钥。
Working with the starter kit, developers connect the AT88CKECC-AWS-XSTK and modules via USB to their PC, which should be running the starter kit software package. The starter kit application walks users through the details of registering certificates on AWS IoT. It uses the root and signer modules mentioned above to represent the roles of the actual root certificates and signing certificates that will eventually be used during manufacturing. For production units, a similar process would occur in the Microchip manufacturing facility where “blank” ATECC508As are configured using certificates that build upon the development organization’s own root of trust (Figure 3).
开发人员使用入门工具包，开发人员将AT88CKECC-AWS-XSTK和模块通过USB连接到PC，PC应运行入门工具包软件包。入门工具包应用程序向用户介绍在AWS IoT上注册证书的详细信息。它使用上面提到的根和签名者模块来表示最终将在制造期间使用的实际根证书和签名证书的角色。对于生产单元，Microchip制造工厂中会出现类似的过程，其中”空白”ATECC508A使用基于开发组织自身信任根的证书进行配置（图3）。
Figure 3: Although the ATECC508A-xxxAW series comes pre-configured by Microchip for AWS IoT, production of devices for customer designs would use a tool such as the AT88CKECCSIGNER signer module to create custom device certificates that build on the development organization’s root of trust. (Image source: Microchip Technology)
Microchip supports the starter kit with a software package that reduces operations and interactions with AWS IoT to a few simple software calls. For example, the main routine in the sample application calls aws_demo_tasks_init(), which launches a series of separate tasks associated with each hardware component in the starter kit.
Microchip通过软件包支持入门工具包，该软件包可将操作和与AWS IoT的交互减少到几个简单的软件调用。例如，示例应用程序中的主例程调用aws_demo_tasks_init（），它会启动与入门工具包中的每个硬件组件关联的一系列单独任务。
Developers can leverage the sample code set to create their own ATECC508-based designs for AWS IoT applications. In fact, the kit builds on the same CryptoAuthLib C-language offered as a standard package for ATECC508 software support. The starter kit simply converts higher-level calls to a series of low-level calls to the CryptoAuthLib library’s “at” routines (Listing 1).
开发人员可以利用示例代码集为AWS IoT应用程序创建自己的基于ATECC508的设计。事实上，该套件基于相同的CryptoAuthLib C语言，作为ATECC508软件支持的标准软件包提供。入门工具包只是将更高级别的调用转换为对CryptoAuthLib库的”at”例程的一系列低级调用（清单1）。
/**
* \brief Send a command array to ATECC508A over I2C.
*
* \param[in] tx_buffer Buffer to be sent
* \return ATCA_SUCCESS On 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;
/* Collect command information from TX buffer. */
if (aws_prov_get_commands_info(tx_buffer, &cmd_index, &rx_length) != ATCA_SUCCESS)
break;
cmd_buffer = (uint8_t *)malloc(tx_buffer[0] + 1);
memcpy(&cmd_buffer[1], tx_buffer, tx_buffer[0]);
/* Initialize every objects. */
_gDevice= atcab_getDevice();
_gCommandObj = atGetCommands(_gDevice);
_gIface = atGetIFace(_gDevice);
/* Get command execution time. */
execution_time = atGetExecTime(_gCommandObj, cmd_index);
if ((status = atcab_wakeup()) != ATCA_SUCCESS )
break;
/* Send command. */
if ((status = atsend( _gIface, (uint8_t *)cmd_buffer, tx_buffer[0])) != ATCA_SUCCESS)
break;
.
.
.
} while(0);
return status;
}
Listing 1: The starter kit software package builds on the standard ATECC508 CryptoAuthLib C library, using a series of CryptoAuthLib “at” calls to implement higher order functionality such as sending commands from the MCU to the ATECC508A. (Code source: Microchip Technology)
For developers working in custom environments, the CryptoAuthLib provides a well-defined architecture that isolates hardware dependencies into a hardware abstraction layer (HAL) (Figure 4). By modifying the HAL routines, developers can build in support for their unique operating environments.
对于在自定义环境中工作的开发人员，CryptoAuthLib提供了一个定义良好的体系结构，可将硬件依赖性隔离到硬件抽象层（HAL）中（图4）。通过修改HAL例程，开发人员可以构建对其独特操作环境的支持。
Figure 4: The multilayered CryptoAuthLib architecture isolates hardware dependencies into a hardware abstraction layer that simplifies porting the library to different operating environments. (Image source: Microchip Technology)
Conclusion
Mutual authentication provides the most secure approach to communications between devices, users, and services, and has emerged as a requirement in AWS IoT. Yet, implementation of mutual authentication presents significant challenges for IoT device deployments. Its success depends on efficient methods for reliably provisioning IoT devices with the intellectual property underlying secure communications protocols.
相互身份验证为设备，用户和服务之间的通信提供了最安全的方法，并且已成为AWS IoT中的一项要求。然而，相互认证的实施对物联网设备部署提出了重大挑战。它的成功取决于有效配置具有安全通信协议的知识产权的物联网设备的有效方法。
Microchip’s pre-configured ATECC508 devices remove traditional barriers to implementation of mutual authentication and provide developers with a drop-in solution to IoT applications designed for AWS IoT. Using these devices, developers can implement ZTP that eliminates manual intervention in IoT device deployment, relying instead on automatic recognition and registration of IoT devices.
Microchip预先配置的ATECC508器件消除了实现相互认证的传统障碍，并为开发人员提供了针对AWS IoT设计的物联网应用的直接解决方案。使用这些设备，开发人员可以实施ZTP，消除物联网设备部署中的人工干预，而不是依赖于物联网设备的自动识别和注册。
Reference:
Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.
免责声明：本网站上各作者和/或论坛参与者表达的观点，信念和观点不一定反映Digi-Key Electronics的意见，信念和观点，也不一定反映Digi-Key Electronics的官方政策。
公众号:银河系1号
公众号:银河系1号
联系邮箱：public@space-explore.com
联系邮箱：public@space-explore.com
(未经同意，请勿转载)
(未经同意，请勿转载)
About The Author
