傳輸層安全性的目的

TLS 的目的是為嵌入式安全支柱做出貢獻：

機密性（加密數據）

完整性（保護數據不被篡改/損壞）

身份驗證（在客戶端和主機之間建立信任）

TLS 和身份驗證齊頭并進。TLS 將啟動并執行加密操作，以建立經過身份驗證和加密的通信隧道。安全元素將存儲和保護TLS協議請求的相關加密密鑰，私鑰是迄今為止最關鍵的密鑰。繼續閱讀以了解為什么如果沒有強大的安全密鑰存儲來保護至少私鑰，加密會很弱。

TLS 用于保護網站到網站的通信，也用于保護基于互聯網協議 （IP） 的物聯網 （IoT） 連接設備。開放系統互連 （OSI） 模型是概念性的，大多數技術并不完全屬于這些層。下面顯示了 TLS 在會話層和表示層之間的位置。

TLS 和身份驗證

TLS 的一個重要部分是身份驗證階段。對于物聯網市場，通常的做法是云平臺和物聯網設備相互進行身份驗證，這稱為相互身份驗證。最常用的技術利用 X509 證書和公鑰基礎設施，因為它只是在嵌入式 deice 上盡可能優化運行計算饑渴的加密算法所需的處理能力，并保持它們相對實惠。有幾個標準，如物聯網消費者EN303645，物聯網工業IEC / ISA62443，電動汽車充電ISO15118和開放充電點協議（OCPP），都建議使用TLS的安全密鑰存儲。ISO15118甚至會告訴我們，如果私鑰由攻擊者控制，并且與支付要交付給車輛的費用相關的金融交易是否可以被冒充并因此被盜。此外，如果您的私鑰被盜，攻擊可能會滲透到整個網絡。

讓我們深入了解身份驗證原則：

數字簽名算法 （DSA）

證書簽名

證書驗證

證書身份驗證

數字簽名算法 （DSA）

在這里，我們解釋了數字簽名算法如何工作的基礎知識：

DSA使用宿主和主體的概念。

主持人向主題發送消息。它們中的每一個都有各自的公鑰/私鑰對，其中公鑰是從私鑰中計算出來的

主題公鑰分發到主機

受試者將提供一個稱為簽名的答案

簽名是使用主題私鑰的消息的加密“簽名”操作的輸出。

然后，主機將使用使用者公鑰驗證簽名。

現在，我們有一個由私鑰簽名的質詢（消息），并獲得了由主機公鑰驗證的簽名。請記住：私鑰簽名，公鑰驗證。

證書簽名

讓我們擴大范圍并將 DSA 概念擴展到 TLS 中使用的 X509 證書以及對證書的哪一部分進行簽名。我們來介紹一下權威和主體關系的概念。兩者都有其公鑰/私鑰對。我們開始使用公鑰基礎結構 （PKI） 關聯到證書鏈。PKI可以建立在證書鏈上，證書頒發機構位于鏈的頂部：頒發機構。

使用者向頒發機構發送證書簽名請求 （CSR）

機構將使用其公鑰對其進行驗證

驗證 CSR 后，證書的“待簽名”（TBS） 部分將通過前面討論的 DSA。在此圖中，我們將特別提及橢圓曲線數字簽名協議（著名的 ECDSA）。

要簽名的證書部分包含：

權威信息

證書信息

主題信息

主題公鑰

然后我們需要在這組數據的末尾附加簽名以轉到下一個概念。

證書驗證

在上一步中，證書使用頒發機構私鑰簽名，在使用者和頒發機構之間創建綁定，但綁定尚未完成。主機需要驗證使用者證書的簽名 TBS 部分是否可信：

主體向主持人（不同于權威機構）提供他的 TBS 和簽名。

主機使用先前分發給它的頒發機構公鑰，并使用它來驗證使用者的簽名并收集使用者的 TBS。

在我們的案例中，驗證是使用 ECDSA 驗證完成的。

現在證書已驗證，讓我們討論實際的證書身份驗證。

證書身份驗證

使用者會將其證書發送到具有權限公鑰的主機

使用者證書包含使用者公鑰

主機將向主體發送隨機質詢（也稱為隨機數），主體將使用 ECDSA 簽名操作并使用主體私鑰對其進行簽名。

簽名被發送回主機，主機將使用先前分發的主題公鑰對其進行驗證。

這是對證書的不同看法。我們可以了解簽名的內容，證書的靜態部分是什么，證書的動態部分是什么。CryptoAuthLib 是與我們的安全元素一起使用的庫，用于處理證書靜態和動態部分的解析。公鑰、簽名和私鑰將由安全元素安全邊界內的必要加密操作處理。

圖 2：完整的 X509 證書

加密和完整性

現在，已經涵蓋了身份驗證的基本概念，我們可以回顧一下加密和完整性概念以及TLS如何處理它們。

這里的想法是，客戶端和物聯網世界中的服務器創建了前向保密的概念。為此，我們需要即時生成臨時對稱密鑰，也稱為臨時密鑰。通常，非對稱操作很慢，因此對稱密鑰用于加密和完整性。我們需要從密鑰交換（也稱為密鑰協議）開始。服務器和客戶端計算出兩端相同的預主密鑰。

在加密術語中，我們將使用橢圓曲線Diffie Hellman Ephemeral （ECDHE）操作，如下所示。

每個客戶端和服務器發出一個隨機數，代表他們自己唯一的私鑰

一方面，私鑰通過 ECDH 運行，但使用另一端公鑰來計算預主密鑰。

另一方將執行相同的操作

現在，每一方都有一個相同的預主密鑰。接下來，我們需要一個偽隨機函數（PRF）來生成額外的密鑰材料：

客戶端和服務器加密密鑰

客戶端和服務器初始化向量 （IV）

客戶端和服務器消息身份驗證代碼 （MAC） 密鑰

如果我們參考 ATECC608 或 TA100，它們都具有 PRF 模式下的密鑰派生函數 （KDF），這是使用 HMAC/SHA1 實現 TLS2.256 PRF 所必需的。讓我們看看PRF在TLS中做了什么。

從預主密鑰中，PRF 生成更多密鑰！從預主密鑰中，我們將通過另一個 PRF 運行預主密鑰和種子，以計算通常長為 48 字節的主密鑰。

“種子”本身由客戶端隨機數、服務器隨機數和主密鑰組成。

最后，我們進入密鑰擴展階段，該階段從前一階段獲取主密鑰，包含客戶端隨機數、服務器隨機數和“密鑰擴展”的種子。種子和主密鑰都通過 PRF 運行以輸出密鑰材料。

請注意，有單獨的加密和完整性檢查：

AES128 CBC 用于加密

HMAC-SHA256 用于 MAC

但也有組合的加密和完整性檢查：

經過身份驗證的關聯數據加密 （AEAD）

GCM - 伽羅瓦計數器模式

CCM - 帶 CBC-MAC 的計數器

下面我們將說明 ATECC608 或 TA100 將實現的對稱加密流。它說明了如何使用所討論的步驟建立前向保密。

TLS 握手和密碼套件

TLS構建得非常靈活，并提供不同的密碼套件。每個密碼套件都由多個加密參數組成，我們剛剛在這篇博文中回顧了這些參數。

密鑰交換算法

身份驗證算法

密碼

算法、密鑰強度、模式

MAC 或 PRF

您可以在以下鏈接中參考密碼套件的廣泛列表。如果您考慮所有現有的密碼套件，則必須考慮嵌入式系統的限制。嵌入式物聯網設備（如煙霧探測器或監控攝像頭）沒有數據中心的馬力 - 您會認為這是顯而易見的，對吧？三思而后行。通常，嵌入式系統的計算能力最小，內存有限，功耗有限，安全性會打擊所有三個系統，因為加密可能會耗費計算，從而影響功耗。就此而言，我們將把示例重點放在以下密碼套件 ATECC608 excel 上，因為它提供了非常成本優化的體系結構和高級別的密鑰保護（通用標準聯合解釋庫 （JIL） 高）： TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256，讓我們分解它：

ECDHE 密鑰交換/協議算法

ECDSA 服務器身份驗證算法

AES 密碼算法

128 密碼強度

GCM 密碼模式

SHA256 PRF（偽隨機函數）

密碼模式為 AEAD（結合加密和完整性檢查）

最后一部分指定 PRF 算法。

您需要 RSA 嗎？請考慮 TA100 和以下密碼套件：TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256。 我們已經看到它用于汽車應用，但也用于基于Linux?的應用，如網關，需要網絡密碼改造，因為舊的連接設備仍然對基礎設施至關重要，在帶有RSA的網絡上運行。同樣，我們有以下密碼學：

ECDHE 密鑰交換/協議算法

RSA 服務器身份驗證算法

AES 密碼算法

128 密碼強度

CBC 密碼模式

SHA256 MAC（消息身份驗證代碼）

它將加密和完整性檢查算法分開。最后一部分指定 MAC 算法。

如您所見，ECC 私鑰或 RSA 私鑰是安全建立 TLS 會話的最重要基礎的機密。如果該密鑰是公開的或可訪問的，則依賴于它的任何加密都與公開的密鑰一樣弱。因此，必須通過在 TA608 安全元件的 ATECC100 中隔離私有設備來保護私有設備。這樣，私鑰就與代碼、用戶、開發人員和制造商“隔絕”。在使用 Microchip 安全配置服務時，這種隔離性會更加增強。以下是 TA100 將支持的一組密碼套件作為示例：

TLS1.2 ： TLS_ECDHE_WITH_AES_128+CBC+SHA256 RSA AES_123 CBC SHA256

TLS1.3 ： TLS_AES_128_GCM_SHA256

TLS1.3 ： TLS_AES_128_CCM_SHA256

TLS1.3 ： TLS_AES_128_CCM_8_SHA256

如何使用 ATECC608 或 TA100 實現 TLS：信任平臺設計套件

讓我們動手操作代碼和硬件，并查看實現細節。首先，下載信任平臺設計套件。這里有幾個TLS用例，包括簡化的交易圖和交鑰匙C代碼項目，以幫助您開始使用我們的安全元件，微控制器和WiFi模塊：

Trust&GO ATECC608 for AWS IoT

Trust&GO ATECC608 for Microsoft Azure

適用于 AWS IoT 的 TrustFLEX ATECC608

TrustFLEX ATECC608 for Microsoft Azure

在TPDS之外，你可以找到來自WolfSSL和mbedTLS的代碼示例，利用PKCS#11 for Linux?平臺。

現在我們將詳細介紹涉及 ATECC608 的 TLS 的實際事務圖。TA100在概念上是相似的（使用talib而不是atcab進行API調用）。下圖主要關注微控制器單元 （MCU） 和 ATECC608 之間的 CryptoAuthLib 回調。您可以通過搜索“atcab”API 調用輕松識別它們。

這就是實現帶有安全元素的TLS的方式。請記住下載信任平臺設計套件并測試 C 代碼項目。請記住，此安裝意味著您選擇的TLS堆棧需要具有對CryptoAuthlib的回調，例如mBedTLS或WolfSSL。請注意，我們的WFI32 WiFi MCU模塊將WiFi堆棧與TLS和微控制器集成在一個模塊或芯片架構中。 如果您的系統具有某種類型的操作系統或RTOS，那么您可以使用PKCS#11訪問CrytpoAuthLib API并向安全元素發送命令。PKCS#11 將刪除與 TLS 堆棧提供程序的任何依賴項，但需要一個能夠通過 PKCS#11 進行通信的嵌入式系統。如果您有裸機實施，那么我們提供的說明將滿足您的系統要求。

審核編輯：郭婷