介紹

這是我們關于物聯網（IoT）安全問題的第二份應用說明。電子設備的安全性是當今互聯世界中的“必備條件”。有大量證據1為了表明當物聯網上設備的安全性受到損害時，您必須謹慎，甚至懷疑該設備和整個物聯網。您肯定不能依靠被黑客入侵的設備進行安全的數據交換、處理或存儲。

在我們的第 1 部分應用說明《保護物聯網：第 1 部分，公鑰加密保護連接設備》中，我們重點關注安全風險的識別，并認為最好的安全性嵌入在電子設備中。我們強調了對策，特別是基于公鑰的算法。

現在，在本后續第2部分應用筆記中，我們將重點介紹安全啟動，它實際上是“信任之根”，也是電子設備可信度的基石。請注意，此討論假定讀者了解密碼學中私鑰和公鑰之間的區別。您可以快速參考我們之前的應用說明，在谷歌搜索這些術語時找到大量討論。在這里，我們將演示如何方便地實現設備安全性，以及如何在現場更新設備。DeepCover安全微控制器將作為支持信任的設備的示例，以保護物聯網。??

信任根始于受信任的軟件

防止試圖破壞電子設備外殼（即硬件）的攻擊的唯一解決方案是使用微控制器，該微控制器從內部不可變存儲器開始執行軟件（請注意，并非每個微控制器都具有此設置和功能）。存儲在微控制器中的軟件被認為是固有的受信任的（即信任根），因為它不能被修改。這種堅不可摧的保護可以通過只讀存儲器（ROM）來實現。或者，如果存在適當的安全性，微控制器內部的閃存（EEPROM）存儲器也可用于存儲信任根軟件。要么有一種保險絲機制，使這個閃存在軟件寫入后不可修改（作為ROM），要么有一個適當的身份驗證機制，只允許授權人員在閃存中寫入信任根軟件。如果這個早期的軟件可以在不受控制的情況下進行修改，則無法保證信任。“早期”意味著它是微控制器上電時執行的第一個軟件。因此，需要此初始軟件的固有可信度。如果該軟件值得信賴，則可用于在放棄微控制器控制權之前驗證應用程序的簽名。它就像一座建立在堅實基礎上的城堡。

引導到安全狀態

上電時，器件的微控制器開始從受信任位置（例如 ROM、受信任的內部閃存）運行信任根代碼。此代碼的主要任務是在成功驗證其簽名后啟動應用程序代碼。簽名的驗證（參見下面的器件所有權）是使用先前加載到微控制器中的公鑰完成的，使用方法1：自我認證或方法2：分層認證，在我們的第1部分應用筆記中討論。為了方便讀者，我們使用下面的側邊欄來重現對驗證和保證公鑰的完整性、真實性和身份的方法的討論。

開發人員仍然可以以通常的方式使用這些受保護的微控制器來編寫軟件、通過JTAG加載和執行軟件以及調試。安全的微控制器不會使開發更加困難。

發布軟件并對代碼進行簽名

一旦軟件完全完成并經過測試，然后由認證實驗室或內部驗證機構審核和批準，就必須發布。發布用于安全啟動的軟件需要一個額外的重要步驟：二進制可執行代碼簽名。事實上，對代碼進行簽名會“密封”代碼（如果不檢測到這些修改，則無法進一步修改代碼）并對其進行身份驗證（審批者的身份已完全確定）。代碼是密封的，因為如果修改，關聯的簽名將變得無效 - 數字簽名的完整性將不再完整。該代碼也經過身份驗證，因為它是由一個獨特的、未公開的私鑰簽名的，私鑰由其所有者——負責簽署代碼的人——小心翼翼地保護。

對代碼進行簽名是認證軟件的重要步驟。軟件一旦獲得外部或內部驗證機構的批準，就不能更改。

取得設備的所有權

通過個性化微控制器中的信任根（處理安全啟動的不可變代碼）來獲取設備的所有權。但我們還需要將軟件審批者擁有的公共代碼驗證密鑰加載到設備中（參見第1部分應用筆記）。請記住，此密鑰是基本密鑰，應受信任。

有兩種方案可以個性化信任根。一種方法使用較小的鍵層次結構，而另一種方法沒有鍵。我們現在將研究這兩種方法。

在第一種方法（圖 1）中，設備的信任根已包含一個根公共“密鑰驗證密鑰”（作為信任根的一部分本質上受信任）。我們稱之為主根密鑰 （MRK）。簡單地重述，該密鑰在信任根中硬編碼，用于驗證公共代碼驗證密鑰 （CVK）。（請參閱邊欄中的方法 2。因此，公共CVK必須在加載到微控制器之前進行簽名。對于此簽名操作，簽名實體是信任根的所有者（即，擁有與信任根中硬編碼的公鑰匹配的私鑰的芯片制造商）。一旦公共 CVK 被信任根加載并接受，信任根的密鑰將不再使用，除了在每次啟動時內部重新檢查 CVK 以確保它未被修改或損壞，或者更新公共 CVK。CVK 現在用于驗證二進制可執行代碼。此個性化步驟具有顯著的潛在優勢：它可以在不安全的環境中執行，因為只有正確簽名的公鑰才能加載到設備中。此外，此個性化步驟并不是一個很大的障礙，因為可以在所有設備上部署相同的CVK。請注意，CVK 可以存儲在外部不受保護的內存中，因為它在使用前經過系統地重新驗證。

圖1.代碼驗證密鑰 （CVK） 由 MRK 驗證，然后用于驗證可執行代碼，然后執行它。

第二種更簡單的個性化信任根的方法不使用先驗密鑰。因此，公共CVK必須加載到內部存儲器中，該存儲器只能由從該內部存儲器運行的受信任軟件寫入，或者加載到不可修改的存儲器中，例如安全環境中的一次性可編程（OTP）存儲器或鎖定閃存（EEPROM）。需要一個受信任的環境來確保預期的公鑰不會被惡意密鑰替換，因為信任根無法驗證此密鑰。此密鑰還必須由校驗和（CRC-32 或哈希）在內部保護，以確保該密鑰沒有完整性問題。或者，為了節省寶貴的 OTP 空間，密鑰可以存儲在不受保護的內存中，但其校驗和值存儲在內部 OTP 內存中。

如此處所述，可以想象一個多方簽名方案，其中多個實體（例如，軟件審批者和外部驗證機構）必須對可執行代碼進行簽名。人們還可以想象更復雜的層次結構，具有不同的代碼驗證密鑰，更中間的密鑰驗證密鑰，甚至多個根密鑰。使用的最終過程實際上取決于應用程序所需的上下文和安全策略。

在此個性化步驟中，可以永久設置其他微控制器選項，例如禁用JTAG。雖然在開發過程中很有用，但必須在生產部件上禁用JTAG，否則可以繞過信任根。

在制造過程中下載應用程序代碼 - 一個簡單而可信的過程

制造過程中的一個步驟包括將先前密封/簽名的二進制可執行代碼加載到設備中。

公鑰方案具有以下獨特優勢：

不需要多樣化。

不涉及任何秘密。

二進制可執行代碼由軟件審批者密封，無法修改。

因此，簽名的二進制可執行代碼可以在任何地方加載。只有此代碼可由電子設備加載和執行;其他二進制可執行代碼將被拒絕。

在此過程中使用公鑰加密非常有價值，因為不會對制造過程施加任何安全限制。

部署、現場維護

基于安全啟動的設備與其他設備一樣部署在現場。但是，若要更新字段中的可執行代碼，必須使用軟件審批者的私鑰對其進行簽名，并通過適當的方式（如本地接口或網絡鏈接）將其加載到設備中。

如果軟件審批者的代碼簽名密鑰被泄露，則還可以在字段中替換關聯的公共 CVK，前提是新密鑰由先前加載到設備中的公鑰驗證密鑰簽名。（此密鑰驗證密鑰是“吊銷后更新”密鑰。但是，泄露根密鑰 （MRK） 不是一種選擇，因為無法在字段中替換此根密鑰。適當的私鑰管理策略確實可以降低這種風險。

密碼學是不夠的

現在假設遵循了適當的密鑰管理和良好的保護實踐。還要假設制造安全、信任和信心得到保證。現在，最后，假設選擇了良好的密碼學，例如標準化算法，足夠長的密鑰，高質量的隨機數。盡管如此，一些主要的安全威脅仍然存在，并嚴重暴露了設備的資產。

公鑰存儲在鎖定的閃存位置，即不能再修改。如果預編程公鑰或安全啟動的完整性基于閃存或OTP存儲器中的鎖定機制，則完整性的強度僅取決于此鎖定技術的強度。任何能夠擊敗這項技術的攻擊者，都可以擊敗目標資產本身的完整性。

同樣，應對數字簽名進行軟件檢查。因此，除了符合算法之外，還有幾種方法可以驗證軟件 - 一些方法健壯，而另一些則不那么可靠。魯棒性意味著抵抗錯誤（有意或無意）、意外問題、錯誤、異常環境條件（例如，低溫、電源故障導致的電源不良）或損壞的字節。這些約束通常通過設備的軟件和硬件驗證來解決和管理。

但穩健性也意味著抵抗特定的、蓄意的、集中的攻擊。這些惡意攻擊可以隨機執行，而無需真正了解平臺（即“黑匣子”攻擊）。或者攻擊可能是在對設備進行認真研究之后進行的（即，攻擊范圍從“灰色”到“白盒”攻擊，對應于攻擊者對平臺的理解水平）。在每個實例中，攻擊者都在尋找可以轉換為攻擊路徑的弱點或限制。

兩個簡單的例子說明了這個想法。我們的第一個示例涉及軟件良好實踐，它要求您在處理輸入數據之前檢查輸入數據的邊界和長度。使用靜態分析工具來評估代碼源質量也是良好做法的一部分。這些操作可幫助開發人員和審核員輕松改進和保證代碼質量。人們還認識到，高效的開發人員將檢測格式錯誤的字節束。遺憾的是，為了盡快交付新軟件，這些檢查并沒有定期實施，因為此外，這些“良好實踐”控制增加了開發時間、測試和驗證時間以及代碼大小，并且通常被認為與基本功能相比不那么重要甚至沒有必要。因此，在實施通信協議后可能會出現緩沖區溢出（圖2），即使是那些理論上安全的協議，如TLS，或內存到存儲器的副本，如在運行應用程序之前從外部NAND閃存到RAM的副本。這些緩沖區溢出通常是對常規操作軟件的功能良好的攻擊。

圖2.緩沖區溢出效果。

另一個示例涉及進程選擇，稱為故障攻擊（圖 3）。從上一節中可以同意，數字簽名檢查對于檢測數據/代碼中的任何完整性/真實性故障非常強大。實際上，在將字節復制到應用程序的運行內存之前，可以對存儲它們的字節執行檢查。但在其他一些操作方案中，字節復制是在檢查發生之前執行的。這意味著這些字節幾乎可以使用/運行，即使它們與數字簽名不匹配。如果攻擊者能夠通過觸發電源故障（圖 3）或任何其他類型的小的非破壞性故障來跳過檢查步驟，則正常進程可能會受到干擾并跳過檢查操作，從而使加載的字節能夠作為真實代碼運行。

一般來說，使安全機制僅依賴于單一的實現機制會削弱這種安全性，并促使攻擊者專注于規避實現。

圖3.故障攻擊的影響：故障通過改變測試條件結果來修改程序的正常路徑。

實施最佳解決方案

目前，像MAX32590這樣的安全微控制器具有信任根，其中包含預加載的不可變根密鑰。在這些安全微控制器中包含MRK的信任根位于ROM或內部OTP或出廠時鎖定的內部閃存中。由于用于存儲密鑰的內存技術是不可變的，因此可以保證 MRK 的完整性。最后，仍對密鑰計算校驗和，以確保在實際使用該密鑰之前不會發生故障。

要初始化自定義的預加載密鑰，客戶將其公共 CVK 提交給制造商進行簽名。制造商使用存儲在 HSM 中的私鑰對客戶的公鑰進行簽名（即認證）2這是嚴格控制的。然后，他們將簽名的公鑰發送回給客戶。此過程很快，在首次發布軟件之前只需要一次（請注意，在軟件開發過程中不需要此安全步驟）。然后，客戶可以加載制造商的密鑰并將其替換為自己的密鑰，并下載其簽名的二進制可執行代碼。

這個過程非常靈活，因為每個部件上都編程了相同的鍵，從而使個性化過程變得非常容易。制造商甚至可以在零件制造之前就使用客戶的密鑰對零件進行個性化（即定制），從而大大減少了客戶的麻煩。此個性化步驟也可以由客戶自己完成。作為一個有趣的責任轉移，后一個關鍵的個性化步驟允許客戶自己擁有微控制器的所有權。最后，DeepCover安全微控制器（如MAX32550）中的ROM代碼允許在現場撤銷和更換密鑰，而不會失去信任。

需要注意的是，這個關鍵的認證過程是不能繞過的。它不是可選的。即使是開發中的安全部件也執行這些相同的原則，但只有一個區別：它們可以在激活測試密鑰的情況下以非常有限的數量提供，以減少在開發或零件評估期間客戶密鑰的暴露。

僅僅為今天設計一個安全的解決方案是不夠的。最實用的解決方案也將為未來的升級而設計。最值得信賴的安全設備（如 DeepCover 設備）支持面向未來的 RSA（高達 2048 位）和 ECC（最多 521 位）簽名方案。此外，PCI PTS實驗室已經審核了他們的代碼。此外，硬件加速器使啟動時的代碼驗證幾乎不可見，因此安全協議不會在啟動過程中造成任何額外的負擔。當代碼從閃存復制到可執行 RAM 時，數字內容摘要是動態計算的。然后，簽名驗證過程只需要很少的額外時間。

DeepCover器件將這些安全機制與其他保護措施相結合，例如JTAG-ICE停用，這使得代碼轉儲、修改或替換變得不可能，因為只有一種機制可以解決靈活/可編程部件上的任何安全問題。所有“門”要么關閉，要么鎖上鑰匙，以給利益相關者提供充分的信心。

結論

我們已經看到，安全啟動是一種廉價但至關重要的安全機制，可用于物聯網上的設備或幾乎任何需要保護資產的應用程序。即使使用這種安全啟動，整體開發和制造過程仍然非常簡單明了。額外的步驟只是：在每個設備中加載一個公共代碼驗證密鑰（CVK），并對要加載到設備的二進制可執行代碼進行簽名。

我們以前說過這一點，但再說一遍是有價值的。我們不允許任何違反電子交易、核電站等關鍵系統或植入式醫療設備的安全漏洞。安全啟動（信任根）是保護物聯網的一個步驟。它使這種信任成為可能并且易于實施。

審核編輯：郭婷