編者按：本系列文章由多個部分組成，文中將提供一些實用的指導，以幫助開發(fā)人員確保從一開始就遵循相關(guān)的最佳實踐。第 1 部分（本文）探討底層安全設(shè)計的加密算法。第 2 部分探討私鑰、密鑰管理和安全存儲在系統(tǒng)安全中所起的作用。第 3 部分檢查安全處理器的內(nèi)建機制，以緩和企圖破壞物聯(lián)網(wǎng)設(shè)備上系統(tǒng)和應(yīng)用軟件執(zhí)行的威脅。第 4 部分明確并展示如何在高級處理器中應(yīng)用安全機制，幫助確保進行必要的隔離，以緩解對物聯(lián)網(wǎng)設(shè)備運行時環(huán)境進行的攻擊。第 5 部分介紹如何在將物聯(lián)網(wǎng)設(shè)備連接到物聯(lián)網(wǎng)云資源時，通過采用更高級別安全措施，讓這些設(shè)備實現(xiàn)持續(xù)的物聯(lián)網(wǎng)安全。
在工業(yè)、醫(yī)療、運輸及其他關(guān)鍵應(yīng)用中，對物聯(lián)網(wǎng)應(yīng)用的依賴程度迅速增加，這極大地改變了安全格局。以往，企業(yè)應(yīng)用普遍擁有隨時可用的資源來處理安全算法，但如今企業(yè)級物聯(lián)網(wǎng)應(yīng)用卻飽受威脅日益增多之苦，且其攻擊目標是不斷擴大的資源受限型物聯(lián)網(wǎng)設(shè)備網(wǎng)絡(luò)。企業(yè)在急于迎接快速涌現(xiàn)的物聯(lián)網(wǎng)機遇時，部署的物聯(lián)網(wǎng)設(shè)備在功能上往往無法支持基本的安全措施，因此難以保護存儲的數(shù)據(jù)，且無法保證在易受攻擊的網(wǎng)絡(luò)上進行數(shù)據(jù)和命令交換。
當然，開發(fā)人員需要做到什么程度才能確保設(shè)計安全取決于多個因素。每個應(yīng)用都面臨著各自的威脅，因而需要對這些威脅帶來的風險進行適當?shù)脑u估。由于互連設(shè)備面臨的威脅數(shù)量不同以往，任何物聯(lián)網(wǎng)設(shè)備都至少需要一些最低限度的安全措施。
在一些人看來，為簡單的物聯(lián)網(wǎng)設(shè)備實施強大的安全措施似乎是過度設(shè)計，但即使是簡單的溫度傳感器，如果缺乏足夠的保護，也會成為黑客入侵企業(yè)網(wǎng)絡(luò)的切入點[1]。其實，正因為物聯(lián)網(wǎng)應(yīng)用提供了普遍連接性，而這些應(yīng)用卻基于資源受限的設(shè)備，才導致物聯(lián)網(wǎng)安全持續(xù)面臨挑戰(zhàn)。事實上，即使物聯(lián)網(wǎng)設(shè)備設(shè)計提供足夠的資源在軟件中執(zhí)行加密算法，但只要這些算法在實現(xiàn)過程中存在細微錯誤，應(yīng)用仍然可能易受攻擊。
本文介紹了加密算法的基本類別，并探討了它們在安全方面的作用。然后，本文將向開發(fā)人員展示如何利用 Maxim Integrated、Microchip Technology 和 Texas Instruments 提供的旨在加速這些算法的處理器和專用器件，以在簡化實現(xiàn)的同時增強安全性的不同方面。
各種類型的加密算法及其作用
加密算法可分為三大類，涉及機密性、身份驗證（驗證消息來源）、不可抵賴性（證明發(fā)送方創(chuàng)建了加密或簽名的消息）和完整性等基本安全原則：
對稱密鑰算法，即算法或加密法使用相同的密鑰，將人類可讀的（明文）消息加密為受保護的版本（密文），之后再將密文解密為明文。對稱密鑰加密法通常用于確保機密性。常見的對稱加密算法包括：
非對稱密鑰算法，即加密法使用一組成對的私鑰和公鑰對消息進行加密和解密，通常作為密鑰協(xié)議和數(shù)字簽名安全擴展協(xié)議的一部分。非對稱加密法通常用于確保機密性、身份驗證或不可抵賴性。公鑰加密算法包括：
橢圓曲線 Diffie-Hellman (ECDH)[5] 密鑰交換
橢圓曲線數(shù)字簽名算法 (ECDSA)[6]
Rivest-Shamir-Adleman (RSA)[4] 算法
聯(lián)邦信息處理標準 (FIPS) 數(shù)字簽名算法 (DSA)
互聯(lián)網(wǎng)工程任務(wù)組 (IETF) Diffie-Hellman (DH)[3] 密鑰交換
使用有限域加密 (FFC) 的算法，包括：
使用整數(shù)分解加密 (IFC) 的算法，包括：
使用橢圓曲線加密 (ECC) 的算法，包括：
哈希算法，此算法將原始消息縮減為一個很短且長度固定的唯一值，常稱為哈希值、摘要或簽名。這種單向轉(zhuǎn)換函數(shù)在驗證消息是否遭到竄改（完整性）方面扮演重要角色，可應(yīng)用于涉及消息驗證碼 (MAC)、密鑰哈希消息驗證碼 (HMAC) 或密鑰派生函數(shù) (KDF) 等的多種協(xié)議。加密哈希算法包括：
與所有有效的加密算法一樣，上述算法的設(shè)計也需遵循多個關(guān)鍵要求，本文礙于篇幅，無法詳細列出。但從廣義角度來看，基于密鑰的算法需要生成的密文幾乎無法在無密鑰的情況下解密（至少從經(jīng)濟角度來說不可行）。哈希算法必須快速生成哈希值：將相同的輸入消息轉(zhuǎn)換成相同的哈希值，但對于哪怕只是有細微變化的輸入消息，也要生成截然不同的哈希值；并且，絕不會將兩條不同消息轉(zhuǎn)換成相同的哈希值，也不會因給定了特定的哈希值而生成原始消息。
盡管這些算法及其他加密算法在細節(jié)上有極大差異，但都仰賴一系列專門設(shè)計的低級操作、轉(zhuǎn)換和其他數(shù)學運算，以便達成整體目標。例如，AES 加密法使用一系列“回合”將明文轉(zhuǎn)換為密文，每個“回合”都會由用戶原始密鑰產(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：這段偽代碼說明了消息加密中涉及的操作序列，此序列使用一組由發(fā)送方私鑰派生的值 (w)，將明文 (in) 轉(zhuǎn)換為密文 (out)。（代碼來源：NIST）
在一個回合中，SubBytes() 轉(zhuǎn)換使用替換表 (S-box) 替換每個字節(jié)，替換表本身也是一系列轉(zhuǎn)換的結(jié)果（圖 1）。
圖 1：在 AES 加密法中，SubBytes() 階段使用替換表 (S-Box) 替換每個字節(jié)。（圖片來源：NIST）
在序列的下一步中，ShiftRows() 轉(zhuǎn)換將后三行中的字節(jié)移位，且每行移動不同的字節(jié)數(shù)（圖 2）。
圖 2：AES 加密法執(zhí)行序列中的 ShiftRows() 階段通過增加偏移量來對行進行移位。（圖片來源：NIST）
在序列的最后步驟中，MixColumns() 對每一列進行轉(zhuǎn)換，用多項式的結(jié)果替換列中的每個字節(jié)；然后 AddRoundKey() 使用專為此目的創(chuàng)建的回合密鑰，與各混合列中的字節(jié)進行按位異或 (XOR) 運算以轉(zhuǎn)換結(jié)果。
回合總數(shù)因密鑰大小而異。AES-128 使用 128 位密鑰，需要 10 個回合，而 AES-192（密鑰大小為 192 位）及 AES-256（256 位）分別需要 12 和 14 個回合。解密遵循相同的模式，只是反向執(zhí)行各過程步驟及其各自的轉(zhuǎn)換。
用于密鑰交換的 ECDH 和用于數(shù)字簽名的 ECDSA 等最新加密法依賴于更復雜的數(shù)學運算，例如由以下公式廣泛定義的橢圓曲線代數(shù)結(jié)構(gòu)：
公式 1
通過慎重選擇曲線參數(shù) a 和 b 并使用其他約束條件，該曲線將顯示出有用的加密屬性（同樣，本文無法詳述）。雖然概念簡單，但特定的參數(shù)組合至關(guān)重要：曲線參數(shù)選擇不當會導致算法仍然無法抵御復雜的攻擊。為了幫助消除這種可能性，NIST 提供了一組具有強魯棒性的標準加密曲線，包括 P-192、P-224、P-256 和魯棒性更強的其他曲線。曲線名稱與曲線的底層素域中元素的素數(shù) p 的位長相對應(yīng)。
開發(fā)人員可使用這些屬性結(jié)合 ECDSA，利用確定的曲線對部分消息進行簽名，并將公鑰和簽名（一對標示為 r 和 s 的數(shù)字）提供給接收方。實際的簽名過程包含以下步驟：
公式 2
公式 3
公式 4
公式 5
最終結(jié)果可以互換，用于驗證消息、確認消息完整性，并確保不可抵賴性。
如何實現(xiàn)加密算法
一般淺略了解這些算法后，人們都會發(fā)現(xiàn)加密算法依賴于一連串數(shù)學運算，并且計算量相當龐大，想要快速完成運算根本不可能或不切實際，因此入侵者無法加以利用。此外，即使粗略地查驗每種算法也能看出，在不影響設(shè)備主要功能要求的情況下，資源受限的物聯(lián)網(wǎng)設(shè)備幾乎不可能執(zhí)行算法的軟件實現(xiàn)。最后，由本文未詳述的算法具體細節(jié)可知，即便是細微的編碼錯誤或?qū)藴噬杂姓`解，也可能造成安全漏洞，甚至會讓加密過程徹底失效。
即使是最大的開發(fā)機構(gòu)和極度依賴這些算法的應(yīng)用，也可能會在算法實現(xiàn)時出錯。例如，某游戲主機就曾發(fā)生過一次眾所周知的安全漏洞事件，原因就是在實施 ECDSA 時，該公司在公式 3 所示的計算類型中使用了常數(shù) k，而非隨機數(shù)，結(jié)果讓黑客推導出安全密鑰 d。類似的安全漏洞事件也曾造成比特幣嚴重損失，就是因為使用了有缺陷的隨機數(shù)發(fā)生器來產(chǎn)生 k。
將基于硬件的加密功能內(nèi)置到處理器和專用安全 IC 中，開發(fā)人員就可在很大程度上忽略執(zhí)行加密算法的復雜細節(jié)，而將精力集中在使用這些功能來保護應(yīng)用的優(yōu)勢上。在器件內(nèi)集成數(shù)據(jù)流和運算，額外增加了一重安全保護，從而消除了一種常見的攻擊形式，即監(jiān)視外部總線以尋找特權(quán)信息跡象。除了提供特定算法的可靠實現(xiàn)外，基于硬件的解決方案還允許開發(fā)人員在設(shè)計中整合安全功能，而不會影響基本要求，如傳輸響應(yīng)延遲和影響整體性能。
這些器件內(nèi)置的加密加速器可為主處理器分擔加密執(zhí)行任務(wù)，使其能夠集中處理設(shè)計的主要功能。實際上，基于硬件的加密支持已逐漸成為處理器的常見功能。同時，并非每個應(yīng)用都需要用到上述算法所支持的所有安全措施。其實，在許多處理器中，開發(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 無線 MCU，支持 AES、ECDH 和 ECDSA 加密，以及 SHA 哈希函數(shù)
Maxim Integrated 的 DS28E38 和 Microchip Technology 的 ATECC608A 等其他安全器件，集成了加密加速器和加速身份驗證協(xié)議所需的相關(guān)功能。除了豐富的加密功能之外，這些器件還支持前文所述的 ECDSA 運算。在物聯(lián)網(wǎng)設(shè)備或智能外設(shè)中，主機處理器可使用此類身份驗證 IC 來快速創(chuàng)建 ECDSA P-256 數(shù)字簽名，以發(fā)送至另一臺設(shè)備，或者驗證來自其他設(shè)備的 ECDSA P-256 簽名。
支持安全功能的處理器與專用器件，通常使用廣泛的基于硬件的安全框架構(gòu)建，以便提供高質(zhì)量隨機數(shù)發(fā)生器等額外的安全功能。許多提供此級別功能的器件會運用半導體設(shè)計中固有的隨機噪聲源，使真隨機數(shù)發(fā)生器 (TRNG) 所需的熵最大化。正如前文所述的比特幣示例所表明，這類 TRNG 是正常運算加密算法的必要因素。
集成對私鑰和其他機密數(shù)據(jù)安全存儲的支持，是安全設(shè)計最重要的功能之一。此外，這些處理器及其他類似處理器更具備其他架構(gòu)性功能，可提供更深層的安全支持。
鑒于其所有功能，具有集成加密加速器和相關(guān)功能的處理器，可通過使用簡單的應(yīng)用程序編程接口 (API) 庫來簡化安全設(shè)計的開發(fā)。直觀的 API 函數(shù)調(diào)用讓開發(fā)人員可以依靠 API 來訪問基礎(chǔ)硬件功能，從而使安全實現(xiàn)抽象化。例如，開發(fā)人員可以使用 Maxim Integrated 推出的用于 MAX32520 MCU 的 MAX32520-KIT 評估套件，結(jié)合該公司的 cription.html/swpart=SFW0010820A" target="_blank">Micros 軟件開發(fā)套件 (SDK)，可快速構(gòu)建安全的物聯(lián)網(wǎng)設(shè)備。除了相關(guān)的驅(qū)動程序和中間件之外，Maxim Integrated 的 Micros SDK 還包括示例函數(shù)，這些函數(shù)演示了使用 AES 加密法加密 (AES128_ECB_enc()) 和解密 (AES128_ECB_dec ()) 消息所需的基本設(shè)計模式（清單 2）。
副本int AES128_ECB_enc(int asynchronous)
{
printf( asynchronous ? "Test Cipher Async
" : "Test Cipher Sync
");
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
" : "Test Cipher Sync
");
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：開發(fā)人員可以檢查 Maxim Integrated 的 Micros SDK 分發(fā)包中的示例代碼，以學習使用 MAX32520 MCU 的集成加密函數(shù)執(zhí)行 AES 加密 (AES128_ECB_enc()) 和解密 (AES128_ECB_dec ()) 所需的基本設(shè)計模式。（代碼來源：Maxim Integrated）
身份驗證協(xié)議
要為應(yīng)用中使用的高級協(xié)議提供安全基礎(chǔ)，具有強魯棒性的加密算法實現(xiàn)尤其重要。像傳輸層安全 (TLS) 這樣的較高層級協(xié)議通常使用一組定義的加密算法（稱為密碼套件）來執(zhí)行運算。在 TLS 中，從約定的密碼套件提取的算法有助于確保物聯(lián)網(wǎng)設(shè)備客戶端與主機服務(wù)器之間的通信會話實現(xiàn)身份驗證和機密性。TLS 1.2[8] 會通過一個特定事務(wù)處理序列，在進行數(shù)據(jù)交換之前，協(xié)商參數(shù)、執(zhí)行身份驗證和交換會話密鑰（圖 3）。
圖 3：TLS 1.2 會話創(chuàng)建協(xié)議使用約定密碼套件提供的各種算法進行身份驗證、密鑰交換和持續(xù)的數(shù)據(jù)交換。（圖片來源：Texas Instruments）
鑒于安全證書中包含每個參與者各自的公鑰，可通過驗證安全證書，確定服務(wù)器以及客戶端（可選）的身份以確保實現(xiàn)身份驗證。在此期間，每個參與者都會發(fā)送一條使用其私鑰加密的消息。由于接收到的公鑰僅能解密用其關(guān)聯(lián)私鑰加密的消息，因此每個參與者都可以確認證書提供者實際擁有該證書。
在下一個 TLS 階段，參與者執(zhí)行一系列事務(wù)處理，以創(chuàng)建共享會話密鑰。該共享會話密鑰隨后會用來加密實際的消息流量，從而確保該會話消息交換的機密性。
多種協(xié)議選擇使開發(fā)人員可以優(yōu)化此通用 TLS 會話的創(chuàng)建過程，但有時會影響整體安全性。此外，在參數(shù)交換過程中，開發(fā)人員可以使用不同的密碼套件，為各個協(xié)議階段選擇合適的 TLS 1.2 支持算法組合，具體包括：
密鑰構(gòu)建：RSA、DH、ECDH
身份驗證：RSA、DSA、ECDSA
加密法：3DES、AES
消息驗證：SHA
最新版本的 TLS 為 TLS 1.3[9]，該協(xié)議規(guī)定先執(zhí)行密鑰交換以更好地保護會話創(chuàng)建過程，從而增加了額外的安全性。更重要的是，TLS 1.3 在很大程度上棄用了 TLS 1.2 的密碼套件，轉(zhuǎn)而使用更強大的算法，包括基于 HMAC 的提取和擴展密鑰派生函數(shù) (HKDF)，以及帶有關(guān)聯(lián)數(shù)據(jù)的認證加密 (AEAD) 算法。AEAD 算法滿足了確保消息真實性、完整性和機密性的廣泛需求。這些算法通過將加密消息與 MAC 綁定實現(xiàn)上述要求，而加密與 MAC 可按照串行方式（圖 4，左）、并行方式（圖 4，右）或兩者并用方式生成。
圖 4：AEAD 使用先加密后生成 MAC（左）與同時加密和生成 MAC（右）方式，分別進行串行或并行 MAC 計算，然后將 MAC 與密文綁定從而提供身份驗證與機密性。（圖片來源：維基百科）
增加安全強度
加密算法與相關(guān)協(xié)議的發(fā)展過程，可以說是決心強化安全性的加密專家與同樣堅定的破解者之間不斷追逐的競賽。例如，為了加強安全性，專家開發(fā)了 ECDSA 作為 DSA 的 ECC 變體，而 DSA 本身則是更早期加密法的變體。因此，ECDSA 的安全強度與 DSA 相同，但密鑰大小則大幅縮小。
在密碼學中，算法的安全強度取決于密鑰位數(shù) x 和攻擊將需要約 2x 次運算才能推演出算法所隱藏私鑰的預期。根據(jù)這些條件，不同類別的算法可能需要截然不同的密鑰長度，才能達到相當安全級別（表 1）。
表 1：不同類別的加密算法可能需要截然不同的公鑰 (L) 或私鑰（N、k、f）大小，才能實現(xiàn)級別相當?shù)陌踩珡姸取＃▓D片來源：NIST）
在這張來自 NIST 的表格中，F(xiàn)FC 算法參數(shù) L 和 N 分別對應(yīng)于公鑰和私鑰的大小。k 和 f 分別對應(yīng)于 IFC 和 ECC 算法的密鑰大小。NIST 指出，安全強度 ≤80 的算法（表中橘色背景的單元格）不準再用于保護政府信息，而其他算法（黃色背景的單元格）基于效率考慮，尚未納入 NIST 標準。
在追求更高安全強度的趨勢下，加密法和建議的密碼套件也因此而不斷發(fā)展。例如，美國國家安全局 (NSA) 商業(yè)國家安全算法 (CNSA) 套件取代了早期的 NSA Suite B，并建議使用更穩(wěn)健的參數(shù)來保護被列為最高機密的信息（表 2）。
表 2：NSA 建議的 CNSA 套件包含加密算法以及保護高度敏感信息所需的最低安全強度建議。（圖片來源：Digi-Key，數(shù)據(jù)來源于 NSA）
展望未來，量子計算功能的出現(xiàn)會為整個安全領(lǐng)域，特別是加密算法，帶來巨大的斷層。
結(jié)語
物聯(lián)網(wǎng)設(shè)備和其他互連設(shè)計面臨著越來越多的威脅，因此需要更強大的基于多種加密算法的安全方法。這些算法依賴于一系列轉(zhuǎn)換與數(shù)學運算，將明文加密為密文，再將密文解密為明文，目的是讓破壞安全性的行為徒勞無功。如上所述，可以采用基于硬件的方式實現(xiàn)這些算法，因而開發(fā)人員能夠更輕松地在設(shè)計中整合強大的安全功能，而不會影響功能和性能方面的主要要求。
參考文獻：
How a fish tank helped hack a casino
FIPS PUB 197：官方 AES 標準
IETF RFC 3526 (DH)
NIST SP 800-56B Rev. 1 (DOI) (RSA)
ments/SP800-56Arev1_3-8-07.pdf" target="_blank">NIST SP 800-56A (ECDH)
FIPS Pub 186-4（數(shù)字簽名）
FIPS PUB 180-4：安全哈希標準 (SHS)
IETF RFC 5246 (TLS 1.2)
IETF RFC 8446 (TLS 1.3)
