Difference between revisions of "User:Helixgroup"

From ForensicsWiki
Jump to: navigation, search
(Draft: This Is About 4 1/2 Pages)
(4 intermediate revisions by 2 users not shown)
Line 256: Line 256:
 
Quoted from http://www.gsnmagazine.com/oct_05_02/high_speed.html (Online, Nov 13)
 
Quoted from http://www.gsnmagazine.com/oct_05_02/high_speed.html (Online, Nov 13)
  
=== Draft: Introduction ===
+
=== Draft: This Is About 4 1/2 Pages ===
 
Introduction
 
Introduction
  
As multi-user, networked computing systems become more prevalent, the problem of protecting sensitive data from unauthorized disclosure and tampering becomes increasingly important.  In 1998, Information Security magazine’s annual survey of security breaches concluded that 54% of all reported security incidents involved unauthorized access by employees.  Only 12% of the reported incidents involved a security breach by an outsider[1]. By 2004, a similar study indicated that in the UK, 51% of reported security incidents involved insiders[2].  However, according to a recent Enterprise Strategy Group survey, less than seven percent of stored backups are encrypted , and less than that are encrypted “at rest” (on disk)[3].
+
As multi-user, networked computing systems become more prevalent, the problem of protecting sensitive data from unauthorized disclosure and tampering becomes increasingly important.  In 1998, Information Security magazine’s annual survey of security breaches concluded that 54% of all reported security incidents involved unauthorized access by employees.  Only 12% of the reported incidents involved a security breach by an outsider (Briney, 1998) In 2004, a similar study indicated that in the UK, 51% of reported security incidents involved insiders (PriceWaterhouseCoopers, 2004).
  
Since Cryptographic File Systems (CryptFS) ensure data integrity and security without requiring user interaction to explicitly encrypt and decrypt the data, it would seem obvious that companies would implement a CryptFS on all systems, and yet they are not.  According to a recent Enterprise Strategy Group survey, less than seven percent of stored backups are encrypted , and less than that are encrypted “at rest” (on disk)[3].
+
Since Cryptographic File Systems (CryptFS) ensure data integrity and security without requiring user interaction to explicitly encrypt and decrypt the data, it would seem obvious that companies would implement a CryptFS on all systems, and yet they are not.  According to a recent Enterprise Strategy Group survey, less than seven percent of stored backups are encrypted , and less than seven percent of data is encrypted “at rest” (on disk) (Robb 2004).
  
This paper describes the Cryptographic File System and the CryptFS “space”, analyzes three Cryptographic File Systems in detail, and then describes why encrypting files on disk is not more common.  Then, a process whereby the adoption rate in business of CryptFS is presented.
+
This paper describes the Cryptographic File System and the CryptFS “space”, analyzes three Cryptographic File Systems in detail, and then describes why encrypting files on disk is not more common.  Then, a process whereby the adoption rate in business of CryptFS will increase is presented.
  
 
Definition of a Cryptographic File System
 
Definition of a Cryptographic File System
  
A Cryptographic File System (CryptFS) is a file system which stores and retrieves all data from the disk in encrypted form, and encrypts/decrypts the data within the address space of the requesting process.  Since the data is stored in encrypted form on the disk, all copies of the data, including backups, are ensured to be encrypted also.  The purpose of such a file system is to add an additional layer of security, controlled by the user, over that user's data.  This is accomplished by making the user storing data be responsible for managing the cryptographic keys with which the data will be encrypted and decrypted.  The goal of a CryptFS is to allow the users storing data to feel confident that the data placed in the CryptFS cannot be compromised, and that access to the “cleartext” (unencrypted) data is controlled by the user through controlling access to the cryptographic keys.
+
A Cryptographic File System is a file system which stores and retrieves all data from the disk in encrypted form, and encrypts/decrypts the data within the address space of the requesting process.  Since the data is stored in encrypted form on the disk, all copies of the data, including backups, are ensured to be encrypted also.  The purpose of such a file system is to add an additional layer of security, controlled by the user, over that user's data.  This is accomplished by making the user storing data be responsible for managing the cryptographic keys with which the data will be encrypted and decrypted.  The goal of a CryptFS is to allow the users storing data to feel confident that the data placed in the CryptFS cannot be compromised, and that access to the “cleartext” (unencrypted) data is controlled by the user through controlling access to the cryptographic keys.
  
{ this probably needs a lot more }
+
{ this probably needs some more } {key management – how they are generated [one for system, one per user, etc]. how to recover if key lost, what if employee leaves, etc.}  Key management is probably the most important feature to consider when evaluating CryptFS implementations.
  
 
Review of the Literature
 
Review of the Literature
Line 275: Line 275:
 
An initial survey of the current Cryptographic File Systems commonly in use today reveals that there are both hardware- and software-based systems.  These implementations  provide support for single- and multi-user situations.  Single-user solutions were not considered as part of the CryptFS space, since by definition, the user is responsible for all facets of the system, including hardware installation, software installation, determining which files should be encrypted, etc.  Hardware solutions were also not in the scope of the CryptFS space, as the implementation and cryptographic key management of hardware solutions are, in a multi-user system, typically out of the control of any single user, and therefore are transparent to the user.  
 
An initial survey of the current Cryptographic File Systems commonly in use today reveals that there are both hardware- and software-based systems.  These implementations  provide support for single- and multi-user situations.  Single-user solutions were not considered as part of the CryptFS space, since by definition, the user is responsible for all facets of the system, including hardware installation, software installation, determining which files should be encrypted, etc.  Hardware solutions were also not in the scope of the CryptFS space, as the implementation and cryptographic key management of hardware solutions are, in a multi-user system, typically out of the control of any single user, and therefore are transparent to the user.  
  
Once the CryptFS space was limited to software solutions for multi-user systems, several other limiting criteria were developed.  To ensure that cost was not going to be a limitation in adoption, open source (“free”) solutions were reviewed.  To ensure that full support was not a limitation, purchased products providing full support were also reviewed.  Ultimately, three systems were chosen: CFS, TCFS and Network Appliances’ DataForte.  CFS and  TCFS where chosen for two main reasons: there is readily-available research material for them, and they are open-source projects where the software distributions are easily accessible and freely available for use.  Conversely, Network Applicance’s DataForte is a commercial system capable of being used as all, or a component of, an end-to-end solution for users willing to pay for such a system.
+
Once the CryptFS space was limited to software solutions for multi-user systems, several other limiting criteria were developed.  To ensure that cost was not going to be a limitation in adoption, open source (“free”) solutions were reviewed.  To ensure that full support was not a limitation, purchased products providing full support were also reviewed.  Ultimately, three systems were chosen: CFS, TCFS and Network Appliances’ DataForte.  CFS and  TCFS where chosen for two main reasons: there is readily-available research material for them, and they are open-source projects where the software distributions are easily accessible and freely available for use.  Conversely, Network Applicance’s DataForte is a commercial system capable of being used as all, or a component of, an end-to-end solution for users willing to pay for such a system.
 +
 
 +
CFS
 +
 
 +
CFS is a CryptFS for the UNIX operating system.  It is viewed as “the first widely used cryptographic file system” (Wright, Martino & Zadok 2003).  Even though it was developed over ten years ago, the “attach” mechanism, described later, inspired NCryptfs, a recent cryptographic file system developed in the research community.  The authors of NCryptfs describe CFS as “a carefully designed portable cryptographic file system” that suffers from performance (Wright, Martino & Zadok 2003).
 +
 
 +
CFS <B> can be thought of as </B> <em>is  (it is not really a filter)</em> a filter  between the user’s host and the disk storage system.  CFS supports local disk storage and NFS for remote storage.  A user’s request to write file blocks are intercepted by CFS, which encrypts the data before sending it to the storage subsystem. Similarly, encrypted file blocks are decrypted by CFS as the blocks move from the storage subsystem to the user’s process space.  The encryption and decryption are performed entirely on the user’s host system, which CFS assumes to be trustworthy.  CFS runs in user mode.  CFS obviously uses the storage subsystem, but it is not integrated in to <B>into</B> the storage subsystem.
 +
 
 +
CFS uses a combination of DES modes to encrypt file blocks. CFS operates in either standard security mode or high security mode.  In standard mode,  the system is vulnerable to “identical block analysis”.  This means that, in standard mode, two identical blocks of cleartext will create identical cipher blocks.  Those attempting to “crack” the encryption can use this information when analyzing the encrypted data.  High security mode ensures that each block uses part of the previous block as the key, therefore guaranteeing that any two identical cleartext blocks will generate different cipher blocks.  Under high security mode, however, it is not possible to have different files with different group ownership in the same directory.  This is because CFS tries to store the initialization vector (IV ) for the DES encryption in the group id fields of the directory entry inode.  In addition, “there is a small risk of losing data if both the inode of a file and its group id changes” (Blaze 1993). Blaze (1993) gives a detailed description of the implementation of CFS.
 +
 +
In addition to encrypting user data, CFS also encrypts file names and path names.  Since the encrypted names are always longer than their plain text equivalents, CFS reduces by half the maximum path components and file name length.
 +
 
 +
Key Management in CFS:
 +
 
 +
CFS does not have one key for the entire disk system, as do many hardware-based encryption solutions.  In CFS, there are many keys.  A single key is used to secure one group of files and directories.  Users may create new groups of files, and new encryption keys, whenever needed. Keys are constructed from a pass phrase supplied by the user.
 +
 
 +
To allow data to be retrieved when the corresponding key pass phrase is lost, or when the key holder is unavailable, CFS uses a smartcard-based key escrow system.  Blaze (1994) describes the details of this system. Essentially when a key is created, it is entered into a smart card.  The combination of the smart card and a separate pass phrase, allows the smart card to be used to decrypt data.  Use of the smart card can be audited, so that the owner of the key can detect if the smart card has been used to decrypt files. By using a smart card key escrow system, CFS avoids problems inherent to a centralized key escrow system and to the possibility that data could be “lost” if an employee leaves abruptly.
 +
 
 +
Security offered by CFS:
 +
 
 +
CFS provides encryption of data and some metadata such as directory information.  User do not have to trust the storage system or the communication network between the local host and the storage system, because all data is encrypted before it is visible to both the network system and the storage system.  However, a user must be able to trust the local host system and all the other users on the system, because the data is unencrypted on the host.  CFS is therefore susceptible to attacks that examine memory and swap space, because the decrypted form of the file may be viewed there. CFS can therefore be at best as secure as the local host system.
 +
 
 +
While CFS does encrypt the contents of each file, and the path names of the files, some metadata about the file are stored in the directory entries and are not hidden.  For example, the creation date of a file is exposed in cleartext and is the actual creation date for the file.
 +
 
 +
In the CFS model, each group of users wishing to share files would need to have a separate directory for that group, since the group of files is the atomic unit in CFS.  The key generated covers all files in the group, and no other files.  Since integrity of the data is largely dependent upon the key for the group remaining within the group, there is a real risk of the key “leaking” out from the group as the number of members in the group grows.  One careless user leaking the key can compromise the secret, and therefore the data, shared by many.
 +
 
 +
End-User Ease of Use in CFS:
 +
 
 +
CFS is not transparent to end users.  There are some changes in the file system managed by CFS that are not immediately obvious just by using CFS.  For example, the reduction in the maximum file name length is not something that is “shown” anywhere.  Also, the restriction that all files within a directory must have the same group ownership is a deviation from the UNIX standard that is not visible.  Applications that rely on standard UNIX features not supported in CFS can be adversely affected.
 +
 
 +
Aside from these minor differences, users must learn 3 new commands: cmkdir, cattach, and cdetach.  The cmkdir command creates a directory, or a root, of a hierarchy of files and directories that will be encrypted under the same key.  The key is produced using a pass phrase entered by the user.  The  cattach command associates an encrypted directory with a “virtual directory” containing the decrypted data.  A user running cattach must produce the same pass phrase used in the cmkdir command to form the association.  This virtual directory is never written to the file system.  It resides in the host system only. A user access data by references the virtual directory.  To remove the association, the cdetach command is used.
 +
 
 +
Learning three new commands, and the concept of using a virtual directory, does not appear to be a hurdle for most UNIX users.  The mapping of a virtual decrypted file to an encrypted file can at times be confusing, and does require the user to adjust to the changes. Tracking pass phrases, one for each group with whom each user shares files can be cumbersome.  In addition there are pass phrases associated with the key escrow system. Users have to manage a number of pass phrases in addition to their log on password.
 +
 
 +
The smart card based key escrow system requires a smart card reader and writer whenever the cmkdir command is used to create keys.  This requires an investment in additional hardware so that each user have the smart card reader/writer, or some centralized process be put in place.  This can be very inconvenient and time consuming, especially for users only occasionally creating new groups.
 +
 
 +
The CFS group hierarchy does not allow for sharing among subgroups. For example, group A has two subgroups B and C.  Users in group B should have accesses to files common to both B and C as well as files private to group B.  Similarly users in group C should have accesses to files common to both groups.  Many systems allow for an access control list to model this hierarchical structure.  CFS does not provide a way that supports this hierarchical structure, which is common in many work activities. The structure can perhaps be simulated (in the previous example, create a new group D for shared files between B and C) but this requires planning and thought into the hierarchy, causes more keys to be needed, and does not flow around changes in “real world” work groups which tend to be very fluid.
 +
 
 +
Administrator Ease of Use in CFS:
 +
 
 +
As CFS uses the native file system for storing encrypted data, there are no additional requirements for administration of a CFS system.  Backups, restores, and failure recovery are all the same as they would be for native systems.  The only difference is that the administrator cannot view the data directly.  One of the original design goals of CFS was compatibility with underlying system services.  Encrypted files and directories are managed just like any other files and directories (Blaze 1993).  CFS introduces two additional administration commands allowing the administrator to retrieve encrypted files in clear text for a user if CFS fails. These commands require the encryption key, but they do not require CFS to be running.
 +
 
 +
CFS is unsupported, “open source” software.  There is only source code distribution of CFS.  Each system administration will need to set up the CFS makefile and configuration.  The instructions for  installing CFS states: “Make sure you're running NFS with SunOS or BSD.  Good luck if you have something else.”  A system administrator charged with high level of security and reliability may not choose CFS because of its lack of support. The administrator may also need to define processes for smartcard reader/writer usage, storage, backup, disaster recovery, etc., if these processes do not already exist. 
 +
 
 +
Cost for CFS:
 +
 
 +
As CFS is provided as “open source” software, the CFS source code is free.  However, there is cost involved with the smart card escrow system. At least one smart card reader and writer is required, perhaps along with a smart card programming kit. In addition, for each key, there is a least one smart card.  Disaster recovery processes may require a duplicate card, and off-site storage space for the duplicates.  The cost of each smart card, with about 30KB of memory, ranges around $23 US. A smart card reader can cost over $100 US.  Development kits for smart cards can cost a few hundred US dollars.  The cost of running CFS is not prohibitive and yet not negligible; especially if many smart card readers and writers are required.
 +
 
 +
Performance:
 +
 
 +
CFS can be several times slower than a system without encryption on a local file system,  For example, copying a large file while fifty reads on that file take place takes four seconds on a local file system without CFS.  The same activity with CFS takes 27 seconds.  The same activity with a user-level tool encryption process takes 5,348 seconds (Blaze 1993).  While CFS does outperform a user-managed encryption, the overhead is still very noticeable by end users when compared to a system without encryption. In fact, one of the drawbacks of CFS is the performance its performance overhead (Wright, Martino & Zadok 2003). Both Blaze (1993) and Wright, Martino & Zadok (2003) provide more performance comparison results for CFS.
 +
 
 +
Conclusion for CFS:
 +
CFS is a research system that brings encryption to the file system level, thereby solving many problems inherent with encryption at the user or application level.  It also provides for sharing of files within groups. However, its lack of support and its reliance on a trusted local host precludes it from commercial use where security is  of utmost importance. In addition, it may be difficult to gain user acceptance because of the additional work required of the users to track all the needed pass phrases. The requirement for smart card reader and writer to create an encrypted directory may also key factor to public acceptance, since this is not yet widely available hardware.
 +
 
 +
 
 +
List of References
 +
 
 +
Blaze, Matt 1993, ‘A Cryptographic File System for Unix’, Proceedings of the First ACM Conference on Computer and Communications Security, ACM, Fairfax, VA.
 +
 
 +
Blaze, Matt 1994, ’Key Management in an Encrypting File System’, USENIX Summer 1994 Technical Conference, USENIX, Boston, MA.
 +
 
 +
Briney, Andy 1998, ‘1998 Annual Industry Survey’, Information Security, vol. 1, no. 6, pp. 27-34.
 +
 
 +
PriceWaterhouseCoopers 2004, ‘Information Security Breaches Survey’, PDF file, viewed 15 Nov 2005, < http://www.infosec.co.uk/files/DTI_Survey_Report.pdf>
 +
 
 +
Robb, Drew 2004, ‘Corporate Data Leaks Spur Interest in Storage Security’, viewed 10 Nov 2005, <http://www.internetnews.com/storage/article.php/3499266>
 +
 
 +
Wright, Charles, Martino, Michael, Zadok, Erez 2003, ‘NCryptfs: A Secure and Convenient Cryptographic File System’, USENIX 2003 Annual Technical Conference, USENIX, Stony Brook University.

Revision as of 21:14, 18 November 2005

The danger in using a wiki as a collaboration tool is that other people will edit it.

Information on cryptographic file system was moved to File Systems#Cryptographic File Systems


Vendor's product overview:

Seagate FDE: http://www.seagate.com/docs/pdf/marketing/PO-Momentus-FDE.pdf

Network Appliance: http://www.netapp.com/ftp/decru-fileshredding.pdf

NetApps DataFort: http://www.decru.com/products/pdf/dsEseries.pdf

Decru Lifetime Key Management: http://www.decru.com/products/ltkm.htm

Decru Whitepaper: http://www.forensicswiki.org/images/6/6f/Securing_Storage_White_Paper.pdf

Price for Decru DataFort E510 1.6 for NAS: http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss346_art680,00.html

DecruDataFort E440: http://www.computerworld.com/hardwaretopics/storage/story/0,10801,78766,00.html

Lenageraghty 22:08, 7 November 2005 (EST)

SAM Useful TCFS site:

Transparent CryptoGraphical file system: http://www.tcfs.it/index.php?pc=2

TCFS intro: http://www.linuxjournal.com/article/2174

--Samlam 19:56, 13 November 2005 (EST)

ERIC Seagate new offerings:

Full Disk Encryption: http://www.eweek.com/article2/0,1759,1825740,00.asp

Seagate product specification: http://www.seagate.com/content/docs/pdf/marketing/PO-Momentus-FDE.pdf


Samlam 12:10, 13 November 2005 (EST)

Cryptographcial File Systems:

File Systems#Cryptographic File Systems Readings on crytographical file systems.

Some Notes from Sam

"What is your prognosis for cryptographic file systems?" is a question we have to answer from this project (see project outline). It is important we address that.



Some Questions / Notes from BJ

I added to the existing outline below. We only get 15 pages max, so we might have to limit ourselves to 2 pages (3 tops) per EFS, so there might be too many items for each EFS listed, but I think it would be good for us to be consistent and have the same items in each EFS.

I think we should start filling out what we can in the outline during this week, so that we can "refine as we go".

Please make sure and add your citations, also. Do not worry about format; we will do that later; but make sure all the information is there.

Suggestion of outline :

  • Introduction (BJ)
    • Definition of an Encrypting File System
    • Purpose/Goal of an EFS
      • Purpose: to add an additional layer of security, controlled by the user, over that user's data
      • Goal: to allow users to feel confident the data placed in the EFS cannot be compromised.
    • Overview of General Workings
      • (description of common functionality and common processes to all or most EFS)
      • You have data in memory, you want to save it to disk, you only want "authorized" people to see it; not even system administrators and/or backup operators
      • You control access by "owning" the key
      • Key is generated (somehow)
      • There is overhead in the process of encrypting/decrypting (unavoidable)
    • Overview of Common Usage
      • Maybe some categories of users and what they are looking for:
      • "business critical applications" like databases, etc. where business relies on data being available and secure
      • "business users" like managers who want to secure employee reviews, HR people wanting to secure salary information, etc.
      • "casual users" people who just want to make sure their data is secure.
    • The currently available systems (market share?)
    • Why we choose CFS TCFS and Network Applicances
  • Study of 4 systems in depth, including why this system is selected for study.
    • CFS (LENA)
      • Overview
        • When Developed
        • Platform(s)
        • Current Version
      • Key Management
      • Ease of Use for End Users
      • Legal Issues
      • Failure Modes
      • Challenges in Installation/Use by System Administrator
      • Performance
      • Cost
      • Conclusion (?? what would that be??)
    • TCFS (SAM)
      • Overview
        • When Developed
        • Platform(s)
        • Current Version
      • Key Management
      • Ease of Use for End Users
      • Legal Issues
      • Failure Modes
      • Challenges in Installation/Use by System Administrator
      • Performance
      • Cost
      • Conclusion (?? what would that be??)
    • Network Appliance DataForte and Seagate (ERIC)
      • Overview
        • When Developed
        • Platform(s)
        • Current Version
      • Key Management
      • Ease of Use for End Users
      • Legal Issues
      • Failure Modes
      • Challenges in Installation/Use by System Administrator
      • Performance
      • Cost
      • Conclusion (?? what would that be??)
    • Windows EFS (BJ)
      • Overview
        • When Developed
        • Platform(s)
        • Current Version
      • Key Management
      • Ease of Use for End Users
      • Legal Issues
      • Failure Modes
      • Challenges in Installation/Use by System Administrator
      • Performance
      • Cost
      • Conclusion (?? what would that be??)
  • Compare the following:
    • Plausibility
    • Usability
    • Cost
  • Common Issues/Problems (ALL)
    • Impact on computer forensics
    • Impact on end-users (i.e. what if you are away on a business trip and you have to go to the hospital and all of your files are encrypted on your laptop?) (or even worse, what if you die and all your financial information is encrypted?)
    • Impact on business owners (e.g. what if an employee quits and all that person's data files, contact info, etc. are encrypted)
  • Future (ALL)
    • What would be useful to add or remove
    • How we would accomplish the changes we suggest
  • Conclusion. (ALL)

--Samlam 08:06, 17 November 2005 (EST)

Bjl170 20:23, 14 November 2005 (EST)

Lenageraghty 08:36, 11 November 2005 (EST)


some thoughts/comments on the updated outline
  • We are examining 3 cyptographical file system - why do we choose the 3 we choose ?
    • Freeware is popular CFS, TCFS is free.
    • CFS is quite often referenced. It is one of the early most widely used system.
    • Net Applicance is a commercial system. Possibly an end-to-end solution (?)
    • Scope of this project: multi-user file systems, as oppose to a single disk drive system.
    • What are some of the existing system ?


  • Betty, it was previously agreed that there are 3 EFS. Sam prefers 3 EFS to 4.
    • Is there any reason why you choose Windows ? I will write up why we choose the 3 that I know of. I am not sure why Windows. I probably write up a snippet for the 3, and you can add the reason for choosing Windows.
  • In response to :"There is overhead in the process of encrypting/decrypting (unavoidable) ", there are hardward disk systems that does it in the hardward. Seagate FDE. But I think that the 3 systems that was mentioned earlier are multi-user systems. I was just about to add to the introduction that we limit our scope to multi-user systems.
  • The bullet on "Common Issues/Problems " is probably redundant. I am not entirely sure. We shall see.
    • Perhaps it is just me, but I somehow feel that it is obvious that it makes disk forensics harder. Do we need to add more to that ? As far as the other questions go, probably the key management system would probably have addressed those problems. I am writing on CFS. It is a 10 year old system, and it already addresses those problems. I have a feeling that TCFS and DataForte/DeCru already solve these problems as well - perhaps just a matter of how covenient it is to use those.
  • A question ? Are there database software running on encrypted file systems ? I actually don't know of anyone using encrypted file system. I know of many people running databases. Just out of curiosity, are there anyone running databases on encrypted file system ? Or do people generally encrypt the fields they want to protect.


Lenageraghty 23:32, 14 November 2005 (EST)

Questions :

  • What systems are currently available ?

Lenageraghty 08:48, 11 November 2005 (EST)

Suggestions/Questions/Outline ?:

  • Solutions from other storage vendors.
  • Desirable features for a cryptographical file system.
  • cost
    • performance
    • total solution for end-users
    • Key management for cryptographical file system
    • Ease of use by end-users
    • Failure modes
    • Challenges in using/installing

Lenageraghty 22:48, 7 November 2005 (EST)

comment from TA (Joe)

That looks like some of the right inroads. Remember that the paper is not very long, so you may want to focus on the three systems and do a deep analysis. Certainly some things to think about:

      Simson's lecture where he talked about it
      Failure modes of such systems
      Challenges in using/installing

comment from teacher: Please remember that this Wiki is publically accessible on the Internet. It's great if you can improve the resource for everbody. But do try to do that, rather than just creating your own space...

Uploads / Partial drafts of writeup

File:HelixCFS.doc Lena's writeup on CFS

Devaition from outline:

  • Did not mention current release, which is not really relevant. (It is 1.4.1 if anyone is interested)
  • Describe the security provided by CFS.
  • No legal issue.
  • Not sure what is meant by failure mode: I assume lost of key ? In any case, we can use backup/restore. Failure is generally taken care of by the system administrator, so failure mode is part of "ease of user" for the system administrator in my draft. But may be at this point it is too early to decide.


Lenageraghty 23:35, 14 November 2005 (EST)


File:Init.doc Lena's snippet to be integrated into introduction (3 EFS)

File:Init2.doc Lena's snippet to be integrated into introduction (4 EFS)

File:Biblio.doc Start of a biblio.


Lenageraghty 01:08, 16 November 2005 (EST)

Initial concluding thoughts

  • Administrators / CSO charged with the operation of high security environments probably don't want to use unsupported software even if they are free. CFS is free but not supported.
  • It is uncommon to run databases on top of cryptographical file systems. Many sensitive information such as payroll/HR are stored in relational databases. Sensitive fields can be encrypted before storing into the databases. For high volume transactions such as stock trading etc, performance is important. People probably rely on auditing in attain security rather than use cyptographical file system to do so.
  • Whether Cryptographical File system will become popular depends on many factors.
    • Are there real inherent problems to Cyptographical File system ? My feeling is that if there are any deficiencies, they'll all be addressed overtime. There will always be faster hardware, better algorithm. There are already commercial systems available (e.g. DataForte)
    • Are there pressures from government or businesses that push for commercial adoption of cryptographical file system regardless of cost. (Someone in livejournal mentions that he sees more pressure nowadays.) Also, I saw something indications that government may use Seagate's FDE. (See quotes below : Seagate ‘Drives’ Notebook Encryption). Searching on the internet for full disk encryption products, there are plenty. I think that there has to be a push for disk encryption on notebook and laptops.
    • High performance and highly reliable database systems are very expensive. However enterprises and businesses pay for them because the Service Level Agreements and expectations are met by the vendors. The enterprises and businesses have a *need* for these data to be processed by the database. Is there a real *need* for cryptographical file systems. Are there other combinations that forms a viable solutions without the need for cryptographical file system. For example, if the data are protected in data centers qualified for a certain security level, would that be an acceptable solution in lieu of cryptographical file system? Where best should a CSO / head or IT spend his resources to attain the level of security required.
    • Will there be heightened security demands for individuals. Even though notebook encryption disk drive for notebook computers are more expensive than ordinary non-encryption drive, if the price is within an affordable range, users will accept the higher price for security. (FDE is $100USD for the drive) Usually for personal items, higher volume of sales implies lower price. The entry barrier will be lowered as there is more demand. Like many electronic devices such as calculator, price comes down over time.

Lenageraghty 21:57, 16 November 2005 (EST)

Harvard Style

I found something on Harvard citation style (googling)

http://www.library.uq.edu.au/training/citation/harvard_6.pdf


Some quotes on news on Seagate : Nov. 17, 2005

Seagate ‘Drives’ Notebook Encryption Seagate Technology, a Scotts Valley, CA-based hard disc drive manufacturer, has developed hardware-based full disc encryption (FDE) for notebook PCs, a technology that could be attractive to government users. Company officials said its Momentus 5400 FDE 2.5-inch hard drive provides protection against unauthorized access to data on stolen or retired notebook PCs.

“We anticipate the earliest of the adopters to be in government and commercial spaces,” said Mark Pastor, Seagate’s director of strategic marketing. “It’s a very user-friendly, comprehensive approach to encrypting data on the hard drive.”

Rather than use software and make a conscious effort to protect specific data, FDE technology requires only a user key to encrypt all data on the drive, he said. The encryption functions, including the password or user key, are performed on the drive, not the operating system, providing additional security from hackers. If the notebook is disposed of or repurposed, the key that is used for encrypting the data would be removed.

“Deleting the key effectively removes the chance that data would then be readable by anybody,” Pastor said.

Seagate began putting the FDE in notebooks first because there use is growing and because their portability makes them vulnerable to loss or theft. But Pastor said Seagate also sees a need for hardware-based FDE in desktop and handheld device environments.

Seagate expects the first Momentus 5400 FDE hard drives to start shipping early next year. In the meantime, it is working with vendors to further develop the product for their needs. Lee, MA-based Wave Systems and Utimaco Safeware AG, of Oberusel, Germany, have announced they are incorporating the FDE hard drives in their products.

Quoted from http://www.gsnmagazine.com/oct_05_02/high_speed.html (Online, Nov 13)

Draft: This Is About 4 1/2 Pages

Introduction

As multi-user, networked computing systems become more prevalent, the problem of protecting sensitive data from unauthorized disclosure and tampering becomes increasingly important. In 1998, Information Security magazine’s annual survey of security breaches concluded that 54% of all reported security incidents involved unauthorized access by employees. Only 12% of the reported incidents involved a security breach by an outsider (Briney, 1998) In 2004, a similar study indicated that in the UK, 51% of reported security incidents involved insiders (PriceWaterhouseCoopers, 2004).

Since Cryptographic File Systems (CryptFS) ensure data integrity and security without requiring user interaction to explicitly encrypt and decrypt the data, it would seem obvious that companies would implement a CryptFS on all systems, and yet they are not. According to a recent Enterprise Strategy Group survey, less than seven percent of stored backups are encrypted , and less than seven percent of data is encrypted “at rest” (on disk) (Robb 2004).

This paper describes the Cryptographic File System and the CryptFS “space”, analyzes three Cryptographic File Systems in detail, and then describes why encrypting files on disk is not more common. Then, a process whereby the adoption rate in business of CryptFS will increase is presented.

Definition of a Cryptographic File System

A Cryptographic File System is a file system which stores and retrieves all data from the disk in encrypted form, and encrypts/decrypts the data within the address space of the requesting process. Since the data is stored in encrypted form on the disk, all copies of the data, including backups, are ensured to be encrypted also. The purpose of such a file system is to add an additional layer of security, controlled by the user, over that user's data. This is accomplished by making the user storing data be responsible for managing the cryptographic keys with which the data will be encrypted and decrypted. The goal of a CryptFS is to allow the users storing data to feel confident that the data placed in the CryptFS cannot be compromised, and that access to the “cleartext” (unencrypted) data is controlled by the user through controlling access to the cryptographic keys.

{ this probably needs some more } {key management – how they are generated [one for system, one per user, etc]. how to recover if key lost, what if employee leaves, etc.} Key management is probably the most important feature to consider when evaluating CryptFS implementations.

Review of the Literature

An initial survey of the current Cryptographic File Systems commonly in use today reveals that there are both hardware- and software-based systems. These implementations provide support for single- and multi-user situations. Single-user solutions were not considered as part of the CryptFS space, since by definition, the user is responsible for all facets of the system, including hardware installation, software installation, determining which files should be encrypted, etc. Hardware solutions were also not in the scope of the CryptFS space, as the implementation and cryptographic key management of hardware solutions are, in a multi-user system, typically out of the control of any single user, and therefore are transparent to the user.

Once the CryptFS space was limited to software solutions for multi-user systems, several other limiting criteria were developed. To ensure that cost was not going to be a limitation in adoption, open source (“free”) solutions were reviewed. To ensure that full support was not a limitation, purchased products providing full support were also reviewed. Ultimately, three systems were chosen: CFS, TCFS and Network Appliances’ DataForte. CFS and TCFS where chosen for two main reasons: there is readily-available research material for them, and they are open-source projects where the software distributions are easily accessible and freely available for use. Conversely, Network Applicance’s DataForte is a commercial system capable of being used as all, or a component of, an end-to-end solution for users willing to pay for such a system.

CFS

CFS is a CryptFS for the UNIX operating system. It is viewed as “the first widely used cryptographic file system” (Wright, Martino & Zadok 2003). Even though it was developed over ten years ago, the “attach” mechanism, described later, inspired NCryptfs, a recent cryptographic file system developed in the research community. The authors of NCryptfs describe CFS as “a carefully designed portable cryptographic file system” that suffers from performance (Wright, Martino & Zadok 2003).

CFS can be thought of as is (it is not really a filter) a filter between the user’s host and the disk storage system. CFS supports local disk storage and NFS for remote storage. A user’s request to write file blocks are intercepted by CFS, which encrypts the data before sending it to the storage subsystem. Similarly, encrypted file blocks are decrypted by CFS as the blocks move from the storage subsystem to the user’s process space. The encryption and decryption are performed entirely on the user’s host system, which CFS assumes to be trustworthy. CFS runs in user mode. CFS obviously uses the storage subsystem, but it is not integrated in to into the storage subsystem.

CFS uses a combination of DES modes to encrypt file blocks. CFS operates in either standard security mode or high security mode. In standard mode, the system is vulnerable to “identical block analysis”. This means that, in standard mode, two identical blocks of cleartext will create identical cipher blocks. Those attempting to “crack” the encryption can use this information when analyzing the encrypted data. High security mode ensures that each block uses part of the previous block as the key, therefore guaranteeing that any two identical cleartext blocks will generate different cipher blocks. Under high security mode, however, it is not possible to have different files with different group ownership in the same directory. This is because CFS tries to store the initialization vector (IV ) for the DES encryption in the group id fields of the directory entry inode. In addition, “there is a small risk of losing data if both the inode of a file and its group id changes” (Blaze 1993). Blaze (1993) gives a detailed description of the implementation of CFS.

In addition to encrypting user data, CFS also encrypts file names and path names. Since the encrypted names are always longer than their plain text equivalents, CFS reduces by half the maximum path components and file name length.

Key Management in CFS:

CFS does not have one key for the entire disk system, as do many hardware-based encryption solutions. In CFS, there are many keys. A single key is used to secure one group of files and directories. Users may create new groups of files, and new encryption keys, whenever needed. Keys are constructed from a pass phrase supplied by the user.

To allow data to be retrieved when the corresponding key pass phrase is lost, or when the key holder is unavailable, CFS uses a smartcard-based key escrow system. Blaze (1994) describes the details of this system. Essentially when a key is created, it is entered into a smart card. The combination of the smart card and a separate pass phrase, allows the smart card to be used to decrypt data. Use of the smart card can be audited, so that the owner of the key can detect if the smart card has been used to decrypt files. By using a smart card key escrow system, CFS avoids problems inherent to a centralized key escrow system and to the possibility that data could be “lost” if an employee leaves abruptly.

Security offered by CFS:

CFS provides encryption of data and some metadata such as directory information. User do not have to trust the storage system or the communication network between the local host and the storage system, because all data is encrypted before it is visible to both the network system and the storage system. However, a user must be able to trust the local host system and all the other users on the system, because the data is unencrypted on the host. CFS is therefore susceptible to attacks that examine memory and swap space, because the decrypted form of the file may be viewed there. CFS can therefore be at best as secure as the local host system.

While CFS does encrypt the contents of each file, and the path names of the files, some metadata about the file are stored in the directory entries and are not hidden. For example, the creation date of a file is exposed in cleartext and is the actual creation date for the file.

In the CFS model, each group of users wishing to share files would need to have a separate directory for that group, since the group of files is the atomic unit in CFS. The key generated covers all files in the group, and no other files. Since integrity of the data is largely dependent upon the key for the group remaining within the group, there is a real risk of the key “leaking” out from the group as the number of members in the group grows. One careless user leaking the key can compromise the secret, and therefore the data, shared by many.

End-User Ease of Use in CFS:

CFS is not transparent to end users. There are some changes in the file system managed by CFS that are not immediately obvious just by using CFS. For example, the reduction in the maximum file name length is not something that is “shown” anywhere. Also, the restriction that all files within a directory must have the same group ownership is a deviation from the UNIX standard that is not visible. Applications that rely on standard UNIX features not supported in CFS can be adversely affected.

Aside from these minor differences, users must learn 3 new commands: cmkdir, cattach, and cdetach. The cmkdir command creates a directory, or a root, of a hierarchy of files and directories that will be encrypted under the same key. The key is produced using a pass phrase entered by the user. The cattach command associates an encrypted directory with a “virtual directory” containing the decrypted data. A user running cattach must produce the same pass phrase used in the cmkdir command to form the association. This virtual directory is never written to the file system. It resides in the host system only. A user access data by references the virtual directory. To remove the association, the cdetach command is used.

Learning three new commands, and the concept of using a virtual directory, does not appear to be a hurdle for most UNIX users. The mapping of a virtual decrypted file to an encrypted file can at times be confusing, and does require the user to adjust to the changes. Tracking pass phrases, one for each group with whom each user shares files can be cumbersome. In addition there are pass phrases associated with the key escrow system. Users have to manage a number of pass phrases in addition to their log on password.

The smart card based key escrow system requires a smart card reader and writer whenever the cmkdir command is used to create keys. This requires an investment in additional hardware so that each user have the smart card reader/writer, or some centralized process be put in place. This can be very inconvenient and time consuming, especially for users only occasionally creating new groups.

The CFS group hierarchy does not allow for sharing among subgroups. For example, group A has two subgroups B and C. Users in group B should have accesses to files common to both B and C as well as files private to group B. Similarly users in group C should have accesses to files common to both groups. Many systems allow for an access control list to model this hierarchical structure. CFS does not provide a way that supports this hierarchical structure, which is common in many work activities. The structure can perhaps be simulated (in the previous example, create a new group D for shared files between B and C) but this requires planning and thought into the hierarchy, causes more keys to be needed, and does not flow around changes in “real world” work groups which tend to be very fluid.

Administrator Ease of Use in CFS:

As CFS uses the native file system for storing encrypted data, there are no additional requirements for administration of a CFS system. Backups, restores, and failure recovery are all the same as they would be for native systems. The only difference is that the administrator cannot view the data directly. One of the original design goals of CFS was compatibility with underlying system services. Encrypted files and directories are managed just like any other files and directories (Blaze 1993). CFS introduces two additional administration commands allowing the administrator to retrieve encrypted files in clear text for a user if CFS fails. These commands require the encryption key, but they do not require CFS to be running.

CFS is unsupported, “open source” software. There is only source code distribution of CFS. Each system administration will need to set up the CFS makefile and configuration. The instructions for installing CFS states: “Make sure you're running NFS with SunOS or BSD. Good luck if you have something else.” A system administrator charged with high level of security and reliability may not choose CFS because of its lack of support. The administrator may also need to define processes for smartcard reader/writer usage, storage, backup, disaster recovery, etc., if these processes do not already exist.

Cost for CFS:

As CFS is provided as “open source” software, the CFS source code is free. However, there is cost involved with the smart card escrow system. At least one smart card reader and writer is required, perhaps along with a smart card programming kit. In addition, for each key, there is a least one smart card. Disaster recovery processes may require a duplicate card, and off-site storage space for the duplicates. The cost of each smart card, with about 30KB of memory, ranges around $23 US. A smart card reader can cost over $100 US. Development kits for smart cards can cost a few hundred US dollars. The cost of running CFS is not prohibitive and yet not negligible; especially if many smart card readers and writers are required.

Performance:

CFS can be several times slower than a system without encryption on a local file system, For example, copying a large file while fifty reads on that file take place takes four seconds on a local file system without CFS. The same activity with CFS takes 27 seconds. The same activity with a user-level tool encryption process takes 5,348 seconds (Blaze 1993). While CFS does outperform a user-managed encryption, the overhead is still very noticeable by end users when compared to a system without encryption. In fact, one of the drawbacks of CFS is the performance its performance overhead (Wright, Martino & Zadok 2003). Both Blaze (1993) and Wright, Martino & Zadok (2003) provide more performance comparison results for CFS.

Conclusion for CFS: CFS is a research system that brings encryption to the file system level, thereby solving many problems inherent with encryption at the user or application level. It also provides for sharing of files within groups. However, its lack of support and its reliance on a trusted local host precludes it from commercial use where security is of utmost importance. In addition, it may be difficult to gain user acceptance because of the additional work required of the users to track all the needed pass phrases. The requirement for smart card reader and writer to create an encrypted directory may also key factor to public acceptance, since this is not yet widely available hardware.


List of References

Blaze, Matt 1993, ‘A Cryptographic File System for Unix’, Proceedings of the First ACM Conference on Computer and Communications Security, ACM, Fairfax, VA.

Blaze, Matt 1994, ’Key Management in an Encrypting File System’, USENIX Summer 1994 Technical Conference, USENIX, Boston, MA.

Briney, Andy 1998, ‘1998 Annual Industry Survey’, Information Security, vol. 1, no. 6, pp. 27-34.

PriceWaterhouseCoopers 2004, ‘Information Security Breaches Survey’, PDF file, viewed 15 Nov 2005, < http://www.infosec.co.uk/files/DTI_Survey_Report.pdf>

Robb, Drew 2004, ‘Corporate Data Leaks Spur Interest in Storage Security’, viewed 10 Nov 2005, <http://www.internetnews.com/storage/article.php/3499266>

Wright, Charles, Martino, Michael, Zadok, Erez 2003, ‘NCryptfs: A Secure and Convenient Cryptographic File System’, USENIX 2003 Annual Technical Conference, USENIX, Stony Brook University.