CN109948354A - 一种跨平台使用硬件隔离环境对文件进行加密校验的方法 - Google Patents

一种跨平台使用硬件隔离环境对文件进行加密校验的方法 Download PDF

Info

Publication number
CN109948354A
CN109948354A CN201910206708.5A CN201910206708A CN109948354A CN 109948354 A CN109948354 A CN 109948354A CN 201910206708 A CN201910206708 A CN 201910206708A CN 109948354 A CN109948354 A CN 109948354A
Authority
CN
China
Prior art keywords
function
file
enclave
code
trusted
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
CN201910206708.5A
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.)
Nanjing University
Beijing NSFocus Information Security Technology Co Ltd
Original Assignee
Nanjing University
Beijing NSFocus Information Security 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 Nanjing University, Beijing NSFocus Information Security Technology Co Ltd filed Critical Nanjing University
Priority to CN201910206708.5A priority Critical patent/CN109948354A/zh
Publication of CN109948354A publication Critical patent/CN109948354A/zh
Pending legal-status Critical Current

Links

Landscapes

  • Storage Device Security (AREA)

Abstract

本发明公开一种跨平台使用硬件隔离环境对文件进行加密校验的方法,是一种在跨平台转移文件同时使用硬件隔离保护文件机密性和完整性的方法,使得对文件的保护可以在两个不同平台的硬件隔离环境中进行。位于PC端的文件,在操作系统环境为Windows或者Linux的情况下,利用Intel SGX技术对它进行加密和校验码的计算,此后文件变为安全状态。当需要把文件转移到移动端时,假设移动端部署的是Android系统,则可利用ARM TrustZone技术对该文件进行解密和完整性校验,反方向亦然。达到了文件跨平台安全传输并同时保证机密性和完整性的目的。

Description

一种跨平台使用硬件隔离环境对文件进行加密校验的方法
技术领域
本发明涉及一种跨平台使用硬件隔离环境对文件进行加密校验的方法,具体是一种在文件的跨平台转移过程中保护其机密性和完整性的方法,属于系统安全技术领域。
背景技术
在如今的大数据时代,数据创造出的价值越来越多,如何保护系统中的数据成为一个至关重要的问题。传统数据通常储存在用户的个人PC上,而现在随着移动设备的使用越来越广泛,更多的用户数据流向了移动端。然而,无论是PC端还是移动端,有价值的数据都会引来一些攻击者的窥探,然而这是用户所不希望看到的。
在PC端,攻击者可能通过传统的远程木马窃取用户的隐私数据,或是直接从物理上拷贝走用户的数据,在一些文件共享的应用中,用户可能在不知不觉中就被攻击者分享走了自己的隐私数据。在移动端,除了上述的攻击方式,攻击者还有可能在无处不在的第三方应用app中种下恶意代码,待用户下载后就开始攻击或偷窃行为,泄露用户隐私。
针对这些威胁到用户隐私的攻击行为,目前的解决方案有文件加密(PC端或移动端),加密锁(PC端),生物特征加密如指纹解锁(移动端)等方式。对于加密保护隐私数据的方法,如今的密码学发展已经使得攻击者无法在可计算时间内破解密码得到隐私数据,也就是说攻击者为了破解隐私数据,必须花费比数据本身价值更大的代价才可能破解密码算法,这样在一定程序上保护了数据的安全,但是如果攻击者攻陷了操作系统权限或是检测了加解密过程,就有可能拿到密钥,在这种情况下,密码算法不攻自破。对于加密锁的方案,它采用了硬件的方式保护软件和数据,但是其缺陷在于:首先加密锁的成本很高,阻碍了它的广泛使用,其次加密锁的扩展性不好,为了与加密锁继承,软件必须经过精心设计,需要考虑应用环境和加密锁硬件的兼容性,并且加密锁需要插在机器的USB口上,占用了一定的资源。而生物特征加密有着和密码学加密一样的问题,并且它只能妨碍攻击者显式地观察到隐私数据,无法抵挡来自网络以及恶意代码的攻击。
由以上现存保护方式的局限性可以看出,用软件方式保护文件时始终存在一个问题,那就是当攻击者拿到系统权限,那么密钥系统就会在攻击者的面前一览无余,整个密码算法显得没有用处。而如果用硬件的方式,则局限性太强不利于推广。因此,只有以硬件隔离为基础,采用软硬件结合的方式才能解决很多安全问题。
现有的硬件隔离技术如Intel SGX(PC端),ARM TrustZone(移动端)通过将可信的进程和数据放在与正常操作系统隔离开的区域中保证可信数据的安全,即使攻击者拿到了系统权限也无法越过硬件隔离观测到加解密过程,也就无法拿到密钥和隐私数据。
发明内容
发明目的:针对现有技术存在的问题与不足,本发明提供一种跨平台使用硬件隔离环境对文件进行加密校验的方法,在具备硬件隔离的不同平台之间安全地转移文件,并依靠SGX和TrustZone,以及密码算法完成文件的加解密和完整性验证,保证文件的机密性和完整性的方法。
最主要的挑战是在不同的平台,例如PC端和移动端,运行不同的操作系统,如Windows,Linux和Android,如何利用不同平台上的硬件隔离环境完成安全的文件转移和验证。
因此,基于上述的考虑,本发明提供了SGX和TrustZone这两种不同的硬件隔离技术为文件进行加解密和完整性验证的方法。考虑到文件的转移可能是在两个不同的平台上,PC端一般采用的是Intel SGX技术,移动端则是TrustZone技术,在本方法中,这二者被用来进行文件的保护,使得文件可以在不同的平台上安全机密地转移,同时保证完整性。
本发明中采用的密码算法为AES GCM模式,它是CTR和GHASH的组合,GHASH操作定义为密文结果与密钥以及消息长度在GF(2128)域上相乘,同时完成了加密和完整性校验的功能,并且具有更高的并行度和更好的性能。
技术方案:一种跨平台使用硬件隔离环境对文件进行加密校验的方法,其中在SGX技术和TrustZone技术的支持下部署用于处理文件加解密和验证的安全应用程序;包括四个部分:PC端安全应用程序,PC端不可信部分,移动端可信程序,移动端不可信部分(Android APP)。
PC端安全应用程序用于完成的是加解密等安全操作,该部分位于SGX的Encalve中,是被硬件隔离保护起来的区域。运行在这里的安全加解密程序不会被攻击者观察到。
PC端不可信部分用于完成的是与PC端用户交互的功能,用户通过该部分向安全应用程序的加解密程序发起请求,调用位于Encalve中的安全应用程序完成加密或解密的操作。PC端安全应用程序和PC端不可信程序之间的交互由Intel SGX的通信机制完成,通过预定义在Enclave中的可信接口和不可信接口完成双向调用。
移动端可信程序位于TrsutZone的Secure World中,也是被硬件隔离保护起来的区域,这部分完成的是加解密和用户验证等安全操作。
移动端不可信部分(Android APP)是运行在移动端的普通app,完成与用户的交互,给用户提供功能界面。用户可以通过它向Secure World发起安全请求,调用可信程序完成数据加解密或是用户验证。移动端可信程序和不可信部分之间的交互由TrustZone机制提供,通过可信程序提供的安全程序入口和函数编号找到对应需要调用的函数,并在调用完成后返回到正常操作系统的普通app中。
若文件需要由PC端转移到移动端,应用本发明需要完成如下步骤:
1.在PC端,运行不可信部分的程序对安全应用程序发起调用;
2.安全应用程序完成加密和计算MAC码,调用返回;
3.将加密并附上了消息验证码的数据转移到移动端;
4.在移动端App发起对可信程序的调用;
5.移动端的可信程序对数据进行解密和校验消息验证码,返回结果给App;
6.App对结果进行判断并向用户展示结果,转移完成。
若文件需要由移动端转移到PC端,则需要完成如下步骤:
1.在移动端,App发起对可信程序的调用;
2.可信程序完成数据的加密和计算MAC码,调用返回;
3.将加密并附上了消息验证码的数据转移到PC端;
4.PC端的不可信部分发起对安全程序的调用;
5.安全程序对数据进行解密并校验消息验证码,返回结果给不可信部分;
6.不可信部分对结果进行判断并向用户展示结果,转移完成。
下面分别从上述四部分讨论安全应用程序的部署。
PC端安全应用程序的实现
在PC端提供了对Intel SGX技术的支持的情况下,平台具备了开发SGX可信应用程序的能力。SGX支持的操作系统有Windows和Linux。
SGX可信应用程序的组成:SGX可信应用程序由App和Enclave两部分代码组成,前者是应用程序的不可信部分,用来为客户提供调用Enclave中可信程序的接口,后者是位于Enclave中的可信程序,是被隔离起来的,完成安全级别高的操作,在本例中具体表现为文件的加解密操作,将加解密过程与密钥存储隔离在安全区域。前者通过后者向外提供的接口调用后者的安全函数功能。
App文件夹下包含不可信程序的源码头文件等,还有一些工具和函数库,分别在Edger8rSyntax文件夹和TrustedLibrary文件夹下。前者包含了一些特定类别比如array类型的数据的基本调用方式和函数接口,后者提供了一些系统功能函数比如线程控制等。
Enclave文件夹下包含应用程序的可信代码部分和可信与不可信代码接口文件,一般地有六个文件:Enclave.config.xml文件,Enclave.cpp文件,Enclave.h文件,Enclave.edl文件,Enclave.lds文件,Enclave_private.pem文件。以及Edger8rSyntax文件夹和TrustedLibrary文件夹,功能如上,不同的是对于ecall函数,这里完成了函数的定义,而之前只是声明其接口。
Enclave.config.xml文件:作为Enclave的配置文件,定义了Enclave的元数据信息,主要包含一些系统配置信息,比如堆栈大小,TCS数量和策略等,一般不用更改。如果在Encalve中的计算量较大需要更多的堆空间时,在此文件中可以修改分配给Enclave的最大堆空间。
Enclave.cpp文件:该文件是Enclave中可信代码的源码文件,实现了需要被外界调用的函数。在本发明中,该文件里包含了加密解密算法,以及MAC码的计算和验证的具体实现。
Enclave.h文件:该文件是Enclave中可信代码的头文件。
Enclave.edl文件:该文件是Enclave与外界函数交互的接口定义文件,有着至关重要的作用。其中分别定义了不可信代码调用可信代码的函数接口和可信代码调用不可信代码的接口,分别在语句块untrusted和trusted中定义。在本发明中向Enclave外的程序提供的安全例程就在本文件中定义。
Enclave.lds文件:该文件定义的是Encalve可执行文件的信息。
Enclave_private.pem文件:该文件是SGX生成的私钥。
除此之外还包括一个定义用户自定义类型的user_types.h文件和该可信应用程序的编译文件Makefile,分别用于声明用户自定义的数据类型和完成整个安全应用的编译。
Enclave中接口函数的定义:Encalve中的接口函数定义了外界可以从Encalve中调用到的函数,有如下两个,分别完成加密计算MAC码和解密验证MAC码:
3)public void Myencrypt([in,size=16]uint8_t*p_key,[in,size_src_len]uint8_t*p_src,uint32_t src_len,[out,size=dst_len]uint8_t*p_dst,uint32_t dst_len,[in,size=12]uint8_t*p_iv,[in,size=aad_len]uint8_t*p_aad,uint32_t aad_len,[out,size=16]uint8_t*p_out_mac);
该函数为加密函数接口的定义,位于Enclave外的SGX安全应用程序的不可信部分可以通过此接口调用Myencrypt函数。
具体实现为,传入密钥,待加密数据及其长度,iv向量的值及长度,密文数据存放指针,MAC码存放指针作为参数,调用系统的rijndael128GCM加密函数得到密文以及MAC码。判断返回值后得到所需数据,该函数的接口定义在encalve.edl文件中,可以被app中的非安全部分调用。
4)public void Mydecrypt([in,size=16]uint8_t*p_key,[in,size_src_len]uint8_t*p_src,uint32_t src_len,[out,size=dst_len]uint8_t*p_dst,uint32_t dst_len,[in,size=12]uint8_t*p_iv,[in,size=aad_len]uint8_t*p_aad,uint32_t aad_len,[out,size=16]uint8_t*p_in_mac);
该函数为解密函数接口的定义,位于Enclave外的程序可以通过此接口调用Mydecrypt函数。
具体实现为,传入解密所需数据作为参数,包括密文,iv向量,MAC码等,调用rijndael128GCM解密函数还原明文并验证MAC码,进而确认完整性。在判断返回值后将明文返回,该函数的接口同样被定义在enclave.edl文件中供非安全部分调用。
在Enclave.edl文件中将这两个接口函数包括在trusted语句块内,表示这两个接口是由Enclave中的可信代码实现的向外界提供功能的函数,按照如下方式:
至此,在编译完成后这两个函数可以被来自Enclave外的函数调用。
Enclave中功能的实现:位于Enclave内的文件完成的功能为:提供AES-GCM函数。
这里面主要包含AES-GCM的加密模式和解密模式。可以利用的是Intel SGX提供的可信函数库sgx_tcrypto.a,其中包含了一些简单的密码算法。在Makefile中加上该函数库的编译即可添加对该函数库的引用。
从sgx_tcrypto.a中利用的函数有如下两个:
该函数的返回值指示函数是否执行成功,或失败的原因。Enclave中需要写的程序主要是调用这个库函数,预处理是对输入的变量类型做转换和对函数返回进行判断。
该函数的返回值用来判断解密及校验是否成功,若解密操作不成功判断是否因为MAC码不匹配。
不可信部分功能的实现:不可信部分完成的功能为取出指定文件的内容调用Myencrypt函数进行加密和调用Mydecrypt函数进行解密并验证,具体选择哪个功能由用户决定,取决于PC端作为文件的发送端或者接收端。
而调用Encalve中函数的过程如下:
首先初始化Enclave,在这个过程中会得到Encalve的id号,然后使用下面两条语句即可在指定id号的Encalve中执行加密或者解密函数,这两个函数就是上面提到的Enclave可信程序向外提供调用服务的函数。
Myencrypt(global_eid,p_key,p_src,count,p_dst,count,p_iv,NULL,0,p_out_mac);
Mydecrypt(global_eid,p_key,p_src,count,p_dst,count,p_iv,NULL,0,p_in_mac);
也就是把Encalve的id号作为第一个参数传进去,其余的参数则参考函数接口中的声明。
在功能完成后使用sgx_destroy_enclave函数销毁初始化的Enclave。
移动端可信应用程序的组成
这一部分介绍的是移动端提供文件加解密和验证完整性外码的实现。可以分为TrustZone部分和Android App部分。
Android App部分完成与用户的交互,并且调用TrustZone的不可信部分,这是一个Java代码调用C代码的过程。
TrustZone的安全应用程序与SGX安全应用程序类似,同样分为可信部分和不可信部分。可信部分位于安全域内,类似于SGX中位于Encalve中的部分,不可信部分同样通过某些接口与可信部分通信,调用可信部分提供的函数功能。在整个系统中,安全域部分的代码是用来保证系统安全性的。由基于硬件隔离的特点可以保证安全域中数据的存储安全和代码的运行安全,因此系统中与安全有关的操作将会被编译为可供客户端(非安全域)调用的程序,通过TrustZone的安全通信机制进行交互。通过以下几个函数非安全域程序可以完成对安全域功能的调用。
安全域功能的实现:安全域中实现的功能是用来完成具体的密码算法过程的,与SGX中一样采用AES-GCM算法。
非安全域功能的实现:非安全域完成的功能有两个:一是在作为非信任方替客户完成对安全域函数的调用,并最终完成整个密码算法过程的功能。二是在Android App运行的时候,作为本地jni代码供App调用。
Android App的实现:由于应用程序运行在Android操作系统上,所以还需要一个Android App完成最外层的与用户交互的功能。
在app需要调用上面提到的密码算法的类中,声明本地方法:
public native byte[]Encrypt(byte plain_text[]);
public native byte[]Decrypt(byte cipher_text[]);
用jni中的javah命令生成包含本地方法声明的头文件,用C实现其中的方法,即上面的函数Java_com_example_priestess_test_activity_Encrypt和Java_com_example_priestess_test_activity_Decrypt。
用ndk-build命令,指定特定的开发板的编译目标选项,如armeabi-v7a,生成可以被java调用的共享库libMyCrypt.so,并在app需要调用该函数的类中声明加载此共享库:
static{
System.loadLibrary(“MyCrypt”);
}
需要调用Encrypt或者Decrypt函数时,就在app中将需要处理的文件内容取出放入byte数组,然后执行java层的Encrypt或Decrypt函数。
运行过程中jni机制会把对Encrypt或Decrypt函数的调用转换为对libMyCrypt.so库中两个本地C函数的调用,最终返回需要的结果给java层。
具体实施方式
下面结合具体实施例,进一步阐明本发明,应理解这些实施例仅用于说明本发明而不用于限制本发明的范围,在阅读了本发明之后,本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。
一种跨平台使用硬件隔离环境对文件进行加密校验的方法,其中在SGX技术和TrustZone技术的支持下部署用于处理文件加解密和验证的安全应用程序;包括四个部分:PC端安全应用程序,PC端不可信部分,移动端可信程序,移动端不可信部分(Android APP)。
PC端安全应用程序用于完成的是加解密等安全操作,该部分位于SGX的Encalve中,是被硬件隔离保护起来的区域。运行在这里的安全加解密程序不会被攻击者观察到。
PC端不可信部分用于完成的是与PC端用户交互的功能,用户通过该部分向安全应用程序的加解密程序发起请求,调用位于Encalve中的安全应用程序完成加密或解密的操作。PC端安全应用程序和PC端不可信程序之间的交互由Intel SGX的通信机制完成,通过预定义在Enclave中的可信接口和不可信接口完成双向调用。
移动端可信程序位于TrsutZone的Secure World中,也是被硬件隔离保护起来的区域,这部分完成的是加解密和用户验证等安全操作。
移动端不可信部分(Android APP)是运行在移动端的普通app,完成与用户的交互,给用户提供功能界面。用户可以通过它向Secure World发起安全请求,调用可信程序完成数据加解密或是用户验证。移动端可信程序和不可信部分之间的交互由TrustZone机制提供,通过可信程序提供的安全程序入口和函数编号找到对应需要调用的函数,并在调用完成后返回到正常操作系统的普通app中。
若文件需要由PC端转移到移动端,应用本发明需要完成如下步骤:
1.在PC端,运行不可信部分的程序对安全应用程序发起调用;
2.安全应用程序完成加密和计算MAC码,调用返回;
3.将加密并附上了消息验证码的数据转移到移动端;
4.在移动端App发起对可信程序的调用;
5.移动端的可信程序对数据进行解密和校验消息验证码,返回结果给App;
6.App对结果进行判断并向用户展示结果,转移完成。
若文件需要由移动端转移到PC端,则需要完成如下步骤:
1.在移动端,App发起对可信程序的调用;
2.可信程序完成数据的加密和计算MAC码,调用返回;
3.将加密并附上了消息验证码的数据转移到PC端;
4.PC端的不可信部分发起对安全程序的调用;
5.安全程序对数据进行解密并校验消息验证码,返回结果给不可信部分;
6.不可信部分对结果进行判断并向用户展示结果,转移完成。
下面分别从上述四部分讨论安全应用程序的部署。
PC端安全应用程序的实现
在PC端提供了对Intel SGX技术的支持的情况下,平台具备了开发SGX可信应用程序的能力。SGX支持的操作系统有Windows和Linux。
SGX可信应用程序的组成:SGX可信应用程序由App和Enclave两部分代码组成,前者是应用程序的不可信部分,用来为客户提供调用Enclave中可信程序的接口,后者是位于Enclave中的可信程序,是被隔离起来的,完成安全级别高的操作,在本例中实现的操作为文件的加解密操作,将加解密过程与密钥存储隔离在安全区域。前者通过后者向外提供的接口调用后者的安全函数功能。
App文件夹下包含不可信程序的源码头文件等,还有一些Edger8rSyntax工具和TrustedLibrary函数库。前者包含了一些特定类别比如array类型的数据的基本调用方式和函数接口,后者提供了一些系统功能函数比如线程控制等。
Enclave文件夹下包含应用程序的可信代码部分和可信与不可信代码接口文件,一般地有六个文件:Enclave.config.xml文件,Enclave.cpp文件,Enclave.h文件,Enclave.edl文件,Enclave.lds文件,Enclave_private.pem文件,和提供了一些Edger8rSyntax工具和TrustedLibrary函数库的文件夹,包含了一些特定类别比如array类型的数据的基本调用方式和函数接口的定义,和提供了一些系统功能函数比如线程控制等。
Enclave.config.xml文件:作为Enclave的配置文件,定义了Enclave的元数据信息,包含堆栈大小,TCS数量和策略等系统配置信息,一般都是默认值。当自定义的安全app有特殊需求,比如在Encalve中的计算量较大需要更多的堆空间时,在此文件中可以修改分配给Enclave的最大堆空间。
Enclave.cpp文件:该文件是Enclave中可信代码的源码文件,实现了需要被外界调用的函数。在本发明中,该文件里包含了加密解密算法,以及MAC码的计算和验证的具体实现。
Enclave.h文件:该文件是Enclave中可信代码的头文件。
Enclave.edl文件:该文件是Enclave与外界函数交互的接口定义文件,有着至关重要的作用。其中分别定义了不可信代码调用可信代码的函数接口和可信代码调用不可信代码的接口,分别在语句块untrusted和trusted中定义。在本发明中向Enclave外的程序提供的安全例程就在本文件中定义。
Enclave.lds文件:该文件定义的是Encalve可执行文件的信息。
Enclave_private.pem文件:该文件是SGX生成的私钥。
除此之外还包括一个定义用户自定义类型的user_types.h文件和该可信应用程序的编译文件Makefile,分别用于声明用户自定义的数据类型和完成整个安全应用的编译
Enclave中接口函数的定义:Encalve中的接口函数定义了外界可以从Encalve中调用到的函数,有如下两个,分别完成加密计算MAC码和解密验证MAC码:
5)public void Myencrypt([in,size=16]uint8_t*p_key,[in,size_src_len]uint8_t*p_src,uint32_t src_len,[out,size=dst_len]uint8_t*p_dst,uint32_t dst_len,[in,size=12]uint8_t*p_iv,[in,size=aad_len]uint8_t*p_aad,uint32_t aad_len,[out,size=16]uint8_t*p_out_mac);
该函数为加密函数接口的定义,位于Enclave外的SGX安全应用程序的不可信部分可以通过此接口调用Myencrypt函数。
p_key:输入参数。算法的密钥,一般为128bits;
p_src:输入参数。算法的输入,即需要处理的数据;
src_len:输入参数。输入数据的长度;
p_dst:输出参数。算法的输出,即加密处理后的数据;
dst_len:输入参数。加密处理后数据的长度,与p_src一致;
p_iv:输入参数。算法需要的初始化变量,为96bits;
p_aad:输入参数。可选的附加的验证数据,这段数据不会被加密。如果不需要则置为NULL;
aad_len:输入参数。p_aad的长度;
p_out_mac:输入参数。算法执行后计算得到的MAC码,128bits。
具体实现为,调用者传入密钥,待加密数据及其长度,iv向量的值及长度,密文数据存放指针,MAC码存放指针作为传入参数,然后调用系统提供的rijndael128GCM加密函数得到密文以及MAC码。判断返回值后得到所需数据,该函数的接口定义在encalve.edl文件中,可以被app中的非安全部分调用。
6)public void Mydecrypt([in,size=16]uint8_t*p_key,[in,size_src_len]uint8_t*p_src,uint32_t src_len,[out,size=dst_len]uint8_t*p_dst,uint32_t dst_len,[in,size=12]uint8_t*p_iv,[in,size=aad_len]uint8_t*p_aad,uint32_t aad_len,[out,size=16]uint8_t*p_in_mac);
该函数为解密函数接口的定义,位于Enclave外的程序可以通过此接口调用Mydecrypt函数。
p_key:输入参数。算法的密钥,一般为128bits;
p_src:输入参数。算法的输入,即需要处理的密文;
src_len:输入参数。输入数据的长度;
p_dst:输出参数。算法的输出,即解密处理后的数据;
dst_len:输入参数。加密处理后数据的长度,与p_src一致;
p_iv:输入参数。算法需要的初始化变量,为96bits;
p_aad:输入参数。可选的附加的验证数据,这段数据不会被加密。如果不需要则置为NULL;
aad_len:输入参数。p_aad的长度;
p_in_mac:输入参数。数据附上的MAC码,用来验证是否符合完整性校验。
具体实现为,调用者传入上述解密所需数据作为参数,包括密文,iv向量,MAC码等,调用系统提供的rijndael128GCM解密函数还原明文并在判断返回值后验证MAC码,进而确认完整性。在调用成功后将明文返回,该函数的接口同样被定义在enclave.edl文件中供非安全部分调用。
在Enclave.edl文件中将这两个接口函数包括在trusted语句块内,表示这两个接口是由Enclave中的可信代码实现的向外界提供功能的函数,按照如下方式:
至此,在编译完成后这两个函数可以被来自Enclave外的函数调用。
Enclave中功能的实现:在本发明中位于Enclave内的文件完成的功能为:提供AES-GCM函数。
这里面主要包含AES-GCM的加密模式和解密模式。可以利用的是Intel SGX提供的可信函数库sgx_tcrypto.a,其中包含了一些简单的密码算法。在Makefile中加上该函数库的编译即可添加对该函数库的引用。
从sgx_tcrypto.a中利用的函数有如下两个:
该函数的返回值指示函数是否执行成功,或失败的原因。Enclave中需要写的程序主要是调用这个库函数,预处理是对输入的变量类型做转换和对函数返回进行判断。
该函数的返回值用来判断解密及校验是否成功,若解密操作不成功判断是否因为MAC码不匹配。
不可信部分功能的实现:不可信部分完成的功能为取出指定文件的内容调用Myencrypt函数进行加密和调用Mydecrypt函数进行解密并验证,具体选择哪个功能由用户决定,取决于PC端作为文件的发送端或者接收端。
而调用Encalve中函数的过程如下:
首先初始化Enclave,在这个过程中会得到Encalve的id号,然后使用下面两条语句即可在指定id号的Encalve中执行加密或者解密函数,这两个函数就是上面提到的Enclave可信程序向外提供调用服务的函数。
Myencrypt(global_eid,p_key,p_src,count,p_dst,count,p_iv,NULL,0,p_out_mac);
Mydecrypt(global_eid,p_key,p_src,count,p_dst,count,p_iv,NULL,0,p_in_mac);
也就是把Encalve的id号作为第一个参数传进去,其余的参数则参考函数接口中的声明。
在功能完成后使用sgx_destroy_enclave函数销毁初始化的Enclave。
移动端可信应用程序的组成
这一部分介绍的是移动端提供文件加解密和验证完整性外码的实现。可以分为TrustZone部分和Android App部分。
Android App部分完成与用户的交互,并且调用TrustZone的不可信部分,这是一个Java代码调用C代码的过程。
TrustZone的安全应用程序与SGX安全应用程序类似,同样分为可信部分和不可信部分。可信部分位于安全域内,类似于SGX中位于Encalve中的部分,不可信部分同样通过某些接口与可信部分通信,调用可信部分提供的函数功能。在整个系统中,安全域部分的代码是用来保证系统安全性的。由基于硬件隔离的特点可以保证安全域中数据的存储安全和代码的运行安全,因此系统中与安全有关的操作将会被编译为可供客户端(非安全域)调用的程序,通过TrustZone的安全通信机制进行交互。通过以下几个函数非安全域程序可以完成对安全域功能的调用。
1)TEEC_InitializeContext:
此函数用于初始化用于与安全域通信的上下文,为加载TA(TrustedApplication)做准备,这里TA的概念类似与运行在Encalve中的安全函数,是被隔离起来的可信部分。
2)TEEC_OpenSession:
此函数用于创建与一个具体的TA展开会话的例程,由于系统中的每一个TA都有一个独一无二的UUID作为标识,因此在此函数中提供需要交互的TA的UUID,以及上面已经创建并且初始化的上下文,然后可以开始与一个TA的会话。
3)TEEC_InvokeCommand:
此函数是具体用来调用TA中某一个特定函数的,也是真正接触到TA中某个具体功能的地方。因为一个TA中可能提供了很多个不同的函数功能,类似于Enclave.edl中向外提供的函数接口。不同的是,在这里不同的函数有不同的调用号,而之前已经与特定的TA建立起了联系,这个函数使用某一个调用号便可以联系到特定TA中的特定函数。
4)TEEC_CloseSession:
此函数用于关闭与某一个TA之间的会话。
5)TEEC_FinalizeContext:
此函数用于注销与安全域通信的上下文,结束所有操作。
安全域功能的实现:安全域中实现的功能是用来完成具体的密码算法过程的,与SGX中一样采用AES-GCM算法。
(1)TA入口函数
每一个TA的源码中都有一个ta_entry.c,其中定义了五个函数,用来定义使用TA的入口。
TA_CreateEntryPoint:创建TA的入口;
TA_DestroyEntryPoint:销毁TA的入口;
TA_OpenSessionEntryPoint:打开同此TA通信会话的入口;
TA_CloseSessionEntryPoint:关闭同此TA通信会话的入口;
TA_InvokeCommandEntryPoint:调用TA中具体功能的入口,一般是一个选择语句,根据从非安全域传进来的参数中包含的调用号选择具体的功能去执行,完成调用的需求。如在本方法的代码中表现为:
其中nCommandID即为调用号,指示调用者希望调用的具体功能是哪一个。上面截取出的部分代码中的TA_CRYPT_CMD_ALLOCATE_OPERATION和TA_CRYPT_CMD_ALLOCATE_TRANSISTENT_OBJECT都是调用号,分别指向完成具体操作的具体功能函数。例如当用户想要调用ta_entry_allocate_operation函数时,传入它的调用号TA_CRYPT_CMD_ALLOCATE_OPERATION,便能在此处跳转到对应函数。
(2)TA端完成AES-GCM算法的函数描述
1)TEE_Result ta_entry_allocate_operation(uint32_t param_type,TEE_Param params[4])
该函数用于指定密码算法的算法类型和方式,密钥大小,并将这些参数与特定的操作结构绑定。具体操作是将传入的参数应用于TEE内部API列表中的TEE_AllocateOperation函数。
2)TEE_Result ta_entry_allocate_transient_object(uint32_t param_type,TEE_Param params[4])
该函数用于产生一个临时的,有特定用途(如用于AES算法)的密钥结构,具体操作是将传入的参数应用于TEE内部API列表中的TEE_AllocateTransientObject函数。
TEE_Result ta_entry_populate_transient_object(uint32_t param_type,TEE_Param params[4])
3)该函数用来指定某个已经被初始化的密钥结构的具体性质,具体操作是将传入的参数应用于TEE内部API列表中的TEE_populateTransientObject函数。
4)TEE_Result ta_entry_set_operation_key(uint32_t param_type,TEE_Paramparams[4])
该函数用于将一个已经初始化并且指派了性质的密钥结构同一个特定的操作结构绑定起来。具体操作是将传入的参数应用于TEE内部API列表中的TEE_SetOperationKey函数。
5)TEE_Result ta_entry_free_transient_object(unt32_t param_type,TEE_Param params[4])
该函数用于释放指定的临时结构,如释放之前生成的临时密钥结构。具体操作是将传入的参数应用于TEE内部API列表中的TEE_TransientObject函数。
6)TEE_Result ta_entry_ae_init(uint32_t param_type,TEE_Param params[4])
该函数用于进行AES-GCM密码算法的初始化,在此操作中传递进的参数有之前已被绑定了具体算法类型,模式以及密钥的操作结构体。具体操作是将传入的参数应用于TEE内部API列表中的TEE_AEInit函数。
7)TEE_Result ta_entry_ae_update(uint32_t param_type,TEE_Param params[4])
该函数用于进行AES-GCM密码算法过程的更新,除初始化的参数外,还需要传入待加密或解密的数据,以及数据长度。具体操作是将传入的参数应用于TEE内部API列表中的TEE_AEUpdate函数。
8)TEE_Result ta_entry_ae_encrypt_final(uint32_t param_type,TEE_Paramparams[4])
该函数用于进行AES-GCM加密过程的最终处理,在前面一个操作的循环更新下,加密的状态被保存在上下文中,此函数利用这些上下文信息进行加密的收尾工作,如短块处理等。得到最终加密完成的密文数据以及MAC码,作为输出。具体操作是将传入的参数应用于TEE内部API列表中的TEE_AEEncryptFinal函数。
9)TEE_Result ta_entry_ae_decrypt_final(uint32_t param_type,TEE_Paramparams[4])
该函数用于进行AES-GCM解密过程的最终处理同时进行MAC码的校验,此函数的返回值指示解密过程是否成功已经校验值是否与传入的MAC码匹配。具体操作是将传入的参数应用于TEE内部API列表中的TEE_AEDecryptFinal函数。
非安全域功能的实现:非安全域完成的功能有两个:一是在作为非信任方替客户完成对安全域函数的调用,并最终完成整个密码算法过程的功能。二是在Android App运行的时候,作为本地jni代码供App调用。
除了之前提到的几个通用的初始化,创建函数,以及从文件中取出数据,还需要以下函数来完成与安全域的交互。
1)ta_crypt_cmd_allocate_operation函数,调用过程为:
ta_crypt_cmd_allocate_operation(&session,&op,TEE_ALG_AES_GCM,TEE_MODE_ENCRYPT,op_key_size);
而这个函数内部的具体实现为将传入的参数放入TEEC_Operation结构op中,指定参数类型(如传入参数或传出参数,值类型或指针类型)并且发出调用TA中ta_entry_allocate_operation函数的请求:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_ALLOCATE_OPERATION,&op,&ret_orig)
其中s为会话结构,TA_CRYPT_CMD_ALLOCATE_OPERATION为该功能的调用号,op为传入的TEEC_Operation结构,ret_orig为返回值。
2)ta_crypt_cmd_allocate_transient_object函数,调用过程为:
ta_crypt_cmd_allocate_transient_object(&session,TEE_TYPE_AES,key_size,&key_handle);
此函数内部是将传入的参数放入op结构中,并调用安全域中的ta_entry_allocate_transient_object函数:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_ALLOCATE_TRANSIENT_OBJECT,&op,&ret_orig);
其中TA_CRYPT_CMD_ALLOCATE_TRANSIENT_OBJECT为安全域对应函数的调用号。
3)ta_crypt_cmd_populate_transient_object函数,调用过程如下:
ta_crypt_cmd_populate_transient_object(&session,key_handle,&key_attr,1);
该函数内部是将传入的参数填充入op结构中,并调用以下安全域中的函数:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_POPULATE_TRANSIENT_OBJECT,&op,&ret_rig);
4)ta_crypt_cmd_set_operation_key函数,调用过程如下:
ta_crypt_cmd_set_operation_key(c,&session,op,key_handle);
该函数内部是将传入的参数填入op结构中,并调用以下安全域中的函数:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_SET_OPERATION_KEY,&op,&ret_orig);
5)ta_crypt_cmd_free_transient_object函数,调用过程如下:
ta_crypt_cmd_free_transient_object(c,&session,key_handle)
该函数内部是将传入的参数填入op结构中,并调用以下安全域中的函数:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_FREE_OPERATION,&op,&ret_orig);
6)ta_crypt_cmd_ae_init函数,调用过程如下:
Ta_crypt_cmd_ae_init(s,&session,op,ip,ip_len,tag_len,0,ptx_len);
该函数内部是将传入的参数填入op结构中,并调用以下安全域的函数:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_AE_INIT,&op,&ret_orig);
7)ta_crypt_cmd_ae_update函数,调用过程如下:
ta_crypt_cmd_ae_update(s,&session,op,ctx,in_incr,out,&out_size);
该函数内部是将传入的参数填入op结构中,并调用以下安全域函数:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_AE_UPDATE,&op,&ret_orig);
8)ta_crypt_cmd_ae_encrypt_final函数,调用过程如下:
ta_crypt_cmd_ae_encrypt_final(s,&session,op,ptx+in_incr,ptx_len+in_incr,ptx_len-in_incr,out+out_offs,&out_size,out_tag,&out_tag_len);
该函数内部是将传入的参数填入op结构中,并调用以下的安全域函数:
TEEC_InvokeCommand(s,TA_CRYPT_CMD_AE_ENCRYPT_FINAL,&op,&ret_orig);
9)ta_crypt_cmd_ae_decrypt_final函数,调用过程如下:
ta_crypt_cmd_ae_decrypt_final(s,&session,op,ctx+in_incr,ctx_len-in_incr,out+out_offs,&out_size,tag,tag_len);
该函数内部是将传入的参数填入op结构,并调用以下的安全域函数:
TEEC_InvokeCommand(s,TA_cRYPT_CMD_AE_DECRYPT_FINAL,&op,&ret_orig);
10)JNIEXPORT jbyteArray JNICALL Java_com_example_priestess_test_activity_Encrypt(JNIEnv*env,jobject thisObject,jbyteArray ByteArray)函数
该函数作为java和C通信中C端的接口,完成的是在java类中已经声明的本地方法的具体实现过程。传入的参数来源于app的java层,经过jni机制的转换变为C中的变量类型并在此函数中完成加密操作,然后再次通过jni机制转换为java层的变量类型回到app中。
因为java层传递来的是java中的byte数组类型,首先通过jni的GetByteArrayElements函数转换为char数组:
Unsigned char*plain_text=(*env)->GetByteArrayElements(env,ByteArray,NULL);
再通过GetArrayLength函数得到数组的长度,最后使用上面的AES-GCM算法便可以完成密码算法。
得到算法的输出后再将输出转换为jbyteArray,jbyteArray可通过jni转换为java中的byte[]:
jbyteArray ret=(*env)->NewByteArray(env,cxt_length);
(*env)->SetByteArrayRegion(env,ret,0,cxt_length,cipher_text);
最后返回结果。
11)JNIEXPORT jbyteArray JNICALL Java_com_example_priestess_test_activity_Decrypt(JNIEnv*env,jobject thisObject,jbyteArray ByteArray)函数
此函数与上一个函数功能结构都类似,只需要把加密部分改为解密部分。
Android App的实现:由于应用程序运行在Android操作系统上,所以还需要一个Android App完成最外层的与用户交互的功能。
在app需要调用上面提到的密码算法的类中,声明本地方法:
public native byte[]Encrypt(byte plain_text[]);
public native byte[]Decrypt(byte cipher_text[]);
用jni中的javah命令生成包含本地方法声明的头文件,用C实现其中的方法,即上面的函数Java_com_example_priestess_test_activity_Encrypt和Java_com_example_priestess_test_activity_Decrypt。
用ndk-build命令,指定特定的开发板的编译目标选项,如armeabi-v7a,生成可以被java调用的共享库libMyCrypt.so,并在app需要调用该函数的类中声明加载此共享库:
static{
System.loadLibrary(“MyCrypt”);
}
需要调用Encrypt或者Decrypt函数时,就在app中将需要处理的文件内容取出放入byte数组,然后执行java层的Encrypt或Decrypt函数。
运行过程中jni机制会把对Encrypt或Decrypt函数的调用转换为对libMyCrypt.so库中两个本地C函数的调用,最终返回需要的结果给java层。
上面已经分别具体描述了在PC端利用SGX技术部署安全应用程序和在移动端利用TrustZone技术部署安全应用程序的方法。
在PC端,首先在BIOS界面下打开对Intel SGX的支持,安装SGX SDK和PSW,这样就具备了开发SGX应用程序的条件。然后加载SGX driver,按照上面的是实现方法编写Enclave和App文件夹下的代码并编译,便可以执行App中的应用程序。
在移动端,首先需要将TrustZone的软件支持加入到AOSP源码中,目前开源的实现有OP-TEE。并且将自己写的TA(完成安全的加解密和验证)和host(完成对安全域的调用)加入到源码的对应目录中,编译后烧到板子上就完成了环境的搭建,同时可以得到AndroidApp需要的本地jni库。再按照开发Android App的方法,完成与用户交互的App便可以达到安全加解密和验证文件的目的。
这两个平台中的安全应用程序提供的都是文件的加解密和完整性验证功能,在文件转移的过程中,由发送文件的平台完成加密和MAC码计算,由接收文件的平台完成解密和MAC码的验证。

Claims (7)

1.一种跨平台使用硬件隔离环境对文件进行加密校验的方法,其特征在于,在SGX技术和TrustZone技术的支持下部署用于处理文件加解密和验证的安全应用程序;包括四个部分:PC端安全应用程序,PC端不可信部分,移动端可信程序,移动端不可信部分;
PC端安全应用程序用于完成的是加解密的安全操作,该部分位于SGX的Encalve中,是被硬件隔离保护起来的区域;
PC端不可信部分用于完成的是与PC端用户交互的功能,用户通过该部分向安全应用程序的加解密程序发起请求,调用位于Encalve中的安全应用程序完成加密或解密的操作;PC端安全应用程序和PC端不可信程序之间的交互由Intel SGX的通信机制完成,通过预定义在Enclave中的可信接口和不可信接口完成双向调用;
移动端可信程序位于TrsutZone的Secure World中,也是被硬件隔离保护起来的区域,这部分完成的是加解密和用户验证的安全操作;
移动端不可信部分是运行在移动端app,完成与用户的交互,给用户提供功能界面;用户可以通过它向Secure World发起安全请求,调用可信程序完成数据加解密或是用户验证;移动端可信程序和不可信部分之间的交互由TrustZone机制提供,通过可信程序提供的安全程序入口和函数编号找到对应需要调用的函数,并在调用完成后返回到正常操作系统的普通app中。
2.如权利要求1所述的跨平台使用硬件隔离环境对文件进行加密校验的方法,其特征在于,若文件需要由PC端转移到移动端,需要完成如下步骤:
(1)在PC端,运行不可信部分的程序对安全应用程序发起调用;
(2)安全应用程序完成加密和计算MAC码,调用返回;
(3)将加密并附上了消息验证码的数据转移到移动端;
(4)在移动端App发起对可信程序的调用;
(5)移动端的可信程序对数据进行解密和校验消息验证码,返回结果给App;
(6)App对结果进行判断并向用户展示结果,转移完成。
3.如权利要求1所述的跨平台使用硬件隔离环境对文件进行加密校验的方法,其特征在于,若文件需要由移动端转移到PC端,则需要完成如下步骤:
(1)在移动端,App发起对可信程序的调用;
(2)可信程序完成数据的加密和计算MAC码,调用返回;
(3)将加密并附上了消息验证码的数据转移到PC端;
(4)PC端的不可信部分发起对安全程序的调用;
(5)安全程序对数据进行解密并校验消息验证码,返回结果给不可信部分;
(6)不可信部分对结果进行判断并向用户展示结果,转移完成。
4.如权利要求1所述的跨平台使用硬件隔离环境对文件进行加密校验的方法,其特征在于,PC端安全应用程序的实现:
在PC端提供了对Intel SGX技术的支持的情况下,平台具备了开发SGX可信应用程序的能力,SGX支持的操作系统有Windows和Linux;
SGX可信应用程序由App和Enclave两部分代码组成,前者是应用程序的不可信部分,用来为客户提供调用Enclave中可信程序的接口,后者是位于Enclave中的可信程序,是被隔离起来的,完成安全操作,前者通过后者向外提供的接口调用后者的安全函数功能;
App文件夹下包含不可信程序的源码头文件;
Enclave文件夹下包含应用程序的可信代码部分和可信与不可信代码接口文件;
Enclave中接口函数的定义:Encalve中的接口函数定义了外界可以从Encalve中调用到的函数,包括分别完成加密计算MAC码和解密验证MAC码的两个函数:
public void Myencrypt();
该函数为加密函数接口的定义,位于Enclave外的SGX安全应用程序的不可信部分可以通过此接口调用Myencrypt函数;
public void Mydecrypt();
该函数为解密函数接口的定义,位于Enclave外的程序可以通过此接口调用Mydecrypt函数;
Enclave中功能的实现:位于Enclave内的文件完成的功能为:提供AES-GCM函数;主要包含AES-GCM的加密模式和解密模式,利用的是Intel SGX提供的可信函数库sgx_tcrypto.a;在Makefile中加上该函数库的编译即可添加对该函数库的引用;
不可信部分功能的实现:不可信部分完成的功能为取出指定文件的内容调用Myencrypt函数进行加密和调用Mydecrypt函数进行解密并验证,具体选择哪个功能由用户决定,取决于PC端作为文件的发送端或者接收端。
5.如权利要求4所述的跨平台使用硬件隔离环境对文件进行加密校验的方法,其特征在于,调用Encalve中函数的过程如下:
首先初始化Enclave,得到Encalve的id号,然后使用Myencrypt(global_eid, p_key,p_src, count, p_dst, count, p_iv, NULL, 0, p_out_mac);Mydecrypt(global_eid,p_key, p_src, count, p_dst, count, p_iv, NULL, 0, p_in_mac);两个函数即可在指定id号的Encalve中执行加密或者解密函数,这两个函数是Enclave可信程序向外提供调用服务的函数;
在功能完成后使用sgx_destroy_enclave函数销毁初始化的Enclave。
6.如权利要求1所述的跨平台使用硬件隔离环境对文件进行加密校验的方法,其特征在于,移动端可信应用程序是移动端提供文件加解密和验证完整性外码的实现,分为TrustZone部分和Android App部分;
Android App部分完成与用户的交互,并且调用TrustZone的不可信部分;
TrustZone的安全应用程序与SGX安全应用程序类似,同样分为可信部分和不可信部分;可信部分位于安全域内,类似于SGX中位于Encalve中的部分,不可信部分同样通过某些接口与可信部分通信,调用可信部分提供的函数功能;与安全有关的操作将会被编译为可供客户端调用的程序,通过TrustZone的安全通信机制进行交互;
安全域中实现的功能是用来完成具体的密码算法过程的,采用AES-GCM算法;
非安全域完成的功能有两个:一是在作为非信任方替客户完成对安全域函数的调用,并最终完成整个密码算法过程的功能;二是在Android App运行的时候,作为本地jni代码供App调用;
由于应用程序运行在Android操作系统上,所以还需要一个Android App完成最外层的与用户交互的功能;
在app需要调用密码算法的类中,声明本地方法:
public native byte[] Encrypt(byte plain_text[]);
public native byte[] Decrypt(byte cipher_text[]);
用jni中的javah命令生成包含本地方法声明的头文件,用C实现其中的方法;
用ndk-build命令,指定特定的开发板的编译目标选项,生成可以被java调用的共享库libMyCrypt.so,并在app需要调用该函数的类中声明加载此共享库:
需要调用Encrypt或者Decrypt函数时,就在app中将需要处理的文件内容取出放入byte数组,然后执行java层的Encrypt或Decrypt函数;
运行过程中jni机制会把对Encrypt或Decrypt函数的调用转换为对libMyCrypt.so库中两个本地C函数的调用,最终返回需要的结果给java层。
7.如权利要求4所述的跨平台使用硬件隔离环境对文件进行加密校验的方法,其特征在于,Enclave文件夹下包含应用程序的可信代码部分和可信与不可信代码接口文件:Enclave.config.xml文件,Enclave.cpp文件,Enclave.h文件,Enclave.edl文件,Enclave.lds文件,Enclave_private.pem文件;
Enclave.config.xml文件:作为Enclave的配置文件,定义了Enclave的元数据信息;
Enclave.cpp文件:该文件是Enclave中可信代码的源码文件,实现了需要被外界调用的函数,该文件里包含了加密解密算法,以及MAC码的计算和验证的具体实现;
Enclave.h文件:该文件是Enclave中可信代码的头文件;
Enclave.edl文件:该文件是Enclave与外界函数交互的接口定义文件;其中分别定义了不可信代码调用可信代码的函数接口和可信代码调用不可信代码的接口,分别在语句块untrusted和trusted中定义;
Enclave.lds文件:该文件定义的是Encalve可执行文件的信息;
Enclave_private.pem文件:该文件是SGX生成的私钥;
除此之外还包括一个定义用户自定义类型的user_types.h文件和该可信应用程序的编译文件Makefile。
CN201910206708.5A 2019-03-19 2019-03-19 一种跨平台使用硬件隔离环境对文件进行加密校验的方法 Pending CN109948354A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910206708.5A CN109948354A (zh) 2019-03-19 2019-03-19 一种跨平台使用硬件隔离环境对文件进行加密校验的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910206708.5A CN109948354A (zh) 2019-03-19 2019-03-19 一种跨平台使用硬件隔离环境对文件进行加密校验的方法

Publications (1)

Publication Number Publication Date
CN109948354A true CN109948354A (zh) 2019-06-28

Family

ID=67008983

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910206708.5A Pending CN109948354A (zh) 2019-03-19 2019-03-19 一种跨平台使用硬件隔离环境对文件进行加密校验的方法

Country Status (1)

Country Link
CN (1) CN109948354A (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111221629A (zh) * 2020-01-09 2020-06-02 上海沄界信息科技有限公司 计算资源使用量量化方法及装置
CN113065325A (zh) * 2021-02-26 2021-07-02 成都环宇知了科技有限公司 一种基于OpenXml的Excel文档分析方法及系统
CN113239329A (zh) * 2021-04-19 2021-08-10 南京大学 一种用于移动端应用程序的可信执行环境的实现系统
WO2021227524A1 (zh) * 2020-05-15 2021-11-18 山东省计算中心(国家超级计算济南中心) 一种具有安全功能的网络边缘存储装置
CN113946801A (zh) * 2021-11-01 2022-01-18 苏州浪潮智能科技有限公司 基于SGX的Python源码的保护方法和装置
US11928204B2 (en) 2020-12-15 2024-03-12 Foris Technology Pte Ltd Method and system with multiple heterogeneous TEE implementations

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107743133A (zh) * 2017-11-30 2018-02-27 中国石油大学(北京) 移动终端及其基于可信安全环境的访问控制方法和系统
CN107766724A (zh) * 2017-10-17 2018-03-06 华北电力大学 一种可信计算机平台软件栈功能架构的构建方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107766724A (zh) * 2017-10-17 2018-03-06 华北电力大学 一种可信计算机平台软件栈功能架构的构建方法
CN107743133A (zh) * 2017-11-30 2018-02-27 中国石油大学(北京) 移动终端及其基于可信安全环境的访问控制方法和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
张倩颖等: "跨平台的可信执行环境模块方案研究", 《通信学报》 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111221629A (zh) * 2020-01-09 2020-06-02 上海沄界信息科技有限公司 计算资源使用量量化方法及装置
CN111221629B (zh) * 2020-01-09 2023-09-05 上海沄界信息科技有限公司 计算资源使用量量化方法及装置
WO2021227524A1 (zh) * 2020-05-15 2021-11-18 山东省计算中心(国家超级计算济南中心) 一种具有安全功能的网络边缘存储装置
US11928204B2 (en) 2020-12-15 2024-03-12 Foris Technology Pte Ltd Method and system with multiple heterogeneous TEE implementations
CN113065325A (zh) * 2021-02-26 2021-07-02 成都环宇知了科技有限公司 一种基于OpenXml的Excel文档分析方法及系统
CN113065325B (zh) * 2021-02-26 2023-06-23 成都环宇知了科技有限公司 一种基于OpenXml的Excel文档分析方法及系统
CN113239329A (zh) * 2021-04-19 2021-08-10 南京大学 一种用于移动端应用程序的可信执行环境的实现系统
CN113239329B (zh) * 2021-04-19 2024-03-19 南京大学 一种用于移动端应用程序的可信执行环境的实现系统
CN113946801A (zh) * 2021-11-01 2022-01-18 苏州浪潮智能科技有限公司 基于SGX的Python源码的保护方法和装置

Similar Documents

Publication Publication Date Title
EP3387813B1 (en) Mobile device having trusted execution environment
CN109948354A (zh) 一种跨平台使用硬件隔离环境对文件进行加密校验的方法
JP5060652B2 (ja) 呼び出しプログラムについての秘密の封印解除方法
US10972265B2 (en) Addressing a trusted execution environment
EP1725924B1 (en) Device with a cryptographic coprocessor
US7457960B2 (en) Programmable processor supporting secure mode
US20180212940A1 (en) Addressing a trusted execution environment using encryption key
WO2016015141A1 (en) System and method for cryptographic suite management
KR20030082484A (ko) 공개 키 암호화에 기초한 데이터의 저장 및 검색
JP2020506611A (ja) 署名鍵を使用した信頼実行環境へのアドレシング
CN111431718B (zh) 基于tee扩展的计算机通用安全加密转换层方法及系统
CN110235134B (zh) 使用洁净室供应来寻址可信执行环境
JP7256862B2 (ja) 保護されたコンテナ間のセキュア通信方法およびそのシステム
Bugiel et al. TruWalletM: Secure web authentication on mobile platforms
Cooijmans et al. Secure key storage and secure computation in Android
CN113810382B (zh) 一种用于抵御sgx侧信道攻击的密文加载方法
CN110750791A (zh) 基于内存加密保障可信执行环境抗物理攻击的方法及系统
US11552790B2 (en) Method for key sharing between accelerators
CN112182669A (zh) 用于存储所要保护的数据记录的系统和方法
KR20190036779A (ko) 보안 펌웨어 업데이트 방법 및 시스템
Kumbhar et al. Hybrid Encryption for Securing SharedPreferences of Android Applications
US11343083B2 (en) Method for key sharing between accelerators in virtual channel
Tarkhani et al. Trustworthy and Portable Emulation Platform for Digital Preservation.
Sharma Onboard credentials: Hardware assisted secure storage of credentials
CN110059489A (zh) 安全电子设备

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
AD01 Patent right deemed abandoned

Effective date of abandoning: 20240209

AD01 Patent right deemed abandoned