Towards the Model-Driven Engineering of Secure yet Safe Embedded Systems

迈向Secure而又Safe的嵌入式系统的模型驱动工程。

摘要

我们介绍SysML-Sec，这是一个基于SysML的模型驱动工程环境，旨在促进嵌入式系统开发的所有方法阶段的系统设计人员和安全专家之间的协作。嵌入式系统设计中的中心问题是对系统体系结构的硬件/软件分区的定义，这应该尽早进行。 SysML-Sec旨在通过集成安全要求和威胁来扩展此分析的相关性。特别是，我们提出了一种敏捷方法论，其目的是尽早评估安全需求和旨在满足系统安全性的安全机制的影响。通过仅具有最小扩展的现有SysML图，就可以以组件为中心的方式捕获安全性问题。将捕获的需求导出为安全性和加密机制之后，就可以在此设计上正式验证安全性属性。为了在SysML模型中得出ProVerif规范，在SysML-Sec工具链中实现了Toperformthatter，模型转换技术。在整个演示过程中，汽车固件格式化流程都可以作为示例。

1 介绍

现在，围绕模型驱动工程（MDE）的大多数贡献为设计安全，复杂，分布式和实时嵌入式系统提供了适当的方法和建模环境。 这些环境通常处理时序约束，调度，资源分配和并发性的分析。 相反，长期以来，人们一直在考虑安全性，特别是在计算机系统中发现严重漏洞之后。 安全性和隐私问题最近特别成为主要的嵌入式系统。 但是，现代嵌入式系统的大小，异构性和通信特性使人们迫切需要开发合适的工程环境，以更明确地定义安全目标和威胁，并通过安全机制实施对策，并评估甚至正式证明安全对策的有效性。

我们介绍SysML-Sec，这是一个基于SysML的模型驱动工程环境，旨在促进嵌入式系统开发的所有方法阶段的系统设计人员和安全专家之间的协作。 SysML-Sec引入了针对安全性问题的自定义SysML图和相关的方法。 SysML-Sec方法包括三个基于SysML的阶段。 （i）系统分析从基于分区的过程开始，在此过程中，可以将安全需求和威胁以及系统的功能特征一起识别出来。 （ii）系统设计侧重于软件实现的安全机制。 最后，（iii）系统验证旨在依靠模型转换技术来正式验证，模拟和测试在先前阶段构建的模型。 本文介绍了总体方法，特别侧重于安全机制的设计和证明。

SysML-Sec方法论和图表已在FP7欧洲项目EVITA的范围内进行开发和试验，从而设计并实现了用于汽车嵌入式系统的安全体系结构。 该架构的定义，设计和验证是采用本文介绍的方法进行的。 因此，有20多个用例（特别是紧急制动用例）针对该目的进行了说明。 本文中的图表直接摘自EVITA“固件刷新”案例研究。

2 上下文：嵌入式系统

2.1 设计嵌入式系统

IT系统通常是按照V周期设计的，其构建阶段（需求，分析，设计，部署）之后是验证阶段（例如测试，形式证明）。 在嵌入式系统中，只有将功能划分为软件和硬件后，V周期才能明显启动。 系统分区通常依赖于Y图表方法[7]。 一方面，这是共同设计软件和硬件功能的第一步；另一方面，这是硬件体系结构（在执行，通信和存储方面定义）的第一步。 该过程的结果是针对该特定系统的关键标准（例如成本，性能等）的最佳硬件/软件架构。 在DIPLODOCUS环境[4]的范围内，以SysML-Sec为基础构建Y图表，其实现如下：

1. 首先将应用程序描述为抽象的通信任务：任务代表的功能与其实现形式无关。

2. 硬件体系结构描述为简化执行节点（例如具有操作系统和中间件的CPU，硬件加速器），通信节点（例如总线）和存储节点（例如内存）。

3. 映射模型[7]定义了任务和任务之间的通信如何分别分配给计算和通信/存储元素，以及如何在硬件和软件之间进行分区。 例如，映射在硬件加速器上的任务是硬件实现的功能，而映射在CPU上的任务是软件实现的功能。

此分区过程至关重要。 确实，如果由于问题（性能，功耗等）的发现较晚而使关键的高级设计选择无效，那么这可能会导致重新设计的成本过高，以及市场的可用性不足。 DIPLODOCUS在映射阶段依赖SysML分配机制。 UML部署图可能是一个很好的选择，但是它用于部署已设计的软件功能：如UML标准所述，“将软件工件分配给节点”。 在DIPLODOCUS中，功能可能完全由硬件实现。 而且，它们是高度抽象的，也就是说，我们不映射任何具体的人工制品（例如资源文件），而仅映射高级功能元素。

2.2 嵌入式系统中的安全问题

越来越多的嵌入式系统已成为通信工件，具有与其直接环境或后端系统的新交互功能，因此容易受到犯罪分子的攻击。例如，已经证明有可能在微软的XBox [15]或ADSL路由器[6]，移动设备[12]，航空电子设备[34]或汽车系统[14]等机顶盒上发起攻击，但仅举几例。这些安全问题中的许多问题反映了对低级漏洞的利用（通常可以通过适当的编程实践和特定的组件测试来解决），或者由于对功能或安全逻辑组件到硬件体系结构的映射了解不足而导致设计漏洞。 。我们认为，SysML-Sec模型驱动工程方法可以在两个方向上进行适当的系统分析，设计和证明，并描述安全威胁和安全目标，并进一步证明它们在系统设计中是否得到妥善处理。

3 SysML-Sec: 总览

3.1 基本原理

我们设计了SysML-Sec环境，以便能够描述安全问题以及分区要求，如[30]中进一步讨论。 特别是，我们的扩展弥合了安全性和攻击的面向目标的描述与基于软件/硬件体系结构（及其模型驱动的分析）的资产的细粒度表示之间的鸿沟。 SysML-Sec还支持分区阶段之后的V循环阶段，尤其是软件分区功能的设计1。 SysML-Sec的主要目标是：

• 在整个嵌入式系统生命周期中指导并增强系统工程师和安全专家之间的协作。这就是我们采用OMG标准，尤其是SysML的原因，这些标准在当今的嵌入式系统世界中非常普遍。

• 提供与使用的MDE方法兼容的安全威胁和安全要求的详细表示，并可以采用逐步完善的方法来定义功能和安全体系结构。这种改进还应有可能弥合最初的高级别要求与随后定义精确而详细的安全机制之间的差距。

• 将软件/硬件代码签名与安全问题的处理结合在一起。我们认为这个特定的设计目标是嵌入式系统领域的关键。

• 在系统划分，系统设计方面提供仿真和形式验证功能，这构成了嵌入式系统工程的两个关键阶段。在系统分区级别，模拟有助于评估安全功能对系统性能的影响，例如安全协议对总线负载的影响。在系统设计级别，正式验证旨在证明威胁是否得到正确处理。

3.2 方法论

SysML-Sec方法采用三个阶段的方法，首先处理系统分析，然后处理软件设计，最后处理系统验证，如图1所示。该分析包括确定需求和攻击，以及对应用程序的划分。 系统。 设计阶段包括安全机制的定义，以及在设计中要证明的安全属性中对安全要求的改进。 最后，验证在不同的工程阶段进行，如下所示。 仿真主要用于分区阶段，以评估安全机制在术语或性能方面的影响。 正式验证旨在证明所设计系统对威胁的恢复能力。 测试本来是要做的，但是要在设计模型产生的已部署实现上进行测试。

3.3 工具化

TTool [1]是一个免费软件，支持多个UML配置文件，例如DIPLODOCUS和AVATAR。 在分区阶段，SysML-Sec重用DIPLODOCUS，如[27]中所述。 需求，攻击和设计通过AVATAR进行分析，AVATAR是专门用于嵌入式系统分析和建模的配置文件[3]。

4 案例研究：固件更新

我们以“固件更新”案例研究说明SysML-Sec方法论阶段。 后者取自欧洲项目EVITA的公开成果[19]。 EVITA的主要目的是为汽车嵌入式系统定义安全的体系结构。 这样的系统负责关键功能并且非常复杂：它们包含大约100个电子控制单元（ECU），它们全部互连到主系统总线（CAN，FlexRay）。 攻击是出于安全和经济原因（尤其是盗窃）的缘故。 如今，随着联网汽车和Car2X通信的出现，与汽车物理访问相关的主要安全隐患也在不断发展，这进一步暴露了这些系统。

所考虑的案例研究旨在通过诊断工具在服务站执行的使用较新版本固件的ECU软件更新。 汽车诊断根据ISO 14229-1中规定的标准统一诊断服务UDS进行硬接线。 首先，要刷新的ECU初始化其软件并启动诊断功能。 服务站员工将其诊断工具连接到车辆中的车载诊断界面。 一旦执行了诊断并执行了身份验证，就结束了编程会话。 最后，可以在ROM中执行刷新。

期望整个过程是安全的，尤其是在固件和/或闪存过程的完整性，机密性和真实性方面。 更具体地说，可以定义以下安全要求（有关更多详细信息，请参见[19]）：

• 真实性：车辆是否一定要与有效的诊断工具进行交流？
• 机密性：固件构成要保护的知识产权。
• 数据完整性：闪存代码必须未经修改。
• 匿名：在闪存过程中，不应将有关驾驶员的私人信息透露给服务站。

5 系统需求工程与分析

安全需求和威胁分析通常被视为IT系统中风险分析的序言。 此过程通常旨在决定是否在系统中引入安全对策，这意味着增加了成本。 在嵌入式系统的情况下，我们认为安全性分析也对系统体系结构及其实时性能有很大影响：因此，安全性要求和威胁分析应遵循迭代的方式进行，因此应更加灵活。

5.1 迭代安全性/系统协同设计过程

系统分区，安全要求和威胁会根据一种或几种典型用例逐步得到完善。 从初始体系结构开始的以下阶段得到了重申，以便达到令人满意的改进水平：

初始体系结构映射。 这些用例中突出显示的系统功能首先被建模为任务。 功能之间的交换以任务之间的信息和事件流为模型。 然后可以将任务和通信映射到系统的草稿结构中。 设计师的经验在确定架构的初稿时起着关键作用。

体系结构分析系统资产是在架构元素（处理器，软件，传感器，硬件加速器，通信通道）中标识的，并且首先是指通用组件，例如：“所有系统总线”。 当体系结构变得更加详细时，资产更有可能被细分为特定元素。 此处采用的硬件/软件分区和功能映射在定义现有资产的类型（及其后的漏洞）中起着关键作用。

安全问题识别。 所选资产的威胁和安全漏洞应尽可能描述攻击者应达到或超过的能力以及攻击的源头（本地，远程，通过特定接口）。 SysML-Sec环境支持按照EVITA案例研究中详细介绍的方法评估风险[31,13]。 我们还通过安全目标实现了对威胁覆盖率的自动检查。 基于风险分析，还应确定映射到威胁的安全目标并确定其优先级。

安全目标可能来自（1）来自系统预期的安全标准或属性，或者（2）来自针对资产的未解决的威胁或攻击，或者（3）来自在迭代过程和详细程度时对另一个安全目标的定义。 架构发生了变化。 在进一步的迭代中，可能需要更新因体系结构更改而弃用的安全目标。

体系结构优化。 当系统及其使用变得更加精确时（例如，新的通信通道，将执行环境定义为OS /中间件/应用程序层等），体系结构的改进源自对体系结构组件的更详细描述。 这也可能是由于将需求映射到系统信息流中而造成的，这些信息流通常分布在多个硬件元素之间。 如果架构和安全性要求不兼容，例如，如果安全机制的性能开销过高，则优化阶段可能会失败。 还应该执行一致性检查，以确保安全目标不与针对同一资产表达的另一要求冲突。 失败表明分析应回溯到优化的前一个阶段。

5.2 Diagrams

5.2.1 需求

安全需求在SysML需求图（RD）中建模。 RD的主要运算符是用于定义需求之间关系的需求包含和派生依赖性形式。 包含关系按照层次结构描述子需求，并使复杂的需求分解为包含其子需求的需求，而deriveReqt确定支持源需求的多个派生需求。 引入了安全需求刻板印象，以明确区分系统的功能需求和安全需求，同时针对单个环境对功能需求和非功能需求进行建模。 此外，定义了Kind参数以指定安全要求的类别（机密性，访问控制，完整性，新鲜度等）。

图2表示对“固件更新”的5个安全性要求：固件的真实性，对闪存存储器的受控访问，其自身派生为对闪存函数和闪存的受控访问以及固件数据的保密性。

5.2.2 威胁和攻击

我们建议不要使用传统的攻击树方法[32]，而是可以使用稍微自定义的SysML参数图，使用更相关的方法更好地对威胁进行建模。 威胁被建模为嵌入到代表攻击目标的块中的值，从而实现了更紧凑的映射并更好地映射到系统体系结构。 攻击（<< Attack >>刻板印象）可以与逻辑运算符（例如OR，AND）以及时间因果运算符（例如SEQUENCE，BEFORE或AFTER）一起链接在一起。 我们认为后一种构造对于描述攻击者在嵌入式系统中的操作观点特别有用，例如在两个因果相关攻击之间存在最大持续时间的情况。 例如，当攻击具有时间限制的认证令牌的系统时，必须首先检索该令牌，然后必须在该令牌到期之前使用该令牌。

为了评估特定漏洞的影响以及在风险评估阶段解决该漏洞的需要，可以将不同参数图中的攻击实例结合在一起。 攻击也可以标记为根攻击，这意味着此攻击位于攻击树的顶部。 最后但并非最不重要的一点是，攻击可以链接到需求，从而可以自动检查攻击的覆盖范围。

图3描述了在EVITA“固件更新”案例研究范围内确定的一些攻击。 代表两个资产（CommunicationUnit，InCarCommunication）。 例如，在通信单元中执行攻击“ Flashing中的漏洞利用漏洞”，然后在InCarCommunication中伪造“ CorruptOrFakeMessage”，则可以执行“ GarageGainsAccessToCCU”。

5.2.3 划分

应用程序模型是通信功能的图形。 例如，在图4中，事件流对应于紫色端口，而信息流对应于蓝色端口。 建模了五个主要功能：诊断连接的初始化（DiagConnInit），诊断请求管理（DiagRequestManager），编程会话管理（ProgSessionManager），固件标识（FirmwareId），最后是固件编程（FirmwareProg）。

该架构模型在图5中进行了部分描绘。它表示要保护的资产。 两个子域连接到主CAN总线。 每个子域都有自己的CPU，RAM和总线。 第一个域还具有硬件加速器，第二个域具有该过程打算更新的闪存。

映射包括将功能元素分配给资产，即，将任务分配给CPU或硬件加速器，以及向总线和内存进行通信。 图5显示了两个子域中三个任务的映射：ProgSessionManager映射到“ CPU_PTC”，而FirmwareProg和FirmwareId映射在“ CPU_ECU”上。

6 系统设计

6.1 方法论方面

系统设计旨在优化分区期间映射到处理器节点上的所有功能的体系结构和行为。 从安全性的角度出发，目的是更详细地描述如何通过在分区阶段定义的硬件体系结构之上执行的软件机制的安全硬件机制来满足安全性要求，并确保该设计真正满足了在分区阶段确定的需求。 在分区中表达的需求是非正式的，是指资产：因此，需要对其进行完善，直到其表达直接与设计元素（例如，属性，方法，交换的消息，状态等）相关为止。 一旦得到完善，它们就构成了要验证的安全属性，特别是通过形式化方法。

通常用于系统设计的SysML图，例如框图和状态机图，缺乏明确的安全机制建模方法。 例如，安全机制通常需要预先共享加密材料（例如，秘密密钥），但是框图无法对此建模。 因此，SysML-Sec扩展了SysML，以便显式地对安全性机制和属性进行建模。

6.2 安全设计扩展

SysML-Sec设计是基于SysML框图和状态机图进行的，具有多个功能扩展，并在pi-calculus（过程代数）中正式定义。 我们假设一个Dolev-Yao攻击者模型，即只能窃听块之间交换的消息，这与从攻击者的角度来看被视为私有的块的属性相反。 该攻击者模型足以描述从外部（即，使用通信网络）或系统内部（即，使用内部总线或系统内的任何其他可访问组件接口）对嵌入式系统的组件之间部署的协议的攻击。 。 但是，它既不旨在捕获对硬件的物理攻击，也不旨在利用多个组件的漏洞。 主要扩展是：

• 公共通道和专用通道：由于通信通道可能在分区阶段就已占用过安全或不安全的总线，因此，如果攻击者可以进行窃听，则我们可以使用公共标签来标记块之间的链接，否则可以使用私有标签。

• 加密算法。 SysML-Sec块可以定义一组与密码算法（例如，加密），verifyMAC等相对应的方法，以便能够描述基于这些算法（例如，密码协议）的安全机制。

• 加密材料。块还可以预共享值，这是设置密码协议通常需要的功能。 SysML-Sec为此目的引入了特定的编译指示：（InitialSystemKnowledge和InitialSessionKnowledge）。用来描述在系统执行之前共享的数据库。第二个定义在同一系统的每个会话中共享的数据。通常，当考虑使用加密协议时，第一个实用指示意味着数据是所有协议会话都预先共享和共有的，而第二个则表示数据是共享的，但在每个协议会话中具有不同的值。

# InitialSystemKnowledge BlockID.attribute [BlockID.attribute]*

例如，图6显示了用作安全协议的密钥分发协议的框图，以便允许ECU以安全方式进行通信。 该协议建立在三个不同的实体上：密钥分发的启动器（ECU1），密钥主控器（KM）和ECU1期望与之共享密钥（ECUN）的ECU。 所有块均定义了加密功能，其中两个在ECUN中可见（encrypt（），decrypt（））。 实用程序“ InitialSystemKnowledge”指出，PSK1是在系统启动之前在ECU1和KM之间共享的属性。

图6表示KM状态机图的子集。 使用状态机来描述每个块的行为。 他们可以操纵密码功能和数据。 例如，在KM块的状态机中，动作msg8 = MAC（msg1，PSK1）将MAC（msg1，PSK1）的结果分配给msg8。

6.3 Security Properties

与设计链接的安全属性是通过分析阶段得出的对安全要求的细化获得的。 已经基于SysML参数图[21]定义了一种专用语言来描述通常复杂的安全属性。 相反，安全属性通常可以用类型（例如，机密性）和与该类型相关的设计元素（例如，块的属性的机密性）来定义。 这种简单性要求一种基本的建模解决方案，该解决方案不基于复杂的图或运算符。 我们的解决方案再次依赖于程序框图注释中提供的实用性：机密性和真实性可以在此级别直接表达。

机密性说明指出，不得将块属性的内容透露给攻击者：

# Confidentiality block.attribute

真实性说明指出，由块block2接收的消息m2必须先在消息m1中由块block1发送。 以下示例描述了这种情况：

# Authenticity block1.s1.m1 block2.s2.m2

这种真实性说明规定了两种状态：发送方块之一，即块1中的一个状态s1，以及块2中的一个状态s2。 同样，在块1的状态机图中，s1对应于m1发送之前的状态。 类似地，s2对应于收到消息并被接受为真实消息后的状态权。

图6的保密性说明指出，切勿公开ECU1的PSK1（预共享密钥1）（秘密密钥）。 此属性源自对机密性的要求：密钥必须保持秘密，以确保要发送到闪存的固件的机密性。 类似地，真实性说明指出，状态解码器OK之后由KM接收的msgauth必须由ECU在状态st1之前的变量msg中发送。

7 系统验证

可以从分区模型（例如，所选硬件体系结构的性能评估：CPU和总线的负载），设计模型（例如，安全性和安全性证明）或从部署模型自动生成的可执行代码中执行系统验证 （例如，安全性和安全性测试）[2]。 必须对模型转换进行定义，以便将SysML-Sec模型转换为仿真，正式或可执行的规范。 映射模型转换在[20]中给出，设计模型转换在[26]和[16]中描述。

从分区模型中，可以评估安全机制对安全约束的影响，例如延迟等实时约束。 [33]中给出了这样一个研究的例子，其中在分区阶段对照安全性属性（等待时间）检查了在CAN总线消息中添加安全性MAC信息的影响。 还可以评估安全机制对总线和CPU负载的影响，因为它们可能影响对安全至关重要的过程和通信的行为。 例如，对从ECU发送到另一ECU的数据包进行解密可能会阻止控制制动器致动的过程的调度。

从SysML-Sec设计中，正式的证明分别依赖于UPPAAL [8]和ProVerif [9]来证明安全性和安全性（请参见图7）。 我们的安全证明考虑到了所有设计元素，包括安全机制，例如加密协议所有状态的活跃性和可到达性，以及安全机制对安全关键过程的影响。 我们的安全证明可能与状态机描述的任何行为有关。 协议的概念在这里很重要：在使用虚拟化机制的情况下，它既捕获了总线或网络上的通信，又捕获了单独块中各个组件之间的通信，例如具有处理单元的单独信任区。

ProVerif [9]是一个工具包，在Dolev-Yao模型下，依赖Horn子句解析来通过密码协议自动分析安全性。 ProVerif输入一组Horn子句或pi演算中的规范以及一组查询。 ProVerif输出是否满足每个查询。 在后一种情况下，ProVerif尝试识别一条轨迹，以解释未满足查询的结论。 图7描绘了在TTool中成功验证的图6中建模的机密性和真实性属性。虽然我们可以指定任何安全性要求，但是我们目前仅支持对可以用这两个安全性属性表示的形式要求的形式验证。

除了为安全目的专门定义的设计要素外，安全证明还考虑了所有设计要素，即面向安全的实用程序和加密方法，对安全属性（活动性，可到达性）没有影响。 同样，安全性证明不涉及相关的系统详细信息。 这样的证明不需要变量或时间信息的值。 安全证明不考虑几个状态机元素，例如时间运算符（after子句）和具有可变值的计算。 例如，a = b + c以符号方式执行，但没有具体值：以这种方式捕获的数据流（我们知道a包含来自b和c的信息）是用于安全证明的唯一有用信息。

8 相关工作和观点

已经存在许多解决IT系统中的安全需求工程或威胁建模的建议。 在[24]中，Nhlabatsi等人。 安全需求工程工作根据四个方面进行分类，即基于目标的方法，基于模型的方法，面向问题的方法和面向过程的方法。 我们的方法将基于安全需求的描述与系统架构和威胁分析的模型驱动工程相结合，并强调了整个工程V周期中敏捷交互的重要性。 在这方面，它的哲学遵循TwinPeaks方法[25]的思想，即使后者不针对硬件系统。 并非像TwinPeaks所建议的那样，在需求和体系结构之间进行简单的螺旋交替，而是在软件的Y-Chart建模及其对硬件组件的映射，资产的标识和对它们的威胁以及安全需求的标识之间进行交替。

在设计级别评估安全属性主要依赖于形式化方法。例如，[35]提出用概率分析方法来验证密码协议。在最近的工作中，[10]将一阶线性时序逻辑（LTL）引入Isabelle / HOL定理证明者，从而使对系统及其安全属性进行建模成为可能，但不幸的是，这导致了无法轻松重用的特定模型。 [23]混合了正式和非正式的安全属性，但是整个验证过程不是完全自动化的，再次需要特定的技能。我们的方法侧重于使用图形语言将半正式规范细分为正式模型，以正式验证安全属性的满意度。在这方面，它似乎与UMLsec方法[18]非常相似，后者是一种旨在定义软件安全性的建模框架。 UMLsec还主要根据上述分类来设计一种基于模型的安全要求工程方法。通过UML框架，可以定义软件组件及其组成的安全性。它还具有完整的框架，可解决从安全要求到测试的模型驱动安全软件工程的各个阶段，包括有关软件组件组成的基于逻辑的形式验证。对于当前论文所关注的嵌入式系统领域，UML允许通过使用UML部署图来描述已经设计的软件到硬件节点的映射[18]。根据OMG自己的定义，这些图描述“一组可用于定义代表软件工件到节点的系统的执行体系结构的结构。”这意味着，不幸的是，他们无法从[7]的意义上处理软件硬件分区。相比之下，SysML-Sec采用了SysML支持者的更全面的观点，并着重于在详细的系统设计之前和期间对安全性和功能特性的各种映射进行非常评估。此外，SysML-Sec还为硬件节点提供了明确的自治仿真和证明语义。最后，SysML-Sec包括低级硬件节点，其使用可能会影响功能的通信和执行，例如：就面向安全的通信而言，DMA引擎可能支持或不支持紧急通信。与UMLsec [17]类似，我们的建议还采用了一种基于目标的方法来描述安全目标。仍然，我们的方法完全在SysML中进行了扩展（基本上是新的构造型和一些运算符），并且没有引入任何新图以使系统工程师容易采用。

根据我们的经验，分区是嵌入式系统中的核心问题。要实现符合安全要求的正确分区，必须尽可能早地理解和量化安全机制的影响。我们注意到只有少数作者，尤其是埃姆斯和莫菲特[11]，以及最近的皮埃特·坎巴塞德​​斯[28]和拉斯波特尼格[29]，都处理了安全性和安全性要求之间的关系。例如，最后两位作者非常详尽地讨论了安全性和安全性需求之间可以建立的关系。尤其是，这些研究可以描述冲突，就像我们在本文中所考虑的那样，但是也可以增强关系（当安全性和安全性趋于相同设计时）或条件依赖性。我们认为，要在SysML-Sec中获得类似的描述，就需要扩展工程方法，并从所有工程阶段到规范阶段都进行额外的反馈交互：例如，应基于之前介绍的安全机制来检查安全要求的满足性将引入任何其他安全机制。我们没有在案例研究中评估任何这样的方法学步骤，这没有功能安全性的要求。但是，我们计划在将来调查此类问题。

我们在本文中介绍的工作更具体地旨在验证安全机制对于安全要求的无害性，而安全要求的规范不在本文的范围之内。这是基于规范和设计阶段中的定量验证，以及对系统体系结构的要求。特别是，首先可以基于安全机制的性质进行估算，最值得注意的是，所使用的密码算法及其成本（在计算和带宽使用方面）。随着将要部署的安全机制的设计以及更加详细的硬件/软件分区的细化，可以使用SysML-Sec框架进行的仿真来对这些元素进行更精确的评估。尽管我们的工具链尚不支持，但最终可能会在开发的组件上使用测试来验证对安全要求的遵守情况。威胁分析本身就是为此采取了行动，将对在实现中执行的安全测试的描述合并到系统模型中。在这方面，我们的建议包括使用SysML参数图进行威胁建模。因此，SysML-Sec可以对攻击树进行编码，但是它采用了以块为中心的观点，并考虑了重用。我们尤其认为，这将允许由安全分析员对具有现成系统组件的现成组件（COTS）进行威胁建模。我们在这里进一步扩展了SysML-Sec的表达能力：我们的声明性方法应特别有用，以便结合其他威胁建模方法的知识。

我们认为，工具支持对于系统的成功和系统工程至关重要，尤其是在非功能性需求（例如安全性和给定设计中的满意度验证）方面。在IT系统开发生命周期的各个级别上，许多其他作者也意识到了这一需求。此外，免费软件的可用性是成功的另一个重要因素，这仅仅是因为它们可以满足特定需求。 KAOS框架[36]开创了面向目标的安全需求工程的先河，它具有整个专用环境。 CARiSMA（UMLsec的扩展级别）集成到Eclipse开发环境中，从而确保了更好的接受度。还开发了威胁建模框架，例如Isograph软件的攻击树+，用于设计攻击树分类免费软件AD工具[22]。还存在许多具有很好接口的正式验证工具，例如AVISPA [5]，它为协议验证提供了良好的支持。可以看出，这些工具中的许多工具仅涉及系统开发生命周期的一部分，这不利于它们的采用。我们的框架旨在遵循SysML的更全面的环境，OMG和INCOSE支持的形式主义，并为系统工程师所广泛了解。

9 总结和未来工作

随着嵌入式系统通过引入通信功能向攻击者开放，嵌入式系统正变得越来越复杂，软件和硬件变得更加复杂。为了减少此类系统的上市时间，同时又要确保其良好或更好的工程质量的经济诱因，需要引入具有适当支持的系统安全工程方法。在这方面，采用具有自动化和简化验证功能的用户友好工具可能会成为强制性要求。我们的建议SysML-Sec专门解决了系统设计和开发各个阶段的需求。它基于一种流行的语言（OMG的SysML），并由免费软件工具包（TTool）支持。它具有正式的验证功能，该功能依赖于公认的安全性（ProVerif）和安全性（UPPAAL）工具包。该方法已开发用于定义安全的汽车嵌入式系统。我们介绍了对该系统进行案例研究的结果，突出了我们方法的几个优点，尤其是在形式验证方面。我们未来的工作将致力于进一步评估我们在其他嵌入式系统上的方法，以及扩展工具支持，尤其是用于增强威胁覆盖范围和需求可追溯性分析。