大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是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加解密的注意事项痞子衡便介绍完毕了，掌声在哪里~~~