汽车网络安全左移实践——基于信任构建汽车安全的探索

编辑整理：谈思实验室

出品平台：谈思汽车

《汽车网络安全左移实践——基于信任构建汽车安全的探索》

本文主要围绕以下四大内容展开：

• 汽车信息安全“七大”

• 谈“信任”

• “信任根”

• 基于信任的网络安全左移实践

首先说一下整车信息安全的七大领域和资产的七大安全属性。

基于TARA分析，通过多次实践，形成整车信息安全的七大领域：

1.  数据与隐私安全

2.  业务与功能安全

3.  应用与平台安全

4.  环境安全

5.  通信安全

6.  后台与移动安全

7.  生产与售后安全

这七个领域全部都要考虑风险评估和安全措施，通常在做安全设计的咨询工作时需要要从这七个方面考虑，尤其是需要进行VTA认证的车型，要对这七个方面的安全做充分的考虑。

我们在做TARA分析的时候，要识别资产，针对资产来做威胁分析与风险评估。通常我们在考虑资产的安全属性时，也会考虑7大安全属性。很多人经常提到的是机密性、完整性和可用性三个属性，但为什么仅仅是CIA三个属性还不够，那是因为汽车的一些独特性，还需要额外加四个。比如新鲜性，因为汽车是一个实时运行的系统，它的执行器很多都是具备实时性的。举个例子，现在的刹车和一个小时候后刹车完全是不一样的，现在指令它不能在一小时后被别人来重放攻击。要解决这个问题，就要确保指令的有效性，在时间上有效性，也就是这里说的新鲜性。至于新鲜性用什么技术手段来保证，是用新鲜度值还是用时间戳或者用挑战值，这是下一个阶段，进行安全方案设计的时候要解决的问题。但是在威胁分析的时候，这个因素必须要考虑在里面。再说真实性，作为物联网的设备来说，有的设备是容易被伪造的。如何防止被伪造的设备攻击，那么就要验证它的真实性，要给这个设备一个证书或者一个私钥的身份。所以我们在做咨询的时候，对于每一个资产要考虑七个安全属性的分析。当然不是所有的资产都包含这七个属性，要根据资产的类型具体情况具体分析。

1、信任与安全的关系

系统安全工程是为了解决漏洞的一系列方法和规则，实际上本质是提供必要的信任证明，以抵抗复杂的网络攻击。首先从原理上来看，要用技术来解决，用流程来保证，还要具备完整的信任链条。例如，零信任架构，零信任是一个以资源保护为核心的网络安全范式，核心是资源保护，这里有两个前提。第一个是信任，信任从来不是隐式授权的，信任是可以传递的。A信任B，B信任C，A就可以信任C。通常叫信任链，但是中间如果有A信任B，B信任C，C不信任D，所以A是不能信任D的。第二个是持续评估，举个例子，一个小时之前这个器件是安全的，不代表现在这个器件还是安全的，没有被篡改，很多时候都跟时间关联比较大，所以要做一个持续性评估。

2、通过信任构建安全示例

安全启动的目的主要是去验证代码的安全性，但如果要验签，验签完之后才能知道加密是可信的，然后固件、OS系统才能启动。APP也要验签，确保APP没有被别人篡改。如何得知验签是可信的，验签用的密钥是否容易被别人篡改，是否容易被别人拿到，如何确保这个密钥可信。使用的密码学算法是否容易被别人攻击（所以通常都选择一些规范的密码学算法）。

用户登录的目的是做身份的可信认证，通常会通过可信的认证因子进行认证，如验证码、口令、生物特征等。

安全诊断是车的零部件会做一些安全诊断，执行器做诊断的时候，如何做身份的验证，如何确保接入的诊断仪是合法的，包括执行器是否是唯一标识的，通常会使用27服务或29服务。

数据安全是全磁盘加密FDE,是可信的用户身份+可信的密码算法。

车载系统常用的防火墙，防火墙的基本工作原理是黑白分明的，严进严出，但会给予一个假定，假定防火墙的引擎和规则配置是值得信任的，黑白名单规则会按照意愿生效。但是基于信任链的思想，需要为假设做出证明，证明引擎值得信任，做了任何一个假设，都要去证明它，这是一个复杂的系统性安全工程。

1、“信任根”的定义

信任根，从基本定义来看，信任根是平台中的一个计算引擎+一段代码+可能的数据，通常这个数据是一组密钥，它提供基础的安全服务，如机密性、完整性、可用性、标识、真实性、授权性还有度量性。信任根还有个特点，它的代码和数据的可信证明是由自身完成不依赖于其他实体的，就是它必须要自证它是安全可性的。

2、常见的“信任根”

常见的信任根有HSM、TEE、TPM等，通常HSM按照EVITA规范分为三种，Full、Medium、Light三种功率，放到不同的位置上，什么地方应该放什么。因为它是提供的安全的能力不一样，可能有的地方，在Light上确保执行器安全就足够了。TPM有个比较强的能力，能做平台的度量，平台度量是度量的一个重要的特点，所以它会放一个度量的信任根在里面。TEE处于这两者之间，它的安全性和数据处理的能力处于HSM和TPM之间。目前在很多车载设备里，至少需要包括其中一种类型，有的时候会做组合。

3、“信任根”与七大领域

谈下信任根与七大领域的关系。第一个，数据与隐私安全，在做数据和隐私安全的时候，会考虑到音视频，比如说音视频的这种机密性要加密存储，那么加密的密钥能否会被别人盗走，如果盗走的话信息就没有机密性可言了。还有例如哨兵模式中的视频加密密钥，这个密钥是不允许车厂获得的，因为哨兵模式所产生的视频信息，它是不属于车厂的，是属于车主的。那么车厂必须要证明，要去拿逻辑来证明，车厂只能碰到它的密文，绝对碰不到它的明文，碰了明文就违反了个人隐私保护。

说到业务和功能安全，蓝牙钥匙等远程控车指令比较多，这时候会做MAC密钥，这个密钥放到哪，怎么存储？

考虑应用与平台安全，会有一些关键业务代码。比如说，在自动驾驶里有AI算法，它的模型是非常重要的，这样关键业务代码能防止被别人篡改。环境安全，是外部的一些设备，尤其是现在v2x如何确保外部环境实体的一些设备、身份、唯一性标识及其完整性保护。

通信安全是车内通信的真实性、完整性和新鲜性，例如SecOC验签。

后台与移动安全，通过机密容器去确保环境的安全，这样的话，这个机密容器生成的时候，它本身的安全是保护的，然后生产过之后，它属于售后的问题，在售后的时候，怎么确保售后不会出现安全风险，这些问题都会在车型准入的审核中被提出并审核。如果这个系统不能在一开始做整车系统的概念设计阶段就把这些安全需求系统的提出来的话，后面付出的代价就比较大。

1、豆荚基于信任的实践-OTA安全

把TEE放到TBOX上去，方案目标是做通信安全，做OTA安全。通常为了信道的安全，系统都会使用TLS协议，数据是加密的。但是安全有个特点是木桶原理，信道是安全的，但在进信道之前呢？在信道往外传的时候加密数据，在加密的环境里是否能拿到这个密钥，不从信道拿，从加密的环境拿，这样的话，这个密钥的安全性就需要包括用密钥对中心的数据做加密的环境是否安全，所以我们在TEE系统里面把密钥存在里面去，然后把TLS协议进行分解，跟加密相关的业务逻辑，这叫关键代码，把这个关键代码给放到TEE系统里，因为TEE系统能保护这种应用程序的执行。

OTA业务为了保证升级包的机密性，通常会进行加密。OTA密文下载下来之后要在TBOX上进行解密，解密后是明文，TBOX是在车里的，容易被第三方touch到。这样的话，如何确保下载下来的明文不会被别人篡改。通过安全启动去做验签，在OTA升级完成之后，不能启动篡改，但是它本身下载的时候，如何防止别人看到原文。利用可信执行环境TEE，把它的密文，解密动作放到TEE里来做，做完之后放到芯片指定的一个区域里面，用芯片的加密器件来处理，最后引导的时候，通过芯片的加密器件再把它解开，然后再传通，在Linux运行之前，Linux系统是看不到原文的。有个重要的环节是这里面很多证书密钥系统都是在生产线上完成的，也就是说在生产线上，如果不把这种证书和它的设备、私钥生成的话，后面可能就没有更安全的通道可以加进去。通常情况下会默认工厂环境是可信的，这时候我们认为后加的流程是不可信的。在工厂环境中，通常还要再加一个动作，就是做一个安全产线，即密钥不能以明文形式进入，必须是对密钥进行加密的密文进入。进入之后，在生产线上通过程序把加密的密钥解开，再存到安全区域。

安全是木桶原理，木桶的短处永远是最弱的地方。我们在做TARA和安全方案设计时，要把流程分析清楚，因此网络安全和功能安全有时候是很难区分的，如果我们不了解执行器的工作原理，就找不到信息源。所以说网络安全跟功能安全是要互相配合的，互相合作的。

2、豆荚基于信任的实践-ZT-V

现在汽车的SOA架构有什么好处，又存在哪些隐患呢。因为SOA的开放性，SOA最主要目的是资源和服务共享，让汽车具备更多的智能服务。但它的问题是，一旦开放的话，肯定会带来很多风险，所以我们要结合零信任来考虑安全的SOA架构。零信任基本核心是3+1，第一个是身份认证，第二是隔离，第三个访问控制，再加上一个持续的审计、持续的度量，再把可信的思想即信任根和可信度量加里面，来做SOA项目的安全防护。

3、豆荚基于信任的实践-TEE

可信执行环境TEE在汽车领域使用的场景广泛，也能够很好地解决问题。第一个是密钥，和HSM、TPM有些类似的地方，需要根据具体的情况，来分析什么时候用HSM，什么时候用TEE，什么时候用TEE和HSM结合。

第二个是敏感代码的保护，TEE提供环境，运算能力更强，很多时候HSM做不到一些运算但它能做。例如安全UI，目前可能用的比较少，在一些特殊的环境可能会用，因为UI会被别人仿造，甚至UI上的动作也会被模仿，如何防止UI被劫持也是个问题。

再来看资源隔离，不管是HSM、TPM，还是TEE，都是具备隔离保护能力的。在CCC车钥匙的规范里面就有明确指示，哪段逻辑要放哪部分的数据，那些隐私数据、机密数据是需要放到TEE环境的。

内容保护方面，视频流最后是一定要解码的，解码之后，这个解完的码通常都放到Rich里面，这样的话就需要考虑Rich是否安全。TEE和TPM比较相似，有一个单独的Rich区域，它是安全的，它是不能被Android、Opreating系统所防的。安全支付比如说现在我们用的手机上所有的支付手段，不管是微信支付，还是支付宝支付，它的TAs(Trusted Applications)生成隐式的串号都是在TEE执行里面的。

4、基于信任的网络安全左移实践

在做咨询的时候，在后期遇到最大的问题是如何去支持客户，支持主机厂，零部件供应商去解决准入认证评审中的问题。很多时候我们都要从前面开始考虑，如果把问题都放在最后的测试阶段，问题解决的难度就变大了，所以要提前把这些安全的问题识别出来，不光要把安全的问题识别出来，还要把方案提出来。从咨询工作中总结得知，这些安全目标要在咨询前提出来，比如在做通信的时候，基本上机密性、身份真实性、完整性、新鲜性都要提前考虑，信道可用性也要考虑。固件，固件的机密性、完整性、可用性、新鲜性也是要考虑的，ECU的可用性、真实性、抗抵赖性、访问控制，包括数据的机密性、完整性、可用性等等。

针对以上安全目标，也有控制手段。

不光要技术手段，而且也要靠规则来约束一些安全配置和安全存储设定，但这些内容过多，所以需要建立规则，即做一些规范把曾经遇到过的问题梳理出来，如前面所提到的七大安全属性。通常资产分为四类，数据流、实体类，实体类分内部实体和外部实体，数据存储。数据流要考虑机密性、完整性、可用性和新鲜性，但是在分析外部实体时候，要考虑真实性和不可抵赖性。虽然定了七个安全属性，但对于不同的资产，要求是不一样的。需要慢慢整理出来，同时在发现问题的时候一定要提出解决对策。

例如机密性问题，通常会怎么解决，例如加密、混淆、隐藏、访问控制、隔离、脱敏，但是具体用哪个，就得看这个功能，所以为什么说网络安全和功能安全有时候结合是比较紧密的。

对于完整性的问题，可以用访问控制、消息认证码、公钥签名、一次性编程，还是要看硬件，如果真的是硬件的话，就用一次性编程。对于一些软件，尤其是应用软件，用访问控制。

在做分析的过程中，仅仅用这些经验和最佳实践做指导，有时候用起来也不是特别方便。所以按照IDS思想做工具，把它变成工作时内部信任的工具，这样的话就有一个知识库。把最佳实践和实际的案例做对比，做映射，放到知识库里。工具的最主要目的是提高设计效率，像早期做TARA分析的时候，一个TBOX大概有160个资产，都要资产分析，尤其是攻击路径的时候，我们提供一个规则库，这样做很好但特别耗时间，而且最主要的是有些地方是重复的，这样如何提高效率，所以需要用到一些工具。做TARA分析，并不是为了分析而分析，最终目的是帮助客户做合规，提高整车安全的安全。R155包括国内即将推出来的《GB汽车整车信息安全技术要求》 ，还有陆续推出的数据安全规范，把这些合规的要求也要加到这里面去，通过这几年形成的规范和最佳实践，形成工具，这样就能真正提高效率，提供更好的服务。