摘要

文章目的

安全需求

安全架构

硬件和软件分区

EVITA硬件安全模块

​编辑硬件接口

安全软件

部署

 摘要和展望

REFERENCES

摘要

        本文介绍了用于安全汽车车载网络的硬件和软件组件，为保护外部车辆通信提供基础。基于欧洲研究项目EVITA（http://evita-project.org）的工作，提供了一个框架，涵盖跨层安全，针对平台完整性、通信通道、访问控制、入侵检测和管理进行安全保护。

        提出了一个模块化的硬件/软件协同设计：硬件安全模块（HSM）提供了保护平台完整性、确保关键材料的完整性和保密性，并增强了加密操作，从而保护了架构的关键资产。为了提供具有成本效益的硬件解决方案，指定了三种不同的HSM变体：

1. 用于保护外部通信接口的完整HSM
2. 用于保护电子控制单元（ECU）之间车载通信的中型HSM
3. 以及用于保护与传感器和执行器之间车载通信的轻型HSM

        软件框架提供与HSM交互的应用特定接口。在整个工作中，遵循了最小权限设计和分离原则等高级设计考虑。

文章目的

        基于车辆对车辆和车辆对基础设施（V2X）通信的汽车应用被认为是未来减少致命交通事故数量和智能交通管理的手段。然而，对实施这些功能的嵌入式IT系统和网络进行恶意攻击，以及对车辆和基础设施之间传输的消息进行恶意侵入，例如发送虚假消息和在无线网络上进行欺骗，可能会产生严重影响。因此，车载网络需要提供适当的安全措施，以防范恶意消息。敏感的车内数据必须是可信的，并且受到修改的保护。

        潜在攻击和相关的安全要求列表（1）作为设计安全车载架构的起点。根据风险级别对攻击进行了分类，以选择适当的保护级别。我们从安全要求（2）中推导出车内安全机制。安全功能在软件和硬件之间进行分割，成本和安全级别是主要的考虑标准。安全密钥的安全存储以及车内电子组件之间的安全和可信通信为车辆或基础设施服务之间的可靠数据交换奠定了基础。因此，我们将“信任根（“root of trust”）”放置在硬件安全模块中，作为车辆电控单元的芯片扩展实现。这使得能够可靠地实施特定于应用程序的安全属性，例如真实性、机密性或新鲜性，以及可靠的访问控制。

        本文的其余部分组织如下：在概述V2X和车载通信领域的相关工作并总结（1）中的安全要求之后，提出了安全架构。

        过去十年来，车辆通信领域取得了巨大的增长，然而还没有定义涵盖车载通信各个方面（数据保护、安全通信、应用程序的安全和防篡改执行平台）的综合性安全架构解决方案。另一方面，一些项目，如

GST, Global Systems for Telematics, EU FP6 project, http://www.gst-forum.org/、

C2C-CC, Car2Car Communication Consortium, http://www.car-to-car.org/、

IEEE WAVE, Wireless Access in Vehicular Environments, IEEE standard 1609.2.和

SeVeCOM SeVeCOM, Secure Vehicle Communication EU FP6 project, http://www.sevecom.org/关注的是车辆间通信，并提出了用于保护车辆对车辆和车辆对基础设施通信的安全架构。这些提案主要针对通信特定的安全需求，采用了基于主机的安全架构风格，因为攻击者被假设为在一个无法定义安全边界的网络中。

        例如，(7) 提出了C2C通信联盟的解决方案，集成了先前的方法(8)(15)(16)(17)用于安全的车辆通信。这些提案主要将汽车视为一个单一实体，使用安全协议与其他汽车进行通信。特别是，该架构依赖于复杂的安全后端基础设施（包括权威机构，尤其是实施PKI，例如用于伪名和身份管理）。这是为了保护车辆的身份，同时在需要时能够管理其标识符。然而，除了需要保护节点标识符之外，这些提案没有提出具体的执行平台要求：所有提案都提到车辆注册和加密材料等数据应以防篡改的方式存储。不幸的是，这个要求没有伴随对车辆内部数据完整性和身份验证可能面临的具体威胁的进一步分析，这可能会指导这种存储的设计。EVITA项目填补了这一空白，通过提供具有安全存储、受信任的执行环境以及硬件中的加密处理器和用于通信、身份验证、授权以及软件中的入侵检测和管理的安全框架，提供了一个车内平台。

安全需求

在最高级别上，涵盖的安全目标包括：

1. 防止对车载通信网络的未经授权的篡改。
2. 防止对车辆应用程序的未经授权的修改，尤其是涉及安全和移动商务应用。
3. 保护车辆驾驶员的隐私。
4. 保护车辆制造商和供应商的知识产权。
5. 同时保持应用程序和安全服务的操作性能。

EVITA项目已经推导出以下一组安全需求和相关的功能需求，以满足上述安全目标（1）：

1. 电子安全相关数据的完整性/真实性：对于关键信息，基于对来源、内容和时间的完整性和真实性的保证，应该决定相应的行动。至少应能检测到这类信息的伪造、篡改或重放。
2. ECU/固件安装/配置的完整性/真实性：对于车辆中的任何ECU及其固件或配置的更换或添加，应保证其在来源、内容和时间上的真实性。特别是对于新的安全算法、安全凭证或授权的上传应受到保护。
3. 安全执行环境：ECU的受损不应导致系统范围的攻击，尤其是对于电子安全应用程序。成功的ECU攻击对于平台的分离和/或更可信任的区域应该具有有限的影响。
4. 车辆访问控制：对于车辆数据和功能的访问应受到控制（例如诊断、资源等）。
5. 可信的车载平台：应确保操作软件的完整性和真实性。如果需要，可以通过与可信参考的比较来防止以不可信的配置运行的修改后的平台。
6. 安全的车内数据存储：应用程序应能够使用功能，以确保对车辆内部存储的数据的访问控制，以及数据的完整性、新鲜性和机密性，特别是个人信息和安全凭证。
7. 某些车内和外部通信的机密性：应确保现有软件/固件以及更新和安全凭证的机密性。某些应用程序可能还需要对其内部或外部发送/接收的部分流量保持机密性。
8. 隐私：应对存储在车辆内部或从车辆发送到外部的个人数据执行隐私策略。例如，某些应用程序应限制将发送的消息进行关联的能力。
9. 安全功能的干扰：安全服务的操作不能对总线系统、CPU、RAM或无线介质的可用性产生负面影响。

上述要求是出于安全方面的考虑而产生的约束。如何满足这些约束在接下来的章节中进行描述。

安全架构

硬件和软件分区

在软件和硬件中对系统进行分区意味着在各种候选硬件架构上执行一组应用功能（包括与安全相关的功能）找到最佳解决方案（11）。这些架构通常建立在硬件节点上，例如CPU、总线、存储器、硬件加速器和传感器/执行器。选择最佳架构的标准通常包括硬件元件的成本、功耗、系统的执行时间或吞吐量，以及能够在不产生重大成本的情况下改变系统功能的能力。

在软件/硬件分区中，通常采用以下方法：描述应用程序功能、候选架构、将应用程序功能映射到架构，然后进行映射的模拟。通过分析模拟结果得到的跟踪，通常可以选择“最佳”架构。

我们使用了一个模型，其中包括硬件安全功能、软件安全功能、安全需求、攻击概率和风险，以及初步的协议定义。我们使用了名为TTool的软件（12）来实现这一目的，它使我们能够回答关于部署和设计决策的问题，并根据特定的安全需求为特定的车辆类型和模型量身定制软件和硬件安全架构。

EVITA硬件安全模块

下图展示了汽车HSM的一般架构。在满足(1)中的安全要求的基础上，选择了一种经济高效的HSM设计，提供足够的安全性和灵活性。在这种架构中，HSM位于与应用CPU核心相同的芯片中。

        HSM的组件分为必选和可选组件，因为根据使用情况，需要满足不同的安全需求。图1中用虚线表示可选组件。为了提供经济高效的硬件解决方案，我们规定了三种不同的EVITA HSM变体，以满足不同的安全需求：

• 完整的EVITA HSM：该HSM专注于保护车辆内部域免受V2X通信的安全漏洞的影响。这需要创建和验证电子签名。为了满足性能要求，需要一个非常高效的非对称加密引擎。完整的HSM提供了所有不同HSM变体中功能、安全性和性能的最高水平。它还旨在提供至少20年的安全寿命，这意味着ECRYPT II Level 7的“长期保护”（13）和/或NIST 2030+（14）。
• 中等的EVITA HSM：该HSM专注于保护车辆内部通信的安全。除了非对称加密模块和性能略低的CPU（例如25 MHz对比100 MHz），中等HSM与完整HSM相似。中等HSM在硬件上没有非对称加密模块；然而，它能够在软件中执行一些非实时关键的非对称加密操作，例如建立共享密钥。由于出于效率和成本的考虑，几乎所有的内部通信保护都基于对称加密算法，因此不包含非对称加密引擎是为了节省成本和硬件尺寸。
• 轻量级的EVITA HSM：该HSM专注于保护受保护的ECU与传感器和执行器之间的交互。它只需要包含一个对称加密引擎和相应的功能缩减的硬件接口。因此，轻量级HSM能够满足传感器和执行器典型的严格的成本和效率要求（例如消息大小、时序、协议限制或处理器消耗）。所需的共享密钥可以通过不同的方式建立，例如在制造过程中进行预配置，通过自初始化（例如基于物理不可克隆函数），甚至在连接的应用处理器中运行软件中的密钥建立协议。

        下表展示了不同HSM变种的组件。所有技术细节，如RAM大小、时钟频率等都是当前的估计值，可能会有所变动。

硬件接口

        EVITA硬件安全模块提供了一个异步（即非阻塞）、几乎完全支持多会话（即可中断）和部分支持多线程的硬件接口。它符合汽车HIS联盟提出的安全硬件扩展（Secure Hardware Extension，SHE）规范（10）。

        硬件接口涵盖了所有加密硬件安全模块的调用规范、更高级别的安全功能（如安全引导、安全时间戳）以及所有必要的安全管理功能（如设备管理、密钥创建、密钥导入/导出）。此外，它还定义了所有硬件解释的数据结构和直接的相互依赖关系，例如密钥层次结构、重放保护计数器或基本访问逻辑。

        EVITA硬件接口的一个独特特点是其固有的细粒度应用特定授权，与使用内部密钥的通用授权（例如）相比。因此，相同的密钥可以针对不同的用途具有不同的授权（称为用途标志）。例如，对称密钥可以针对使用该密钥进行加密、解密、MAC生成或MAC验证具有不同的授权。这些授权反过来可以直接基于密码，也可以间接基于各个ECU平台配置类似于可信计算（Trusted Computing，TC）方法（例如，TC身份验证引导），甚至可以是两者的组合（即，配置和密码）。

        此外，每个单独的用途标志都可以具有其个别的导出约束。因此，密码界面的定义如下（此处简化）：

EVITA_RETURNCODE cipher_init(
    
in algorithm_identifier, // 引用硬件密码算法

in cipher_mode{encrypt|decrypt}, // 指示使用标志“encrypt”或“decrypt”

in operation_mode{CBC|GCM|..}, // 指示密码操作模式

in padding_scheme{none|bit|..}, // 指示填充方案（如果需要）

in initialization_vector, // 初始化向量（如果需要）

in key_handle, // 引用要使用的内部密钥

in key_authorization_size, // 请求使用标志的密钥授权

out max_chunk_size, // 处理（process）函数的最大块大小

out session_handle ); // 多会话身份验证句柄



EVITA_RETURNCODE cipher_process(

in session_handle, // 来自init()的会话引用

in input_data_size, // 要进行加密或解密的输入数据大小

out output_data ); // 加密或解密的输出数据



EVITA_RETURNCODE cipher_finish(

in session_handle, // 释放会话句柄

out final_output ); // 最后一个输出块（例如，来自填充方案）

        首先，通过定义所有相关的操作参数，并在创建引用的密钥时提供（直接或间接）必要的密钥使用授权（如果已设置相应的授权），对密码进行初始化。然后，初始化将返回所有相关的处理参数（例如，最大块大小）和会话标识符，用于中断和并行处理相应的密码操作。在加密或解密所有数据块之后，密码会话被关闭，并通过调用最终化命令释放会话句柄。

安全软件

我们采用了一种灵活且模块化的安全框架，可以实现分布式部署（2）。由于使用情况可能要求满足一部分安全需求，模块化架构可以在可能的情况下重复使用安全组件。安全框架提供以下功能：

1. 访问控制：管理和执行策略。
2. 身份验证服务：根据需求提供身份验证机制。
3. 安全通信：建立经过身份验证和/或保密的通信通道。
4. 入侵检测：模块提供在不同抽象级别上检测和管理入侵的手段。

这些模块可以以面向策略的方式进行配置。为了实现最大程度的灵活性和适应性，所有安全模块可以通过接受和执行个别安全策略来进行配置（静态或动态配置），例如：

1. 授权策略：指定某个实体在特定条件下被允许访问和使用特定资源的程度，例如文件访问、网络和输入/输出设备访问、外部和内部通信（即过滤策略，定义可以在某些通信端点之间进行通信的内容、来源、协议或服务），以及连接的外围设备的使用。
2. 隐私策略：定义需要对数据和信息进行多大程度的隐藏，以防止第三方访问，或者至少需要对一定程度的隐私进行匿名处理。
3. 身份验证策略：定义所需的身份验证级别（例如密码、智能卡）以进行相应的角色授权。
4. 入侵检测策略：定义特定的攻击场景和攻击启发式规则。
5. 入侵响应策略：定义对特定类型的检测到的攻击执行的反制措施类型。

        安全软件框架的模块可以部署到各个电子控制单元（ECU）上，具体取决于ECU的角色、需求和性能要求。

部署

        我们概述了基于一个名为“主动制动”（Active Brake）的电子安全场景的硬件安全模块部署，该场景是在（9）中定义的使用案例的一部分。该场景使用车辆间通信。在图2中，显示了参与此场景通信的接收车辆内的电子控制单元（ECU）。数据在通信控制单元（CCU）进行真实性和授权的分析，然后分发到各个域和ECU，执行相应的操作。每个接收ECU都会检查数据的真实性（即其是否源自CCU）。为此，这些ECU配备了HSM。根据ECU的性能和运行环境，使用中型或轻量级HSM（对于传感器而言，由于平台的限制，仅可使用轻量级HSM）。

 摘要和展望

        我们已经设计和规定了一个模块化的安全硬件和软件概念，将用于汽车车载网络和相应的电子控制单元。安全硬件的不同变体使得部署具有成本效益。它们反映了不同领域和电子组件的安全要求。

        EVITA项目将在车载组件之间定义安全协议。在实施和集成到汽车操作系统和运行环境之前，将使用形式化方法和模拟来验证这些协议。HSM将使用来自Infineon的FPGA逻辑板和汽车微控制器进行原型设计。最后，硬件和软件将部署到演示车辆中。

REFERENCES

(1) A. Ruddle, D. Ward, B. Weyl, S. Idrees, Y. Roudier, M. Friedewald, T. Leimbach,

A. Fuchs, S. Gürgens, O. Henniger, R. Rieke, M. Ritscher, H. Broberg, L. Apvrille,

R. Pacalet, G. Pedroza, “Security requirements for automotive on-board networks based

on dark-side scenarios”, EVITA Deliverable D2.3, 2009.

(2) B. Weyl, M. Wolf, F. Zweers, T. Gendrullis, M.S. Idrees, Y. Roudier, H. Schweppe,

H. Platzdasch, R. El Khayari, O. Henniger, D. Scheuermann, A. Fuchs, L. Apvrille,

G. Pedroza, H. Seudié, J. Shokrollahi, A. Keil, “Secure on-board architecture specification”, EVITA Deliverable D3.2, 2010.

(3) GST, Global Systems for Telematics, EU FP6 project, http://www.gst-forum.org/

(4) C2C-CC, Car2Car Communication Consortium, http://www.car-to-car.org/

(5) IEEE WAVE, Wireless Access in Vehicular Environments, IEEE standard 1609.2.

(6) SeVeCOM, Secure Vehicle Communication EU FP6 project, http://www.sevecom.org/

(7) M. Gerlach, A. Festag, T. Leinmüller, G. Goldacker and C. Harsch, “Security Architecture for a Vehicular Communication”. In International Workshop on Intelligent Transportation (WIT), 2005.

(8) T. Kosch: Local Danger Warning based on Vehicle Ad-hoc Networks: Prototype and

Simulation. In Proceedings of 1st International Workshop on Intelligent Transportation

(WIT), Hamburg, Germany, March 2004.

(9) E. Kelling, M. Friedewald, T. Leimbach, M. Menzel, P. Saeger, H. Seudié, B. Weyl,

“Specification and evaluation of e-security relevant use cases”, EVITA Deliverable

D2.1, 2009.

(10) R. Escherich, I. Ledendecker, C. Schmal, B. Kuhls, C. Grothe, F. Scharberth: SHE –

Secure Hardware Extension – Functional Specification Version 1.1. Hersteller-Initiative

Software (HIS) AK Security, 2009.

(11) S. Künzli. Efficient Design Space Exploration for Embedded Systems. PhD thesis.

2006.

(12) TTool, the TURTLE Toolkit. http://labsoc.comelec.enst.fr/ttool.html

(13) ECRYPT II: Yearly Report on Algorithms and Keysizes (2008-2009), D.SPA.7 Rev.

1.0, ICT-2007-216676, 07/2009.

(14) NIST: Recommendation for Key Management, Special Publication 800-57 Part 1,

03/2007.

(15) M. Raya, P. Papadimitratos, and J.-P. Hubaux, “Securing vehicular communications,”

IEEE Wireless Communications Magazine, Special Issue on Inter-Vehicular Communications, October 2006.

(16) M. Raya, D. Jungels, P. Papadimitratos, I. Aad, and J.-P. Hubaux, “Certificate Revocation in Vehicular Networks,” Laboratory for Computer Communications and Applications (LCA), EPFL, Tech. Rep. LCAREPORT-2006-006, 2006.

(17) P. Papadimitratos, V. Gligor, and J.-P. Hubaux, “Securing Vehicular Communications –

Assumptions, Requirements, and Principles,” in Proc. 4th Workshop on Embedded

Security in Cars (escar), 2006.