Linux文件加密系统的设计.docVIP

Linux文件加密系统的设计 　　摘 要：对文件内容加密，可有效解决数据泄露问题。目前传统的第三方软件多采用非透明式加密，对用户而言，操作不便；新型的堆叠式文件加密方案可以有效解决透明性问题，但此类设计方案实施较为复杂，并存在内核版本依赖性。文中采用Hook机制，通过监控用户对指定文件目录进行操作，捕获用户对该目录具体文件的访问；自动调用应用层的加解密模块，完成对具体文件的加解密，解决透明性问题。由于该系统的加解密功能在应用层实现，与具体文件系统无关，因此又可以有效简化系统设计，灾难恢复性强，稳定性高。 　　关键词：数据加密；进程间约束；消息Hook机制；锁机制 　　中图分类号：TP309.7；TP316.81 文献标识码：A 文章编号：2095-1302（2018）02-00-03 　　0 引 言 　　最近几年，基于Linux内核开发的操作系统逐渐从服务端走向用户终端。尤其某些单位，从服务器到个人终端都以Linux作为系统支撑。因此，对于存放在Linux上的敏感数据进行加密保护，已成为一个急需解决的问题。 　　多数第三方加密软件均采用非透明式文件存储方式，需要用户在打开指定文件时调用解密模块；同样，当用户关闭文件时，需要调用加密模块，导致体验效果不好。 　　新型堆叠式文件加密系统[1]虽然可以解决用户透明性问题，但需要重新设计一个新的文件管理层，用以对文件加密，因此需要对加密文件系统进行重新?O计。此类方案对于设计者而言，需要深入掌握Linux各方面的知识，如文件系统管理、内存管理、驱动设计等。虽然设计方案在理论上可行，但在系统的具体实现过程中却十分复杂，而且开发周期长，成本昂贵，短期内看不出测试结果。 　　1 整体方案设计 　　该系统使用文件锁[2]和消息Hook机制[3]进行设计，既可以有效解决用户透明性问题，又可以降低整体设计难度。如图1所示，系统中目录A作为被监控目录，用于存放需要加密的文件，目录B可以视为缓存目录或者备份目录。当明文文件被存放到目录A中时，加密子进程在目录B中创建一个新的临时文件，用以保存加密之后的密文。当明文文件加密完成后，再利用目录B中的临时密文文件替换目录A中的文件。同样，当需要对目录A中的密文文件解密时，读取目录B中的临时密文文件，然后调用解密子进程对其解密，最后将解密之后的数据覆盖目录A的密文文件。 　　整体方案只需调用Linux提供的接口就可以完成设计，且绝大部分数据处理过程都位于应用层。即便系统遇到不可控因素而产生灾难性后果，也可以在现有文件系统中找到保存完整的加密数据，对其进行解密操作，有效解决文件恢复问题。可以看出，基于应用层的方案设计无须对Linux内核进行深层次的修改，降低了开发难度。 　　2 关键技术点 　　目录A和目录B间的数据交换需要多个子进程先后进行协调工作，包括维护子进程、加密子进程、解密子进程。如果用户操作目录A以及目录A中的文件，那么维护子进程就能够捕捉到用户的操作，并且通知其他子进程进行后续操作。 　　系统方案的设计需要解决两个技术点，即监控目录和进程间控制。 　　2.1 监控目录 　　在Linux内核最新版本中添加了监控操作文件的消息Hook模块，即inotify，利用inotify作为实现监控目录的核心。 　　监控模块经过初始化后，返回相应的监控实例id，然后将需要监控的对象路径添加到监控实例中，这些对象可以是文件，也可以是文件目录。若不监控该对象，则可以从监控实例中移除。 　　监控用户操作文件并产生消息队列的过程如图2所示。当用户对监控目录A中的文件进行操作时，消息Hook模块便对虚拟文件系统（VFS）进行监控，将用户的操作类型通过消息方式发送到应用层的消息队列中，使得后台维护子进程（通过轮询方式）能够实时捕捉。 　　维护子进程通过读取消息队列[4]判断产生的事件并调用对应的加密或解密子进程。通常用户在访问一个文件时，可能会产生连续多个消息事件。例如，用户打开一个加密文件，监控模块首先产生IN_OPEN消息事件，然后产生IN_WRITE消息事件，最后产生IN_CLOSE消息事件。因此，在监控一个对象时，需要维护子进程依次捕获该对象所产生的一系列消息事件，判断当前监控对象需要进行的操作。 　　2.2 进程间控制 　　用户使用编辑器等软件打开目录A中的密文文件，维护子进程自动调用加解密模块完成文件解密过程，将解密之后的明文数据呈现给用户。在解密过程中，采用文件锁方式使用户进程产生等待，便于解密模块解密。 　　但多数编辑软件在打开文件时不检查文件锁，而是直接读取文件内容，因此用户读取的是密文数据。为了使这些软件产生等待，在文件打开时，需要将这些软件产生的进程强制性地检查文件是否被锁定。由于这些进程打开的文件最终都需要调