信息安全大赛基于虚拟机的数据防水墙.docx

信息安全大赛基于虚拟机的数据防水墙.docx

《信息安全大赛基于虚拟机的数据防水墙.docx》由会员分享，可在线阅读，更多相关《信息安全大赛基于虚拟机的数据防水墙.docx（30页珍藏版）》请在冰豆网上搜索。

信息安全大赛基于虚拟机的数据防水墙

2008年全国大学生电子设计竞赛信息安全技术专题邀请赛

作品设计报告

作品题目

基于虚拟机的数据防水墙

参赛学校

国防科学技术大学

参赛队员

熊俊

李海锋

李卫星

指导教师

张权

目录

第一章引言1

1.1背景1

1.2设计思想2

第二章系统分析3

2.1系统功能分析3

2.1.1系统框图3

2.1.2功能描述3

2.2作品特色4

第三章系统实现方案5

3.1关键问题与技术难题5

3.2实现方案5

第四章软件设计7

4.1文件保护模块7

4.1.1文件信息的驱动拦截7

4.1.2程序流程图12

4.1.3主密钥13

4.2主机设备控制模块13

4.2.1设备控制13

4.2.2接口驱动13

4.2.3设备控制驱动程序15

第五章系统测试24

5.1系统测试方案24

5.2系统测试环境及设备25

5.3测试数据结果及分析26

参考资料26

第一章引言

1.1背景

随着互联网及计算机的发展，由于早期互联网协议缺少对于安全问题的考虑，个人计算机、内部网络面临着信息被盗、信息丢失的难题。

各种木马、病毒、攻击手段活跃在互联网及个人计算机处，对信息安全造成重大威胁。

同时各种防攻击、防窃取技术也相对发展，从防火墙到入侵检测\防御系统，从防攻击、防病毒、防垃圾邮件到防蠕虫、防钓鱼、防间谍软件，各种防御手段和产品层出不穷，但即便如此，计算机安全漏洞、安全隐患，以及安全事件依然应接不暇，特别是对于内部人员造成的信息泄露尤为突出。

探索新的更有力的安全防御系统及数据加密技术迫在眉睫。

“防水墙”（WaterBox）是相对于“防火墙”（FireWall）提出的一个概念，它是用来加强信息系统内部安全的重要工具，主要为防止内部信息向外扩散。

具体说来，防水墙技术是一个以内网安全理论为基础，以数据安全为核心，利用密码学技术、PKI技术、操作系统核心技术、访问控制技术、审计跟踪技术等技术手段，对涉密信息、重要业务数据和技术专利等敏感信息的存储、传播和处理过程实施安全限制保护，最大限度地防止敏感信息外泄的内网数据保护技术。

利用防水墙有效的做到了除大脑记忆外的任何敏感信息泄露。

“防水墙”中一个重要的部分就是对于敏感文件的加解密，以确保数据的安全性。

针对目前加密方式和方法而言，文件过滤加解密技术以及minifilter框架的确定为信息加密指明了新的方向。

对以文件形式存在于计算机中的数据在驱动层拦截读写操作，之后进行透明加解密，从而以密文存在于计算机中，有效的保证了数据的安全性。

透明加解密有着众多的优点：

1、加解密过程是透明的,对用户而言感觉不到加解密工作,防止了用户操作失误带来的无意泄露,同时保证了本地文件的安全性；

2、文件系统过滤驱动加密通常对特定进程或文件类型的文件操作才进行透明加解密；对那些不期望的文件操作，例如用户主动把文件拷贝到U盘、作为邮件附件发送或者远程用户通过文件共享拷走文件、黑客攻破系统后拷贝文件等，其只能得到密文,保证了明文信息安全性。

文件过滤加解密为数据上了一把安全锁，然而加密与解密，就像是“矛”与“盾”，两者就是一个共体。

加密过程给予数据安全保护，然而解密过程中明文信息的存放成为了新的问题。

目前的透明加解密产品，在用户获得系统权限，打开文档进行解密后，明文信息将存在于本地机器（如内存）上，这对于攻击者或病毒是如获至宝,加密系统又失去其保护功能。

文件系统过滤驱动加密产品通常依赖于操作系统的身份鉴别机制，对于通过操作系统认证的用户均进行透明加解密，所以操作系统在身份鉴别上的漏洞也就成了文件系统过滤驱动加密的漏洞（众所周知Windows的身份鉴别的漏洞很大）。

为达到数据在本地机器上的彻底保护，有人又提出对各种可能输出明文的途径进行“封堵”。

目前市场上各种各样的“封堵”途径产品层出不穷，然而大多数只是封堵了或多或少的一部分途径，很难做到万无一失。

1.2设计思想

目前大多数文件系统加密软件产品，如上面讲到的存在着以下的问题：

通常都依赖与操作系统安全，另外就是对于加密密钥的管理，有些产品将密钥交给管理员管理，一旦丢失密钥文件，磁盘上的密文信息将会全部暴露。

即使网络再坚固，攻击者、黑客还可以利用病毒、软件在文档打开过程中获取内存（或其他位置）中文档明文信息,或是通过各种方式获得系统权限，进入系统后所有信息将全部暴露，因为他们熟悉网络上安全措施的结构。

本系统搭建一个虚拟安全平台，对设备而言在主机上建立设备控制模块，“封堵”所有可能输出明文的通道。

对数据而言通过文件保护模块完成对文件的透明加解密操作。

文件保护模块和主机设备控制模块共同工作使得数据得到了彻底的保证，并且对选择的文件类型进行强制加密。

强制加密可以有效防御因用户忘记加密或其他原因而造成的数据丢失。

要实现对于设备的控制，目前有两种方法：

1、应用层的SetupAPI函数；2、内核层的过滤程序。

SetupAPI能够对主机上的各个设备类进行管理，例如开启、禁用、重启等，但主要有以下两个缺陷：

1、SetupAPI对设备管理时处理速度较慢，系统如果采用这种方式来控制设备，可能导致涉密文件关闭的速度明显变慢。

2、采用SetupAPI方式禁用的设备，也可以被其他程序调用SetupAPI函数重新开启。

而内核层的过滤程序不存在这些问题，而且这种方式的速度比SetupAPI快的多。

我们考虑通过内核层来实现对设备的控制与管理，从而使得主机构筑成一个安全平台。

第二章系统分析

2.1系统功能分析

2.1.1系统框图

系统主要由文件保护模块、主机设备控制模块构成。

文件保护模块主要完成文件数据的驱动透明加解密，采用minifilter框架。

主机设备控制模块主要完成对于主机上的设备控制，“封堵”主机上可能与外界通信的端口。

图1系统框图

2.1.2功能描述

为了使得文件加解密得到彻底的保证，数据明文信息不致被盗走，通过文件保护模块以及设备控制模块共同搭建一个虚拟安全平台，在该平台上完成数据的加解密过程，安全平台关闭主机上所有可能与外部通信的设备，这样即使明文信息出现在本地系统中，外界也将不能盗取走。

（1）主机设备控制模块，软件安装完成后，将关闭所有主机上可能与外部通信的设备或端口。

这些设备或端口包括红外、蓝牙、1394、串口、并口、Pcmcia等，部分USB类型端口可以通过，但是通过USB拷出来的将是密文。

（2）文件保护模块，在驱动层拦截文件的读写操作，对文件数据进行透明加解密。

用户在安装过程中可以自己选择需要加密解密的文件类型。

对于选定的加密文件类型的文件将进行强制加密。

2.2作品特色

通过研究现有的文件系统过滤驱动加密产品，发现在本地机器上直接进行透明加解密，明文信息得不到最后的保证。

该系统完成透明加解密，同时“封堵”主机上可能与外界通信的端口，从而使得明文信息不致被窃取。

特色一：

提出了一种更好的解决加解密时明文信息的存放问题的方案----基于虚拟机。

为了使得明文信息在解密过程中不被窃取，构建了一个虚拟安全平台。

特色二：

通过内核层完成设备的控制，实现了一种比直接调用应用层SetupAPI更快更有效的设备控制方案。

通过对设备的控制，“封堵”了主机上所有可能与外界通信的设备。

特色三：

在虚拟安全平台上进行文件的透明加解密，基于Minifilter框架在驱动层拦截文件的读写操作，对选定的文件类型数据进行加解密。

特色四：

文件保护模块中，通过检查后缀名来看是否为我们关心的文件类型，如是则给该文件创建一个文件头（File-Head-Shell）来跟踪文件状态，每次打开或关闭时，检查文件头信息从而完成加解密操作。

特色五：

要求对选定的加密文件类型进行强制加密，对用户来说感觉不到加解密过程，数据将于密文形式存放于主机上，并且通过U盘拷出来的将是密文。

第三章系统实现方案

3.1关键问题与技术难题

针对目前加解密技术的发展，对整个系统功能及需求的分析，系统存在着以下关键问题和技术难点：

（1）系统要完成对指定文件类型进行强制加解密，需要不断跟踪文件操作的状态，添加文件的加密标识。

（2）对于Windows系统而言，对磁盘的读写操作都是以扇区对齐的，即读写的文件偏移都为一个扇区的整数倍（一般为512字节的整数倍），输入的读写字节数也应该是扇区的整数倍。

采用何种加密方案成了关键，对于随机访问文件而言，分组密码具有很大的优势，分组密码可以直接以扇区为单位进行CBC加密，加密的效率和安全性也较高。

但是Windows下，一个文件的大小并不是都是扇区的整数倍，如果都以扇区为单位对文件进行分组加密，对于文件尾部的非扇区整数倍文件内容显然不合适。

（3）在内核层如何判断设备类型，拦截系统访问请求，从而实现对主机设备的控制。

（4）由于类过滤驱动程序需要inf文件来安装，并且安装完需要重启计算机系统，我们不希望安装主机设备控制驱动程序后重启系统，如何实现动态加载来安装主机设备控制驱动程序。

（5）动态驱动拦截：

由于Windows有一个机制，只有当一种类型的设备接入系统时，系统才自动查找并加载相应的驱动程序。

如果设备没有接入系统，系统并不会自动加载对应的驱动程序。

这就给我们带来一个问题：

设备控制驱动运行时，需要监控的驱动程序（如\driver\irda）并没有加载。

当用户接入红外设备时，操作系统自动加载\driver\irda。

如果我们采用动态绑定的方法，控制驱动程序并不能得到\driver\irda驱动加载的通知。

3.2实现方案

文件保护模块主要负责对指定类型的文件自动加解密。

工作原理是在文件系统过滤层上拦截系统对文件的访问，当系统访问磁盘上被保护类型的文件时，文件保护模块能自动对读取的数据进行解密处理；当系统写入磁盘上被保护类型的文件时，文件保护模块能自动对写入的数据进行加密处理。

整个过程无需用户的干预，不影响用户的正常使用。

而磁盘上的文件都是以密文形式存在。

图2文件系统过滤

我们使用基于minifilter框架的swapbuffer、ctx等代码示例，为每个文件信息添加一个文件头（File-Head-Shell）来跟踪文件状态。

对扇区长度文件采用AES加密算法，对文件尾不足扇区长度的采用RC4算法。

为了进一步保护系统中解密的明文数据，文件保护模块工作时，还需要和主机设备控制模块协同工作，主机设备控制模块将封堵主机上所有可能与外界通信的设备，同时主机设备控制模块对部分USB设备不封堵。

主机设备控制模块中我们通过对类过滤驱动的分析，实现了一个基于IRP过滤方法的设备控制驱动程序。

相比类过滤驱动而言，基于IRP过滤方法的设备控制驱动程序能够动态加载，并且很好的适用我们的这个系统。

第四章软件设计

4.1文件保护模块

4.1.1文件信息的驱动拦截

要实现对指定类型文件进行加解密操作，必须能够拦截到系统对文件的读写。

文件保护模块采用基于minifilter框架的文件系统过滤驱动程序。

4.1.1.1文件的加密与解密

编写的FilePro.sys驱动程序将为各个需要拦截的IRP注册Pre和Post回调函数，FilePro.sys将在这些回调函数中根据需要对文件进行加密和解密。

FilePro.sys主要拦截的IRP与对应的函数有：

{IRP_MJ_READ,//读

0,//FLTFL_OPERATION_REGISTRATION_SKIP_CACHED_IO,

SwapPreReadBuffers,

SwapPostReadBuffers},

{IRP_MJ_WRITE,//写

0,//FLTFL_OPERATION_REGISTRATION_SKIP_CACHED_IO,

SwapPreWriteBuffers,

SwapPostWriteBuffers},

{IRP_MJ_CREATE,//创建

FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO,

CtxPreCreate,

CtxPostCreate},

{IRP_MJ_CLEANUP,

FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO,

CtxPreCleanup,

NULL},

{IRP_MJ_SET_INFORMATION,

FLTFL_OPERATION_REGISTRATION_SKIP_CACHED_IO,

CtxPreSetInfo,

NULL},

{IRP_MJ_QUERY_INFORMATION,

FLTFL_OPERATION_REGISTRATION_SKIP_CACHED_IO,

NULL,

CtxPostQueryInfo},

其中SwapPreReadBuffers和SwapPostReadBuffers主要负责文件的解密操作；SwapPreWriteBuffers和SwapPostWriteBuffers主要负责文件的加密操作；CtxPreCreate和CtxPostCreate主要负责文件加密状态的识别和读取；CtxPreSetInfo主要负责修改文件名的识别；CtxPreCleanup主要负责文件关闭时的操作；CtxPostQueryInfo主要负责查询文件信息时的操作。

对文件的加密和解密主要是通过以上的函数配合完成的，其中加密应在写操作前（SwapPreWriteBuffers），解密应在读操作后（SwapPostReadBuffers）。

4.1.1.2文件的加密状态

当系统打开一个文件时，FilePro.sys的CtxPreCreate和CtxPostCreate将拦截到此操作。

每次读写（read、write）操作前都将发IRP_MJ_CREATE。

对于一个需要打开的文件，CtxPostCreate将根据下面两个条件判断该文件是否需要加密：

1）文件的后缀名是否在需要加密的后缀名列表中（后缀名作为需要加密的文件类型---用户在安装过程中输入）；

2）该文件是否已经被加密。

为了便于对文件的状态进行跟踪，FilePro.sys为每一个打开的文件流维护一个上下文，该结构体由Windows的FltMgr维护,我们将该上下文定义为一个CTX_STREAM_CONTEXT类型的结构体，结构体中包括加解密信息及加解密状态信息。

第一种情况比较容易检查，FilePro.sys只需要使用FLT_FILE_NAME_NORMALIZED和FLT_FILE_NAME_QUERY_DEFAULT，调用FltGetFileNameInformation得到文件名信息,然后检查文件后缀名是否在需要加密的文件列表中即可。

如该文件属于需要加密的文件列表，FilePro.sys将CTX_STREAM_CONTEXT的“需要加密标识IsNeedEncrypt”设置为TRUE。

而对于第二种情况，我们为每个文件创建了一个文件头（file-head-shell），FilePro.sys只需要在CtxPostCreate中首先打开该文件，读取文件的前4096字节，并对读取到的信息进行判断是否为已加密的文件。

为了能够具体判断一个文件是否被加密，FilePro.sys定义了一个FILE_HEAD_SHELL文件头结构，该结构用于判断文件是否已经加密。

FILE_HEAD_SHELL的结构如下：

//**********************************************************

//处于文件头的文件壳信息

//文件头长度必须为volCtx->SectorSize的整数倍

//**********************************************************

typedefstruct_FILE_HEAD_SHELL

{

charsHeadSignature[16];//16字节，文件头信息

WORDwMinorVersion;//2字节，文件头版本信息

WORDwMajorVersion;//2字节，文件头版本信息

BOOLEANbEncrypted;//1字节，文件是否加密

BYTEEFEK[32];//32字节，EFEK

BYTEPayload[455+4096-512];//中间空闲的部分

DWORDCheckSum;//4字节，文件头的校验和

}FILE_HEAD_SHELL,*PFILE_HEAD_SHELL;

FILE_HEAD_SHELL结构体为4096字节（4KB）。

其中包含了文件头信息sHeadSignature、文件头的版本信息wMinorVersion与wMajorVersion、文件加密标记bEncrypt、加密的文件加密信息EFEK、空闲的部分Payload，以及文件头的校验和部分CheckSum。

由于文件头信息为4KB，TXT空文件加密后将为4KB。

图3文件头结构

FilePro.sys检查一个文件是否为加密文件主要分为以下几个步骤：

1）读取文件的前4096字节，并且保存到FILE_HEAD_SHELL结构体中。

判断sHeadSignature文件头信息是否正确，如是则转到下一步，否则为非加密文件；

2）读取文件头校验和CheckSum并且与计算FILE_HEAD_SHELL得到的校验和比较，如果不等表示为非加密文件；

3）判断bEncrypted是否为TRUE，如果是的话，表示是一个加密文件，否则表示是一个加了文件头的文件，但是并未被加密。

上面的判断都通过,FilePro.sys将CTX_STREAM_CONTEXT的“已经加密IsEncrypt”设置为TRUE。

对于一个CTX_STREAM_CONTEXT的“需要加密标识IsNeedEncrypt”为TRUE而“已经加密IsEncrypt”为FALSE的文件而言，表明该文件是一个新的需要加密的文件，FilePro.sys将调用GenAndCalcEFEK（）为其生成文件加密密钥FEK，并且保存到对应的CTX_STREAM_CONTEXT中。

然后FilePro.sys将CTX_STREAM_CONTEXT的bKeyGenerated标记为TRUE，表示已经为该文件产生了密钥。

对于生成了IsEncrypt为TRUE和bKeyGenerated为TRUE的文件而言，接下来FilePro.sys将根据其FEK生成用于AES加解密的轮密钥。

对于CTX_STREAM_CONTEXT中“已经加密IsEncrypt”为TRUE的文件而言，将在读写文件时的SwapPreReadBuffers和SwapPostReadBuffers或者SwapPreWriteBuffers和SwapPostWriteBuffers中自动根据CTX_STRAM_CONTEXT中的密钥信息进行加解密。

对于文件改名而言，这里就需要对SwapPreSetInfo和SwapPostSetInfo中的信息进行处理了。

SwapPreSetInfo和SwapPostSetInfo根据文件的类型以及文件状态对文件的CTX_STREAM_CONTEXT中的相关标记进行标识，在CtxPreCleanup进行处理，如果是需要加密的状态，则在文件关闭时进行加密。

4.1.1.3加解密算法与密钥

我们采用的加密方案为AES与RC4混合加解密算法。

流加密算法中对输入的明文长度无限制，一般而言，对于顺序读取的文件采用流加密比较好。

但是对于随机访问文件而言，流加密算法必须首先计算出指定文件偏移处的密钥状态，才能进行正确解密，这相当于文件从头解密一次，加解密的效率较低。

对于随机访问文件而言，分组密码具有很大的优势，分组密码可以直接以扇区为单位进行CBC加密，加密的效率和安全性也较高。

但是Windows下，一个文件的大小并不是都是扇区的整数倍，如果都以扇区为单位对文件进行分组加密，对于文件尾部的非扇区整数倍文件内容显然不合适。

因此作品中文件保护模块FilePro.sys采用AES+RC4的加密方案，方案如下：

对于非文件尾的文件内容，FilePro.sys采用AES算法，由于系统对这些内容的访问都以扇区为单位，FilePro.sys可以以扇区为一个单元，对其进行加解密，保证顺序访问和随机访问都能快速加解密

对于处于文件尾部的非扇区大小的内容而言，FilePro.sys采用RC4算法进行加解密。

图4加密算法

对于每一个需要加密的文件，FilePro.sys生成随机的文件加密密钥FEK，并且把FEK的加密形式EFEK保存到加密文件的文件头FILE_HEAD_SHELL中，而EFEK是由主加密密钥MEK加密的。

为了防止恶意用户根据驱动程序得到MEK，从而破解FEK，驱动程序将MEK加密为EMEK并且保存到文件自身。

EMEK是由安装程序在安装客户端软件的时候写入的。

当FilePro.sys启动时，其将采用系统预设的密钥对EMEK进行解密，，从而得到MEK，进而可以由FEK得到EFEK。

由文件FEK生成EFEK以及由EFEK得到FEK的流程如下：

图5密钥算法

4.1.2程序流程图

如下图，驱动层拦截到IRP,如果是IRP_MJ_CREAT,则判断文件是否在黑名单,然后判断是否有加密标志,如果没有,则添加标志；如果拦截到IRP_MJ_WRITE,则读取标志,判断是否需要加密,是则执行加密操作；如果拦截到IRP_MJ_READ,判断是否有加密标志,是则执行解密运算。

图6程序流程图

4.1.3主密钥

密钥长度KeyLength必须等于32，如果不等加密则调用失败。

在驱动程序安装过程中，对用户输入的任意位PIN码，我们通过对PIN码进行Hash（MD5）得到32位，再通过硬编码写入，作为主密钥MEK的加密形式EMEK。

在安装完成后由系统预设密钥对EMEK进行解密得到主密钥MEK。

4.2主机设备控制模块

4.2.1设备控制

要实现对设备的控制，目前有两种方案：

1、应用层的SetupAPI函数；2、内核层的设备过滤程序。

SetupAPI能够对主机上的各个设备类进行管理，例如开启、禁用、重启等，但本系统不适合使用SetupAPI进行处理。

我们通过实践发现内核层的设备过滤程序速度比SetupAPI快的多，将更加适合我们系统要求。

4.2.2接口驱动

主机控制模块驱动程序由接口驱动和控制驱动两部分组成。

接口驱动为应用程序以及其他驱动程序暴露统一的控制接口，从而可以通过应用层或其他驱动模块控制设备。

系统的应用层可能有控制设备开启/禁用的需求。

应用层调用设备控制模块，也能对设备进行开启/禁用控制。

考虑到windows内核和驱动的差别，主机设备控制模块的接口采用DLL和SYS方式实现。

接口DLL由应用层调用；接口驱动由其他模块的驱动程序和接口DLL调用，它将设备控制命令分发给各个设备控制驱动。

控制接口如下图所示：

图7设备控制模块内部结构

程序将各种类型需要控制的设备，以及设备的访问方式统一编码。

其他模块使用这些统一的编码方式调用设备控制接口。

下表列出了部分系统中需要控制的设备，及其编码：

设备名称

编码

备注

unknownDevice

0

未知设备

FloppyDevice

1

软驱设备

CDRomDevice

2

光驱设备

B1394Disk

3

1394总线的磁盘设备

USBDisk

4

USB总线的磁盘设备

NetworkDevice