本文主要介绍 EVITA 方案构根据需求与应用情况构建的不同用例与对应场景（用例17至用例18），并对该部分用例与用例说明进行总结。
本文来自实验室龚思陈、孙伊凡的学习笔记
3.18 Use Case 17 – Diagnosis｜Remote Flashing
3.18.1 描述
3.18.1.1 概述
-
背景：诊断的结果可能是需要更新ECU的软件版本以消除bug提高功能性，当时处理的方法是通过电缆来更新
-
目的：无线更新ECU
-
主要流程：
-
服务中心首先使用互联网或无线局域网与车内网络建立连接
通过CU向动力系统内的ECU发送连接请求
-
请求完整性得到认证、服务中心身份认证后，发送连接响应，共享会话密钥，建立安全信道
-
对车进行诊断，获取 ECU类型，固件版本，上次更新日期等必要版本信息开始更新会话
-
更新工具发送请求，要求开始 ECU层面的编程会话
-
编程会话开启
-
更新工具向ECU的RAM发送加经过加密的新软件版本过程中 CU 始终在ECU层面检查每一条消息的完整性、可验证性、新鲜性软件在 ROM 中被更新 ，日期会被记录
-
更新工具 结束ECU层面的编程会话，断开与车辆的连接
3.18.1.2 通讯实体与关系
3.18.2 场景
3.18.3 需求
3.18.3.1 功能需求
-
诊断工具：移动功能
-
车内CU：
-
检查RSU和诊断工具的身份
-
发送、接收外部请求
-
检查数据完整性与数据新鲜性
-
可靠的传输
3.18.3.2 技术需求
-
通讯类型：互联网，无线局域网
-
通讯范围：当下最先进
-
通讯时延取决于通讯范围
-
ECU有足够的内存：48 bytes （考虑AES-128 bit，ECC-256 bit）
3.18.4 安全方面
-
可认证性：车辆需要验证 RSU 和 诊断工具是否允许与车辆交互
-
数据完整性：防止误诊；保证更新完成
-
数据新鲜性
-
不可抵赖性：防止服务中心推卸责任
-
机密性：用于复制保护，防止重新设计，保护专有技术
-
匿名性：防止窃听者监听获得车主的隐私消息
3.19 Use Case 18 – Diagnosis｜Flashing per OBD
3.19.1 描述
3.19.1.1 概述
-
主要流程
-
车主将车移至服务中心
-
ECU 初始化软件并且开始诊断函数，调用诊断（默认模式下的）服务器
-
服务中心人员将电缆插入诊断连接接头，使诊断工具与车内诊断接口连接
-
通讯单元向ECU发送诊断请求
-
ECU认证诊断工具并检验数据完整性
-
编程会话开始
-
服务中心人员从核实ECU种类与固件版本开始诊断，判断是和否需要更新
-
诊断工具向ECU发送加密过的新固件包，存储在 ECU 的 RAM 中新固件在ECU层面被解密，在 ROM packet wise 中刷新，更新日期写入ECU
-
向 ECU 发送 EcuResset 请求后，编程会话结束
3.19.1.2 通讯实体与关系
3.19.2 场景
3.19.3 需求
3.19.3.1 功能需求
-
车内通讯单元
-
核实 RSU/诊断工具 的身份
-
检查数据完整性
-
发送、接收外部请求
-
通讯可靠性
3.19.3.2 技术需求
-
通讯类型：flash cable connection
-
通讯范围：电缆长度决定
-
车辆内置 OBD
3.19.4 安全方面
-
可认证性：防止恶意代码对车载系统的损害
-
机密性：保护 ECU 更新软件的专有知识
-
保护数据完整性：更新的软件在运行前未被篡改
-
新鲜性：防止重放攻击
-
不可抵赖性：防止服务中心推卸责任
4 总结与展望
4.1 总结
车载网络的主要特征：
-
当下安全系统通常使用对不同信号的周期性检查来检测故障
-
只有通信不限于车载网络的情况下，才会使用安全措施（例如，诊断，软件更新，电子缴费）
-
车载网络，尤其是用于动力总成、底盘安全领域的，旨在满足“硬”实时需求。它的带宽有限，但是响应时间非常短。
4.2 展望
将来的安全考量：
-
防止对车载系统的基础设施的非法篡改，以确保内部安全关键系统不受影响；车辆不会发送虚假信息；必须防止、检测和遏制对系统的攻击。
-
防止、检测或遏制外部通信基础设施受到攻击，保护通信实体的私密性；能够正确识别，并消除注入（无线）通信基础设施中的虚假消息对电子安全应用产生的影响。
原文始发于微信公众号（轩辕实验室）：欧盟EVITA项目预研 第二章（六）
