CN103294958A - 面向类Linux系统的内核级虚拟聚合并行加密方法 - Google Patents
面向类Linux系统的内核级虚拟聚合并行加密方法 Download PDFInfo
- Publication number
- CN103294958A CN103294958A CN2013101888260A CN201310188826A CN103294958A CN 103294958 A CN103294958 A CN 103294958A CN 2013101888260 A CN2013101888260 A CN 2013101888260A CN 201310188826 A CN201310188826 A CN 201310188826A CN 103294958 A CN103294958 A CN 103294958A
- Authority
- CN
- China
- Prior art keywords
- key
- encrypted card
- module
- data
- encrypted
- 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.)
- Granted
Links
Images
Landscapes
- Storage Device Security (AREA)
Abstract
本发明公开了一种面向类Linux系统的内核级虚拟聚合并行加密方法，要解决的技术问题是在Linux内核驱动加密卡实现文件的并行加密。技术方案是改进eCryptfs加密文件系统原有的密钥管理模块、数据加解密模块，并设计实现虚拟聚合模块。虚拟聚合模块中，密钥端口映射表负责存放所有加密卡的密钥端口状态，任务调度模块分配加密卡及密钥端口，密钥加载模块完成向密钥端口中导入密钥。改进后的密钥管理模块及数据加解密模块利用虚拟聚合模块分配的加密卡及密钥端口，调用加密卡的编程接口，完成并行文件加解密。采用本发明可以在任何支持eCryptfs的类Linux计算机上，使用多块加密卡进行文件并行加解密，减轻系统CPU的运算压力，提高加密速度和安全性。
Description
技术领域
本发明涉及数据安全技术领域，特别是涉及面向类Linux系统的内核级虚拟聚合并行加密方法。
背景技术
随着计算机技术和互联网的飞速发展，数据泄密事件频频发生，数据安全保密问题日益受到人们的重视。加密技术是保障数据安全的一种非常有力的方式，通过将用户数据文件进行加密保护，能有效地防止非法入侵者窃取用户的机密数据文件。
加密技术按实现方式可分为基于软件的加密和基于硬件的加密：硬件加密通常是采用硬件加密卡等加密设备，如成都天融信研发的SJY17型PCI加密卡、四川卫士通的SJY115系列密码卡；软件加密是通过程序代码实现加解密运算，如OpenSSL函数库。硬件加密由于硬件芯片本身难于被攻击的特点，具有较高的安全性，而软件实现的加密方式存在加密流程容易被跟踪调试、加解密密钥无法安全存放等安全问题。按实现层次可分为应用层加密和操作系统内核层加密。由于内核较之应用程序具有难于调试跟踪特性，加之内核本身的可靠性及复杂性，使得内核层实现的加密方式比应用层实现的加密方式具有更高的安全性。
在目前主流的操作系统中，Windows操作系统占据了大部分市场。在Windows上的加密技术，如EFS（Encrypting File System）加密文件系统，它可方便的加密NTFS文件卷，但由于Windows系统的闭源性，其核心技术是不公开的，而且其内核架构与其它平台存在较大差异，Windows上的加密技术无法应用于其他平台。
类Linux系统作为开放源码的操作系统以其高稳定性和安全性在世界上得到越来越广泛的使用，国内采用类Linux系统的用户也越来越多，我国也基于类Linux操作系统研发了自主可控的国产操作系统，如麒麟，红旗，中标等。在类Linux操作系统内核层实现的数据加解密服务包括用于加密块设备的dm-crypt以及被广泛使用的用于加密文件的eCryptfs。eCryptfs是一个功能强大的企业级的加密文件系统，为应用程序提供透明、动态、高效和安全的文件加解密服务。由于eCryptfs将加密服务集成到文件系统，做到一文一密，较之使用单一密钥加密整个块设备的dm-crypt，eCryptfs加密粒度更细，具有更高的安全性。eCryptfs通过调用内核密码接口（Kernel Crypto API）进行数据加解密操作，由于软算法本身固有的安全隐患，使得eCryptfs加解密过程的安全性受到限制。同时，由于CPU大量的计算能力被用来进行数据加解密，系统的性能也会受到一定的影响。
图1为eCryptfs加密文件系统（简称eCryptfs）在Linux操作系统中的逻辑关系图，eCryptfs工作在操作系统内核的文件系统层次，用户空间的应用程序对加密文件的操作请求由eCryptfs处理。eCryptfs将与文件系统相关的操作交给文件服务层处理，包括响应应用程序的操作请求、判断操作请求的类型、根据操作请求的类型执行相应的处理（如打开文件、读文件、写文件）等，而将与文件数据加解密相关的操作提交给加解密服务层处理。eCryptfs的加解密服务层包含两大模块：数据加解密模块、密钥管理模块。其中，数据加解密模块调用内核密码接口进行文件数据加解密，所使用的密钥称为文件加密密钥FEK（File EncryptionKey）。内核密码接口支持多种对称密钥加密算法，如DES3、AES-128。密钥管理模块负责管理FEK，包括FEK的产生、FEK的加解密。密钥管理模块使用内核伪随机数发生器产生FEK，调用内核密码接口对FEK进行加解密，所使用的密钥为用户持有的文件密钥加密密钥FEKEK（File Encryption Key EncryptionKey），加密后的FEK称为EFEK（Encrypted File Encryption Key），使用密钥状态结构体存放。密钥状态结构体是一种与被操作文件相关联的数据结构，包含记录一些文件信息的数据结构，如文件版本号、文件头大小；与加密相关的数据结构，如FEK、EFEK以及所使用的密钥算法；指向FEKEK的指针等内容。
图2为eCryptfs的文件加解密流程图，步骤如下：
第一步，eCryptfs中文件服务层接收应用程序操作请求。
第二步，文件服务层判断操作请求的类型，如果是打开文件请求，转2.1，如果是读文件请求，转2.2，如果是写文件请求，转2.3。
2.1，应用程序请求打开文件，如果文件不存在，则由文件服务层创建文件，同时密钥管理模块调用内核伪随机数发生器产生FEK，再调用内核密钥接口加密FEK，得到EFEK，将EFEK存入新创建文件的头部，同时，将FEK缓存至新创建文件的密钥状态结构体中，转第三步；如果文件已存在，则文件服务层从已存在文件头部读取EFEK，密钥管理模块调用内核密码接口解密EFEK，得到FEK，将FEK缓存至打开文件的密钥状态结构体中，转第三步。
2.2，应用程序请求读文件，eCryptfs的文件服务层根据读操作请求，读取密文，数据加解密模块调用内核密码接口进行数据解密，解密完成后，由文件服务层提交明文，转第三步。
2.3，应用程序请求写文件，eCryptfs的文件服务层根据写操作请求，数据加解密模块调用内核密码接口对明文数据进行加密，加密完成后，由文件服务层保存密文文件。
第三步，结束。
商用的硬件加密卡由一组密钥存储单元（也称为密钥端口）与加密运算核心组成，密钥存储单元允许使用者通过加密卡驱动程序提供的编程接口（具体编程接口的名称和用法可参见商用的硬件加密卡厂商提供的编程接口文档）向其中导入密钥，加密运算核心通过读取密钥端口已导入的密钥对数据进行加解密。
基本的编程接口如下：
| 接口名 | 描述 |
| GetFileKey | 调用硬件加密卡随机产生一个密钥 |
| LoadFileKey | 向加密卡的密钥端口导入一个密钥 |
| SymEncrypt | 调用硬件加密卡使用密钥端口已导入的密钥对数据进行加密 |
| SymDecrypt | 调用硬件加密卡使用密钥端口已导入的密钥对数据进行解密 |
| GetCardCount | 获取加密卡的数量 |
通过查询国内外已发表的专利，没有公开的在Linux内核使用多块加密卡进行文件并行加解密的方法。电子科技大学学术典藏库中的硕士论文《Linux上内核多加密卡容错实时并行调度系统》文献，提出了针对网络数据传输的加密方法，但该方法无法运用于文件加密。因此，研究一种在Linux内核驱动多加密卡实现文件并行加密的方法，充分利用加密卡高安全、高性能的特性，提高文件加密服务的安全性与性能，有着重要意义和实用价值。目前还没有公开的文献涉及此方面的技术研究。
发明内容
本发明要解决的技术问题是在Linux内核驱动加密卡实现文件的并行加密，提高加密的安全性及加密速度。
本发明的技术方案是：改进eCryptfs加密文件系统加解密服务层中原有的密钥管理模块、数据加解密模块，并设计实现虚拟聚合模块，使eCryptfs支持使用多块加密卡进行文件并行加解密，从而提供一种面向类Linux系统的内核级虚拟聚合并行加密方法。
本发明具体包含如下步骤：
第一步：改进eCryptfs加密文件系统，提供对加密卡并行加密的支持，改进方法是：
1.1改进密钥状态结构体。在密钥状态结构体中增加last_port字段，用以存放最近一次使用的密钥端口映射表（参见1.2.1步）表项的编号，密钥端口映射表包含与此密钥状态结构体相关联文件最近一次加解密操作所使用的加密卡及其密钥端口的编号。
1.2设计虚拟聚合模块，该模块由密钥端口映射表、任务调度模块以及密钥加载模块组成，密钥端口映射表用于存放所有加密卡的密钥端口状态；任务调度模块通过查询密钥端口映射表，为密钥管理模块及数据加解密模块的调用请求均匀地分配加密卡及密钥端口；密钥加载模块通过加密卡驱动程序提供的编程接口向加密卡的密钥存储单元中导入FEK。具体步骤如下：
1.2.1设计密钥端口映射表ports_map，建立所有加密卡密钥端口与密钥端口映射表之间的映射关系。系统中所有加密卡的总数表示为Dcount，单个加密卡包含的密钥端口数量为N（为常量），则ports_map包含的表项数为Dcount*N（“*”表示运算符号“乘”），表示为Pcount。每个表项包括下列域：序号id、加密卡的编号card、加密卡密钥端口号index、端口空闲标识avail以及用于存放FEK的fek区。序号id的范围为0到Pcount-1，card的范围为0到Dcount-1，index的范围为1到N，avail可有EMPTY和BUSY两种取值，EMPTY表示空闲，BUSY表示已占用，fek通常是一段字符数据，存放FEK。
1.2.2设计虚拟聚合模块中的任务调度模块，该模块与密钥管理模块、数据加解密模块以及密钥端口映射表相连，在密钥管理模块及数据加解密模块请求使用加密卡时，任务调度模块通过查询密钥端口映射表，根据加密卡及密钥端口的状态执行任务调度，为操作请求分配加密卡及密钥端口。
1.2.3设计虚拟聚合模块中的密钥加载模块，密钥加载模块与密钥管理模块、数据加解密模块、任务调度模块、密钥端口映射表及加密卡驱动相连，在密钥管理模块及数据加解密模块请求进行数据加解密操作前，查询密钥端口映射表，与加密卡驱动程序交互，调用加密卡LoadFileKey接口，向任务调度模块分配的加密卡及密钥端口中导入密钥，并更新密钥端口映射表ports_map。
1.3修改eCryptfs的密钥管理模块，密钥管理模块与虚拟聚合模块以及加密卡驱动程序相连，由虚拟聚合模块分配可用的加密卡及密钥端口，并与加密卡驱动程序交互，使用加密卡相应的接口，完成FEK的产生及FEK的加解密。具体步骤如下：
1.3.1修改FEK产生方式，将原有调用内核伪随机数发生器的函数修改为调用加密卡驱动提供的GetFileKey接口函数，将GetFileKey产生的密钥作为FEK存放在待加解密文件相关联的密钥状态结构体中。
1.3.2修改FEK的加解密方式，将原有调用内核密码接口进行FEK加解密的方法修改为调用加密卡提供的数据加解密接口SymEncrypt/SymDecrypt进行FEK加解密。
1.4修改数据加解密模块，将原来调用内核密码接口进行数据加解密的方式改为调用加密卡接口进行数据加解密。数据加解密模块与虚拟聚合模块以及加密卡驱动程序相连，由虚拟聚合模块分配可用的加密卡及密钥端口，与加密卡的驱动程序交互，调用加密卡提供的数据加解密接口SymEncrypt/SymDecrypt进行数据加解密。
第二步：使用改进后的eCryptfs加密文件系统进行文件数据加解密。
2.1初始化密钥端口映射表，建立密钥端口映射表与加密卡密钥端口之间的映射关系，具体如下：
2.1.1初始化变量Dcount，使用加密卡接口GetCardCount获取加密卡的数量，存放到变量Dcount中。
2.1.2初始化Pcount，Pcount为所有加密卡密钥端口总数，Pcount=Dcount*单个加密卡的密钥端口数N(N为常量，“*”表示运算符号“乘”)。
2.1.3初始化循环变量i为0。
2.1.4令ports_map[i]表示第i项密钥端口映射表的数据，修改ports_map第i项的id域为i，card域为i%Dcount（%表示运算符号“取模”），index域为i/Dcount（/表示运算符号“除”，所得结果向上取整）。
2.1.5令i=i+1，如果i<Pcount，转2.1.4继续建立映射关系，否则转2.1.6。
2.1.6将ports_map的前Dcount项为作为保留项，称为保留密钥端口映射表reserved_ports_map。
2.1.7使用加密卡接口LoadFileKey向reserved_ports_map表中各项对应的fek域导入用户提供的文件密钥加密密钥FEKEK。
2.2eCryptfs的文件服务层接收应用程序操作请求，并判断操作请求的类型，如果是打开文件，转2.2.1，如果是写文件，转2.2.2，如果是读文件，转2.2.3。
2.2.1如果文件不存在，执行2.2.11，如果文件已存在，执行2.2.1.2。
2.2.1.1文件不存在时，执行如下步骤：
2.2.1.1.1eCryptfs的文件服务层执行创建文件函数创建新文件。
2.2.1.1.2密钥管理模块采用加密卡驱动程序提供的GetFileKey函数产生FEK。
2.2.1.1.3任务调度模块从保留密钥端口映射表reserved_ports_map中获取可用的保留加密卡及密钥端口，方法是：
2.2.1.1.3.1初始化循环变量i为0。
2.2.1.1.3.2令reserved_entry为reserved_ports_map表第i项的数据，判断reserved_entry的avail字段是否为EMPTY，若不是，转2.2.1.1.3.3，否则转2.2.1.1.3.5。
2.2.1.1.3.3令i=i+1，若i<Dcount，则转2.2.1.1.3.2继续遍历，否则转2.2.1.1.3.4。
2.2.1.1.3.4调用Linux内核API函数schedule等待一个调度周期，转2.2.1.1.3.1重新遍历。
2.2.1.1.3.5将reserved_entry的avail字段置为BUSY。
2.2.1.1.4密钥管理模块调用加密卡加密FEK，得到EFEK，方法是：
2.2.1.1.4.1密钥管理模块调用加密卡接口SymEncrypt，以reserved_entry对应密钥端口已导入的FEKEK对FEK进行加密，得到EFEK。
2.2.1.1.4.2任务调度模块将reserved_entry的avail字段置为EMPTY，释放占用的保留密钥端口。
2.2.1.1.5密钥管理模块将EFEK存放到新创建文件的头部。
2.2.1.1.6密钥管理模块将FEK存入到新创建文件的密钥状态结构体中，转2.3步。
2.2.1.2文件已存在，执行如下步骤：
2.2.1.2.1密钥管理模块从已存在文件头部读取EFEK。
2.2.1.2.2任务调度模块采用步骤2.2.1.1.3的方法从保留密钥端口映射表中获取可用的保留加密卡及密钥端口。
2.2.1.2.3密钥管理模块调用加密卡接口解密EFEK，得到FEK，方法是：
2.2.1.2.3.1密钥管理模块调用加密卡接口SymDecrypt，以reserved_entry对应密钥端口已导入的FEKEK对EFEK进行解密，得到FEK。
2.2.1.2.3.2任务调度模块将reserved_entry的avail字段置为EMPTY，释放占用的保留密钥端口。
2.2.1.2.4将FEK缓存至打开文件的密钥状态结构体中，转2.3步。
2.2.2写操作请求执行步骤如下：
2.2.2.1任务调度模块分配加密卡及密钥端口，方法是：
2.2.2.1.1初始化last，存放待加密文件的密钥状态结构体stat的last_port字段的值。
2.2.2.1.2判断ports_map表第last项（称为last_entry）的avail字段是否为EMPTY，如果不是，转2.2.2.1.4，否则转2.2.2.1.3。
2.2.2.1.3判断ports_map第last_entry项的fek字段的值是否与stat存放的fek字段的值相等，如果不相等，转2.2.2.1.4，如果相等，转2.2.2.1.8。
2.2.2.1.4令循环变量i＝0。
2.2.2.1.5判断ports_map表第(last+i)%Pcount项（称为new_entry，“%”为运算符“取模”）的id字段是否小于Dcount，如果小于，转2.2.2.1.7继续遍历；否则，执行2.2.2.1.6。
2.2.2.1.6判断ports_map表第new_entry项的avail字段是否为EMPTY，如果不是，转2.2.2.1.7继续遍历，如果是，转2.2.2.1.9。
2.2.2.1.7令i=i+1，若i<Pcount，则转2.2.2.1.5，否则，调用Linux内核API函数schedule等待一个调度周期，并转2.2.2.1.4重新遍历。
2.2.2.1.8令entry＝last_entry，转2.2.2.2。
2.2.2.1.9令entry＝new_entry。
2.2.2.2密钥加载模块向分配的加密卡密钥端口加载密钥，方法是：
2.2.2.2.1将entry的avail字段设置为BUSY
2.2.2.2.2判断entry的id字段是否与待加密文件的密钥状态结构体stat的last_port字段相等，若相等，转2.2.2.2.5，若不相等，执行2.2.2.2.3；
2.2.2.2.3将stat的last_port字段置为ports_map表第entry项的id域。
2.2.2.2.4将stat存放的fek复制到ports_map表第entry项的fek域。
2.2.2.2.5采用加密卡接口LoadFileKey函数，根据ports_map表第entry项的card及index域向对应的加密卡密钥端口导入stat存放的fek。
2.2.2.3数据加解密模块调用加密卡接口对明文数据进行加密，方法是：
2.2.2.3.1数据加解密模块将待加密数据以加密卡支持的数据长度为单位进行分片。
2.2.2.3.2数据加解密模块将分片后的数据逐片提交给加密卡进行处理，方法是：
2.2.2.3.2.1初始化data为存放原始数据以及加密后数据的内存空间。
2.2.2.3.2.2将待处理的数据片复制到data。
2.2.2.3.2.3数据加解密模块采用加密卡接口SymEncrypt，使用步骤2.2.2.2中已导入的密钥对data进行加密。
2.2.2.3.3文件服务层将加密后的数据逐片地进行拼接。
2.2.2.3.4任务调度模块将entry的avail置为EMPTY，释放占用的加密卡密钥端口。
2.2.2.4加密完成后，保存密文文件，转2.3步。
2.2.3读操作请求执行步骤如下：
2.2.3.1文件服务模块根据操作类型读取密文
2.2.3.2任务调度模块采用步骤2.2.2.1的方法分配加密卡及密钥端口。
2.2.3.3密钥加载模块采用步骤2.2.2.2的方法向分配的加密卡密钥端口加载密钥。
2.2.3.4数据加解密模块调用加密卡接口进行数据解密，方法是：
2.2.3.4.1数据加解密模块将待解密数据以加密卡支持的数据长度为单位进行分片。
2.2.3.4.2数据加解密模块将分片后的数据逐片提交给加密卡进行处理，方法是：
2.2.3.4.2.1初始化data为存放原始数据以及解密后数据的内存空间。
2.2.3.4.2.2将待处理的数据片复制到data。
2.2.3.4.2.3数据加解密模块采用加密卡接口SymDecryptt，使用步骤2.2.3.3已导入的密钥对data进行解密。
2.2.3.4.3文件服务层将解密后的数据逐片地进行拼接。
2.2.3.4.4任务调度模块将entry的avail置为EMPTY，释放占用的加密卡密钥端口
2.2.3.5解密完成后，向应用程序提交明文。
2.3结束。
本发明提供了一种面向类Linux系统的内核级并行加解密方法。采用本发明后，用户可以在任何支持eCryptfs的类Linux计算机上，使用加密卡进行文件数据加解密，其技术效果表现在以下几点：
1、本发明设计了虚拟聚合模块，能够将多块加密卡虚拟成一块性能强大的虚拟加密卡，对应用程序提供统一的文件操作接口，屏蔽多卡并行加解密的实现细节。系统对虚拟加密卡的加解密请求将均衡分发至底层多块加密卡，以利用多块加密卡的并行运算能力，减轻了系统CPU的运算压力，提高系统的加解密吞吐率。
2、本发明改进了FEK的产生方式，其中，将FEK的产生方式由内核提供的随机函数发生器改为通过商用硬件加密卡产生，解决了因内核随机数发生器生成的随机数质量不高、无法安全存放等安全问题。
3、本发明改进了FEK加解密及数据加解密过程，将原来调用内核密码接口由CPU执行运算的软件加密方式改为调用加密卡加密的硬件加密方式，这种改进有三个方面的好处：第一，解决了某些高密度的加密运算占用CPU资源，影响系统整体运行效率的问题；第二，由于硬件芯片本身难于被攻击的特点，硬件加密方式的加密流利不易被跟踪高度，具有更高的安全性；第三，解决了受CPU运算性能的限制，加密速度不高的瓶颈问题。
附图说明
图1：背景技术所述eCryptfs加密文件系统逻辑关系图。
图2：背景技术所述eCryptfs加密文件系统加解密流程。
图3：本发明的总体流程图。
图4：本发明第一步所改进的eCryptfs加密文件系统的架构图。
具体实施方式
图3为本发明的总体流程图。
第一步：改进eCryptfs加密文件系统，提供对商用加密卡并行加密的支持。
1.1改进密钥状态结构体。在密钥状态结构体中增加last_port字段，用以存放最近一次使用的密钥端口映射表表项的编号，密钥端口映射表包含与此密钥状态结构体相关联文件最近一次加解密操作所使用的加密卡及其密钥端口的编号。
1.2设计虚拟聚合模块，该模块由密钥端口映射表、任务调度模块以及密钥加载模块组成，密钥端口映射表用于存放所有加密卡的密钥端口状态；任务调度模块通过查询密钥端口映射表，为密钥管理模块及数据加解密模块的调用请求均匀地分配加密卡及密钥端口；密钥加载模块通过加密卡驱动程序提供的编程接口向加密卡的密钥存储单元中导入FEK。
1.3修改eCryptfs的密钥管理模块，密钥管理模块与虚拟聚合模块以及加密卡驱动程序相连，由虚拟聚合模块分配可用的加密卡及密钥端口，并与加密卡驱动程序交互，使用加密卡相应的接口，完成FEK的产生及FEK的加解密。
1.4修改数据加解密模块，将原来调用内核密码接口进行数据加解密的方式改为调用加密卡接口进行数据加解密。数据加解密模块与虚拟聚合模块以及加密卡驱动程序相连，由虚拟聚合模块分配可用的加密卡及密钥端口，与加密卡的驱动程序交互，调用加密卡提供的数据加解密接口SymEncrypt/SymDecrypt进行数据加解密。
第二步：使用改进后的eCryptfs加密文件系统进行文件数据加解密。
2.1初始化密钥端口映射表，建立密钥端口映射表与加密卡密钥端口之间的映射关系。
2.2eCryptfs的文件服务层接收应用程序操作请求，并判断操作请求的类型，根据操作请求的类型，执行相应的流程。
应用程序请求打开文件时，如果文件不存在，则由eCryptfs的文件服务层执行创建文件函数创建新文件，同是密钥管理模块采用加密卡驱动程序提供的GetFileKey函数产生FEK，然后任务调度模块从保留密钥端口映射表获取可用的保留加密卡及密钥端口，密钥管理模块调用加密卡加密FEK，得到EFEK，再将EFEK存放到新创建文件的头部，并将FEK存入到新创建文件的密钥状态结构体中。如果文件已存在，则密钥管理模块从已存在文件头部读取EFEK，任务调度模块从保留密钥端口映射表中获取可用的保留加密卡及密钥端口，调用加密卡接口解密EFEK，得到FEK，将FEK缓存至打开文件的密钥状态结构体中。
应用程序请求写操作时，首先由任务调度模块分配加密卡及密钥端口，然后密钥加载模块向分配的加密卡密钥端口加载密钥，最后数据加解密模块调用加密卡接口对明文数据进行加密，加密完成后，保存密文文件。
应用程序请求读操作时，文件服务模块根据操作类型读取密文，任务调度模块分配加密卡及密钥端口，然后密钥加载模块向分配的加密卡密钥端口加载密钥，最后数据加解密模块调用加密卡接口进行数据解密，解密完成后，向应用程序提交明文。
图4为本发明第一步所改进的eCryptfs加密文件系统的架构图，本发明在不改变加解密服务层接口的基础上，修改密钥管理模块、数据加解密模块，并设计实现虚拟聚合模块。
虚拟聚合模块由密钥端口映射表、任务调度模块、密钥加载模块组成，其中，密钥端口映射表ports_map为多块加密卡生成一个用于存放所有加密卡密钥端口状态的数据表，对于ports_map的调用者而言，它所操作加密卡可以被视为一块支持多路密钥通道的虚拟加密卡，不需要考虑底层多卡并行加解密的细节；任务调度模块与密钥管理模块、数据加解密模块以及密钥端口映射表相连，在密钥管理模块及数据加解密模块请求使用加密卡时，任务调度模块通过查询密钥端口映射表，根据加密卡及密钥端口的状态执行任务调度，为操作请求分配加密卡及密钥端口，实现多块加密卡负载均衡调度。密钥加载模块与密钥管理模块、数据加解密模块、任务调度模块、密钥端口映射表及加密卡驱动相连，在密钥管理模块及数据加解密模块请求进行数据加解密操作前，密钥加载模块利用加密卡的密钥端口在加密卡内部缓存部分最近使用文件的文件密钥，查询密钥端口映射表，与加密卡驱动程序交互，调用加密卡LoadFileKey接口，向任务调度模块分配的加密卡及密钥端口中导入密钥，并更新密钥端口映射表ports_map。
密钥管理模块及数据加解密模块处理与文件数据加解密相关的操作，与虚拟聚合模块及加密卡驱动相连，通过虚拟聚合模块获取可用的加密卡及密钥端口，调用加密卡的相关操作接口，使用已获取的加密卡及密钥端口完成密钥管理及文件数据加解密。
Claims (7)
1.一种面向类Linux系统的内核级虚拟聚合并行加密方法，其特征在于包括以下步骤：
第一步：改进eCryptfs加密文件系统，方法是：
1.1改进密钥状态结构体，在密钥状态结构体中增加last_port字段，用以存放最近一次使用的密钥端口映射表表项的编号；
1.2设计虚拟聚合模块，该模块由密钥端口映射表、任务调度模块以及密钥加载模块组成，密钥端口映射表用于存放所有加密卡的密钥端口状态；任务调度模块通过查询密钥端口映射表，为密钥管理模块及数据加解密模块的调用请求均匀地分配加密卡及密钥端口；密钥加载模块通过加密卡驱动程序提供的编程接口向加密卡的密钥存储单元中导入文件加密密钥FEK：
1.2.1设计密钥端口映射表ports_map，建立所有加密卡密钥端口与密钥端口映射表之间的映射关系；系统中所有加密卡的总数表示为Dcount，单个加密卡包含的密钥端口数量为N，N为正整数，ports_map包含的表项数为Dcount*N，表示为Pcount，每个表项包括下列域：序号id、加密卡的编号card、加密卡密钥端口号index、端口空闲标识avail以及用于存放FEK的fek区；序号id的范围为0到Pcount-1，card的范围为0到Dcount-1，index的范围为1到N，avail可有EMPTY和BUSY两种取值，EMPTY表示空闲，BUSY表示已占用，fek通常是一段字符数据，存放FEK；
1.2.2设计虚拟聚合模块中的任务调度模块，任务调度模块与密钥管理模块、数据加解密模块以及密钥端口映射表相连，在密钥管理模块及数据加解密模块请求使用加密卡时，任务调度模块通过查询密钥端口映射表，根据加密卡及密钥端口的状态执行任务调度，为操作请求分配加密卡及密钥端口；
1.2.3设计虚拟聚合模块中的密钥加载模块，密钥加载模块与密钥管理模块、数据加解密模块、任务调度模块、密钥端口映射表及加密卡驱动相连，在密钥管理模块及数据加解密模块请求进行数据加解密操作前，查询密钥端口映射表，与加密卡驱动程序交互，调用加密卡LoadFileKey接口，向任务调度模块分配的加密卡及密钥端口中导入密钥，并更新密钥端口映射表ports_map；
1.3修改eCryptfs的密钥管理模块，密钥管理模块与虚拟聚合模块以及加密卡驱动程序相连，由虚拟聚合模块分配可用的加密卡及密钥端口，并与加密卡驱动程序交互，使用加密卡相应的接口，完成FEK的产生及FEK的加解密；
1.4修改数据加解密模块，将原来调用内核密码接口进行数据加解密的方式改为调用加密卡接口进行数据加解密；数据加解密模块与虚拟聚合模块以及加密卡驱动程序相连，由虚拟聚合模块分配可用的加密卡及密钥端口，与加密卡的驱动程序交互，调用加密卡提供的数据加解密接口SymEncrypt/SymDecrypt进行数据加解密；
第二步：使用改进后的eCryptfs加密文件系统进行文件数据加解密，方法是：
2.1初始化密钥端口映射表，建立密钥端口映射表与加密卡密钥端口之间的映射关系；
2.2eCryptfs的文件服务层接收应用程序操作请求，并判断操作请求的类型，根据操作请求的类型，如果是打开文件，转2.2.1，如果是写文件，转2.2.2，如果是读文件，转2.2.3；
2.2.1如果文件不存在，执行2.2.11，如果文件已存在，执行2.2.1.2。
2.2.1.1文件不存在时，执行如下步骤：
2.2.1.1.1eCryptfs的文件服务层执行创建文件函数创建新文件；
2.2.1.1.2密钥管理模块采用加密卡驱动程序提供的GetFileKey函数产生FEK；
2.2.1.1.3任务调度模块从保留密钥端口映射表reserved_ports_map中获取可用的保留加密卡及密钥端口；
2.2.1.1.4密钥管理模块调用加密卡加密FEK，得到EFEK即加密后的FEK；
2.2.1.1.5密钥管理模块将EFEK存放到新创建文件的头部；
2.2.1.1.6密钥管理模块将FEK存入到新创建文件的密钥状态结构体中，转2.3步；
2.2.1.2文件已存在，执行如下步骤：
2.2.1.2.1密钥管理模块从已存在文件头部读取EFEK；
2.2.1.2.2任务调度模块采用步骤2.2.1.1.3的方法从保留密钥端口映射表中获取可用的保留加密卡及密钥端口；
2.2.1.2.3密钥管理模块调用加密卡接口解密EFEK，得到FEK；
2.2.1.2.4将FEK缓存至打开文件的密钥状态结构体中，转2.3步；
2.2.2写操作请求执行步骤如下：
2.2.2.1任务调度模块分配加密卡及密钥端口，方法是：
2.2.2.1.1初始化last，存放待加密文件的密钥状态结构体stat的last_port字段的值；
2.2.2.1.2判断ports_map表第last项即last_entry的avail字段是否为EMPTY，如果不是，转2.2.2.1.4，否则转2.2.2.1.3；
2.2.2.1.3判断ports_map第last_entry项的fek字段的值是否与stat存放的fek字段的值相等，如果不相等，转2.2.2.1.4，如果相等，转2.2.2.1.8；
2.2.2.1.4令循环变量i＝0；
2.2.2.1.5判断ports_map表第(last+i)%Pcount项的id字段是否小于Dcount，如果小于，转2.2.2.1.7；否则，执行2.2.2.1.6；第(last+i)%Pcount项称为new_entry，“%”为运算符“取模”；
2.2.2.1.6判断ports_map表第new_entry项的avail字段是否为EMPTY，如果不是，转2.2.2.1.7，如果是，转2.2.2.1.9；
2.2.2.1.7令i=i+1，若i<Pcount，则转2.2.2.1.5，否则，调用Linux内核API函数schedule等待一个调度周期，并转2.2.2.1.4；
2.2.2.1.8令entry＝last_entry，转2.2.2.2；
2.2.2.1.9令entry＝new_entry；
2.2.2.2密钥加载模块向分配的加密卡密钥端口加载密钥，方法是：
2.2.2.2.1将entry的avail字段设置为BUSY；
2.2.2.2.2判断entry的id字段是否与待加密文件的密钥状态结构体stat的last_port字段相等，若相等，转2.2.2.2.5，若不相等，执行2.2.2.2.3；
2.2.2.2.3将stat的last_port字段置为ports_map表第entry项的id域。
2.2.2.2.4将stat存放的fek复制到ports_map表第entry项的fek域；
2.2.2.2.5采用加密卡接口LoadFileKey函数，根据ports_map表第entry项的card及index域向对应的加密卡密钥端口导入stat存放的fek；
2.2.2.3数据加解密模块调用加密卡接口对明文数据进行加密；
2.2.2.4加密完成后，保存密文文件，转2.3步；
2.2.3读操作请求执行步骤如下：
2.2.3.1文件服务模块根据操作类型读取密文；
2.2.3.2任务调度模块采用步骤2.2.2.1的方法分配加密卡及密钥端口；
2.2.3.3密钥加载模块采用步骤2.2.2.2的方法向分配的加密卡密钥端口加载密钥；
2.2.3.4数据加解密模块调用加密卡接口进行数据解密；
2.2.2.5解密完成后，向应用程序提交明文；
2.3结束。
2.如权利要求1所述的一种面向类Linux系统的内核级虚拟聚合并行加密方法，其特征在于所述修改eCryptfs的密钥管理模块的具体步骤如下：
2.1修改FEK产生方式，将原有调用内核伪随机数发生器的函数修改为调用加密卡驱动提供的GetFileKey接口函数，将GetFileKey产生的密钥作为FEK存放在待加解密文件相关联的密钥状态结构体中；
2.2修改FEK的加解密方式，将原有调用内核密码接口进行FEK加解密的方法修改为调用加密卡提供的数据加解密接口SymEncrypt/SymDecrypt进行FEK加解密。
3.如权利要求1所述的一种面向类Linux系统的内核级虚拟聚合并行加密方法，其特征在于所述任务调度模块从保留密钥端口映射表reserved_ports_map中获取可用的保留加密卡及密钥端口的方法是：
3.1初始化循环变量i为0；
3.2令reserved_entry为reserved_ports_map表第i项的数据，判断reserved_entry的avail字段是否为EMPTY，若不是，转3.3，否则转3.5；
3.3令i=i+1，若i<Dcount，则转3.2，否则转3.4；
3.4调用Linux内核API函数schedule等待一个调度周期，转3.1；
3.5将reserved_entry的avail字段置为BUSY。
4.如权利要求1所述的一种面向类Linux系统的内核级虚拟聚合并行加密方法，其特征在于所述密钥管理模块调用加密卡加密FEK，得到EFEK的方法是：
4.1密钥管理模块调用加密卡接口SymEncrypt，以reserved_entry对应密钥端口已导入的文件密钥加密密钥FEKEK对FEK进行加密，得到EFEK；
4.2任务调度模块将reserved_entry的avail字段置为EMPTY，释放占用的保留密钥端口。
5.如权利要求1所述的一种面向类Linux系统的内核级虚拟聚合并行加密方法，其特征在于密钥管理模块调用加密卡接口解密EFEK，得到FEK的方法是：
5.1密钥管理模块调用加密卡接口SymDecrypt，以reserved_entry对应密钥端口已导入的FEKEK对EFEK进行解密，得到FEK；
5.2任务调度模块将reserved_entry的avail字段置为EMPTY，释放占用的保留密钥端口。
6.如权利要求1所述的一种面向类Linux系统的内核级虚拟聚合并行加密方法，其特征在于所述执行写操作请求时，数据加解密模块调用加密卡接口对明文数据进行加密的方法是：
6.1数据加解密模块将待加密数据以加密卡支持的数据长度为单位进行分片；
6.2数据加解密模块将分片后的数据逐片提交给加密卡进行处理，方法是：
6.2.1初始化data为存放原始数据以及加密后数据的内存空间；
6.2.2将待处理的数据片复制到data；
6.2.3数据加解密模块采用加密卡接口SymEncrypt，使用步骤2.2.2.2中已导入的密钥对data进行加密；
6.3文件服务层将加密后的数据逐片地进行拼接；
6.4任务调度模块将entry的avail置为EMPTY，释放占用的加密卡密钥端口。
7.如权利要求1所述的一种面向类Linux系统的内核级虚拟聚合并行加密方法，其特征在于所述执行读操作请求时，数据加解密模块调用加密卡接口进行数据解密的方法是：
7.1数据加解密模块将待解密数据以加密卡支持的数据长度为单位进行分片；
7.2数据加解密模块将分片后的数据逐片提交给加密卡进行处理，方法是：
7.2.1初始化data为存放原始数据以及解密后数据的内存空间；
7.2.2将待处理的数据片复制到data；
7.2.3数据加解密模块采用加密卡接口SymDecryptt，使用步骤2.2.3.3中已导入的密钥对data进行解密；
7.4.3文件服务层将解密后的数据逐片地进行拼接；
7.4.4任务调度模块将entry的avail置为EMPTY，释放占用的加密卡密钥端口。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310188826.0A CN103294958B (zh) | 2013-05-21 | 2013-05-21 | 面向类Linux系统的内核级虚拟聚合并行加密方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310188826.0A CN103294958B (zh) | 2013-05-21 | 2013-05-21 | 面向类Linux系统的内核级虚拟聚合并行加密方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103294958A true CN103294958A (zh) | 2013-09-11 |
| CN103294958B CN103294958B (zh) | 2015-07-22 |
Family
ID=49095800
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310188826.0A Expired - Fee Related CN103294958B (zh) | 2013-05-21 | 2013-05-21 | 面向类Linux系统的内核级虚拟聚合并行加密方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103294958B (zh) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103605927A (zh) * | 2013-11-08 | 2014-02-26 | 深圳市道通科技有限公司 | 一种基于嵌入式Linux系统实现加密和解密方法 |
| CN104317551A (zh) * | 2014-10-17 | 2015-01-28 | 北京德加才科技有限公司 | 一种超高安全的真随机数生成方法及真随机数生成系统 |
| CN104636685A (zh) * | 2015-02-25 | 2015-05-20 | 山东超越数控电子有限公司 | 一种龙芯硬件平台上的linux操作系统保护方法 |
| CN105373744A (zh) * | 2015-10-29 | 2016-03-02 | 成都卫士通信息产业股份有限公司 | 基于Linux的扩展文件系统加密方法 |
| CN105631343A (zh) * | 2014-10-29 | 2016-06-01 | 航天信息股份有限公司 | 基于加密卡和服务器的密码运算的实现方法和装置 |
| CN106682521A (zh) * | 2016-11-28 | 2017-05-17 | 北京计算机技术及应用研究所 | 基于驱动层的文件透明加解密系统及方法 |
| CN107092835A (zh) * | 2017-04-21 | 2017-08-25 | 杭州华澜微电子股份有限公司 | 一种虚拟存储盘的计算机数据加密装置及方法 |
| CN107220550A (zh) * | 2017-04-19 | 2017-09-29 | 上海海加网络科技有限公司 | 基于eCryptfs的加密卡性能优化方法及系统 |
| CN107247625A (zh) * | 2017-06-14 | 2017-10-13 | 湖南麒麟信安科技有限公司 | 一种基于多卡冗余校验的数据加解密调度方法 |
| CN111539042A (zh) * | 2020-07-13 | 2020-08-14 | 南京云信达科技有限公司 | 一种基于核心数据文件可信存储的安全操作方法 |
| CN116827930A (zh) * | 2023-03-27 | 2023-09-29 | 盘锦千寻信息技术有限公司 | 便携式计算机 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101620547A (zh) * | 2009-07-03 | 2010-01-06 | 中国人民解放军国防科学技术大学 | X86计算机虚拟化的物理中断处理方法 |
| US20100185852A1 (en) * | 2007-07-05 | 2010-07-22 | Hitachi Software Engineering Co., Ltd. | Encryption and decryption method for shared encrypted file |
| CN101859263A (zh) * | 2010-06-12 | 2010-10-13 | 中国人民解放军国防科学技术大学 | 一种支持在线迁移的虚拟机间快速通信方法 |
| CN102646079A (zh) * | 2012-04-23 | 2012-08-22 | 中国人民解放军国防科学技术大学 | 面向类Linux操作系统的磁盘数据保护方法 |
-
2013
- 2013-05-21 CN CN201310188826.0A patent/CN103294958B/zh not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100185852A1 (en) * | 2007-07-05 | 2010-07-22 | Hitachi Software Engineering Co., Ltd. | Encryption and decryption method for shared encrypted file |
| CN101620547A (zh) * | 2009-07-03 | 2010-01-06 | 中国人民解放军国防科学技术大学 | X86计算机虚拟化的物理中断处理方法 |
| CN101859263A (zh) * | 2010-06-12 | 2010-10-13 | 中国人民解放军国防科学技术大学 | 一种支持在线迁移的虚拟机间快速通信方法 |
| CN102646079A (zh) * | 2012-04-23 | 2012-08-22 | 中国人民解放军国防科学技术大学 | 面向类Linux操作系统的磁盘数据保护方法 |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103605927A (zh) * | 2013-11-08 | 2014-02-26 | 深圳市道通科技有限公司 | 一种基于嵌入式Linux系统实现加密和解密方法 |
| CN103605927B (zh) * | 2013-11-08 | 2017-01-11 | 深圳市道通科技股份有限公司 | 一种基于嵌入式Linux系统实现加密和解密方法及装置 |
| CN104317551A (zh) * | 2014-10-17 | 2015-01-28 | 北京德加才科技有限公司 | 一种超高安全的真随机数生成方法及真随机数生成系统 |
| CN105631343A (zh) * | 2014-10-29 | 2016-06-01 | 航天信息股份有限公司 | 基于加密卡和服务器的密码运算的实现方法和装置 |
| CN104636685A (zh) * | 2015-02-25 | 2015-05-20 | 山东超越数控电子有限公司 | 一种龙芯硬件平台上的linux操作系统保护方法 |
| CN105373744A (zh) * | 2015-10-29 | 2016-03-02 | 成都卫士通信息产业股份有限公司 | 基于Linux的扩展文件系统加密方法 |
| CN106682521A (zh) * | 2016-11-28 | 2017-05-17 | 北京计算机技术及应用研究所 | 基于驱动层的文件透明加解密系统及方法 |
| CN106682521B (zh) * | 2016-11-28 | 2020-02-07 | 北京计算机技术及应用研究所 | 基于驱动层的文件透明加解密系统及方法 |
| CN107220550A (zh) * | 2017-04-19 | 2017-09-29 | 上海海加网络科技有限公司 | 基于eCryptfs的加密卡性能优化方法及系统 |
| CN107092835A (zh) * | 2017-04-21 | 2017-08-25 | 杭州华澜微电子股份有限公司 | 一种虚拟存储盘的计算机数据加密装置及方法 |
| CN107092835B (zh) * | 2017-04-21 | 2020-02-21 | 杭州华澜微电子股份有限公司 | 一种虚拟存储盘的计算机数据加密装置及方法 |
| CN107247625A (zh) * | 2017-06-14 | 2017-10-13 | 湖南麒麟信安科技有限公司 | 一种基于多卡冗余校验的数据加解密调度方法 |
| CN107247625B (zh) * | 2017-06-14 | 2019-08-09 | 湖南麒麟信安科技有限公司 | 一种基于多卡冗余校验的数据加解密调度方法 |
| CN111539042A (zh) * | 2020-07-13 | 2020-08-14 | 南京云信达科技有限公司 | 一种基于核心数据文件可信存储的安全操作方法 |
| CN116827930A (zh) * | 2023-03-27 | 2023-09-29 | 盘锦千寻信息技术有限公司 | 便携式计算机 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103294958B (zh) | 2015-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103294958B (zh) | 面向类Linux系统的内核级虚拟聚合并行加密方法 | |
| US9037870B1 (en) | Method and system for providing a rotating key encrypted file system | |
| Arockiam et al. | Efficient cloud storage confidentiality to ensure data security | |
| CN102855448B (zh) | 一种字段级数据库加密装置 | |
| US20150172046A1 (en) | Multi-level key management | |
| CN104079574A (zh) | 云环境下基于属性和同态混合加密的用户隐私保护方法 | |
| CN103795525A (zh) | 数据加密的方法 | |
| CN101997834A (zh) | 支持高性能安全协议的装置 | |
| WO2021139075A1 (zh) | 合同的加密和解密方法、装置、设备及存储介质 | |
| CN103279715A (zh) | 数据库数据加解密方法及装置 | |
| CN104834873A (zh) | 一种用于云数据信息加密解密的u盘及实现方法 | |
| CN103647636A (zh) | 安全访问数据的方法及装置 | |
| CN106326751A (zh) | 一种可信道系统及其实现方法 | |
| CN102945356A (zh) | 云环境下搜索引擎的访问控制方法及系统 | |
| CN108572861A (zh) | 一种虚拟可信根的保护方法、系统、设备及存储介质 | |
| CN204669402U (zh) | 一种基于u盘的云数据信息加密解密系统 | |
| CN104182691B (zh) | 数据保密方法及装置 | |
| CN104346575B (zh) | 一种软件定义安全体系结构 | |
| CN116886356B (zh) | 一种芯片级透明文件加密存储系统、方法及设备 | |
| CN103729324A (zh) | 一种基于usb3．0接口的云存储文件安全保护装置 | |
| CN107087002A (zh) | 一种数据的加解密方法、装置及电子设备 | |
| CN111798236A (zh) | 交易数据加、解密方法、装置及设备 | |
| CN203982391U (zh) | 一种带有网络接口的pci-e加密卡 | |
| CN111625843A (zh) | 一种适用于大数据平台的数据透明加解密系统 | |
| Kumar et al. | Data security and encryption technique for cloud storage |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150722 Termination date: 20210521 |