电子电子架构——AUTOSAR信息安全机制有哪些（上）
我是穿拖鞋的汉子，魔都中坚持长期主义的工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
人们会在生活中不断攻击你。他们的主要武器是向你灌输对自己的怀疑：你的价值、你的能力、你的潜力。他们往往会将此伪装成客观意见，但无一例外的是，他们想让你怀疑自己。
本文主要讲述如下内容，介绍电子电气架构中汽车以太网诊断路由汇总：
-> 1、SecOC应用
-> 2、TLS医用
-> 3、IPsec应用
随着汽车网联化和智能化不断发展，汽车不再孤立存在，越来越多地融入到互联网中。在这同时，汽车也慢慢成为潜在的网络攻击目标，汽车的网络安全已成为汽车安全的基础，受到越来越多的关注和重视。
AUTOSAR作为目前全球范围普遍认可的汽车嵌入式软件架构，已经集成的相关信息安全模块对实现信息安全需求有着充分的支持，例如保护车内通信或保护机密数据。由于CP AUTOSAR 和AP AUTOSAR 的体系结构不同，目前信息安全模块的相关技术实现也存在差异。
本文对于信息安全模块做一个简单梳理汇总：
一、SecOC应用
在车载网络中，车载CAN总线作为常用的通讯总线，其大部分数据是以明文方式广播发送且无认证接收，这种方案具有低成本、高性能的优势。在以往车辆作为独立个体，没有远程控制风险的年头是可以存在的。但是随着汽车网联化、智能化的业务需要，数据安全性越来越被重视。
传统的针对报文添加Rolling Counter 和Checksum信息的方法，实现的安全性十分有限，也容易被逆向破解，进而可以伪造报文控制车辆。
因此SecOC应运而生，其是在AUTOSAR软件包中添加的信息安全组件，主要增加了加解密运算、密钥管理、新鲜值管理和分发等一系列的功能和新要求。
该模块的主要作用是为总线上传输的数据提供身份验证，它可以有效地检测出数据回放、欺骗以及篡改等攻击。
上图消息认证和新鲜度验证流程
在SecOC模块标准中，AUTOSAR主要基于MAC的身份验证和Freshness的防重放攻击，来实现数据的真实性和完整性校验。首先Message Authentication Code是保障信息完整性和认证的密码学方法之一，其中CMAC（Cipher based MAC）一般用于对称加密，整车厂可在车辆下线刷写程序时静态分配密钥，也可选择使用云端服务器动态地给车辆分配密钥）是车载总线加密认证常用方案。MAC 的作用不是防止有效数据被泄露，而是为了保护数据不会被攻击方篡改，即完成数据来源的认证。如需保护通信数据不被攻击方监听，则报文的有效数据还需要进行额外的加密。
为了降低重复攻击的风险，则需要在Secured I-PDU中加入新鲜度值，Freshness Value是一个根据一定逻辑不断更新的数值，Freshness Value 的更新方法多种多样，AUTOSAR 标准将基于计数器或基于时间的新鲜度值作为典型选项。
在CP AUTOSAR 平台，SecOC 模块依赖于PduR的API和功能，提供了PDU Router所需的上下两层API（upper and lower layer API）功能。依赖于由CSM 模块在AUTOSAR 中提供的加密算法。SecOC模块需要API 函数来生成和验证加密签名（Cryptographic Signatures）或消息验证码（Message Authentication Codes）。为RTE 提供具有管理功能的API 作为服务接口进行调用。
SecOC 通信协议特性同样适用于AP AUTOSAR 平台标准中，其主要目标是实现与CP AUTOSAR平台SecOC 功能互操作性，尤其适用于使用 UDP 多播的消息场景（SecOC 是目前唯一支持的协议）和与CP AUTOSAR 之间基于信号的网络绑定的安全通信场景。
AP AUTOSAR通信管理中的SecOC
为了实现与CP AUTOSAR 平台的互操作性，SecOC同样应用于Adaptive CM中。认证信息包括认证器（例如，消息认证码）和可选的新鲜度值。为了保持与CP AUTOSAR 平台的互操作性并提供可选的新鲜度值管理功能，AP AUTOSAR CM 将依赖于可插入的新鲜度值管理库。该库将提供新鲜度值管理相关的API，包含CP AUTOSAR 平台关于Freshness Management 客户端、服务端接口的副本以及调用定义的相关功能。
SecOC 的核心思想在于通信认证，但是不涉及报文加密。虽然伪造报文的难度已经大大提升了，但是在通信过程中采用明文传输，依旧有一定的风险；认证信息的强度和信息长度相关，通信认证方案会加大报文负载（传统CAN 报文的负载只用8-64 个字节），从而导致负载率提升，通信实时性下降，可能使得正常功能受到影响，应考虑信息安全强度与通信实时性的相互平衡；MAC 技术应考虑对称密钥的管理和共享的问题，目前大部分MCU 是没有安全功能的，对称密钥也是明文保存在系统或者内存中。共享该密钥时采用明文通信，这是非常不安全的。但MCU 的计算能力和存储空间是有限的，采用了安全机制以后，必然占用很大的资源消耗，应充分考虑系统的稳定性，以保障业务与安全机制能够正常运行；SecOC 用于保证安全通信，必然涉及密钥（key）的管理，应考虑灌装、更新和维护该key, 同时还需考虑换件后key 的一致性。
二、TLS
TLS（Transport Layer Security）作为传输层的中坚力量，可以支撑上层的SOME/IP、MQTT 和HTTP 等协议。不但可以用于V2X的安全通讯，也可以用于车内通讯节点之间的安全通讯。当然像T-BOX等可以与车外节点通讯的节点来说，其安全性要求更高，可以应用更加完整的广义TLS，既安全，又灵活。而车内之间一般IP地址、端口、服务接口等都固定，安全性要求也不如T-BOX 高，则可以应用广义TLS中的预共享密钥（TLS_PSK）等套件，既高效，又稳定。
TLS 属于工作在传输层的协议，它介于传输层底层协议和上层应用协议之间。而以太网的传输层主要有两大底层协议：TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。二者各有特点，互为补充。不管在传统互联网上，还是车载以太网上，两者都是常见的传输层底层协议。不同的传输层底层协议实际上对应着不同的传输层安全保护协议，采用TCP 传输的，就用TLS 保护。采用UDP 传输的，就用DTLS 保护。DTLS 的全称是Datagram Transport Layer Security，比TLS 多出来的“D” ，指的就是UDP 中的“D” 。TLS 和DTLS 各有不同的版本，目前主流支持的还是1.2 和1.3版本。
AUTOSAR 标准基于Ethernet 架构同时提供了ISO DoIP的解决方案。DoIP 全称是Diagnostic Over IP，顾名思义就是基于IP 的诊断。DoIP 具有处理大量数据、节省重编程时间、方便接入IT 设施、标准通信灵活使用等优势。普通的DoIP 是基于TCP 进行诊断通信，在ISO 13400-2 2019 版本中定义了安全的DoIP 会话，即基于TLS 进行诊断通信。
DoIP server协议栈会根据DoIP client 实体的请求，确定使用TCP 还是TLS 进行诊断信息的传输。TLS 允许在Client DoIP 实体和Server DoIP 实体之间建立经过身份认证和加密的通信通道，Client DoIP实体身份的验证可以在诊断应用层中实现，例如ISO 14229 中定义的0x29 服务。
TLS 技术仍有自身的技术局限性。大部分控制器都是采用了MCU，计算能力和存储空间都是有限的，采用了安全机制，例如加解密算法、消息摘要算法、签名验签算法等，必然占用很大的资源消耗，应考虑在不影响正常功能的情况下安全策略能够正常实施。SSL/TLS 采用安全认证的方式来识别对方身份，需要提前灌装安全证书，如果控制器进行换件，应保证证书的一致性，让新的控制器能够进行身份的合法验证，从而正常通信。在实际应用场景中，大部分控制器可能没有安全存储环境（SE 或者HSM 等），应考虑保证证书和私钥的安全存储。在采用TLS 进行安全认证通信中，必然会降低通信的效率，应考虑通信的实时性。安全技术应用的同时会带来一些资源消耗，产生一定的局限性。应当在满足汽车信息安全相关法规标准的原则下，技术手段在不影响控制器正常运行的前提下，进行方案选型完成集成部署，如果内部安全通信技术手段消耗过多的控制器资源并影响了正常业务运行，应适当降低安全等级，必须同时兼顾控制器运行和内部安全通信。
随着汽车网联化的发展，以太网通讯已经在车内通讯及车联网普及，TLS 和DTLS 也更多地出现在汽车行业的视野里。AUTOSAR 在CP 和AP 中也加入了TLS 和DTLS 的规范。从AUTOSAR CP 4.4 标准开始就明确了支持1.2 和1.3 版本，优先选择1.3 版本。AP R21-11 中只描述了1.2 版本，但相信将来版本也会加上1.3 版本。
三、IPsec
IPsec（Internet Protocol Security）是网络安全协议，运行在OSI 模型的第三层（Internet Protocol，IP 层），在VPN（Virtual Private Network）应用很广泛。IPsec 在IP 层对报文提供数据机密性、数据完整性、数据来源认证、防重放等安全服务，定义了如何在IP 数据包中增加字段来保证IP 包的完整性、私有性和真实性，以及如何加密数据包。
