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