產品安全不可忽視 i.MX RT系列外置Flash加密爲您的產品安全保駕護航

1、背景

NXP宣佈推出i.MX RT系列處理器，內核基於 Arm-Cortex M7，運行主頻高達600MHz，3020的coremark跑分，使人咋舌。i.MX RT1020/1050/1060系列MCU沒有片內FLASH，從而可讓用戶根據實際須要靈活搭配不一樣容量、不一樣廠家的外置FLASH 存儲器。飛凌嵌入式剛剛發佈的OK1061-S、OK1052-C採用的是4MB/16MB串行NorFlash，QSPI接口。使用外置FLASH的方案，也不用擔憂裏面的程序有被竊取的風險，這些問題，NXP在設計芯片之初，都已經考慮在內。下面咱們來了解一下，如何給外置Falsh進行加密。

2、咱們來介紹一下Flash加密的幾種方法：

一、HAB（High-Assurance Boot）簽名認證

這種模式，並非對Falsh中的image進行加密，而是對燒寫到Flash中的image進行合法性認證，檢測image是否被惡意破壞或篡改，若是檢測到image未經受權，即不合法，則MCU便不會執行該image。

咱們使用非對稱加密來實現HAB功能。加密工具會生成私鑰和相應的公鑰對。而後私鑰用於加密咱們想要發佈的鏡像，此加密爲鏡像生成惟一標識符，稱爲證書。公鑰也附加到鏡像上。在程序啓動時，公鑰用於解密證書。用於檢查比較證書和鏡像是否匹配。只有當證書和鏡像匹配時，鏡像才被視爲「受信任」。不然，鏡像被視爲「不安全」，不容許加載和運行。此過程稱爲身份驗證。***只能訪問公鑰，根據非對稱加密的屬性，私鑰不能從中推斷出來。若是沒有私鑰，***就沒法爲其惡意鏡像附加有效證書。咱們將公鑰的摘要值（哈希）燒錄到RT芯片的eFuses。一旦燒寫，就沒法修改。這能夠防止***使用另外一對私鑰和公鑰做弊的可能性。

下面咱們經過圖標來簡單描述一下此過程。

1）產生公鑰私鑰，而且將公鑰摘要值燒寫到efuse：

 

2）使用私鑰對鏡像摘要加密生成鏡像證書：

 

3）安全啓動時，對鏡像證書進行認證的過程：

 

上圖中，一個正常作過簽名的鏡像文件在flash存在形式應該是由image（包括ivt，bootdata、dcd和應用image），HABdata（包括Public Key、Certificate和CSF）兩部分組成，如圖：

 

系統啓動時，MCU內部ROM的BootLoader啓動程序主要進行以下工做：

1） 將flash中image摘要進行HASH運算生產一個摘要值；

2） 使用已經在efuse中的燒寫好的Public Key的摘要值與flash中的Public Key進行匹配，若是匹配成功，則進行下一步。

3） 使用Public Key解密flash中證書Certificate，獲得鏡像摘要值與第一步中生成的鏡像摘要值進行比對，若是比對成功則說明鏡像合法。

二、加密啓動（HAB簽名認證與HAB加密）

加密啓動是簽名認證與加密的組合啓動。

這種模式屬於中級安全模式，簽名認證是對iamge合法性驗證，而HAB加密就是對flash中的用戶image明文經過加密算法轉換爲密文。HAB加密使用的AES-128算法，其對應的128bits的AES-128 Key不是由用戶自定義的，而是HAB加密工具自動隨機生成的，而且每一次加密操做生成的AES-128 Key都是不同的，即便你沒有更換輸入的原始image。咱們的image實際就是使用AES-128 Key這把鑰匙進行加密的，咱們稱這把鑰匙爲：DEK（Data Encryption Key），這把鑰匙存在於加密工具所在的PC機。既然DEK每一次都不同並且存在於我的電腦中，那麼MCU在啓動的時候是怎麼找到這把鑰匙解密的呢？對，咱們須要把這把鑰匙的信息附加在image裏面，燒寫到flash中，待到啓動的時候MCU的bootLoder程序會先把鑰匙從image中取出來。那麼問題來了，既然bootLoder可以取出鑰匙，那麼做爲***的你我能不能也讀出flash中的image取出DEK呢，固然沒那麼簡單，由於這塊存儲DEK的區域也是通過加密的，想要取出DEK還須要另外一把鑰匙Master Secret Key，該鑰匙用於建立密鑰的加密區域blob（DEK blob），這把鑰匙只能由MCU內部的DCP或BEE訪問。這意味着每一個芯片的blob是惟一的。在啓動引導時，blob以這樣的方式封裝，即只有i.MX RT上的DCP才能訪問DEK。下面的這個圖顯示了加密解密的過程：

 

因此一個作過加密啓動的鏡像存在與flash中應該是組織結構：

 

三、加密XIP（單引擎/雙引擎BEE加密）

i.MX RT boot rom支持串行nor flash上的XIP（Execute-In-Place，在flash本地執行代碼），直接使用BEE控制器提供的動態解密功能（使用aes-ctr-128或aes-ecb-128加密算法）。在執行加密XIP以前，引導ROM須要正確設置BEE控制器，這些配置參數存儲在保護區域描述符塊prdb中，而整個prdb使用aes-cbc-128模式加密，這個用於加密prodb的aes密鑰存儲在密鑰信息塊（kib）中，而kid使用efuse中提供的aes密鑰加密爲ekib）。整個或部分軟件圖像使用自定義的私鑰（pvk）加密(而後將密鑰燒錄到片上efuse塊中)，這個密鑰被限制爲僅能使用qspi解密引擎（bee）訪問。在ROM代碼初始化BEE塊以後的引導過程當中，存儲在qspi flash中的加密和未加密的數據能夠被動態訪問。每一個芯片均可以使用一個惟一的密鑰來加密程序鏡像，所以每一個鏡像只能用正確的密鑰在芯片上引導，從而防止鏡像盜用。

i.MX RT內部有兩個BEE加密引擎分別爲BEE引擎0和BEE引擎1，因此BEE加密又分爲單引擎加密和雙引擎加密。

單引擎加密： 經過上面的描述中咱們知道，BEE加密使用用戶自定義的密鑰進行加密，加密時將該密鑰燒錄到MCU內部的efuse中，其實，也可使用MCU內部的SVNS Key做爲密鑰，該密鑰在芯片出廠時已預先燒錄，沒法更改，具備高級別訪問權限，只能由內部DCP或BEE模塊訪問。

單引擎加密能夠自定義設置加密區域和選擇BEE加密引擎（使用 SVNS Key做爲密鑰時只能選擇引擎0，使用自定義密鑰時，便可選擇引擎0也可選擇引擎1）。在加密過程當中，加密工具會將這些配置信息存儲到prdb塊中。密鑰信息存儲在kib信息塊中。

雙引擎加密： 雙引擎加密使用兩個用戶自定義的密鑰，分別賦予引擎0和引擎1使用，用戶能夠分別自定義設置他們的加密區域，加密時加密工具會將這些信息分別存儲在prdb0和prdb1中。密鑰信息存儲在kib0和kib1中。

下面簡單看一下解密流程：

 

 

BEE控制器經過讀取MCU內部efuse燒錄的用戶密鑰PVK，使用該PVK解密EKIB（Encrtpted KIB）密鑰信息塊，將其中的密鑰取出，用於解密EPRDB(Encrtpted PRDB),得到BEE控制器的參數配置信息，BEE控制器經過此配置信息將密文image進行動態解密。

作過BEE加密的鏡像存在於flash中應該是這種組織結構：

3、總結

上面簡單介紹了一些關於Flash加密原理，如今咱們總結一下一共有四中加密模式。

模式一：HAB簽名認證。

模式二：HAB簽名認證和HAB加密。

模式三：SNVS Key單引擎BEE加密。

模式四：用戶自定義Key單引擎BEE或雙引擎BEE加密。

這四種加密模式安全等級依次升高。其中HAB加密屬於靜態加密，是由片內ROM裏的Boot程序將加密後的密文image所有解密成明文image，copy到MCU內存ram中再執行，而BEE加密是由MCU芯片內部的BEE控制器對密文image進行邊解密邊執行，屬於動態加密（若是是Non-XIP Image，則解密執行流程與HAB加密相似）。

原文連接：https://www.forlinx.com/article_view_346.html