CN117633795A - 基于可信执行环境的内部接口用无干扰性系统 - Google Patents

基于可信执行环境的内部接口用无干扰性系统 Download PDF

Info

Publication number
CN117633795A
CN117633795A CN202311585708.3A CN202311585708A CN117633795A CN 117633795 A CN117633795 A CN 117633795A CN 202311585708 A CN202311585708 A CN 202311585708A CN 117633795 A CN117633795 A CN 117633795A
Authority
CN
China
Prior art keywords
tee
interface
state
state machine
machine model
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202311585708.3A
Other languages
English (en)
Inventor
张强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ningbo Qianchuan Technology Co ltd
Original Assignee
Ningbo Qianchuan Technology Co ltd
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 Ningbo Qianchuan Technology Co ltd filed Critical Ningbo Qianchuan Technology Co ltd
Priority to CN202311585708.3A priority Critical patent/CN117633795A/zh
Publication of CN117633795A publication Critical patent/CN117633795A/zh
Pending legal-status Critical Current

Links

Classifications

    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Storage Device Security (AREA)

Abstract

本发明公开了基于可信执行环境的内部接口用无干扰性系统，涉及接口管理领域，其技术方案要点包括：对原有TEE系统的内部调用接口进行了重新设计，使其满足快速形式化验证框架的要求；其次，确定代码抽象和要验证的层级，对这部分接口进行状态机建模以及TEE接口间的无干扰性建模，形成系统要满足的状态机规约和系统属性规约；状态机模型或者说状态机规约是系统接口设计的依据和基础，使用Python创建TEE系统的状态机模型，以及通过一阶逻辑表达式表示的无干扰性系统上层属性；最后，使用验证框架对修改后的TEE内部接口其进行推理验证，得到最终正确的求解，实现了满足TEE内部接口无干扰性的TEE系统设计。

Description

基于可信执行环境的内部接口用无干扰性系统
技术领域
本发明涉及接口管理领域，更具体地说，它涉及基于可信执行环境的内部接口用无干扰性系统。
背景技术
伴随着IoT的快速发展，移动设备的应用发生了质的改变，人们可以使用手机进行网上购物以及在线转账和消费支付，这些对敏感信息的操作，使人们对移动设备的安全性也有了更高的要求，可信执行环境技术作为移动设备安全的重要技术发挥了重要作用。
目前，主要的芯片厂商Intel的SGX和ARM的TrustZone都提出了自己的可信执行环境方案，尤其是基于ARM的TrustZone技术，由于移动设备对ARM架构的依赖，使得基于ARMTrustZone架构的可信执行环境移动设备更是比比即是，国内外的研究机构和企业单位也纷纷推出了自己的可信执行环境系统，包括国外企业中的Trustonic的T-base、高通的QSee和Linaro的OP-TEE；国内也涌现出了研发TEE的相关企业，包括瓶钵的TrustKernel和沈阳豆荚科技的ISEE；科研单位也发布了各自的TEE系统，包括赫尔辛基大学与Intel合作研发的Open-TEE以及格拉兹技术大学的Andix OS。
随着GPTEE标准的提出，不仅对TEE设计、接口、保护轮廓等进行了规范，也对可信执行环境的安全有了更多的要求。然而，随着TEE技术的发展，大量的可信执行环境相关漏洞也被频繁的暴露出来。可信执行环境的安全性备受质疑。因此，提升可信执行环境本身的安全性刻不容缓。
传统测试框架都是从与TEE对应的REE发起，来判断TEE本身的功能是否正确，且测试用例十分有限，目前暴露的有关TEE系统的漏洞主要集中在REE与TEE的通信接口，而TEE内部相关安全问题的研究较少。其原因主要是TEE本身是一个非常复杂的系统，涉及到软硬件的协同操作。软件本身又非常的大，涉及到操作系统、切换、各种服务和可信应用。无疑给整个系统的安全性带来了问题。同时，传统的测试方法只能保证提供有限的测试用例，无法覆盖系统的所有路径。
采用形式化方法对软件系统进行验证是公认的最有效的安全手段。也有部分前人针对于TEE进行了相关的形式化工作，信息流安全性作为TEE系统的重要属性已经在GPTEE相关标准中明确提出，但根据调研发现，目前还没有针对TEE系统内部接口的信息流控制策略的形式化验证方法和案例，GlobalPlatform(GP)TEE内部接口标准规定，TEE内部的各可信应用TA之间要满足隔离性，不允许将不同TA的敏感信息泄露给对方，这一属性要求TEE满足信息流的无干扰性，即，不同的TA之间不存在隐蔽通道。
传统的验证方法要求从规约入手，逐渐精化，再使用验证系统验证不同层次的求精关系，同时验证每一层都满足上层属性规约的要求。然而，传统的验证方法需要开发者具备一定的逻辑推理基础和经验，同时验证效率不高，对于使用Hyperkernel框架验证TEE内部接口也有许多困难，一方面，因为TEE系统庞大且复杂，分层众多，在抽象时，如果抽象的层级过高，则无法对相关要保护的敏感信息进行建模，如果抽象层级过低，则增大了形式化验证难度，故而，如何对TEE系统中及内部接口层进行精确抽象成为一个难题，另一方面，TEE原有接口的实现比较复杂，无法实现基于快速形式化验证框架的验证，因此，基于上述问题，本发明对可信执行环境的内部接口进行无干扰性系统设计。
发明内容
针对现有技术存在的输液速度过快或者过慢以及药液温度与体温温差给病患带来的不适的问题，本发明的目的在于提供基于可信执行环境的内部接口用无干扰性系统，实现输液过程中输液速度和输液温度的调控。
为实现上述目的，本发明提供了如下技术方案：
基于可信执行环境的内部接口用无干扰性系统，所述内部接口用无干扰性系统包括处理层：
数据层用于TEE内部接口无干扰性的设计，具体包括以下步骤：
S1步骤：对原有TEE系统的内部调用接口进行了重新设计，使其满足快速形式化验证框架的要求；
S2步骤：确定代码抽象和要验证的层级，对这部分接口进行状态机建模以及TEE接口间的无干扰性建模，形成系统要满足的状态机规约和系统属性规约；
S3步骤：使用验证框架对修改后的TEE内部接口其进行推理验证，得到最终正确的求解。
优选的，所述S1步骤中，TEE内部包含TA接口和TEE内部接口两种类型的通信接口，当调用TA_invokeCommandEntryPoint接口后，TEE通过指定TA完成REE端请求的相关操作，TA启动后，可以通过TEE_internal_API来访问TEE中的各种资源和服务，完成REE Client端的功能；TA还可以通过TEE_Client_API来启动其他TA帮助完成REE Client端的功能，根据GP标准规定，可信应用是可信的，但必须保证可信应用之间的强隔离性，不允许敏感信息从一个TA流向另外一个TA，TEE系统内部接口的有限接口设计，具体工作过程包括以下步骤：
步骤S11：对资源进行静态管理：objectID以固定长度的字符串来管理，即使用最大的objectIDLen存储objectID对象，并通过数组的方式分配固定个数objectID，对于TEE_ObjectHandle对象，也使用数组来存储，通过静态分配的方式供TA申请；
步骤S12：对当前接口进行细粒度的拆分，形成多个简单的元操作：由TA开发者负责完成对该接口的实现功能，针对于此接口，将其拆分为参数验证元操作、数据块读元操作、MAC值校验元操作和TEE对象申请元操作；
步骤S13：TA负责数据的循环读取操作，TEE系统只提供读取块的系统接口；
步骤S14：将一些具体操作放到底层，接口层负责调用：MAC值的运算通过调用加解密服务来完成。
优选的，所述S2步骤中，其无干扰性定义为：
定义1：output(run(s0,α),a)＝output(run(s0,purge(α,dom(a))),a)
其中，S：状态集合；
A:action集合，也是状态转化函数集合；
O:输出结果集合；
D:安全域集合，实例中的安全域包含蓝色和粉色两个进程实体；
a:action；
s0：初始状态；
α:action序列；
step:S×A→S，指在状态S下执行一次action调用；
output:S×A→O,指在状态S下执行一次action调用后的输出结果；
dom:A→D,指为每个action分配一个安全域；
run:S×A*→S,状态S在经过一系列的action后迁移到另外一个状态；
purge:A*×D→A*，移除掉所有对安全域D有影响的actions序列之后得到的action序列。
优选的，所述定义1进行验证时，需要对所有的action，即TEE内部API自由组合进行求解，并根据输出结果的比较得到满足干扰性的求解，根据Unwinding定理验证每一个action，简化推理过程，且满足如下性质：
输出一致性：
步伐一致性：
局部满足策略：
对三个性质进行程序解释之前需要对安全域等价性进行定义，即～u可以通过定义dom_equal(s1,s2)函数来表示：
def dom_equal(s1,s2):
return z3.And(s1.currentTA＝＝s2.currentTA,
s1.TAs_Count＝＝s2.TAs_Count,…))
在此基础之上，步伐一致性可以通过一阶逻辑的方式表示为如下：
z3.ForAll([s1,s2],z3.Implies(dom_equal(s1,s2),dom_equal(trans(s1),trans(s2)))
优选的，所述TEE内部API的信息流策略，局部满足策略，要根据TEE系统的信息流访问策略来制定，TEE_internal_API只适用于可信应用内部的调用，基于GP接口的信息流策略：信息可以通过TEE_Client_API在不同的TA之间流通，针对于每个TEE_internal_API，不允许信息从一个TA流向另一个TA，TEE系统的这种隔离性使用Python规约来简要描述，可以表示为如下代码：
class Trust_APP_Domain:
def__init__(self,uuid):
self.uuid＝uuid
#信息流策略
def info_flow_to(self,other,action):
if self.uuid＝＝other.uuid&&action in TEE_internal_API:#TEE内部接口，TAi->TAi
return True
else if self.uuid！＝other.uuid&&action in TEE_Client_API:#TEE外部接口，TAi->TAj
return True
else:
return False
TEE系统的内部接口信息流策略满足非及物性。
优选的，所述TEE状态机模型以及系统内部接口无干扰性的上层属性规约使用类似Hyperkernel的规约书写方式进行编写，通过对接口执行符号执行操作获取状态机模型各个接口要满足的规约，从而获得表示状态空间变化的一阶逻辑表达式，这些表达式描述了系统在经过一次系统调用后可以满足的所有状态条件，也可以称为内核代码应该满足的状态机规约；
符号执行过程会在全局上维护两个变量，一个是符号状态，用于表示变量到符号表达式的映射，另外一个是符号化路径的约束条件PC，这是一个无量词的一阶公式，两者共同组成了一阶逻辑形式的状态机规约，声明规约直接通过一阶逻辑表达式编写系统要满足的相关系统特性，TEE系统无干扰性也属于系统应满足的声明规约。
优选的，所述S3步骤中包含两种验证策略，分别为：验证系统状态机模型满足上层属性规约的要求后，认为通过框架中的代码生成器生成的内核接口满足正确性的要求，即第一种流程在认为代码生成器可信的情况下只需验证定理2；将自动生成的内核代码按照Hyperkernel的流程进一步验证，判断其接口是否满足正确性的要求，即第二种方式需要验证定理1和定理2；
定理1：内核实现是状态机规约的一个精化；
定理2：状态机规约要满足声明规约的要求。
为了验证两个定理的正确性，需要证明定义2和定义3的正确性：
定义2，规约和代码之间的精化关系可以描述为如下公式：
statespec表示规约中当前的状态机状态；
stateimpl表示实现代码中的状态机状态；x表示对于任意的输入；
statespec～stateimpl表示两个状态机满足等价条件；
fspec(statespec，x)表示在执行规约中的状态转化函数之后得到的状态；
fimpl(stateimpl，x)表示执行内核接口函数之后得到的状态；
定义3，状态机规约的正确性可描述如下公式：
其中，P()代表逻辑谓词函数，是由一阶逻辑表达式组成的逻辑运算函数。
优选的，所述TEE内部接口的无干扰性通过求精的方法来验证过程中，要求状态机模型和策略满足严格的求精关系，对于任意两个系统：
M1＝{S1,A,O,init1,step1,op1}
M2＝{S2,A,O,init2,step2,op2}
将M1视为状态机规约，M2视为实现代码，如果M2是M1的一个数据求精，那么对于任意执行序列，他们将产生相同的输出，为了验证M2是M1的一个精化，需要验证如下的求精条件：
(1)init2∝init1
(2)
(3)
其中∝表示精化关系，第一点表示初始状态满足精化关系；第二点表示如果两个状态满足精化关系，则经过一次action后的两个状态仍然满足精化关系；第三点表示如果两个状态满足精化关系，则经过一个action之后的输出结果应该相等。
优选的，所述两个状态机M1和M2的策略和/> 如果说针对M1和M2，策略P2是策略P1的精化，那么要求对于任意的action和行动序列都要满足如下公式：
dom1(a,run1(init1,α))＝dom2(a,run2(init2,α))
因此，我们得到求精定理为：给定两个系统M1和和M2，以及M1和的策略P，如果M2满足P对M1和和M2的任何策略精化的无干扰性，则需要满足如下条件：
1)P对于M1和是成立的，并满足unwinding条件；
2)M1和和M2之间满足求精条件；
上面的求精定理的两个条件，也符合定理1和定理2，但声明规约中要添加策略P以及unwinding条件。
优选的，所述快速形式化验证开发流程包括如下步骤：
步骤S101：创建状态机模型以及系统属性规约：开发者首先根据框架要求，使用Python开发两个规约，一个用于描述系统抽象的状态机模型，另一个用于描述状态机模型要满足的系统属性，其中状态机模型包含一个抽象系统状态机以及状态机在完成一次接口调用后，系统可能发生的不同状态变化的系统接口，系统属性规约也叫声明规约，用于描述系统要满足的相关上层属性；
步骤S102：验证状态机模型的正确性：针对状态机模型中的每个系统接口，通过符号评估器进行符号执行，获得每个接口经过状态转换后的所有可能的状态空间，在这里以一阶逻辑(FOL)的方式进行表示，将声明规约以及状态变换FOL作为可满足表达式输入，通过z3求解器进行求解，验证状态机模型的每个接口是否都满足声明规约中的要求，如果求解成功，就得到了正确的状态机模型，如果求解失败，通过反例给出的提示信息对状态机模型进行修改；
步骤S102：从状态机模型自动生成实现代码：通过代码生成器，根据内核状态机模型以及相关附属信息，将其转化为相关实现C代码；
步骤S102：验证生成的代码是否满足状态机模型：该过程是可选步骤，如果信任代码合成器的正确性，可以忽略这一步操作，为了进一步验证自动生成的代码满足状态机模型的要求，使用者首先通过框架提供的LLVM C前端将实现代码转换为LLVM的中间表示(IR)并封装；通过符号评估器，分别对状态机模型状态转换接口和系统实现代码系统接口的LLVM IR执行符号执行，获得两者以一阶逻辑表示的所有可能状态变化；将两者以及状态等价函数作为输入，通过z3求解器进行求解，如果成功，证明实现代码满足状态机模型的要求，否则给出反例，进行查找。
与现有技术相比，本发明具备以下有益效果：
1、本发明中，从已有的可信执行环境系统出发，研究了基于GPTEE标准的内部API的信息流安全性。本发明从形式化验证系统信息流无干扰性的理论出发。阐述了形式化验证的基本方法以及如何创建基于快速形式化验证框架的系统模型，并在可信执行环境上层接口进行状态机建模，并提出了满足TEE内部接口信息流的安全规约；本发明分析了使用扩展的形式化验证框架的可行性，并从TEE系统的内部接口的重新设计开始，以有限接口设计原则为基础，对已有接口进行了重新设计，使用有线接口的设计思想对该可信执行环境系统内部接口进行了重新设计，使其满足快速形式化验证框架。最后，本发明对设计后的系统进行了推理验证，发现了可能造成信息泄露的隐蔽通道，通过扩展的快速形式化验证框架验证重构后TEE内部接口之间满足无干扰性。通过实验分析了扩展框架对于验证TEE系统无干扰性的性能，以及新的系统设计所带来的性能负载，实验分析证明，经过验证的系统能够有效的避免可信应用之间的隐蔽通道，同时，保证系统不会带来过大的性能负载。
附图说明
图1为系统软件的快速形式化验证开发流程；
图2为定理1的证明过程；
图3为TEE架构；
图4为满足GPTEE标准相关接口的系统信息流调用过程；
图5为基于状态转换的信息流无干扰性；
图6为基于GP接口的信息流策略；
图7为TEE_OpenPersistentObject细粒度拆分后的程序流程；
图8为验证流程；
图9为形式化验证性能分析；
图10为系统运行时性能分析。
具体实施方式
下面，将参考附图详细地描述根据本申请的示例实施例。显然，所描述的实施例仅仅是本申请的一部分实施例，而不是本申请的全部实施例，应理解，本申请不受这里描述的示例实施例的限制。
本发明针对于困难点的解决方法和工作过程为：首先，对原有TEE系统的内部调用接口进行了重新设计，使其满足快速形式化验证框架的要求。快速形式化验证方法是一种设计和验证相结合，基于SMT的求解器进行推理的形式化验证方法，为了提升验证能力，要求系统本身设计采用适合SMT求解的数据结构、代码结构进行设计，避免递归和无边界的循环，保证在通过符号执行方法获取状态空间时的全覆盖策略；其次，本发明确定了代码抽象和要验证的层级，对这部分接口进行状态机建模以及TEE接口间的无干扰性建模，形成系统要满足的状态机规约和系统属性规约，状态机模型或者说状态机规约是系统接口设计的依据和基础，也是使用扩展框架自动合成合法代码的前提条件，这部分代码要求开发者根据框架要求，使用Python创建TEE系统的状态机模型，以及通过一阶逻辑表达式表示的无干扰性系统上层属性；最后，使用验证框架对修改后的TEE内部接口其进行推理验证，得到最终正确的求解。
实施例一
实施例一对本发明提出的基于可信执行环境的内部接口用无干扰性系统中TEE系统内部接口设计做进一步说明。
为了提升基于SMT的求解器的形式化验证性能，Hyperkernel提出了使用系统设计与验证相结合的方式辅助验证器进行验证。有限接口包含三个方面的要求：(1)系统接口避免无界的循环和递归的出现；(2)系统接口的细粒度管理，简化接口的复杂性；(3)系统资源静态管理，提升符号执行的效率。
在TEE系统内部接口有限接口设计的过程中：基于GPTEE标准的内部接口是不满足有限接口定义的，以安全存储接口TEE_OpenPersistenObject为例。
TEE_Result TEE_OpenPersistentObject(
uint32_t storageID,
[in(objectIDLength)]void*objectID,size_t objectIDLen,
uint32_t flags,
[out]TEE_ObjectHandle*object)；
当前安全存储接口满足seal存储，即满足文件本身的保密性、原子操作性、文件本身的完整性，同时，由于借助了REE侧的文件系统存储对象的文件，安全存储操作本身还要满足防回滚攻击，所以，原有系统借助了RPMB来保存相关counter值，因此，简单的打开文件操作，与传统的文件系统中的打开文件获得文件标识符的操作有明显的不同。
已有的安全存储对象打开操作包含后面几个操作：1)根据objectID和objectIDLen获得存储在Rom中文件；2)验证文件的完整性；3)如果文件被破坏，删除该文件并返回错误码，否则，获取该文件的相关信息存储到TEE_objectHandle中。
很显然，当前的接口并不满足有限接口的设计标准，主要体现为：接口的参数不满足有限接口要求，objectID作为内存指针存储着对象的标识符是动态存储，需要人为的通过指针和长度来解析，通过符号化参数变量的方式，那么objectID的范围是整个内核地址空间，显然无法进行符号执行；其次，TEE_ObjectHandle*object作为输出在目前的实现中，是以动态内存分配的方式来获得的，不满足有限接口的设计原则。
有限接口的内部操作相对复杂，由于永久对象是以块的方式存储的，受限于数据通道的大小，在验证较大存储对象的完整性时，需要进行多次的读取操作，从而造成TEE与REE的切换，对读取到的数据块进行完整性校验需要经过大量的循环操作，并且计算程序复杂度较高，这些循环操作在符号化变量后，很可能造成无边界循环，使符号执行操作陷入死循环。
接口之间存在交叉调用的过程，由于文件是加密存储的，需要调用相关加解密API来解密获得相关对象的信息，以及通过HMAC来计算当前文件的完整性。因此，增加了验证API之间无干扰性的难度。因此，基于GP标准的内部API无法通过上面提到的验证框架实现验证。
本发明采取了如下措施来实现接口的有限性原则：
1.对资源进行静态管理：objectID以固定长度的字符串来管理，即使用最大的objectIDLen存储objectID对象，并通过数组的方式分配固定个数objectID。相似的，对于TEE_ObjectHandle对象，也使用数组来存储，通过静态分配的方式供TA申请；
2.对当前接口进行细粒度的拆分，形成多个简单的元操作：由TA开发者负责完成对该接口的实现功能。针对于此接口，本发明将其拆分为参数验证元操作、数据块读元操作、MAC值校验元操作和TEE对象申请元操作；
3.由于存储对象大小的不确定性，会造成根据读取的头文件信息中的长度信息来循环的读取文件。符号执行过程将符号化这个长度信息，造成状态空间爆炸，从而影响性能。因此，本发明让TA负责数据的循环读取操作，TEE系统只提供读取块的系统接口。避免了验证接口时出现无界的循环。
4.将一些具体操作放到底层，接口层负责调用：MAC值的运算通过调用加解密服务来完成，而这些服务不在本发明的验证范围之内，进一步减轻了验证上的负载。
由于系统的耦合度较高，不能以单个接口为准进行拆分。这样很可能造成拆分的接口对于其他接口来说很少使用，造成系统的冗余和膨胀，不利于开发者的管理。本发明在分析了已有接口的实现后，提出了通过功能点来划分。以TEE_OpenPersistentObject为例，其接口的细粒度划分结果如图7示。
图7中简略描述了经过细粒度划分后，TA执行Open操作时，执行的工作流程。其中所有以TEE_Meta开头的都被划分的元函数。第1行到第8行执行检查参数是否正确，以及检查是否存在回滚；从第9行到13行是TA循环的读取信息块，从而检查文件的完整性。计算HMAC的过程由底层加解密服务通过标准加解密库来完成，本发明不对密码学算法进行形式化验证；最后，填充对象并返回。
在对有限接口设计在TEE内部接口中可行性分析的过程中：
有限接口的设计原则要求静态管理TEE内部系统资源，这样会预先造成一定的内存资源占用，但是，如果系统本身运行较多的TA时，也会动态的申请会多资源对象，造成内存的占用率提升，由于TEE系统在初始化阶段内存的使用大小就已经被固定，所以，在使用静态资源管理方式时，只要预先分配的资源在预设内存大小之内，并不会出现内存消耗殆尽，对于TEE_Malloc操作，本发明修改了动态申请的方式，通过重定义类型页的方式提供内存空间，以满足静态资源管理的要求。
有限接口的细粒度接口管理原则将一个接口调用分解成多个接口，这样会增加由于多次接口调用而产生的上下文切换，但这部分切换对于实现整个接口所需要的计算所消耗的计算时间来说，占有的比例很小，由于TEE系统本身采用了微内核的架构方式，在内核的陷入陷出方面已经做了很多优化，已经不是微内核架构的性能瓶颈，所以，细粒度接口划分造成的性能损耗还是可以接受的。
实施例二
实施例二对本发明提出的基于可信执行环境的内部接口用无干扰性系统做进一步说明。
TEE内部接口无干扰性包括TEE架构及系统信息流的无干扰性和TEE无干扰性建模。
在TEE架构及系统信息流中，如图3所示，基于TrustZone技术的基本TEE架构，一个处理器被分为两种状态，安全状态和非安全状态。TEE系统运行在处理器的安全状态下，并通过内存、硬件资源的严格划分保证TEE本身运行环境的安全。TEE软件栈一般包括可信内核组件和可信应用，可信内核及组件中OS内核一般采用微内核来减少可信基，其他组件包含各种服务、驱动、通信代理等。在可信内核及组件之上会向可信应用暴露可以调用的可信内部接口层以及库函数。本发明的研究重点集中在绿色方框包围的基于GPTEE标准的可信内部接口层，对该接口进行了重新定义和封装，并对这些重新设计的接口的信息流无干扰性进行了形式化验证，即TA和TA之间不会产生信息泄露。
如图4所示，REE通过指定的TEEC Client接口(左侧线框包围的接口)与TEE进行通信，TEE内部包含两种类型的通信接口：TA接口(右侧线框中最左侧的一排接口)和TEE内部接口(虚线框内包围的接口)。当调用TA_invokeCommandEntryPoint接口后，TEE通过指定TA完成REE端请求的相关操作。TA启动后，可以通过TEE_internal_API来访问TEE中的各种资源和服务，完成REE Client端的功能；
TA还可以通过TEE_Client_API(TEE_OpenTASession或者TEE_InvokeTACommand)来启动其他TA帮助完成REE Client端的功能，根据GP标准规定，可信应用是可信的，但必须保证可信应用之间的强隔离性，不允许敏感信息从一个TA流向另外一个TA，例如，当一个TA创建密钥时，需要通过硬随机数生成器产生一个随机数，该随机数是否可能在调用相关加密API时，通过全局变量被共享给其他TA，从而造成敏感数据的泄漏。通过传统的测试方式还无法找出这种信息安全漏洞。
GP标准所要实现的接口包括可信核心框架API、可信存储API、加解密操作API、可信时间API、可信算数API等。其中，相关API可能出现交叉调用。例如，可信存储的API在对密钥进行加密存储时，需要使用到加解密操作API，虽然开发者可以单独实现可信存储过程中的加解密操作，但这种做法显然是冗余的。因此，这种方式也使得不同的API之间高度耦合，对于验证不同TA之间的信息流安全性造成了难度。本发明的工作集中在可信存储API和加解密API的操作上。
在信息流无干扰性方面：无干扰性指对于一个安全域u和v，如果u中的任何活动都不会影响v中观察到的结果，那么u与v就是无干扰的。隐蔽通道(convert channel)可以通过创建一个能力级在不同安全域之间传递信息对象，而这种信息对象在计算机安全策略中是不允许传递的。验证系统的信息流无干扰性，可以保证系统中不会出现这种隐蔽通道，达到系统的信息流安全。
一个比较简单的例子，在登录系统时，如果用户正确的输入用户名，但是输入错误的登录密码，这时系统提示“您输入的密码错误”。这种例子可在很多简单登录系统中找到。但是，输出信息其实已经暴露了系统的相关信息。密码错误提示用户，我输入的账号是正确的，错误的只是密码。所以，对于攻击者可以利用这个隐蔽通道将攻击范围缩小到对密码的攻击。再如：对于操作系统内核，所有线程共享N个内存页。线程T1首先申请N-1个页，并通过是否分配最后一页来编码一个1比特的敏感数据secret。而第二个线程T2通过申请一个页是否分配成功来学习这个secret。当资源是有限并且容易耗尽时，这个secret就可以被T2通过这个隐蔽通道来获取。
基于状态转换的隐蔽通道可以通过如下方式进行表示，如图5所示，圆形以及内部的文字表示不同的状态；两个trans1分别表示TEE系统中两个不同可信应用(TA)进程，其中，transN表示一个状态转化函数，N表示状态转换函数被调用的次数；后面的数字表示产生的状态中的结果。以TA生成一个密钥为例，trans表示对应TEE内部API。第一种情况，两个TA都参与了生成密钥的过程，但在蓝色TA生成密钥的过程中间，另外一个TA也进行了密钥生成的系统接口调用。第二种情况表示单独的蓝色进程创建密钥的过程。本发明用数字代表产生的密钥ID，则第一种情况下，蓝色TA产生的密钥为3。而第二种情况下，产生的密钥为2；所以，蓝色TA创建密钥受到了由于有粉色TA的创建密钥的影响。即两个TA之间存在隐蔽通道而不满足无干扰性。因此，其无干扰性定义为：
定义1：output(run(s0,α),a)＝output(run(s0,purge(α,dom(a))),a)
其中，S：状态集合；
A:action集合，也是状态转化函数集合；
O:输出结果集合；
D:安全域集合，实例中的安全域包含蓝色和粉色两个进程实体；
a:action；
s0：初始状态；
α:action序列；
step:S×A→S，指在状态S下执行一次action调用；
output:S×A→O,指在状态S下执行一次action调用后的输出结果；
dom:A→D,指为每个action分配一个安全域；
run:S×A*→S,状态S在经过一系列的action后迁移到另外一个状态；
purge:A*×D→A*，移除掉所有对安全域D有影响的actions序列之后得到的action序列。
在TEE无干扰性建模方面，应用Unwinding定理
按照定义1所述使用上文提到的框架进行验证，需要对所有的action，即TEE内部API自由组合进行求解输出结果进行比较才能得到一个系统是否满足干扰性，对于使用基于逻辑求解的方式求解上面的逻辑公式是不现实的。因此需要根据经典Unwinding定理[2]对上面的求解进行化简，通过验证每一个action，简化推理过程。根据Unwinding定理需要满足如下性质：
输出一致性：
步伐一致性：
局部满足策略：
首先，对三个性质进行程序解释之前需要对安全域等价性进行定义，即～u可以通过定义dom_equal(s1,s2)函数来表示：
def dom_equal(s1,s2):
return z3.And(s1.currentTA＝＝s2.currentTA,
s1.TAs_Count＝＝s2.TAs_Count,…))
在此基础之上，步伐一致性可以通过一阶逻辑的方式表示为如下：
z3.ForAll([s1,s2],z3.Implies(dom_equal(s1,s2),dom_equal(trans(s1),trans(s2)))
由于trans函数在符号执行后，返回不同约束对应的状态，以及不同前置条件对应的输出结果。所以上面的公式也适用于性质1，输出一致性。
TEE内部API的信息流策略中，局部满足策略，要根据TEE系统的信息流访问策略来制定，如图6所示描述了满足GP标准的信息流访问控制策略。TEE_internal_API只适用于可信应用内部的调用。TA之间的信息流访问需要通过TEE_Client_API来访问。信息可以通过TEE_Client_API在不同的TA之间流通，针对于每个TEE_internal_API，不允许信息从一个TA流向另一个TA
TEE系统的这种隔离性使用Python规约来简要描述，可以表示为如下代码：
class Trust_APP_Domain:
def__init__(self,uuid):
self.uuid＝uuid
#信息流策略
def info_flow_to(self,other,action):
if self.uuid＝＝other.uuid&&action in TEE_internal_API:#TEE内部接口，TAi->TAi
return True
else if self.uuid！＝other.uuid&&action in TEE_Client_API:#TEE外部接口，TAi->TAj
return True
else:
return False
TEE系统的内部接口信息流策略满足非及物性。即如图6所示，成立，并且/>成立，但是并不意味着/>成立。
实施例三
实施例二对本发明提出的基于可信执行环境的内部接口用无干扰性系统做进一步说明。
快速形式化验证方法及扩展基于经典框架及扩展：Hyperkernel方法以及框架是一种系统设计方法和验证策略相结合的操作系统内核形式化验证方法。该方法要求开发者通过Python按照指定要求编写系统内核的状态机规约和声明规约。在状态机规约的指导下，编写系统代码，并验证代码和状态机规约之间的求精关系以及状态机规约满足声明规约的要求。本发明中使用了Hyperkernel的扩展框架[8]验证TEE系统内部API的无干扰性特性。
如图1所示，图1给出了使用该扩展框架开发系统软件的工作流程，并介绍了使用本发明中的开发验证框架如何设计和开发一个可验证的系统软件，总结为如下五个步骤：
S101步骤：创建状态机模型以及系统属性规约
开发者首先根据框架要求，使用Python开发两个规约，一个用于描述系统抽象的状态机模型，另一个用于描述状态机模型要满足的系统属性。其中状态机模型包含一个抽象系统状态机以及状态机在完成一次接口调用后，系统可能发生的不同状态变化的系统接口。系统属性规约也叫声明规约，用于描述系统要满足的相关上层属性，如进程隔离性等。
S102步骤：验证状态机模型的正确性
针对状态机模型中的每个系统接口，通过符号评估器进行符号执行，获得每个接口经过状态转换后的所有可能的状态空间，在这里以一阶逻辑(FOL)的方式进行表示。将声明规约以及状态变换FOL作为可满足表达式输入，通过z3求解器进行求解，验证状态机模型的每个接口是否都满足声明规约中的要求，如果求解成功，就得到了正确的状态机模型。如果求解失败，通过反例给出的提示信息对状态机模型进行修改。
S103步骤：从状态机模型自动生成实现代码
通过代码生成器，根据内核状态机模型以及相关附属信息，将其转化为相关实现C代码。
S104步骤：验证生成的代码是否满足状态机模型
如图1中虚框所包含的部分，该过程是可选步骤，如果信任代码合成器的正确性，可以忽略这一步操作。为了进一步验证自动生成的代码满足状态机模型的要求，使用者首先通过框架提供的LLVM C前端将实现代码转换为LLVM的中间表示(IR)并封装；通过符号评估器，分别对状态机模型状态转换接口和系统实现代码系统接口的LLVM IR执行符号执行，获得两者以一阶逻辑表示的所有可能状态变化；将两者以及状态等价函数作为输入，通过z3求解器进行求解，如果成功，证明实现代码满足状态机模型的要求，否则给出反例，进行查找。
Hyperkernel使用Python描述OS内核应该满足的规约。该规约可以分为两类，一种用于描述内核状态以及状态变化的状态机规约；一种是用来描述内核相关属性的声明规约。本发明使用类似Hyperkernel的规约书写方式编写TEE状态机模型以及系统内部接口无干扰性的上层属性规约。
规约是通过一定的逻辑表达式，如一阶逻辑、霍尔逻辑、高阶逻辑等来描述的。上面提到的状态机规约(状态机模型)并不是真正意义规约，因为状态机模型只描述了系统的内部状态相关对象以及状态转化函数，并没有给出相关逻辑表示。如图1所示，为了获取状态机模型的各个接口要满足的规约，需要对接口执行符号执行操作，从而获得表示状态空间变化的一阶逻辑表达式。这些表达式描述了系统在经过一次系统调用后可以满足的所有状态条件。因此，这些表达式集合也可以称为内核代码应该满足的状态机规约。符号执行过程会在全局上维护两个变量，一个是符号状态，用于表示变量到符号表达式的映射。另外一个是符号化路径的约束条件PC，这是一个无量词的一阶公式。两者共同组成了一阶逻辑形式的状态机规约。声明规约直接通过一阶逻辑表达式编写系统要满足的相关系统特性，如进程的隔离性等。本发明中的TEE系统无干扰性也属于系统应满足的声明规约。
本发明包含两种验证策略：1)验证系统状态机模型满足上层属性规约的要求后，认为通过框架中的代码生成器生成的内核接口满足正确性的要求；2)将自动生成的内核代码按照Hyperkernel的流程进一步验证，判断其接口是否满足正确性的要求。第一种策略认为代码生成器本身是正确的；第二种策略忽略自动生成的代码的正确性，通过原有流程进一步验证。针对两种策略，需要验证不同的定理，不同策略要满足的验证目标。
验证目标总结可以为如下两个定理：
定理1：内核实现是状态机规约的一个精化。
为了验证定理1所满足的求精关系，需要开发者提供一个对等函数，用于表述状态机规约不同状态与时下代码之间的对应关系，否则，验证器无法判断哪些抽象内核状态与实现代码中的内核状态保持一致。在对等函数的基础上，分别对状态机转换函数和实现代码的LLVM IR进行符号执行，分别获得一阶逻辑表示的状态空间，结合对等函数一并作为求解序列输入到Z3中进行推理求解。其具体实现方式图2所示。
定理2：状态机规约要满足声明规约的要求。
为了验证定理2，系统将规约经过符号执行后得到的一阶逻辑状态空间和声明规约作为求解序列一并输入到求解器中进行求解。如果得到反例，则表示验证失败，需要通过反例查找错误原因，否则验证成功。
框架提供了两种验证策略，第一种流程在认为代码生成器可信的情况下只需验证定理2，第二种方式需要验证定理1和定理2。针对两种情况的分析为：
第一种方式认为代码生成器可靠的策略在很多研究中都有相关案例。如，我们在验证操作系统时，普遍会认为代码使用编译器进行编译的过程是正确的，即认为编译器是可信的。编译器本身也是一种代码转换器，其优势是经过大量人员使用并测试。也有人通过形式化的方式验证编译器[16,17]，使其满足正确性。针对于内核的代码自动生成的研究中，Termite[18]也是采用自动生成的方式，并认为代码合成过程是可信的，将研究重点放在如何编写正确的规约上。
第二种方式是传统的验证流程，例如，Hyperkernel采用了手动编写代码的方式，并使用同时验证定理1和定理2来保证代码和状态机模型的一致性，同时，保证状态机模型满足上层属性规约的要求。如果使用此种验证方式，则需要对实现代码的系统接口进行LLVM IR级别的封装，同时进行符号执行操作。对于验证过程产生了额外的性能负载。另外，开发者仍需要手动编写对等函数，这种操作而可能出现人为错误的可能，从而增加验证的迭代次数。
基于以上两点的分析，本发明默认使用第一种策略。同时，提供了第二种策略的选择权。
为了验证两个定理的正确性，需要证明如下两个定义的正确性：
定义2，规约和代码之间的精化关系可以描述为如下公式：
statespec表示规约中当前的状态机状态；
stateimpl表示实现代码中的状态机状态；x表示对于任意的输入；
statespec～stateimpl表示两个状态机满足等价条件；
fspec(statespec，x)表示在执行规约中的状态转化函数之后得到的状态；
fimpl(stateimpl，x)表示执行内核接口函数之后得到的状态；
所以，该表达式的描述了如何在执行之前，规约中的抽象内核状态与实现代码中的内核状态等价，则经过状态转化函数(内核接口)之后，两者的内核状态仍旧等价。
定义3，状态机规约的正确性可描述如下公式：
其中，P()代表逻辑谓词函数，是由一阶逻辑表达式组成的逻辑运算函数定义2要求验证器验证状态机规约满足以谓词形式表示的系统属性。
与Hyperkernel不同，本发明中将验证重点放到无干扰性属性的验证上，因此，在上面的两个定义中去掉了原有验证定义中的不变量相关说明。
实施例四
实施例二对本发明提出的基于可信执行环境的内部接口用无干扰性系统做进一步说明。
形式化验证包括精化，精化也称求精，被广泛用于验证系统。开发者通过high-level的抽象规约来描述目标系统的行为，并验证具体的实现的任何行为都是被抽象规约所允许的。求精允许开发者在规约层验证系统的各种属性，从而间接的证明实现代码满足这些属性的要求。
在本发明中也使用了求精的方法来验证TEE内部接口的无干扰性。由于实现代码可能会增加相关操作造成信息泄露，因此，本发明要求状态机模型和策略满足严格的求精关系。对于任意两个系统：
M1＝{S1,A,O,init1,step1,op1}
M2＝{S2,A,O,init2,step2,op2}
本发明中可以将M1视为状态机规约，M2视为实现代码。如果M2是M1的一个数据求精[3,4]，那么对于任意执行序列，他们将产生相同的输出。为了验证M2是M1的一个精化，需要验证如下的求精条件：
(1)init2∝init1
(2)
(3)
其中∝表示精化关系。第一点表示初始状态满足精化关系；第二点表示如果两个状态满足精化关系，则经过一次action后的两个状态仍然满足精化关系；第三点表示如果两个状态满足精化关系，则经过一个action之后的输出结果应该相等。
对于两个状态机M1和M2的策略和/>如果说针对M1和M2，策略P2是策略P1的精化，那么要求对于任意的action和行动序列都要满足如下公式：
dom1(a,run1(init1,α))＝dom2(a,run2(init2,α))
因此，我们得到求精定理为：给定两个系统M1和和M2，以及M1和的策略P，如果M2满足P对M1和和M2的任何策略精化的无干扰性，则需要满足如下条件：
1)P对于M1和是成立的，并满足unwinding条件；
2)M1和和M2之间满足求精条件；
上面的求精定理的两个条件，也符合定理1和定理2，但声明规约中要添加策略P以及unwinding条件。
在验证流程中，为了提升开发开发速度，本发明使用了框架中的第一种验证类型，即只验证定理2，而不验证定理1。定理1的正确性规约在执行一次内部接口调用时得到相同的状态空间变化，以及相同的输出结果。我们将工作集中到编写正确的状态机规约以及正确的无干扰性属性规约上。这里的无干扰性属性主要通过上面介绍的unwinding条件来实现。具体的开发验证流程如图8所示：
验证求精需要证明三个求精条件，而这三个求精条件也是对定理1的扩展，即增加了输出结果的一致性验证。本发明默认代码自动合成的正确性。主要有以下几个原因：有限接口设计中的三个原则使得要实现的代码接口的逻辑变得简洁，同时，接口代码的长度也很小，因此为生成正确的代码打好了基础；规约详细描述了接口中不同前置条件对应的输出接口，满足求精条件中的输出结果一致性；基于状态机的代码生成方式保证了生成代码的流程符合状态变迁的一致性；初始化一致性在本发明中是默认的；原有Hyperkernel框架中的等价性验证需要提供对等函数，而扩展框架中的对等函数作为辅助模型为生成正确代码提供了帮助，起到了状态空间等价的作用。
通过对安全存储接口中的8个接口进行了细粒度划分，共生成21个元接口。同时还对TEE_Client_API中的TEE_Invoke_Command进行了划分，基于这些接口构建了第一个版本的状态机模型以及无干扰信息流策略。
通过图8中的验证流程进行了验证分析，由于本发明是在已有TEE系统的基础设定规约，因此，状态机规约中的状态转换函数实现的功能也与当前TEE系统中的内容相似。在此前提下，我们发现，原有的设计中存在一个隐蔽通道。本发明使用了AES-CTR加密算法对数据块进行加密操作，该算法需要一个初始化向量(Initialization Vector，简称IV)作为加解密运算。同时，由于使用了软随机数，系统中设置了一个counter值作为IV生成的一个参数，该counter被所有TA进程共享。这就造成了在生成IV时取决于counter值的大小，而counter值是共享的，因此很容易泄漏TA的IV给其他TA。虽然没有完全的泄漏密钥给另外一个进程TA，但这也增加了恶意TA从TEE内部破解密钥的几率。
形式化验证平台选用了一台Intel Core i7-6700处理器，内存大小为32G机器作为测试环境。本发明选用的Z3求解器的版本为V4.5.0。图9显示了验证部分接口所需要的时间大小。可以看到，形式化验证的主要性能消耗包含两部分：第一个是通过符号执行过程获得状态空间变化所消耗的时间；第二个是对符号执行后得到的状态空间一阶逻辑表达式进行求解所消耗的时间。从验证结果可以看到，形式化验证的性能负载主要集中在符号执行阶段，而最后的逻辑求解的性能消耗几乎可以忽略不计。其中，验证时间最长的用时57.856秒，最短的用时不到4秒。实验结果表明，所有被验证接口可以在一定时间内完成，满足快速验证的要求。
本发明并没有对TEE系统中的单个元接口进行性能测试，为了计算有限接口设计方式对系统性能的影响，本发明对比了原有TEE接口与由元接口组成的相同GPTEE标准接口的性能差别。如图10所示，实验中对比了安全存储功能中有关临时对象和永久对象的相关操作接口。本发明的实验平台采用来自于联发科的工业移动设备芯片MTK6797/Helio X20，该芯片采用了4+4的大小核心设计，REE系统为Andorid M。安全存储接口所使用的操作对象是大小为512Kb的存储数据。实验结果表明，有限接口设计方式比原有GPTEE接口仅有平均约3％～7％的性能负载。这主要是于上下文切换的增加以及用户空间TA调用时自己对函数的修改造成的。但这部分性能负载与整个接口的实现上消耗的性能相比非常的有限，不会对整个系统的造成较大的性能开销。
本发明从已有的可信执行环境系统出发，研究了基于GPTEE标准的内部API的信息流安全性。本发明从形式化验证系统信息流无干扰性的理论出发。阐述了形式化验证的基本方法以及如何创建基于快速形式化验证框架的系统模型。本发明分析了使用扩展的形式化验证框架的可行性，并从TEE系统的内部接口的重新设计开始，以有限接口设计原则为基础，对已有接口进行了重新设计。最后，本发明对设计后的系统进行了推理验证，发现了可能造成信息泄露的隐蔽通道。通过实验分析了扩展框架对于验证TEE系统无干扰性的性能，以及新的系统设计所带来的性能负载。实现结果表明，系统能在有效时间内快速完成验证，同时，在运行时性能上并没有太大的负载，证明了方法的可行性。
以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术用户来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述内部接口用无干扰性系统包括处理层：
数据层用于TEE内部接口无干扰性的设计，具体包括以下步骤：
S1步骤：对原有TEE系统的内部调用接口进行了重新设计，使其满足快速形式化验证框架的要求；
S2步骤：确定代码抽象和要验证的层级，对这部分接口进行状态机建模以及TEE接口间的无干扰性建模，形成系统要满足的状态机规约和系统属性规约；
S3步骤：使用验证框架对修改后的TEE内部接口其进行推理验证，得到最终正确的求解。
2.根据权利要求1所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述S1步骤中，TEE内部包含TA接口和TEE内部接口两种类型的通信接口，当调用TA_invokeCommandEntryPoint接口后，TEE通过指定TA完成REE端请求的相关操作，TA启动后，可以通过TEE_internal_API来访问TEE中的各种资源和服务，完成REE Client端的功能；TA还可以通过TEE_Client_API来启动其他TA帮助完成REE Client端的功能，根据GP标准规定，可信应用是可信的，但必须保证可信应用之间的强隔离性，不允许敏感信息从一个TA流向另外一个TA，TEE系统内部接口的有限接口设计，具体工作过程包括以下步骤：
步骤S11：对资源进行静态管理：objectID以固定长度的字符串来管理，即使用最大的objectIDLen存储objectID对象，并通过数组的方式分配固定个数objectID，对于TEE_ObjectHandle对象，也使用数组来存储，通过静态分配的方式供TA申请；
步骤S12：对当前接口进行细粒度的拆分，形成多个简单的元操作：由TA开发者负责完成对该接口的实现功能，针对于此接口，将其拆分为参数验证元操作、数据块读元操作、MAC值校验元操作和TEE对象申请元操作；
步骤S13：TA负责数据的循环读取操作，TEE系统只提供读取块的系统接口；
步骤S14：将一些具体操作放到底层，接口层负责调用：MAC值的运算通过调用加解密服务来完成。
3.根据权利要求1所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述S2步骤中，其无干扰性定义为：
定义1：output(run(s0,α),a)＝output(run(s0,purge(α,dom(a))),a)
其中，S：状态集合；
A:action集合，也是状态转化函数集合；
O:输出结果集合；
D:安全域集合，实例中的安全域包含蓝色和粉色两个进程实体；
a:action；
s0：初始状态；
α:action序列；
step:S×A→S，指在状态S下执行一次action调用；
output:S×A→O,指在状态S下执行一次action调用后的输出结果；
dom:A→D,指为每个action分配一个安全域；
run:S×A*→S,状态S在经过一系列的action后迁移到另外一个状态；
purge:A*×D→A*，移除掉所有对安全域D有影响的actions序列之后得到的action序列。
4.根据权利要求3所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述定义1进行验证时，需要对所有的action，即TEE内部API自由组合进行求解，并根据输出结果的比较得到满足干扰性的求解，根据Unwinding定理验证每一个action，简化推理过程，且满足如下性质：
输出一致性：
步伐一致性：
局部满足策略：
对三个性质进行程序解释之前需要对安全域等价性进行定义，即～u可以通过定义dom_equal(s1,s2)函数来表示：
def dom_equal(s1,s2):
return z3.And(s1.currentTA＝＝s2.currentTA,
s1.TAs_Count＝＝s2.TAs_Count,…))
在此基础之上，步伐一致性可以通过一阶逻辑的方式表示为如下：
z3.ForAll([s1,s2],z3.Implies(dom_equal(s1,s2),dom_equal(trans(s1),trans(s2)))。
5.根据权利要求4所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述TEE内部API的信息流策略，局部满足策略，要根据TEE系统的信息流访问策略来制定，TEE_internal_API只适用于可信应用内部的调用，基于GP接口的信息流策略：信息可以通过TEE_Client_API在不同的TA之间流通，针对于每个TEE_internal_API，不允许信息从一个TA流向另一个TA，TEE系统的这种隔离性使用Python规约来简要描述，可以表示为如下代码：
class Trust_APP_Domain:
def__init__(self,uuid):
self.uuid＝uuid
#信息流策略
def info_flow_to(self,other,action):
if self.uuid＝＝other.uuid&&action in TEE_internal_API:#TEE内部接口，TAi->TAi
return True
else if self.uuid！＝other.uuid&&action in TEE_Client_API:#TEE外部接口，TAi->TAj
return True
else:
return False
TEE系统的内部接口信息流策略满足非及物性。
6.根据权利要求5所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述TEE状态机模型以及系统内部接口无干扰性的上层属性规约使用类似Hyperkernel的规约书写方式进行编写，通过对接口执行符号执行操作获取状态机模型各个接口要满足的规约，从而获得表示状态空间变化的一阶逻辑表达式，这些表达式描述了系统在经过一次系统调用后可以满足的所有状态条件，也可以称为内核代码应该满足的状态机规约；
符号执行过程会在全局上维护两个变量，一个是符号状态，用于表示变量到符号表达式的映射，另外一个是符号化路径的约束条件PC，这是一个无量词的一阶公式，两者共同组成了一阶逻辑形式的状态机规约，声明规约直接通过一阶逻辑表达式编写系统要满足的相关系统特性，TEE系统无干扰性也属于系统应满足的声明规约。
7.根据权利要求1所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述S3步骤中包含两种验证策略，分别为：验证系统状态机模型满足上层属性规约的要求后，认为通过框架中的代码生成器生成的内核接口满足正确性的要求，即第一种流程在认为代码生成器可信的情况下只需验证定理2；将自动生成的内核代码按照Hyperkernel的流程进一步验证，判断其接口是否满足正确性的要求，即第二种方式需要验证定理1和定理2；
定理1：内核实现是状态机规约的一个精化；
定理2：状态机规约要满足声明规约的要求；
为了验证两个定理的正确性，需要证明定义2和定义3的正确性：
定义2，规约和代码之间的精化关系可以描述为如下公式：
statespec表示规约中当前的状态机状态；
stateimpl表示实现代码中的状态机状态；x表示对于任意的输入；
statespec～stateimpl表示两个状态机满足等价条件；
fspec(statespec，x)表示在执行规约中的状态转化函数之后得到的状态；
fimpl(stateimpl，x)表示执行内核接口函数之后得到的状态；
定义3，状态机规约的正确性可描述如下公式：
其中，P()代表逻辑谓词函数，是由一阶逻辑表达式组成的逻辑运算函数。
8.根据权利要求7所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述TEE内部接口的无干扰性通过求精的方法来验证过程中，要求状态机模型和策略满足严格的求精关系，对于任意两个系统：
M1＝{S1,A,O,init1,step1,op1}
M2＝{S2,A,O,init2,step2,op2}
将M1视为状态机规约，M2视为实现代码，如果M2是M1的一个数据求精，那么对于任意执行序列，他们将产生相同的输出，为了验证M2是M1的一个精化，需要验证如下的求精条件：
(1)init2∝init1
(2)
(3)
其中∝表示精化关系，第一点表示初始状态满足精化关系；第二点表示如果两个状态满足精化关系，则经过一次action后的两个状态仍然满足精化关系；第三点表示如果两个状态满足精化关系，则经过一个action之后的输出结果应该相等。
9.根据权利要求8所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述M1和M2的策略和/>如果说针对M1和M2，策略P2是策略P1的精化，那么要求对于任意的action和行动序列都要满足如下公式：
dom1(a,run1(init1,α))＝dom2(a,run2(init2,α))
因此，我们得到求精定理为：给定两个系统M1和和M2，以及M1和的策略P，如果M2满足P对M1和和M2的任何策略精化的无干扰性，则需要满足如下条件：
1)P对于M1和是成立的，并满足unwinding条件；
2)M1和和M2之间满足求精条件；
上面的求精定理的两个条件，也符合定理1和定理2，但声明规约中要添加策略P以及unwinding条件。
10.根据权利要求9所述的基于可信执行环境的内部接口用无干扰性系统，其特征在于，所述快速形式化验证开发流程包括如下步骤：
步骤S101：创建状态机模型以及系统属性规约：开发者首先根据框架要求，使用Python开发两个规约，一个用于描述系统抽象的状态机模型，另一个用于描述状态机模型要满足的系统属性，其中状态机模型包含一个抽象系统状态机以及状态机在完成一次接口调用后，系统可能发生的不同状态变化的系统接口，系统属性规约也叫声明规约，用于描述系统要满足的相关上层属性；
步骤S102：验证状态机模型的正确性：针对状态机模型中的每个系统接口，通过符号评估器进行符号执行，获得每个接口经过状态转换后的所有可能的状态空间，在这里以一阶逻辑(FOL)的方式进行表示，将声明规约以及状态变换FOL作为可满足表达式输入，通过z3求解器进行求解，验证状态机模型的每个接口是否都满足声明规约中的要求，如果求解成功，就得到了正确的状态机模型，如果求解失败，通过反例给出的提示信息对状态机模型进行修改；
步骤S102：从状态机模型自动生成实现代码：通过代码生成器，根据内核状态机模型以及相关附属信息，将其转化为相关实现C代码；
步骤S102：验证生成的代码是否满足状态机模型：该过程是可选步骤，如果信任代码合成器的正确性，可以忽略这一步操作，为了进一步验证自动生成的代码满足状态机模型的要求，使用者首先通过框架提供的LLVM C前端将实现代码转换为LLVM的中间表示(IR)并封装；通过符号评估器，分别对状态机模型状态转换接口和系统实现代码系统接口的LLVM IR执行符号执行，获得两者以一阶逻辑表示的所有可能状态变化；将两者以及状态等价函数作为输入，通过z3求解器进行求解，如果成功，证明实现代码满足状态机模型的要求，否则给出反例，进行查找。
CN202311585708.3A 2023-11-24 2023-11-24 基于可信执行环境的内部接口用无干扰性系统 Pending CN117633795A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311585708.3A CN117633795A (zh) 2023-11-24 2023-11-24 基于可信执行环境的内部接口用无干扰性系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311585708.3A CN117633795A (zh) 2023-11-24 2023-11-24 基于可信执行环境的内部接口用无干扰性系统

Publications (1)

Publication Number Publication Date
CN117633795A true CN117633795A (zh) 2024-03-01

Family

ID=90031493

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311585708.3A Pending CN117633795A (zh) 2023-11-24 2023-11-24 基于可信执行环境的内部接口用无干扰性系统

Country Status (1)

Country Link
CN (1) CN117633795A (zh)

Similar Documents

Publication Publication Date Title
US10839107B2 (en) Managing a smart contract on a blockchain
CN110245506B (zh) 基于区块链的智能合约管理方法及装置、电子设备
Steffen et al. zkay: Specifying and enforcing data privacy in smart contracts
CN110032883B (zh) 区块链中实现隐私保护的方法、系统和节点
Austin et al. Multiple facets for dynamic information flow
EP3971742B1 (en) Methods, blockchain nodes and storage media for deploying smart contract
Arden et al. Sharing mobile code securely with information flow control
Mai et al. Verifying security invariants in ExpressOS
US9208319B2 (en) Code base partitioning system
CN110020856B (zh) 区块链中实现混合交易的方法、节点和存储介质
MX2014007102A (es) Facilitacion de interacciones de solicitud de servicio de sistema para aplicaciones protegidas por hardware.
Gollamudi et al. Automatic enforcement of expressive security policies using enclaves
Austin et al. Multiple facets for dynamic information flow with exceptions
Schmitz et al. Faceted dynamic information flow via control and data monads
US20150195083A1 (en) Homomorphic cryptography modeling in support of privacy policies
Balliu et al. Jslinq: Building secure applications across tiers
CN112287357A (zh) 一种针对嵌入式裸机系统的控制流验证方法与系统
CN117633795A (zh) 基于可信执行环境的内部接口用无干扰性系统
Duggan Cryptographic types
Harris et al. Program synthesis for interactive-security systems
Austin et al. Typed faceted values for secure information flow in Haskell
Gollamudi Secure-by-Construction Applications Using Trusted Execution Environments
Schmitz Faceted Information Flow
Tan et al. Formal modeling and verification of cloudproxy
Vassena Verifying Information Flow Control Libraries

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination