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）。
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）。
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）。
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;
}
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例程，開發人員可以構建對其獨特操作環境的支援。
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號
聯絡郵箱：public@space-explore.com
(未經同意，請勿轉載)