痞子衡嵌入式：SNVS Master Key僅在i.MXRT10xx Hab關閉時才能用於DCP加解密

i.MXRT不僅僅是處理性能超強的MCU，也是安全等級極高的MCU。如果大家用過痞子衡開發的一站式安全啟動工具 NXP-MCUBootUtility，應該會從其用戶手冊3.3節中瞭解到i.MXRT支持的幾種安全啟動等級，其中HAB加密啟動方式和BEE/OTFAD加密啟動方式中都提及了一種神秘的密鑰 ... ...

　　大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是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)。