Security notes
该如何打下一台智能…
该如何打下一台智能汽车
首发于先知社区：https://xz.aliyun.com/t/9629
前言
更多的是对车联网安全认知过程的记录，希望能找到车联网安研需要的一些技能树和研究的大体方向。
最初对车联网安全的认知，大概要从sky-go在MOSEC 20 BaijiuCon里汽车安全talk里的一张汽车安全攻击面导图说起：
首先从我们朴素的车联网认知出发，结合图里认识的关键字，有两个常规思路的攻击路径：
- 云服务。IoT设备所谓万物互联，除了局域内用CAN或PLC连接的情况，基本都是借助云服务实现，这就把这部分车联网安全问题可以归类为主机安全问题和一些认证相关的问题。
- 移动终端。也就是图里从Phone到IVI的路径，可能通过WiFi，可能通过蓝牙，可以通过协议、无线电的安全问题考虑，也可以从移动端的安全问题入手。
然后，了解一下图里相对生僻的关键字所代表的进入车内网路径：
- GNSS，定位模块。
- ADAS，先进驾驶辅助系统。
- Sensor，传感器。（图里最右边红色圆柱确实看不清，问了Sky-go的师傅，大概是传感器这方面）
- V2X，基于蜂窝（Cellular）通信演进形成的车用无线通信技术（Vehicle to Everything），RSU（路侧设备）、OBUs（车载设备）在车联网时代便依此通信。
之后，再从车内网组件视角梳理车联网的一般组件：
-
TCU(Telematics Control Unit) 远程信息控制单元
-
ECUs（Electronic Control Unit）电子控制单元
-
IVI（In-Vehicle Infotainment system）信息娱乐系统
-
OBD-II 第二代随车诊断系统
回看sky-go的talk所分享的攻击链：一个移动终端起步的攻击链。其流程即通过终端发起请求，后端服务下发指令到车联网模块，随后转发至车载网络，最终命令执行：
从渗透的角度想，一次针对系统的攻击，分为内网边界突破和内网横纵向扩散两部分，前者往往是难度的来源。要想完成无接触的攻击链，基本上就云服务和移动终端两条路可走，但对汽车系统的攻击和纯黑盒的渗透并不同，我们能摸到同车型基本一致的ECU和IVI。之前面一个IoT岗，他们实验室对设备挖洞基本上是按技能树分，做内核的找内核洞，做fuzz的去fuzz协议，做逆向的分析固件云云。同理，私以为针对每个车内组件做研究，随着成果蔓延，运气足够，或许也就能形成完整的攻击链。
基础知识
0x00.总线
总线，是指计算机组件间规范化的交换数据的方式，即以一种通用的方式为各组件提供数据传送和控制逻辑，英文称BUS，顾名思义。
但这里有个让人有点困扰的的点，即协议和总线概念上微妙的差别。比如说我们说PCIE，可能是PCIE接口，有可能是PCIE总线，还有可能是PCIE协议，认知差异客观存在。回归到总线和协议，从狭义上讲，如果不是说物理总线，那么我们默认的总线往往是包含其协议，譬如CAN的WIKI如是：
控制器局域网 (Controller Area Network，简称CAN或者CAN bus) 是一种功能丰富的车用总线标准。被设计用于在不需要主机（Host）的情况下，允许网络上的单片机和仪器相互通信。 它基于消息传递协议，设计之初在车辆上采用复用通信线缆，以降低铜线使用量，后来也被其他行业所使用。
在车联网视角里，我们的确可以直接把总线视为硬件的互通标准，对其了解并考虑其中可利用的点，即此处安全研究的目标。
控制器局域网CAN
现行的汽车控制系统标准总线便是上文提及的CAN，用于实现嵌入式系统和ECU的通信需求。车联网时代之前，CAN只负责车内数据交换和信息传输，不与外界通信，那个时代想利用CAN进行攻击那得物理接入汽车才能做到；问题就出在车联网之后， 联网组件接入CAN让远程利用成为可能。
好，通晓背景之后，该考虑一下CAN的实际部署形式和容易被收集到的安全问题：
CAN的实际部署
CAN运行在两条线路上，CAN高电平（CANH）和CAN低电平（CANL），使用差分信号（低速CAN除外），即当信号输入时，CAN提升一条线的电平，在另一条线降低同幅度的电平。当1位数据被发送到CAN总线上，同时广播升高1V和降低1V的电平信号，传感器和ECU中有一个收发器，确保这两种信号均被触发，如果没有被同时触发，即判定为噪声丢弃。
一般两条双绞线构成总线，在总线终结端，两导线跨接一个120Ω的终结电阻，完成总线要求的在每个末端进行终止的需求。
易收集的安全问题
1、广播数据包，易监听、捕获
CAN总线中报文是通过广播传送方式，所有的节点都可以接受总线传送的消息（如图2），为报文信息监听提供了可能，汽车总线数据容易被捕获分析。
2、传播的消息源不完整不可靠
协议中没有原始地址信息，接收ECU对收到的数据无法确认是否为原始数据，这就容易导致攻击者通过注入虚假信息对CAN总线报文进行伪造、篡改等。
3、总线的脆弱性
CAN总线协议中基于优先级的仲裁机制，为黑客对总线收发报文进行拒绝服务攻击提供可能。攻击者可以通过嗅探或监听等手段对汽车总线进行重放或洪泛攻击，导致ECU无法正常发送和接收报文。
简单来说，CAN和安全策略比较落后的问题基本一致，因为最初只考虑功能和性能问题，安全机制往往不会被考虑到，这种系统从完整性、可用性、保密性、不可抵赖性这些安全几要素上考虑都有收获2333
标准数据包
| 字段名 | 字长 （位） | 作用 |
|---|---|---|
| 起始位（SOF） | 1 | 表示帧的传输开始 |
| 标志符（ID\green） | 11 | 唯一识别码，同样代表了优先级 |
| 远程传输请求（RTR\蓝色） | 1 | 数据帧时一定是显性（0），远程请求帧时一定是隐性（1） |
| 标志符拓展位（IDE） | 1 | 对于只有11位标志符的基本帧格式，此段一定為显性（0） |
| 预留位（R0） | 1 | 预留位一定是显性（0），但是隐性（1）同样是可接受的 |
| 数据长度代码（DLC） | 4 | 数据的字节数（0-8字节） |
| 数据段（Data field） | 0–64 (0-8 字节) | 待传输数据（长度由数据长度码DLC指定） |
| 循环冗余校验（CRC） | 15 | 循环冗余校验 |
| 循环冗余校验定界符 | 1 | 一定是隐性（1） |
| 确认槽（ACK） | 1 | 发信器发送隐性（1）但是任何接收器可以宣示显性（0） |
| 确认定界符（ACK delimiter） | 1 | 一定是隐性（1） |
| 结束位(EOF) | 7 | 一定是隐性（1） |
主要关注：
- ID：仲裁ID，识别正试图通信的设备的ID，两个CAN数据包同时在总线上发送，低仲裁ID优先。
- IDE：是否为扩展包
- DLC：数据大小，0-8字节
- Data：数据本身
扩展包：可链接在一起形成更长ID。用SRR代替RTR，IDE置1.
CAN-utils工具包
这里要先了解个概念——SocketCAN：我们如果想用CAN和车辆通信，要考虑到各种各样的驱动、软件等等，非常麻烦，所以说需要将多种CAN工具及其不同接口统一成一个通用的接口，目前通用的这个就叫SocketCAN。SocketCAN将CAN驱动作为网络设备实现，通过socket描述程序对CAN总线的访问。
CAN-utils便是SocketCAN方面可说最为得用的工具包，从最基本的抓包、转储、重放、生成到计算芯片组比特率、读对应比特率寄存器值，应有尽有。
详细工具可见其Github repo的README，也包括编译之类的信息。
另外，socketcand和Kayak算是另一类和CAN交互的实现，尤其Kayak实现了可视化，可能对CAN的分析会更加友好些。
OBD-II连接器
OBD-II是CAN总线之上的车上诊断系统，是一种设备于车中用以监控车辆运行状态和回报异常的系统，可为车主，维修技术人员以及汽车保险公司提供诊断能力，例如监控汽车的速度和燃油。该诊断端口连接至CAN总线并传递CAN总线消息。作为基于消息的协议，特殊的OBD-II消息被定义为传达诊断信息，称为OBD-II参数ID（PID）。不同于特定车辆制造商定义的高度定制的CAN总线消息，这些OBD-II PID是标准化的。基于OBD-II标准，开发了许多用于车辆诊断的OBD-II软件狗，例如监视速度，燃油和发动机状态。插入OBD-II端口后，这些加密狗可以不断发送CAN总线消息，以查询来自CAN总线的诊断数据。
通过OBD-II端口很容易和车内CAN总线进行交互。事实上大部分的汽车OBD-II端口也确实充当着一个直接进入车内总线的接口，况且此接口提供12V的直流电源输出，可直接为连接设备提供电源。
从OBD-II的接口和生态我们能分辨出两个攻击面：
- 可以将其理解为车内网的BADUSB（更近硬件层危害升级功能丰富版）。通过近源渗透，将设备接入汽车的OBD-II接口，用设备发起攻击。
- 各种各样的已存在OBD-II设备可能导致的攻击，比如其配套应用安全问题可能导致攻击者可以无线访问OBD-II端口。
其他
同时，CAN总线也有一些CAN的扩展协议，其他总线也有更慢更易实现的SAE J1850，还有ISO 14230、LIN、MOST、FlexRay等等总线，不再赘述，实际接触到之后读手册即可。
0x01.Hack ECU
这里首先要明确一下ECU指代的对象，Electronic Control Unit，电子控制单元。一辆车往往有10+电子控制器，有发动机控制单元（Engine Control Unit），有变速器控制单元（Transmission Control Unit）等等，我们讲Hack ECU，并非仅仅Hack Engine Control Unit，而是针对电子控制单元这个攻击面，在嵌入式层找洞。
ECU攻击可分三类：
前门（front door）攻击
劫持原始设备制造商（OEM）的访问机制。
OBD-II标准规定车辆可以通过OBD-II连接器进行重编程。所以对原厂编程方式进行逆向工程是一种有保证的攻击方式。其实我们所谓的重编程也就是汽车改装领域的刷ECU，虽说ECU基本上都是大公司调参平衡之后的较优解，但难免有人会不在乎油耗、部件寿命之类的追逐最大动力。看来以后做不了安全还能去刷ECU收智商税（不是
以J2534编程协议为例：
J2534，引入一系列DLL，将标准API映射到汽车通信的必需指令。
使用J2534工具攻击车辆系统，基本思路：观察、记录、分析，而后扩展功能。
实施流程：获取并配置一个J2534应用程序及相应的接口硬件，以执行希望观察的任务。完成设置后，下一步则在使用J2534工具对目标执行操作
观察方式：
- J2534填隙DLL:一种软件J2534接口，能连接到物理J2534接口并传递和记录所收到的所有命令。
- 协同使用J2534和嗅探器
后门（back door）攻击
用传统的攻击嵌入式设备的方式去攻击ECU，固件提取解包分析，硬件调试等等。
首先分析电路板，从最大的芯片开始，一一去看SRAM、EEPROM、FlashROM、一次性可编程ROM、串行EEPROM、串行Flash、NVSRAM等。
漏洞利用
发现非预期的访问机制。从Bug方面考虑，可借助Fuzzing和PWN方面的漏洞挖掘等方式。
0x02. IVI
IVI (In-Vehicle Infotainment 简称 IVI)， 是采用车载专用中央处理器，基于车身总线系统和互联网服务，形成的车载综合信息娱乐系统。
攻击面
一般拥有一个以上可以用于汽车通信的物理输入（同时也是它的攻击面）：
- 辅助插孔：
- CD-ROM
- DVD
- 触摸屏、旋钮、按键
- USB
- 一个以上的无线输入：
- 蓝牙
- 蜂窝连接
- 数字收音机
- GPS
- Wi-Fi
- XM收音机
- 内部网络控制：
- 总线网络（CAN、LIN、KWP、K线）
- 以太网
- 高速多媒体总线
OTA更新
一般流程：
- 企业推送OTA升级包，车端与OTA云服务器建立安全连接，一般将待更新的固件传输到车辆的 T-box（或者其他联网部件），再传输给 OTA Manager。
- OTA Manager管理所有 ECU 的升级过程，它负责将固件分发到 ECU，并告知 ECU 何时执行更新。
- ECU更新完成后，OTA Manager通过 T-box（或者其他联网部件）向云服务器发送确认。
从流程中涉及的事物考虑，首先云服务是最为常见的攻击面，拿下云服务器肯定是攻击的有效途径。
然后车与云服务通信过程中，主要考虑协议、认证相关问题，升级包能否被获取、修改，有无做完整性校验，通信加密是否可靠。
私以为，整个流程的每个环节是否对信息可信和数据安全做校验是关键，和我们日常接触的TCP等流量的数据安全并无本质区别。
IVI相关应用
目前IVI好多都直接使用Android作系统，对其进行攻击可考虑Android相关问题。
另外，智能车往往会有配套APP，对APP测试也是常见有效攻击思路。
攻击IVI硬件
基本思路类似于Hack ECU，不过多了些对外连接部分的测试，比如说对蓝牙、Wi-Fi作安全性测试。
0x03.车间系统
V2V（Vehicle-To-Vehicle），车间通信技术，用在与基础设施通信时称之为V2I（Vehicle-To-Infrastructure）。具体实现三种方式：
- 蜂窝网络。
- DSRC（Dedicated Short-Range Communication 专用短程通信技术）。
- 混合方式，DSRC、Wi-Fi、卫星及其他任何可行通信手段组合。
可以说，车间通信是车联网技术中最具“车联网”感的，它确实也是在和车联网一起发展，意味着不完全成熟。目前很多所谓的5G+汽车概念，就是把5G用于车间通信的实现，和DSRC其实算是竞争者
DSRC
使用5.85GHz~5.925GHz的V2V/V2I保留频段。有效通信距离由发射功率决定，路旁设备约1000，车辆较弱为300。
基于802.11p和1609.x无线协议，基于WiFi的称WAVE（Wireless Access for Vehicle Environments），基于1690.3称WSMP（WAVE Short-Message Protocol，WAVE短消息协议）
基于PKI的安全措施
5G+的车间通信安全性尚未完全可知，但DSRC、蜂窝以及混合通信的安全性均基于类SSL的公钥基础设施（PKI，Public Key Infrastructure）。
公开密钥基础建设，又称公开密钥基础架构、公钥基础建设、公钥基础设施、公开密码匙基础建设或公钥基础架构，是一组由硬件、软件、参与者、管理政策与流程组成的基础架构，其目的在于创造、管理、分配、使用、存储以及撤销数字证书。 密码学上，公开密钥基础建设借着数字证书认证机构将用户的个人身份跟公开密钥链接在一起。(From 维基百科)
这部分问题基本可以参考认证安全的相关研究，在车联网这边主要的差别在汽车的证书上。
因为车辆存储空间有限，且需避免DSRC拥堵，车辆的PKI系统需要较短密钥，故使用椭圆曲线加密算法（ECDSA-256）密钥，证书大小约Internet证书八分之一。
参与V2V通信车辆使用两种类型证书：
- 长期证书（Long-Term Certificate，LTC），包含车辆的标识符，且可被撤销，用于申请短期证书
- 短期证书（Short-Term/Pseudonym Certificate，PC），有效期短，所以不需要撤销，会直接过期。用于匿名传输，该传输模式用于制动或道路条件等普通消息的传输。
0x04.无线电安全
基本环境
SDR（Software Defined Radio，软件无线电）和一个可编程的电台，Hack RF就不错。
SDR可以与GNU Radio配合工作，查看、过滤、解调被编码的信号。
应用正确的解调器，需要具备识别某个信号所用调制方式的能力，首先种类有两种：幅移键控（ASK）、频移键控（FSK）。
ASK数据位由信号的振幅表达，有波动时表达1，静默0。
FSK数据位由信号的载波频率表达，FSK的载波信号始终存在，高频1低频0。
TPMS
针对汽车安全，从无线电的视角，可以对TPMS（胎压监测系统）进行攻击。TPMS通过无线方式向轮室中发送信息，让信号在一定程度上得到车体的屏蔽，通常用315或415MHz的UHF频段。
控钥匙和防盗系统
还有更经典更传统的一个攻击视角——遥控钥匙和防盗系统。
这方面的无线信号主要是RFID，即Radio-Frequency IDentification，射频识别，流程大致如是：
遥控钥匙使用一个工作与125KHz的应答器与车上的一个防盗器通信，防盗器除非接收到正确的解锁代码或其他令牌，将阻止车辆发动。使用低频RFID信号是为了保证遥控钥匙电池耗尽是，钥匙系统也正常工作。
可行方式：
- 干扰遥控钥匙信号。在RFID接收机的通带范围内向接收机发垃圾数据，干扰接收机。通带窗口宽度包括一定的额外空间，可以向该段空间加入噪声，阻止接收机改变rolling code，同时仍允许攻击者查看正确的密钥序列。将有效开锁请求记录在存储器同时，继续等待遥控钥匙发送另一个请求，同样记录之。之后攻击者可以向车回放第一个请求，令其开启或锁闭，具体取决于遥控钥匙发送的信号。
- 前向预测攻击。观测遥控钥匙向车辆发送信号及车上应答器做出响应的质询-响应交换过程，预测下一个信号。受限于PRNG（伪随机数生成器）的脆弱性。
- 字典攻击。记录质询-响应的交换，存储至字典。遇到匹配的请求发送即可。受限于是否使用发送方校验确保响应有效。
- 导出应答器存储内容
- 逆向CAN总线
- 钥匙编程器和应答器复制机。替换丢失钥匙机制。偷车主流方式 : )
PKES
靠近即开锁的机制。对其攻击与RFID类似。
技能树整理
对车联网的攻击面有些认识之后，也大概能理解做相关的研究需要哪些技能了：
- 逆向（大量，一方面是固件逆向，一方面针对协议也需）
- 嵌入式知识（主要针对ECU）
- 车载总线
- 无线电安全（围绕V2X）
- 数据安全（最好有所了解，牵扯很多认证相关的问题）
- 移动安全（毕竟车机≈大手机）
- 渗透（主要针对云服务）
后记
本篇其实更多是对车联网安全学习的笔记，以笔者对车联网粗浅的理解对各部分作安全视角的认识。之所以想了解车联网，想了解这种“大号手机”的安全问题，是觉得未来大型设备的联网是必然，安全问题也必然随之而来，从车开始研究会比较容易扩散。譬如我们研究汽车的CAN总线问题，后期代入小型飞机的CAN总线问题就非常自然，想想如果能拿下能上天的大家伙，如何一种黑客的浪漫。
路漫漫其修远兮，个中谬误和缺失还望读者不吝赐教，多谢。
参考
《汽车黑客大曝光》
2020 MOSEC BaijiuCon Sky-team talk slipper师傅直播录屏