汽车网络安全方案产品交付形态的思考

lixinfu

目录
1.问题引入

2.产品包需求

2.1 密码服务

2.2 密钥管理

2.3 证书管理

2.4 随机数生成

2.5 安全启动

2.6 安全更新

2.7 安全核间通信

3.产品形态方案分析

3.1 黑盒方案

3.2 白盒方案

4.小结

   
为什么要突然提出这个问题？那肯定是工作中遇到了呀，绝知此事要躬行，所以想记录一下思考过程，同时与各位同行一同探讨。今天的文章有点长，但请大家耐心看完，提出宝贵意见。谢谢各位！！

01

—
问题引入在之前基于AUTOSAR架构的产品交付上面，通常是芯片厂或者EB这类公司提供MCAL，基础软件供应商例如Vector、普华、东软这种提供BSW基础demo\BSW客制产品，然后OEM、零部件供应做应用层和集成工作，这中间产品发布的流程、产品是黑盒还是白、产品的保密程度其实大伙儿也心知肚明。但现在智能网联汽车的盛行，车载网络安全也日渐凸显，从前的产品交付形态也面临着比较多的信息安全风险，其次网络安全这个新领域，谁先抢到制高点，说不定会重塑供应链体系格局，所以从最上游的芯片厂开始都有了自己的小九九。比如说某国产芯片厂，买芯片送全套AUTOSAR BSW+信息安全+功能安全方案；NXP以bin文件形式释放信息安全包；英飞凌子公司Hitex也提供信息安全+功能安全方案，黑盒还是白盒方式不详。基础软件供应商也不甘落后，ETAS黑盒交付，大抵是博世给的勇气？Vector白盒交付可以学到很多，但得加钱；国产基础软件，很难评。那么到底这个网络安全包有什么魔力？我们首先从产品包的基础需求开始。
02
—

产品包需求首先说下我总结的产品包需求，是一个比较宽泛的概念需求，并仅针对底盘、动力控制类的MCU提出的，毕竟我司目前搞的就是这个方向的芯片，具体如下：

2.1 密码服务

（1）产品包应提供以下密码服务接口，以适配应用程序的不同场景：

不同工作模式的对称密码服务： AES-ECB/CBC/CTR/OFB/XTS/CBC-MAC/ CMAC/CCM/GCM SM4-ECB/CBC/CTR/OFB/XTS/CBC-MAC/CMAC/CCM/GCM

非对称密码服务： 非对称加解密 -- RSAES\SM2PKE 数字签名和认证 -- RSASSA\ECDSA\DSA\ SM2DSA 密钥交换 -- DH\ECDH\SM2KEP

摘要算法服务： Digest SHA1/224/256/384/512\SM3\MD5 HMAC-SHA1/224/256/384/512/SM3/MD5

（2）密码服务均需以特定的标识符来分辨算法及算法工作模式，示例如下：

Algorithm Family	Value	Description
CRYPTO_ALGOFAM_AES	0x01	AES cipher
Algorithm Mode	Value	Description
CRYPTO_ALGOMODE_ECB	0x01	Block Mode: Cipher Block Chaining

（3）对称、非对称及摘要密码服务需根据加密驱动硬件实例设计加密驱动抽象以适配不同算法的并行调用，示例如下：



（4）相同算法使用同一加密驱动硬件实例需根据优先级进行分配，高优先级密码任务可以打断当前正在处理的低优先级密码任务，示例如下：



（5）针对特定密码服务，如下

HASH

MAC_Generate\Verify

Encrypt\Decrypt

AEAD_Encrypt\Decrypt

SIGNATURE_Generate\Verify

        需根据以下状态机进行操作，每种状态均需支持独立API以复用：

操作状态	描述	备注
Start	开始处理一个新的密码操作请求	需清空引擎中的会话上下文
Update	分块密码操作需要输入，由该状态来添加中间数据
Finish	分块操作的最后一步，需要数据填充；该状态返回最终密码操作结果

（6）上述所有服务的属性，如调度优先级、处理模式(Asyn/Syn)及Asyn对应回调、所用算法类型、所有算法密钥索引、硬件加速驱动对象均需静态配置。

2.2 密钥管理

（1）密钥生成

为减小密钥泄露的风险，需提供在安全系统进行密钥生成的功能；
该方式可作为密钥注入的备选方案，例如密钥注入时量产环境不可信，或者设备已部署使用。

（2）密钥派生
为减小在用密钥泄露的风险，需提供在安全系统进行密钥派生的功能；通过密钥索引的方式在安全系统内部获取待派生密钥元素，并根据静态配置(派生密钥、盐值、派生算法以及派生自定义签)和随机数作为参数，进行密钥派生；派生的密钥需与用户指定的密钥索引对应。

（3）密钥导入及更新
除密钥生成的方式外，需支持在可信环境下导入密钥、更新密钥的功能。

（4）密钥复制
需提供密钥复制功能。根据用户配置，把密钥及其所有(或部分)元素复制到同一加密驱动程序中的另一个密钥中。

（5）密钥导出
为支持工程开发，需提供密钥导出功能。在整车量产阶段前，密钥只能以受保护的(例如，加密和认证)格式导出；一旦量产后，该功能自动失效。

2.3 证书管理

To Do

2.4 随机数生成

为实现数字签名或者密钥生成，需提供随机数生成的功能。为提高随机数生成速度和防止伪随机数产生相同值，可采用真随机数作为拓展熵源，生成种子给伪随机数模块使用，然后进行熵池的迭代。如下：

2.5 安全启动

在兼顾启动速度、身份认证和完整性的情况下，可提供如下三种启动方式：顺序启动、并行启动、混合启动。

2.6 安全更新

安全更新分为两类：

Host侧的应用代码、数据更新

        Host侧的应用代码更新，通常也叫作安全更新；

        该需求仅针对现有基于UDS的Slave ECU的安全更新，其更新流程示例如下：

HSM侧的应用代码、数据自更新

由于功能或者配置的迭代，HSM侧的应用代码或者数据也有自更新的需求。该需求需指定信任锚点和信任根。

2.7 安全核间通信

        为了Host与HSM的安全核间通信需支持以下功能：

版本标识信息交互

Host和HSM的内部状态交互

Host和HSM的中断交互处理

Host和HSM的信号量机制操作

Secure Flash更新的握手控制

Host和HSM的请求、响应交互

03

—

产品形态方案分析
有了上述产品需求之后，我们要悸蔷褪墙桓斗绞搅恕Ｎ掖有酒?А⒐┯ι獭⒅斩擞没Ъ父龇较蚪?蟹治觥Ｓ腥缦铝街郑�

3.1 黑盒方案

产品形态为HSM侧工程为黑盒，Host侧工程为白盒，对标ETAS网络安全解决方案，如下：

实现方案： 提供详细的接口说明 提供HSM侧工程加密bin文件和Host侧工程源码 提供授信的工程包发布平台 提供信息安全解决方案集成服务

优点： HSM内部高度保密 用户使用简单，仅需根据产品手册调用API即可

缺点： 需与每个客户对接HSM产品应用需求，满足客户定制化 需提供HSM自更新成套解决方案，满足客户定制化

实现难点 缺乏有车规信息安全解决方案量产经验的人员 需一直参与客户产品的生命周期管理，即需求变更引发的工程更新、缺陷引发的工程更新

方案面向对象： 主机厂 零部件供应商

3.2 白盒方案

产品形态为HSM侧工程和Host侧工程为白盒，对标Vector网络安全解决方案，如下：

实现方案： 提供详细的配置和接口说明 提供HSM侧工程源码和Host侧工程源码 提供可视化界面完成工程配置 提供信息安全解决方案培训

优点： 对芯片厂来说，信任锚点和信息安全风险转移 对芯片厂来说，如面向基础软件供应商，仅需提供MCAL层；如面向OEM或者零部件供应商，需提供整个Crypto Stack，方案灵活 对用户来说，方案透明，更易于发现产品信息安全漏洞 用户可快速响应需求变更

缺点： 存在方案泄露的风险 需重新定义信任根，可能与零信任模型概念冲突 需提供工程配置服务（面向OEM或者零部件供应商）

实现难点 缺乏有车规信息安全解决方案量产经验的人员 需提供工程配置工具

方案面向对象： 具备自研能力的主机厂\零部件供应商 基础软件供应商，如Vector\普华\东软睿驰等

04

—

小结
我能想到的产品形态优缺点如上，其实如果是真有本事的原厂，在信息安全方案上直接一条龙服务，那真是香，双方都省成本，但是专业的事情还得专业的人做。芯片厂的代码在行内人眼中应该就是个玩具，所以给了ETAS\Vector、国产基础软件等供应商各种机会。不知道，各位对产品交付形态看法怎么样？