NXP宣布推出i.MXRT系列處理器，內核基於Arm-CortexM7，運行主頻高達600MHz，3020的coremark跑分，令人咋舌。
i.MXRT1020/1050/1060系列MCU沒有片內Flash，從而可以讓用戶根據實際需要靈活搭配不同容量、不同廠家的外置Flash存儲器。
飛凌嵌入式剛剛發布的OK1061-S、OK1052-C採用的是4MB/16MB串行NorFlash，QSPI接口。使用外置FLASH的方案，也不用擔心裏面的程序有被竊取的風險，這些問題，NXP在設計晶片之初，都已經考慮在內。
下面我們來了解一下，如何給外置Falsh進行加密。
1、我們來介紹一下Flash加密的幾種方法：
HAB（High-AssuranceBoot）籤名認證
這種模式，並不是對falsh中的image進行加密，而是對燒寫到Flash中的image進行合法性認證，檢測image是否被惡意破壞或篡改，如果檢測到image未經授權，即不合法，則MCU便不會執行該image。
我們使用非對稱加密來實現HAB功能。加密工具會生成私鑰和相應的公鑰對。然後私鑰用於加密我們想要發布的鏡像，此加密為鏡像生成唯一標識符，稱為證書。公鑰也附加到鏡像上。在程序啟動時，公鑰用於解密證書。用於檢查比較證書和鏡像是否匹配。只有當證書和鏡像匹配時，鏡像才被視為「受信任」。否則，鏡像被視為「不安全」，不允許加載和運行。此過程稱為身份驗證。黑客只能訪問公鑰，根據非對稱加密的屬性，私鑰不能從中推斷出來。如果沒有私鑰，黑客就無法為其惡意鏡像附加有效證書。我們將公鑰的摘要值（哈希）燒錄到RT晶片的eFuses。
一旦燒寫，就無法修改。這可以防止黑客使用另一對私鑰和公鑰作弊的可能性。下面我們通過圖標來簡單描述一下此過程。
1）產生公鑰私鑰，並且將公鑰摘要值燒寫到efuse：
2）使用私鑰對鏡像摘要加密生成鏡像證書：
3）安全啟動時，對鏡像證書進行認證的過程：
上圖中，一個正常做過籤名的鏡像文件在Flash存在形式應該是由image（包括ivt，bootdata、dcd和應用image），HABdata（包括PublicKey、Certificate和CSF）兩部分組成，如圖：
系統啟動時，MCU內部ROM的BootLoader啟動程序主要進行如下工作：
■ 將Flash中image摘要進行HASH運算生產一個摘要值；
■ 使用已經在efuse中的燒寫好的Public Key的摘要值與Flash中的Public Key進行匹配，如果匹配成功，則進行下一步。
■ 使用Public Key解密Flash中證書Certificate，得到鏡像摘要值與第一步中生成的鏡像摘要值進行比對，如果比對成功則說明鏡像合法。
加密啟動（HAB籤名認證與HAB加密）
加密啟動是籤名認證與加密的組合啟動。
這種模式屬於中級安全模式，籤名認證是對iamge合法性驗證，而HAB加密就是對Flash中的用戶image明文通過加密算法轉換為密文。HAB加密使用的AES-128算法，其對應的128bits的AES-128Key不是由用戶自定義的，而是HAB加密工具自動隨機生成的，並且每一次加密操作生成的AES-128Key都是不一樣的，即使你沒有更換輸入的原始image。
我們的image實際就是使用AES-128Key這把鑰匙進行加密的，我們稱這把鑰匙為：DEK（DataEncryptionKey），這把鑰匙存在於加密工具所在的PC機。
既然DEK每一次都不一樣而且存在於個人電腦中，那麼MCU在啟動的時候是怎麼找到這把鑰匙解密的呢？對，我們需要把這把鑰匙的信息附加在image裡面，燒寫到Flash中，待到啟動的時候MCU的bootLoder程序會先把鑰匙從image中取出來。
那麼問題來了，既然bootLoder能夠取出鑰匙，那麼作為黑客的你我能不能也讀出Flash中的image取出DEK呢，當然沒那麼簡單，因為這塊存儲DEK的區域也是經過加密的，想要取出DEK還需要另一把鑰匙MasterSecret Key，該鑰匙用於創建密鑰的加密區域blob（DEKblob），這把鑰匙只能由MCU內部的DCP或BEE訪問。
這意味著每個晶片的blob是唯一的。在啟動引導時，blob以這樣的方式封裝，即只有i.MXRT上的DCP才能訪問DEK。下面的這個圖顯示了加密解密的過程：
所以一個做過加密啟動的鏡像存在與Flash中應該是組織結構：
加密XIP（單引擎/雙引擎BEE加密）
i.MXRT boot rom支持串行norFlash上的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塊之後的引導過程中，存儲在qspiFlash中的加密和未加密的數據可以被動態訪問。
每個晶片都可以使用一個唯一的密鑰來加密程序鏡像，因此每個鏡像只能用正確的密鑰在晶片上引導，從而防止鏡像盜用。
i.MXRT內部有兩個BEE加密引擎分別為BEE引擎0和BEE引擎1，所以BEE加密又分為單引擎加密和雙引擎加密。
單引擎加密：通過上面的描述中我們知道，BEE加密使用用戶自定義的密鑰進行加密，加密時將該密鑰燒錄到MCU內部的efuse中，其實，也可以使用MCU內部的SVNSKey作為密鑰，該密鑰在晶片出廠時已預先燒錄，無法更改，具有高級別訪問權限，只能由內部DCP或BEE模塊訪問。
單引擎加密可以自定義設置加密區域和選擇BEE加密引擎（使用SVNSKey作為密鑰時只能選擇引擎0，使用自定義密鑰時，即可選擇引擎0也可選擇引擎1）。
在加密過程中，加密工具會將這些配置信息存儲到prdb塊中。密鑰信息存儲在kib信息塊中。
雙引擎加密：雙引擎加密使用兩個用戶自定義的密鑰，分別賦予引擎0和引擎1使用，用戶可以分別自定義設置他們的加密區域，加密時加密工具會將這些信息分別存儲在prdb0和prdb1中。密鑰信息存儲在kib0和kib1中。
▼下面簡單看一下解密流程：
BEE控制器通過讀取MCU內部efuse燒錄的用戶密鑰PVK，使用該PVK解密EKIB（EncrtptedKIB）密鑰信息塊，將其中的密鑰取出，用於解密EPRDB(EncrtptedPRDB)，獲得BEE控制器的參數配置信息，BEE控制器通過此配置信息將密文image進行動態解密。
做過BEE加密的鏡像存在於Flash中，應該是這種組織結構：
2、總結
上面簡單介紹了一些關於Flash加密原理，現在我們總結一下一共有四中加密模式。
■ 模式一：HAB籤名認證。
■ 模式二：HAB籤名認證和HAB加密。
■ 模式三：SNVSKey單引擎BEE加密。
■ 模式四：用戶自定義Key單引擎BEE或雙引擎BEE加密。
這四種加密模式安全等級依次升高。
其中HAB加密屬於靜態加密，是由片內ROM裡的Boot程序將加密後的密文image全部解密成明文image，copy到MCU內存ram中再執行，而BEE加密是由MCU晶片內部的BEE控制器對密文image進行邊解密邊執行，屬於動態加密（如果是Non-XIPImage，則解密執行流程與HAB加密類似）。