保護物聯(lián)網(wǎng)：安全啟動，嵌入式設(shè)備的“信任根”

介紹

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

在我們的第 1 部分應(yīng)用說明《保護物聯(lián)網(wǎng)：第 1 部分，公鑰加密保護連接設(shè)備》中，我們重點關(guān)注安全風(fēng)險的識別，并認為最好的安全性嵌入在電子設(shè)備中。我們強調(diào)了對策，特別是基于公鑰的算法。

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

信任根始于受信任的軟件

防止試圖破壞電子設(shè)備外殼（即硬件）的攻擊的唯一解決方案是使用微控制器，該微控制器從內(nèi)部不可變存儲器開始執(zhí)行軟件（請注意，并非每個微控制器都具有此設(shè)置和功能）。存儲在微控制器中的軟件被認為是固有的受信任的（即信任根），因為它不能被修改。這種堅不可摧的保護可以通過只讀存儲器（ROM）來實現(xiàn)?；蛘撸绻嬖谶m當?shù)陌踩?，微控制器?nèi)部的閃存（EEPROM）存儲器也可用于存儲信任根軟件。要么有一種保險絲機制，使這個閃存在軟件寫入后不可修改（作為ROM），要么有一個適當?shù)纳矸蒡炞C機制，只允許授權(quán)人員在閃存中寫入信任根軟件。如果這個早期的軟件可以在不受控制的情況下進行修改，則無法保證信任?！霸缙凇币馕吨俏⒖刂破魃想姇r執(zhí)行的第一個軟件。因此，需要此初始軟件的固有可信度。如果該軟件值得信賴，則可用于在放棄微控制器控制權(quán)之前驗證應(yīng)用程序的簽名。它就像一座建立在堅實基礎(chǔ)上的城堡。

引導(dǎo)到安全狀態(tài)

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

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

發(fā)布軟件并對代碼進行簽名

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

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

取得設(shè)備的所有權(quán)

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

有兩種方案可以個性化信任根。一種方法使用較小的鍵層次結(jié)構(gòu)，而另一種方法沒有鍵。我們現(xiàn)在將研究這兩種方法。

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

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

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

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

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

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

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

公鑰方案具有以下獨特優(yōu)勢：

不需要多樣化。

不涉及任何秘密。

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

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

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

部署、現(xiàn)場維護

基于安全啟動的設(shè)備與其他設(shè)備一樣部署在現(xiàn)場。但是，若要更新字段中的可執(zhí)行代碼，必須使用軟件審批者的私鑰對其進行簽名，并通過適當?shù)姆绞剑ㄈ绫镜?a target="_blank">接口或網(wǎng)絡(luò)鏈接）將其加載到設(shè)備中。

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

密碼學(xué)是不夠的

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

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

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

但穩(wěn)健性也意味著抵抗特定的、蓄意的、集中的攻擊。這些惡意攻擊可以隨機執(zhí)行，而無需真正了解平臺（即“黑匣子”攻擊）?；蛘吖艨赡苁窃趯υO(shè)備進行認真研究之后進行的（即，攻擊范圍從“灰色”到“白盒”攻擊，對應(yīng)于攻擊者對平臺的理解水平）。在每個實例中，攻擊者都在尋找可以轉(zhuǎn)換為攻擊路徑的弱點或限制。

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

圖2.緩沖區(qū)溢出效果。

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

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

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

實施最佳解決方案

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

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

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

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

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

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

結(jié)論

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

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

審核編輯：郭婷