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 

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
CryptoAuthentication device meets these requirements, providing a simple drop-in solution for designers building devices for AWS IoT.
與AWS合做開發的"通用"Microchip預配置版本ATECC508A 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 AWS zero-touch provisioning kit (Figure 2).
或者，他們可使用Microchip評估器件AT88CKECC-AWS-XSTK 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一塊兒提供AT88CKECCROOTroot 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:

1. wolfSSL Atmel ATECC508A

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號

聯繫郵箱：public@space-explore.com

(未經贊成，請勿轉載)