盡管人們越來越意識到需要安全性，但開發人員經常發現自己在安全性方面采取了快捷方式，將物聯網設備連接到云端。在許多情況下，合適的安全機制的復雜性，微型電池供電的物聯網設備中可用的有限內存和處理資源以及運輸產品的需求之間的沖突似乎是不可克服的。

解決這些問題和為簡化物聯網設備中安全功能的實施，Microchip Technology和Google合作創建了一種方法，將Microchip的安全硬件功能與稱為JSON Web令牌（JWT）的簡單數據結構相結合。結果是確保物聯網設備與Google Cloud IoT核心服務之間相互身份驗證的簡便方法。

本文將介紹物聯網設備安全威脅，并介紹當前用于應對該威脅的設備。它將確定安全漏洞以及開發人員和嵌入式系統設計人員如何使用JWT關閉它們。

物聯網設備的安全漏洞

對物聯網設備的攻擊可以采取多種形式，絕不僅限于大規模的物聯網部署。對于希望利用用于分布式拒絕服務（DDoS）攻擊的僵尸網絡中的許多單個設備的資源的黑客來說，即使是最小的物聯網也是一個很有吸引力的目標。因此，每一類物聯網設備的設計者都不可避免地需要通過基于硬件的強大安全機制來保護他們的系統，從而阻止攻擊。

例如，使用系統內存或閃存存儲用于加密和身份驗證的私鑰會使IoT設備容易受到攻擊。更糟糕的是，黑客可以竊取這些密鑰并使用它們來訪問物聯網網絡和附加的公司資源。

安全IC

Microchip Technology的CryptoMemory和CryptoAuthentication IC等專用安全設備具有硬件功能基于保護私鑰和其他秘密數據的機制。 EEPROM陣列集成在這些器件中，提供安全存儲，只能通過器件的SPI或I 2 C串行接口訪問的加密安全機制（圖1）。因此，這些設備提供了一種向任何物聯網設備設計添加安全存儲和其他安全功能的簡單方法。

圖1：Microchip Technology硬件安全設備（如AT88SC0204C CryptoMemory IC）提供安全存儲，使用集成加密機制保護對片上EEPROM的訪問。 （圖片來源：Microchip Technology）

Microchip CryptoAuthentication系列的成員（如ATECC608A）增強了安全存儲基礎，并支持安全設計中常用的加密算法。在其硬件功能中，該器件具有多種算法的硬件加速功能，包括：

非對稱加密算法：

FIPS186-3橢圓曲線數字簽名算法（ECDSA）

FIPS SP800-56A橢圓曲線Diffie-Hellman（ECDH）

NIST標準P256橢圓曲線加密（ECC）

對稱加密算法：

SHA-256哈希密碼術

基于哈希的消息身份驗證代碼（HMAC）密碼術

AES-128密碼術

AES-GCM（ Galois字段乘法）密碼學

密鑰派生函數（KDF）：

偽隨機函數（PRF）KDF

基于HMAC的提取 - 并且擴展KDF（HKDF）

對于加密專家來說，這組加密功能代表了支持更高級別安全協議所需的全面機制列表。身份驗證和安全數據交換。例如，KDF功能提供了傳輸層安全性（TLS）協議所需的基本機制，用于在交換甚至開始之前驗證數據交換會話中的參與者。

在此協議中，TLS會話以客戶端向服務器發送啟動安全會話的請求。服務器使用其數字證書進行響應，客戶端使用該證書來確認服務器的身份。在客戶端以這種方式驗證服務器之后，會話設置繼續通過使用服務器的公鑰來生成會話密鑰，以加密使用PRF KDF或更強大的HDKF創建的一些隨機值。

TLS身份驗證協議是Internet安全的基礎。稱為證書頒發機構（CA）的整個證書提供商行業已經發展為支持安全通信的這一關鍵組件。公司從CA獲得可信證書，以便在自己的服務器上安裝，以支持上述標準TLS服務器身份驗證協議。

對于物聯網應用，網絡與公司來源廣泛而深入地連接，這種單向認證不足以確保保護。例如，具有欺詐性證書的黑客可以將自己表示為物聯網設備的合法服務器，作為更廣泛攻擊的一部分。

盡管存在風險，但物聯網開發人員經常難以實施TLS相互身份驗證協議，因為證書，密鑰，使用TLS實現客戶端身份驗證所需的軟件可能會超出許多物聯網設備的功能。通過合作，Microchip Technology和Google創建了一種替代方法，將ATECC608A功能與稱為JSON Web令牌（JWT）的簡單數據結構相結合。結果是確保物聯網設備與Google Cloud IoT核心服務之間相互身份驗證的簡便方法。

基于JWT的身份驗證

在RFC 7519中指定，JWT是行業標準容器關于準備和傳輸JWT的實體的信息，稱為索賠。 JWT結構本身包含三個部分：

標題，包括JSON名稱：密碼算法的名稱（“alg”）的值對（例如，ECDSA的“EC256”使用NIST P-256曲線）用于簽署令牌和令牌的類型（“typ”）（這些令牌的“JWT”）

Payload，包括JSON名稱：每個索賠的值對

簽名，它使用標頭中指定的算法來編碼密鑰以及標頭和聲明集，每個單獨轉換為加密前的base64 URL編碼表示

RFC 7519為在有效負載或其他部分中指定聲明提供了極大的靈活性。該標準甚至允許在沒有簽名或加密的情況下創建的不安全JWT，在這種情況下，標頭將包括算法的名稱：值對{{alg“：”none“}。對于與Google Cloud IoT核心服務一起使用的JWT，Google需要簽名部分以及包含三個強制聲明的有效負載，包括：

“iat” - 以ISO 8601 UTC時間戳格式創建令牌時的“頒發時間”，自1970-01-01T00：00：00Z以來的秒數（例如，2019年6月30日的1561896000 12 ：格林威治標準時間00:00 PM）

“exp” - 指定令牌到期時間的UTC時間戳，最大24小時超過“iat”值加上10分鐘寬限期，以解決不同之間的系統時鐘偏差客戶端和服務器（例如，2019年7月1日1561982400，格林威治標準時間00:00 00:00）

“aud” - 包含開發人員Google Cloud項目ID的字符串

< p> Google的物聯網設備身份驗證方案將基于TLS的常規服務器身份驗證與使用這些相對簡單的聲明創建的JWT進行物聯網設備身份驗證相結合。要啟動新會話，IoT設備會打開一個到服務器的安全套接字，并使用前面描述的相同TLS協議對服務器進行身份驗證。

此過程的下一步依賴于Google IoT云對用于物聯網網絡事務的輕量級消息隊列遙測傳輸（MQTT）協議。使用安全套接字到經過身份驗證的服務器，IoT設備使用其唯一的JWT作為登錄密碼“登錄”到該服務器的MQTT主機服務（清單1）。

雖然IoT設備發送用戶名作為此登錄序列的一部分，但用戶名不用于身份驗證。因此，傳輸了一個虛擬用戶名（清單2）。相反，IoT設備的認證基于作為登錄密碼發送的JWT進行。由于JWT簽名是標頭，有效負載和設備私鑰的組合，因此Google Cloud IoT核心服務可以驗證JWT是否真正來自授權設備。對于此驗證，Google Cloud IoT服務使用以前由IoT設備開發人員使用下述密鑰管理流程存儲在Google云中的設備公鑰。與單獨使用TLS相比，此方法通過混合方法提供相互身份驗證，從而加快流程，同時降低物聯網設備資源需求。

關鍵使能器

ATECC608A及其供應鏈的功能是此方法的關鍵推動因素。雖然任何MCU最終都可以從JWT報頭和有效負載生成加密加密簽名，但任何僅使用軟件執行的方法在沒有基于硬件的安全密鑰存儲的情況下仍然容易受到攻擊。此外，對于許多資源有限的物聯網設備或具有嚴格響應時間要求的應用，“僅軟件”實現所需的處理器負載和執行延遲可能是禁止的。最后，沒有豐富的安全算法和更高級協議經驗的開發人員很難實現所需的軟件功能。 Microchip通過其CryptoAuthLib庫解決了這些問題（圖2）。

圖2：因為CryptoAuthLib使用硬件抽象層（HAL）將API函數和核心基元與底層硬件分開，所以開發人員可以定位他們的適用于各種支持設備的軟件。 （圖片來源：Microchip Technology）

Microchip CryptoAuthLib簡化了安全IoT功能的實現，例如Google JWT身份驗證協議，將復雜的安全操作簡化為通過CryptoAuthLib應用程序編程接口（API）提供的一組函數調用。對于物聯網開發人員而言，最重要的可能是Microchip CryptoAuthLib核心功能充分利用了諸如ATECC608A之類的Microchip加密IC，可加快設計中安全功能的執行速度。例如，清單1中對atca_jwt_finalize（）的調用使用可用的加密設備（如ATECC608A）來創建用作清單2中密碼的JWT。在這種情況下，ATECC608A加速JWT簽名的加密，讀取設計的私有來自其集成安全存儲的關鍵，以完成前面描述的簽名創建過程。

然而，即使使用復雜的軟件和安全設備，由于傳統上管理密鑰和證書所需的方法，物聯網設備仍然容易受到攻擊。過去，私鑰需要在外部生成并在制造，分發甚至部署期間加載到安全存儲設備中。即使使用硬件安全模塊和安全設施，在“需要知道”它們的唯一設備之外短暫存在這些秘密代表了可能導致其意外或意圖暴露的安全弱點。通過利用ATECC608A的功能，Microchip和Google在很大程度上消除了傳統的安全漏洞。

在這種新方法中，Microchip使用ATECC608A生成密鑰對的能力，而無需私鑰離開設備（圖3）。然后，Microchip使用中間證書對設備生成的公鑰進行簽名，該證書由客戶提供并存儲在Microchip安全設施內的安全服務器中。最后，Microchip安全地將公鑰傳輸到Google Cloud IoT設備管理器中的客戶帳戶，該設備管理器可為每個設備存儲最多三個公鑰，以支持密鑰輪換策略。部署后，IoT設備可以使用ATECC608A安全功能來創建前面描述的相互身份驗證過程中使用的JWT。

圖3：Microchip Technology和Google Cloud IoT服務相結合，簡化了密鑰和證書的配置，提供了一種旨在加強IoT應用安全性的受保護機制。 （圖片來源：谷歌）

Microchip和Google之間的此次合作讓開發人員可以完全卸載這一關鍵密鑰管理流程。對于自定義要求，開發人員可以使用CryptoAuthLib API函數atcab_genkey（）實現自己的密鑰管理過程，這會導致ATECC608A生成密鑰對，將私鑰存儲在其安全存儲中，并返回關聯的公鑰。/p>

為了探索密鑰生成和其他ATECC608A安全功能，開發人員可以快速建立一個圍繞Microchip SAM D21 Xplained Pro評估套件構建的綜合開發環境。基于Microchip ATSAMD21J18A 32位Arm ? Cortex ? -M0 + MCU，SAM D21 Xplained Pro套件提供了Microchip高級軟件框架（ASF）支持的完整硬件平臺驅動程序和代碼模塊。

為了評估包括ATECC608A在內的CryptoAuthentication設備，開發人員可以簡單地將CryptoAuth XPRO-B附加板插入Xplained Pro板的兩個擴展頭之一。 Microchip提供了用于評估CryptoAuthLib與ATECC608A的安全功能的示例軟件。更進一步，開發人員可以將Microchip ATWINC1500-XPRO Wi-Fi附加板插入另一個標頭，以運行Microchip示例軟件，該軟件演示了本文中描述的相互認證流程，包括TLS服務器認證和JWT設備認證。

結論

雖然物聯網應用安全帶來了多項要求，但關鍵挑戰通常在于為物聯網設備和云資源實施相互身份驗證。在資源有限的物聯網系統中，傳統協議可能超過可用內存和處理資源。使用Microchip Technology CryptoAuthLib庫和ATECC608A CryptoAuthentication IC，開發人員可以實施基于JSON Web Tokens的更高效方法，以便將IoT設備安全地連接到Google Cloud IoT服務。