大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是i.MXRT系列中資料協處理器DCP使用SNVS Master Key加解密的注意事項。
i.MXRT不僅僅是處理效能超強的MCU，也是安全等級極高的MCU。如果大家用過痞子衡開發的一站式安全啟動工具 NXP-MCUBootUtility，應該會從其 使用者手冊 3.3節中瞭解到i.MXRT支援的幾種安全啟動等級，其中HAB加密啟動方式和BEE/OTFAD加密啟動方式中都提及了一種神祕的金鑰 - SNVS Master Key，今天痞子衡就跟大家聊聊這個金鑰用於DCP模組的注意事項（文中僅以i.MXRT1060為例，其他RT10xx型號或許有微小差別）。
一、DCP模組簡介
先來給大家科普下DCP模組，DCP是Data Co-Processor的簡稱，從名字上看是個通用資料協處理器。在i.MXRT1060 Security Reference Manual中有一張系統整體安全架構簡圖，這個簡圖中標出了DCP模組的主要功能 ：CRC-32演算法、AES演算法、Hash演算法、類DMA資料搬移。
看到DCP支援的功能，你就能明白其模組命名的由來了。本質上它就是一個資料處理加速器，如果說CRC-32/Hash演算法只是算出一個結果（下圖中Mode3），而AES演算法則是明文資料到密文資料的轉換（存在資料遷移，下圖中Mode2），DMA式資料搬移則更明顯了（下圖中Mode1），DCP內部整合了memcopy功能，可以實現比普通DMA方式效率更高的記憶體到記憶體資料塊搬移，memcopy功能還支援blit模式，支援傳輸矩形資料塊到frame buffer用於LCD顯示。
我們今天主要是聊DCP的AES加解密功能，其支援AES-128演算法，包含Electronic Code Book (ECB)和Cipher Block Chaining (CBC)模式，演算法標準符合 NIST US FIPS PUB 197 (2001)規範，AES運算的最小單元是16位元組。
二、DCP-AES金鑰來源
對於加解密而言，一個很重要的特性就是金鑰管理。DCP的AES金鑰（長度均為128bits）來源很豐富，按性質可分成四類：
- SRAM-based keys: 使用者自定義的存放於SRAM中的金鑰，最終會被寫入DCP的KEY_DATA暫存器中，最多四組。
- Payload key: 使用者自定義的跟加解密資料放一起的金鑰，操作時DCP直接解析。
- eFuse SW_GP2 key: 使用者燒錄到eFuse SW_GP2區域的金鑰，可鎖定住讓軟體無法訪問，但DCP可通過內建專用途徑獲取到。
- SNVS Master key: 晶片出廠時預存的唯一金鑰，金鑰值無法獲知，DCP可通過內建專用途徑獲取到。
選用SRAM-based keys和Payload key僅需要在DCP模組內部配置即可，而選用eFuse SW_GP2 key和SNVS Master key則要在如下IOMUXC_GPR暫存器中額外設定。
IOMUXC_GPR_GPR10暫存器用於選擇Key是來自eFuse SW_GP2還是SNVS Master Key：
IOMUXC_GPR_GPR3暫存器用於選擇Key是來自SNVS Master Key（總256bits）的低128bit還是高128bit（注意此暫存器對eFuse SW_GP2其實不生效，因為SW_GP2僅128bits）：
三、什麼是SNVS Master Key？
SNVS全稱Secure Non-Volatile Storage，它既是DCP的配套模組，也是晶片系統的安全事務監測中心。它能夠提供一個獨特的Master Key給DCP模組，這個Master Key可有三種產生方式（在SNVS_LPMKCR中設定）：
- OTPMK：這種就是直接使用eFuse裡出廠預燒錄的OTPMK（256bits），這個OTPMK是每個晶片唯一的，並且被鎖住了軟體不可訪問。
- ZMK：這種是利用存在SNVS_LP ZMKRx暫存器組中的金鑰，該祕鑰可由使用者寫入，此金鑰在晶片主電源斷掉時會繼續保留（因為在LP域可由鈕釦電池供電），在晶片受到安全攻擊時金鑰會被自動擦除。
- CMK：前兩者組合後的Key，即OTPMK和ZMK的異或結果。
一般來說，使用最多的SNVS Master Key就是預設的OTPMK。
四、兩種DCP驅動
關於DCP模組的驅動，在下載的晶片SDK包裡有兩種：
- ROM版本：\SDK_2.x.x_EVK-MIMXRT1060\devices\MIMXRT1062\drivers\fsl_dcp.c
- SDK版本：\SDK_2.x.x_EVK-MIMXRT1060\middleware\mcu-boot\src\drivers\dcp\fsl_dcp.c
middleware裡的DCP驅動是ROM team負責的，他們是在晶片Tapeout之前寫的，屬於早期驅動；device包裡的DCP驅動才是SDK team負責的，是晶片Tapeout之後寫的，是正式版本。
兩版驅動都實現了AES加解密，不過程式碼風格不同。比如ROM版本驅動的dcp_aes_ecb_crypt()函式同時支援加密和解密模式，而在SDK版本驅動裡則分成兩個函式：DCP_AES_EncryptEcb() - 加密 、DCP_AES_DecryptEcb() - 解密。
五、DCP正確獲取SNVS Master Key
前面鋪墊了那麼多，終於來到正題了。DCP模組如何拿到正確的SNVS Master Key？讓我們以\SDK_2.x.x_EVK-MIMXRT1060\boards\evkmimxrt1060\driver_examples\dcp 例程來做個測試。
這個dcp例程演示了五種DCP工作模式，我們就測試第一種TestAesEcb()，將巨集DCP_TEST_USE_OTP_KEY改為1，即使用OTPMK低128bits作為DCP的金鑰：
#define DCP_TEST_USE_OTP_KEY 1 /* Set to 1 to select OTP key for AES encryption/decryption. */
int main(void)
{
dcp_config_t dcpConfig;
// ...
/* Initialize DCP */
DCP_GetDefaultConfig(&dcpConfig);
#if DCP_TEST_USE_OTP_KEY
/* Set OTP key type in IOMUX registers before initializing DCP. */
/* Software reset of DCP must be issued after changing the OTP key type. */
DCP_OTPKeySelect(kDCP_OTPMKKeyLow);
#endif
/* Reset and initialize DCP */
DCP_Init(DCP, &dcpConfig);
/* Call DCP APIs */
TestAesEcb();
// ...
}
在初始晶片狀態（Hab Open）下，使用J-Link下載工程進RAM直接單步除錯看一看，在執行完DCP_AES_EncryptEcb()函式後檢視cipher[]陣列，可以看到其值為0xCF, 0x2E, 0xA3...，好吧我們根本不知道SNVS Master Key到底是多少，所以這個密文是否正確也無從知曉。
既然無法得知SNVS Master Key，那我們做個小實驗，使用SRAM-based keys來做一次加密，金鑰姑且設個全0吧，再看一下結果，你發現了什麼，cipher[]的值是不是很熟悉？跟之前SNVS Master Key加密的結果一致，難道這顆晶片的SNVS Master Key是全0？想想不可能，肯定是流程哪裡出了問題！
現在讓我們再回憶 MCUBootUtility 使用者手冊裡關於測試HAB加密以及BEE/OTFAD加密使用SNVS Master Key的前提條件，是的，晶片狀態需要先設定為Hab Close，好，讓我們現在在eFuse裡將SEC_CONFIG[1:0]設為2'b10（Hab Close），然後再次使用J-Link除錯進去看一看，怎麼回事？cipher[]值依舊是0xCF, 0x2E, 0xA3...
上面的測試對TestAesEcb()函式做了一個簡單的修改，將cipher[]值通過串列埠列印出來，那我們就將程式通過NXP-MCUBootUtility下載到Flash裡由ROM來啟動執行吧（退出除錯狀態），我們再來看串列埠列印，哈哈，終於值變了，這意味著DCP終於拿到了正確的SNVS Master Key(非0)。
總結一下，SNVS Master Key僅在晶片Hab狀態是Close並且非除錯狀態下才能被DCP正常獲取，否則DCP獲取到的是全0的假Key。
至此，i.MXRT系列中資料協處理器DCP使用SNVS Master Key加解密的注意事項痞子衡便介紹完畢了，掌聲在哪裡~~~
歡迎訂閱
文章會同時釋出到我的 部落格園主頁、CSDN主頁、知乎主頁、微信公眾號 平臺上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
