本文讨论了智能网联汽车发展中车载网络安全的重要性，比较了芯片厂提供的黑盒和基础软件供应商如Vector的白盒产品包方案，涉及密码服务、密钥管理和产品形态选择，探讨了各自的优缺点和市场角色。
为什么要突然提出这个问题？那肯定是工作中遇到了呀，绝知此事要躬行，所以想记录一下思考过程，同时与各位同行一同探讨。今天的文章有点长，但请大家耐心看完，提出宝贵意见。谢谢各位！！
1 问题引入
在之前基于AUTOSAR架构的产品交付上面，通常是芯片厂或者EB这类公司提供MCAL，基础软件供应商例如Vector、普华、东软这种提供BSW基础demo\BSW客制产品，然后OEM、零部件供应做应用层和集成工作，这中间产品发布的流程、产品是黑盒还是白、产品的保密程度其实大伙儿也心知肚明。
但现在智能网联汽车的盛行，车载网络安全也日渐凸显，从前的产品交付形态也面临着比较多的信息安全风险，其次网络安全这个新领域，谁先抢到制高点，说不定会重塑供应链体系格局，所以从最上游的芯片厂开始都有了自己的小九九。
比如说某国产芯片厂，买芯片送全套AUTOSAR BSW+信息安全+功能安全方案；NXP以bin文件形式释放信息安全包；英飞凌子公司Hitex也提供信息安全+功能安全方案，黑盒还是白盒方式不详。
基础软件供应商也不甘落后，ETAS黑盒交付，大抵是博世给的勇气？Vector白盒交付可以学到很多，但得加钱；国产基础软件，很难评。
那么到底这个网络安全包有什么魔力？我们首先从产品包的基础需求开始。
2 产品包需求
首先说下我总结的产品包需求，是一个比较宽泛的概念需求，并仅针对底盘、动力控制类的MCU提出的，毕竟我司目前搞的就是这个方向的芯片，具体如下：
-
2.1 密码服务
（1）产品包应提供以下密码服务接口，以适配应用程序的不同场景：
|
|
|
（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的请求、响应交互
3 产品形态方案分析
有了上述产品需求之后，我们要考虑就是交付方式了。我从芯片厂、供应商、终端用户几个方向进行分析。有如下两种：
-
3.1 黑盒方案
产品形态为HSM侧工程为黑盒，Host侧工程为白盒，对标ETAS网络安全解决方案，如下：
| 实现方案：
|
| 优点：
|
| 缺点：
|
| 实现难点
|
| 方案面向对象：
|
-
3.2 白盒方案
产品形态为HSM侧工程和Host侧工程为白盒，对标Vector网络安全解决方案，如下：
| 实现方案：
|
| 优点：
|
| 缺点：
|
| 实现难点
|
| 方案面向对象：
|
4 小结
我能想到的产品形态优缺点如上，其实如果是真有本事的原厂，在信息安全方案上直接一条龙服务，那真是香，双方都省成本，但是专业的事情还得专业的人做。芯片厂的代码在行内人眼中应该就是个玩具，所以给了ETAS\Vector、国产基础软件等供应商各种机会。不知道，各位对产品交付形态看法怎么样？
扫一扫
8306
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
