YTM32的HSM模块在信息安全场景中的应用

文章目录

YTM32的HSM模块在信息安全场景中的应用
- 引言
- 应用场景：一点点密码学基础
- 硬件：YTM32的信息安全子系统
- - HCU外设模块
  - - 硬件特性
    - 基本的应用操作流程，以计算AES-ECB为例
    - 硬件上对处理多块数据上的一些设计细节
    - - 处理多块消息 for AES / SHA
      - 存储上下文数据，使用CR[CS]寄存器
      - 操作流步骤
    - 存放密钥Key
    - 关于FIFO
- 软件资源
- Performance
- 小节

引言

随着汽车上通信系统越来越复杂，云端、远程通信的场景越来越多，信息安全变得越来越重要，在通信领域常用的AES、SHA、RSA等加密算法被越来越多地应用到汽车电子系统中。通常这类加解密算法都需要大量的数学运算，需要消耗相当多的CPU时间，但同时汽车应用场景对ECU有比较高的实时性要求，为了节省主CPU的资源，专用于执行加解密算法的硬件HSM模块应运而生。

广义上的HSM（Hardware Security Module），是MCU上专门用于实现加解密算法的外设模块，它一般会有一个独立的CPU，专门用来进行加解密运算，还有一些针对特定算法的硬件加速器（如AES-128、SHA-256等）。有了HSM模块，程序中就可以把加解密运算交给HSM来执行，同时主CPU就可以去做其他工作，一段时间后来查询结果，或等待HSM计算完成后通过中断等方式通知主CPU计算结果即可。HSM通常还拥有单独的存储区，包括RAM和NVM（Flash存储器），HSM的存储区在正常运行状态下应只允许HSM读写，主CPU不能读写。这样就可以把算法秘钥等重要数据存储在HSM存储区，与主CPU进行隔离，进一步加强安全性。此外HSM模块还会集成（或者共存）真随机数生成器等加密算法常用外设。

应用场景：一点点密码学基础

常用的加密方法，比较耳熟能详的是摘要算法（哈希算法，HASH）、对称加密、非对称加密等。

摘要算法是不可逆的，主要作用是对信息的完整性和一致性进行校验。
对称加密算法是可逆的，主要作用是保证私密信息不被泄露。不同于摘要算法（HASH），是真正意义上的加密算法。
相对于对称加密在加解密过程中使用同一个密钥，非对称加密在加密和解密过程中使用的密钥也是不同的（公钥和私钥）。

假设有发送方向接收方发送消息。如果没有任何加密算法，接收方发送的是一条明文消息：我是小灰。
在这里插入图片描述

如果中间人截获到消息，即使中间人无法篡改消息，也可以窥探到消息的内容，从而暴露了通信双方的私密。

因此，我们不再直接传送明文，而改用对称加密的方式传输密文，画风就变成了下面这样：

在这里插入图片描述
具体工作的步骤如下：

发送方利用密钥123456，加密明文我是小灰，加密结果为TNYRvx+SNjZwEK+ZXFEcDw==。
发送方把加密后的内容TNYRvx+SNjZwEK+ZXFEcDw==传输给接收方。
接收方收到密文TNYRvx+SNjZwEK+ZXFEcDw==，利用密钥123456还原为明文我是小灰。（使用相同密钥的对称加密方法）

硬件：YTM32的信息安全子系统

HCU外设模块

YTM32的HCU（Hardware Cryptography Unit）是HSM的一种典型实现，使用硬件计算引擎，可以实现对用户数据的加解密计算，其中包括AES、SM4、SHA等算法，并配合真随机数发生器TRNG和HCU_NVR存储区，完成了对加解密系统的硬件支持。如图x所示。

在这里插入图片描述

图x YTM32的HCU外设系统框图

从HCU外设的系统框图中可以看到，HCU的核心是一个复用成多种模式的计算引擎，用户可以通过FIFO向计算引擎送数参与计算，并在计算结束后，通过FIFO读出计算结果。HCU的用户操作接口（寄存器）并不复杂，主要的配置选项都在选择计算引擎的工作模式上（HCU_CR寄存器），DMA和中断，以及标志位的设置，都是面向FIFO的常规功能。

需要特别关注的是，HCU外设模块从Flash（EFM模块）存储器中导入Key到HCU_KEY寄存器的机制，以及众多面向具体加解密算法，需要通过专用的寄存器传入专用的参数，例如通过HCU_MSGINFO寄存器和HCU_MSGADL寄存器指定输入数据（“消息”，Message）的长度，通过HCU_ASECV寄存器为计算ASE-CTR算法时传入Counter参数，通过HCU_ASEIV寄存器为计算ASE-CBC算法时传入Initial Vector参数，通过HCU_ASEMAC寄存器为计算ASE-CMAC算法时传入或传出MAC值。

硬件特性

支持使用128-bit、192-bit、256-bit等不同长度的密钥。
可以实现加密和解密运算。
可以使用安全的硬件密钥（存放在以Flash为存储介质的HCU_NVR）和灵活的软件密钥（可软件写入HCU_KEY寄存器）。
实现了多种硬件加密算法的计算引擎
- AES （ECB, CBC, CTR, CCM, CMAC ）
- SM4 （ECB）
- SHA （SHA-256, SHA-384）
以大端方式保存输入数据和输出数据，但支持按位、按字节和按16位字逆序。
使用输入FIFO和输出FIFO缓存数据，最大缓存深度可达128 Byte。
支持DMA和中断，可以从MCU的内存空间中取数和送数。

基本的应用操作流程，以计算AES-ECB为例

使用HCU计算引擎的流程大体相似：先准备密钥Key、配置引擎，到准备数据、执行计算，最后等待计算完成读取计算结果。这里以AES-ECB为例，具体说明使用HCU计算引擎的操作过程：

导入计算过程的密钥，可以使用预先烧录至Flash存储区的HCU_NVR，也可以人工向HCU_KEY寄存器中写数。
配置计算引擎，设置HCU_CR[ENGSEL]=1, HCU_CR[ALGSEL]=0，指定即将以AES-ECB模式进行计算。
指定实际使用密钥的长度，设置HCU_CR[KEYLEN]，例如，可指定长度为128。
向HCU的数据FIFO中写入即将要参与计算的数据，向HCU_IFDAT寄存器中写数。
指定即将要参与计算的数据长度，向HCU_MSGADL[MSGLEN]寄存器中写数。
[可选的步骤] 根据不同计算模式的需要，需要额外写入计算参数：
- 对于AES-CBC计算，需要在这个阶段写入HCU_IV寄存器。
- 对于AES-CTR计算，需要在这个阶段写入HCU_CTR寄存器。
指定即将要进行的是加密计算还是解密计算，设置HCU_CR[ENC]寄存器。
启动计算，设置HCU_GO[GO]=1。
等待计算完成。
当硬件计算完成后，将有标志位HCU_SR[OD]=1。
从HCU的数据FIFO中读出计算的结果，从HCU_OFDAT寄存器中读数。

其他计算模式的过程大体相同，在软件应用上，可以直接调用SDK软件包中的API，或者阅读参考手册对照具体的操作。

硬件上对处理多块数据上的一些设计细节

处理多块消息 for AES / SHA

一般应用中，AES / SHA计算引擎处理一个消息块的长度小于 32768 / 65536 字节，对应在HCU外设的寄存器字段HCU_CR[MSGLEN]中配置。但当用户需要处理（加密或解密）长度大于 32768 / 65536 字节的消息块，就需要使用处理多块消息的机制：需要指定寄存器HCU_CR[MSGB]和HCU_CR[MSGE]，表示即将要进行处理的数据块是开始块（Begin Message）、中间块（Middle Message）或是结束块（End Message），并且需要配置HCU_CR[CS]=1指定即将处理完成数据块后，需要为下次计算保留种子（在AES-CBC和AES-CTR两种计算模式下，除了Key之外，还需要配合IV和CTR值才能启动数据块的计算）。

存储上下文数据，使用CR[CS]寄存器

大部分计算过程，都是对于一段不长的数据进行计算，经过一次计算就可以得到最终的结果。

但对于AES-CBC和AES-CTR这两种计算过程，可能会计算一组比较长的数据。在开始计算数据前，还需要预先设定IV寄存器（Initial Vector）和CTR寄存器参与计算。当设置HCU_CR[CS]=1，处理完数据块后，产生的IV和CTR值将被载入到硬件的HCU_IV寄存器和HCU_CTR寄存器，供下一个数据块的处理过程使用，并以此类推。

操作流步骤

通过HCU_MSGINFO和HCU_MSGADL分别指定完整数据块的长度和每次参与计算的数据子块的长度。设置HCU_CR[CS]=1，启用保存计算上下文。设置[HCU_CR[MSGB]:HCU_CR[MSGE]]的值为0b10、0b00、0b01，指定即将处理最开始的子数据块、若干个中间子数据块和最后一个字数据块。

配置准备开始执行分多块的计算：

配置HCU_MSGINFO寄存器，设定真个长消息的数据长度（如果是AES-CCM，则不包含额外的数据长度）。
设置HCU_CR[CS]=1，启用保存计算上下文。

配置计算第一个数据块：

设置HCU_CR[MSGB]=1, HCU_CR[MSGE]=0，指定即将处理长消息的第一个子数据块。
设置HCU_MSGADL[MSGLEN]，指定即将处理的一个子数据块的长度。
配置执行加解密引擎。
设置HCU_GO[GO]=1，启动计算引擎。等待计算完成。
当硬件计算完成后，将有标志位HCU_SR[OD]=1。

配置计算中间的数据块：

设置HCU_CR[MSGB]=0, HCU_CR[MSGE]=0，指定即将处理长消息的中间子数据块。
其余操作同上述计算过程相同。

配置计算最后的数据块：

设置HCU_CR[MSGB]=0, HCU_CR[MSGE]=1，指定即将处理长消息的中间子数据块。
其余操作同上述计算过程相同。

注意：

分多块计算的功能仅适用于AES（CCM / CMAC）和 SHA 引擎。
设置各分块的大小，在计算SHA-256时，应为64字节的倍数，在计算SHA-384时，应为128字节的倍数。

存放密钥Key

根据手册中存储空间（Memory Map）和EFM模块（Embedded Flash Module）章节中的介绍，YTM32微控制器片内的Flash中，还划分了一块区域HCU_NVR，专门用于存放同HCU相关的密钥数据。如图x所示。

在这里插入图片描述

图x YTM32B1ME微控制器的存储映射

HCU_NVR中可以存放32组 AES-256的Key。用户可通过配置EFM_CTRL[AES_KEY_SEL]寄存器，指定AES-256的Key序号，然后在EFM_CMD寄存器中写入Load AES Key命令，如图x所示，就可以将对应的Key从Flash中的HCU_NVR载入到HCU_KEY寄存器中，参与AES算法的计算。这就是使用硬件密钥的方法。

在这里插入图片描述

图x EFM中的CMD寄存器可以识别的命令

当然，在调试阶段，或者需要使用灵活密钥的情况下，用户软件也可以不使用预先存放在硬件Flash中的密钥，而直接向HCU_KEY寄存器中写入Key值参与计算。

出于安全的考虑，用户软件（通过CPU）不能直接读取HCU_NVR存储区和HCU_KEY寄存器中的数据。用户可以通过写Flash的方式（带有KEY）向HCU_NVR中写数，但除了最初写数的人，别人是无法再读出正确的数。

关于FIFO

Input FIFO入口寄存器的位宽是32b，但手册上明确说明，要求每次向FIFO中写数必须为128b，这也就意味着对Input FIFO的操作，每次都要加倍再加倍，连续4次写入才算完成一次操作。

在这里插入图片描述

图x Input FIFO每次必须以128b写入

Input FIFO可以通过Watermark触发中断，但Watermark的值是以字（1 Word）为单位的，这也就意味着Watermark的实际设定值必须是4的倍数（4个Word对应128b）。

至于Input FIFO Watermark的中断，这里有一个逻辑。在Operation Done事件到来之前，Input FIFO Watermark的事件都是按需触发的，即只要当前FIFO中的数据量（Word数量）小于Watermark的设定值，就可以触发对应的中断。但若Operation Done事件到来，此时Input FIFO的检测逻辑就停了，哪怕Input FIFO中的数据已经耗尽，库存低于Watermark值，（刚消耗掉最后一组128b数据后），也不会再产生Input FIFO Watermark的中断。因此在YTMicro SDK的样例代码中，停用Input FIFO Watermark中断的操作并不是等着一个空的Input FIFO触发，而是同Operation Done事件放在一起停用的。

void HCU_IRQHandler(void)
{
    /* Operate done handler */
    if ((HCU_GetStatusFlag(OPERATION_DONE_FLAG)) && (HCU_GetIntMode(OPERATION_DONE_FLAG)))
    {
        /* clear flags. */
        HCU_ClearStatusFlag(OPERATION_DONE_FLAG); /* Clear operate done flag */

		/* disable interrupts. */
        HCU_SetIntMode(OPERATION_DONE_FLAG, false);
        HCU_SetIntMode(INPUT_FIFO_WATERMARK_FLAG, false);  /* Disable input watermark interrupt */
        ...
}

软件资源

YTMicro SDK中，提供了HCU外设模块的驱动程序，以及一个基本的样例工程hcu_ecb。

从笔者的经验看来，目前设计这个样例工程更多是为验证HCU驱动代码，并简单演示HCU模块的应用流程。从用户角度看，如果需要更充分有效地利用好HCU外设，原厂的开发团队应该在后续会设计和发布专门的功能安全软件组件，将这些硬件细节隐藏在将来会逐渐统一的通用HSM软件接口之下（例如集成到AutoSAR软件体系中），因为HSM的开发者大多是算法专家，相对于某个具体的外设模块的实现，他们更多关注的是软件的应用场景，以及实际计算的速率。

所以，这里还是期待原厂的软件开发团队继续为开发者带来一些惊喜。