|
<<"D A Goodwin (My Dad!)'s Painting Gallery" [Main Index] "Biking and My NeverLost">> File System Security Policy07 April 2003
This article provides a brief overview of the fundamentals of file system security and the usual methods of implementation. It then studies in depth the extra strengths provided by encryption methods and how these should be implemented. Microsoft's Encrypting File System is studied as a useful example of what problems operating system level encryption solves and what weaknesses are left open.
File System ImplementationThe problem with having a centralised matrix is that it takes up a lot of space and most of the cells will be empty (Indicating no privileges on that object by that domain.) The efficient way to store it is to cut it into rows and store each row with its domain or to cut it into columns and store each column with its associated object. Storing a list of permissions with an object is known as an access control list (ACL). This is the most common form of access control and is used in OS such as Windows NT and UNIX. In Windows each object has a variable length list of domains attached to it and the permissions associated with those domains. A typical example for a file might be:File1.doc goodwin: Total control user2: read, write promo01: Read, Execute Everyone: Read. As you can see this allows for very complex and specific permissions. This can be both an advantage and a draw back. It is an advantage as arbitrarily complex policies can be implemented. Unfortunately it also makes it harder to see if your policy contains any gaps. UNIX uses a simplified ACL relying on 9 access bits. These bits are divided up to indicate Read/Write/eXecute permissions for user, group and everyone else. A typical file might have the following access rights. File1.txt rwxr-x--- This would indicate read, write and execute permissions for the owner, read and execute for the group and no permissions for everyone else. All though this system is less flexible than Windows' ACL implementation it is generally sufficient and easier to verify. The second manner of implementing the policy defined in a security matrix is to split it into rows and keep the information stored along with other domain information. In this way each user can immediately see which objects they have access to. These lists of permissions are known as capabilities. Capabilities are lists of pointers to objects along with the permissions the user has on the object. The capability has to be protected from user tampering with two common methods being to keep it stored in the OS’s memory space or to have it encrypted by the OS’s public key. This mechanism is useful in distributed systems where by the user can present a capability obtained from one system as proof of access right to another. Kerberos, the distributed authentication system, uses this in the form of tickets. The main difficulty with capabilities is that they are hard to revoke. The OS has to check every domain to see who has access to the object. To help alleviate this problem systems can have the capability point to an intermediate node which points to the real object. Then by making the intermediate node point to a null object, you can effectively remove the rights assigned by that capability. However, this doesn't allow selective revocation. eg/ removing user1's permissions but not user2's. The above two systems are secure as long as one can rely on the OS to differentiate between different users (domains) and enforce its policies. However this is not always the case and can lead to a false sense of security. Common attacks to gain access to files usually involve convincing the operating system that you are somebody else or by bypassing the file system altogether. Fooling the OS into believing you are someone else is typically done by stealing a user's password. This can be done by dictionary attacks against the OS password file, intelligent guess-work or by watching the user type in his password (shoulder surfing). The second method involves bypassing the OS by booting into another operating system. For example, booting LINUX off a floppy disk or booting from another compromised machine over the network. From the second operating system, in which you have full administrator privileges, you can read the files that interest you. Encrypting File SystemsOne possible solution to this problem is the use of encryption software. Encryption relies on scrambling data so that it is very computationally intensive to unscramble it if you do not know the key. In this way even if an attacker bypasses the usual security mechanisms the data is in an undecipherable form. For a while now there have been many third party security products available to encrypt user documents. However, these have a number of weaknesses which could be solved by an OS based scheme. Often the user has to manually encrypt and decrypt the file before and after use. This is extra work for the user and there is always the possibility that they will forget to re-encrypt and leave the file readable after use.Secondly many applications create temporary files while the user is working and these will not be encrypted and are often left behind after the user has finished working. In addition there is the possibility that the user's keys will be swapped out of memory and into a paging file during use. This means that others could mine the paging file after the user has finished working in the hope of finding passwords. Finally the encryption keys are often derived from a password which makes it vulnerable to all the usual password guessing attacks. On another level there is often no recovery mechanism, meaning that if someone leaves a company or looses their keys then the data is lost forever. This is of particular concern in a corporate environment. Microsoft has proposed its Encrypting File System (EFS) as a solution to the above problems. EFS sits above NTFS in the OS kernel and provides transparent file encryption and decryption. It automatically generates symmetric keys to encrypt the files when they are created and ensures that they are encrypted when they are saved. It also has an obligatory key recovery policy to ensure that files can be recovered if the originals are lost. EFS resides in the kernel's non-swapable memory pool and so ensures that it is never ends up in the page file. At this stage very few programs are 'encryption aware.'To get round the problem of unencrypted temp files the current version of EFS only allows the creation of encrypting directories from the GUI. Whatever is placed in these directories is automatically encrypted. Thus temporary files will be created along side the original file in an encrypted space. It is also recommended that the Windows temp directory is encrypted. From the command line or API users are able to encrypt individual files or to mark that the entire contents of a directory should be encrypted. In either case every file has its own individual encryption key. EFS works by generating a random symmetric key when the file is created and then using this key to encrypt the file. This is known as the File Encryption Key (FEK). As this is a randomly generated string, it is practically impervious to password guessing attacks. Two copies are then made of this key. One is encrypted with the user's public key from their X.509 certificate and stored as a file attribute known as the data decryption field (DDF). The second copy is encrypted with the recovery agent's public key and also stored as a file attribute known as the data recovery field (DRF).  This method allows users to share files by simply maintaining a list of the same FEK encrypted with different user's public keys in the data decryption field. It also allows the recovery agents to recover files without revealing any information about the user or compromising their private key. To decrypt a file the above process is simply run in reverse. A user presents their private key and this is used to decrypt the FEK. Then the FEK can decrypt the file. The private portion of the users key should be stored elsewhere, for example in smart cards, otherwise the system is open to the same password guessing attacks as before. (The attacker could break the user’s password to decode their private key which decodes the FEKs which decodes the file.) EFS resides on top of NTFS and is part of the security sub-system of Windows. When calls to the OS are made to read and write data EFS en/decrypts files block at a time. This helps ensure lower computational overheads by only en/decrypting the portions of the file which are actually being read. EFS uses a symmetric encryption algorithm as this too is less computationally intensive than an asymmetric one. Policy in MS EFSEncryption policy can be decided at three levels:
set by a company administrator overrides any policy set by a local user. This is important as it ensures the policy is coherent within an organisation and that the administrator can maintain one recovery agent for the whole organisation. If a recovery agent's certificate has expired or is not available then EFS refuses to encrypt new files. This prevents users from creating unrecoverable files. Each time a file is opened EFS checks that the file recovery information is up to date. If the recovery agent's certificate has changed since the last time the file was opened then the data recovery field is updated to reflect this change. This update can only be performed at this time as it is the only time when there is a decrypted copy of the FEK for the recovery agent to encrypt. Recovery agents' private keys should never be discarded as files which have not been used will continue to have FEKs encrypted by the old recovery agents. This could be a potential problem over a long period of time as the number of expired recovery certificates grows it will be harder to know which one to use when you wish to recover an old file that hasn't been used for many years. The recovery keys should be kept in a safe offline location to prevent abuse. Attacks against EFS where administrators have left the recovery keys on the system have been highlighted and are discussed later on. One obvious need is to back up encrypted data without the encryption keys. EFS allows this with calls to its API functions OpenRaw(), ReadRaw(), WriteRaw() and CloseRaw(). These allow encrypted data to be read directly from the file system. Usually if a user tries to access a file to which they don't have the decryption keys they get a simple 'Access Denied' message. WeaknessesDespite its strengths EFS is not a panacea, nor was it designed to be. By itself it only protects local NTFS volumes. Encrypted data read from remote volumes is decrypted before it is transmitted thus leaving it open to sniffing based attacks. Also EFS is only designed to encrypt user files. As the EFS system doesn't start until the OS is fully up and running, encrypting system files has the disastrous effect of making the computer unbootable.EFS has been designed to use plug in encryption modules allowing the algorithms used to be upgraded as better ones become available. Unfortunately due to export regulations the only currently available encryption is DES with a 40 bit key. This level of encryption has been proven time and again insufficient for serious security needs. (56 bit DES encryption can be broken in under a day by a committed adversary.) Clearly this it is not worth the time and trouble of implementing EFS if the encryption provided is easily breakable. As with all security systems people are looking for weaknesses in its implementation and configuration. One possible problem which has come to light is that if the recovery keys are left on a PC, which is the default setting for a stand alone machine, then it is vulnerable to OS bypassing attacks. The malicious user boots the machine from floppy into their own OS, and can then reset the recovery agent's password. Then they can reboot into the original OS and log on as the recovery agent. This gives them access to the encrypted files. A second possible weakness is that when files are moved from being unencrypted to encrypted a plain text back up is made in case of system failure during encryption. Although this file is 'deleted' as soon as the operation is complete the unencrypted version will still reside on the disc until its sectors are over written. These could be vulnerable to someone who can access your disk and has a low level disc reading tool. To get around this problem Microsoft recommends that files are created directly into an encrypted directory. Some of these attacks could be avoided by better implementation. However Microsoft is working with the constraint that their EFS must be compatible with applications and systems written for previous versions of Windows. Also the attacks on EFS have shown that encryption is useless unless it is properly configured and this is not a trivial task. This necessitates the use of a specially trained computer security expert. Ultimately, for total protection, physical security is needed. Recovery and User keys need to be stored offline and preferably involve two factor authentication. ie/ The user has to present two pieces of evidence that he has authorisation. This is most often in the form of a token (A smartcard or one time password generator.) and a password. |
nav: home archives photos my other sites: - New York Running - ISOGA Heavy Metal Band! - Vacations in France! friends: - simon's scene - mark's musings previously: - More Like it - Worst Webhost ever? - Against Bottled Water - Recovering Disk Space in Windows - Sun Ray Deployment at IS195 - Running Route Database - Update - Pics from Mike's Bike Trip - Central Park Moonlight Cycle - Kristin Plater's Next Show... - Kristin Plater Plays the Alphabet Lounge - Your Chance to Influence US Energy Policy! - Practical NY Energy Tips - PCs - Missing the Point - Practical NY Energy Tips - Lighting - Making the Switch to Firefox - Belize to Gutemala and Back Again - Diving in Cancun - Today... - Peru and Belize! - PC Fix Up Tips |