i.MX RT系列外置Flash加密為您的產品安全保駕護航
一、背景
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進行加密。
二、我們來介紹一下Flash加密的幾種方法：
1、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，得到鏡像摘要值與第一步中生成的鏡像摘要值進行比對，如果比對成功則說明鏡像合法。
2、加密啟動（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中應該是組織結構：
3、加密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中應該是這種組織結構：
三、總結
上面簡單介紹了一些關于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加密類似）。
換一批
