第二章 硬件架构:HSM内核架构与密码加速器

各位同学,今天我们来聊聊英飞凌HSM的硬件底子。说白了,就是看看这颗安全芯片到底长什么样,里面都塞了些什么东西。

我刚开始接触HSM时,总觉得它就是个黑盒子——把密钥扔进去,它就能帮你做加解密。直到有一次项目里遇到性能瓶颈,我才被迫打开这个黑盒子,仔细研究它的内部结构。嗯,从那以后,我养成了一个习惯:做安全方案之前,先把硬件架构吃透。

2.1 HSM内核架构:双核还是单核?

英飞凌的HSM方案,目前主流的有两种内核选择:ARM Cortex-M系列和RISC-V。我个人更习惯把Cortex-M叫“老伙计”,毕竟在车规级芯片里它已经摸爬滚打十几年了。

核心要点:HSM内部通常是一个独立的微控制器,与主核(比如AURIX的TriCore)完全隔离。它有自己的CPU、RAM、ROM和密码加速器,主核根本访问不到HSM的内部存储。

为什么会这样设计?你想想看,如果攻击者攻破了主核,他就能直接读到密钥,那HSM还有什么意义?所以硬件上必须做到“物理隔离”。

特性 ARM Cortex-M RISC-V
生态成熟度 非常成熟,工具链完善 正在追赶,开源生态活跃
实时性 优秀,有NMI和优先级中断 取决于具体实现
安全扩展 TrustZone for ARMv8-M 物理隔离+自定义指令
我在项目中见过 TC3xx系列HSM 部分TRAVEO系列

我记得有一次做方案选型,客户非要问“RISC-V是不是比ARM更安全?”我的回答是:安全不取决于内核指令集,而取决于你如何隔离、如何管理密钥、如何设计访问控制。内核只是载体。

2.2 专用密码加速器:别让CPU干苦力

做加解密运算,尤其是非对称算法(RSA、ECC),如果全靠CPU硬算,那性能惨不忍睹。我见过一个项目,用纯软件做一次ECDSA签名,花了将近200毫秒——这在车控场景里根本没法用。

所以英飞凌在HSM里集成了专用密码加速器,也叫PKA(Public Key Accelerator)或Crypto Engine。它的作用很简单:把那些重复、计算密集的数学运算,从CPU手里接过来。

我的经验:密码加速器不是万能的。它只加速特定算法。比如有些HSM只支持RSA和ECC,不支持SM2/SM3/SM4。如果你要做国密方案,选型时一定要确认加速器是否支持国密算法。

加速器的工作流程大致如下:

  1. CPU把运算参数(密钥、数据、模式)写入加速器的寄存器
  2. 加速器独立完成运算,不占用CPU
  3. 运算完成后触发中断,CPU读取结果

这个过程中,CPU可以去做别的事。说白了就是“异步干活”,效率高很多。

注意:加速器运算期间,密钥材料不能离开HSM的安全边界。有些低端方案会把密钥传到外部RAM再运算——这是大忌。攻击者只要在总线上挂个逻辑分析仪,密钥就裸奔了。

2.3 安全存储单元:密钥的保险柜

密钥存在哪里?存在Flash里?存在RAM里?都不对。HSM内部有一个专门的安全存储单元,通常是一小块OTP(一次性可编程)存储器加上NVM(非易失性存储器)。

我习惯把安全存储单元比作“保险柜里的内层抽屉”。主核连保险柜都打不开,更别说抽屉了。

安全存储单元有几个关键特性:

  • 物理防篡改:如果检测到芯片被开盖、探针攻击,存储单元会自动擦除密钥
  • 访问权限控制:只有HSM固件才能读写,主核只能通过安全通道请求服务
  • 生命周期管理:密钥可以设置为“只可写入一次”或“只可导出一次”

我在一个项目里遇到过这样的坑:客户把HSM的密钥存储区当普通Flash用,频繁擦写。结果OTP区域提前耗尽,芯片直接报废。嗯,从那以后我每次做培训都要强调:安全存储单元不是普通存储,它的寿命和写入次数是严格受限的。

2.4 硬件架构总览:一张图说清楚

下面这张图是我自己画的HSM内部结构,你可以把它当作“寻宝图”来记。

英飞凌HSM硬件架构总览 主核 TriCore / ARM Cortex-R 运行应用软件 无法访问HSM内部 HSM安全边界(物理隔离) HSM内核 ARM Cortex-M / RISC-V 运行安全固件 密码加速器 (PKA) RSA / ECC / AES / SHA 国密SM2/SM3/SM4(可选) 安全存储单元 OTP + NVM 密钥、证书、安全配置 安全RAM 临时密钥、会话数据 掉电即失 安全通信接口 Mailbox / SPI / 共享内存(加密通道) 注意 主核与HSM之间 只能通过安全通道通信 不能直接读写HSM内部资源

这张图里,红色虚线框就是HSM的安全边界。所有敏感操作——密钥生成、签名、解密——都在这个框里完成。主核只能通过Mailbox或共享内存发请求,拿结果,但永远看不到中间数据。

2.5 硬件层面的安全启动流程

有了上面的硬件基础,安全启动就顺理成章了。我简单梳理一下硬件层面的启动流程:

  1. 上电复位:HSM内核先于主核启动
  2. 自检:HSM检查自己的固件完整性(用ROM里的BootROM做哈希校验)
  3. 密钥加载:从安全存储单元读取根密钥,加载到密码加速器
  4. 验证主核固件:HSM读取主核的Bootloader,用根密钥验证签名
  5. 释放主核:验证通过后,HSM释放主核复位信号,主核开始运行
  6. 持续监控:主核运行期间,HSM持续监控安全状态(电压、温度、频率)

关键点:整个启动过程中,主核是被动的。它不能决定自己能不能启动,而是由HSM说了算。这就是“硬件信任根”的含义——信任的起点在HSM里,不在主核里。

我记得第一次调通这个流程时,看到主核乖乖等着HSM“放行”,那种感觉就像你拿着钥匙开门,而钥匙在别人手里。嗯,安全就是这样——把控制权交给最可信的那个模块。

2.6 避坑指南:硬件设计中的常见问题

最后,分享几个我在项目中踩过的坑:

  • 时钟源选择:HSM和主核最好用独立的时钟源。共用时钟的话,攻击者可以通过时钟毛刺攻击绕过安全校验
  • 电源隔离:HSM的供电要独立稳压,不能和主核共用LDO。否则主核掉电时,HSM也可能跟着掉电,导致密钥丢失
  • 调试接口:量产时必须锁死HSM的JTAG/SWD接口。我见过一个客户忘了锁,结果被第三方轻松读出固件
  • 温度监控:HSM内部有温度传感器,检测到异常高温(可能是激光攻击)时,会自动擦除密钥

曾经有个血的教训:某项目为了省成本,把HSM和主核放在同一个电源域。结果一次电源波动,HSM的密钥存储区数据出错,导致整个批次的车载控制器无法启动。返修成本够买几百颗独立电源芯片了。

好了,硬件架构这部分就讲到这里。记住一句话:HSM的硬件设计,核心就是“隔离”二字——物理隔离、电气隔离、时钟隔离、存储隔离。把这四个隔离做好了,安全就成功了一半。