PDF - eCryptfs: An Enterprise-class Cryptographic Filesystem for Linux

eCryptfs: An Enterprise-class Cryptographic Filesystemfor LinuxMichael Austin HalcrowInternational Business Machines, Inc.mhalcrow@us.ibm.comAbstracteCryptfs is a cryptographic filesystem forLinux that stacks on top of existing filesystems.It provides functionality similar to thatof GnuPG, only the process of encrypting anddecrypting the data is done transparently fromthe perspective of the application. eCryptfsleverages the recently introduced Linux kernelkeyring service, the kernel cryptographicAPI, the Linux Pluggable Authentication Modules(PAM) framework, OpenSSL/GPGME,the Trusted Platform Module (TPM), and theGnuPG keyring in order to make the processof key and authentication token managementseamless to the end user.1 Enterprise RequirementsAny cryptographic application is hard to implementcorrectly and hard to effectively deploy.When key management and interactionwith the cryptographic processes are cumbersomeand unwieldy, people will tend to ignore,disable, or circumvent the security measures.They will select insecure passphrases, mishandletheir secret keys, or fail to encrypt their sensitivedata altogether. This places the confidentialityand the integrity of the data in jeopardyof compromise in the event of unauthorized accessto the media on which the data is stored.While users and administrators take greatpains to configure access control mechanisms,including measures such as user accountand privilege separation, Mandatory AccessControl[13], and biometric identification,they often fail to fully consider the circumstanceswhere none of these technologies canhave any effect – for example, when the mediaitself is separated from the control of itshost environment. In these cases, access controlmust be enforced via cryptography.When a business process incorporates a cryptographicsolution, it must take several issuesinto account. How will this affect incrementalbackups? What sort of mitigation is in placeto address key loss? What sort of education isrequired on the part of the employees? Whatshould the policies be? Who should decidethem, and how are they expressed? How disruptiveor costly will this technology be? Whatclass of cryptography is appropriate, given therisks? Just what are the risks, anyway? Wheneversensitive data is involved, it is incumbentupon those responsible for the information toreflect on these sorts of questions and to takeaction accordingly.We see today that far too many businessesneglect to effectively utilize on-disk encryp-

tion. We often see news reports of computerequipment that is stolen in trivial cases ofburglary[5] or of backup tapes with sensitivecustomer data that people lose track of.[10]While the physical security measures in placein these business establishments are usuallysufficient given the dollar value of the actualequipment, businesses often underrate thevalue of the data contained on the media in thatequipment. Encryption can effectively protectthe data, but there there exist a variety of practicalbarriers to using it effectively. eCryptfsdirectly addresses these issues.1.1 Integration of File Encryption into theFilesystemCryptography extends access control beyondthe trusted domain. Within the trusted domain,physical control, authentication mechanisms,DAC/MAC[14][13], and other technologiesregulate what sort of behaviors userscan take with respect to data. Through variousmathematical operations, cryptographic applicationscan enforce the confidentiality and theintegrity of the data when it is not under theseforms of protection. The mathematics, however,is not enough. The cryptographic solutionmust take human behavior into accountand compensate for tendencies to take actionsthat compromise the security afforded by thecryptographic application.Several solutions exist that solve separatepieces of the data encryption problem. In oneexample highlighting transparency, employeeswithin an organization that uses IBM LotusNotes [11] for its email will not evennotice the complex PKI or the encryption processthat is integrated into the product. Encryptionand decryption of sensitive email messagesis seamless to the end user; it involveschecking an “Encrypt” box, specifying a recipient,and sending the message. This effectivelyaddresses a significant file in-transit confidentialityproblem. If the local replicated mailboxdatabase is also encrypted, then this addressesconfidentiality (to some extent) on thelocal storage device, but the protection is lostonce the data leaves the domain of Notes (forexample, if an attached file is saved to disk).The process must be seamlessly integrated intoall relevant aspects of the user’s operating environment.We learn from this particular application thatenvironments that embody strong hierarchicalstructures can more easily provide the infrastructurenecessary to facilitate an easy-to-useand effective organization-wide cryptographicsolution. Wherever possible, systems shouldleverage this infrastructure to protect sensitiveinformation. Furthermore, when organizationswith differing key management infrastructuresexchange data, the cryptographic applicationshould be flexible enough to support alternateforms of key management.Current cryptographic solutions that ship withLinux distributions do not fully leverage existingLinux security technologies to make theprocess seamless and transparent. Surprisinglyfew filesystem-level solutions utilize publickey cryptography. eCryptfs brings together thekernel cryptographic API, the kernel keyring,PAM, the TPM, and GnuPG in such a way soas to fill many of the gaps[3] that exist withcurrent popular cryptographic technologies.1.2 Universal ApplicabilityAlthough eCryptfs is geared toward securingdata in enterprise environments, we exploredhow eCryptfs can be flexible for use in a widevariety of circumstances. The basic passphrasemode of operation provides equivalent functionalityto that of EncFS[23] or CFS[20], withthe added advantage of the ability to copy an

encrypted file, as an autonomic unit, betweenhosts while preserving the associated cryptographiccontexts. eCryptfs includes a pluggablePublic Key Infrastructure API throughwhich it can utilize arbitrary sources for publickey management. One such plugin interfaceswith GnuPG (see Section 5.7) in order toleverage the web-of-trust mechanism alreadyin wide use among participants on the Internet.1.3 Enterprise-classWe designed and implemented eCryptfs withthe enterprise environment in mind. These environmentsentail a host of unique opportunitiesand requirements.1.3.1 Ease of Deploymentoperate at the VFS layer and can mount ontop of any previously existing directory. Thesefilesystems store cryptographic metadata inspecial files stored in the location mounted.Thus, the files themselves cannot be decryptedunless the user copies that metadata along withthe encrypted files.eCryptfs goes one step beyond other filesystemsby storing cryptographic metadata directlyin the files. This information is associatedon a per-file basis, in a manner dictated bypolicies that are contained in special files onthe target. These policies specify the behaviorof eCryptfs as it works with individual files atthe target. These policies are not required inorder for the user to work with the files, but thepolicies can provide enhanced transparency ofoperation. Planned enhancements include utilitiesto aid in policy generation (see Section 7).eCryptfs does not require any modifications tothe Linux kernel itself. 1 It is deployable as astand-alone kernel module that utilizes a setof userspace tools to perform key managementfunctions.Many other cryptographic filesystem solutions,such as dm-crypt, require that a fixed partition(or image) be established upon which to writethe encrypted data. This provides the flexibilityof block-layer encryption; any application,such as swap, a database application, ora filesystem, can use it without any modificationto the application itself. However, it islimited in that the amount of space allocatedfor the encrypted data is fixed. It is an inconvenienttask to increase or decrease the amountof space available on the encrypted partition.Cryptographic filesystems like EncFS[23] andCFS[20] are more easily deployable, as they1 Note that the key_type_user symbol must be exportedby the kernel keyring module, which may requirea one-line patch for older versions of the module.1.3.2 PKI IntegrationThrough its pluggable PKI interface (see Section5.7), eCryptfs aims to be integrable withexisting Public Key Infrastructures.1.3.3 TPM UtilizationThe Trusted Computing Group has publishedan architecture standard for hardware supportfor various secure operations.[7] Several vendors,including IBM, implement this standardin their products today. As an example, morerecent IBM Thinkpad and workstation productsship with an integrated Trusted ComputingPlatform (TPM) chip.The TPM can be configured to generate a public/privatekeypair in which the private exponentcannot be obtained from the chip. Thesession key to be encrypted or decrypted with

this key must be passed to the chip itself, whichwill then use the protected private key to performthe operation. This hardware support providesa strong level of protection for the keythat is beyond that which can be provided by asoftware implementation alone.Using a TPM, eCryptfs can essentially “bind”a set of files to a particular host. Should themedia ever be separated from the host whichcontains the TPM chip, the session keys (seeSection 5.1) of the file will be irretrievable.The user can even configure the TPM in sucha manner so that the TPM will refuse to decryptdata unless the machine is booted in acertain configuration; this helps to address attacksthat involve booting the machine fromuntrusted media.1.3.4 Key EscrowEmployees often forget or otherwise lose theircredentials, and it is subsequently necessaryfor the administrator to reset or restore thosecredentials. Organizations expect this to happenand have processes in place to rectify thesituations with a minimal amount of overhead.When strong cryptographic processes are inplace to enforce data integrity and confidentiality,however, the administrator is no morecapable of retrieving the keys than anyone elseis, unless some steps are taken to store the keyin a trustworthy escrow.which they apply, as EncFS or CFS do, allowfor incremental backup utilities to operatewhile maintaining the security of the data,but the administrator must take caution to assurethat the backup tools are also recording thecryptographic metadata. Since eCryptfs storesthis data in the body of the files themselves,the backup utilities do not need to take any additionalmeasures to make a functional backupof the encrypted files.2 Related WorkeCryptfs extends cryptfs, which is one ofthe filesystems instantiated by the stackablefilesystem framework FiST.[9] Erez Zadokheads a research lab at Stony Brook University,where FiST development takes place. Cryptfsis an in-kernel implementation; another optionwould be to extend EncFS, a userspace cryptographicfilesystem that utilizes FUSE to interactwith the kernel VFS, to behave in a similarmanner. Much of the functionality of eCryptfsrevolves around key management, which canbe integrated, without significant modification,into a filesystem like EncFS.Other cryptographic filesystem solutionsavailable under Linux include dm-crypt[18](preceded by Cryptoloop and Loop-AES),CFS[20], BestCrypt[21], PPDD[19],TCFS[22], and CryptoFS[24]. Reiser4[25]provides a plugin framework whereby cryptographicoperations can be implemented.1.3.5 Incremental BackupsCryptographic filesystem solutions that operateat the block layer do not provide adequatesecurity when interoperating with incrementalbackup utilities. Solutions that store cryptographiccontexts separately from the files to3 Design StructureeCryptfs is unique from most other cryptographicfilesystem solutions in that it storesa complete set of cryptographic metadata togetherwith each individual file, much like

Figure 1: Overview of eCryptfs architecturePGP-encrypted files are formatted. This allowsfor encrypted files to be transferred acrosstrusted domains while maintaining the abilityfor those with the proper credentials to gainaccess to those files. Because the encryptionand decryption takes place at the VFS layer,the process is made transparent from the application’sperspective.eCryptfs is implemented as a kernel moduleaugmented with various userspace utilitiesfor performing key management functions.The kernel module performs the bulk encryptionof the file contents via the kernel cryptographicAPI. A keystore component extractsthe header information from individual files 2and forwards this data to a callout application.The callout application evaluates the headerinformation against the target policy and performsvarious operations, such as promptingthe user for a passphrase or decrypting a ses-2 Note that the initial prototype of eCryptfs, demonstratedat OLS 2004, utilized Extended Attributes (EA)to store the cryptographic context. Due to the fact thatEA’s are not ubiquitously and consistently supported,this information was moved directly into the file contents.eCryptfs now uses EA’s to cache cryptographiccontexts, but EA support is not required for correct operation.sion key with a private key.eCryptfs performs key management operationsat the time that an application either opens orcloses a file (see Figure 2). Since these eventsoccur relatively infrequently in comparison topage reads and writes, the overhead involved intransferring data and control flow between thekernel and userspace is relatively insignificant.Furthermore, pushing key management functionsout into userspace reduces the amountand the complexity of code that must run inkernel space.4 Cryptographic OperationseCryptfs performs the bulk symmetric encryptionof the file contents in the kernel moduleportion itself. It utilizes the kernel cryptographicAPI.4.1 File FormatThe underlying file format for eCryptfs isbased on the OpenPGP format described in

Figure 2: New file processRFC 2440[2] (see Figure 3). In order to accommodaterandom access, eCryptfs necessarilydeviates from that standard to some extent.The OpenPGP standard assumes that the encryptionand decryption is done as an atomicoperation over the entire data contents of thefile; there is no concept of a partially encryptedor decrypted file. Since the data is encryptedusing a chained block cipher, it would be impossibleto read the very last byte of a file withoutfirst decrypting the entire contents of thefile up to that point. Likewise, writing the veryfirst byte of the file would require re-encryptingthe entire contents of the file from that point.To compensate for this particular issue whilemaintaining the security afforded by a cipheroperating in block chaining mode[6], eCryptfsbreaks the data into extents. These extents,by default, span the page size (as specified foreach kernel build). Data is dealt with on aper-extent basis; any data read from the middleof an extent causes that entire extent to bedecrypted, and any data written to that extent

Figure 3: Underlying file formatcauses that entire extent to be encrypted.Each extent has a unique initialization vector(IV) associated with it. One extent containingIV’s precedes a group of extents to which thoseIV’s apply. Whenever data is written to an extent,its associated IV is rotated and rewritten tothe IV extent before the associated data extentis encrypted. The extents are encrypted withthe block cipher selected by policy for that fileand employ CBC mode to chain the blocks.4.1.1 Sparse FilesSparse files present a challenge for eCryptfs.Under UNIX semantics, a file becomes sparsewhen an application seeks past the end of a file.The regions of the file where no data is writtenrepresent holes. No data is actually written tothe disk for these regions; the filesystem “fakesit” by specially marking the regions and settingthe reported filesize accordingly. The space occupiedon the disk winds up being less than thesize of the file as reported by the file’s inodes.When sparse regions are read, the filesystemsimply pretends to be reading the data from thedisk by filling in zero’s for the data.The underlying file structure for eCryptfsis amenable to accommodating this behavior;IV’s consisting of all zero’s can indicatethat the underlying region that corresponds issparse. The obvious problem with this approachis that it is readily apparent to an attackerwhich regions of the file consist of holes,and this may constitute an unacceptable breachof confidentiality. It makes sense to relegateeCryptfs’s behavior with respect to sparse filesas something that policy decides.4.2 Kernel Crypto APIeCryptfs performs the bulk data encryption inthe kernel module, and hence it takes advantageof the kernel cryptographic API to performthe encryption and the decryption. Oneof the primary motivators in implementingeCryptfs in the kernel is to avoid the overheadof context switches between userspace and kernelspace, which is frequent when dealing withpages in file I/O. Any symmetric ciphers supportedby the Linux kernel are candidates forusage as the bulk data ciphers for the eCryptfsfiles.4.3 Header InformationeCryptfs stores the cryptographic context foreach file as header information contained directlyin the underlying file (see Figure 4).Thus, all of the information necessary for userswith the appropriate credentials to access thefile is readily available. This makes filesamenable to transfer across untrusted domainswhile preserving the information necessary todecrypt and/or verify the contents of the file.In this respect, eCryptfs operates much like anOpenPGP application.

Figure 4: Writing file headersMost encrypted filesystem solutions either operateon the entire block device or operate onentire directories. There are several advantagesto implementing filesystem encryption at thefilesystem level and storing encryption metadatain the headers of each file:• Granularity: Keys can be mapped to individualfiles, rather than entire block devicesor entire directories.• Backup Utilities: Incremental backuptools can correctly operate without havingto have access to the decrypted content ofthe files it is backing up.• Performance: In most cases, only certainfiles need to be encrypted. Systemlibraries and executables, in general, donot need to be encrypted. By limiting theactual encryption and decryption to onlythose files that really need it, system resourceswill not be taxed as much.• Transparent Operation: Individual encryptedfiles can be easily transferred offof the block device without any extratransformation, and others with authorizationwill be able to decrypt those files. Theuserspace applications and libraries do notneed to be modified and recompiled tosupport this transparency.4.4 Rotating Initialization VectorseCryptfs extents span page lengths. For mostarchitectures, this is 4096 bytes. Subsequent

writes within extents may provide informationto an attacker who aims to perform linearcryptanalysis against the file. In order tomitigate this risk, eCryptfs associates a uniqueInitialization Vector with each extent. TheseIV’s are interspersed throughout each file. Inorder to simplify and streamline the mappingof the underlying file data with the overlyingfile, IV’s are currently grouped on a per-pagebasis.4.5 HMAC’s Over ExtentsIntegrity verification can be accomplished viasets of keyed hashes over extents within thefile. Keyed hashes are used to prove thatwhoever modified the data had access to theshared secret, which is, in this case, the sessionkey. Since hashes apply on a per-extentbasis, eCryptfs need not generate the hash overthe entire file before it can begin reading thefile. If, at any time in the process of readingthe file, eCryptfs detects a hash mismatch foran extent, it can flag the read operation as failingin the return code for the VFS syscall.This technique can be applied to generatea built-in digital signature structure for filesdownloaded over the Internet. Given that aneCryptfs key management module is able to ascertainthe trustworthiness of a particular key,then that key can be used to encode a verificationpacket into the file via HMAC’s. Thisis accomplished by generating hashes over theextents of the files, as eCryptfs normally doeswhen operating in integrity verification mode.When the file is closed, an HMAC is generatedby hashing the concatenation of all ofthe hashes in the file, along with a secret key.This HMAC is then encrypted with the distributor’sprivate key and written to an HMACtypepacket. The recipients of the file can proceedthen to retrieve the secret key by decryptingit with the distributor’s trusted public keyand performing the hash operations to generatethe final HMAC, which can be comparedthen against the HMAC that is stored in the fileheader in order to verify the file’s integrity.4.6 File ContextEach eCryptfs inode correlates with an inodefrom the underlying filesystem and has a cryptographiccontext associated with it. This contextcontains, but is not limited to, the followinginformation:• The session key for the file• Whether the file is encrypted• A pointer to the kernel crypto API contextfor that file• The signatures of the authentication tokensassociated with that file• The size of the extentseCryptfs can cache each file’s cryptographiccontext in the user’s session keyring in orderto facilitate faster repeat access by bypassingthe process of reading and interpreting of authenticationtoken header information from thefile.4.7 RevocationSince anyone with the proper credentials canextract a file’s session key, revocation of accessfor any given credential to future versions ofthe file will necessitate regeneration of a sessionkey and re-encryption of the file data withthat key.

Figure 5: Key management5 Key Management5.1 Session KeyseCryptfs aims to operate in a manner that is astransparent as possible to the applications andthe end users of the system. Under most circumstances,when access control over the datacannot be provided at all times by the host, thefact that the files are being encrypted shouldnot be a concern for the user. Encryption mustprotect the confidentiality and the integrity ofthe files in these cases, and the system is configuredto do just that, using the user’s authenticationcredentials to generate or access thekeys.Every file receives a randomly generated sessionkey, which eCryptfs uses in the bulk dataencryption of the file contents. eCryptfs storesthis session key in the cryptographic metadatafor the file, which is in turn cached in the user’ssession keyring. When an application closesa newly created file, the eCryptfs encrypts thesession key once for each authentication tokenassociated with that file, as dictated by policy,then writes these encrypted session keys intopackets in the header of the underlying file.When an application later opens the file,eCryptfs reads in the encrypted session keys

and chains them off of the cryptographic metadatafor the file. eCryptfs looks through theuser’s authentication tokens to attempt to finda match with the encrypted session keys; ituses the first one found to decrypt the sessionkey. In the event that no authentication tokensin the user’s session keyring can decrypt anyof the encrypted session key packets, eCryptfsfalls back on policy. This policy can dictateactions such as querying PKI modules for theexistence of private keys or prompting the userfor a passphrase.5.2 PassphrasePasswords just don’t work anymore.– Bruce SchneierMany cryptographic applications in Linux relytoo heavily on passphrases to protect data.Technology that employs public key cryptographyprovides stronger protection againstbrute force attacks, given that the passphraseprotectedprivate keys are not as easily accessibleas the encrypted data files themselves.Passphrase authentication tokens in eCryptfsexist in three forms: non-passphrased, saltless,and salted. In order to address the threatof passphrase dictionary attacks, eCryptfs utilizesthe method whereby a salt value is concatenatedwith a passphrase to generate apassphrase identifier. The concatenated valueis iteratively hashed (65,537 times by default)to generate the identifying signature for thesalted authentication token.On the other hand, saltless authentication tokensexist only in the kernel keyring and are notat any time written out to disk. The userspacecallout application combines these saltless authenticationtokens with non-passphrased authenticationtokens to generate candidate saltedauthentication tokens, whose signatures arecompared against those in file headers.While eCryptfs supports passphrase-based protectionof files, we do not recommend usingpassphrases for relatively high-value data thatrequires more than casual protection. Mostpassphrases that people are capable of rememberingare becoming increasingly vulnerable tobrute force attacks. eCryptfs takes measuresto make such attacks more difficult, but thesemeasures can only be so effective against a determinedand properly equipped adversary.Every effort should be made to employ the useof a TPM and public key cryptography to providestrong protection of data. Keep in mindthat using a passphrase authentication token inaddition to a public key authentication tokendoes not in any way combine the security ofboth; rather, it combines the insecurity of both.This is due to the fact that, given two authenticationtokens, eCryptfs will encrypt and storetwo copies of the session key (see Section 5.1)that can individually be attacked.5.3 Kernel KeyringDavid Howells recently authored the keyringservice, which kernel versions 2.6.10 and laternow include. This keyring provides a host offeatures to manage and protect keys and authenticationtokens. eCryptfs takes advantageof the kernel keyring, utilizing it to store authenticationtokens, inode cryptographic contexts,and keys.5.4 Callout and DaemonThe primary contact between the eCryptfs kernelmodule and the userspace key managementcode is the request-key callout application,which the kernel keyring invokes. Thiscallout application parses policy informationfrom the target, which it interprets in relationto the header information in each file. It may

then make calls through the PKI API in order tosatisfy pending public key requests, or it maygo searching for a salted passphrase with a particularsignature.In order to be able to prompt the user for apassphrase via a dialog box, eCryptfs musthave an avenue whereby it can get to the user’sX session. The user can provide this means bysimply running a daemon. The eCryptfs daemonlistens to a socket (for which the locationis written to the user’s session keyring). Wheneverpolicy calls for the user to be promptedfor a passphrase, the callout application can retrievethe socket’s location and use it to requestthe daemon to prompt the user; the daemonthen returns the user’s passphrase to the calloutapplication.passphrase can be used to extract the user’s privatekey from his GnuPG keyring. It could beused to derive a key (via a string-to-key operation)that is directly used to protect a sessionkey for a set of files. Furthermore, this derivedkey could be combined with a key stored in aTPM in order to offer two-factor authentication(i.e., in order to access a file, the user must have(1) logged into a particular host (2) using a particularpassphrase).Due to PAM’s flexibility, these operations donot need to be restricted to a passphrase. Thereis no reason, for example, that a key containedon a SmartCard or USB device could not beused to help authenticate the user, after whichpoint that key is used in the above named cryptographicoperations.5.5 Userspace Utilities5.7 PKITo accommodate those who are not running theeCryptfs layer on their systems, userspace utilitiesto handle the encrypted content comprisepart of the eCryptfs package. These utilities actmuch like scaled-down versions of GnuPG.5.6 Pluggable Authentication ModulePluggable Authentication Modules (PAM)provide a Discretionary Access Control(DAC)[14] mechanism whereby administratorscan parameterize how a user isauthenticated and what happens at the timeof authentication. eCryptfs includes a modulethat captures the user’s login passphrase andstores it in the user’s session keyring. Thispassphrase is stored in the user’s sessionkeyring as a saltless passphrase authenticationtoken.Future actions by eCryptfs, based on policy,can then use this passphrase to perform cryptographicoperations. For example, the logineCryptfs offers a pluggable Public Key Infrastructure(PKI) interface. PKI modules acceptkey identifiers and data, and they return encryptedor decrypted data. Whether any particularkey associated with an identifier is available,trustworthy, etc., is up to the PKI moduleto determine.eCryptfs PKI modules need to implement a setof functions that accept as input the key identifierand a blob of data. The modules have theresponsibility to take whatever course of actionis necessary to retrieve the requisite key, evaluatethe trustworthiness of that key, and performthe public key operation.eCryptfs includes a PKI module that utilizesthe GnuPG Made Easy (GPGME) interfaceto access and utilize the user’s GnuPGkeyring. This module can utilize the user’s loginpassphrase credential, which is stored inthe user’s session keyring by the eCryptfs PAM(see Section 5.6), to decrypt and utilize theuser’s private key stored on the user’s keyring.

The eCryptfs TPM PKI module utilizes theTrouSerS[26] interface to communicate withthe Trusted Platform Module. This allows forthe use of a private key that is locked in thehardware, binding a file to a particular host.The eCryptfs openCryptoki PKCS#11[15]framework PKI provides a mechanism forperforming public key operations via varioushardware devices supported by openCryptoki,including the IBM Cryptographic Accelerator(ICA) Model 2058, the IBM 4758 PCI CryptographicCoprocessor, the Broadcom CryptoAccelerator, the AEP Crypto Accelerator, andthe TPM.It is easy to write additional PKI modules foreCryptfs. Such modules can interface withexisting PKI’s that utilize x.509 certificates,with certificate authorities, revocation lists, andother elements that help manage keys within anorganization.5.8 Key Escrow/Secret SharingIn enterprise environments, it often makessense for data confidentiality and integrity tobe a shared responsibility. Just as prudent businessorganizations entail backup plans in theevent of the sudden loss of any one employee,the data associated with business operationsmust survive any one individual in the company.In the vast majority of the cases, it isacceptable for all members of the business tohave access to a set of data, while it is notacceptable for someone outside the companywho steals a machine or a USB pen drive tohave access to that data. In such cases, someforms of key escrow within the company areappropriate.In enterprise environments where corporateand customer data are being protected cryptographically,key management and key recoveryis an especially critical issue. Techniquessuch as secret splitting or (m,n)-thresholdschemes[4] can be used within an organizationto balance the need for key secrecy with theneed for key recovery.5.9 Target-centric PoliciesWhen an application creates a new file,eCryptfs must make a number of decisionswith regard to that file. Should the file be encryptedor unencrypted? If encrypted, whichsymmetric block cipher should be used toencrypt the data? Should the file containHMAC’s in addition to IV’s? What should thesession key length be? How should the sessionkey be protected?Protecting the session key on disk requireseven more policy decisions. Should apassphrase be used? Which one, and howshould it be retrieved? What should be thestring-to-key parameters (i.e., which hash algorithmand the number of hash iterations)?Should any public keys be used? If so, whichones, and how should they be retrieved?eCryptfs currently supports Apache-like policydefinition files 3 that contain the policies thatapply to the target in which they exist. For example,if the root directory on a USB pen drivedevice contains a .ecryptfsrc file, then eCryptfswill parse the policy from that file and applyit to all files under the mount point associatedwith that USB pen drive device.Key definitions associate labels with(P KI, Id) tuples (see Figure 6).Application directive definitions override defaultpolicies for the target, dependent uponthe application performing the action and thetype of action the application is performing(see Figure 7).3 XML formats are currently being worked on.

Application /usr/bin/muttScenario OPEN_FOR_READFileState ENCRYPTEDAction PROMPTApplication /usr/bin/muttScenario ALLFileState ENCRYPTEDAction DECRYPTApplication /usr/bin/oofficeScenario OPEN_FOR_CREATEAction encrypt_strongFigure 7: Example policy: application directivesThe action definitions associate labels with(Action, Cipher, SessionKeySize) tuples.eCryptfs uses these directives to set cryptographiccontext parameters for files (see Figure8).The directory policy definitions give defaultactions for files created under the specified directorylocation, along with application directivesthat apply to the directory location (seeFigure 9).6 Additional MeasureseCryptfs concerns itself mainly with protectingdata that leaves trusted domains. Additionalmeasures are necessary to address variousthreats outside the scope of eCryptfs’sinfluence. For example, swap space shouldbe encrypted; this can be easily accomplishedwith dm-crypt.[18]Strong access control is outside the scope ofthe eCryptfs project, yet it is absolutely necessaryto provide a comprehensive security solutionfor sensitive data. SE Linux[16] providesa robust Mandatory Access Control frameworkthat can be leveraged with policies to protectthe user’s data and keys.Furthermore, the system should judiciouslyemploy timeouts or periods of accessibility/applicabilityof credentials. The kernelkeyring provides a convenient and powerfulmechanism for handling key permissions andexpirations. These features must be used appropriatelyin order to address human oversight,such as failing to lock down a terminalor otherwise exit or invalidate a security contextwhen the user is finished with a task.

DefaultAction blowfish_encryptDefaultState PROMPTDefaultPublicKeys mhalcrow legalDefaultPassphrase LOGIN# This directives for files under this location# that meet this criteriaApplicationDirective mutt_decryptApplicationDirective mutt_prompt_on_read_encrypted# Overrides the prior set of policiesDefaultAction encrypt_strongDefaultPublicKeys host_tpmFigure 9: Example policy: directory policies7 Future WorkeCryptfs is currently in an experimental stageof development. While the majority of the VFSfunctionality is implemented and functioning,eCryptfs requires testing and debugging acrossa wide range of platforms under a variety ofworkload conditions.eCryptfs has the potential to provide weak filesize secrecy in that the size of the file wouldonly be determinable to the granularity of oneextent size, given that the file size field inthe header is encrypted with the session key.Strong file size secrecy is much more easilyobtained through block device layer encryption,where everything about the filesystem isencrypted. eCryptfs only encrypts the datacontents of the files; additional secrecy measuresmust address dentry’s, filenames, andExtended Attributes, which are all within therealm of what eCryptfs can influence.At this stage, eCryptfs requires extensive profilingand streamlining in order to optimize itsperformance. We need to investigate opportunitiesfor caching cryptographic metadata,and variations on such attributes as the size ofthe extents could have a significant impact onspeed.eCryptfs policy files are equivalent to theApache configuration files in form and complexity.eCryptfs policy files are amenable toguided generation via user utilities. Anothersignificant area of future development includesthe development of such utilities to aid in thegeneration of these policy files.Desktop environments such as GNOME orKDE can provide users with a convenient interfacethrough which to work with the cryptographicproperties of the files. In one scenario,by right-clicking on an icon representingthe file and selecting “Security”, the user

PKI GPGId 3F5C22A9PKI GPGId 7AB1FF25PKI TPMId DEFAULTAction ENCRYPTCipher blowfishSessionKeySize 128Action ENCRYPTCipher aesSessionKeySize 256Figure 8: Example policy: action defsFigure 6: Example policy: key defswill be presented with a window that can beused to control the encryption status of the file.Such options will include whether or not thefile is encrypted, which users should be ableto encrypt and decrypt the file (identified bytheir public keys as reported by the PKI pluginmodule), what cipher is used, what keylengthis used, an optional passphrase that is used toencrypt the symmetric key, whether or not touse keyed hashing over extents of the file forintegrity, the hash algorithms to use, whetheraccesses to the file when no key is availableshould result in an error or in the encryptedblocks being returned (as dictated by targetcentricpolicies5.9), and other properties thatare interpreted and used by the eCryptfs layer.8 RecognitionsWe would like to express our appreciation forthe contributions and input on the part of allthose who have laid the groundwork for an efforttoward transparent filesystem encryption.This includes contributors to FiST and Cryptfs,GnuPG, PAM, and many others from whichwe are basing our development efforts, as wellas several members of the kernel developmentcommunity.9 ConclusioneCryptfs is an effort to reduce the barriers thatstand in the way of the effective and ubiquitousutilization of file encryption. This is especiallyrelevant as physical media remains exposedto theft and unauthorized access. Wheneversensitive data is being handled, it shouldbe the modus operandi that the data be encryptedat all times when it is not directly beingaccessed in an authorized manner by the applications.Through strong and transparent keymanagement that includes public key support,key->file association, and target-centric policies,eCryptfs provides the means whereby acryptographic filesystem solution can be moreeasily and effectively deployed.

10 AvailabilityeCryptfs is licensed under the GNUGeneral Public License (GPL). Source-Forge is hosting the eCryptfs code baseat http://sourceforge.net/projects/ecryptfs. We welcomeany interested parties to become involved inthe testing and development of eCryptfs.11 Legal StatementThis work represents the view of the author anddoes not necessarily represent the view of IBM.IBM and Lotus Notes are registered trademarksof International Business Machines Corporationin the United States, other countries,or both.Other company, product, and service namesmay be trademarks or service marks of others.References[1] M. Blaze. “Key Management in an EncryptingFile System”, Proc. Summer ’94USENIX Tech. Conference, Boston, MA,June 1994.[2] J. Callas, L. Donnerhacke, H. Finney, andR. Thayer. RFC 2440. November 1998.See ftp://ftp.rfc-editor.org/in-notes/rfc2440.txt.[3] M. Halcrow. “Demands, Solutions, andImprovements for Linux Filesystem Security.”Proceedings of the 2004 OttawaLinux Symposium, Ottawa, Canada, July2004.[4] S. C. Kothari. “Generalized Linear ThresholdScheme.” Advances in Cryptology:Proceedings of CRYPTO 84, Springer-Verlag, 1985, pp. 231-241.[5] M. Liedtke. “Stolen UC Berkeleylaptop exposes personal data ofnearly 100,000.” Associated Press.March 29, 2005. See http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2005/03/28/financial/f151143S80.DTL[6] B. Schneier. Applied Cryptography. NewYork: John Wiley & Sons, Inc., 1996. Pp.193-197.[7] The Trusted Computing Group.“TCG Specification ArchitectureOverview version 1.0.” https://www.trustedcomputinggroup.org/downloads/ TCG_1_0_Architecture_Overview.pdf[8] E. Zadok, L. Badulescu, and A. Shender.“Cryptfs: A stackable vnode levelencryption file system.” Technical ReportCUCS-021-98, Computer Science Department,Columbia University, 1998.[9] E. Zadok and J. Nieh. “FiST: A Languagefor Stackable File Systems.” Proceedingsof the Annual USENIX Technical Conference,pp. 55-70, San Diego, June 2000.[10] “Ameritrade addresses missing tape.”United Press International. April 19, 2005.See http://washingtontimes.com/upi-breaking/20050419-110638-7335r.htm[11] For more information on IBM LotusNotes, see http://www-306.ibm.com/software/lotus/. Informationon Notes security can be obtained fromhttp://www-10.lotus.com/ldd/today.nsf/f01245ebfc115aaf

8525661a006b86b9/232e604b847d2cad88256ab90074e298?OpenDocument[12] For more information on PluggableAuthentication Modules (PAM), seehttp://www.kernel.org/pub/linux/libs/pam/[13] For more information on MandatoryAccess Control (MAC), see http://csrc.nist.gov/publications/nistpubs/800-7/node35.html[14] For more information on DiscretionaryAccess Control (DAC), see http://csrc.nist.gov/publications/nistpubs/800-7/node25.html[23] For more information on EncFS,see http://arg0.net/users/vgough/encfs.html[24] For more information on CryptoFS, seehttp://reboot.animeirc.de/cryptofs/[25] For more information on Reiser4, seehttp://www.namesys.com/v4/v4.html[26] For more information on TrouSerS,see http://sourceforge.net/projects/trousers/[15] For more information on openCryptoki,see http://sourceforge.net/projects/opencryptoki[16] For more information on Security-Enhanced Linux (SE Linux), seehttp://www.nsa.gov/selinux/index.cfm[17] For more information on Samhain, seehttp://la-samhna.de/samhain/[18] For more information on DM-crypt,see http://www.saout.de/misc/dm-crypt/[19] For more information on PPDD,see http://linux01.gwdg.de/~alatham/ppdd.html[20] For more information on CFS, seehttp://sourceforge.net/projects/cfsnfs/[21] For more information on BestCrypt, seehttp://www.jetico.com/index.htm#/products.htm[22] For more information on TCFS, seehttp://www.tcfs.it/