如何實(shí)現(xiàn)部署的物聯(lián)網(wǎng)設(shè)備在功能上支持基本的安全措施執(zhí)行任務(wù)？

在工業(yè)、醫(yī)療、運(yùn)輸及其他關(guān)鍵應(yīng)用中，對(duì)物聯(lián)網(wǎng)應(yīng)用的依賴(lài)程度迅速增加，這極大地改變了安全格局。以往，企業(yè)應(yīng)用普遍擁有隨時(shí)可用的資源來(lái)處理安全算法，但如今企業(yè)級(jí)物聯(lián)網(wǎng)應(yīng)用卻飽受威脅日益增多之苦，且其攻擊目標(biāo)是不斷擴(kuò)大的資源受限型物聯(lián)網(wǎng)設(shè)備網(wǎng)絡(luò)。企業(yè)在急于迎接快速涌現(xiàn)的物聯(lián)網(wǎng)機(jī)遇時(shí)，部署的物聯(lián)網(wǎng)設(shè)備在功能上往往無(wú)法支持基本的安全措施，因此難以保護(hù)存儲(chǔ)的數(shù)據(jù)，且無(wú)法保證在易受攻擊的網(wǎng)絡(luò)上進(jìn)行數(shù)據(jù)和命令交換。

當(dāng)然，開(kāi)發(fā)人員需要做到什么程度才能確保設(shè)計(jì)安全取決于多個(gè)因素。每個(gè)應(yīng)用都面臨著各自的威脅，因而需要對(duì)這些威脅帶來(lái)的風(fēng)險(xiǎn)進(jìn)行適當(dāng)?shù)脑u(píng)估。由于互連設(shè)備面臨的威脅數(shù)量不同以往，任何物聯(lián)網(wǎng)設(shè)備都至少需要一些最低限度的安全措施。

在一些人看來(lái)，為簡(jiǎn)單的物聯(lián)網(wǎng)設(shè)備實(shí)施強(qiáng)大的安全措施似乎是過(guò)度設(shè)計(jì)，但即使是簡(jiǎn)單的溫度傳感器，如果缺乏足夠的保護(hù)，也會(huì)成為黑客入侵企業(yè)網(wǎng)絡(luò)的切入點(diǎn)。其實(shí)，正因?yàn)槲锫?lián)網(wǎng)應(yīng)用提供了普遍連接性，而這些應(yīng)用卻基于資源受限的設(shè)備，才導(dǎo)致物聯(lián)網(wǎng)安全持續(xù)面臨挑戰(zhàn)。事實(shí)上，即使物聯(lián)網(wǎng)設(shè)備設(shè)計(jì)提供足夠的資源在軟件中執(zhí)行加密算法，但只要這些算法在實(shí)現(xiàn)過(guò)程中存在細(xì)微錯(cuò)誤，應(yīng)用仍然可能易受攻擊。

本文介紹了加密算法的基本類(lèi)別，并探討了它們?cè)诎踩矫娴淖饔谩Ｈ缓?，本文將向開(kāi)發(fā)人員展示如何利用 Maxim Integrated、Microchip Technology 和 Texas Instruments 提供的旨在加速這些算法的處理器和專(zhuān)用器件，以在簡(jiǎn)化實(shí)現(xiàn)的同時(shí)增強(qiáng)安全性的不同方面。

各種類(lèi)型的加密算法及其作用

加密算法可分為三大類(lèi)，涉及機(jī)密性、身份驗(yàn)證（驗(yàn)證消息來(lái)源）、不可抵賴(lài)性（證明發(fā)送方創(chuàng)建了加密或簽名的消息）和完整性等基本安全原則：

對(duì)稱(chēng)密鑰算法，即算法或加密法使用相同的密鑰，將人類(lèi)可讀的（明文）消息加密為受保護(hù)的版本（密文），之后再將密文解密為明文。對(duì)稱(chēng)密鑰加密法通常用于確保機(jī)密性。常見(jiàn)的對(duì)稱(chēng)加密算法包括：

Triple DES（一種數(shù)據(jù)加密標(biāo)準(zhǔn)），又稱(chēng)為 3DES，或由美國(guó)國(guó)家標(biāo)準(zhǔn)與技術(shù)研究院 （NIST） 正式命名的三重?cái)?shù)據(jù)加密算法 （TDEA）。

高級(jí)加密標(biāo)準(zhǔn) （AES） 算法，例如使用 256 位密鑰的 AES-256。

非對(duì)稱(chēng)密鑰算法，即加密法使用一組成對(duì)的私鑰和公鑰對(duì)消息進(jìn)行加密和解密，通常作為密鑰協(xié)議和數(shù)字簽名安全擴(kuò)展協(xié)議的一部分。非對(duì)稱(chēng)加密法通常用于確保機(jī)密性、身份驗(yàn)證或不可抵賴(lài)性。公鑰加密算法包括：

使用有限域加密 （FFC） 的算法，包括：

聯(lián)邦信息處理標(biāo)準(zhǔn) （FIPS） 數(shù)字簽名算法 （DSA）

互聯(lián)網(wǎng)工程任務(wù)組 （IETF） Diffie-Hellman （DH） 密鑰交換

使用整數(shù)分解加密 （IFC） 的算法，包括：

Rivest-Shamir-Adleman （RSA）算法

使用橢圓曲線(xiàn)加密 （ECC） 的算法，包括：

橢圓曲線(xiàn) Diffie-Hellman （ECDH） 密鑰交換

橢圓曲線(xiàn)數(shù)字簽名算法 （ECDSA）

哈希算法，此算法將原始消息縮減為一個(gè)很短且長(zhǎng)度固定的唯一值，常稱(chēng)為哈希值、摘要或簽名。這種單向轉(zhuǎn)換函數(shù)在驗(yàn)證消息是否遭到竄改（完整性）方面扮演重要角色，可應(yīng)用于涉及消息驗(yàn)證碼 （MAC）、密鑰哈希消息驗(yàn)證碼 （HMAC） 或密鑰派生函數(shù) （KDF） 等的多種協(xié)議。加密哈希算法包括：

消息摘要 5 （MD5）

安全哈希算法 （SHA），例如將消息轉(zhuǎn)換成 256 位哈希值的 SHA-256。

與所有有效的加密算法一樣，上述算法的設(shè)計(jì)也需遵循多個(gè)關(guān)鍵要求，本文礙于篇幅，無(wú)法詳細(xì)列出。但從廣義角度來(lái)看，基于密鑰的算法需要生成的密文幾乎無(wú)法在無(wú)密鑰的情況下解密（至少?gòu)慕?jīng)濟(jì)角度來(lái)說(shuō)不可行）。哈希算法必須快速生成哈希值：將相同的輸入消息轉(zhuǎn)換成相同的哈希值，但對(duì)于哪怕只是有細(xì)微變化的輸入消息，也要生成截然不同的哈希值；并且，絕不會(huì)將兩條不同消息轉(zhuǎn)換成相同的哈希值，也不會(huì)因給定了特定的哈希值而生成原始消息。

盡管這些算法及其他加密算法在細(xì)節(jié)上有極大差異，但都仰賴(lài)一系列專(zhuān)門(mén)設(shè)計(jì)的低級(jí)操作、轉(zhuǎn)換和其他數(shù)學(xué)運(yùn)算，以便達(dá)成整體目標(biāo)。例如，AES 加密法使用一系列“回合”將明文轉(zhuǎn)換為密文，每個(gè)“回合”都會(huì)由用戶(hù)原始密鑰產(chǎn)生唯一的“回合密鑰”，并將其與原矩陣合并（清單 1）。

副本

Cipher（byte in［4*Nb］， byte out［4*Nb］， word w［Nb*（Nr+1）］）

begin

byte state［4，Nb］

state = in

AddRoundKey（state， w［0， Nb-1］）

for round = 1 step 1 to Nr–1

SubBytes（state）

ShiftRows（state）

MixColumns（state）

AddRoundKey（state， w［round*Nb， （round+1）*Nb-1］）

end for

SubBytes（state）

ShiftRows（state）

AddRoundKey（state， w［Nr*Nb， （Nr+1）*Nb-1］）

out = state

end

清單 1：這段偽代碼說(shuō)明了消息加密中涉及的操作序列，此序列使用一組由發(fā)送方私鑰派生的值 （w），將明文 （in） 轉(zhuǎn)換為密文 （out）。（代碼來(lái)源：NIST）

在一個(gè)回合中，SubBytes（） 轉(zhuǎn)換使用替換表 （S-box） 替換每個(gè)字節(jié)，替換表本身也是一系列轉(zhuǎn)換的結(jié)果（圖 1）。

圖 1：在 AES 加密法中，SubBytes（） 階段使用替換表 （S-Box） 替換每個(gè)字節(jié)。

在序列的下一步中，ShiftRows（） 轉(zhuǎn)換將后三行中的字節(jié)移位，且每行移動(dòng)不同的字節(jié)數(shù)（圖 2）。

圖 2：AES 加密法執(zhí)行序列中的 ShiftRows（） 階段通過(guò)增加偏移量來(lái)對(duì)行進(jìn)行移位。

在序列的最后步驟中，MixColumns（） 對(duì)每一列進(jìn)行轉(zhuǎn)換，用多項(xiàng)式的結(jié)果替換列中的每個(gè)字節(jié)；然后 AddRoundKey（） 使用專(zhuān)為此目的創(chuàng)建的回合密鑰，與各混合列中的字節(jié)進(jìn)行按位異或 （XOR） 運(yùn)算以轉(zhuǎn)換結(jié)果。

回合總數(shù)因密鑰大小而異。AES-128 使用 128 位密鑰，需要 10 個(gè)回合，而 AES-192（密鑰大小為 192 位）及 AES-256（256 位）分別需要 12 和 14 個(gè)回合。解密遵循相同的模式，只是反向執(zhí)行各過(guò)程步驟及其各自的轉(zhuǎn)換。

用于密鑰交換的 ECDH 和用于數(shù)字簽名的 ECDSA 等最新加密法依賴(lài)于更復(fù)雜的數(shù)學(xué)運(yùn)算，例如由以下公式廣泛定義的橢圓曲線(xiàn)代數(shù)結(jié)構(gòu)：

公式 1

通過(guò)慎重選擇曲線(xiàn)參數(shù) a 和 b 并使用其他約束條件，該曲線(xiàn)將顯示出有用的加密屬性（同樣，本文無(wú)法詳述）。雖然概念簡(jiǎn)單，但特定的參數(shù)組合至關(guān)重要：曲線(xiàn)參數(shù)選擇不當(dāng)會(huì)導(dǎo)致算法仍然無(wú)法抵御復(fù)雜的攻擊。為了幫助消除這種可能性，NIST 提供了一組具有強(qiáng)魯棒性的標(biāo)準(zhǔn)加密曲線(xiàn)，包括 P-192、P-224、P-256 和魯棒性更強(qiáng)的其他曲線(xiàn)。曲線(xiàn)名稱(chēng)與曲線(xiàn)的底層素域中元素的素?cái)?shù) p 的位長(zhǎng)相對(duì)應(yīng)。

開(kāi)發(fā)人員可使用這些屬性結(jié)合 ECDSA，利用確定的曲線(xiàn)對(duì)部分消息進(jìn)行簽名，并將公鑰和簽名（一對(duì)標(biāo)示為 r 和 s 的數(shù)字）提供給接收方。實(shí)際的簽名過(guò)程包含以下步驟：

首先，算法在曲線(xiàn)上選取某個(gè)點(diǎn)，稱(chēng)為基點(diǎn) G（x，y），再將基點(diǎn)與開(kāi)發(fā)人員的私鑰 （d） 模 p 相乘，以生成公鑰 Q（x，y）：

公式 2

然后，在值域 ［1 。.. n-1］ 中選取隨機(jī)數(shù) k 以產(chǎn)生另一個(gè)坐標(biāo)點(diǎn) （x1，y1）：

公式 3

這樣，即可生成消息 m 的 SHA 哈希值 H（m）

最后，使用隨機(jī)數(shù) k 的模逆元 k-1，生成數(shù)字簽名的最終 r 和 s 分量，如下所示：

公式 4

公式 5

最終結(jié)果可以互換，用于驗(yàn)證消息、確認(rèn)消息完整性，并確保不可抵賴(lài)性。

如何實(shí)現(xiàn)加密算法

一般淺略了解這些算法后，人們都會(huì)發(fā)現(xiàn)加密算法依賴(lài)于一連串?dāng)?shù)學(xué)運(yùn)算，并且計(jì)算量相當(dāng)龐大，想要快速完成運(yùn)算根本不可能或不切實(shí)際，因此入侵者無(wú)法加以利用。此外，即使粗略地查驗(yàn)每種算法也能看出，在不影響設(shè)備主要功能要求的情況下，資源受限的物聯(lián)網(wǎng)設(shè)備幾乎不可能執(zhí)行算法的軟件實(shí)現(xiàn)。最后，由本文未詳述的算法具體細(xì)節(jié)可知，即便是細(xì)微的編碼錯(cuò)誤或?qū)?biāo)準(zhǔn)稍有誤解，也可能造成安全漏洞，甚至?xí)尲用苓^(guò)程徹底失效。

即使是最大的開(kāi)發(fā)機(jī)構(gòu)和極度依賴(lài)這些算法的應(yīng)用，也可能會(huì)在算法實(shí)現(xiàn)時(shí)出錯(cuò)。例如，某游戲主機(jī)就曾發(fā)生過(guò)一次眾所周知的安全漏洞事件，原因就是在實(shí)施 ECDSA 時(shí)，該公司在公式 3 所示的計(jì)算類(lèi)型中使用了常數(shù) k，而非隨機(jī)數(shù)，結(jié)果讓黑客推導(dǎo)出安全密鑰 d。類(lèi)似的安全漏洞事件也曾造成比特幣嚴(yán)重?fù)p失，就是因?yàn)槭褂昧擞腥毕莸碾S機(jī)數(shù)發(fā)生器來(lái)產(chǎn)生 k。

將基于硬件的加密功能內(nèi)置到處理器和專(zhuān)用安全 IC 中，開(kāi)發(fā)人員就可在很大程度上忽略執(zhí)行加密算法的復(fù)雜細(xì)節(jié)，而將精力集中在使用這些功能來(lái)保護(hù)應(yīng)用的優(yōu)勢(shì)上。在器件內(nèi)集成數(shù)據(jù)流和運(yùn)算，額外增加了一重安全保護(hù)，從而消除了一種常見(jiàn)的攻擊形式，即監(jiān)視外部總線(xiàn)以尋找特權(quán)信息跡象。除了提供特定算法的可靠實(shí)現(xiàn)外，基于硬件的解決方案還允許開(kāi)發(fā)人員在設(shè)計(jì)中整合安全功能，而不會(huì)影響基本要求，如傳輸響應(yīng)延遲和影響整體性能。

這些器件內(nèi)置的加密加速器可為主處理器分擔(dān)加密執(zhí)行任務(wù)，使其能夠集中處理設(shè)計(jì)的主要功能。實(shí)際上，基于硬件的加密支持已逐漸成為處理器的常見(jiàn)功能。同時(shí)，并非每個(gè)應(yīng)用都需要用到上述算法所支持的所有安全措施。其實(shí)，在許多處理器中，開(kāi)發(fā)人員都能找到多種加速加密算法和算法組合，例如以下處理器：

Maxim Integrated 的 MAX32631 32 位微控制器，支持 AES 和 DSA 加密

Maxim Integrated 的 MAX32520 32 位 MCU，支持 AES、SHA 和 ECDSA 算法

Microchip Technology 的 PIC 24F XLP 16 位微控制器系列，其中 PIC24FJ256GA406 等器件支持 AES 和 3DES 加密

Microchip Technology 的 32 位 PIC 32MZ MCU 和 32 位 SAM9X60 MPU 系列，其中 PIC32MZ2048EFM144 和 SAM9X60T 等器件支持 AES 和 3DES 加密，以及 SHA 和 HMAC 哈希函數(shù)

Texas Instruments 的 SimpleLink MCU 系列，如 CC1312R 和 CC2652R 無(wú)線(xiàn) MCU，支持 AES、ECDH 和 ECDSA 加密，以及 SHA 哈希函數(shù)

Maxim Integrated 的 DS28E38 和 Microchip Technology 的 ATECC608A 等其他安全器件，集成了加密加速器和加速身份驗(yàn)證協(xié)議所需的相關(guān)功能。除了豐富的加密功能之外，這些器件還支持前文所述的 ECDSA 運(yùn)算。在物聯(lián)網(wǎng)設(shè)備或智能外設(shè)中，主機(jī)處理器可使用此類(lèi)身份驗(yàn)證 IC 來(lái)快速創(chuàng)建 ECDSA P-256 數(shù)字簽名，以發(fā)送至另一臺(tái)設(shè)備，或者驗(yàn)證來(lái)自其他設(shè)備的 ECDSA P-256 簽名。

支持安全功能的處理器與專(zhuān)用器件，通常使用廣泛的基于硬件的安全框架構(gòu)建，以便提供高質(zhì)量隨機(jī)數(shù)發(fā)生器等額外的安全功能。許多提供此級(jí)別功能的器件會(huì)運(yùn)用半導(dǎo)體設(shè)計(jì)中固有的隨機(jī)噪聲源，使真隨機(jī)數(shù)發(fā)生器 （TRNG） 所需的熵最大化。正如前文所述的比特幣示例所表明，這類(lèi) TRNG 是正常運(yùn)算加密算法的必要因素。

集成對(duì)私鑰和其他機(jī)密數(shù)據(jù)安全存儲(chǔ)的支持，是安全設(shè)計(jì)最重要的功能之一。此外，這些處理器及其他類(lèi)似處理器更具備其他架構(gòu)性功能，可提供更深層的安全支持。

鑒于其所有功能，具有集成加密加速器和相關(guān)功能的處理器，可通過(guò)使用簡(jiǎn)單的應(yīng)用程序編程接口 （API） 庫(kù)來(lái)簡(jiǎn)化安全設(shè)計(jì)的開(kāi)發(fā)。直觀的 API 函數(shù)調(diào)用讓開(kāi)發(fā)人員可以依靠 API 來(lái)訪(fǎng)問(wèn)基礎(chǔ)硬件功能，從而使安全實(shí)現(xiàn)抽象化。例如，開(kāi)發(fā)人員可以使用 Maxim Integrated 推出的用于 MAX32520 MCU 的 MAX32520-KIT 評(píng)估套件，結(jié)合該公司的 Micros 軟件開(kāi)發(fā)套件 （SDK），可快速構(gòu)建安全的物聯(lián)網(wǎng)設(shè)備。除了相關(guān)的驅(qū)動(dòng)程序和中間件之外，Maxim Integrated 的 Micros SDK 還包括示例函數(shù)，這些函數(shù)演示了使用 AES 加密法加密 （AES128_ECB_enc（）） 和解密 （AES128_ECB_dec （）） 消息所需的基本設(shè)計(jì)模式（清單 2）。

副本

int AES128_ECB_enc（int asynchronous）

{

printf（ asynchronous ？ “Test Cipher Async\n” ： “Test Cipher Sync\n”）;

char *_key = “797f8b3d176dac5b7e34a2d539c4ef36”;

char key［MXC_AES_KEY_128_LEN］;

ascii_to_byte（_key， key， MXC_AES_KEY_128_LEN）;

const char *iv_src = “”;

char iv_dst［16］;

ascii_to_byte（iv_src， iv_dst， 16）;

char *_pt= “00000000000000000000000000000000”;

char pt［MXC_AES_DATA_LEN］;

ascii_to_byte（_pt， pt， MXC_AES_DATA_LEN）;

mxc_ctb_cipher_req_t cipher_req = {

（uint8_t*）pt，

MXC_AES_DATA_LEN，

（uint8_t*）iv_src，

（uint8_t*）result，

&Test_Callback };

// Reset crypto block

MXC_CTB_Init（MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA）;

MXC_CTB_IntEnable（asynchronous）;

MXC_CTB_Cipher_SetMode（MXC_CTB_MODE_ECB）;

MXC_CTB_Cipher_SetCipher（MXC_CTB_CIPHER_AES128）;

MXC_CTB_Cipher_SetKeySource（MXC_CTB_CIPHER_KEY_SOFTWARE）;

// Load key into cipher key register

MXC_CTB_Cipher_SetKey（（uint8_t *）key， MXC_AES_KEY_128_LEN）;

if （asynchronous）{

wait = 1;

MXC_CTB_Cipher_EncryptAsync（&cipher_req）;

while（ wait ）;

} else {

MXC_CTB_Cipher_Encrypt（&cipher_req）;

}

const char *_expected = “322FD6E503395CDB89A77AC53D2B954F”;

char expected［MXC_AES_DATA_LEN］;

ascii_to_byte（_expected， expected， MXC_AES_DATA_LEN）;

return AES_check（result， expected， MXC_AES_DATA_LEN）;

}

int AES128_ECB_dec（int asynchronous）

{

printf（ asynchronous ？ “Test Cipher Async\n” ： “Test Cipher Sync\n”）;

char *_key = “797f8b3d176dac5b7e34a2d539c4ef36”;

char key［MXC_AES_KEY_128_LEN］;

ascii_to_byte（_key， key， MXC_AES_KEY_128_LEN）;

const char *iv_src = “”;

char iv_dst［16］;

ascii_to_byte（iv_src， iv_dst， 16）;

char *_pt= “322FD6E503395CDB89A77AC53D2B954F”;

char pt［MXC_AES_DATA_LEN］;

ascii_to_byte（_pt， pt， MXC_AES_DATA_LEN）;

mxc_ctb_cipher_req_t cipher_req = {

（uint8_t*）pt，

MXC_AES_DATA_LEN，

（uint8_t*）iv_src，

（uint8_t*）result，

&Test_Callback };

// Reset crypto block

MXC_CTB_Init（MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA）;

MXC_CTB_IntEnable（asynchronous）;

MXC_CTB_Cipher_SetMode（MXC_CTB_MODE_ECB）;

MXC_CTB_Cipher_SetCipher（MXC_CTB_CIPHER_AES128）;

MXC_CTB_Cipher_SetKeySource（MXC_CTB_CIPHER_KEY_SOFTWARE）;

// Load key into cipher key register

MXC_CTB_Cipher_SetKey（（uint8_t *）key， MXC_AES_KEY_128_LEN）;

if （asynchronous）{

wait = 1;

MXC_CTB_Cipher_DecryptAsync（&cipher_req）;

while（ wait ）;

} else {

MXC_CTB_Cipher_Decrypt（&cipher_req）;

}

const char *_expected = “00000000000000000000000000000000”;

char expected［MXC_AES_DATA_LEN］;

ascii_to_byte（_expected， expected， MXC_AES_DATA_LEN）;

return AES_check（result， expected， MXC_AES_DATA_LEN）;

}

清單 2：開(kāi)發(fā)人員可以檢查 Maxim Integrated 的 Micros SDK 分發(fā)包中的示例代碼，以學(xué)習(xí)使用 MAX32520 MCU 的集成加密函數(shù)執(zhí)行 AES 加密 （AES128_ECB_enc（）） 和解密 （AES128_ECB_dec （）） 所需的基本設(shè)計(jì)模式。

身份驗(yàn)證協(xié)議

要為應(yīng)用中使用的高級(jí)協(xié)議提供安全基礎(chǔ)，具有強(qiáng)魯棒性的加密算法實(shí)現(xiàn)尤其重要。像傳輸層安全 （TLS） 這樣的較高層級(jí)協(xié)議通常使用一組定義的加密算法（稱(chēng)為密碼套件）來(lái)執(zhí)行運(yùn)算。在 TLS 中，從約定的密碼套件提取的算法有助于確保物聯(lián)網(wǎng)設(shè)備客戶(hù)端與主機(jī)服務(wù)器之間的通信會(huì)話(huà)實(shí)現(xiàn)身份驗(yàn)證和機(jī)密性。TLS 1.2［8］ 會(huì)通過(guò)一個(gè)特定事務(wù)處理序列，在進(jìn)行數(shù)據(jù)交換之前，協(xié)商參數(shù)、執(zhí)行身份驗(yàn)證和交換會(huì)話(huà)密鑰。

TLS 1.2 會(huì)話(huà)創(chuàng)建協(xié)議使用約定密碼套件提供的各種算法進(jìn)行身份驗(yàn)證、密鑰交換和持續(xù)的數(shù)據(jù)交換。

鑒于安全證書(shū)中包含每個(gè)參與者各自的公鑰，可通過(guò)驗(yàn)證安全證書(shū)，確定服務(wù)器以及客戶(hù)端（可選）的身份以確保實(shí)現(xiàn)身份驗(yàn)證。在此期間，每個(gè)參與者都會(huì)發(fā)送一條使用其私鑰加密的消息。由于接收到的公鑰僅能解密用其關(guān)聯(lián)私鑰加密的消息，因此每個(gè)參與者都可以確認(rèn)證書(shū)提供者實(shí)際擁有該證書(shū)。

在下一個(gè) TLS 階段，參與者執(zhí)行一系列事務(wù)處理，以創(chuàng)建共享會(huì)話(huà)密鑰。該共享會(huì)話(huà)密鑰隨后會(huì)用來(lái)加密實(shí)際的消息流量，從而確保該會(huì)話(huà)消息交換的機(jī)密性。

多種協(xié)議選擇使開(kāi)發(fā)人員可以?xún)?yōu)化此通用 TLS 會(huì)話(huà)的創(chuàng)建過(guò)程，但有時(shí)會(huì)影響整體安全性。此外，在參數(shù)交換過(guò)程中，開(kāi)發(fā)人員可以使用不同的密碼套件，為各個(gè)協(xié)議階段選擇合適的 TLS 1.2 支持算法組合，具體包括：

密鑰構(gòu)建：RSA、DH、ECDH

身份驗(yàn)證：RSA、DSA、ECDSA

加密法：3DES、AES

消息驗(yàn)證：SHA

最新版本的 TLS 為 TLS 1.3［9］，該協(xié)議規(guī)定先執(zhí)行密鑰交換以更好地保護(hù)會(huì)話(huà)創(chuàng)建過(guò)程，從而增加了額外的安全性。更重要的是，TLS 1.3 在很大程度上棄用了 TLS 1.2 的密碼套件，轉(zhuǎn)而使用更強(qiáng)大的算法，包括基于 HMAC 的提取和擴(kuò)展密鑰派生函數(shù) （HKDF），以及帶有關(guān)聯(lián)數(shù)據(jù)的認(rèn)證加密 （AEAD） 算法。AEAD 算法滿(mǎn)足了確保消息真實(shí)性、完整性和機(jī)密性的廣泛需求。這些算法通過(guò)將加密消息與 MAC 綁定實(shí)現(xiàn)上述要求，而加密與 MAC 可按照串行方式或兩者并用方式生成。

AEAD 使用先加密后生成 MAC（左）與同時(shí)加密和生成 MAC（右）方式，分別進(jìn)行串行或并行 MAC 計(jì)算，然后將 MAC 與密文綁定從而提供身份驗(yàn)證與機(jī)密性。

增加安全強(qiáng)度

加密算法與相關(guān)協(xié)議的發(fā)展過(guò)程，可以說(shuō)是決心強(qiáng)化安全性的加密專(zhuān)家與同樣堅(jiān)定的破解者之間不斷追逐的競(jìng)賽。例如，為了加強(qiáng)安全性，專(zhuān)家開(kāi)發(fā)了 ECDSA 作為 DSA 的 ECC 變體，而 DSA 本身則是更早期加密法的變體。因此，ECDSA 的安全強(qiáng)度與 DSA 相同，但密鑰大小則大幅縮小。

在密碼學(xué)中，算法的安全強(qiáng)度取決于密鑰位數(shù) x 和攻擊將需要約 2x 次運(yùn)算才能推演出算法所隱藏私鑰的預(yù)期。根據(jù)這些條件，不同類(lèi)別的算法可能需要截然不同的密鑰長(zhǎng)度，才能達(dá)到相當(dāng)安全級(jí)別。

不同類(lèi)別的加密算法可能需要截然不同的公鑰 （L） 或私鑰（N、k、f）大小，才能實(shí)現(xiàn)級(jí)別相當(dāng)?shù)陌踩珡?qiáng)度。

在這張來(lái)自 NIST 的表格中，F(xiàn)FC 算法參數(shù) L 和 N 分別對(duì)應(yīng)于公鑰和私鑰的大小。k 和 f 分別對(duì)應(yīng)于 IFC 和 ECC 算法的密鑰大小。NIST 指出，安全強(qiáng)度 ≤80 的算法（表中橘色背景的單元格）不準(zhǔn)再用于保護(hù)政府信息，而其他算法（黃色背景的單元格）基于效率考慮，尚未納入 NIST 標(biāo)準(zhǔn)。

在追求更高安全強(qiáng)度的趨勢(shì)下，加密法和建議的密碼套件也因此而不斷發(fā)展。例如，美國(guó)國(guó)家安全局 （NSA） 商業(yè)國(guó)家安全算法 （CNSA） 套件取代了早期的 NSA Suite B，并建議使用更穩(wěn)健的參數(shù)來(lái)保護(hù)被列為最高機(jī)密的信息。

NSA 建議的 CNSA 套件包含加密算法以及保護(hù)高度敏感信息所需的最低安全強(qiáng)度建議。

展望未來(lái)，量子計(jì)算功能的出現(xiàn)會(huì)為整個(gè)安全領(lǐng)域，特別是加密算法，帶來(lái)巨大的斷層。

總結(jié)

物聯(lián)網(wǎng)設(shè)備和其他互連設(shè)計(jì)面臨著越來(lái)越多的威脅，因此需要更強(qiáng)大的基于多種加密算法的安全方法。這些算法依賴(lài)于一系列轉(zhuǎn)換與數(shù)學(xué)運(yùn)算，將明文加密為密文，再將密文解密為明文，目的是讓破壞安全性的行為徒勞無(wú)功。如上所述，可以采用基于硬件的方式實(shí)現(xiàn)這些算法，因而開(kāi)發(fā)人員能夠更輕松地在設(shè)計(jì)中整合強(qiáng)大的安全功能，而不會(huì)影響功能和性能方面的主要要求。
責(zé)任編輯:pj