AUTOSAR信息安全框架和关键技术分析

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

随着汽车网联化和智能化，汽车不再孤立，越来越多地融入到互联网中。在这同时，汽车也慢慢成为潜在的网络攻击目标，汽车的网络安全已成为汽车安全的基础，受到越来越多的关注和重视。AUTOSAR作为目前全球范围普遍认可的汽车嵌入式软件架构，已经集成的相关信息安全模块对实现信息安全需求有着充分的支持，例如保护车内通信或保护机密数据。由于CP AUTOSAR 和AP AUTOSAR 的体系结构不同，目前信息安全模块的相关技术实现也存在差异。

在车载网络中，CAN 总线作为常用的通讯总线之一，其大部分数据是以明文方式广播发送且无认证接收，这种方案具有低成本、高性能的优势。但是随着汽车网联化、智能化的业务需要，数据安全性越来越被重视。传统的针对报文添加RollingCounter 和 Checksum 信息的方法，实现的安全性十分有限，也容易被逆向破解，进而可以伪造报文控制车辆。

SecOC 是在AUTOSAR 软件包中添加的信息安全组件，主要增加了加解密运算、密钥管理、新鲜值管理和分发等一系列的功能和新要求。该模块的主要作用是为总线上传输的数据提供身份验证，它可以有效地检测出数据回放、欺骗以及篡改等攻击。

图4.1-1消息认证和新鲜度验证流程

在SecOC 标准中，AUTOSAR 主要基于MAC 的身份验证和Freshness 的防重放攻击，来实现数据的真实性和完整性校验。首先MAC（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 之间基于信号的网络绑定的安全通信场景。

图4.1-2 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（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（Internet Protocol Security）是网络安全协议，运行在OSI 模型的第三层（Internet Protocol，IP 层），在VPN（Virtual Private Network）应用很广泛。IPsec 在IP 层对报文提供数据机密性、数据完整性、数据来源认证、防重放等安全服务，定义了如何在IP 数据包中增加字段来保证IP 包的完整性、私有性和真实性，以及如何加密数据包。

图4.1-3 IPsec协议及组件功能

IPsec 提供了两种安全机制：认证和加密。认证机制使IP 通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。加密机制通过对数据进行加密运算来保证数据的机密性，以防数据在传输过程中被窃听。

IPsec 的安全体系由验证头协议（Authentication Header，AH）、安全封装协议（Encapsulating Security Payload ，ESP）及安全联盟（Security Association，SA）三部分组成。AH 是认证头协议（IP 协议号为51），主要提供的功能有数据源验证、数据完整性校验和防报文重放功能，可选择的散列算法有MD5（Message Digest ），SHA1（Secure Hash Algorithm）等。ESP 是报文安全封装协议（IP 协议号为50），ESP 将需要保护的用户数据进行加密后再封装到IP 包中，验证数据的完整性、真实性和私有性。可选择的加密算法有DES，3DES，AES 等。SA（Security Association）是IPsec 的基础，也是IPsec的本质，IPsec 对数据流提供的安全服务通过SA 来实现，它包括协议、算法、密钥等内容。IPsec 有隧道（tunnel）和传输（transport）两种运行模式，运行模式和安全体系中的AH 及ESP 组合形成4 种情况：隧道模式+AH、隧道模式+ESP、传输模式+AH 以及传输模式+ESP。

AUTOSAR CP R19-11 标准在TCP/IP 模块加入IPsec 相关功能介绍，并对功能实现进行了条件约束，目前只支持IPsec 运输运行模式，隧道运行模式、IPv6 和多点传播都暂不支持。并规定了其他模块可执行的操作内容，KeyM 模块可为IPsec 子模块提供证书处理，CSM 允许执行IPsec 子模块所使用的加密作业和密钥操作。

AUTOSAR AP 中IPsec 协议实施的目标是在车载IP 网络中提供安全的通信通道。在 AUTOSAR 自适应平台中实施IPsec 将为网络节点之间的通信提供保密性、完整性或两者兼备的选项。IPsec 作为标准网络安全协议提供了安全通信的手段，同时支持多供应商堆栈互操作性。自适应平台没有为电子控制单元指定任何操作系统，因此是IPsec 功能最好的实践方式。

为了汽车软件提供统一的安全加密/ 解密接口，AUTOSAR 在4.3 版本推出Crypto Stack 模块。Crypto Stack 是AUTOSAR 架构体系中负责数据加密保护和密钥管理的模块，由Crypto Service Manager,Crypto Interface, Crypto Driver 三个部分组成，为应用程序和系统服务提供了标准化的密码服务接口。密码服务可以是哈希计算，非对称签名验证，对称加密等。其主要应用于ECU 通信加密、SecurityAccess 流程保护和KEY 的管理等使用场景。

CSM(Crypto Service Manager）是加密服务管理器，位于AUTOSAR 的SYS 模块最高层的服务层。服务层是基础软件的最高层，它的任务是为应用软件和基本软件模块提供基本服务，即为应用软件和基本软件模块提供最相关的功能。CSM 基于一个依赖于软件库或硬件模块的加密驱动程序来提供加密功能的服务，也可以使用多个加密驱动程序的混合设置。CSM 通过CryIf(Crypto Interface）访问不同的加密驱动程序。

图4.1-4 CSM和邻近模块的关系

CSM 作为服务层，为SWC 或BSW 提供加密操作的接口。CSM 的主要任务是对服务进行调度和排序，并调用加密接口（CryIf）进行进一步操作。CryIf 将请求调度到加密驱动程序及其静态分配给该服务的加密驱动程序对象。CSM 使用基元（CsmPrimitives，已配置加密算法的实例）的静态配置来定义加密操作。然后将这样的基元分配给Job(Job 是配置过的CsmJob，指的是密钥、密码原语和参考信道），该配置决定进一步的属性，如优先级、异步或同步执行以及程序执行中应使用的密钥。需要注意的是，密钥总是位于加密驱动程序本身中，CSM 只使用对它的引用。

密钥和基元的分离允许加密操作和密钥管理API 分离。这使得应用程序可以专注于所需的加密操作，如MAC 计算和验证，而密钥管理器则在配置设置期间提供密钥。

CSM的API大致可以分为两类：直接AP（I 主要用于密钥管理）和基于Job的AP（I 主要用于加密操作）（见下图）直接API 与CryIf 和Crypto Driver 中的函数有直接对应关系，这些函数只能同步调用，CSM将把参数从应用程序直接传递给函数调用。基于Job 的API 使用一个Job 结构，即Crypto_JobType，它包含静态和动态参数以及对结构的引用，为执行该Job 的加密驱动程序提供所有必要的信息，使用Job 的每个服务都将使用此结构。服务的所有必要参数将由CSM 打包到结构的元素中，然后调用CryIf，然后调用配置好的Crypto Driver。

图4.1-5 CSM、CryIf和Crypto的Job API和直接API调用树

Job 可以同步运行，也可以异步运行，这取决于静态配置。加密服务信息、加密算法族和模式的参数决定了加密驱动程序中要执行的确切的加密算法。

CryIf（Crypto Interface）是加密接口模块，位于BSW（Basic SoftWare）的抽象层。CryIf 模块提供了唯一的接口来管理不同的加密硬件和软件解决方案，如 HSM、SHE 或基于软件的 CDD。

图4.1-6 AUTOSAR Layered View with Crypto-Interface

CryDrv 有如下两种实现方式：

• 1. Crypto（HW based）：硬件加密模块的驱动程序，用于控制HSM（Hardware Security Module）或SHE（Security Hardware Extensions），和具体芯片有关。

• 2. Crypto（SW based）：基于软件的CDDs（Complex Device Drivers） 实现的加密算法， 如AES-128 等算法。

基于以上两种不同的实现方式，CryIf 模块提供了唯一的接口来管理不同的加密硬件和软件解决方案。因此，基于 CryIf 维护的映射方案，CSM 模块可以使用多个底层的Crypto HW 以及 Crypto SW 解决方案。此外，CryIf 还确保了对加密服务的并发访问，从而能够同时处理多个加密任务。

与CP AUTOSAR 不同，AUTOSAR 自适应平台支持用于通用加密操作和安全密钥管理的API。该API 支持在运行时动态生成密钥和加密作业，以及对数据流进行操作。API 实现可以引用一个中央单元（加密服务管理器）来实现平台级任务，例如跨应用程序一致地进行访问控制和证书存储。该实现还可以使用加密服务管理器来协调功能到加密驱动程序的卸载，例如硬件安全模块（HSM）。为了在潜在的应用程序受损的情况下支持密钥的安全远程管理，Crypto Stack 集成了密钥管理体系结构，其中密钥和相关数据以端到端的保护形式进行管理。密钥可以基于现有的供应密钥以受信任的方式引入系统，也可以通过本地密钥生成以不受信任的方式引入系统。

车内信息娱乐应用程序由于与外界互联网相连，因此被入侵的风险很高，像这类应用程序在设计时一定是不被允许使用车身控制相关服务的。例如信息娱乐系统被外界攻击，然后被远程控制去使用制动服务，为了保障安全，必须要阻止这种信息娱乐应用程序对制动服务访问的任何尝试。

日益增长的信息安全需求驱动了身份和访问管理（IAM）的概念，因为AUTOSAR Adaptive 平台需要和应用程序建立健壮和良好定义的信任关系。IAM 为Adaptive 应用程序引入了特权分离，并针对攻击时的特权升级提供了保护。另外，在部署期间，IAM 能够使集成者提前验证Adaptive 应用程序要求的资源访问权限。IAM 为来自适应应用程序对服务接口，Adaptive 平台基础功能簇和相关模型资源的的请求提供了访问控制框架。

IAM 框架为AUTOSAR Adaptive 平台堆栈和Adaptive 应用程序的开发人员提供了一种机制，这种机制用于对每个应用程序的意图进行建模，根据访问请求提供访问控制决策，并执行控制访问。IAM 侧重于提供方法来限制Adaptive 应用程序对Adaptive 平台基础接口、服务接口与功能集群相关的明确资源接口( 例如KeySlots) 的访问。特别对系统资源( 如CPU 或RAM) 的强制配额不包括在IAM 中。

在运行期间，IAM 的进程对Adptive 应用程序是透明的，除非请求被拒绝并发出通知。远程Adaptive平台提供的服务实例请求由IAM 覆盖的，传入请求的PDPs 必须由Adaptive 应用程序实现。

该框架旨在运行期间执行对AUTOSAR 资源的访问控制。假设Adaptive 应用程序将在启动时进行身份验证，并且现有受保护的运行时环境确保Adaptive 应用程序被正确隔离，并且防止它们的特权升级( 例如绕过访问控制)。

考虑一个简单的应用场景，对于访问权限的描述，通常可以用一个访问权限矩阵来表示：

图4.1-7 访问权限矩阵

访问权限矩阵显示的是访问主体和访问客体之间的访问权限。所谓访问主体，是指一个想要获得其他服务访问权限的对象，通常是指系统中的一个进程；所谓访问客体，是指应当授权被访问的对象，通常它可以是指系统中的一个进程也可以是系统中的其他资源。

访问权限相关的信息需要以清单文件的形式部署在系统中。对于这份清单文件，有两种组成形式：

第一种，针对每一个服务和应用，从访问权限主体的角度，列举每个访问主体的访问意图，也就是每个访问主体拥有的其他服务或应用程序（访问客体）的访问权限；

第二种，针对每一个服务和应用，从被访问的客体角度，列举出它支持被哪些其他服务和应用（访问主体）访问。对于访问主体，通常情况下它可访问的客体清单文件是不会随着时间推移而改变；但是对于一个访问客体，它的被访问清单会随着部署了新的应用而更新。

在一个加密功能中，密钥和证书的功能比重很大。首先，密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。许多加密算法需要使用到密钥，因此，就需要KeyM 模块来管理密钥，而KeyM 对于密钥的管理主要体现在更新和生成密钥方面。而证书以加密或解密的形式保障了用户网络交流中的信息和数据的完整性和安全性。KeyM 模块可以实现证书链的配置保存与验证，这使得网络中的信息和数据的安全性更高。

AUTOSAR KeyM 模块由两个子模块组成：密钥子模块和证书子模块。密钥子模块用于初始化、更新和维护的密钥材料；证书子模块允许定义和配置证书，以便在生产时存储它们，并进一步用于多种用途。

图4.1-8 AUTOSAR layered view with KEYM

密钥子模块提供了一个API 和配置项，用于引入或更新预定义的加密密钥材料。它充当一个关键客户端，解释从一个关键服务器提供的数据，并创建相应的关键材料，这些密钥被提供给加密服务管理器。成功安装密钥材料后，应用程序就能够进行加密操作。

证书子模块提供了对证书进行操作的API 和配置。允许配置证书链，在配置中将证书的属性和关系设置好，上层应用通过 API 将证书数据传给KeyM 后，证书子模块将根据配置内容及HSM 按照标准结构解析的证书存储配置的位置（NVM、CSM 或 RAM）。此外，证书子模块允许BSW 模块和SWC 在AUTOSAR 软件架构的中心点上更有效地使用证书进行操作。此类操作的示例包括验证完整的证书链或从运行时提供并验证的证书中检索元素。所需的加密操作（如验证证书签名）仍然由加密服务管理器中定义的相关加密作业执行。

与CP AUTOSAR 不同，AP AUTOSAR 平台的更新和配置、通信、持久性或诊断等服务，也需要加密服务作为其功能的一部分。因为架构差异的原因，AP AUTOSAR 平台会将需要用户自定义、差异性的功能在应用层去实现，所以应用程序可以定义所需的密钥插槽、加密提供程序和证书。当需要关键材料时，必须由自适应应用程序（例如OEM key manager）配置，平台应指定槽型机器的关键槽。为了管理关键材料，一个专用的自适应应用程序（密钥管理器）可以指定相同的密钥插槽（即相同的参数和插槽型机器）。

车辆中的许多新功能建立在车载和后台服务之上，需要面对保护车辆免受网络攻击的挑战。为车辆的E/E 架构配置了安全机制，更新签名软件、安全启动和安全车载通信系统正在逐步建立。目前，IDS 作为一种额外的安全机制正在引起OEM 和供应商的关注。

入侵检测系统管理器（IdsM）是一个基础软件模块（适用于Classic AUTOSAR）或平台服务（适用于Adaptive AUTOSAR），用于收集和集中聚合可能由车辆软件、通信或电子系统受到恶意攻击而导致的安全事件。软件组件IdsM 提供了接收板载安全事件SEv 通知的标准化接口。SEv 可以通过BSW (Basic Software Modules）和SW-C (application Software Components）实现的安全传感器上报。此外，可以用可选的上下文数据（如事件类型和可疑数据）报告SEv，这些数据对于在后端执行的安全取证来说是有用的信息。

除了收集，IdsM 还可以根据可配置的规则对SEv 进行筛选。IdsM 将上报的SEv 过滤并转换为合格的机载安全事件（QSEv)，IdsM 进一步处理QSEv，用于存储或转发。根据总体安全概念的不同，QSEv可以通过安全事件内存（Sem）在本地持久化，也可以传播到已配置的接收器，或者两者兼有。可用的接收器是诊断事件管理器（Dem）模块和IDS 报告器模块（IdsR)，它们可以将QSEv 数据传递给后端中的安全操作中心（SOC)。

在车辆内的每个安全相关或机器中，IdsM 模块或服务的实例会收集和过滤安全事件（可选地包括附加数据），以便将它们存储在本地安全事件内存（Sem）和/ 或通过车辆网络将它们转发到中央入侵检测系统报告器（IdsR)。例如，该IdsR 可能位于远程信息处理单元内，使其能够通过蜂窝网络向OEM 的安全操作中心（SOC）发送安全报告和相关数据。然后，安全事件管理（SIEM）分析这些信息，并在必要时用于制定和决定适当的防御或缓解措施以应对攻击。

AUTOSAR 标准指出BSW 模块、CDD 和SWC 都可以充当安全传感器，安全传感器将安全事件（SEv）报告给IdsM，AUTOSAR 标准化可以由AUTOSAR BSW 报告的安全事件类型的子集。每个BSW 的规格里列出了自己产生的安全事件类型，这些事件由相应模块报告，业务组件也可以报告在AUTOSAR 中未标准化的自定义安全事件类型，可以使用安全性摘要（SecXT）指定由特定ECU 报告的安全性事件类型的属性。AUTOSAR 入侵检测系统管理器是通用的、提供灵活的配置。它独立于底层通信系统，在上述限制和假设条件下可以应用于任何汽车领域。

来源：汽车电子嵌入式