汽车信息安全--车规MCU信息安全设计应采用哪种安全架构？

最新推荐文章于 2024-02-23 14:45:34 发布

king110108

最新推荐文章于 2024-02-23 14:45:34 发布

阅读量374

点赞数

分类专栏：信息安全(Cyber Security) 文章标签：汽车安全架构信息安全 HSM

原文链接：https://mp.weixin.qq.com/s?__biz=MzI0MTY1NjUxMg==&mid=2247485888&idx=1&sn=5280004dcdf8d1c09ea3cb6ab5e5bf4d&chksm=e9097e6fde7ef77903aee800e66a77c5bd06b6811c9c846caeb19521c73d998c8db71131d24e&scene=132&exptype=timeline_recommend_article_extendread_samebiz#w

版权

信息安全(Cyber Security) 专栏收录该内容

18 篇文章 105 订阅

订阅专栏

1.问题引入

不知道大家在设计车规ECU安全启动的时候有没有这个困惑，为什么我们配置的待校验对象基本是只有Host侧的代码数据段，如下图所示：

HSM Firmware中存放关于Host待校验程序段的启动信息，包括待校验对象首地址和长度、校验所使用的密钥、校验失败的惩罚措施以及签名信息等；

实际在MCU启动时通常是HSM核跑完Start.s后就直接开始运行固件代码，几乎没有校验HSM Firmware中的完整性和有效性。

这就意味着在OEM、供应商等眼里，MCU中的HSM相关的硬件、软件都是可信的，可以完全作为信任根来使用。

那在芯片原厂眼里，车规MCU内部的HSM到底是不是可信的呢？

2.常见网络安全架构简述

在聊HSM是否可信前，首先要明确的车规MCU内置HSM是采用哪种网络安全架构。

根据国家保密科技测评中心于今年6月7日发表的文章，它将当前国内外现有的网络安全模型架构主要分为4大类，分别为边界防御架构、纵深防御架构、零信任架构、可信计算架构。

2.1 边界防御架构

边界防御，即通过在网络边界处严密布防，鉴定内部网络或者内部资源的访问对象身份，常见的有防火墙技术、虚拟专用网技术、网闸等。如下图所示：

该架构可以控制外部网络对内部资源的访问，只有被授权合法的访问才能穿透网络边界，从而进一步提升内部网络信息安全。

2.2 纵深防御架构

纵深防御架构的基本思路是有点类似行军打仗，根据战事轻重缓急和地势特点，设置不同类型的防御范围，分别为一线、二线、三线，从而构成较为完备的战争防御纵深；网络信息安全同样也是类似的攻防战，因此该架构会根据不同网络安全防护措施的优点，尽可能地阻断攻击者的威胁。根据美国国防部提出的PDRR（Pro-tection,Detection,Reaction,Reco-very）模型，即防护、检测、响应、恢复4道防线，纵深防御架构通过在这些技术框架区域中实施保障机制，最大程度地降低风险，应对攻击并保护信息系统的安全。

2.3 零信任架构

传统的网络安全架构通常只注重边界防御保护，通过身份验证和完整性验证对授权用户开放访问权限，防御方式往往采用“一次验证、静态授权”，通过边界、纵深防御将攻击者挡在外部，在边界内部则畅通无阻；而零信任架构采用了“持续验证+动态授权”，强调不信任、始终验证，以身份作为访问控制的基础、持续对安全访问进行验证，同时对访问进行动态控制。

2020年NIST发布的《 800-207 Zero Trust Architecture》进一步展示了ZTA的逻辑架构，如下：

强调了当前零信任架构的三大技术：软件定义边界、身份识别与访问管理你、微隔离。

同样，根据华为IP知识百科，零信任架构的三大核心原则为：持续验证、动态授权和全局防御，如下图：

通过持续验证，零信任架构建立以身份为中心的访问控制机制，确保接入网络的用户等持续可信；通过动态授权，将访问目标权限细分为应用、功能、数据等颗粒度，实现精细动态控制；通过全局防御对终端、用户行为异常、流量威胁、应用鉴权等方面进行评估，创建完整的信任链，从而实现安全网络。

2.4 可信计算架构

根据2020年国标发布的《GB/T 38638-2020: 信息安全技术可信计算可信计算体系结构》描述，可信计算是指在计算同时进行安全防护，保证计算全程可控、不被干扰。

可信计算架构由可信计算节点和可信链接构成，为其所在网络环境提供相应等级的安全保障，如下：

可信计算节点由可信部件+计算部件，可信部件提供密码算法、平台身份可信、平台数据安全保护等可信计算功能调用的支撑，可信部件主要包括TCM(可信密码模块)或者TPM(可信平台模块)、可信平台控制模块（TPCM）、可信软件基和可信链接等。

计算部件和可信部件逻辑相互独立，形成具备计算和防护功能并存的双体系结构，如下：

以可信部件中的TPM为例，它存在的前提是有一个信任根，用于衡量系统的可信度。

可信计算组织TCG规范中的信任根由三部分组成

1.度量可信根(Root of Trust for Measurement, RTM)

2.存储可信根(Root of Trust for Storage, RTS)

3.报告可信根(Root of Trust for Report, RTR)

一个完整的TPM至少应具备四个功能：对称\非对称加密、安全存储、完整性检测、签名认证。如下图所示：

使用TPM的最大优势在于系统的安全启动、加密密钥的安全管理、敏感信息\隐私数据的安全管理。

3. 关于车规MCU信息安全架构的思考

那么我们在设计车规MCU的信息安全系统架构时，应该要从哪些地方入手？是否可以把上述几种架构有机结合？

在这之前，先要了解当前汽车运行环境会遭到哪些网络攻击。

随着智能网联的飞速发展，汽车本身不再是一个封闭的个体，其遭受网络攻击的可能性大大增加。常见的威胁如下：

1.简单的非侵入式攻击，例如近距离接触汽车，通过汽车的物理接口如OBD、IVI USB、ECU Debug、SPI、UART等进行；也可以通过物理条件例如温度、电压、时钟等故障注入进行攻击。

2.量子计算机提供的蛮力攻击威胁：利用量子计算机的超强算力能够轻松破解密钥、密码

3.中央集成式的汽车电子电气架构要求跨域高带宽通信数据必须真实有效，而这些跨域车内通信也是很容易被攻击的点；

如何建立优秀的网络信息安全防御措施？

这就不得不聊一聊目前被业内广泛接受的EVITA项目。

EVITA，全称E-safety vehicle intrusion protected applications，2008年10月31日成立，但是2011年12月1日之后官网就没有新的更新。

它本身是一个欧洲国家资助的项目，旨在为汽车车载网络设计一种架构原型，在这种架构中，安全相关组件免受篡改，敏感数据免受泄露。

该项目的核心需求很简单，有如下三个：

车内、车外通信的高实时性，例如支持SecOC和V2X

系统所有电子组件均需被保护，其系统脆弱性取决于最薄弱的防御环节

良好的经济性，需要根据汽车行业进行量身定制

基于上述需求，EVITA提出了硬件加密模块(Hardware Security Module)的三种变体：

EVITA Light HSM用于保护传感器、执行器和ECU之间的交互；

EVITA Medium HSM用于保护控制器和内部车辆网络通信

EVITA Full HSM用于保护车辆外部通信（V2X）

在该项目描述中，HSM作为信任根（Root of Trust），把信息安全相关的功能全部锚定在一个独立、受保护、授信的硬件环境中；通过HSM提供的信息安全功能能够有效防止软件篡改、数据泄露。

可以看出，EVITA推荐在ECU内部采用信息安全架构为：可信计算架构。

不仅如此，

2018年BOSCH发表《A TPM or hardware trust anker is required to securely store the key for signature generation》进一步指出使用TPM或者硬件可信锚点构建汽车控制器的信息安全防御纵深架构；

2019年英飞凌发表《Future requirements for automotive hardware security》将EVITA HSM和汽车信息安全控制器结合，详细描述了其架构的经济性和技术优点。

但是对于车规MCU来说，要想实现信息安全架构，从硬件层面上还是需要以EVITA HSM为主，构建可信计算平台，把HSM作为信任锚点，将信息安全相关功能例如对称\非对称加解密、安全存储、安全调试、安全启动固化在HSM内部；防御纵深架构和边界防御架构为辅助，实现多方面的安全保护措施以及身份验证措施。

整体而言，其功能架构划分为下图所示：

那么零信任模型架构能不能用在车规MCU设计里呢？这个难以把控。

我们来做这样一个思考：假设仅有HSM BootRom作为信任根，从系统上电开始，所有程序段、数据段均需要做机密性、完整性和可用性的认证，首先在启动时间上就有很大不确定性；其次，在安全启动构建信任链的过程中，HSM BootRom作为芯片厂已经掩膜固化好的程序段，对于HSM Firmware、User Bootloader和User App的校验，应该是如下流程：

这里就出现了一个难点？HSM BootRom在开发阶段是如何知晓要校验HSM Firmware的相关信息（首地址、代码长度、对称\非对称、密钥、校验失败惩罚措施）。

一般来讲，HSM Firmware不由芯片厂独立开发，因为本身这块内容属于软件开发范畴，不是芯片厂强项，所以即使像英飞凌这样的厂家，在HSM这块的软件开发仅仅提供了BootRom，并且在这个阶段只是做了它内部AES密钥的身份、完整性验证，至于后续的信息安全功能（HSM Firmware）则由其下设软件子公司Hitex进一步研发，同时芯片厂的信息安全战略合作伙伴（ETAS、Vector、EB、云驰未来、伊世智能）签署NDA后也会做相应的配套方案。

如果想要支撑零信任模型，那么在芯片开发阶段至少必须规定HSM Firmware某个关键程序段必须是由HSM BootRom进行验证，意味着芯片厂要开始蚕食Tire 1\2的领域了，这个得看芯片厂自身实力，如果研发能力强、客户关系好、整个车规开发生态让用户感到舒服（突然想到了某途），那么OEM直接和芯片厂合作也不是不可能。

此外，采用零信任架构还需要持续验证和动态授权，意味着在车规MCU HSM内部需要将资源的颗粒度进一步细化，同时还需要一套高效的授权方式，在做系统需求分析时，这些需要进一步论证。

理想很丰满，现实很骨感，不知道那些莽撞切到车规MCU的国内芯片厂有没有认识到这个产业链的环环相扣。