Microchip的微控制器與安全元件相結合如何提供幫助？

微控制器中的不可變啟動存儲器是任何通過安全啟動和安全固件升級實現固件驗證的應用中非常重要的功能。最新的PIC24F低功耗微控制器（MCU）和高性能dsPIC33數字信號控制器（DSC）具有ICSP?寫禁止和CodeGuard? Security的閃存OTP，可實現不可變的安全啟動。ICSP 寫禁止是一種訪問限制功能，激活后，通過外部編程器和調試器以及讀寫保護功能限制對所有閃存的訪問。激活后，ICSP 寫禁止功能可防止 ICSP 閃存編程和擦除操作，并使閃存的行為類似于一次性可編程 （OTP） 存儲器。CodeGuard 安全功能支持將閃存程序內存分段為兩個具有不同權限的專用區域。第一個內存區域是引導段，它保存實現固件驗證例程的引導加載程序代碼。此引導段可以對自身和內存的應用程序區域的所有自寫進行寫保護。CodeGuard 安全性與 ICSP 寫禁止功能的閃存 OTP 一起使引導加載程序不可變。正如我們之前提到的，我們必須記住，在當前的上下文中，不可變并不意味著無法訪問或不可讀，但無法通過遠程數字攻擊進行修改。第二個內存區域稱為保存應用程序映像的常規段。

在 CodeGuard Flash 安全性的引導段中實現的固件驗證碼（不允許更改）向利用 CryptoAuthlib 庫的安全元素發出 ECDSA 驗證命令。來自加密身份驗證系列信任平臺的 TrustFLEX ATECC608 安全元件配備了安全密鑰存儲和基于硬件的加密加速器，能夠在幾毫秒內運行 ECDSA 驗證操作，并且它還將安全地保護將用于在代碼簽名和/或代碼摘要上執行此加密功能的公鑰。公鑰現在存儲在安全元件的不可變安全內存區域中，利用防篡改和側信道攻擊保護進行物理保護。現在訪問和更改密鑰和代碼要困難得多。查看我們的軟件庫，了解MPLAB代碼配置器（MCC）支持的PIC24F MCU和dsPIC33 DSC，MPLAB?代碼配置器（MCC）是一個免費的圖形編程環境，可生成無縫、易于理解的C代碼以插入到您的項目中。MCC 中的 CryptoAuthlib 庫簡化了 TrustFLEX ATECC608 與 PIC24 或 dsPIC33 器件的接口，并可實現各種安全功能。您可以通過 MCC 16 位引導加載程序庫添加固件驗證和安全固件升級功能。有關更多信息，請訪問我們的嵌入式安全設計中心，了解如何實施安全啟動和 OTA。您還可以參考 ShieldsUP 安全網絡研討會 #26：使用 dsPIC33 DSC、PIC24F MCU 和 ATECC608 器件簡化安全應用設計

MCU 和 ATECC608 TrustFLEX 之間的交易圖是怎樣的？

信任平臺設計套件（TPDS）軟件工具是開始使用Microchip安全元件的起點。打開 TPDS 時，可以選擇用例和開發平臺。然后，該工具將詳細說明所選用例的實際事務圖。

例如，下面是經典微控制器和 TrustFLEX ATECC608 之間的固件驗證事務圖。它顯示了主機MCU如何計算固件摘要，將該摘要作為質詢發送到安全元素，安全元素嘗試使用預先配置的公鑰以加密方式驗證摘要+簽名，最后接收來自安全元素的響應。您可以看到主機MCU用于與安全元件通信的實際CryptoAuthLib API調用，例如“atcab_secureboot_MAC”，以及對MCU和安全元件之間實際發生的情況的簡單描述。

圖 1：使用 TrustFLEX ATECC2 的固件驗證用例的信任平臺設計套件 V608 事務圖

在此方案中，該工具將引導您完成以下期間需要發生的情況：

- 原型制作階段：

非對稱密鑰對由工具生成用于原型設計

公鑰由 TPDS 再次通過您的筆記本電腦進行配置，用于原型設計目的。對于生產，Microchip提供安全密鑰配置服務

使用私鑰對代碼圖像進行簽名，以創建代碼圖像的簽名

- 啟動時：

主機MCU計算摘要

主機MCU將摘要和簽名發送到安全元件

安全元件驗證并響應有效/無效

主機 MCU 接收響應，指示固件的有效性

固件被授權在MCU中運行

如果您的微控制器沒有 BootROM 功能，但您仍然想使用安全元件怎么辦？

現在想象一下，您的設計基于經典的32位微控制器，例如SAMD21 ARM? Cortex? M0+，并且沒有BootROM功能。這是當今絕大多數設計的情況，更換為新的微控制器涉及重新認證成本和時間，而這些成本和時間并不總是負擔得起的。

在這種情況下，您需要假設您的微控制器代碼可以更改。如果從微控制器到安全元件的ECDSA驗證命令可以更改，后果是什么？如果代碼仍然已簽名，并且您的微控制器內沒有用于驗證的密鑰，則可能會受到影響，但不會影響您的整個設備群（假設您使用的是公鑰基礎設施）。這是由于安全元件使您的公鑰保持隔離，它將保護隊列的其余部分。需要考慮的幾個問題可能包括：

是否值得花時間對代碼進行逆向工程，以簡單地關閉您必須物理訪問的設備？在大多數情況下，可能不會。這會影響設備隊列嗎？每個設備都必須物理訪問，這是不切實際的。從遠程攻擊的角度來看，如果我們假設需要 OTA 更新來驗證真正簽名的代碼并且代碼中沒有密鑰，則可能不會。

此外，您能否信任您的合同制造商，提供將驗證您的代碼的加密密鑰？如果答案是否定的，則安全元件的價值將翻倍，因為Microchip提供安全的密鑰配置服務，可以在我們的安全工廠內秘密加載密鑰，以消除合同制造商的密鑰暴露并繞過中間人。計劃您想要更改CM的那一天，如果密鑰位于安全元件中，則只需使用Microchip更改送貨地址即可。

最后，損益（P&L）與財務風險水平的成本影響是一個巨大的考慮因素。我們已經看到客戶使用我們的安全元件，因為它是一種非常經濟高效的密鑰解決方案。一旦您在嵌入式系統中加載密鑰，您就可以自定義該微控制器或微處理器。想象一下，您的處理器大約是 3-5 美元，現在您已經定制了您的控制器，這些控制器是不可取消、不可退回的多美元硅片，放在您的貨架上。安全元件大大降低了財務風險。

物流供應鏈障礙和在MCU中安全配置“驗證”密鑰的成本增加

微處理器通常比微控制器具有更豐富的安全功能，但這兩種解決方案都需要有一個安全的物理邊界，密鑰和加密算法都將位于該邊界。不幸的是，這種設計很難以經濟高效的方式實現，因為安全邊界會對處理器或控制器的芯片成本產生重大影響。單體解決方案的成本并不是唯一需要增加的成本，但完全支持此類架構的技術支持、處理多用戶權限的各種工具以及安全處理密鑰配置的供應鏈物流繼續增加復雜性和風險。讓我們從損益的角度來看這個問題。讓我們想象一下 100，000 個微處理器單元，它們都裝有密鑰，這使得所有這些處理器都是自定義的。現在想想你貨架上的庫存成本，無論你是分銷商，還是一個OEM，這個成本都會打擊你的損益，并隨著時間的推移增加你的項目風險，因為項目不斷被自然地推遲。

更具可擴展性的架構是使用Microchip CryptoAuthentication?配套設備，如ATECC608 TrustFLEX。密鑰被隔離在經濟高效的安全密鑰存儲中，幾乎可以運送到世界任何地方（根據 EAR99 出口法規）。安全密鑰配置服務消除了密鑰暴露給供應鏈中間商，減少了攻擊面。

總之，您需要考慮安全啟動的固件驗證、運行時代碼驗證和 OTA 更新后的安全基礎，以及在處理加密密鑰時的各種供應鏈風險和成本。將安全元件（如 ATECC608）與微控制器（如 dsPIC33 DSC 或 PIC24F MCU）與具有不可變啟動功能的組合是設計的絕佳基礎選擇。如果微控制器沒有 bootROM 功能，但依賴于安全元件來物理隔離公鑰，則您的威脅模型和風險評估可能會在大多數應用程序中驗證此類架構。

審核編輯：郭婷