在做SOA架构下的安全测试中,发现27算法在一些新场景下的用途以及存在的安全问题。回头翻资料的时候发现讲27服务(安全访问)的文章倒是不少,而讲述完整的UDS刷写过程的文章相当少,且很少与安全相结合。今天和大家分享一下27安全访问的安全性以及我对UDS刷写流程的一些认识。
本文完整讲述UDS刷写流程以及其中的安全威胁和防御措施,其中涉及到的基础之间见上一篇文章 “车联网安全基础知识之UDS刷写前置基础知识”。
UDS 刷写流程
使用 CANoe 等工具刷写时,开发环境后台帮助我们完成了很多工作,平常大家很少注意这背后到底发生了什么。下面就来看看整个刷写流程。
刷写过程定义了刷写前、刷写中、刷写后三个阶段, 负责将正确的刷写文件( S19 或者 HEX) 下载到 ECU 中。
1 刷写前(设置刷写网络)
刷写前,刷写工具读取 ECU 的 Boot 软件版本号(F180)、软件版本(F188)、 VIN(F190)、 硬件版本(F191),根据从 ECU 获取到的相关信息到刷写数据库中查找对应的升级文件。维修店代码或诊断设备序列号(F198)、刷写日期(F199)在刷写启动时写入,用于追溯之前的刷写操作。
刷写准备阶段需要确认待刷写控制器的相关版本信息, 设置刷写网络等。这个阶段在整车各个控制器的应用程序中执行, 此阶段, 使用功能地址向网络上的各控制器发出诊断请求进行网络设置。
1.1 切换到扩展模式(10 03)
默认状态下 ECU 在 01 默认会话中,使用UDS 会话切换(10 03)进入拓展会话。
1.2 检查刷写前提条件(31 01 XX XX)
整车厂通常会定义一些控制器刷写的前提条件,比如车速要低于3km/h等,这一步就可以检查刷写前提条件是否满足。不同的OEM/Tier1可能有不同的检查条件。常见的前置条件如下,
-
ECU 的电源电压不能太高或者太低(9V-16V)
-
车辆处于 IGN On 状态, 但不在 Ready 状态
-
车辆处于静止状态,车速为 0km/h
具体实现上,使用 31服务 执行检查编程条件的例程 routine,如条件不满足(比如车速过高等),则退出刷写。
1.3 停用故障码存储功能(85 02)
刷写过程中,控制器功能不正常,可能不能收发总线消息,这种情况下,需要避免在这个过程中触发故障码存储。使用85诊断故障码设置服务设置故障码设置类型为OFF(02)关闭DTC的存储。
1.4 停止发送一般通讯报文(28 01 01 XX XX)
刷写过程中,因为传输的数据较多,因此停用通讯报文的发送可以降低总线负载。
使用28服务关闭与诊断无关的报文,将节约出来的通信资源用于刷写软件,提升刷写速度。
2 刷写中(认证&下载数据)
刷写中首先进行身份认证,而后可以写入指纹,然后执行刷写擦除内存,向指定地址下载固件,并检查写入是否正确。
2.1 切换到编程会话(10 02)
刷写过程必须要在编程会话中才可以进行。使用会话控制服务 10 02 切换到 programming session。
2.2安全访问-请求种子(27 01)
27 安全访问服务 保证是有权限的人员或者设备才能够进行刷写,安全访问服务子功能请求种子向 ECU 请求安全认证种子。
2.3 安全访问-发送与验证Key(27 02)
诊断设备收到种子后,将种子作为输入,使用双方已知的算法,计算得到Key。然后使用子功能发送秘钥将计算得到的秘钥发送给ECU。ECU使用相同的算法计算出秘钥并与收到的值进行对比,相同则认证通过。
如果连续多次认证失败,安全访问会暂停服务一段时间。每认证失败一次,ECU安全访问失败计数器就会加1。当错误次数达到3次后,将收到0x36(尝试次数超限)的否定响应码,并延时10秒。10秒之内请求会收到0x37(延时时间未到)的否定响应码,10s之后才能再次发起认证请求。
2.4 写入指纹(2E XX XX YY YY ...)
记录刷写时间(F198)、写入指纹信息(F199),标记写软件人的身份(维修店编号、诊断设备序列号)。
2.5 擦除内存(31 01 FF 00 XX XX YY YY)
在向 ECU 的内存区域下载数据之前, 需要先擦除内存区域已有数据。
采用 31 例程控制服务 FF00 擦除内存,根据控制器地址空间分配和芯片擦除能力,单次擦除所有或多次分段擦除。
31 01 FF 00 擦除起始地址 擦除长度
2.6 请求下载(34 XX YY ZZ ZZ AA AA)
向ECU传输软件之前需要指定写入的地址和数据的大小。
刷写设备使用 34 请求下载服务向 ECU 指定刷写起始地址和刷写数据的大小, 请求下载 ($34)服务指定的内存从起始到结束应该是连续的。如果不是连续的,刷写设备应该为每个要刷写的数据块发送一个单独的请求。
34 数据格式标识符 地址和长度格式标识 内存地址 内存大小
2.7 传输数据(36 XX YY YY ...)
软件下载服务,将数据下载到上一步指定的内存中。
刷写设备使用 36 传输数据服务向 ECU 内存区域中传输刷写的数据,一个数据块通常需要多条传输数据服务传输。
36 数据块顺序计数器 数据
2.8 请求传输退出 (37)
37 服务退出当前连续内存区域的刷写,将在肯定响应中携带校验和,校验最近的一条请求下载请求服务指定的内存区域。
返回的校验和与刷写设备计算的校验和进行比较,如果不相同,将重新使用 36 数据传输服务下载数据,多次校验不通过,刷写将会中断。
2.9 检查存储空间(31 01 02 02)
检验刷写的数据的可靠性,在软件/数据刷写完毕时,刷写设备通过例行程序服务来验证刷写到内存区域的每块数据是否成功。
检查刷写的数据的完整性,确定来源合法,通过CRC、哈希、数字签名等方法,保证刷写过程中不会出错,且刷写的数据是来自合法的提供者。
2.10 检查编程依赖(31 01 FF 01)
使用 31 例程控制服务 FF01 确认刷入的软件和ECU的硬件,基础软件是匹配的。
2.11 ECU复位(11 01)
整个刷写完成后,刷写设备要求 ECU 硬件复位, ECU 进入应用程序。
11 复位服务重启ECU,使刷写的新软件生效。
3 刷写后(还原网络)
刷写后的步骤与刷写前的步骤是对应的,启用刷写前禁用的通信等。
此时网络恢复到正常的模式, ECU 以默认的波特率进行正常的通信,并能进行故障码的检测和存储。刷写结束后要求各 ECU 恢复非诊断消息的发送及接收 。
3.1 切换到扩展模式(10 03)
默认状态下 ECU 在 01 默认会话中,使用UDS 会话切换(10 03)进入拓展会话。在拓展会话中,启用非诊断通信、清除刷写阶段产生的故障码、各 ECU 恢复故障码的检测。
3.2 启用发送一般通讯报文(28 00 01 XX XX)
使用 28 通信控制服务启用在刷写前停止收发的一般通讯报文。
3.3 各 ECU 恢复故障码的检测(85 01)
恢复故障码检测,使用85诊断故障码设置服务设置故障码设置类型为ON(01)恢复DTC的存储。
3.4 ECU 回到默认模式(10 01)
从拓展会话切换回默认会话。
刷写流程图
安全威胁
刷写中最主要的安全维修就是安全访问被突破,而后就能获取ECU中的软件/数据以及刷入篡改的固件。
安全访问算法
安全访问算法一般采用对称加密算法,通常还是简单的移位算法,算法强度较低。
故障注入: 算法大部分主机厂自己设计实现的,算法本身的安全性很少验证。使用故障注入等方式存在被绕过认证的可能。
泄露: 主机厂/供应商代码、企标等在互联网上泄露。
易被逆向: seed2key 一般以 so 文件存在,对固件、诊断仪中的库文件逆向得到安全访问算法。
Key
配置问题: Key的有效长度过短,CVE-2017-14937 安全气囊安全访问(SA)Key为2个字节,第一个字节恒为0x01,那么气囊点火算法只有256个可能的密钥对。
安全常量
除了算法本身以外,最重要的就是安全常量。安全常量通常为4个字节。
安全常量硬编码: 安全常量硬编码在so库中,逆向安全访问算法得到安全常量。
默认: 使用默认的安全常量,在渗透测试中曾多次遇到,0xc541a9 是最常见的安全常量。
使用相同常量: 使用同一种算法的ECU依赖于不同的安全常量来保障安全性。不会因为一个模块算法和常量被分析出来之后,直接影响到另外一个模块上。此外,同一车型同一类型ECU的常量通常相同,很少有实现一机一密的。
种子
种子可被预测: 某车型中的种子基于时间产生,获取到Mask后,能够预测到后续的种子。预测到种子能够缩减破解的时间。
1
static uint32 UDS_GenerateSeed(void)
2
{
3
uint32 u32LocalSeedValue;
4
5
u32LocalSeedValue = STM0_TIM0.U;
6
u32LocalSeedValue ^= UDS_ku32LocLevel01;
7
u32LocalSeedValue = ( u32LocalSeedValue << 7 ) | ( u32LocalSeedValue >> 24 );
8
9
return u32LocalSeedValue;
10
}
种子随机性: 种子随机性较弱,多次请求出现相同种子的情况。
固定种子: 每次获取到的种子相同,这使得爆破出Key成为了可能。
种子恢复: ECU复位后种子相同,每认证一次后复位一次,能够有效降低爆破的数量级。
安全防护 Bypass
-
直接从应用层绕过,对一些实现了远程诊断的车型,直接调用应用层,操作敏感功能,而无需要关注安全访问。
-
ECU Reset 重置绕过安全访问延时。
-
安全访问延时绕过,2010 年的 VW Golf 转向ECU 在 K线上实现的UDS,使用低权限的用户登录后认证失败计算器就是清零。在爆破高权限时,在中间穿插一些低权限用户登录就能持续爆破。
拒绝服务
- · 持续发送错误的消息,将触发10s延时认证,影响正常的刷写。
- · 31 服务擦除内存,使 ECU 变砖。
- · 刷写前提条件不健全,如车辆在运行中执行刷写流程,影响行车安全;正常行驶中,停止通信报文发送,出现异常。
窃听获取固件
由于CAN广播传输的特性,任何节点都能接收到发送的消息。当下载固件时,如果固件没有加密传输(在请求下载中指定为不加密) ,持续监听总线,当执行ECU升级时,能够监听获取到固件。
非法刷写
-
· 34、36 缺乏身份认证,在未经身份认证的情况下刷写。
-
· 安全认证被突破,刷入非法固件。
软件付费绕过
经过认证后,通过篡改固件或发送伪造消息启用需要额外付费的功能。
防御
使用非对称算法: 使用 29服务 替代27服务,29服务支持非对称算法,安全性能够得到很大的提升。即使算法泄露,也不会造成影响。
安全常量采用安全存储: 自行实现的对称加密算法安全常量通常硬编码在so库中,容易被逆向出。安全常量应采用安全存储。
算法逻辑安全: ECU复位后,产生的种子每次都一样,应避免采用类似缺陷的算法;敏感功能都受到安全访问保护。
安全配置: Key 的有效长度能够有效防御暴力破解等;刷写前置条件健全,在特定条件下方能执行刷写流程。
安全启动: 应用安全启动,当安全访问被突破后,拒绝启动刷入经过篡改的固件。
安全传输: 固件采用加密传输,请求下载数据传输标识指明为加密传输,并对应使用加密固件。
监测: 检测潜在的攻击,及时阻断。
还原: 检测到被篡改,通过备份、云端等信息恢复。
附录
参考
ISO14229 Unified diagnostic services (UDS) — Part 1
XXXX ECU刷新规范
车联网安全事件时间轴
汽车安全
Bootloder开发方案(基于UDS)
基于UDS的ECU软件刷写流程
UDS诊断服务基础篇之27
CANoe中使用CAPL刷写流程详解(Trace图解)
【VCU】详解S19文件(S-record)
SREC (file format) - Wikipedia
Intel HEX file format
Intel HEX - Wikipedia
us-18-Milburn-There-Will-Be-Glitches-Extracting-And-Analyzing-Automotive-Firmware-Efficiently
系列文章
车联网安全基础知识之汽车模块化平台
车联网安全基础知识之大众集团汽车电子电气架构
车联网安全基础知识之TBOX主要功能
车联网安全基础知识之大众J949(OCU/T-BOX)
车联网安全基础知识之充电基础设施
车联网安全基础知识之从插线端子分析车内通信网络结构
车联网安全基础知识之QNX命令
车联网安全基础知识之测试台架购买
车联网安全基础知识之USB SPH2.0线束制作
车联网安全基础知识之UDS刷写前置基础知识