傳輸層安全性的目的

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

機密性（加密數(shù)據(jù)）

完整性（保護數(shù)據(jù)不被篡改/損壞）

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

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

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

TLS 和身份驗證

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

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

數(shù)字簽名算法 （DSA）

證書簽名

證書驗證

證書身份驗證

數(shù)字簽名算法 （DSA）

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

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

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

主題公鑰分發(fā)到主機

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

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

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

現(xiàn)在，我們有一個由私鑰簽名的質(zhì)詢（消息），并獲得了由主機公鑰驗證的簽名。請記?。核借€簽名，公鑰驗證。

證書簽名

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

使用者向頒發(fā)機構(gòu)發(fā)送證書簽名請求 （CSR）

機構(gòu)將使用其公鑰對其進行驗證

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

要簽名的證書部分包含：

權(quán)威信息

證書信息

主題信息

主題公鑰

然后我們需要在這組數(shù)據(jù)的末尾附加簽名以轉(zhuǎn)到下一個概念。

證書驗證

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

主體向主持人（不同于權(quán)威機構(gòu)）提供他的 TBS 和簽名。

主機使用先前分發(fā)給它的頒發(fā)機構(gòu)公鑰，并使用它來驗證使用者的簽名并收集使用者的 TBS。

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

現(xiàn)在證書已驗證，讓我們討論實際的證書身份驗證。

證書身份驗證

使用者會將其證書發(fā)送到具有權(quán)限公鑰的主機

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

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

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

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

圖 2：完整的 X509 證書

加密和完整性

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

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

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

每個客戶端和服務(wù)器發(fā)出一個隨機數(shù)，代表他們自己唯一的私鑰

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

另一方將執(zhí)行相同的操作

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

客戶端和服務(wù)器加密密鑰

客戶端和服務(wù)器初始化向量 （IV）

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

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

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

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

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

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

AES128 CBC 用于加密

HMAC-SHA256 用于 MAC

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

經(jīng)過身份驗證的關(guān)聯(lián)數(shù)據(jù)加密 （AEAD）

GCM - 伽羅瓦計數(shù)器模式

CCM - 帶 CBC-MAC 的計數(shù)器

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

TLS 握手和密碼套件

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

密鑰交換算法

身份驗證算法

密碼

算法、密鑰強度、模式

MAC 或 PRF

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

ECDHE 密鑰交換/協(xié)議算法

ECDSA 服務(wù)器身份驗證算法

AES 密碼算法

128 密碼強度

GCM 密碼模式

SHA256 PRF（偽隨機函數(shù)）

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

最后一部分指定 PRF 算法。

您需要 RSA 嗎？請考慮 TA100 和以下密碼套件：TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256。 我們已經(jīng)看到它用于汽車應(yīng)用，但也用于基于Linux?的應(yīng)用，如網(wǎng)關(guān)，需要網(wǎng)絡(luò)密碼改造，因為舊的連接設(shè)備仍然對基礎(chǔ)設(shè)施至關(guān)重要，在帶有RSA的網(wǎng)絡(luò)上運行。同樣，我們有以下密碼學(xué)：

ECDHE 密鑰交換/協(xié)議算法

RSA 服務(wù)器身份驗證算法

AES 密碼算法

128 密碼強度

CBC 密碼模式

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

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

如您所見，ECC 私鑰或 RSA 私鑰是安全建立 TLS 會話的最重要基礎(chǔ)的機密。如果該密鑰是公開的或可訪問的，則依賴于它的任何加密都與公開的密鑰一樣弱。因此，必須通過在 TA608 安全元件的 ATECC100 中隔離私有設(shè)備來保護私有設(shè)備。這樣，私鑰就與代碼、用戶、開發(fā)人員和制造商“隔絕”。在使用 Microchip 安全配置服務(wù)時，這種隔離性會更加增強。以下是 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 實現(xiàn) TLS：信任平臺設(shè)計套件

讓我們動手操作代碼和硬件，并查看實現(xiàn)細節(jié)。首先，下載信任平臺設(shè)計套件。這里有幾個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?平臺。

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

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

審核編輯：郭婷