SEFS: Security Module for Extensible File System Architectures

SEFS: Security Module for Extensible File System Architectures Þ Þ Lu´ıs FerreiraÝ , AndréZúquete and Paulo Ferreira Ý ISEL/INESC, Þ IST/INESC g fluis.ferreira, andre.zuquete, paulo.ferreira @inesc.pt Abstract ethical access by file server’s administrators; or (iv) unauthorized accesses to users’ files by an attacker Data security is a fundamental issue in modern com- capable of impersonating them. Whence, access con- puter systems. In particular, data storage systems are trol mechanisms, either physical or logical, aren’t bul- frequently subject to attacks and so need protection. letproof, and that may be a major concern for people Typical storage systems rely on access control mecha- dealing with sensitive data. nisms, either physical or logical, to prevent unautho- To make it even worse, current distributed file sys- rized users from accessing stored data. However, such tems exacerbate some of the previous problems and mechanisms are useless against non-ethical attitudes introduce new ones. On distributed file systems peo- taken by privileged users, like system administrators. ple have to trust on: (i) the physical security of remote Thus, the ultimate solution for ensuring the privacy of file servers, (ii) administration teams (that may blur sensitive data is to use cryptographic techniques. individual non-ethical attitudes), (iii) the capability This article describes the design and implemen- of remote authentication mechanisms to prevent per- tation of a security module, for extensible file sys- sonification, and, finally, (iv) they have to trust that tem architectures (SEFS), that enforces file security attackers cannot understand or modify data flows using cryptographic techniques. The security mod- between the client node and the file server. ule provides privacy facilities at file granularity. The All these security issues can be overcome by place where the module is inserted in the file system locally applying user-driven cryptography, the ulti- architecture maximizes the transparency of its oper- mate strong data protection mechanism in multi-user ation: existing applications can transparently work computer systems. For the particular case of file with encrypted files, which may be physically stored systems, sensitive files should be stored and trans- anywhere (fixed/removable local/remote devices). ferred encrypted, and should only be decrypted just Furthermore, the proposed solution allows a flexible before being used by legitimate users’ applications and discretionary way of marking files as secure, not (and encrypted immediately after being used). This imposing any modification in their location. A pro- solution ensures the protection of files as long as legit- totype was implemented for the Microsoft Windows imate users are the only ones controlling the encryp- 95 architecture, but a similar solution may be adopted tion/decryption engine (which depends on users’ for other Windows systems, such as Windows NT secret keys). or Windows 2000. Preliminary performance evalua- The main goal of our work is to protect sensitive tions show that the cost of security provided by SEFS data, stored either in local or remote files, by adding is acceptable and mostly due to cryptographic algo- security properties, namely cryptographic privacy, to rithms. files and directories. These security properties are specifically requested by users for specific files or directories, and transparently enforced using crypto- 1 Introduction graphic techniques controlled by user’s cipher keys. To simplify the manipulation of secure files by appli- Data security is a major concern of today’s informa- cations, they are ciphered and deciphered transpar- tion systems, both for transient and permanent data. ently at file system level by the SEFS module (and Since file systems are the main mechanism provided not with a user-level tool, e.g. PGP [24]). The names by operating systems for permanent data storage, the of secure files and directories are also hidden using security of long term data implies an effective protec- cryptography. Names are used as well to store per-file tion of files. security-related metadata used by SEFS. The traditional policy for protecting files relies on The transformation of ordinary files and directo- two mechanisms: physical enclosure of the storage ries into secure ones is handled by specific SEFS media, and logical access control barriers managed by tools or plug-ins for popular file system browsers the operating system (e.g. ACL monitors[6, 20, 21]). (e.g. Explorer). Secure files are protected by a secret However, these mechanisms may fail in many differ- key using symmetric cryptographic algorithms, and, ent scenarios, for instance: (i) free physical access to a unlike EFS [5], no particular mechanisms are provided stolen laptop; (ii) access to removable storage devices, for administrative recover of cipher keys (as we want e.g. a backup CD-ROM or a floppy disk; (iii) non- to protect users from non-ethical administrators). 1 The SEFS module lies within the file system archi- (and metadata, e.g. their name) depends only on tecture, below applications’ API for file manipulation, the standard access control of the underlying file sys- and uses underlying file systems structures to store tem. This way, normal administrative procedures, secure files. Many existing file system types can be like backups or volume relocations, can still deal with used to store secure files (FAT, FAT32, NTFS, CIFS, secure files. etc.). Unlike CFS [1], SEFS allows users to freely sprin- Users may specify, with the minimum inconve- kle secure files within those file systems. Extending nience, which files have security properties and which file system’s functionality became possible with more don’t. Security properties of directories can be inher- recent file system architectures, that offer the possi- ited by subdirectories or files, either existing or newly bility to intercept file system requests. This intercep- created. Furthermore, secure files may exist any- tion mechanism allows the development of new file where, and not only on special directories or volumes, system features to improve current systems, instead in order to simplify the management of users’ securely of developing completely new ones, and we used stored data. it to implement SEFS. A first prototype of the SEFS SEFS provides a ”decrypted view” over local or module was developed for the Microsoft Windows 95 remote file systems, allowing authorized users to architecture, but a similar solution can be adopted for transparently manipulate the decrypted contents and other Windows systems, like Windows NT or Win- metadata of secure files (see Figure 1). Each decrypted dows 2000. view is controlled by a set of keys known by a user, the Preliminary performance evaluations of read/write authorized one for that view. Secure and not secure operations show that the cost of security is acceptable, files may coexist in the same volume. Similarly, differ- although significant. The performance degradation is ent users may store secure files in the same volume, mostly due to cryptographic transformations, which but it is assumed that in each machine there is at most are responsible for 78 to 95% of the total SEFS over- one user locally authenticated. Other users can, at the head in read/write operations. same time, be authenticated on other machines and, This paper is organized as follows. In Ü2we throughout their own SEFS, remotely access secure describe the general architecture of SEFS. In Ü3we files in the same volume. describe the implementation of SEFS. In Ü4 we eval- Machine B uate the performance of SEFS. In Ü5 we present other view solutions and we compare them with SEFS. Finally, in Dir file system sample Ü6 we present the conclusions of the paper. Machine A User Y F1 view Dir K2 F2 SEFS F3 2 SEFS – Security Extension for Dir F1 User X K1 F1 F2 Machine C File Systems F2 K1 K2 Dir F3 SEFS F3 In this section we describe the general architecture of F1 SEFS. First we present the main design goals observed view F2 in the design of SEFS and we discuss its architecture; F3 then we describe how SEFS handles cipher keys, and User Z finally we highlight some of the high-level issues in the development of SEFS and the solutions proposed. Figure 1: Example of SEFS decrypted views (dashed The SEFS module was designed in order to achieve boxes) from a file system sample (dashed oval) shared four major goals: by different machines and users, either using or not SEFS. Those using SEFS have a different view of the 1. Provide transparent file system security (i.e. original file system contents, and the view depends on cryptographic transformations of sensitive data) the cipher keys provided locally to SEFS. Encrypted for existing applications with discretionary and files, represented as grey boxes, can only be seen easy-to-use file granularity; decrypted by users using SEFS and the correct cipher ½ Ã ¾ key (Ã for F2 and for F3). 2. Use existing file systems, both local or remote, to store secure files and directories mixed with ”normal” ones; Microsoft Windows allows three ways of extending the system functionality: (i) by extending partic- 3. Maximize users’ trust in its security features; and ular applications’ functionalities by means of explicit hooks to plug-ins, (ii) by wrapping legacy code, or 4. Have the lowest possible impact on the overall (iii) by extending, whenever allowed, the core func- performance of the file system. tionalities provided by the operating system. The first The first goal is fundamental for simplifying the solution is clearly not well suited for providing trans- daily use of secure files, as well as the administration parent security features for a broad range of exist- of file systems. Secure files are just ordinary files, but ing applications. Wrapping legacy code is a powerful their data and some of their metadata is encrypted. but delicate approach that should be avoided if one The visibility of secure files and their encrypted data has the possibility of extending the system functional- 2 ity.

Load more