目录

1.SecOC和系统安全？

2.破解实录

 2.1 破解安全访问授权

2.2 程序控制的漏洞

3.小结

---

2020年左右，汽车信息安全开始在业内普及。

对于这种新概念，部分OEM仍采取以往开发模式，在不影响软件架构的大背景下，直接进行软件的功能堆叠。

毫无疑问，这种开发逻辑没有做任何TARA分析，后门漏洞肯定存在，因此今天就来聊聊一些已知的攻击事件。

1.SecOC和系统安全？

2021年，某日系车被爆出通过逆向工程可以提取到SecOC密钥，从而可以向任意ECU发送消息，控制大多数驾驶功能，例如AEB、ACC等等。

但根据AUTOSAR SecOC文档描述，理论上它的MAC生成逻辑是相对难以攻破的，首先用于MAC生成的数据包括了完整新鲜度值、ID以及原始数据，但接收或者发出报文的最终身份信息是由截断的新鲜度值和截断MAC值共同构成，如下；

而新鲜度值截取部分只包括了消息计数器低位和重置低位，如下：

在不知道Trip Counter、Reset Counter的情况下，想要正向破解SecOC几乎是不可能的。

但是总线上的同步报文全是明文，它将上述两个计数器完全暴露了出来：

那接下来就只需要提取到SecOC相关密钥，整套车内板端安全通信就被攻破了。

现如今，密钥一般存放在HSM或者SHE内部，想要直接逆向是比较困难的； 

但如果从整体ECU软件架构上来思考这个问题，一切就变得奇怪了起来。

首先我们回忆一下，关于密钥更新的这部分逻辑，很多ECU仍然采用UDS进行更新，这就意味着必定有相关的DID；

其次目前汽车ECU成熟且比较典型的ECU Flash 布局如下：

在迭代比较慢的ECU里，A\B升级还没完全普及，仍然采用Bootlaoder升级App的方式；

按照之前经验，Bootlaoder中的Flash Driver运行一般有两种方式：

• 解密存在Flash中的FlsDriver并搬运到RAM运行；
• 接收上位机下发的FlsDriver，并在指定RAM位置运行。

而我们知道，Bootlaoder的更新流程大部分沿用ISO 14229、ISO 15765、不外乎企标在细节上有所不同。这种升级必然有接口对外，而这就有可能被成为攻击向量。

日系车SecOC密钥被提取，也正是从上述方向找到了突破口，我们来看看他们是如何一步一步对系统进行破解。

2.破解实录

破解的目标ECU为EPS，通过拆解发现了该ECU的MCU型号为RH850\P1M-E，该芯片有ICU-S，符合EVITA-Light；

虽然该芯片调试端口量产时被锁住了，但通过电压故障注入攻击，代码仍旧被逆向提取，如下：

当然这不是今天的重点。

通过对这些代码进行审计，梳理出了对SecOC报文的MAC计算流程，攻击者惊讶地发现：该ECU的SecOC软件模块竟然没有使用HSM，并且所有AES计算全是软件完成，这意味着SecOC相关密钥有可能仅仅是加密存储，但没有受到保护。

这就是比较奇怪的一点：明明这颗芯片带有ICUS，为什么不使用？有没有可能是成本原因？甚至说是为了赶进度，在不修改整体软件架构的情况下把该模块迅速实现了？

进一步的，通过梳理Bootloader中的更新流程，攻击者发现了一个致命的漏洞，通过该漏洞可以任意提取芯片内部数据，那就是前面我们提到的“接收上位机下发的FlsDriver，并在指定RAM位置运行”。

整体攻击逻辑总结如下：

1. 通过UDS SID 0x10，从默认会话切换到编程会话；
2. 通过UDS SID 0x27完成身份验证；
3. 通过UDS SID 0x2E设置AES必要的密钥、IV等等；
4. 使用UDS SID 0x34、0x36、0x37将上位机的FlsDriver下载到RAM，但是这个FlsDriver被攻击者替换为shellcode；
5. 通过UDS SID 0x31 Routine Control对shellcode进行验证，包括CRC和CMAC；
6. 通过Routine Control控制FlsDriver擦除目标区域，但实际上触发了shellcode的运行；
7. 最终Dump出SecOC密钥。

 2.1 破解安全访问授权

27服务基本逻辑是上位机向ECU请求一个随机种子，然后对这个种子进行运算得要一个security key，并发送给ECU；ECU同时也算一个值，进行比较，相同则解锁授权，如下：

但在该ECU中，代码逻辑除了基本流程外，在请求种子时，ECU还需要上位机下发16byte数据参与到Security Key的计算，具体流程如下：

在ECU里包含一个AES KEY，长度128bit，用于加密Master下发的16字节数据，得到一个派生密钥Key1；然后继续使用Key1对种子进行解密，得到最终的Security Key。

因为Firmware已经被逆向出来，并且在由于没有使用ICUS，参与到上述计算的AES Key必定没有被加密（否则就需要对AES KEY进行解密，也可以从固件中看出逻辑）；知道这个逻辑后，很容易绕开安全访问这个服务；

那么接下来就是如何shellcode下载到ram中。

2.2 程序控制的漏洞

RoutineControl是UDS里比较重要的一个服务，常见用法包括memory擦除、运行自举测试、校验等等，一旦27服务被破解后，31里面的各种routine即可任意使用。

在上面我们知道，该ECU的FlsDriver是通过上位机下载到RAM运行，因此篡改这个FlsDriver（shellcode），并保证它通过CRC、CMAC等校验，我们就可以通过shellcode 提取到SecOC密钥。

经过分析，该FlsDriver有特定格式，具体如下：

在 偏移0xFD0处，存放着Driver实际运行地址，该项目中为0xFEBF0000，意味着每次触发擦写程序，都会从跳转至这里开始运行；

除此之外，还有CRC以及AES CMAC用于身份和完整性验证，这里可以通过识别到的DID进行，具体逻辑如下：

使用固件中的另一个私密Key对写入的DID 0x201进行加密，得到AES Key，然后把写入的DID 0x202数据以及请求下载到的有效Payload(0xFF0字节)组合得到0x1000byte数据，用AES Key对其进行CMAC计算，得到最终的CMAC并添加到待下载的FlsDriver末位，这样就拼凑了上述格式的有效payload，并且可以完美通过校验；

最终，我们要dump SecOC密钥的程序就在shell code中实现。效果如下：

3.小结

可以看到，在获取到SecOC Key之后，我们只需要在总线上抓到同步报文的Reset\Trip Counter即可完整拼凑出带SecOC属性的报文，从而实现整车的控制。

这个ECU的开发很显然仍旧采用以前的软件架构和思路，这在面对汽车信息安全时显得不是特别契合，一方面功能能够按照规范完成，但另一方面由于之前开发思路基本没有考虑过网络攻击，这就很有可能留下了一些漏洞；因此，在未来几年，为弥补这方面的缺憾，OEM、Tier 1的软件架构势必会出现很大的改动。

我们拭目以待！