SysML模型转换验证安全属性

原创于 2025-10-26 09:26:38 发布 · 751 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#SysML # ProVerif # 安全验证 # 模型转换 # 嵌入式系统

SysML模型转换用于安全与安全性分析

摘要

尽管由于各种重大攻击事件，人们对嵌入式系统的安全性和安全性意识 recently 有所提高，但构建一种实用且精确的设计此类安全与安全系统的方法论问题仍未解决。当测试覆盖率不理想时，形式化分析在系统设计阶段发现安全漏洞方面具有更大的潜力。然而，形式化验证方法通常需要较强的技术背景，限制了其应用。本文中，我们形式化地描述了一种验证过程，使其能够证明基于 SysML 的块图和状态机图上的保密性等以安全为导向的性质。通过对这些形式化定义的图到 ProVerif规范的转换进行数学描述，我们得以证明该验证方法的正确性。

关键词

模型驱动工程 · Verification · Safety ·安全性 · Embedded系统

引言

在我们日益互联的世界中，安全性已成为嵌入式系统日益关注的问题。这一观点首先适用于联网车辆或工业系统等关键系统。目前已有许多方法（即方法、模型和工具）可独立于其安全性来评估这些系统的关键方面：例如基于模型检测或构造正确性技术的实时可调度性、形式化验证技术。模型驱动工程通常通过UML图之间的一致性检查或模型到形式化规约算法来考虑安全性方面，以从如统一建模语言图中评估安全性属性。关于安全性方面，常见的做法是依赖专注于安全性的专用模型和工具，例如ProVerif[1]和Avispa[6],，因此这些工具与与安全相关的模型和工具不兼容。结果，安全性往往被视为使用合适工具的正确方式，甚至被完全忽略。然而，当现成的加密解决方案不适用，特别是当资产或通信的重要性被误解时，这会导致更隐蔽的缺陷。此类安全性

当受影响的设备数量较少且漏洞易于修复（例如通过软件补丁）时，问题可能较小。然而，对于嵌入式系统而言，情况通常并非如此，因为设计缺陷可能无法修复，并会影响一系列产品。即使在产品发布之前就发现了安全性漏洞，重新思考整个架构所需的工作量也可能大到难以承受。

为了便于设计具有安全需求的关键系统，我们建议在与安全相关的模型中增强安全性机制，并从同一模型提供从安全到形式化规范以及从安全到形式化规范的转换。本文介绍了支持安全性和安全性的系统建模语言‐Sec环境。然后，我们详细阐述了最初在[16]中简要描述的系统建模语言‐Sec模型到安全形式化规范的转换。该转换算法具有重要价值，因为它使我们能够在通用设计模型上执行安全验证，从而避免容易出错的模型重复。然而，该转换算法此前尚未被形式化描述。本文给出了该转换算法的形式化描述，以证明该方法的正确性。

在整个论文中，我们将通过一个教学示例来说明建模和验证的不同阶段。尽管该示例被有意简化至最基本程度，以便读者能够轻松参考，但它仍可作为更复杂的实际设计的一部分使用。在所呈现的场景中，两个参与者（称为爱丽丝和鲍勃）通过不安全（公共）信道进行通信。爱丽丝反复向鲍勃发送敏感数据。这些消息在通过公共信道传输之前由爱丽丝加密。这两个参与者事先共享了一个加密密钥，我们假设密钥共享的方式无需建模。实际上，该密钥可能是通过物理方式共享的，或者基于非对称密钥材料（例如通过Diffie‐Hellman协议）生成，或者由可信第三方提供给爱丽丝和鲍勃。爱丽丝用于加密其通信的密钥会周期性更换，因此每次都会创建新密钥。每当爱丽丝发送一条新消息时，她都会附上新创建的密钥，以便鲍勃能够解密下一条消息。我们通常希望验证潜在攻击者无法通过窃听和篡改公共信道上的消息来获取爱丽丝发送的数据。其他更复杂的安全协议和系统也已使用本文所述的方法进行了建模和验证。

该验证方法使我们能够在可接受的时间内（在通用计算机上少于5分钟）对这些模型证明保密性和真实性属性。我们不会在本文中详细说明这些案例研究，但建议感兴趣的读者访问SysML‐Sec网站1，相应的模型可免费获取。

本文组织如下：在第2节中，我们介绍了所采用的方法论，并给出了建模语言（一种SysML配置文件）的形式化描述。第3节介绍了基本模型ProVerif语言，并给出了SysML模型到ProVerif模型的转换。第4节用于

示意图0

2 SysML‐Sec语言

SysML‐Sec[5]是一种遵循模型驱动方法的建模语言，用于设计具有安全性、安全性和性能约束的嵌入式系统。选择该建模语言是因为它能够使用户分析系统将要实现的行为，并专门针对嵌入式系统。此外，它由一个免费开源工具支持，且本文提出的算法已集成到该工具中。

设计一个应用：基本上，SysML‐Sec 支持两个主要的建模阶段：
1. 系统级软硬件划分阶段包括捕获目标应用的功能元素，建模候选架构，并最终将功能元素（包括功能间通信）映射到候选架构上。随后是验证子阶段，在该阶段评估安全性、安全性和性能约束，以选择“最佳”的软硬件划分。2. 在成功完成划分阶段后，进入软件设计阶段。首先，由前一阶段映射到处理器节点的高层函数构建软件组件，然后逐步进行细化。细化通常涉及对算法和协议（包括安全协议）的精确描述。

两个阶段的设计元素均基于（安全性和安全性）需求构建。在所有建模阶段都支持验证，以评估安全性和安全性需求。攻击树还有助于捕获在所考虑的映射模型中可行的潜在攻击。

TTool 是一款支持 SysML‐Sec 各个阶段和模型的免费开源工具。它提供了一键式方法，用于安全性、安全性和性能验证，并能将验证结果回溯到建模视图。

软件设计验证

如下所述，软件设计基于通信模块构建，其行为通过状态机图进行描述。软件设计验证旨在评估安全与安全属性的满足情况。安全验证检查大量属性，包括安全性（例如无死锁）和活性（例如可达性）属性。这些属性可以通过时态逻辑语言的一个子集（例如 CTL）建模，也可以通过模型中的观察器进行建模，这些观察器以状态机图表示。TTool 依赖于 UPPAAL 模型检测工具来进行验证。

2.1 语法

在软件设计阶段，SysML‐Sec 图旨在描述一个软件设计。本节提供软件设计的正式定义。

定义1 设计
设计由通过链接互连的构件网络和一组指令定义： D= 〈B,C,P〉其中 B是一组构件， C是一组通道， P是一组指令。

图1显示了两个构件爱丽丝和鲍勃以及两者之间由光照派符号表示的公开链接。本文中不提及数据类型，因为就安全性分析而言，它们仅起到语法糖的作用。

SysML构件由一组方法和属性组成。通信端口可以附加到构件上，每个端口都附有接口和信号[12]。为简便起见，我们直接将信号附加到SysML构件上。

定义2 构件
一个构件是一个元组：构件 = 〈标识符 A,M,S,行为〉其中
– ident 是一个构件名称。– A 是一组属性。– M 是一组方法。– S 是一组有向信号。对于每个 s ∈S，类型(s) ∈{in, out}。– 行为是一个状态机图。

我们定义一个函数block，对于给定的设计 D，返回其构件的集合；并定义函数sig和att，分别用于返回给定构件b的信号和属性集合。

定义3 通道
一个通道在构件之间连接信号：通道=〈类型 R〉，其中类型是一种物理属性，可以是私有或公开，并且 R是两组信号之间的一一对应关系， R ⊆ sig(b1)×sig(b2)，其中 b 1, b 2 ∈ block(D)满足 ∀(s1, s 2) ∈R，类型(s1) ≠ 类型(s2)。

系统建模语言设计支持语用标记的概念。指令使我们能够描述系统在初始状态下的属性，并查询将在验证期间检查的设计属性。为了简化此描述，我们将仅考虑两种类型的指令：‐ 表示在执行开始时两个属性具有相同的值（Pinit）；‐ 查询属性的保密性（ Psecret）。

定义4 语用标记
设 D为一个设计。我们定义一个语用标记为一对： P= (Pinit, Psecret) 其中 Pinit⊆(⋃b∈block(D) att(b))² and Psecret⊆⋃b∈block(D)att(b)

状态机图是一种将变量命名为属性的带标签的转换系统；状态机图可以在转换上具有属性的守卫和赋值。属性可以被操作、定义或访问。令 f表示函数名f， xi表示变量名，c为通道名c。状态机图中动作项的集合 Actions定义如下：

a ∈ Actions ::= f(x1,..., xn) function call
             | x := exp assignment expression
             | c〈x〉 input action
             | ¯c〈x〉 output action
             | ν.x random action
             | ε empty action

系统建模语言‐Sec中的表达式（exp）可以是变量和函数调用（x和f(x1,…, xn)）。

集合 Guards是布尔表达式的集合。

定义5 状态机图
状态机图是一个有根有向图：行为= 〈Q, q0, q⊥, E〉其中
– Q 是一组节点。
– q0 ∈ Q 是一个初始状态节点。
– q⊥ ∈ Q 是一个（可能为空的）终止状态节点。
– E ⊆ Q× Guards× Actions× Q。

设计者为每个状态赋予一个名称。我们定义一个标注函数L，用于返回给定状态的名称。对于一条边 e=(q, g, a,q ′)，我们定义函数source(e)= q、guard(e)= g、action(e)= a以及 target(e)= q ′。一个跟踪 σ ∈ Actions∗是动作的一个序列 a0 a1, … an，使得存在一个状态序列 q0 q1, … qn，并且对所有 i= 1,…, n满足(qi−1, g, ai, qi) ∈ E。

活动图的语法约束

TTool 对状态机图施加了一些基本属性，即：
1. 初始状态节点只能出现在边的源端。
2. 终止状态节点只能出现在边的目标端。
3. 对于任意状态节点，都存在一条从初始状态节点到该节点的路径。
4. 任何不同于终止状态节点的状态节点都至少有一个输出转换。

我们引入基本块的概念，该概念将用于我们的转换中。一个基本块可以被视为一个子设计，它具有唯一的入口点，并可通过多个点触发。具体而言，它是一个连通的子图，其中所有状态都恰好有一条输入边，但有一个状态例外，我们将其命名为根。我们将使用 Out函数，该函数返回从给定状态出发的所有输出转换。我们还定义了一个谓词 UniqueOut和 UniqueIn，它们接收一个状态 q作为参数，仅当没有两条不同的转换分别以 q作为源状态和目标状态时才返回真。

UniqueOut(q) ⇔ (∀(q1, g1, a1, q′1),(q2, g2, a2, q′2) ∈ E. q1= q ∧ q2= q ⇒ g1=g2 ∧ a1= a2 ∧ q′1= q′2)
UniqueIn(q) ⇔ (∀(q1, g1, a1, q′1),(q2, g2, a2, q′2)∈E. q′1= q ∧ q′2= q ⇒ q1= q2 ∧ g1=g2 ∧ a1= a2)

图2a 和 b 分别展示了爱丽丝和鲍勃的两个状态机图的图形表示。注意，图中未显示空动作和“true”守卫。状态用彩色框表示（初始状态除外，它用圆形表示），转换用箭头表示，动作则通过箭头旁边的文字表达式（用于函数调用和赋值表达式）或具有不同形式的白色框（用于其他类型的动作）来表示。例如，爱丽丝的状态机由一个初始状态通过空转换连接到名为 generateNewKey的状态组成。该状态通过带有 4 个动作的转换连接到另一个状态 sendSecret：一个随机动作和 3 个赋值表达式。另一个转换从sendSecret 连接到 generateNewKey，并带有一个输出动作。注意，在图中，每个转换上有多个动作。这在语义上等价于多个链式转换，每个转换仅带有一个动作和一个true守卫。

3 从 SysML‐Sec 到 ProVerif

我们的目标是提供一个使用系统建模语言（SysML）设计安全且可靠系统的环境。我们的计划是为系统建模语言的行为语义提供形式化定义，并生成用于安全分析的标准代码。本节描述了支持安全分析的系统建模语言设计的行为语义。

3.1 ProVerif语言

ProVerif [7]是一种在符号模型上运行的密码协议验证工具。ProVerif规范采用一种遵循明确定义的结构[8]的自定义语言进行描述。它由一系列声明和一个进程组成。我们的翻译使用了ProVerif语言核心，仅排除了部分声明。具体而言，它涵盖了以下特性，这些特性构成了用于生成安全性分析的良构代码的完整语言：
– Function声明（由fun和reduc关键词引用）。它们通常用于描述密码学原语，如hash、symmet-ric encryption等，且不依赖于我们正在转换的具体设计D。
– 变量声明（用通道和free关键字表示）。它们声明了所有参与者共享的通道和其他变量，这些变量可以是公共的或私有的。
– 查询（由query关键字表示），用于表达用户希望在设计上证明的安全属性。
– 子过程声明（由let关键字表示）。每个子过程声明包含设计中部分状态机图的行为描述。它们可被其他子过程或主进程引用。如果没有任何引用，则会被忽略。
– 主进程（由process 关键字表示），是设计的入口点。它可以引用任意子过程。

ProVerif代码示例的全局结构如清单1.1所示。

特别是，我们看到一个构造器声明（sencrypt），一个析构器声明（ sdecrypt），两个共享变量声明（token Bob 0和token Alice 0），一个保密性查询，一个子进程的声明（Bob 0）以及主进程，该主进程创建一个新的私有名称（Alicekey data）。

(*函数 *)
fun sencrypt (位串, 位串): 位串。
reduc 对所有 x : 位串, k : 位串; sdecrypt (sencrypt (x ,k ),k )=x .
...
(*变量 *)
free 令牌 Bob 0:位串 [私有 ]。
free 令牌爱丽丝 0:位串 [私有 ]。
...
(*查询 *)
query attacker(new爱丽丝 secret data)。
...
(* Sub-processes *)
let 鲍勃 0=
new strong Bob 02 ：位串 out(chControl , strong Bob 02 );
...
(* Main process *)
process
new爱丽丝 key data:位串 ...

清单1.1. ProVerif 文件的全局结构

SysML模型转换用于安全与安全性分析

3.2 将SysML‐Sec设计D转换为ProVerif

我们现在给出SysML‐Sec设计的语义，该语义表示为从SysML‐Sec设计到 ProVerif规范的转换。对于每个SysML‐Sec设计D，解释函数表示为如下形式：
$$ \llbracket D \rrbracket_E = F_E(D) \oplus V_E(D) \oplus Q_E(D) \oplus P_E(D) \oplus “\text{process}” \oplus \text{Main}_E(D) $$
它依赖于多个辅助函数来表达设计中特定部分的语义。该语义的核心实体包括五个函数：$F_E(D)$ 用于生成函数集合， $V_E(D)$ 用于生成变量集合，$Q_E(D)$ 用于从指令中生成查询集合，$P_E(D)$ 用于生成进程集合，以及 $\text{Main}_E(D)$ 用于生成管理其他进程全局实例化的主进程。这些函数的构造依赖于称为环境的概念，记为 $E=(E_q, E_v)$，用于记录在状态机遍历过程中需要访问的状态（$E_q$）和已经访问过的状态（$E_v$）。

在定义解释函数之前，引入一些符号会有所帮助。我们使用引号（”）字符来表示字符串的开始和结束（对应于ProVerif指令）。相邻放置的带引号的字符串通过 $\oplus$ 操作符连接，以生成完整的字符串（完整源代码）。
$\vec{a}_{a \in S}$ 表示在集合 $S$ 上的参数列表。

(1) 声明部分

函数
它们包含可在所有SysML‐Sec设计中使用的常见密码学原语列表。此外还包括用于保护变量的附加函数 tok 和 untok ，以及为每个私有通道添加的一对加密与解密函数。

变量
它们由三种类型组成：用于公共通信的通道、控制消息的通道（由 chctrl 引用）以及每个基本的变量构件（由 令牌... 引用）。请注意， 令牌... 变量只有在子过程生成后才能生成。

查询
本文重点关注保密性属性。对于设计者希望检查其保密性的每个变量 $v$，我们生成形式为 "query attacker(new v)" 的查询。

(2) 过程生成

子过程
它们通过遍历SysML‐Sec设计中每个基本块的状态机图生成。为此，解释函数依赖一个待访问状态的队列 $E_q$，该队列初始化为包含每个基本块的根状态，以及一个列表 $E_v$，用于记录所有已被访问的状态（初始为空）。当存在未探索的状态时，从 $E_q$ 集合中选取一个状态 $s$，将其加入已探索集合 $E_v$，并通过调用第一个函数 $\llbracket s \rrbracket^p_E$（见表1）创建一个子过程。其思想是，翻译函数从根开始遍历整个基本块，并在遇到每个构造符时调用相应的解释函数生成 ProVerif指令。所有解释函数均在表1中定义。这些函数使用术语“新鲜变量”，意味着该变量是全新的，在代码其他任何地方均未出现，仅在其创建指令中存在。非正式地讲，如表1所述，解释函数将状态翻译为用于可达性查询的相应 ProVerif事件；将转换翻译为守卫对应的条件语句($\llbracket .,. \rrbracket^t_E$)，以及动作对应的 ProVerif指令($\llbracket .,. \rrbracket^a_E$)。后续状态的翻译延续由$\llbracket . \rrbracket^c_E$函数完成。有两个解释函数需要特别注意：具有多个输出转换的情况，以及连接两个不同基本块状态的转换。
对于前者，生成的ProVerif进程会为每条可能的转换生成一个令牌，并使其对攻击者可见($\llbracket . \rrbracket^m_E$)，然后通过要求攻击者接受其中一个令牌来触发路径。对于后者，进程也会生成一个令牌($\llbracket . \rrbracket^b_E$)，该令牌必须包含当前块的状态（以其属性描述）以及要调用的基本块的标识符（即令牌变量）。为了防止攻击者重放之前的令牌，令牌中包含由被调用方颁发的随机数。该令牌通过封装到私有函数 tok 中，以防止攻击者篡改或窥探。

主进程
然后将主进程附加到ProVerif规范的末尾。其目的是首先为每个状态机创建一个唯一的 tok(...) 消息，以便攻击者可以调用2对应于每个基本块的进程，其中该基本块的根是状态机的初始状态。为了为每个构件创建令牌，主进程需要实例化该构件的属性，等待一个随机数并发送令牌。然后，它并行运行（由 $|$ 操作符表示）所有已创建的进程，并无限次执行（由 ! 操作符表示）。

$$
\text{Main} E(D)=\left( \bigoplus {b \in \text{block}(D)} \left( \bigoplus_{a \in \text{att}(b)} “\text{new } a;” \oplus “\text{in}(chctrl, nonce); \text{out}(chctrl, \text{tok}(\text{token } L(q_0), \text{nonce}, \text{args}))” \right) \right) “|||” \bigoplus_{q \in E_v} “! \text{proclabel } L(q)”
$$
其中 $\text{args} = \vec{a}_{a \in \text{att}(b)}$

4 验证

本节的目的是提供论据以验证本文所给出的语义。第一部分形式化地证明了我们没有引入任何

我们的翻译过程中的新信息；第二部分通过一个示例来展示我们的翻译在实际中如何工作。

4.1 正确性定理

我们首先证明了转换算法的可靠性：如果在软件设计中存在秘密信息泄露的可能，则在ProVerif规范中也存在相应的泄露。转换算法的可靠性表明，由 $\text{Main}_E(D)$ 生成的每个ProVerif代码均符合软件设计 $D$ 的保密性属性。

命题1
如果项 $M$ 在SysML-Sec模型中是一个秘密，则 $M$ 在生成的ProVerif规范中也是一个秘密。

证明通过对SysML‐Sec模型所有可能的执行轨迹长度进行归纳完成（详细证明见[15]）。

为了检查保密性等属性，ProVerif 会尝试通过查找所有可能导致该属性被违反的执行轨迹，在一种近似模型中进行证明。由于在一般情况下已证明在 Dolev‐Yao 模型中证明保密性问题是不可判定的 [4,10]，因此需要这种近似模型；该模型的构造确保了在实际模型中的每条可能轨迹都会在近似模型中产生一条可能的轨迹。因此，ProVerif 可以给出三种类型的结果（此处以保密性为例）：
– 属性为true。ProVerif 在近似模型中未发现导致属性违反的跟踪。由于该近似是可靠的，这意味着该属性在真实模型上也为真。
– 属性为false。 ProVerif 在近似设计中找到了一条跟踪，并成功构造了在真实模型上对应的跟踪。所找到的跟踪将由 ProVerif 随结果一并提供。
– 属性为cannot be proved。ProVerif 在近似设计中找到了一条跟踪，但该跟踪无法对应到真实模型上的有效跟踪。在此情况下，ProVerif 无法得出结论，但会返回近似模型上的跟踪，以便设计者判断该跟踪是否对应一条有效跟踪。

我们保留这三种可能的结果，并通过TTool界面提供给设计者。

4.2 TTool中的验证结果

为了使设计者能够同时查看先前的验证结果并据此继续建模，验证结果将显示在设计者所构建的图上。可达性、保密性和真实性的验证结果以绿色（当属性成立时）或红色（当属性不成立时）的形式显示在构件图和状态机图上。

此外，为了便于调试，在信息可用的情况下，系统会向设计者提供一条跟踪路径，说明该属性为真（例如某个状态是如何可达的）或为假（例如密钥是如何被泄露的）。该跟踪路径基于 ProVerif 生成的跟踪自动构建，并以序列图形式显示。因此，该跟踪展示了参与者（所有构件和攻击者）之间交换的消息以及每个构件所经历的状态。如图3b 所示，我们可以看到鲍勃的状态机中的已接收状态是如何通过接收爱丽丝发送给鲍勃的消息而到达的，该消息包含数据： (sencrypt((爱丽丝的密钥, 爱丽丝的新密钥), 爱丽丝的密钥)) 。

5 相关工作

在设计软件组件时评估安全性属性主要依赖于形式化方法。例如，[20]提出使用概率分析方法来验证加密协议。这些协议被表示为树结构，其中节点捕获知识，边被赋予转移概率。尽管这些树可以包含恶意代理以建模攻击和威胁，但安全性属性并未被显式表示。此外，对于威胁分析，攻击需要被明确表达并手动求解。[21]定义了一组用于实现安全目标的形式化基本安全服务。在此方法中，安全属性分析高度依赖设计者的经验。而且，威胁评估难以有效进行。目前存在多种安全性属性的形式化验证方法。其中大多数方法并非自动化，也无法作为工程工具使用，例如 [9,17] 和 [2]。在我们所知的面向工程的安全验证研究中，最接近的是 [13,14] 和 [19]。UMLsec[13] 是一个建模框架，旨在统一建模语言框架内定义软件组件的安全属性及其组合。它还提供了一个相当完整的框架，涵盖从安全需求规范到测试的模型驱动的安全软件工程各个阶段，包括

基于逻辑的形式化验证，涉及软件组件的组合。在 [14], 科迪等人提出了攻防树的形式化描述。在这些图中，攻击者与系统（防御者）之间的交互被建模为攻击和对抗措施。从这个意义上说，我们的方法有所不同，因为它依赖于攻击者能力以及对系统行为的描述，这意味着本文提出的验证算法能够在无需预先了解攻击形式的情况下，证明某一设计针对某类攻击者是安全的。另一方面，攻防树上的验证算法只能证明某种对抗措施对特定攻击是有效的。最近，[19] 开发了一种扩展的UML模型，扩展了UML的序列图用于安全协议验证。他们的方法包括将模型转换为ProVerif，以验证保密性和对应性。虽然序列图特别适合评估观测等价性属性，因为它们展示了参与者之间交换的消息，但本文所使用的状态机图能够更直观地建模精确的行为属性（例如条件语句或循环）。此外，我们的过程还包括弱真实性和强真实性的验证。

本文在之前关于SysML‐Sec的出版物基础上进行了扩展，提出了如何更好地对某些情况（例如循环）进行建模，并改进了其模型到ProVerif的转换，同时考虑了ProVerif的能力和局限性。因此，我们在不影响SysML‐Sec图的验证能力的前提下，成功减少了安全属性证明失败的情况。

6 结论

本文描述了一种用于嵌入式系统（安全性）和安全性的建模与验证的形式化且新颖的模型驱动方法。文章本身重点关注形式化的系统建模语言到ProVerif的转换，并概述了该方法可靠性的证明。最后但同样重要的是，这种新转换已集成在TTool中，并包含反向追踪功能。整体方法通过一个示例进行了说明。然而，该方法已成功应用于多种系统，包括TLS协议的认证与非认证版本、消息应用如Signal/Telegram所使用的X3DH协议实现、面向Intel SGX架构的密钥交换协议，以及自动驾驶汽车的嵌入式架构设计。我们的形式化描述为未来等价性或可靠性证明奠定了框架基础。ProVerif的证明局限性也可通过其他证明技术加以解决，例如基于Prolog的方法。