基于组密钥服务器的加密文件系统的设计和实现模板.doc

基于组密钥服务器加密文件系统设计和实现*Supported by the National Natural Science Foundation of China under Grant No. 60473101 (国家自然科学基金项目); the National Grand Fundamental Research 973 Program of China under Grant No. CB318205 (国家“九七三”关键基础研究发展计划基金项目)；the Program for New Century Excellent Talents in University under Grant No. NCET-05-0067（新世纪优异人才支持计划） 肖达+, 舒继武, 薛巍， 刘志才， 郑纬民（清华大学 计算机科学和技术系,北京 100084）（清华信息科学和技术国家试验室（筹）北京 100084）+联络人：电话：[phone]，E-mail: Design and Implementation of a Group Key Server-Based Cryptographic File SystemXiao Da+, Shu Ji-Wu, Xue Wei, Liu Zhi-Cai, Zheng Wei-Min（Department of Computer Science and Technology, Tsinghua University, Beijing 100084, China）（Tsinghua National Laboratory for Information Science and Technology（TNList）, Beijing 100084) +Corresponding author: Phn: [phone], E-mail: , Abstract:Network storage techniques facilitate data sharing but also introduce new vulnerabilities. Cryptographic file systems provide the confidentiality and integrity of file data stored on servers that are not under users direct control by cryptographic methods. The key management schemes for current shared cryptographic file systems cannot satisfy the security, flexibility and efficiency requirements simultaneously. This paper proposes a cryptographic file system called CKS-CFS. A trusted Group Key Server (GKS) is introduced to manage file encryption keys in a centralized manner and to enable the employment of flexible access control policies. The computation and storage requirement for GKS is reduced through the use of access control blocks and lockboxes so that the function of GKS can be implemented by hardware to provide strong security. The overhead of revocation is reduced by block granularity encryption and key versioning technique. We have implemented a prototype of GKS-CFS based on Lustre and evaluated its performance. Compared with other systems, the cryptographic cost in common file operations in GKS-CFS is reduced by an order of magnitude by avoiding the usage of public-key cryptography; Bonnie+ benchmark test shows that the performance of sequential read/write and random file operations are reduced on average by 42.0% and 8.4% respectively.Key words:cryptographic file system, confidentiality, integrity, key management, tamper-resistant hardware摘 要:网络存放技术在方便数据共享同时带来了新安全隐患，加密文件系统经过密码学方法确保留放在不受用户直接控制服务器上文件数据机密性和完整性。现有针对共享加密文件系统密钥管理方法不能同时满足安全性、灵活性和高效性需求。本文提出了加密文件系统GKS-CFS。引入可信组密钥服务器（GKS）集中管理文件加密密钥，GKS上能够实施灵活访问控制策略。经过使用访问控制块和锁盒子，降低了对GKS计算和存放需求，使之能够用硬件实现来增强安全性；经过文件数据分块加密和密钥版本技术，降低了权限撤销开销。我们在Lustre上实现了GKS-CFS原型系统并进行了测试。测试结果表明因为避免使用了公钥密码算法，和其它系统相比，GKS-CFS一般文件操作中密码学操作开销降低了一个数量级，次序读写和随机文件操作性能分别平均降低了42.0%和8.4%。关键词:加密文件系统；机密性；完整性；密钥管理；防损硬件1 引言网络存放技术在方便数据共享和降低管理成本同时带来了新安全隐患。在网络存放环境中，数据可能存放在不受用户直接控制服务器上，传统访问控制方法已不足以确保用户数据安全性。加密文件系统（Cryptographic File System）1, 2, 3, 4, 5, 6, 7经过用户端密码学方法确保文件在网络中传输和在服务器上存放过程中机密性和完整性， 提供端到端安全性。加密文件系统能够分为两类：非共享和共享。非共享加密文件系统（如最早加密文件系统CFS1）不许可文件被多用户共享，所以不需要考虑加密密钥管理问题。但这种系统显然不能满足企业环境中多用户协同工作和数据共享需要。在共享加密文件系统中，许可文件被多个用户共享，所以一个关键问题是怎样管理加密密钥，使授权用户能够轻易得到密钥从而访问文件，同时未授权用户极难得到密钥。现有共享加密文件系统中密钥管理方法关键分为两类：一类是将含有相同访问权限文件分组，组内文件共享一个密钥，并由全部者或可信第三方分发给授权用户2,6。这种方法降低了密钥数目，但缺点是当一个用户从组中退出从而不再拥有组内文件访问权限时，需要将组内全部文件用新密钥重新加密，计算开销很大。另一类方法是将文件密钥用每个含有访问权限用户公钥加密3,4，这种方法能够实现单个文件粒度共享，但只能实现以用户列表方法表示访问控制策略，不够灵活。我们认为，一个好密钥管理方案应同时满足三方面需求：一、安全性，密钥存放和分发应由可信赖机制来确保；二、灵活性，能够易于实施多个访问控制策略；三、高效性，由加密带来文件访问和用户权限撤销中额外开销尽可能小。现有系统全部不能同时满足三个需求。本文设计并实现了一个新加密文件系统GKS-CFS（Group Key Server-Cryptographic File System），来实现安全、灵活和高效文件共享。该系统针对政府和企业等含有集中控制机构环境，引入一个可信组密钥服务器（Group Key Server，GKS），集中负责文件密钥生成和分发。经过使用锁盒子和访问控制块降低GKS计算和存放需求，从而有可能以硬件方法确保GKS安全性，进而确保整个系统安全性，同时便于在GKS上实施灵活访问控制。提出一个高效用户权限撤销机制，采取了以文件块为粒度密钥管理策略，并结合密钥版本技术，有效降低了权限撤销开销。我们在Lustre8上实现了GKS-CFS系统原型并进行了测试。因为避免使用了公钥密码算法，和其它系统相比，GKS-CFS一般文件操作中密码学开销降低了一个数量级。Bonnie+测试结果显示，次序读写和随机文件操作性能分别降低了42.0%和8.4%2 安全模型本节介绍GKS-CFS所采取假设和安全模型。系统中有五种角色：全部者（创建文件和设置访问权限）、读者（对文件有读权限）、写者（对文件有读写权限）、文件服务器（存放文件数据）和组密钥服务器（存放密钥）。全部者、读者和写者经过文件系统用户端操作文件。在GKS-CFS中，用户端是不可信，恶意用户和攻击者可能试图经过用户端访问她们无权访问文件，用户存放在用户端上私密信息（如私钥）也有可能被攻击者窃取。文件服务器也是不可信。它能够将数据泄露给非法用户、篡改数据或向用户提供不真实数据。系统中唯一可信是组密钥服务器，它负责管理用于加密文件密钥并向正当用户提供密钥。考虑到在一个实际企业应用环境中，海量数据存放需要有多个文件服务器，这些服务器可能隶属于不一样管理域，确保全部这些服务器安全是困难，相比之下，确保一个组密钥服务器安全是相对轻易，所以我们认为我们安全假设是合理。需要指出是，在GKS-CFS中，全部用户需要对组密钥服务器给予绝对信任，所以不适于无集中控制机构松散耦合组织，如对等网络环境，而适合于含有集中控制机构组织，如政府、企业等。GKS-CFS经过密码学技术确保文件数据机密性和完整性。文件内容（可了解）只会被授权用户取得。当未授权用户或文件服务器试图篡改文件数据时，授权用户能够检测到该行为。CKS-CFS不提供数据可用性确保，不能预防恶意用户或服务器删除数据。如需提供可用性，需要将密码学技术和冗余技术结合，这不在本文讨论范围之内。3 系统设计3.1 基础思想和设计目标在GKS-CFS中，GKS作为全局唯一可信节点，统一负责维护和分发文件密钥。用户访问每个文件前，全部要向GKS发出请求，获取该文件加密密钥和署名密钥（写文件）。GKS首先验证用户身份，并依据预先设置访问控制策略判定用户是否有对文件访问权限，假如有，则将文件密钥返回给用户，如没有，则拒绝该请求。因为全部密钥由GKS统一管理，只要确保GKS安全性，就能确保整个系统安全性；而且GKS上能够依据因为需求实施灵活访问控制策略。GKS-CFS设计目标是：l 对GKS计算和存放需求最小。GKS上只需存放少许本身密钥，而不需要存放每个文件加密密钥和署名密钥，同时用户访问一个文件过程中，GKS只需做少许针对密钥加解密运算，而不需要对大量文件数据加解密，使GKS易于用安全硬件实现，从而确保安全性。l 额外开销尽可能小。额外开销包含密码学操作开销和权限撤销时重新加密数据开销。3.2 锁盒子和访问控制块GKS-CFS中采取对象及它们之间关系图1所表示。本文中所用缩略语及其含义在表1中列出。每个文件被分成若干个数据块（block），每个数据块用一个随机生成对称密钥（数据块密钥，FBK）加密。GKS-CFS采取了文件2引入锁盒子（lockbox）思想，一个文件全部FBK存放在该文件对应锁盒子中，并用该文件锁盒子密钥（LBK）加密，LBK也是对称密钥, 只有对文件有读权限用户才能获取LBK。每个FBK还对应一个版本号，用于权限撤销时密钥更新（见3.5节）。在锁盒子中和FBK一同存放还有每个数据块安全哈希值（cryptographic hash），用以校验数据块完整性。将一个文件全部数据块哈希值组织成一个Merkle哈希树9，哈希树根（root hash）用文件署名密钥（FSK）加密后保留在访问控制块中。只有对文件有写权限用户才能获取FSK。注意本文FSK和文件3,6中文件署名密钥不一样，前者是一个对称密钥，后者是一个公私钥对中私钥。表1：缩略语及其含义缩略语含义FBKFile Block KeyLBKLockbox KeyFSKFile Sign KeyGEKGKS Encryption KeyGSKGKS Sign KeyACBAccess Control Block 图1：GKS-CFS对象及对象间关系。实线箭头代表对称加密。每个文件对应一个访问控制块（ACB），用以控制授权用户对LBK和FSK获取。ACB中包含文件访问控制属性（access control attributes）、LBK、FSK、文件版本号、完整性标识（auth tag）和加密根哈希，其中LBK和FSK用GKS维护一个加密密钥（GEK）加密，只有GKS才能解密。访问控制属性是由文件全部者创建并由GKS检验文件访问规则，比如一个访问控制列表（ACL），要求了哪些用户和组能够访问文件，和她们权限。文件版本号用于权限撤销时密钥更新（见3.5节）。完整性标识是其它域一个带密钥消息认证码（keyed HMAC），用以预防对访问控制块篡改。生成认证码GKS认证密钥（GSK）由GKS维护，所以只有GKS能依据文件全部者需要对ACB内容进行修改。注意加密根哈希不参与完整性标识计算，因为该值在写文件时会发生改变，能够避免每次写文件全部由GKS重新生成访问控制块。用户访问文件时，在密钥请求中将ACB和自己身份标识发送给GKS，GKS首先用GSK验证ACB完整性，然后依据其中访问控制属性和用户身份标识确定用户对文件访问权限，假如用户有读（写）权限，就将LBK（和FSK）用GEK解密后返回给用户。GKS-CFS采取锁盒子和访问控制块好处是：1）GKS不需要维护每个文件加密密钥，只需要维护两个密钥：GEK和GSK，而FBK作为元数据一部分和文件数据一起存放在文件服务器上，降低了GKS存放需求。2）访问文件时，GKS只需要做数据量很小对称密钥加解密（对LBK、FSK和根哈希），不需要公钥加解密，降低了GKS计算需求。3）用户不需要在用户端主机上维护自己私密信息（如用户私钥），降低了用户端主机被入侵带来危害。需要指出是，一个实际系统可能被划分成多个管理域，每个管理域应有自己GKS。所以在ACB中还应包含域ID，用户访问文件时依据域ID找到对应GKS。为简明起见，这部分在上文描述中已省略。另外，考虑到一旦GKS维护GEK丢失，则域内全部文件全部将不可访问，所以必需预防对GKS可用性攻击，这能够经过将GEK以秘密分存方法存放到多个恢复代理上来实现3.3 文件访问协议需用户访问文件时用户端和GKS通信协议图2所表示。Create file Client GKS : ACB_REQ | ACL | UserID Client GKS : ACBRead file Client GKS : READ_KEY_REQ | ACB | UserID Client GKS : LBK | root hashWrite file Client GKS : WRITE_KEY_REQ | ACB | UserID Client GKS : LBK | root hash | FSK Change file access control attributes Client GKS : CHANGE_ACL_REQ | ACB | ACL | UserID Client GKS : ACB | LBK图2：文件访问协议创建文件：文件全部者向GKS发送获取ACB请求，其中包含用户标识和文件访问控制属性（ACL）。GKS依据ACL生成ACB返回给全部者。全部者将ACB作为文件元数据一部分存放到文件服务器上。读文件：读者首先从文件服务器获取ACB，然后向GKS发送获取读密钥请求，其中包含用户标识和ACB。GKS依据ACB中访问控制属性检验用户权限，然后将LBK和根哈希解密后返回给读者。读者用LBK解密锁盒子，并用锁盒子中数据块哈希重新计算根哈希和收到根哈希比较，然后用锁盒子中FBK解密从文件服务器读取文件数据，并用数据块哈希校验完整性。写文件：过程和读文件类似，区分在于GKS将文件署名密钥（FSK）和根哈希一起返回给写者，写者关闭文件时，重新计算根哈希，并用FSK加密，替换ACB中原有域。更改文件访问权限：全部者首先从文件服务器获取ACB，然后向GKS发送更改访问控制属性请求，其中包含用户标识、ACB和新访问控制属性。GKS首先检验用户是否是文件全部者，然后依据新访问控制属性生成新ACB返回给全部者。全部者用新ACB覆盖文件服务器上旧ACB，并用新LBK重新加密锁盒子。3.4 身份认证为了确保GKS只响应授权用户解密请求，GKS必需能够对发出请求用户身份进行认证。用户认证可采取多个方法，如基于对称密钥Kerberos协议10或公钥基础设施（PKI）等。需要指出是，GKS-CFS关键设计目标是加密文件系统中高效密钥管理，它本身并不提供认证机制，而需要和一个现有独立认证机制协同工作确保安全性。比如，如采取Kerberos认证方法，则需要一个票据分发服务器向用户分发代表身份票据，同时GKS和票据分发服务器共享一个密钥用于验证用户提供身份票据真实性。这种密钥管理机制和认证机制分离策略提升了系统布署时灵活性。本文关键关注基于ACB访问控制和密钥管理方法，具体认证协议将不作深入讨论。在上节描述文件访问协议中，用户向GKS发出请求之前，先要向GKS认证身份并协商会话密钥，以后用户和GKS间通信内容全部用会话密钥加密确保并用随机数等方法确保完整性。为清楚起见，图2中只有用户和GKS间发送消息内容，省略了消息加密和完整性确保部分。3.5 权限撤销用户权限撤销是指使一个原本对文件有访问权限用户不再含有对该文件权限。当从文件访问控制列表中移除一个用户项，或将一个用户从一个组中剔除时，全部会发生权限撤销。在通常加密文件系统中，权限撤销操作有较大计算开销，因为需要用新密钥重新加密文件，避免被撤销用户用原有文件密钥访问文件。在GKS-CFS中，为了降低权限撤销开销，采取了懒惰权限撤销（lazy revocation）方法，其基础思想是，当一个文件需要重新加密时，推迟重新加密时机，直到文件内容被更新时，同时只对被更新部分重新加密，从而经过降低加密数据量降低计算开销。在GKS-CFS中，经过LBK版本号和数据块密钥版本号控制权限撤销中重新加密过程。创建文件和向新文件写入数据时，LBK版本号和FBK版本号初始化为零。发生权限撤销时，更新文件LBK，用新LBK重新加密锁盒子中FBK（注意不需要重新加密文件数据块），同时将LBK版本号增加1。以后，对该文件有写权限用户对文件某个数据块更新或在文件尾追加新数据块时，首先比较数据块FBK版本号和LBK版本号，假如前者小于后者，表明数据块需要重新加密，则更新FBK，用新FBK加密新写入数据块，最终将FBK版本号增加到和FBK版本号一致，使下一次写入无须再更新FBK；假如前者等于后者，表明数据块不需要重新加密，用原有FBK加密新写入数据块即可。经过文件分块加密和FBK版本号使用，避免了只更新文件一小部分就需要将整个文件重新加密情况，最大程度降低了权限撤销对正常文件访问影响。4 安全性分析本节对GKS-CFS系统安全性进行分析，指出我们系统能够预防哪些攻击，哪些攻击仍然是可能，并讨论哪些方法能够预防这些攻击。以下分析均假设文件服务器上访问控制机制是不可信，一个非授权用户或攻击者能够经过文件服务器取得加密文件数据、锁盒子和访问控制块。能够预防攻击包含：(a) 对文件没有读权限用户或攻击者读取文件内容。因为文件数据块用FBK加密，一个文件全部FBK由LBK加密保留在锁盒子中，LBK由GEK加密放在ACB中，所以，没有读权限用户向GKS发出请求时，GKS不会将LBK解密返回给用户，从而用户不能用LBK解密锁盒子中FBK，进而用FBK解密文件数据块读取其内容。(b) 对文件没有写权限用户或攻击者篡改文件数据。没有写权限用户向GKS发出请求时，GKS不会将FSK解密返回给用户，从而用户不能按其意图更改根哈希值。假如用户更改数据块，当另一个授权用户读取文件，重新计算并校验根哈希时，或发觉数据块和锁盒子中哈希值不匹配，或发觉锁盒子中哈希值和ACB中根哈希不匹配，两种情况全部表明文件已被非法篡改。(c) 除全部者外其它用户经过修改ACB中访问控制属性取得对应权限。ACB含有完整性标识(auth_tag)确保其不可篡改性，只有GKS才能依据文件全部者请求对ACB中任何内容（包含访问控制属性）进行修改。其它用户或攻击者试图更改ACB并用更改过ACB向GKS发送请求时，GKS会经过校验auth_tag发觉ACB完整性已被破坏并拒绝请求。(d) 攻击者经过入侵GKS取得GEK和GSK。鉴于整个系统安全性取决于GEK和GSK两个密钥安全性，在真正系统实现中，应将它们保留在GKS上特殊防损硬件（Tamper-Resistant Hardware，TRH）中，该硬件可由硬件安全模组（Hardware Security Module, HSM）或智能卡（smartcard）实现，使用它们加密和解密LBK和FSK操作也全部在该特殊硬件内进行，确保这两个密钥在任何情况不会离开该特殊硬件。这么即使GKS软件被攻破，攻击者取得对GKS操作系统完全控制权，她也无法取得GEK和GSK，从而确保保留在文件服务器上文件仍然是安全。（在本文实现中，因为条件限制，我们仍然用软件模块实现GKS。）仍然可能攻击包含：(e) 对文件服务器攻击。攻击者能够攻击文件服务器，当攻击者控制文件服务器时，能够恶意损坏或删除其上文件，造成文件对授权用户不可访问。实际上，用单纯密码学方法不能预防这种对数据可用性攻击。能够将本文提出方法和数据冗余技术相结合提供可用性确保，比如将文件以多副本形式保留在多台文件服务器上。(f) 对组密钥服务器攻击。攻击者能够攻击组密钥服务器。即使不能取得GKS密钥（GEK和GSK），但能够将GKS停机或将保留密钥硬件拆除，造成保留在文件服务器上文件不能解密，但文件内容不会泄露。为预防这种攻击，能够将GKS密钥以秘密分存方法备份到多个恢复代理上，方便在存放密钥硬件丢失时恢复密钥。另一个方法是设置多台GKS同时提供密钥服务。(g) 对用户端攻击。攻击者能够经过攻击文件系统用户端得到目前用户正在访问文件及其密钥。但和基于文件组密钥管理策略6相比，因为采取了细粒度以文件为单位密钥管理策略，一次成功攻击只能获取单个文件密钥，而不是泄露组内全部文件共同密钥，将密钥泄露带来损害降到了最低。5 扩展方案我们在原有系统设计基础上提出一个扩展方案设计深入提升系统可用性和性能。在原系统设计中，GKS是系统中唯一安全访问入口点，轻易形成安全性微弱步骤和性能瓶颈。而扩展方案基础思想是：将GKS功效集成到一个卡片上，称为GK-Card，该卡片能够用硬件安全模组（Hardware Security Module, HSM）或智能卡（smartcard）实现。为每一个需要使用密钥服务文件系统用户端安装一个这么GK-Card。当用户需要解密ACB中密钥时，不再向网络上GKS发出请求，直接向本机GK-Card发请求即可。扩展方案和原GKS-CFS采取相同密钥层级结构，每个GK-Card负责加密和解密ACB中相关密钥，同时负责用户身份认证和访问控制。系统管理员为每个期望使用加密文件系统用户端分发一个GK-Card，并将GEK和GSK初始化到GK-Card中。用户端能够利用GK-Card完成ACB中密钥加解密，但不能取得其中GEK和GSK，确保了安全性。和原方案相比，扩展方案有两个优点：首先，假如本机GK-Card出现故障，只会造成本机上用户端无法访问文件，其它机器上用户端仍然能够经过自己GK-Card正常访问文件，一个GK-Card丢失也不会造成GKS密钥丢失，提升了系统可用性。其次，各密钥操作均在用户端完成，不需要发往GKS实施，避免了和GKS建立安全连接网络通信延迟及链路上用于认证、消息机密性和完整性计算开销，提升了系统性能。因为每个GK-Card只存放GEK和GSK两个密钥且不需要频繁更新，所以各个GK-Card能够独立行驶功效而不需要相互交互，确保了方案可行性。相关该扩展方案部分具体问题，如GK-Card接口和内部设计，文件系统用户端和GK-Card间通信协议，还需要做深入研究，这也是我们下一步工作之一。6 系统实现为了验证GKS-CFS设计方案可行性和效率，我们在Lustre8上实现了GKS-CFS原型系统。 Lustre是CFS企业开发并得到广泛应用开源并行文件系统，由文件系统用户端（FS client）、元数据服务器（MDS）和对象存放设备（OST）三部分组成，每部分又包含若干内核模块。比如，在用户端中包含实现文件系统逻辑模块llite，和OST交互模块OSC，和MDS交互模块MDC，在OSC之上结构逻辑对象设备模块LOV等。GKS-CFS软件结构图3所表示。其中白色矩形框代表Lustre原有软件模块，灰色矩形框代表我们新添加模块。我们增加了独立内核模块gks作为组密钥服务器，同时在用户端添加了两个内核模块gkc和crypto。gkc负责和GKS通信并向上提供密钥管理接口，是3.3节描述文件访问协议实施者。crypto模块实际完成文件数据块加解密操作，它调用了Linux内核提供crypto API函数库。创建和打开文件时，文件系统用户端调用gkc提供接口设置内存中和密钥相关数据结构；读写文件时，OSC模块在将一个数据块写入OST之前或从OST读出一个数据块以后调用crypto提供接口加密或解密数据块。为简明起见，图中只显示了Lustre用户端中和关键I/O逻辑联络紧密模块，而省略了其它模块。图3：GKS-CFS软件结构文件锁盒子以扩展属性形式保留在MDS上。在目前实现中，GKS没有对gkc发出请求进行用户身份认证，而且消息是以明文传输。以后计划引入Kerberos认证机制，GKS经过gkc提供票据认证其身份，并经过GKS和gkc协商会话密钥确保二者见消息机密性和完整性。7 性能评价我们在GKS-CFS原型系统上进行了测试，以衡量加密操作对系统性能影响。测试内容包含加解密相关操作开销和和给基准测试程序读写性能测试。7.1 密码学操作开销表2列出了多种文件操作中加解密相关操作额外开销。测试服务器配置为Intel Pentium III x 4处理器，1GB内存，运行Redhat Linux操作系统（内核版本2.6.10）。多种加解密相关操作开销用Linux内核提供crypto API库函数测量。在本文全部测试中，数据块大小为4KB，数据块用128比特密钥长度AES算法加密，加密模式为计数器模式。哈希值计算采取SHA-1。为了取得计算根哈希和解密锁盒子开销，假设文件平均大小为2MB。LBK、FSK和根哈希一样使用128比特密钥长度AES 加密，模式为ECB。ACB默认长度是512字节。表2：加解密相关操作开销文件操作加解密相关操作延迟（ms）累计（ms）实施者频率创建文件加密LBK和FSK计算ACB认证码0.190.320.51GKS每个文件打开文件校验ACB认证码解密LBK和FSK解密根哈希校验根哈希解密锁盒子0.320.190.190.70GKS每个文件1.521.953.47读/写者关闭文件计算根哈希加密根哈希1.520.191.71读/写者每个文件写文件加密数据块计算数据块哈希1.040.871.93写者每个数据块读文件解密数据块校验数据块哈希1.050.871.92读者每个数据块从表2能够看出，打开文件关键开销是计算根哈希和解密锁盒子，关闭文件关键开销是校验哈希根。读/写文件开销是加/解密数据块和计算/校验数据块哈希。权限撤销操作和创建文件类似，只是增加了重新加密锁盒子操作，为简明起见，它开销没有在表2中列出。当读写大文件时，加解密数据块和计算/校验署名将占额外开销关键部分。下面我们将GKS-CFS和基于公私钥密钥管理方案在创建和打开文件时文件密钥操作相关开销进行比较。在基于用户公私钥密钥管理方案（如3, 5, 6）中，创建文件时需要将文件密钥用每个含有权限用户公钥加密，并对密钥元数据署名，相关开销为Tcreate = nTPubEnc + TS，打开文件时需要用用户私钥解密文件密钥并验证密钥元数据署名，相关开销为Topen = TPubDec + TV。其中TPubEnc和TPubDec分别为一次公钥加密和公钥解密时间，TS和TV分别为一次署名操作和验证署名操作时间，n为对文件含有权限用户数目。在GKS-CFS基于对称密钥密钥管理方案中，创建文件相关开销为Tcreate = 2TSymEnc + TMAC，打开文件相关开销为Topen = 2TSymDec + TMAC，其中TSymEnc和TSymDec分别为一次对称密钥加密和解密时间，TMAC为一次计算对ACB计算认证码时间。公私钥密码计算复杂度要大大高于对称密码计算复杂度。在我们测试平台上测得一次公钥加密和解密延迟分别为50ms和15ms左右（署名和验证操作延迟在同一个数量级），大大高于AES加解密和计算认证码延迟。相比其它系统，因为我们提出方法中没有使用公钥密码系统，使一般文件操作中密码学操作开销降低了一个数量级。另外我们看到，由GKS实施操作只在创建和打开时发生且开销全部很小，大部分操作由用户端完成，这满足了设计目标中尽可能降低GKS计算量需求。7.2 IOZone性能测试我们用IOZone测试工具对GKS-CFS原型系统性能进行了测试，并和不带加密功效基准Lustre系统进行了比较，测试环境由百兆以太网连接4台服务器组成，分别充当用户端、MDS、OSD和GKS，服务器配置同7.1节。我们首先测试了加解密计算带来额外开销。为了更正确测量出加解密计算开销，我们将文件大小设为系统内存2倍即2GB，来尽可能屏蔽文件系统缓存影响，测试了在不一样I/O请求大小下吞吐率改变。结果图4和图5所表示。 图4：随机读性能比较 图5：随机写性能比较从图4和图5能够看出，加密部分对吞吐率影响随I/O请求大小增加而增大，这是因为加解密延迟随I/O请求大小增加速度基础是线性，而因为受寻道时间影响，I/O响应时间随I/O请求大小增加速度低于线性，所以加密延迟在总延迟百分比逐步增大。当I/O请求大小为64KB时，随机读和随机写吞吐率分别降低了23%和56%。接下来我们测试了GKS-CFS在不一样文件大小下随机读写和次序读写吞吐率并和基准Lustre系统比较。文件大小改变范围是64KB256MB，I/O请求大小设为64KB。次序读写和随机读写结果分别图6和图7所表示。从两图中能够看出，当文件大小小于4MB时，GKS-CFS和Lustre吞吐率差异较小，不超出14.6%。这是因为文件较小时，会被缓存在用户端文件系统缓存中，不会触发加解密操作。当文件大小超出4MB而小于256MB时，随机写和次序写性能会有较多降低，这是因为文件系统用户端llite会定时将内存中足够多脏页面写回到OST，从而触发加解密操作。 图6：不一样文件大小次序读写性能比较 图7：不一样文件大小随机读写性能比较7.3 Bonnie+性能测试为了评价GKS-CFS在多种文件系统操作（创建、读写、删除、获取属性等）时性能，我们用Bonnie+基准测试程序进行了测试，文件大小设为内存2倍即2GB。测试分两组，第一组是多种模式下次序读写性能，共测试5种模式：逐字符写（Write Per Chr）、块写（Write Block）、读后写（Rewrite）、逐字符读（Read Per Chr）、块读（Read Block），结果图8所表示。从结果能够看出，次序读写性能下降较大，平均降低42.0%，因为次序读写时磁盘寻道带来延迟缩短，所以加解密计算额外开销占了主导地位。其中，读后写模式吞吐率下降最大，为66.8%，这是因为该模式在读出数据和写入数据时需要做两次加解密操作。 图8：不一样模式次序读写性能比较 图9：随机文件操作性能比较第二组测试是多种随机文件元数据操作性能，包含创建（Create）、获取属性（Stat）、删除（Delete）、寻址（Seek）四种操作，指标是每秒操作次数。结果图9所表示。从结果能够看出，和次序读写相比，随机操作性能下降较小，平均下降8.4%，其中创建操作因为需要和GKS通信获取密钥，性能下降最大，为29.1%。在随机操作中，磁盘寻道延迟变大，占总延迟关键部分，而加解密计算开销影响相对变小。从Bonnie+两组试验结果能够看出，当应用特点为大数据量连续读写时，GKS-CFS加解密对系统性能影响较大；当应用特点为小数据量频繁文件元数据操作时，GKS-CFS和基准Lustre系统性能差异很小。7.4 扩展系统模拟实现和测试我们基于GKS-CFS工作给出扩展系统软件模拟实现和性能测试。因为硬件条件限制，在实现中我们用软件模拟GK-Card硬件行为，即把GK-Card实现为一个内核模块加载到用户端，把GKS-CFS系统中GKS密钥操作方法抽取出来封装在模块中，经过接口向用户端文件系统提供密钥操作服务。我们一样使用Bonnie+测试了系统文件元数据操作性能，并和基准Lustre和GKS-CFS进行比较。测试环境由3台服务器组成，分别充当用户端、MDS和OSD，服务器配置同5.1节。我们假设GK-Card由硬件安全模组（HSM）实现，经过PCI接口和主机连接，接口带宽为133MB/s。在我们实现中，ACB长度为128字节，则文件系统用户端和GK-Card间传输延迟为128B / 133MB/s x 2 = 1.92s。我们在GK-Card端用软件方法模拟这一延迟。假设GK-Card处理速率是主机CPU五分之一，我们用模块中每种密钥操作循环5次来模拟这种效应。测试结果图10所表示。图10：扩展系统随机文件操作性能测试从结果能够看出，除文件创建以外，基于GK-Card扩