认真搞搞汽车MCU

（5）AUTOSAR中的Crypto Stack(五)-- HSM的多Host多会话机制分析。（4）AUTOSAR中的Crypto Stack(四)-- SecureBoot源码分析。（5）汽车网络安全--常见非对称算法概述。（6）汽车网络安全--常见摘要算法概述。（3）欧几里得算法、扩展欧几里得算法。RSA、ECC、ELGamal等留坑。（1）模运算、模逆元。

在之前文章中，我们提到了关于SHE密钥更新的流程。不过最近在做实际实现和规范的追溯关系时，发现了实际与理想还是存在不小差距，所以还是将流程再梳理梳理。

如果用户程序在量产后进行BugFix升级，那针对用户程序的MAC值就必须同步进行修改，因此讨论BOOT_MAC的更新也是非常有必要的

Information gathering capabilities：从在观活动收集观测主题的网络活动等；Logging Capabilities：记录与检测到事件的相关数据，该数据可用于确认警报的有效性；Detection Capabilities：检测事件的能力，常见手段有异常行为的阈值设定、黑白名单、警告设置等；Prevention Capabilities：针对入侵事件的预防、防范功能。

在车控类ECU中，我们通常把主控芯片MCU中的HSM以及HSM固件统一看做整个系统安全架构的信任根。所以大家默认在HSM内部存储的数据等都是可信的，例如CycurHSM方案中使用HSM硬件存储认证启动所需要的公钥，保证该公钥不被篡改；vHSM同理。但是，最近交流听说有工具可以将某芯片的所有Flash全部dump出来，首先我对这个保持怀疑，其次结合之前从实际调试来看，有部分OEM或者Tier1以明文形式将存储这些密钥信息（最多加个厂家自定义混淆算法）存储在HSM独占DFlash中。

MAC全称Message authentication code，是经过特定算法后产生的一小段数据信息，用于校验某数据的完整性和真实性。在数据传递过程中，可检查其内容是否被更改过，不管更改的原因是来自意外或是蓄意攻击。同时可以作为数据来源的身份验证，确认数据的来源。常见的MAC算法包括CMAC和HMAC。

SE这个东西其实大家经常用，那就是智能手机的使用。从外观形式上看，它是一颗独立的芯片，有内核，有Flash、Ram\ROM、加密引擎等等，用于敏感数据的存储或者是需要信息安全覆盖的APP运行，例如我们的手机银行、支付宝等等，此外，它还负责保证在其内部的代码、数据免受恶意软件攻击，具备硬件防篡改能力(物理拆解SE，芯片自毁)。由于它是一颗独立芯片，因此需要采用协议与外部通信，例如SPI、I2C。通常情况SE会嵌入到手机本身，或者eSIM卡，我们不关心也是自然。

如果我们把HSM当成黑盒子，只用它的相关功能就好了；但实际上从成本和场景出发，信息安全解决方案是需要客制化的；例如，某些控制件只需要支持SecOC和少量的密钥存储，那么SHE就完全可以满足要求，上HSM价格更贵且浪费了，这对成本敏感的OEM是不可接受的。所谓我们来看看目前MCU大厂的HSM方案，以U2A、S32K3、TC3xx为例。

黑客针对汽车ECU的网络攻击某种意义上讲是通过非授权方式访问到目标ECU内部资源，从而获取ECU内部数据、影响该ECU的运行状态、导致功能失效等。获取控制权限：例如车辆行驶过程劫持程序执行流程，影响该ECU的系统机密性、完整性等；获取、篡改程序和数据信息：例如改装车刷ECU提升动力、获取车主个人隐私信息、获取整车敏感数据等；拒绝服务：通过内存破坏使得目标ECU失去提供正常服务的能力，导致系统失效。因此，针对上述三类攻击目的，我们就可以定义出一个ECU到底需要保护哪些资产。

一入网络安全才发现深似海，传统汽车MCU码农转型之路异常艰难。在CP AUTOSAR中的CryptoDriver SWS对密钥格式的需求来源于RFC，其中要求了RSA、ECC、SHE等key material的格式。再往下看，我就有些迷糊了，例如关于RSA Private Key的OCTEE STRING格式根据IETF RFC8017，Public Key又得根据RFC5280，完全不得其解。所以今天先从生成密钥对，并对其进行解析开始，一步一步拆解。

我们简单描述了PEM格式，但是引出了ASN,1的问题，所以下片文章，我继续分析，并将pem格式解析出来什么是ASN.1?ASN.1定义了一种抽象的数据类型和其对应的表示方式，并提供了一种描述和交换结构化数据的通用方式，使得不同系统之间可以理解和交换数据。由于ASN.1 只是定义了数据结构，并未规定具体的编码方式，因此该语言要与编码规则一起完成数据的编码和解码。在密码学中，常见的有BER(Basic Encoding Rules)、DER(Distinguished Encoding Rules)；

最近在讨论汽车信息安全时听到一些新的概念：在车规MCU中HSM不能作为信任根。但回想起之前做ECU产品时，HSM又像个黑盒子；特别是在做安全启动时，基本只做Host侧程序数据的身份、完整性验证，这很明显是把HSM当作了信任根。有分歧就有讨论，偏信则暗，兼听则明；那么今天就来收集整理下信任根、信任锚等概念，理清思路；

在上文，我们讲解了信任锚和信任根，本文继续讲解汽车中关于硬件信任锚点的内容，最终回归到问题：HSM是否可以作为信任根？

当真正开始思考如何设计基于HSM的密钥管理系统，才发现基于之前vHSM的套路是相当不完备的。仅仅是依靠AUTOSAR KeyM和CSM提出的密钥管理要点作为需求，总觉得是无根之水，不够踏实。因此我打算从密钥的实际使用场景、HSM中如何保护密钥两个方面入手，保证系统方案的溯源。

个人理解，密钥管理是必须考虑到一个密钥的全生命周期，即该密钥从产生、分发、部署、使用最后到销毁的整个过程，而在汽车行业，密钥管理又是和ECU产品开发、产线量产、汽车运行、报废等过程息息相关，这是芯片厂在做密钥管理系统方案的难度之一；在产线生产阶段，密钥的角色就变化了，有不需要修改固化到OTP里，有需要使用一段时间就更新的，因此需要设定一套方案来实现密钥的加密固化、密钥的存储。HSM提供密钥生成的功能，那么用于生成密钥的种子的安全性就显得尤为重要，使用有可预见概率的随机数生成器肯定是不够安全。

在产品量产后，如果Debug口不禁用，一旦攻击者通过debug连接到ECU，那么很有可能对ECU进行注入恶意代码攻击、套取密钥、逆向工程等，从而对OEM、Tier1造成巨大损失。因此，我们可以对调试接口新增一种状态：Locked。但是这又有一个问题，当在售后阶段车上的某个件如果出现了偶发问题，需要回家复现或者调试，这个时候Debug口已经禁用了，这就很容易抓瞎？在整车产品中，芯片的生命周期是严格与整车绑定到一起，大致可分为：芯片出厂阶段、Tier-1开发阶段、OEM量产阶段、售后阶段和报废阶段。

这种方式也存在密钥泄露的风险，所以通常基于信息安全等级的不同要求，可以适当使用密钥派生机制，通过芯片特定ID或者Trim数据作为派生的输入；最明显的就是密钥的管理，什么情况下密钥不变、什么情况下密钥得保存，密钥更新后如何保证其新鲜度值，这不仅仅是芯片厂需要考虑的，还需要Tier 1、OEM共同讨论，才能得出一个较为成熟的方案。本文主要从信息安全角度对调试这一重大功能做了分析，针对售后阶段的bug分析作了信息安全方面的妥协，提出了常见的临时解锁debug口的手段。这是大变革，也是大机遇。

这个来自家里人的灵魂拷问直接把我问懵了，我只能片面地以个人粗浅理解回答：为了防止黑客攻击。再往下深入聊，我突然发现我没有能力以通俗易懂的比喻来解释。为此，我将自己对这个问题的思考过程记录下来，方便未来的我回溯。对于这个宏大的命题，我从如下几个方向来进行解读。

书接上文《

本章内容讲述了S32K Host和Hse之间的通信机制，就原理来看，更像是TC3xx HSM、RH850 ICU中HT2HSM、HSM2HT的升级版本。这也给我们在做这方面的软硬件设计时提供了新的思路，如何结合这几家的优点来设计出一套安全可信的通信单元，是接下来要着重考虑的事情。

本章内容讲述了S32K Host和Hse之间的通信机制，就原理来看，更像是TC3xx HSM、RH850 ICU中HT2HSM、HSM2HT的升级版本。这也给我们在做这方面的软硬件设计时提供了新的思路，如何结合这几家的优点来设计出一套安全可信的通信单元，是接下来要着重考虑的事情。

AUTOSAR R23-11发布有一段时间了，不知大家有没有浅尝一下。据发布会介绍，这次版本主要面向下一代E\E架构新增了Safety、Security的特性，因此为了跟上节奏，现将最新CP AUTOSAR关于security机制进行汇总。

在上一篇文章，我们简述了CP autosar的信息安全相关模块和secoc通信，本节我们主要聊关于R22-R23提出来的新的机制。

最近在和朋友们交流汽车网络安全趋势时，讨论最多的是供应商如何向OEM证明其网络安全能力。这是很重要的一环，因为随着汽车网络安全相关强制标准的执行，越来越多OEM是需要通过相关认证的。例如出海欧盟和日本市场的相关车型需要通过R155认证，其中最关键就是网络安全管理体系(CSMS)认证，只有在获得CSMS认证的前提下，才能申请车辆型式准入(VTA)。在R155 7.2.2.4中明确提到OEM需要证明其网络安全管理体系(CSMS)如何管理供应商和OEM之间的网络安全活动的互动、依赖和权责关系。

随着智能网联汽车的盛行，汽车内部遭受黑客攻击的可能性与日俱增。为了防范和缓解网络攻击，硬件信任锚（Hardware Trust Anchors）越来越多的被用到汽车控制器领域；所谓HTA，就是提供了一种基于硬件安全机制的隔离环境，可以有效保护安全敏感数据、为应用控制算法提供各种密码服务。大家最为熟悉的HTA就是HSM。英飞凌：Aurix HSM / SHE+瑞萨：Intelligent Cryptographic Unit（ICU）飞思卡尔称呼)

上一篇我们讲解了HTA基本概念，SHE和EVITA HSM区别以及SHE的架构，接下来我们聊一聊SHE中的密钥管理策略。

在当前车规MCU的规格制定中，除了要满足ISO26262，ISO21434也要在考虑之中。因此，目前中高端车规MCU普遍都会设计硬件安全模块（HSM），该模块可以用于密码计算的硬件加速、敏感数据和密钥的存储。基本上在车规MCU中，密钥都是存放在HSM中。安全启动：非对称和对称密码体制均可使用，但考虑启动速度，对称密码体制使用较多；在HSM标识一般称之为Boot_Key;安全通信：在车内ECU通信，为满足实时性，通常采用对称密码体制，称之为SecOC_Key；

我在前篇文章里详细记录了车规MCU信息安全设计过程关于网络安全架构的思考过程，从芯片原厂、供应商、OEM等角度思考如何建立起完备的信任链；不过这思考过程仅仅只是一家之言，因此我又对比了国内外芯片厂、OEM等对于安全启动的方案设计，并进行总结。首先回顾一下安全启动的定义：安全启动是在系统启动过程中，验证程序或数据的签名，确保程序数据的完整和可信，以防止在启动过程中加载并运行了未经授权的程序。在安全启动机制下，所有启动文件（如：启动引导程序、内核镜像、固件）均需先通过签名校验才被允许加载运行。

我们描述了芯驰E3的安全启动机制，接下来我们继续看其他芯片、OEM等安全启动机制。

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

Security系统是集成电路(即微控制器或SoC)中的专用子系统。在汽车市场中，它们通常被称为安全硬件扩展(SHE)模块或硬件安全模块(HSM)。

常见的算法有SM3、SHA256等等，值得一提是，早年间常见的MD5、SHA1已被攻破。基于之前的开发经验，车内配置HSM的控制器主要包含T-Box、座舱域、智驾域以及网关，动力控制较少，特别是制动和转向涉及较少，第一底盘控制非常关键且需要快速响应，目前来看安全芯片性能有所欠缺，第二也是最关键的一点，主机厂或者供应商对于底盘控制类的迭代非常谨慎。安全芯片的主要作用是为整个系统建立起一个可信的环境，主要通过安全启动、可信启动、加密启动等组合，再结合通信、存储相关的功能要求，共同完成一个可信系统的建立。

能够建立明确的网络安全组织架构，划分权责关系；能够鉴别车辆型式的风险；能够评估、分类和处理已鉴别的风险；能够验证已识别的风险已被妥善管理；能够测试某个车辆型式的网络安全；能够保证风险评估始终更新；能够对车辆型式的网络安全威胁和攻击进行监管、检测和阻止；能够提供相关数据以支持对企图或成功的网络攻击的分析。

对于汽车安全，业内人员通常聊得最多的就是汽车功能安全，多数基于ISO26262为基础，旨在开发设计阶段通过各项措施来减少因汽车电气电子系统故障而导致的各种不可控风险。

借标准附录里H中展示的车灯系统为例，来看看解析下危害分析方法论。

书接上文，我们正式开始对车灯系统的TARA分析，首先回顾下整车关于车灯系统描述：可以比较肯定的是，我们定义的item为车灯系统，因此可以看到上图中画出了item boundary；同时定义出运行环境，个人理解，这块就是为TARA分析提供足够的环境支撑，不管是直接还是间接与车灯系统有关系的，都需要列举出来。有了上述基本概念，我们接着回顾TARA分析方法的八股文：资产定义 -> 相应破坏场景定义 -> 影响评级 -> 危害场景识别 ->

在聊完车载信息安全需求之后，势必要去看看​应用场景有哪些。根据之前的开发经验简单聊一下我知道的，还有很多没有讲，比如说车云之间具体如何进行信息安全防护，SOC上不同操作系统的虚拟化安全边界等等，所以这里抛砖引玉，聊聊之前​做过的一些内容。

与Safety的典型分析方法一样，Security也有一些典型的信息安全威胁分析方法(TARA分析)，根据SAE J3061、ISO/SAE 21434和EVITA项目的推荐，整理如下。

本篇内容从国内外汽车网络安全的法规，详细描述了R155和ISO/SAE 21434的联系和交叉，基于21434简单阐述了资产定义、威胁等级定义等示例；最后描述了从整车角度出发，汽车网络渗透测试所要关注的测试内容。 接下来，我将以一个车灯系统的demo为例（21434提供），看看是如何定义出一个满足ISO/SAE 21434的系统。

综上，为保证上述两种升级包的发布来源有效、数据完整不被篡改、升级内容不被恶意截获，一方面需要为升级包进行签名，保证数据来源可靠，数据完整没有被篡改；T-Box(或者带有T-Box功能的座舱域)接收到来自云端的升级包后，对升级包进行验签解密，完成数据包的拆分，同时作为OTA Master对车内所有ECU进行差分升级。在生产或者下线阶段，必须要禁用或者锁定相关的调试接口，禁用意味着无法与硬件调试接口建立连接，锁定意味着硬件调试接口受到保护，只能根据安全调试解锁来访问。安全存储通常是有两种方式实现。