傳輸層安全性的目的

TLS 的目的是為嵌入式安全支柱做出貢獻(xiàn)：

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

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

身份驗(yàn)證（在客戶端和主機(jī)之間建立信任）

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

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

TLS 和身份驗(yàn)證

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

讓我們深入了解身份驗(yàn)證原則：

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

證書簽名

證書驗(yàn)證

證書身份驗(yàn)證

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

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

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

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

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

受試者將提供一個(gè)稱為簽名的答案

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

然后，主機(jī)將使用使用者公鑰驗(yàn)證簽名。

現(xiàn)在，我們有一個(gè)由私鑰簽名的質(zhì)詢（消息），并獲得了由主機(jī)公鑰驗(yàn)證的簽名。請(qǐng)記住：私鑰簽名，公鑰驗(yàn)證。

證書簽名

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

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

機(jī)構(gòu)將使用其公鑰對(duì)其進(jìn)行驗(yàn)證

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

要簽名的證書部分包含：

權(quán)威信息

證書信息

主題信息

主題公鑰

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

證書驗(yàn)證

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

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

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

在我們的案例中，驗(yàn)證是使用 ECDSA 驗(yàn)證完成的。

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

證書身份驗(yàn)證

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

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

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

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

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

圖 2：完整的 X509 證書

加密和完整性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

請(qǐng)注意，有單獨(dú)的加密和完整性檢查：

AES128 CBC 用于加密

HMAC-SHA256 用于 MAC

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

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

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

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

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

TLS 握手和密碼套件

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

密鑰交換算法

身份驗(yàn)證算法

密碼

算法、密鑰強(qiáng)度、模式

MAC 或 PRF

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

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

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

AES 密碼算法

128 密碼強(qiáng)度

GCM 密碼模式

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

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

最后一部分指定 PRF 算法。

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

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

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

AES 密碼算法

128 密碼強(qiáng)度

CBC 密碼模式

SHA256 MAC（消息身份驗(yàn)證代碼）

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

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

讓我們動(dòng)手操作代碼和硬件，并查看實(shí)現(xiàn)細(xì)節(jié)。首先，下載信任平臺(tái)設(shè)計(jì)套件。這里有幾個(gè)TLS用例，包括簡(jiǎn)化的交易圖和交鑰匙C代碼項(xiàng)目，以幫助您開始使用我們的安全元件，微控制器和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?平臺(tái)。

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

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

審核編輯：郭婷