CN114297659B - 一种基于形式化验证的嵌入式设备安全启动方案设计方法 - Google Patents

Abstract

本发明公开了一种基于形式化验证的嵌入式设备安全启动方案设计方法，基于形式化的分析与验证，通过分析威胁模型，得到安全需求，并以此为基础建立形式化模型，最终转换成安全启动方案，并通过定理证明的方法确保嵌入式设备安全启动方案的可用性和安全性，本发明针对嵌入式系统设备在安全启动过程中存在的安全性问题，提供了一种基于形式化验证的解决方法。该方法系统全面地分析了安全启动过程中所面临的问题，给出具体的安全启动方案设计，并通过使用定理证明的方法给出具体方案的可用性和安全性的证明，本发明不仅可以快速的解决安全启动过程中的威胁，还从理论上证明了方案的安全性和可靠性。

Description

一种基于形式化验证的嵌入式设备安全启动方案设计方法

技术领域

本发明涉及形式化方法领域，尤其涉及一种基于形式化验证的嵌入式设备安全启动方案设计方法。

背景技术

近年来，随着万物互联时代的到来，各类智能嵌入式设备在我们的日常生活中有了越来越广泛的应用，甚至在关键的医疗、自动驾驶、航空航天、轨道交通等领域也有着规模化的部署，为用户提供了多种便利服务。然而，在实际应用场景中部署的嵌入式设备通常具有海量、异构、资源受限(如不支持TPS、HSM、SGX enclave等额外的硬件安全特性)等特点，致使这些设备很容易存在能够被攻击者利用的漏洞。一旦某台嵌入式设备存储的数据被窃取或篡改，不仅可能导致其无法正常运行，甚至可能威胁用户的人身安全。因此在确保设备功能正常可用的同时，其安全性亦不容忽视。

安全启动是指，在启动阶段以一个信任根开始，通过一级度量一级，一级验证一级，一级信任一级的方式，逐步的对启动过程中每个阶段的数据和资源进行验证，最终完成操作系统的启动，并在此过程中构成一条完整信任链的方法。通过使用此方法，当系统成功启动时，用户可以确保攻击者未对设备启动过程中涉及的所有数据和资源进行篡改，进而保证系统的安全可信。

本发明的针对现有安全启动流程中存在的安全问题提出了一种基于形式化验证的安全启动方案设计方法，并使用形式化验证的方法证明方案的安全性及正确性。

安全启动已经成为业界共识，但是在方案设计上仍存在不少问题：

(1)虽然针对安全启动的研究越来越多也愈加成熟，但是许多设计方案依然不能有效的保护系统安全。例如，在目前SMP系统上的安全启动流程均由引导处理器(BootstrapProcessor)完成，应用处理器(Application Processor)在启动阶段处于休眠状态，等引导处理器完成了安全启动流程后再唤醒应用处理器。然而这种机制造成了严重的安全漏洞。具体来说，攻击者可以通过植入bootkit替换应用处理器，并篡改片上存储和可变代码。因此，在引导处理器唤醒应用处理器后，攻击者可以获得和引导处理器同等级的权限，甚至篡改系统运行时数据，给系统造成极大安全威胁。

(2)虽然形式化的相关技术的应用范围越来越广泛，但是很少有人将其应用到对安全启动的证明上，导致现有的启动方案大多缺乏严格的证明，因此可能存在被忽视的逻辑缺陷或潜在的漏洞。因此为确保设备的启动安全，对其启动方案进行分析和证明，是可有效保证设备启动方案安全性和正确性的手段。近年来，当前产业界以及学术界已经开始认识到对设备启动方案进行形式化分析和证明的重要性和价值，并开展了积极有益的探索，但是目前该领域的研究仍处于初级阶段。

本发明针对上述问题，提出了一种基于形式化验证的嵌入式设备安全启动方案设计方法。为保证最终方案的正确性，利用形式化方法对系统面临的安全威胁进行分析，建立高层安全抽象模型，包含系统安全假设和安全目标，在此基础上建立功能规约模型以及形式化高层安全需求模型。对功能规约模型进行解释，以实例化方式设计实现具体设计层模型。证明具体设计层模型在符合安全需求模型中定义的安全假设的前提下能够满足安全需求模型中定义的安全目标，以保证嵌入式设备安全启动方案设计的正确性和安全性。

发明内容

本发明的目的在于针对现有启动方案的不足，提出了一种基于形式化验证的嵌入式设备安全启动方案设计方法。

本发明的目的是通过以下技术方案来实现的：

本发明公开了一种基于形式化验证的嵌入式设备安全启动方案设计方法，基于形式化的分析与验证，通过分析威胁模型，得到安全需求，并以此为基础建立形式化模型，最终转换成安全启动方案，并通过定理证明的方法确保嵌入式设备安全启动方案的可用性和安全性，包括以下步骤：

1)建立威胁模型：根据嵌入式设备在安全启动过程中所面临的安全威胁、攻击者的攻击手段以及系统中可信和不可信的组件，分析并建立针对系统安全的威胁模型；

2)基于威胁模型确立安全目标：根据步骤1)中所建立的威胁模型，分析攻击者的攻击能力，确定安全启动方案应该达成的安全目标；

3)基于安全目标定义高层安全需求：使用形式化规约语言描述该安全目标，建立高层安全需求模型；

4)基于安全目标定义抽象层功能规约模型：基于步骤2)中确立的安全目标，定义方案的功能规约模型；

5)证明功能规约模型满足高层需求模型：证明步骤4)中的功能规约模型满足步骤3)中的高层安全需求；即将步骤3)中的高层安全需求作为待验证的定理，将步骤4)中定义的功能规约作为预定义条件去尝试完成满足性证明，若无法证明则调整功能规约模型的内容，直至其完成证明；

6)基于功能规约模型进行具体设计层建模：该具体设计层模型是对步骤4)得到的功能规约模型的实例化，即通过使用更具体的数据结构表示功能规约中所定义的形式化模型；

7)证明具体设计层模型的功能正确性：通过形式化规约语言将系统需要满足的不定式定义为多个引理，证明具体设计层模型满足每个不变式引理以保证具体设计层模型的功能正确性；

8)证明具体设计层模型与功能规约模型的精化关系：证明步骤6)得到的具体设计层模型是步骤4)得到的功能规约模型的一个精化：即将步骤4)的抽象层的功能规约作为待验证的性质，将步骤6)实现的具体设计层作为预定义条件，若具体设计层的形式化模型为功能规约形式化模型的精化，则具体设计层能满足功能规约中定义的功能函数，否则根据具体设计层形式化模型不为功能规约形式化模型精化的部分，调整具体设计层的模型代码，直至具体设计层形式化模型为功能规约形式化模型的精化；

9)根据形式化的具体设计层模型分析得到安全启动方案：根据具体设计层形式化模型中所设计的安全启动步骤，通过逻辑等价性转换以及时间复杂度和空间复杂度的优化，使用编程语言实现高效的安全启动方案。

作为进一步地改进，本发明所述步骤1)中威胁模型，需要准确并且合理的区分并定义启动过程中的可信与不可信组件，并根据不可信组件可能遭受的攻击行为，以及可信组件所提供的安全基础，准确描述出系统可能面临的安全威胁。

作为进一步地改进，本发明所述步骤2)中的安全目标应为，在系统可信组件提供的安全基础上，解决步骤1)所建立的安全威胁模型中包含的所有威胁。

作为进一步地改进，本发明所述步骤4)中的功能规约模型包括处理器在安全启动过程中状态以及应该达成的安全功能函数。

作为进一步地改进，本发明所述步骤6)中的具体设计层模型中的具体事件需要包含安全启动方案正常执行时的事件以及攻击者采取的攻击行为。

作为进一步地改进，本发明所述步骤6)中的具体设计层模型中的具体事件需要包含安全启动方案正常执行时的事件以及攻击者采取的攻击行为。

本发明的有益效果：本发明针对嵌入式系统设备在安全启动过程中存在的安全性问题，提供了一种基于形式化验证的解决方法。该方法系统全面地分析了安全启动过程中所面临的问题，给出具体的安全启动方案设计，并通过使用定理证明的方法给出具体方案的可用性和安全性的证明。现有研究中，尚未有人提出类似的形式化方法。相比于传统的方法，本发明不仅可以快速的解决安全启动过程中的威胁，还从理论上证明了方案的安全性和可靠性。

附图说明

图1是基于形式化方法的嵌入式设备安全启动方案设计流程图；

图2是方案具体设计层状态迁移关系图；

具体实施方式

本发明公开了一种基于形式化验证的嵌入式设备安全启动方案设计方法。对称多处理(SMP)是一种计算机体系结构，在这个体系结构中，单个处理器中的多个核有一个单独的共享内存空间。在此种架构的设备中，安全启动流程由引导处理器(BootstrapProcessor)完成，其它的处理器均作为应用处理器(Application Processor)，在启动阶段处于休眠状态，等引导处理器完成了安全启动流程后再唤醒应用处理器。为使本发明的目的和效果更加清晰，下面将SMP系统设备启动过程中对应用处理器身份认证方案的设计过程作为实例，根据附图和优选实施例详细描述本发明具体实施方式。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

结合图1和图2，本发明实施例提供了一种基于形式化验证的嵌入式设备安全启动方案设计方法，该方案包括如下步骤：

(1)建立威胁模型：根据嵌入式设备在安全启动过程中所面临的安全威胁、攻击者的攻击手段以及系统中可信和不可信的组件，分析并建立针对系统安全的威胁模型。

图1是基于形式化方法的嵌入式设备安全启动方案设计流程图；如图1所示，其具体包括：

(a)系统资产：系统资产包括SMP架构安全启动过程中的安全以及不安全的系统组件，例如用于引导处理器和应用处理器通信的共享内存、外部存储Flash，其均为容易遭受攻击者攻击的不安全资产，而存于引导处理器片上存储的Boot ROM可以认为是安全资产。；

(b)攻击目的：攻击者的攻击目的在于替换应用处理器以植入bootkit来篡改其代码，并通过该手段来监控、窃取甚至篡改设备启动后运行在该设备上的程序产生的数据，威胁用户的隐私；

(c)攻击能力：包括替换应用处理器、修改外部存储中的存储内容以及劫持引导处理器与应用处理器间的通信信道；

(2)基于威胁模型确立安全目标：根据步骤(1)中所建立的威胁模型，分析攻击者的攻击能力，确定安全启动方案应该达成的安全目标，在本实施例中具体包括：

(a)确保安全启动过程中应用处理器身份的真实性及合法性；

(b)确保安全启动过程中外部存储中存储内容的完整性；

(c)确保安全启动过程中处理器之间通信信道的机密性。

(3)基于安全目标定义高层安全需求：使用形式化规约语言描述该安全目标，建立高层安全需求模型。在本实施例中将其描述成三个待证明的定理。描述如下：

(a)定理1：未检测到异常时正常执行，即如果设备没有遭到攻击，则从初始状态出发，经过任意行为最终到达的状态一定满足预先定义的success性质，即引导处理器和应用处理器之间已经互相完成认证并建立了加密信道。

(b)定理2：检测到初始状态配置错误则终止执行，即如果设备遭受攻击，从初始状态出发，经过任意行为到达的最终状态一定满足bad性质。此定理可以拆分成以下两条子定理：

(b.1)定理2.1：如果应用处理器被替换，则从初始状态出发，经过任意行为到达的最终状态一定满足预先定义的bad性质，即检测出启动过程异常并退出。

(b.2)定理2.2：如果外部存储被篡改，则从初始状态出发，经过任意行为到达的最终状态一定满足预先定义的bad性质，即检测出启动过程异常并退出。

(c)定理3：检测到通信数据被篡改则终止执行，即从初始状态出发，经过包含针对通信信道攻击行为的行为后到达的最终状态一定满足预先定义的bad性质，即检测出启动过程异常并退出。

(4)基于安全目标定义抽象层功能规约模型：基于步骤(2)中确立的安全目标，定义方案的功能规约模型，包括处理器在安全启动过程中状态以及应该达成的安全功能函数。

本实施例中功能规约模型定义为一个状态机和安全启动过程中安全功能描述的集合。状态机定义为四元组M＝<S,∈,φ,s0>，其中S为状态空间，是所有状态的集合，∈为事件标记的集合，抽象表示协议中各类事件，s0∈S是初始状态，φ:∈→P(S×S)表示状态迁移函数的集合。安全功能为本实施例中最终方案需要实现的功能的形式化描述。

(5)证明功能规约模型满足高层需求模型：证明步骤(4)中的功能规约模型可以满足步骤(3)中的高层安全需求；即将步骤(3)中的高层安全需求作为待验证的定理，将步骤(4)中定义的功能规约作为预定义条件去尝试完成满足性证明，若无法证明则调整功能规约模型的内容，直至其可以完成证明。

使用形式化验证的方法证明抽象层功能规约模型满足于其定义的安全需求。采用定理证明方法，通过逻辑推理，并结合定理证明器与人工交互证明两种方式进行证明。Isabelle/HOL提供了定理自动证明和人工交互证明的功能，但自动证明仅适用于简单命题，当命题较为复杂时，需要人工进行推导和证明。

(6)基于功能规约模型进行具体设计层建模，该具体设计层模型是对步骤(4)得到的功能规约模型的实例化，即通过使用更具体的数据结构表示功能规约中所定义的形式化模型。

在本实施例中，具体设计层的形式化模型是对步骤(4)中定义的状态机以及事件的实例化，包括对状态、事件以及状态迁移的建模。

(a)状态是一个record类型字段，包含有ROM配置信息、存储配置信息、共享内存、处理器的数据结构和当前系统状态。当前系统状态具体类型较多，可以细分为初始状态、正常状态、错误状态、攻击者状态、结束状态和异常状态。

(b)事件是对抽象层形式化规约模型中状态机中事件标记集合的具体表示，其具体定义为Behavior。这些事件包括读取片上存储、验证证书、发送接收数据和攻击者对通信信道的攻击等，包括攻击者行为和系统行为，具体的定义如下表所示：

表1事件与执行者关系

(c)状态迁移exec_be是对功能规约模型中φ:∈→P(S×S)的具体定义，其定义如下。该definition表示状态s执行事件be后的状态，首先需要对状态s和事件be进行判定，如果状态s下无法执行事件be，则其后继状态仍为s；如果状态s下能够执行事件be，则需要根据be的类型规范执行具体的事件。

图2是方案具体设计层状态迁移关系图；在本实施例中，具体的状态迁移关系如图2所示。该图描述了该系统下的所有状态迁移关系。系统从初始状态开始，经过一系列行为，最终将到达END状态或ABNORMAL状态。状态迁移只表明两两相邻状态之间存在迁移关系，并不表示某个状态随着迁移关系能到达其后继的所有状态。例如从INIT状态到END状态的所有路径中，可能经过攻击者状态，但实际上只要经过攻击者状态，其后的某个状态会在执行verify_packet事件后，最终迁移到ABNORMAL状态，而无法到达END状态。安全校验机制可表示为系统在INIT状态下，经过一系列事件(引导处理器与应用处理器间的安全校验动作)，最终到达了稳定状态。通过判定稳定状态的性质即可表明引导处理器与应用处理器是否完成身份的验证。

(7)证明具体设计层模型的功能正确性：通过形式化规约语言将系统需要满足的不定式定义为多个引理，证明具体设计层模型满足每个不变式引理以保证具体设计层模型的功能正确性。

在本实施例中，系统需要满足的不变式即，引导处理器和应用处理器(的私钥)、存储在ROM中的根证书哈希值、存储在flash中的根证书、引导处理器和应用处理器的公钥证书在认证过程中不会被篡改。

(8)证明具体设计层模型与功能规约模型的精化关系：证明步骤(6)得到的具体设计层模型是步骤(4)得到的功能规约模型的一个精化：即将步骤(4)的抽象层的功能规约作为待验证的性质，将步骤(6)实现的具体设计层作为预定义条件，如果具体设计层的形式化模型为功能规约形式化模型的精化，则具体设计层能满足功能规约中定义的功能函数，否则根据具体设计层形式化模型不为功能规约形式化模型精化的部分，调整具体设计层的模型代码，直至具体设计层形式化模型为功能规约形式化模型的精化。

与步骤(5)的证明过程类似，使用自动证明和人工交互证明两种方式进行证明，只是此处的待验证部分为步骤(4)中定义的功能规约模型中的安全功能，预定义条件则为步骤(6)中得到的具体设计层模型。即证明具体设计层中处理器从初始状态开始，经过所定义的事件以及状态迁移关系，可以最终满足步骤(4)中所定义的安全功能。

(9)根据形式化的具体设计层模型分析得到安全启动方案：根据具体设计层形式化模型中所设计的安全启动步骤，通过逻辑等价性转换以及时间复杂度和空间复杂度的优化，使用编程语言实现高效的安全启动方案。

本领域普通技术人员可以理解，以上所述仅为发明的优选实例而已，并不用于限制发明，尽管参照前述实例对发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实例记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在发明的精神和原则之内，所做的修改、等同替换等均应包含在发明的保护范围之内。

Claims (6)

1.一种基于形式化验证的嵌入式设备安全启动方案设计方法，其特征在于，基于形式化的分析与验证，通过分析威胁模型，得到安全需求，并以此为基础建立形式化模型，最终转换成安全启动方案，并通过定理证明的方法确保嵌入式设备安全启动方案的可用性和安全性，包括以下步骤：

1)建立威胁模型：根据嵌入式设备在安全启动过程中所面临的安全威胁、攻击者的攻击手段以及系统中可信和不可信的组件，分析并建立针对系统安全的威胁模型；

2)基于威胁模型确立安全目标：根据步骤1)中所建立的威胁模型，分析攻击者的攻击能力，确定安全启动方案应该达成的安全目标；

3)基于安全目标定义高层安全需求：使用形式化规约语言描述该安全目标，建立高层安全需求模型；

4)基于安全目标定义抽象层功能规约模型：基于步骤2)中确立的安全目标，定义方案的功能规约模型；

5)证明功能规约模型满足高层需求模型：证明步骤4)中的功能规约模型满足步骤3)中的高层安全需求；即将步骤3)中的高层安全需求作为待验证的定理，将步骤4)中定义的功能规约作为预定义条件去尝试完成满足性证明，若无法证明则调整功能规约模型的内容，直至其完成证明；

6)基于功能规约模型进行具体设计层建模：该具体设计层模型是对步骤4)得到的功能规约模型的实例化，即通过使用更具体的数据结构表示功能规约中所定义的形式化模型；

7)证明具体设计层模型的功能正确性：通过形式化规约语言将系统需要满足的不定式定义为多个引理，证明具体设计层模型满足每个不变式引理以保证具体设计层模型的功能正确性；

8)证明具体设计层模型与功能规约模型的精化关系：证明步骤6)得到的具体设计层模型是步骤4)得到的功能规约模型的一个精化：即将步骤4)的抽象层的功能规约作为待验证的性质，将步骤6)实现的具体设计层作为预定义条件，若具体设计层的形式化模型为功能规约形式化模型的精化，则具体设计层能满足功能规约中定义的功能函数，否则根据具体设计层形式化模型不为功能规约形式化模型精化的部分，调整具体设计层的模型代码，直至具体设计层形式化模型为功能规约形式化模型的精化；

9)根据形式化的具体设计层模型分析得到安全启动方案：根据具体设计层形式化模型中所设计的安全启动步骤，通过逻辑等价性转换以及时间复杂度和空间复杂度的优化，使用编程语言实现高效的安全启动方案。

2.根据权利要求1所述的基于形式化验证的安全启动方案设计方法，其特征在于，所述步骤1)中威胁模型，需要准确并且合理的区分并定义启动过程中的可信与不可信组件，并根据不可信组件可能遭受的攻击行为，以及可信组件所提供的安全基础，准确描述出系统可能面临的安全威胁。

3.根据权利要求1所述的基于形式化验证的安全启动方案设计方法，其特征在于，所述步骤2)中的安全目标应为，在系统可信组件提供的安全基础上，解决步骤1)所建立的安全威胁模型中包含的所有威胁。

4.根据权利要求1或2或3所述的基于形式化验证的安全启动方案设计方法，其特征在于，所述步骤4)中的功能规约模型包括处理器在安全启动过程中状态以及应该达成的安全功能函数。

5.根据权利要求4所述的基于形式化验证的安全启动方案设计方法，其特征在于，所述步骤6)中的具体设计层模型中的具体事件需要包含安全启动方案正常执行时的事件以及攻击者采取的攻击行为。

6.根据权利要求1或2或3所述的基于形式化验证的安全启动方案设计方法，其特征在于，所述步骤6)中的具体设计层模型中的具体事件需要包含安全启动方案正常执行时的事件以及攻击者采取的攻击行为。