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

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

Info

Publication number
WO2023082340A1
WO2023082340A1 PCT/CN2021/132932 CN2021132932W WO2023082340A1 WO 2023082340 A1 WO2023082340 A1 WO 2023082340A1 CN 2021132932 W CN2021132932 W CN 2021132932W WO 2023082340 A1 WO2023082340 A1 WO 2023082340A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
security
formal
design layer
specific design
Prior art date
Application number
PCT/CN2021/132932
Other languages
English (en)
French (fr)
Inventor
常瑞
黄何
张卓若
李荣泰
戴勤明
毛天宇
Original Assignee
浙江大学
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 浙江大学 filed Critical 浙江大学
Publication of WO2023082340A1 publication Critical patent/WO2023082340A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the invention relates to the field of formal methods, in particular to a method for designing a safe startup scheme of an embedded device based on formal verification.
  • Secure startup refers to starting with a root of trust in the startup phase, and gradually verifying the data and resources at each stage of the startup process through a level-by-level measurement, a level-by-level verification, and a level-by-level trust level. , and finally complete the booting of the operating system and form a complete chain of trust in the process.
  • the present invention proposes a security startup scheme design method based on formal verification, and uses the formal verification method to prove the security and correctness of the scheme.
  • the bootstrap processor (Bootstrap Processor) completes the secure boot process on the current SMP system, and the application processor (Application Processor) is in a dormant state during the boot phase, and wakes up the application processor after the bootstrap processor completes the secure boot process. device.
  • this mechanism creates a serious security hole.
  • an attacker can replace the application processor by implanting a bootkit and tamper with on-chip storage and variable code. Therefore, after the boot processor wakes up the application processor, the attacker can obtain the same level of authority as the boot processor, and even tamper with the system runtime data, which poses a great security threat to the system.
  • the present invention proposes a formal verification-based design method for a secure startup scheme of an embedded device.
  • formal methods are used to analyze the security threats faced by the system, and a high-level security abstract model is established, including system security assumptions and security goals.
  • a function specification model and a formal high-level security requirement model are established. .
  • the object of the present invention is to propose a design method of a secure startup scheme for embedded devices based on formal verification to address the shortcomings of existing startup schemes.
  • the invention discloses a method for designing a safe start-up scheme of an embedded device based on formalized verification. Based on formalized analysis and verification, the security requirements are obtained by analyzing the threat model, and the formalized model is established on this basis, and finally converted into A secure boot solution, and ensure the usability and security of the secure boot solution for embedded devices through a theorem proving method, including the following steps:
  • step 2) Establish security goals based on the threat model: According to the threat model established in step 1), analyze the attacker's attack capabilities, and determine the security goals that the secure startup plan should achieve;
  • step 5 Prove that the function specification model meets the high-level requirement model: prove that the function specification model in step 4) meets the high-level security requirements in step 3); the high-level security requirements in step 3) are taken as the theorem to be verified, and the The defined function specification is used as a predefined condition to try to complete the proof of satisfaction. If it cannot be proved, the content of the function specification model is adjusted until the proof is completed;
  • the specific design layer model is an instantiation of the functional specification model obtained in step 4), that is, the formalized model defined in the functional specification is expressed by using a more specific data structure ;
  • step 6) Prove the refinement relationship between the specific design layer model and the function specification model: prove that the concrete design layer model obtained in step 6) is a refinement of the function specification model obtained in step 4): the function specification of the abstract layer in step 4) As the property to be verified, the specific design layer realized in step 6) is used as a predefined condition. If the formal model of the specific design layer is the refinement of the formal model of the functional specification, the specific design layer can meet the functions defined in the functional specification function, otherwise, adjust the model code of the specific design layer until the formal model of the specific design layer is the refinement of the formal model of the function specification according to the part of the formal model of the specific design layer that is not the refinement of the formal model of the function specification;
  • the security startup scheme is obtained: according to the security startup steps designed in the formal model of the specific design layer, through logical equivalence transformation and optimization of time complexity and space complexity, use programming language to implement efficient secure boot scenarios.
  • the threat model in step 1) of the present invention needs to accurately and reasonably distinguish and define trusted and untrusted components in the startup process, and according to the possible attack behavior of untrusted components, and trusted components
  • the provided security basis accurately describes the security threats that the system may face.
  • the security goal in step 2) of the present invention should be to resolve all threats contained in the security threat model established in step 1) on the basis of security provided by trusted components of the system.
  • the function specification model in step 4) of the present invention includes the state of the processor during the secure boot process and the security functions that should be achieved.
  • the specific events in the specific design layer model in step 6) of the present invention need to include events during the normal execution of the secure boot solution and attack behaviors taken by the attacker.
  • the specific events in the specific design layer model in step 6) of the present invention need to include events during the normal execution of the secure boot solution and attack behaviors taken by the attacker.
  • the present invention provides a solution based on formal verification for the security problems existing in the process of secure startup of embedded system equipment. This method systematically analyzes the problems faced in the process of secure booting, gives a specific design of a secure booting scheme, and gives the proof of the usability and security of the specific scheme by using theorem proving method.
  • the existing research no one has proposed a similar formal method. Compared with the traditional method, the present invention can not only quickly solve the threat in the safe startup process, but also theoretically prove the security and reliability of the scheme.
  • Figure 1 is a flow chart of the design of the embedded device security startup scheme based on the formal method
  • Figure 2 is a state transition diagram of the specific design layer of the scheme
  • the invention discloses a method for designing a safe startup scheme of an embedded device based on formal verification.
  • Symmetric multiprocessing is a computer architecture in which multiple cores in a single processor have a single shared memory space.
  • the secure boot process is completed by the bootstrap processor, and other processors are used as application processors (Application Processor), which are in a dormant state during the boot phase, and wait for the bootstrap processor to complete the secure boot After the process, wake up the application processor.
  • Application Processor Application Processor
  • the embodiment of the present invention provides a method for designing a secure startup scheme for embedded devices based on formal verification, the scheme comprising the following steps:
  • Figure 1 is a flow chart of the design of a secure startup scheme for embedded devices based on formal methods; as shown in Figure 1, it specifically includes:
  • System assets include secure and insecure system components in the secure boot process of the SMP architecture, such as shared memory for boot processor and application processor communication, external storage Flash, which are vulnerable to attackers It is an unsafe asset for attacks, while the Boot ROM stored on the boot processor chip can be considered as a secure asset. ;
  • attack purpose is to replace the application processor to implant a bootkit to tamper with its code, and through this means to monitor, steal or even tamper with the data generated by the program running on the device after the device is started, threatening User privacy;
  • Attack capabilities including replacing the application processor, modifying the storage content in external storage, and hijacking the communication channel between the boot processor and the application processor;
  • Theorem 1 Execute normally when no abnormality is detected, that is, if the device is not attacked, starting from the initial state, the state finally reached after any behavior must satisfy the predefined success property, that is, the boot processor and application processing The devices have completed mutual authentication and established an encrypted channel.
  • Theorem 2 If the initial state configuration error is detected, the execution will be terminated, that is, if the device is attacked, starting from the initial state, the final state reached after any behavior must satisfy the bad property. This theorem can be split into the following two sub-theorems:
  • Theorem 2.2 If the external storage is tampered with, starting from the initial state, the final state reached through any behavior must satisfy the predefined bad property, that is, detect the abnormality of the startup process and exit.
  • step (2) Define the functional specification model of the abstract layer based on the security goal: based on the security goal established in step (2), define the functional specification model of the solution, including the state of the processor during the secure startup process and the security function that should be achieved.
  • the function specification model is defined as a set of descriptions of a state machine and a security function in a secure startup process.
  • the security function is a formal description of the function to be implemented in the final solution in this embodiment.
  • Prove that the function specification model meets the high-level requirement model prove that the function specification model in step (4) can meet the high-level security requirements in step (3); take the high-level security requirements in step (3) as the theorem to be verified, Use the function specification defined in step (4) as a predefined condition to try to complete the proof of satisfaction, if it cannot be proved, then adjust the content of the function specification model until it can complete the proof.
  • the method of formal verification is used to prove that the functional specification model of the abstraction layer satisfies the security requirements defined by it.
  • the theorem proving method is adopted, through logical reasoning, and combined with theorem prover and manual interactive proof to prove.
  • Isabelle/HOL provides the function of automatic proof of theorem and manual interactive proof, but automatic proof is only suitable for simple propositions. When the proposition is more complex, manual derivation and proof are required.
  • the formalized model of the specific design layer is the instantiation of the state machine and events defined in step (4), including the modeling of states, events, and state transitions.
  • (a) Status is a record type field, which contains ROM configuration information, storage configuration information, shared memory, processor data structure and current system status. There are many specific types of the current system state, which can be subdivided into initial state, normal state, error state, attacker state, end state, and abnormal state.
  • An event is a specific representation of the set of event markers in the state machine in the formal specification model of the abstract layer, which is specifically defined as Behavior. These events include reading on-chip storage, verifying certificates, sending and receiving data, and attackers’ attacks on communication channels, etc., including attacker behavior and system behavior.
  • Behavior includes reading on-chip storage, verifying certificates, sending and receiving data, and attackers’ attacks on communication channels, etc., including attacker behavior and system behavior.
  • State transition exec_be is the specific definition of ⁇ : ⁇ P(S ⁇ S) in the function specification model, and its definition is as follows. The definition represents the state after state s executes event be. First, it is necessary to judge state s and event be. If event be cannot be executed in state s, its subsequent state is still s; if event be can be executed in state s, then Specific events need to be executed according to the type specification of be.
  • Fig. 2 is a state transition relationship diagram of the specific design layer of the scheme; in the present embodiment, the specific state transition relationship is as shown in Fig. 2 .
  • This diagram describes all state transition relationships under the system. The system starts from the initial state, and after a series of behaviors, it will finally reach the END state or the ABNORMAL state. State transition only indicates that there is a transition relationship between two adjacent states, and does not mean that a certain state can reach all subsequent states along with the transition relationship. For example, all paths from the INIT state to the END state may pass through the attacker state, but in fact, as long as the attacker state passes through, a certain state will eventually migrate to the ABNORMAL state after executing the verify_packet event, and cannot reach END state.
  • the security verification mechanism can be expressed as that the system reaches a stable state after a series of events (safety verification actions between the boot processor and the application processor) in the INIT state. By determining the nature of the steady state, it can be indicated whether the boot processor and the application processor have completed identity verification.
  • Prove the functional correctness of the specific design layer model define the infinitives that the system needs to satisfy as multiple lemmas through a formal specification language, and prove that the specific design layer model satisfies each invariant lemma to ensure that the specific design layer The functional correctness of the model.
  • the invariants that the system needs to satisfy are, boot processor and application processor (private key), root certificate hash value stored in ROM, root certificate stored in flash, boot processor The public key certificate of the application processor and the application processor will not be tampered with during the authentication process.
  • Prove the refined relationship between the specific design layer model and the functional specification model prove that the specific design layer model obtained in step (6) is a refinement of the functional specification model obtained in step (4): that is, the abstraction of step (4)
  • the function specification of the layer is the property to be verified, and the specific design layer realized in step (6) is used as the predefined condition. If the formal model of the specific design layer is the refinement of the formal model of the functional specification, the specific design layer can satisfy the function Function functions defined in the specification, otherwise, according to the part of the formal model of the specific design layer that is not the refined part of the formal model of the function specification, adjust the model code of the specific design layer until the formal model of the specific design layer is the refined part of the formal model of the function specification. change.
  • step (5) Similar to the proof process of step (5), two methods of automatic proof and manual interactive proof are used for proof, except that the part to be verified here is the security function in the function specification model defined in step (4), and the predefined conditions are For the specific design layer model obtained in step (6). That is to prove that the processor in the specific design layer can finally satisfy the security function defined in step (4) from the initial state, through the defined event and state transition relationship.
  • the security startup scheme is obtained: according to the security startup steps designed in the formal model of the specific design layer, through logical equivalence transformation and optimization of time complexity and space complexity, use programming language to implement an efficient secure boot solution.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

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

Description

一种基于形式化验证的嵌入式设备安全启动方案设计方法 技术领域
本发明涉及形式化方法领域,尤其涉及一种基于形式化验证的嵌入式设备安全启动方案设计方法。
背景技术
近年来,随着万物互联时代的到来,各类智能嵌入式设备在我们的日常生活中有了越来越广泛的应用,甚至在关键的医疗、自动驾驶、航空航天、轨道交通等领域也有着规模化的部署,为用户提供了多种便利服务。然而,在实际应用场景中部署的嵌入式设备通常具有海量、异构、资源受限(如不支持TPS、HSM、SGX enclave等额外的硬件安全特性)等特点,致使这些设备很容易存在能够被攻击者利用的漏洞。一旦某台嵌入式设备存储的数据被窃取或篡改,不仅可能导致其无法正常运行,甚至可能威胁用户的人身安全。因此在确保设备功能正常可用的同时,其安全性亦不容忽视。
安全启动是指,在启动阶段以一个信任根开始,通过一级度量一级,一级验证一级,一级信任一级的方式,逐步的对启动过程中每个阶段的数据和资源进行验证,最终完成操作系统的启动,并在此过程中构成一条完整信任链的方法。通过使用此方法,当系统成功启动时,用户可以确保攻击者未对设备启动过程中涉及的所有数据和资源进行篡改,进而保证系统的安全可信。
本发明的针对现有安全启动流程中存在的安全问题提出了一种基于形式化验证的安全启动方案设计方法,并使用形式化验证的方法证明方案的安全性及正确性。
安全启动已经成为业界共识,但是在方案设计上仍存在不少问题:
(1)虽然针对安全启动的研究越来越多也愈加成熟,但是许多设计方案依然不能有效的保护系统安全。例如,在目前SMP系统上的安全启动流程均由引导处理器(Bootstrap Processor)完成,应用处理器(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)是一种计算机体系结构,在这个体系结构中,单个处理器中的多个核有一个单独的共享内存空间。在此种架构的设备中,安全启动流程由引导处理器(Bootstrap Processor)完成,其它的处理器均作为应用处理器(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事件与执行者关系
Figure PCTCN2021132932-appb-000001
(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)中的具体设计层模型中的具体事件需要包含安全启动方案正常执行时的事件以及攻击者采取的攻击行为。
PCT/CN2021/132932 2021-11-12 2021-11-24 一种基于形式化验证的嵌入式设备安全启动方案设计方法 WO2023082340A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111336512.1 2021-11-12
CN202111336512.1A CN114297659B (zh) 2021-11-12 2021-11-12 一种基于形式化验证的嵌入式设备安全启动方案设计方法

Publications (1)

Publication Number Publication Date
WO2023082340A1 true WO2023082340A1 (zh) 2023-05-19

Family

ID=80964421

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/132932 WO2023082340A1 (zh) 2021-11-12 2021-11-24 一种基于形式化验证的嵌入式设备安全启动方案设计方法

Country Status (2)

Country Link
CN (1) CN114297659B (zh)
WO (1) WO2023082340A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115687166B (zh) * 2023-01-05 2023-04-07 军事科学院系统工程研究院网络信息研究所 一种形式化验证方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070192344A1 (en) * 2005-12-29 2007-08-16 Microsoft Corporation Threats and countermeasures schema
CN104135397A (zh) * 2014-07-01 2014-11-05 浙江工业大学 面向无线传感网安全协议设计与实现的形式化验证方法
CN106708730A (zh) * 2016-11-22 2017-05-24 北京控制工程研究所 一种针对嵌入式实时操作系统形式化验证方法
WO2021057053A1 (zh) * 2019-09-29 2021-04-01 南京大学 一种智能家居物联网系统受攻击安全验证的方法和装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006071985A2 (en) * 2004-12-29 2006-07-06 Alert Logic, Inc. Threat scoring system and method for intrusion detection security networks
US20070157311A1 (en) * 2005-12-29 2007-07-05 Microsoft Corporation Security modeling and the application life cycle
CN102103677A (zh) * 2011-03-09 2011-06-22 天津大学 威胁模型驱动的软件安全评估方法
CN104881606B (zh) * 2015-04-30 2017-12-26 天津大学 基于形式化建模的软件安全需求获取方法
CN109150833A (zh) * 2018-07-19 2019-01-04 华东交通大学 一种基于模型检测的安全协议形式化验证方法
CN109388377A (zh) * 2018-10-08 2019-02-26 广西民族大学 一种基于形式化建模的软件安全需求获取方法
CN111368302B (zh) * 2020-03-08 2024-02-02 北京工业大学 基于攻击者攻击策略生成的自动威胁检测方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070192344A1 (en) * 2005-12-29 2007-08-16 Microsoft Corporation Threats and countermeasures schema
CN104135397A (zh) * 2014-07-01 2014-11-05 浙江工业大学 面向无线传感网安全协议设计与实现的形式化验证方法
CN106708730A (zh) * 2016-11-22 2017-05-24 北京控制工程研究所 一种针对嵌入式实时操作系统形式化验证方法
WO2021057053A1 (zh) * 2019-09-29 2021-04-01 南京大学 一种智能家居物联网系统受攻击安全验证的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Doctoral Dissertation", 30 April 2017, PLA INFORMATION ENGINEERING UNIVERSITY, CN, article CHANG, RUI: "Research on Trusted Execution Environment Construction and Security Defense Techniques for Embedded Devices", pages: 1 - 145, XP009546494 *

Also Published As

Publication number Publication date
CN114297659A (zh) 2022-04-08
CN114297659B (zh) 2024-05-10

Similar Documents

Publication Publication Date Title
Parno et al. Bootstrapping trust in modern computers
Parno et al. Bootstrapping trust in commodity computers
Datta et al. A logic of secure systems and its application to trusted computing
Parno Bootstrapping Trust in a" Trusted" Platform.
Shen et al. Research on trusted computing and its development
JP5455318B2 (ja) 動的信頼管理
Böck et al. Towards more trustable log files for digital forensics by means of “trusted computing”
Larsen et al. Cloudvaults: Integrating trust extensions into system integrity verification for cloud-based environments
CN114651253A (zh) 用于策略强制实施的虚拟环境类型验证
Gallery et al. Trusted computing: Security and applications
CN112511306A (zh) 一种基于混合信任模型的安全运行环境构建方法
Yao et al. Building secure firmware
Zhang et al. Design, implementation and verification of cloud architecture for monitoring a virtual machine's security health
WO2023082340A1 (zh) 一种基于形式化验证的嵌入式设备安全启动方案设计方法
Feng et al. The theory and practice in the evolution of trusted computing
Nauman et al. Token: Trustable keystroke-based authentication for web-based applications on smartphones
Fournaris et al. From hardware security tokens to trusted computing and trusted systems
Ozga et al. Chors: Hardening high-assurance security systems with trusted computing
Msgna et al. Secure application execution in mobile devices
Niemi et al. Platform attestation in consumer devices
Sisinni Verification of software integrity in distributed systems
Jenkins Defense in Depth of Resource-Constrained Devices
Khattak et al. Security, trust and privacy (STP) framework for federated single sign-on environment
Lombardi et al. Security for cloud computing
Haldar Semantic remote attestation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21963784

Country of ref document: EP

Kind code of ref document: A1