原创:整车时钟同步系统的功能安全与信息安全融合设计
无论是在 ISO26262 标准中，还是在 ISO21434 标准中，都在讨论两个概念应该充分的沟通和协同，因为功能安全的需求和信息安全的需求和目标可能并不一致却相互影响。例如：增加一个内容的信息安全性往往需要对来源进行身份认证和完整性认证，但复杂的加密算法会增加处理过程中的时延，对功能的实时性和故障诊断周期间隔带来很大的影响；此外，如果识别到一个功能安全相关的功能所面临的信息安全威胁没有采取妥善的处置措施，其暴露率和可控性可能会因为外部攻击者的影响而变化。另一方面，由于功能安全和信息安全所依据的理论知识体系并不相同，在企业中往往是由不同的团队独立处理的，组织模式的原因也可能会人为造成二者之间的信息差和内容违背。
所以，在一直以来，有很多的管理人员都希望功能安全和信息安全在管理和设计、分析方法上可以充分融合。
在中文表达里“安全”这个词的表达囊括了众多概念，特别是在电子电控产品开发过程中的多项安全领域中，功能安全、信息安全、数据安全、系统安全等概念相互耦合和影响。如果能将安全统筹和有效协同，可以减少工作中的重复投入和信息差。毕竟在当前行业的大环境下，资源的协同整合和降本始终是一个绕不开的话题。
但如何融合好这些标准的要求，达到降本增效的目的，对于相关的从业人员提出了较高的要求，比如：在概念阶段的安全分析中能否综合考虑更多方面的要求和设计环节上对彼此相互的影响，将一部分评估和证明共享，最好，还能够在系统架构要上是一致的和共用的，来减少架构复杂性和开发成本。
对于概念阶段的融合，目前，有很多尝试将 HARA 过程和 TARA 过程融合的方法，例如：《Complying with ISO 26262 and ISO/SAE 21434: A Safety and Security Co-Analysis Method for Intelligent Connected Vehicle 》这篇文章中就介绍和对比了很多不同的安全分析方法。
不同的安全分析方法对比
但今天的主题并不想过多的讨论分析方法，因为分析的方法可能需要首先满足不同的组织内部实际的运行情况和特点，所以我想把关注点先放在安全分析之前，即一切的起点——相关项定义活动。
因为一切分析的关键都是首先明确出这个功能想做什么？受众是谁？在什么系统条件和环境下？系统边界在哪里？如果前期定义的场景不充分或者不正确，后面在利用安全分析进行安全需求导出都会有错误或与实际的安全期望之间偏差。
我尝试以最近做过的一个关于的项目为例，来尝试对上述想法展开论述：
在这个项目中我们需要是提供一个安全的时钟同步系统，但开始阶段只需要对时钟同步功能进行分析，不用关心具体是实施协议，首先需要的是了解使用场景，即整车时间同步协议栈可能被用于同步什么样的时钟基准，以及总共需要有几个时钟基准在车内被使用？
于是，可以首先尽可能罗列当前和一定时间内，车载环境下可能的对于时钟基准有依赖的相关场景，例如：
用户体验相关的业务：
1. 用于用户时钟显示：为了车辆乘客可以方便的观察和掌握时间，整车仪表盘，娱乐屛上通常会显示车辆当地的时间，时钟显示功能通常可以通过车辆的设置菜单进行调节，一般还需要包括时间格式（12 小时制或 24 小时制）、时区、夏令时等选项。
2. 用于车端任务的预约和编排：可以参考时间来进行未来一个时间段任务的预约设定进行任务离线配置，解决无网络的环境下的任务执行。
内部开发和维护的需要：
1. 用于传感器采样数据或者任务调度时基对齐：数据收集和融合的过程中需要保证数据基于同样一个时间基准，以保证不同传感器采集的数据能够正确的对齐和匹配，提高数据的质量和可行度，另外，在中央集中式电子电气架构发展的趋势下，由于功能的重新分配，边缘测的区域控制器更多可能仅执行采集和执行动作，大量逻辑分离和上移导致功能执行的不一致性和误差，需要倚靠统一的时钟基准进行相互协同。
2. 用于车辆内部通讯消息的新鲜度参考：为了解决车内敏感数据通讯信息认证和完整性保护的问题，通常需要在信息中增加消息认证码（MAC）及数据新鲜度（freshness value），具备单调递增特性且不会因别的因素影响抖动的一种全局统一参考。
3. 用于评估自动驾驶系统安全性：自动驾驶系统稳定性和安全性的评估和衡量需要以系统无安全事件的运营时间为度量，目前正在准备的有条件自动系统的工作草案以累计运行无危害事件的时间，作为有条件自动驾驶系统的残余风险接收准则。
售后和持续运营的需要：
1. 用于软件日志的记录：软件模块输出的状态日志。这些日志附带时间戳，时间戳最好可以和现实时间相同，方便问题排查。
2. 用于电子电控单元产生故障冻结帧：故障冻结帧会根据预设逻辑将整车相关的状态数据、故障发生次数和故障发生时间进行持久化保存，并支持使用标准诊断命令进行读出，冻结帧数据的读取可以帮助维修人员快速找出故障的原因和位置，节省维修时间和成本。
3. 用于整车维护和维修：预测车辆的维护需求，比如通知客户更换易耗品（雨刮、机油、滤清器等），以确保车辆性能和延长使用寿命。部分易损件，例如：蓄电池、橡胶、空调滤清器等更换可能需要以时间为参考进行，而与车辆行驶的距离无关。
4. 用于车辆保险和二手车定价，车辆的使用频率可能是一个重要的参考因素。
城市管理和环境保护的需要：
1. 用于评估车辆对环境的影响，运行时间可以作为传统燃油车辆计算排放量的一个参数，尤其是在怠速或低速运行时，这些情况下排放量与时间的相关性可能更高。
2. 用于评估车辆对道路的使用频率，交通规划和管理更关注车辆在道路上的占用时间和运行模式，这与车辆的累计运行时间直接相关，而与行驶的具体距离关系不大，可以给城市管理者更科学的管理城市拥堵的方案。
从上述整理的使用场景，我们很容易对车内使用的时钟基准进行特征总结，车内时钟基准可归纳为以下类型：
1. 一类可以称之为整车业务时间：整车中一般需要基于高精度时间源（外部网络）获取，获取为 UTC 时间，可以附带用户时区信息，和用户现实时间（墙上时钟）相同，它是一种绝对时间，当时钟出现偏差时，可以进行一定程度上的调整，目的是使用户更好的理解和参考，为了更快的获取这种时间信息，可以设置多个时钟源同时作用（例如：GNSS、NITZ、NTP 等），不同时钟源之间的切换策略需要考虑用户的观感和相关业务的影响，负责同步这种时钟的主系统需要具备单独的供电回路或备用电池，应该能够在主系统断电时持续计时。
2. 第二类可以称之为整车累计运行时间：由负责时钟同步主时钟系统进入工作模式时开始计时，主时钟系统休眠时停止并进行持久化存储，不会在下次车辆启动时从零时开始，用于表明车辆的累计运行时间，它是一种相对时间，需要保持相对稳定，即使出现累计误差也不要进行调整和变化。
3. 最后一类可以称之为整车系统时间：它和整车累计运行时间基本相同，主要区别是主时钟系统休眠时停止并不会进行持久化存储，下次车辆启动时从零时开始。
由于整车累计运行时间和整车系统时间的高度一致性，很自然的可以发现这二者可以统一为整车累计运行时间的时间基准，那么整车业务时间的时间基准能否统一整车累计运行时间呢？不建议这么做，因为整车业务时间的时间基准为了精度需要使用 GNSS 和网络时钟信号（NITZ、NTP 等），它们作为整车授时源存在以下问题：
1. GNSS 时钟源的获取时间相对较长，常规冷启动要经过搜星、捕获、跟踪、解码、伪距测量和定位计算几个过程，整个过程至少需要 30 秒~1 分钟左右时间。常规做法是混合加入一些本地时间源和网络时间源进行动态选择，以加快定位前的时间获取，但是不同时间源之间的切换又会带来时钟基准的变化。
2. GNSS 时钟源稳定性容易受到射频信号中断和干扰，例如：驶入地下停车场或行驶在高架桥下、高大的建筑物旁导致卫星信号被反射等多径效应场景，导致通过 GNSS 时钟源进行的授时产生中断或者跳变。
3. GNSS 时钟源的精度有限制，GNSS 时钟来源于接收机中同步脉冲信号 PPS，虽然精度可以到纳秒级，没有累计误差，但 GNSS 接收机对外输出格式为按照整秒数上升沿更新作为标准 UTC 时间，意味着整车网络同步时时钟精度为秒。如有业务依赖更小单位进行数据融合，则可能无法满足要求。
所以当需要同步的时钟基准和使用场景、特点都被明确，相关项定义工作也就完成了，这一点非常的重要，因为大量离散的场景被抽象、汇聚为两种时钟基准（整车运行时间和整车业务时间），大大简化了后续的设计和分析工作。
我们可以发现无论同步的是哪种时钟基准，功能的目的都是在车内统一时钟基准，所以，其 High level 的安全需求是可以统一的（防止偏差的时钟基准被采用），证明其核心设计应该可以进行统一，但需要注意到的是，不同场景下的信息安全和信息安全严格程度和容忍偏差可能是不同的（参考下图的示意）。
不同时钟使用场景下的时钟容忍偏差（示意）
可以看到，上述罗列的大部分的使用场景下，无论是在功能安全方面还是信息安全方面，都可以接受比较大的时钟偏差（圈中的相关的场景下的时钟基准），甚至没有相关的要求，但在几个关键的场景下，时钟基准的对于偏差的接受程度具有非常严格的要求，在不同的损失场景下（可能由系统性失效、随机硬件失效和外部攻击造成）也是不同的，所以后续我们也需要针对性的考虑在系统设计中。另外，不同时钟基准的需求特征是不同的，时钟的获取、存储和同步策略应该有针对性的进行考量。
另外，我们可能要从车辆拓扑架构出发，分析可能的整车时钟同步系统使用和部署情况，根据未来中央集中式电子架构的发展趋势，中央计算单元和区域控制器之间将通过以太网高速连接，而区域控制器（或整车接口控制器）和其他区域内控制器或智能执行器的连接方式出于成本考虑可能仍使用低速网络，比如 CAN。所以整车时钟基准可能存在多级授时，即：
· 第一级授时：内外部时钟源将时间基准授予整车中的时钟主节点。
· 第二级授时：整车中的时钟主节点将时间基准授予区域网络上的时钟主节点（相对于区域网络来说是仍然是区域主时钟节点）。
· 第三级授时是指区域主时钟节点将时间基准授予区域网络上的时钟从节点。
时间拓扑系统中还会有桥接节点（switch）连接不同网段来转发时间数据包，但是这些桥接节点的时间同步功能往往是高度定制的，很难在其之上进行二次开发，叠加和分配相关的安全需求。
每级授时的协议可能不同，例如在以太网上进行时间同步的协议标准主要是 802.1as，也就是 gPTP 协议，而 CAN 网络上大部分可能会使用的是 AUTOSAR 标准和 STBM 模块，所以需要有节点充当时间网关的角色（例如区域控制器）进行协议转换，但在不同层级进行传输和协议转换后仍要确保路径网络上的时间基准的功能安全完整性和信息安全完整性。
接下来，需要进行整车时钟同步系统的 HARA 和 TARA，安全分析的过程此处省略，我们可以得出以下整车时钟同步系统的安全需求，安全需求应该能够覆盖功能的失效模式和受攻击模式。
功能安全方面：
1. 负责同步时钟的主节点应该具备故障检测和合理性检测能力：主节点被唤醒后，需要进行业务时钟初始化，检查内部时钟相关的硬件的故障状态和可信度（例如：晶振错误、系统时钟发生卡滞、频率超限、锁相环时钟丢失（由于时钟抖动）、时钟监控机制失效等），另外对于时钟基准的合理性也需要结合上下文进行判断。
2. 当主节点运行期间，也需要按照一定的周期进行硬件故障诊断，当确定硬件故障成熟或时间明显不可信时，需要转到安全状态，例如发送显性的故障标记，让相关安全的功能推出或降级。如果功能由失效可运行的要求，那么还需要考虑冗余。
3. 如果有冗余的时钟主节点，冗余的节点应该能够保持时刻的高可用和热备状态，保证从切换后时钟偏差在允许的范围内，以防止功能异常。
4. 整车时钟系统应该具备通讯完整性的保护和校验机制：使用时钟同步协议同步整车时钟系统，其本质还是在网络上传递时间戳信息，因此，也需要具备传输过程的保护和校验机制。
信息安全方面：
1. 整车时钟系统的报文应该具备防篡改机制：为了防止攻击者截获并修改业务时钟同步报文，进行数据包操纵攻击，修改整车时钟基准，整车时钟系统应该具备协议数据包完整性校验机制。
2. 整车时钟系统应该具备时钟源身份认证和授权机制，防止中间人攻击，包括将合法数据包拦截和删除：攻击者可以通过成为时钟同步系统中的一个合法参与节点，当攻击者拦截并丢弃协议数据包时，就会导致数据包拦截和删除攻击，从而阻止目标节点接收部分或全部协议数据包。
3. 整车时钟系统应该能够防止时间同步数据包延迟攻击:攻击者没有直接拦截和删除合法数据包，而是人为的为数据包添加延迟，使用基于欺骗消息的协议数据包响应合法时钟，由于时钟基准本身是错误的或时钟的延迟计算是基于错误信息，可以间接影响其他系统的时钟基准。
4. 整车时钟系统报文应该具备防重放机制：为了防止攻击者录制和重放攻击实现针对业务时钟同步报文重放，修改整车业务时钟基准，整车业务时钟应该具备协议数据包新鲜性的校验机制。
5. 整车时钟系统应该能够防止肉鸽攻击，操作目标合法节点成为时钟同步系统的主时钟进而影响同步。和第二条类似，但这次攻击者是之间操作了合法的时钟参与节点。
6. 整车时钟系统应该能够防止一定程度的泛洪攻击和加密性能攻击：攻击者传输虚假协议数据包，导致接收方的计算压力和加密引擎利用率很高。通过这种攻击，可能导致整车时钟系统的可用性下降。
7. 整车时钟系统应该能够防护针对于外部特定时间源的欺骗攻击：时间源攻击针对的是时钟主节点的使用时间源的攻击，特别是对整车业务时钟来说很多时钟源也是来自与自车之外的远程通信信号。例如，如果时钟主节点使用基于 GPS 的时钟作为其参考时钟源，攻击者可以干扰 GPS 信号的接收，或发送类似于 GPS 卫星的导航信号（常见的方式是录制并重放导航电文），从而导致时钟主节点使用错误的参考时间。
8. 整车时钟系统的关键信息的宜结合外部措施或态势感知系统进行监控：可以基于预定义的触发器或定期向车辆制造商私有云平台或态势感知平台来同步车辆关键信息，基于此信息的收集和诊断可以判断车辆的时间基准是否遭受人为攻击，作为信息安全事件响应的输入。
最后，更重要的是让安全的时钟同步可以支撑更多的车载场景，让其可落地，因此：
1. 对整车时钟系统采取的安全保护措施不应该明显降低时钟同步的性能。无论我们采取何种安全措施和机制、其设计必须确保不会显著降低时间传输的质量，尤其是对精度和性能更加敏感的整车累计运行时间基准，为了保障传输质量和性能，我们必须考虑使用桥接节点，另一方面，我们可能倾向于选择异步的故障判断机制而非同步阻塞的机制。
2. 我们采取的安全措施和机制设计必须考虑到桥接节点的接入和影响，为了具备广泛的适用性，不能分配安全要求到桥接节点上，但又因为桥接节点在第一条中是必然存在的，所以安全机制和设计必须要覆盖在桥接节点处造成的失效场景并添加到攻击路径中。
整车时钟系统的安全模型可以简单表示为下图
整车时钟同步系统的安全模型
之后，我们可以从分析得到的安全需求中得出我们需要实现的技术需求，例如：
1. 整车时钟同步系统应该具备初始化过程，即在整车主节点进行时钟同步前，应该进行时间相关的硬件要素和外设的故障自检、时钟源可信度检查，并利用证书链确认系统中各节点的身份合法性。
2. 由于时钟同步报文在网络中被传输，可能由于通讯传输故障和干扰、以及恶意攻击造成完整性缺失。
3. 由于时钟同步报文经过桥接节点，可能由于桥接节点硬件或软件故障或外部恶意攻击造成完整性缺失。
4. 时钟同步报文可能会由于时钟从节点是硬件或软件故障或外部恶意攻击造成完整性缺失。
5. 时钟系统的身份由配置静态的生成，而不经过动态的选取。
6. 整车业务时钟系统的主节点需要在休眠前进行时钟的持久化存储，并维持计时。
7. 整车累计运行时钟的主节点需要冗余部署，以两个独立的时钟域进行同步。
8. 整车累计运行时钟的时钟主节点和通用时钟主节点（冗余部署的）的时间基准应该周期性对齐以消除累计误差。
我想法是，在时钟主节点和同步节点，我们可以设置一个公共的软件模块，它内含了功能安全和信息安全的安全机制，但是，最后的约束是一个显著的麻烦，由于桥接节点的存在和广泛适用性的考虑，很难在时钟同步协议本身的基础上进行修改和增加相关的要求，使得蓝色虚线框中的安全性得到增强。
因此，我在这里想到的方法是通过使用功能安全的安全分解和类 EGAS 安全架构的概念来处理这个问题，将这个功能安全概念产生一些变化，使用一条冗余通道对原本的输出进行监控，如下图所示：
整车时钟系统功能安全概念
冗余的通道由时钟安全模块从应用层发出，可以将功能安全机制和信息安全机制做进此模块，并且按照流程进行开发，以符合 ISO26262 和 ISO21434 的标准符合性。在接收端（从节点）也由对应的时钟同步的监控模块利用此时钟同步时间去校验本地时间，分析其中的偏差，来分析其发生故障和发生攻击事件的可能性，当偏差值超过设置的阈值，时钟从节点可以进入安全状态，以保障时钟同步功能的完整性。
那么，有了这条冗余的应用层时钟同步通道，通讯传输过程的信息安全的安全机制（例如 MAC 认证）也可以绕开桥接节点实施了。需要注意的是，由概念阶段我们在进行场景分析的时候我们已经了解了，每个时钟基准能够忍受的攻击时间窗口和故障容忍时间是不同的，因此我们应该分别设置时间窗口的阈值，整体上来说，整车累计运行时间基准的功能安全和信息安全偏差阈值远远小于整车业务时间。
这样的话，从节点可以分别判断功能是否进入功能安全保护状态（FUSA Protection Status）或信息安全保护状态（CS Protection Status），例如：停止接收时钟同步消息，采用自身系统时间维持计时，同时，出于安全预警的考虑，可以触发信息安全事件的 trigger 到 VSOC 平台。
此外，由于对比的参考报文相对于时钟同步来说是完全独立的，因此时钟同步协议本身的性能并不会收到影响，因此我们满足了关于时钟同步性能的限制条件。
当然，只在冗余路径施加安全机制并没有解决所有的功能安全和信息安全问题，由于主路径没有安全覆盖，导致系统时间的修改可能会先于比较机制作用前发生，特别是系统的时间有可能已经被攻击，导致上层依赖时间同步应用的功能完整性受到损伤，所以应该综合其他的措施。
总结：
基于场景进行了相关项的定义和分析，提出了一种通用于车内各系统及车云之间时钟相关的协同系统架构，这种架构可以形成网络中所有节点时钟同步标准化模块，能够提供面向多类型时钟能够快速集成，能够进行快速配置。另一方面，满足于功能安全要求和信息安全要求的整车时钟基准，又可以作为其他功能安全要求的基础设施，例如全局性软件执行时序或者全局的新鲜度管理器。
参考引用文章
·《Complying with ISO 26262 and ISO/SAE 21434: A Safety and Security Co-Analysis Method for Intelligent Connected Vehicle 》
·《IEEE 1588 2019》
·《AUTOSAR_FO_RS_TIMESYNC R23-11》
·《RFC 7384 Time Protocol Security Requirements 2014 Oct.》
END
作者：朱震海
文章来源：sasetech
推荐阅读
更多物联网安全，PSA 等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA 技术交流群，请备注研究方向。
