A Formal Methodology Applied to Secure Over-the-Air Automotive Applications

适用于安全的空中汽车应用的形式化方法论

摘要

未来汽车应用中预期的高复杂性将要求经常更新支持这些应用的电子设备。 即使车载设备值得信赖，对空中交换的潜在攻击也对安全性和安全性提出了严格的要求。 为了解决对安全属性的形式验证，我们先前已经引入了AVATAR UML配置文件，其方法论涵盖了需求，分析，设计和形式验证阶段[1]。 现在，我们建议将AVATAR扩展到在所有方法论阶段和相同模型中都支持安全性。 本文将扩展的AVATAR应用于无线协议，以对车内控制单元进行可信赖的固件更新，并特别关注设计和形式验证阶段。

1 动机与概述

减少致命交通事故数量的一种有前途的途径是依靠V2X1通信[2]。 然而，增加新的车载服务显然促进了新颖的应用，但是也对安全性和安全性提出了严格的要求。 确实，如[3]中所述，对车载网络的攻击可能会带来严重的后果。 更准确地说，如果攻击者可以将恶意固件安装到车辆中，则他可能会虚拟地控制车载系统并对其执行任意操作[4]。 攻击者安装这种固件的一种方法是攻击空中（OTA）诊断和固件更新过程。 最后，必须以高安全性和安全性保证水平来开发V2X应用程序-包括远程刷新程序。

已经引入了几种方法来确保嵌入式系统中给定的安全级别。 例如，通用标准包括一种正式的认证方法，不幸的是，这种方法成本高昂，涉及书面工作，既没有解决安全问题，也没有提供攻击防护。 许多其他方法涵盖了关键嵌入式系统的开发，但是正式的验证阶段不幸地只关注安全属性，例如[5]。可以直接使用形式化方法，但是其中许多方法主要针对系统子部分的验证-例如，它们 只针对通信部分，即通信协议[6]-同时让其余部分几乎不被发现。

而且，针对整个系统的验证方法通常非常复杂，需要专门知识[7]。此外，仅提供部分或没有自动化支持的方法可能不适用于非经验丰富的用户[8]。我们的方法通过安全构造和验证技术扩展了面向安全的环境AVATAR。 AVATAR是针对实时嵌入式系统的统一建模语言（UML）配置文件。 AVATAR涵盖了所有常规方法阶段（需求捕获，系统分析，系统设计，属性建模和正式验证）[1]。此外，开放式工具包TTool完全支持AVATAR，该工具包提供了用于建模和自动属性验证的友好前端[9]。在EVITA项目[2]的范围内，我们应用了这种新颖的方法来正式确保汽车安全关键应用程序。我们以[10]中描述的FirmwareUpdates（FU）协议的验证为目标，该协议最近被提议为远程和有线固件更新的V2X解决方案。已经使用了几种方法来专门验证固件更新规范[11]，[12]，[13]。尽管如此，他们还是在协议验证中采用了可疑的假设，例如弱访问控制和单向身份验证（无车辆身份验证）。我们的方法部分解决了这些已确定的问题。

此篇文章的结构如下。 首先，我们在第二节中介绍了基本的车内安全架构。 然后，第三节描述了我们如何在安全性方面扩展AVATAR。 第四部分中的FU协议说明了正式的验证过程。 验证结果将在第五节中介绍。第六节最后总结了本文。

2 安全架构和漏洞

最近的车载智能运输（IT）架构包含了将车载电子控制单元（ECU）互连的通信网络技术（例如LIN，CAN，MOST和FlexRay）的异构情况[14]。这种设备数量的增加触发了新应用的发展，反过来也带来了对安全性和安全性的更复杂的要求。根据[3]中确定的安全要求，我们引入了一种安全架构[15]，该架构涵盖ECU中的跨层安全性，目标是平台完整性，通过指定软件和硬件安全机制来实现通信渠道，访问控制和入侵检测。此安全体系结构通过一组加密协议得到了进一步增强[16]。体系结构和协议的组合应强制执行针对各个用例确定的安全要求[14]。但是，如[17]所述，安全协议的部署可能会引入诸如设计漏洞之类的漏洞（例如，安全漏洞）。在协议设计中），实现漏洞（易受攻击的协议实现），配置漏洞（组件配置不当）和系统漏洞（易受攻击的主机平台）。因此，EVITA的深入形式分析同时考虑了架构的安全相关元素和密码协议。但是，本文重点关注针对配置和系统漏洞的密码协议的验证（请参阅第III-B节）。

3 形式验证方法

A AVATAR配置

1）AVATAR：AVATAR是一个SysML环境[1]，具有5个阶段的方法：需求捕获，系统分析，系统设计，属性建模和形式验证。SysML图支持所有这些阶段。根据SysML块表示进行AATAR设计。 SysML块由属性列表，方法列表，同步和异步信号列表以及SysML状态机图（SMD）定义。一个SMD包括一组与过渡相关联的状态：后者用防护，变量操作和方法调用标记。 SMD（参见图3）还支持信号发送和接收运算符（分别由chanOut（），chanIn（）表示）以及确定性和非确定性的时间运算符（例如计时器）。TTool是一个开源工具包[9]，它支持多个UML配置文件，例如TURTLE [18]，DIPLODOCUS [19]和AVATAR。在TTool中，只需按一下按钮即可检查AVATAR设计的安全性能：底层的正式语言和工具包（UPPAAL [20]）实际上对用户完全隐藏。

2）出于安全目的扩展AVATAR：AVATAR的所有方法论阶段均已扩展如下：安全性和安全性问题应在同一模型中一起建模，并且安全性和安全性应从同一模型中证明。 例如，需求阶段现在支持面向安全性的需求和攻击树[21]。 更准确地说，设计和验证阶段扩展如下

a.Design：该设计支持面向加密的数据类型（例如，密钥）和SysML加密块，用于定义面向加密的方法（例如，encrypt（），mac（））。现在可以将块之间的通信通道声明为公共或专用。攻击者只能收听公共的。现在可以在SysML文本注释中定义面向安全的模型编译指示。pragma＃InitialCommonKnowledgeB1.x B2.y表示BlocksB1和B2的属性xandy分别具有相同的初始值，例如，该编译指示对建模预共享密钥很有用。

b。安全属性：要验证的安全属性也定义为实用程序。 ＃ConfidentialityB.datpragma必须验证BlockB的属性是否仍然是机密的。杂注＃Au-thenticityB1.st1.msg1 B2.st2.msg2指出，在状态st2中B2接收到的所有消息msg2必须相对于B1是真实的，即，它们必须在statest1之后由B1发送给msg1byB1。

c。形式验证：扩展的AVATAR图可以根据安全属性进行形式验证，同时仍然可以进行安全性证明。为了安全起见，我们定义了一个AVATAR到ProVerif（）的转换过程，并已在TTool中实现了该过程。ProVerif是一个用于自动证明机密性和真实性属性的工具包[2

最后，通过AVATAR设计，现在只需按一下按钮，就可以对机密性和真实性属性进行建模和验证

B 验证的目标

我们基于AVATAR的验证方法依赖于以下验证目标：T oV：=（S，SR，M，P，H，At，V T），其中：

S是系统资产的一组代表性但非穷举性的行为，用UML用例，交互概述和序列图表示。

SR是通过SysML安全性需求图[3]表示的一组安全性或安全性需求，该图提供了用于细化和关联到资产的层次结构。

M是抽象化S中指定系统的AVATAR模型。

P表示从SR.Pis派生的属性，使用机密性和真实性编译指示在AVATAR中表示（请参阅第III-A小节）。

H是在建模步骤S→M和SR→P中考虑的一组假设和抽象。 H还包括验证所需的模型约束，例如，陈述不能猜测给定的密钥。

At是攻击者的模型。相对于攻击者而言，安全性处于低迷状态。 AVATAR依赖于ProVerif [22]的Dolev-Yao攻击者模型：攻击者可以通过公共渠道侦听，拦截，篡改和注入消息。

VT是一种验证技术，用于证明M是否满足P的属性。对于安全属性，VT取决于[1]中描述的方法：AVATAR处理活动性，可到达性和无死锁属性的证明。为了验证安全属性，VT是在ProVerif中实现的解析算法。

首先，需求和分析阶段分别产生SR和S。 然后，在系统设计阶段构建M。属性建模阶段定义P。 在多个阶段中，假设被直接或隐含地用作输入。 在正式验证阶段，最后两个ToV组件-At＆V T-由TTool-to-Proverif（）自动翻译功能以及ProVerif自身隐式处理。

4 固件更新协议的验证

上一节中描述的正式验证方法现已应用于FU协议。

A 协议分析(S)

为了简化S的建模和描述，将FUProtocol分为两个连续的阶段，分别称为“诊断”和“下载”。即使本文仅描述了诊断阶段，也对两个阶段进行了建模和验证。但是，有关下载阶段和FU协议的更多详细信息可以在[10]中找到。诊断阶段包括外部诊断工具（DT），汽车通信控制单元（CCU）和目标车载ECU之间的初始交换。固件更新。最初，DT建立安全通道以有效地与ECU通信。因此，DT生成了不对称密钥M ki，并将其传输到ECU（参见图1，消息1至4）。一旦M ki分布，DT和目标ECU之间的后续交换将受到M k保护。为了准备闪烁，应将ECU设置为编程模式（参见图1，消息5至8）。要解锁，目标ECU挑战DT，以依靠ECU提供的种子N a-和工厂预共享的对称密钥sk（Smk：= ComputeKey（NA，ssk））来计算代码Smk。仅当两个Smk代码都匹配时，ECU才会解锁以进行编程。然后，固件通过DT（下载阶段）从原始设备制造商（OEM）服务器安全地转移到目标ECU。

B Security需求(SR)

作为风险和威胁分析的结果[3]，FU协议必须满足一组严格的安全要求。这是从SR提取的最关键的安全要求的子集。更详细的安全要求可以在[21]中找到。


固件机密性（CSR.1）：从OEM传输到DT以及从DT传输到目标ECU时，必须对固件保持机密。

密钥机密性（CSR.2）：交换或使用非公共密钥的交易所必须在整个刷新过程中保持密钥机密性。

内部真实性（ASR.1）：每当CCU与ECU之间发生交换时，都必须确保声明的作者与真实作者之间的对应关系。

外部真实性（ASR.2）：每当在DT实用程序和OEM服务器之间或在DT与车载组件之间交换数据时，都必须确保声明的作者与真实作者之间的对应关系。

C 验证模型的目标(M)

建立协议模型M，以S为参考。S-DT，CCU，ECU和OEM中的每个通信实体（CE）都使用一个AVATAR块（见图2）。对于此案例研究，我们仅描述FU协议中第一个交换的建模。其他交换也以类似方式捕获。如图1所示，该第一次交换包含一个加密密钥（{M k} {pkccu}），一个时间戳（ts1）和使用DT的密钥（Sign（M1，skdt））执行的M1签名。交换必须在发送块和接收块的状态机图（SMD）中表示。首先，在DT的SMD中定义初始状态（请参见图3）。其次，调用几个预定义的加密方法以将M1构建为初始状态的输出转换。实际上，dat1，dat2和sign已分配给属性M sgx，后者分别捕获{M k} {pkccu}，ts1和Sign（M1，skdt）。一旦组成，M sgxtruly对应于M1，并通过公共输出信号operatorchanOut（M sgx）进行广播。因此，CCU的SMD被相应地设计为接收M1。因此，从CCU的SMD中的初始状态开始的传出转换包括等待M1的输入信号operatorIncIn（M sgx）（请参见图3）。收到M1后，将调用预定义的方法ySign（）来验证M1的签名。布尔属性重新表示答案：错误的签名（not（resp）== true）导致阻塞状态。相反，一个真实的（resp == true）将导致协议中的有效状态。对于所有其他协议数据单元，都将重复这种用于消息交换的建模模式。

D 性质(P)

SR中的每个安全要求都转换为P中的一个或多个属性。通过依赖第III-A节中定义的属性pragma，在AVATAR模型M中将属性形式化。例如，安全要求CSR.1（请参阅第IV-B小节）被转换为表I第一行中描述的pragma。该pragma对属性固件的机密性进行建模。 CSR.2也被翻译成几个类似的pragma，从而为以下秘密Block属性的机密性建模：skdt，skccu，skecu，skoem，Mk，Na，Smkandssk。随之而来的是，只要在车内部件CCU和ECU（CCU↔ECU）之间发生交换，ASR.1就会表达出相互的真实性。此外，为了符合ASR.2，外部汽车通讯实体（CE）以及每次交换（DT↔CCU，DT↔ECU和OEM↔DT）也需要相互认证。表I的第二行和第三行包含说明如何分别为消息M1和M4实现DT和CCU相互认证的pragma（请参见图1，M1和M4）

E 假设(H)

#InitialCommonKnowledge pragma中明确考虑了Blocks在消息交换之前预先共享的值的假设（例如，密钥或种子）（请参阅第III-A小节）。 系统启动时值是秘密的事实的假设是在 #Confidentiality pragma中隐式声明的。 根据第二节，我们假设每个CE块都是一个受信任的域，在其中安全地执行操作。 相反，CE块之间的通信通道被假定为公共通道，因此可能受到攻击。 即使攻击者At可以知道CE块中声明的加密方法，不可逆的方法（例如Hash，MAC或Signature -prevent At）也可以公开通过crypto方法输入的数据。 的确，除非系统模型M具有可利用的弱点，否则At永远不会泄露秘密材料，因此At无法猜测秘密密钥值。 注意，ToV方法不考虑计算攻击。

5 验证和结果

只需按一下按钮，就可以验证FU协议ToV，因此不需要专业知识。 在此，我们简要描述此自动验证过程。第一步，将M-中考虑的模型M，属性P和假设H-自动转换为ProVerif规范，即转换为一组Horn子句。 图4显示了基本SMD过渡到ProVerif的转换。 此外，ProVerif包括攻击者At，其中描述了一组Horn子句{h⇒c}（假设表示结论），从而反映了攻击者可能获得的知识。 对于与某个语用关联的每个子句cp⇒hp，该算法正式证明只要达到事实cp，就必然隐含hp中的事实：

机密性证明：对于语用#Confidentiality B.dat，证明At是否可以导出Horn子句sh1⇒c1，的链式序列。 。 。 ，hn⇒cn，ci⊂hi+ 1，其中h1是其已获知的知识和datis incn的子集，它揭示了秘密数据。

真实性证明：对于每个实用程序#Authenticity B1.State1.dat1 B2.State2.dat2，证明攻击者At可以部分或完全模拟B1。 在这种情况下，B2接受至少一个由At发出的消息，从而破坏消息源（B1）与目的地（B2）之间的对应关系（射入协议，[22]）。 因此，仅在保留发送者-接收者对应关系的情况下，才可以确保真实性。 由于B1和B2可能会互换其角色（B2始发地，B1目的地），因此可以相应地编写类似的用法以实现对真实性的相互验证

最后，很明显，At的行为是根据允许的操作（例如，仅侦听/插入公共频道）以及H语句所施加的限制（例如，给定的密钥是不可猜测的）来定义的。 固件更新协议的验证结果R（ToV）在表II中显示为可追溯性矩阵，并在安全要求SR，属性P和验证结果之间建立了对应关系。 请注意，“ X.o”和“ Y.d”分别用于缩短原始语句和目标语句的真实性。

6 总结

车载软件/硬件架构的复杂性的提高将当前开发此类系统的方法推向了极限。 即使很长一段时间以来都明确考虑了安全属性，仍然需要定义用于同时处理Safety属性和Security属性的方法。 依靠著名的建模语言（SysML），AVATAR是适合设计人员的集成框架。 自动化的形式验证减少了对形式技术技能的需求。

新的AVATAR安全功能已成功应用于固件更新协议的建模和形式验证。 实际上，已经验证了强大的相互身份验证以及机密性。 EVITA项目的范围内还验证了其他协议和车载系统组件，从而证明了AVATAR的适用性。

现在，将以新的安全功能（特别是完整性和freshness）扩展AVATAR。 此外，还选择了AVATAR来对下一代航空平台中的安全性和安保特性进行建模和验证，因此有望在未来几年中进一步发展。