SysML Models and Model Transformation for Security

SysML模型和模型转换以实现安全性

摘要

嵌入式系统的安全漏洞已成为网络罪犯非常有价值的目标。 引入SysML-Sechas来针对这些系统在其开发阶段的安全性。 但是，评估这些阶段的攻击抵抗力需要有效地捕获系统的行为，并从这些行为中正式证明安全性。 因此，本文提出（i）增强了新颖的SysML框图和状态机图，以更好地捕获安全功能，以及（ii）从模型到Proverif的转换.ProVerif是首次发布的用于对安全协议进行形式化分析的工具包，但可以 通常用于评估机密性和真实性。 本文演示了使用复杂的非对称密钥分发协议的方法的正确性。

SysML-Sec，安全性，模型驱动的工程，模型转换，ProVerif，TTool

1 介绍

连接的嵌入式系统和网络物理系统的比例不断增加，为攻击网络罪犯提供了更多机会。 仅列举过去对此类连接系统的攻击的几个例子，我们可以提及ADSL路由器（Assolini，2012），移动和智能电话（Maslennikov，2010），航空电子或汽车系统（Hoppe等人，2011）以及智能对象，例如。 Fitbit上披露的最新漏洞（Apvrille，2015年）。 甚至在医疗设备（例如Hos-pira Symbiq药泵）上也已发现安全漏洞（ICS-CERT，2015年）。 这种攻击还针对工业系统，这些工业系统的传感器越来越多地与脆弱的信息系统相连，如Stuxnet，Flame和Duqu（Maynor，2006年）攻击所证明的那样。 此类系统的可扩展性以各种目标为目标，例如恐怖行为和勒索软件。

在代码大小，分布和异构性等方面，系统复杂性是主要的风险因素。 更好地考虑这些系统风险的一种解决方案是在开发周期中考虑所有约束，包括安全性。 先前，我们从安全性，性能和安全性方面介绍了SysML-Sec环境来处理此类复杂系统的设计（Apvrille和Roudier，2015年）。 SysML-Sec在考虑软件/硬件分区的前提下从需求和可能的攻击开始着手进行系统开发。在分区阶段之后，SysML-Sec还支持软件组件的设计，并再次考虑了安全性。 TTool是SysML-Sec的免费/开源支持工具（Apvrille，2003年）。

TTool依靠UPPAAL获得安全证明，并依靠ProVerif从SysML-Sec框图中执行安全证明。 但是，SysML-Sec在建模（即，建模安全功能）和证明（在模型到验证的转换中的局限性）方面都有很多强大的限制。 本文针对这些限制中的几种提出了新的建模和转换方法。 特别是，我们已经完全形式化并实施了模型转换。

下一节从建模和安全证明环境方面给出了相关工作。 第3节介绍SysML-Sec。 第4节重点介绍mod-eling扩展以及模型到proverif的转换。 第5节介绍了TTool的更新版本和验证功能。 最后，第六节总结了论文。

2 相关工作

在设计软件组件时评估安全属性主要依赖于形式化方法。例如，（Toussaint，1993）提出使用概率分析方法来验证加密协议。 协议被表示为树，其节点捕获知识，而边缘被分配了转移概率。 尽管这些树可能包含恶意代理程序以对攻击和威胁进行建模，但仍未明确表示安全属性。 此外，对于威胁分析，应该明确表示并手动解决攻击。（Trcek和Blazic，1995年）定义了一套正式的基本安全服务集，用于实现安全目标。在这种方法中，安全属性分析在很大程度上取决于设计者的经验。 此外，威胁评估也不容易。

在最近的工作中，时态逻辑语言已用于表示安全属性。（Drouineaud等人，2004年）将一阶Lin-ear时态逻辑（LTL）引入到Isabelle / HOL定理证明器中，从而使对系统及其安全属性都进行建模，但不幸的是导致无法轻松重用的特定模型。 （Ma ̃na和Pujol，2008）混合了正式和非正式的安全属性，但是整个验证过程并不是完全自动化的，再次需要特定的技能。类似地，软件体系结构建模（SAM）框架（Ali等，2009）旨在弥合非正式安全需求与其正式表示和验证之间的鸿沟。 SAM使用正式和非正式的安全技术来实现已定义的目标并缓解缺陷。因此，可以依靠符号模型验证器（SMV）在LTL模型上验证活动性和无死锁的属性。即使SAM依靠完善的工具包-SMV-并考虑到威胁模型，“安全性证明”流程仍未实现自动化。

UMLsec（J̈urjens，2007）是一个建模框架，旨在定义软件组件的安全属性及其在UML框架中的组成。 它还具有相当完整的框架，可以解决模型驱动的安全软件工程设计的各个阶段，从安全要求的规范到测试，包括有关软件组件组成的基于逻辑的形式验证。

最近（Shen et al。，2014）开发了扩展的UML模型，扩展了用于安全协议验证的UML序列图，其方法还包括将该模型转换为ProVerif以验证机密性和对应性。 但是，我们的工作包括状态图，可以对更广泛的协议进行建模。 基本顺序图可以仅对单个执行建模，而状态图可以对包含语句和循环的协议进行建模。 此外，我们的流程还包括验证弱而强的真实性。

考虑到ProVerif的功能和局限性，我们针对以前的出版物提出了一种更好的模型化情况（例如循环）及其从模型到验证者的转换的方法，从而设法限制了安全性证明的情况 将失败，而不会影响SysML-Sec图的安全性证明功能。

3 上下文

3.1 SysML-Sec

SysML-Sec连接了对安全性需求和攻击的面向目标的描述（图1的左半部分），以及基于软件/硬件划分的资产的细粒度表示（图1的右半部分）。 SysML-Sec还支持分区阶段之后的V循环阶段（图1的右下角），尤其是软件分区功能的设计。设计阶段包括安全机制的定义，以及在设计中要证明的安全属性中对安全性要求的细化：我们在文件中解决了这一阶段。验证发生在不同的工程阶段。为了评估安全机制对性能的影响，仿真通常在分区阶段中使用。正式验证旨在证明设计中的系统对威胁的恢复能力。测试具有类似的目的，但基于设计模型而在已部署的实施中进行（Apvrille和Roudier，2015年）

SysML-Sec设计由SysML块和状态机图组成.SysML-Secblock可以定义与密码算法（例如encrypt（））相对应的一组方法，以描述基于这些算法（例如密码协议）的安全机制。 块还可以预共享值，这是设置密码协议通常需要的功能。

SysML-Sec设计的正式证明分别基于UPPAAL（Bengtsson和Yi。，2004）和ProVerif（Blanchet，2009）来证明安全性和安全性。 ProVerif是一个工具包，在Dolev-Yao模型下，它依赖Horn子句解析来对加密协议上的安全属性进行自动分析。 ProVerif将输入作为一组Horn子句或pi演算中的规范与一组查询一起使用。 然后ProVerif输出是否满足每个查询。 在另一种情况下，ProVerif尝试识别一条轨迹，以解释如何得出查询不满意的结论

安全证明考虑了除为安全目的专门定义的设计要素外的所有设计要素：面向安全的实用程序和加密方法，这些要素对安全性（活动性，可到达性）没有影响。 类似地，安全性证明属性将不相关或不受支持的系统详细信息抽象掉了。 例如，安全证明不需要时间信息，因此不会考虑临时操作符（后文）。 其他建模元素（如循环）在翻译过程中会被忽略。

3.2 SysML-Secdesign图中缺少的功能

自从我们首次提出将SysML-Sec模型转换为ProVerif以来，多年来，我们从忠实的测试人员那里收集了宝贵的反馈意见。 在容易纠正的极端情况或可用性错误中，一些健壮性问题表示更基本的问题。这些问题通常与SysML-Sec中的功能语义与ProVerif中的对应功能之间的不匹配有关。 我们提出了一些最重要的问题，这些问题促使我们完全重新设计翻译过程：

**循环。**通常，用户可以利用TTool中嵌入的验证功能来评估提供服务的系统的安全性。 对于某些系统，使用循环对它们的状态机建模似乎是自然的。 不幸的是，ProVerif第一步试图将给定的规范弄平。 使用实现时的直接转换，对包含循环的设计的验证不会终止。我们解决了本文中的这一重大缺陷。

**私有通道：**与ProVerif中一样，SysML-Sec使用户能够对两种类型的通道进行建模：专用通道和公共通道。 尽管对于ProVerif，它们的语义应该相同，但是它们在可达性查询方面的行为却有所不同。 ProVerif认为应始终接收发送的消息。 在专用通道上，只有明确指定的实体才能读取发送的消息，而在公共通道上，攻击者也可以读取该消息。 在评估事件的可及性时，ProVerif会尝试重建跟踪并在事件触发的确切时刻停止。 因此，如果仅在通过专用信道发送消息之后发生该事件，则该消息将不会被读取。 因此，ProVerif会认为跟踪无效，无法证明返回结果。正如我们希望在我们的上下文中提供证明可达性的能力一样，修改私有通道表示形式也是我们工作中要解决的重要问题。

4 扩展图

4.1 深入设计图

在TTool中，用户首先将框图和关联的状态图构建为图形模型。 方框图描述了系统的体系结构和组件，与方框关联的状态图描述了它们的行为。

我们以欧洲FP7EVITA项目为例，该项目定义了汽车通讯系统的安全架构（Kellinget等，2009）。 在此体系结构中，安全关键的ECU（电子控制单元）与CAN或Flexray总线互连。 汽车系统可能出于经济原因（免费激活可选功能）或出于犯罪目的而受到攻击。汽车系统与信息系统（路标，通行费等）的互连以及Internet提供了对这些系统进行攻击的新方法系统。

为了避免攻击及其在ECU上的传播，会话密钥定期分配在相关ECU的组之间。 图2展示了具有实体ECU1和ECU2的非对称密钥分发协议的框图。 图3显示了描述其通信协议的状态图的摘录。ECU1处理该密钥并在公共通道上发送该密钥，而ECU2接收该消息，验证密钥，并使用它发送消息。 锁显示验证结果，将在第5节中进行描述。


图形模型经过翻译以在ProVerif，UPPAAL等中进行验证。第4.1.2节提供了详细的正式描述。

4.1.1 用pragma扩展SysML-Sec

并非所有模型参数和查询都在框图和状态图中用图形表示。 例如，我们需要能够在会话开始时声明两个属性相等。 我们用实用语扩展了SysML，即有关系统属性的正式文本注释。 语法分为模型Pragma或属性Pragma。 模型Pragma提供了更多面向块属性的面向安全的语义，而属性Pragmas描述了块属性或状态机的安全属性。 表1中描述了pragma。

4.1.2 SysML-Sec图的形式化

为了为ProVerif在SysML-Sec设计图上执行的证明提供可靠的数学基础，我们决定正式表示对模型进行的转换，如TTool中所述。 这种形式化将提供我们如何将通用SysML图链接到依赖Horn子句的ProVerif规范的理解，以及不完整来源的来源。 这种形式化也是为将来的工作建立等效性的数学证明的第一步

第一个转换将与计时器相关的功能转换为一组块和信号。 在我们的形式化过程中，固有地考虑了后者。

形式上，我们用D表示SysML-Secdiagrams；d∈D:: =（B，Mp，Pp），其中B是一组块，Mp是一组模型pragma，Pp是一组属性pragma。

我们定义一个块b∈B:: =（A，M，Σ，ss，E，S，O，T，L），其中A是一组属性，M是一组方法，Σ是一组信号， ss一个开始状态，e一组结束状态，s一组状态，o一组操作，t一组将属性，方法，信号和状态与它们的合格名称关联的转换和Lalabeling函数。 属性，方法和信号可以在块视图中映射到它们的匹配图形元素，而状态，操作和转换对应于所考虑块的状态机。

a∈A与每个属性关联一种类型：属性可以采用的一组具体值。 我们将求值称为映射，该映射为每个属性a∈A返回一个值。 我们假设我们能够在A上构造模式.p表示的模式由方法或简单运算符（=，and，+等）对A元素的应用组成.A上的模式集表示为P. 我们稍微扩展标签功能L以接受格式正确的模式作为输入。

操作集O被定义为基本操作集的不相交：

其中Ordm是一组随机操作，而Oout和Oin分别是一组out和in动作。 我们通过ν.a编码随机操作，通过̄m〈p〉输出动作，通过m 〈a〉 in输入动作，其中m∈∑，p∈P和a∈A。

最后，我们将转移t∈T定义为元组（i，o，g，R），其中：


我们只处理结构良好的块，以便映射SysML图的直观语义。 例如，没有过渡可以到达开始状态（ss）或从结束状态进入，并且多个过渡只能在一个状态而不是在一个操作处加入或拆分。

由于我们希望使用ProVerif后端在SysML-Sec图上执行安全性证明，因此必须首先转换这种图以匹配ProVerif可以处理的等效表示形式。

4.2 ProVerif的语义

ProVerif具有两种不同的语义：Horn子句和pi-calculus。从SysML-Sec转换为ProVerif时，我们会生成pi-calculus规范。 生成利用了Horn子句的语义来建模概念，例如ProVerif不直接支持的状态机图中的循环。

为了更全面地了解TTool提供的证明，应该首先熟悉ProVerif证明引擎。 因此，我们尝试在本节中简要介绍ProVerif，并向感兴趣的读者介绍手册和白皮书，以便更好地理解。

Pi演算可以根据并行执行并通过通道交换消息的过程来描述协议。 流程可以拆分以创建并发执行的流程，并复制到给定协议的多个模型执行（称为会话）中。 加密原语（例如对称和非对称加密或哈希）可以通过以下函数进行建模：这些函数可以是创建新值的构造函数，也可以是减少表达式中应用的构造函数数量的析构函数。

从该规范开始，可以查询可达性，对应性和机密性属性，并且ProVerif将向用户显示结果，如果该属性已验证，则为true；如果找到伪造该属性的跟踪，则为false；如果ProVerif断言失败，则无法证明 或重新引用查询的属性。 不幸的是，无法通过无数个会话和无限制的消息空间来提供属性的此类失败是不可避免的，因为此问题无法确定（Durginet等，2004）。 因此，当将pi演算规范转换为Horn子句时，ProVerif会做出sound近似。

4.3 SysML-Sec到ProVerif的翻译

SysML-Sec图的某些组件可以很直接地映射到ProVerif的对应组件，因为我们借鉴了ProVerif的攻击者模型和通道语义。 但是，对于其他组件（如状态机图或专用通道上的循环），我们必须仔细考虑ProVerif推理，以避免尽可能多的情况而导致证明失败。 在以下各节中，我们将介绍整个翻译过程，并提供有关非显而易见的功能或情况的更多详细信息。

4.3.1 SysML-Sec图的划分

由于SysML-Sec状态机图可能包含循环，因此我们需要将这些循环展开到一定限度，或者重用可以多次执行的已翻译规范的一部分。在静态分析中已经考虑了这两种选择 由于规范中的跳跃通常会导致完整性方面的损失，而通过限制重复次数来展平图形会影响证明的正确性，因此规范的工作是非常重要的。

为了保持ProVerif保证的稳健性，我们选择不限制循环。 这样，将由格式正确的块组成的SysML-Sec图表转换为ProVerifif规范的第一步是确定每个块中每个基本块的初始状态。 ，T）是块的子部分，可以将其视为仅具有一个入口点的原子。 从一个块b =（A，M，Σ，ss，E，S，O，T，L）∈B可以构造一组基本块（用BB（b）表示），这些基本块形成状态的一部分， 操作和过渡集。

我们将InitBB（b）定义为基本块的初始状态集。 该集合是所有状态的集合，这些状态至少具有两个不同的传入转换。

我们通过遍历SysML-Sec图给出基本块的构造功能。 用→表示的功能是根据一组推理规则指定的。 每个基本块的构造规则从其初始状态开始

通过递归添加不是初始状态的所有转换和节点来构建基本块，这些转换和节点的路径均从初始状态开始。

4.3.2 翻译基本块

每个基本块（s，E，S，O，T）∈BB（b）的迁移函数由函数[[]]：状态，转换集→π演算代码，将转换集展开为 ProVerif规范。 我们通过串联生成的指令来构建代码。 为此，我们使用串联运算符⊕。转换规则在表2中进行了正式定义；它们以应应用的顺序列出。让我们简要解释表2中的翻译规则。

规则（a）处理多个传出转换，应在有多个传出转换（| I |> 1）时应用。（b）转换警卫，（c）转换动作。（d）和（e ）以状态处理，（f），（g）和（h）处理操作。 最后，（i）停止翻译算法。 请注意，（e）也停止了翻译，因为它处理了将该基本块链接到另一个块的过渡（更多详细信息请参见第4.3.3节）。

当一个状态之后有多个传出转换时，只要可以验证保护该转换的布尔条件，它就可以使用其中的任何一个。 从安全的角度来看，使用这些转换之一进行的攻击的任何痕迹都是有效的。 从概念上讲，这等效于让攻击者选择在不确定的情况下进行哪种过渡。 我们在规则（a）中对此建模，方法是创建与每个过渡相对应的值，将其公开，然后等待与攻击者的选择相对应的值。

4.3.3 实用程序和基本块链接

规则（e）显示如何将控制从一个基本块传递到另一个基本块。 ProVerif通过展平它们来支持简单的流程调用，因此，对于包含循环的图来说，它们不会终止。 因此，不是直接调用基本块，而是生成形式为tok（call L（n’），arg）的令牌，并使攻击者可以使用它们。 一个这样的令牌允许攻击者执行初始状态为n’∈InitBB（b）的基本块，并将该块的属性值作为参数传递（arg =⋃a∈A{L（a）}） 。

此令牌仅应在正确的会话中使用一次，因此我们在会话中添加会话标识符以确保令牌在同一会话中被伪造和使用，并使用随机机制防止其重复使用。 不幸的是，由于ProVerif近似值（不可避免的），使用随机数会影响ProVerif在存在循环的情况下证明属性（主要是真实性）的能力。

5 在TTool中验证

ProVerif结果作为包含结果的文本文件传递回TTool。 对所有状态都执行可到达状态查询，而仅对实用程序中列出的属性执行真实性和保密性查询。 来自第4.1小节中模型的相关结果以例如可到达状态，不可到达状态，机密数据，满意的真实性…的列表的形式给出。为了方便用户使用，文本结果还通过方框图和状态图传达，如图2和3所示。

经过ProVerif验证后，状态图显示状态的可到达性，红色锁表示无法访问的状态，绿色锁表示可访问的状态。 该框图显示了“身份验证”和“机密性”验证结果，在编译指示上以彩色拆分锁显示，左下半部分表示“强真实性”，右上半部分表示“弱真实性”。 半锁定的绿色表示真实性满意，红色表示不满意，灰色表示无法证明。 证明为机密的属性以绿色锁显示，证明为非机密的属性以红色锁显示。

根据第4.1节所述的非对称密钥分发，我们举例说明了我们向ProVerif进行翻译的功能和限制。 图2中的ProVerif验证表明，已对ECU1和ECU2中的密钥mvksk和idk1sk进行了机密性验证。 所示的两个真实性查询都证明了强真实性和弱真实性。

在图3所示的状态图中，我们确认对协议至关重要的状态是可以到达的，并且该协议能够完成。 仅由于意外行为才可以到达的状态（例如UnexpectedMsg6）被确认为不可达。

接下来，我们演示了我们能够对包含循环的状态图执行安全性验证。 在ECU2中，我们添加了从最后一个stateProtocolRunEndedback到第一个stateWaitingForMsg0的过渡，以形成一个循环。 对框图或状态图没有其他修改。 ECU2现在准备与任何愿意的实体配对，并且应该在每个会话中使用不同的密钥。

机密性属性保持不变，但真实性属性已更改，如图4所示。强真实性不再通过循环进行验证，因为攻击者可以截获ECU1和ECU2之间的整个交换，然后可以将其重放给ECU2。 可以通过使用nonce代替时间戳（被认为是常数）来纠正。 我们的案例研究提供了一个示例验证以及由于循环引起的更改。

6 总结

SysML-Sec的目标是安全，可靠的嵌入式系统的整个开发周期。 它由一个用户友好的工具包提供支持，该工具包明确支持安全和安保工程，并且只需按一下按钮即可提供正式验证。 但是，先前在安全性证明方面的贡献在建模和证明能力方面都有很大的局限性。 因此，本文提出了一种基于新的建模元素（编译指示）和新的模型到证明转换的完全新颖的方法。 本文对建模元素和转换都进行了形式化。 特别是，本文表明，我们的方法现在支持循环和专用通道，并将其集成到TTool中。

尽管如此，将SysML-Sec图转换为ProVerif仍然包含限制。 它们取决于ProVerif限制或新的翻译过程。 我们在这里介绍它们是为了警告潜在的用户和潜在的未来工作。

循环： 即使我们当前对循环的转换可以证明大多数属性（强身份验证的证明有时会失败）并为其他结果提供良好的结果，但在某些情况下引入随机数来链接基本块可能会导致ProVerif无法证明结果。 我们做出了这种折衷，因为循环很可能会降低证明的完整性。 一种可能的改进是使用户能够手动提供提示，以帮助ProVerif证明其包含循环的图表。

算术。 将SysML-Sec图转换为ProVerif时，我们将丢弃在动作或防护中执行的任何与算术相关的操作。 实际上，ProVerif没有对算术的表示，regarding运算甚至数字等类型。 考虑到这些操作，将需要我们对ProVerif证明引擎进行深度修改，例如，将其与理论求解器进行接口。 在可预见的将来，这不是我们工作的一部分。

**时间。**即使当前的翻译考虑了计时器，SysML after子句仍未处理。 但是，向ProVerif添加了功能，以便能够对阶段建模，该阶段可能会用于在某种程度上转换这些子句。

将来的其他工作包括对等价性的数学证明和保留安全属性的从设计到可执行的代码过程。