IoT 安全基礎知識 — 第 1 篇：加密的使用

作者：Stephen Evanczuk

資料提供者：DigiKey 北美編輯群

2020-06-03

編者說明：此系列文章包含數篇內容，為開發人員提供實用的指南，協助其確保從一開始就遵循最佳做法。本文為第 1 篇，探討建構起安全設計的加密演算法。第 2 篇將探討私鑰、金鑰管理和安全儲存在安全系統中所扮演的角色。第 3 篇將研究安全處理器的內建機制，檢驗這些機制是否能減輕威脅，防止其破壞 IoT 裝置上的系統和應用軟體執行。第 4 篇將識別並說明如何在進階處理器中應用安全機制，協助確保已具備所需的隔離，以減緩對 IoT 裝置執行階段環境所進行的攻擊。第 5 篇將說明如何透過 IoT 裝置所用的更高階安全措施，在將裝置連接到 IoT 雲端資源時，繼續維護 IoT 安全性。

工業、醫療、運輸和其他重要應用對 IoT 應用的依賴程度快速提升，安全佈局也隨之產生極大變化。以往，企業應用普遍擁有隨時可用的資源來處理安全演算法，但如今企業級 IoT 應用卻飽受日益增加的一連串威脅，且其攻擊目標是不斷擴大的資源受限型 IoT 裝置網絡。急著應對快速興起的 IoT 商機時，組織往往倉促佈署連基本安全功能都沒有的 IoT 裝置，因此無法保護儲存的資料，以及資料與指令在易受攻擊的網路之間的交換。

當然，開發人員需要下多少功夫來保護設計，則取決於多個因素。每個應用面臨的威脅都不相同，需要適當評估這些威脅帶來的風險。連線式裝置遭遇的威脅數量非比尋常，因此任何 IoT 裝置都至少需要一些最低程度的安全措施。

對某些人來說，為簡易型 IoT 裝置實作穩健的安全措施，似乎有過度設計之嫌。但是，如果保護措施不足，即便單純的溫度感測器，也會成為駭客入侵公司網路的切入點 ^[1]。正是 IoT 應用無處不在的連線，以及這些應用底層裝置的資源受限情況，才導致 IoT 安全性不斷面臨挑戰。事實上，即便 IoT 裝置的設計具備充足的資源，能夠在軟體中執行加密演算法，若實作演算法時出現細微錯誤，應用仍會受到攻擊。

本文將介紹加密演算法的基本類別，並探討其在安全性中所扮演的角色。然後說明開發人員如何利用 Maxim Integrated、Microchip Technology 和 Texas Instruments 等公司的處理器以及專用裝置來加速這些演算法，並在簡化實作的同時增強安全性的各個層面。

各種加密演算法及其角色

加密演算法可分成三大類，可應對機密性、身份驗證 (確認訊息來源)、不可否認性 (證明訊息是由寄件者建立及加密或簽署) 以及完整性的基本安全原則：

對稱金鑰演算法，即演算法或密碼會使用相同的安全金鑰，將人類可讀的訊息 (明文) 加密成受保護的版本 (密文)，之後再將密文解密為明文。對稱金鑰加密法通常用於確保機密性。常見的對稱加密演算法包括：
- Triple DES (資料加密標準)，亦稱為 3DES 或三重資料加密演算法 (TDEA)，後者為美國國家標準暨技術局 (NIST) 制訂的正式名稱。
- 先進加密標準 (AES)^[2] 演算法，例如使用 256 位元金鑰的 AES-256。
非對稱金鑰演算法，即加密法使用一對私鑰和公鑰對訊息進行加密和解密，通常屬於範圍更廣的金鑰協商和數位簽章安全協定。非對稱加密法通常用於確保機密性、身份驗證或不可否認性。公鑰加密演算法包括：
- 使用有限域加密 (FFC) 的演算法包括：
  - 聯邦資訊處理標準 (FIPS) 的數位簽章演算法 (DSA)
  - 網際網路工程工作小組 (IETF) 的迪菲-赫爾曼 (DH)^[3]金鑰交換
- 使用整數分解加密 (IFC) 的演算法包括：
  - RSA (Rivest–Shamir–Adleman)^[4]演算法
- 使用橢圓曲線加密 (ECC) 的演算法包括：
  - 橢圓曲線迪菲-赫爾曼 (ECDH)^[5]金鑰交換
  - 橢圓曲線數位簽章演算法 (ECDSA) ^[6]
雜湊演算法，此演算法將原始訊息縮減成一個很小且長度固定的獨特數值，其通常稱為雜湊、摘要或簽章。這些單向轉換函數在驗證訊息是否遭到竄改 (完整性) 時扮演重要角色，可應用於涉及訊息驗證碼 (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：這段偽程式碼描述訊息加密中涉及的操作序列。此序列使用一組由發送者私鑰衍生的值，將明文 (輸入) 轉換為密文 (輸出)。(程式碼來源：NIST)

在回合中，SubBytes() 轉換會使用替換表 (S-box) 取代每個位元組，而該表本身也是一連串轉換後的結果 (圖 1)。

圖 1：在 AES 加密法中，SubBytes() 階段使用替換表 (S-Box) 取代每個位元組。(圖片來源：NIST)

在序列的下一個步驟中，ShiftRows() 轉換對最後三行中的位元進行移位，且每行移動不同數量的位元 (圖 2)。

AES 加密法執行序列中的 ShiftRows() 階段示意圖 圖 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 建立另一個座標點 (x₁,y₁)：

方程式 3

產生訊息 m 的 SHA 雜湊，即 H(m)
使用亂數 k 的模數倒數 k^-1，產生數位簽章的最終 r 和 s 分量，具體如下所示：

方程式 4

方程式 5

最終結果為一個交換值，可驗證訊息、確認訊息完整性並確保不可否認性。

如何實作加密演算法

從表面來看這些演算法會發現，加密演算法依靠一連串數學運算來嘗試影響結果，但由於運算量龐大，導致要快速完成運算根本不可能或不切實際，因此不會遭到入侵者利用。此外，即便粗略地檢驗每種演算法也能看出，資源受限的 IoT 裝置若要執行軟體實作的演算法，幾乎不太可能不對裝置的主要功能要求進行妥協。最後，未能在本文所示步驟中顯示的演算法精確細節透露出，即便是微不足道的編碼錯誤或對標準的輕微誤解，也可能造成安全弱點，甚至會讓加密過程徹底失敗。

即便是最大的開發機構和極度仰賴這些演算法的應用，也可能會在實作演算法時發生錯誤。例如，某遊戲主機就曾發生過一次眾所周知的安全弱點事件，原因就是在實作 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 運算。在 IoT 裝置或智慧型周邊裝置中，主機處理器可使用此類身份驗證 IC 來快速建立 ECDSA P-256 數位簽章，以傳送至另一個裝置，或是驗證來自其他裝置的 ECDSA P-256 簽章。

支援安全功能的處理器與專用裝置，通常是以廣泛的硬體式安全架構打造，可提供額外的安全功能，如高品質的亂數產生器。許多提供此層級能力的裝置會運用半導體設計中固有的隨機雜訊來源，將真實亂數產生器 (TRNG) 所需的熵值最大化。正如前述比特幣範例所示，這類 TRNG 是確保加密演算法正常運作的重要因素。

私鑰與其他安全資料的整合性安全儲存支援，是安全設計的重大能力之一。這些處理器及其他類似處理器更具備其他架構性功能，可提供更深層的安全支援。

具有整合式加密加速器與相關特點的處理器，可憑藉其所有能力，透過直覺化的應用程式開發介面 (API) 資料庫，來簡化安全設計的開發。直覺化的 API 函數調用能讓開發人員對安全實作進行抽象化，並依賴 API 來存取底層的硬體功能。例如，開發人員可以使用 Maxim Integrated 的 MAX32520-KIT 評估套件 (適用於 MAX32520 MCU)，並搭配 Maxim Integrated 的 Micros 軟體開發套件 (SDK)，快速構建安全的 IoT 裝置。除了相關的驅動程式與中介軟體，Maxim Integrated 的 Micros SDK 還包含範例函數，可用於展示 AES 加密法進行訊息加密 (AES128_ECB_enc()) 和解密 (AES128_ECB_dec ()) 所需的基本設計模式 (清單 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：開發人員可以檢視 Maxim Integrated 的 Micros SDK 發行套件內的範例程式碼，以瞭解使用 MAX32520 MCU 內建的加密函數來執行 AES 加密 (AES128_ECB_enc()) 與解密 (AES128_ECB_dec ()) 時所需的基本設計模式。(程式碼來源：Maxim Integrated)

身份驗證協定

若要為應用中使用的更高階協定提供安全基礎，實作可靠的加密演算法尤其重要。傳輸層安全性 (TLS) 等更高階協定通常會使用一組定義好的加密演算法 (稱為加密套件)，來執行相關運算。在 TLS 中，從約定的加密套件提取的演算法，有助於在 IoT 裝置用戶端與主機伺服器之間的通訊工作階段中，確保達到身份驗證和機密性。TLS 1.2[8] 會通過特定序列的交易，來協商參數、執行身份驗證以及交換工作階段金鑰，然後才會進行資料交換 (圖 3)。

TLS 1.2 工作階段建立協定的示意圖 圖 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 右) 或兩者並用的方式產生。

AEAD 提供身份驗證與機密性的示意圖圖 4：AEAD 使用所謂的「加密-然後-MAC」(左) 與「加密-並-MAC」(右) 等方法，分別以串聯或並聯方式計算 MAC，然後將 MAC 與密文整合在一起，以提供身份驗證與機密性。(圖片來源：Wikipedia)

提高安全強度

加密演算法與相關協定的演化過程，可以說是決心強化安全性的加密專家與同樣堅定的破解者之間不斷角逐的競賽。例如，為了加強安全性，專家開發了 ECDSA 作為 DSA 的 ECC 變體，而 DSA 本身則是更早期加密法的變體。結果是 ECDSA 可以達到與 DSA 相同強度的安全性，但金鑰大小則大幅縮小。

在密碼學中，演算法的安全強度由以下因素定義：x 位元數，以及預期一次攻擊將需要約 2^x 次運算才能推衍出演算法底層的私鑰。按照這些定義，不同類別的演算法可能需要截然不同的金鑰長度，才能達到相當水準的安全性 (表 1)。

不同類別的加密演算法表格 表 1：不同類別的加密演算法可能需要金鑰大小截然不同的公鑰 (L) 或私鑰 (N、k、f)，才能達到相當水準的安全強度。(圖片來源：NIST)

在 NIST 提供的這張表格中，FFC 演算法參數 L 與 N 分別對應公鑰與私鑰的大小。對於 IFC 和 ECC 演算法，k 和 f 分別對應金鑰大小。NIST 指出，安全長度為 £80 的演算法 (表中的橘色背景者) 不再批准用於保護政府資訊，而其他演算法 (黃色背景者) 基於效率考量，尚未納入 NIST 標準。

在追求更高安全強度的趨勢下，加密法和建議的加密套件也不斷演變。例如，美國國家安全局 (NSA) 商用國家安全演算法 (CNSA) 套件取代早期的 NSA Suite B，並建議使用更強大的參數來保護列為最高機密的資訊 (表 2)。

加密演算法以及最低安全強度的相關建議表格 表 2：NSA 建議的 CNSA 套件包含加密演算法，以及保護高度敏感性資訊所需的最低安全強度建議。(圖片來源：Digi-Key，引述 NSA 資料)

展望未來，量子運算能力的可用性會對總體安全性產生戲劇性的斷層，特別是加密演算法。

結論

IoT 裝置與其他連線設計面臨越來越多的威脅，因此需要使用以多種加密演算法為基礎而日益強大的安全方法。這些演算法依賴一連串的轉換與數學運算，將明文加密為密文，再將密文解密為明文，目的是讓破壞安全性的行為徒勞無功。如前面所述，可採用硬體方式實作這些演算法，就能讓開發人員更輕鬆打造具備強大安全性的設計，而不會影響對功能與效能的主要要求。