TransCrypt File Server Enhancements for Secure Remote Access

(1)

TransCrypt File Server Enhancements for

Secure Remote Access

Salih K A

Department of Computer Science & Engineering

Indian Institute of Technology Kanpur

(2)

TransCrypt File Server Enhancements for

Secure Remote Access

A Thesis Submitted

In Partial Fulfillment of the Requirements

For the Degree of

Master of Technology

by

Salih K A

to the

Department of Computer Science & Engineering

Indian Institute of Technology Kanpur

(3)

(4)

Abstract

Many organizations keep a great deal of confidential information on computers. Such information is to be stored securely, while giving the convenience of accessibil-ity from any part of the world. For data securaccessibil-ity, one can make use of encrypting filesystems such as File Vault, eCryptfs, dmCrypt etc. Another encrypting file sys-tem TransCrypt [25] was designed to provide a very strong solution to the problem of securing data in a manner transparent to the user. It provides stronger security compared to other existing encrypting file systems and restricts its trust only to in-structions in the kernel mode of execution. All processes in user space including processes with super user privileges, are excluded from its trust model.

TransCrypt provides per-user access control, per-file encryption and per-volume managerial control. However, it was not designed to work over network and hence could not address the security issues when data was accessed over network. In this thesis, we re-architecture TransCrypt to make it work over network as a network file system. The major security breaches while accessing the files over network are carefully analyzed and the proposed design counters all these attacks using strong cryptographic methods. We also discuss the implementation of the design at the File Server side, where TransCrypt volumes are hosted.

Additionally, the earlier TransCrypt implementations had made a set of modi-fications to the Virtual File System (VFS) layer in the Linux kernel. The Linux kernel code undergoes changes periodically and hence causes problems while porting Trans-Crypt to newer versions. This work also moves the TransTrans-Crypt VFS modifications to a Linux Security Module (LSM), which makes TransCrypt largely independent of Linux Kernel code changes. In addition to this, design and implementation of a cer-tificate cache is discussed which makes the perfomance of TransCrypt based filesystem a lot better than the earlier implementations [18, 30, 24] .

(5)

Acknowledgments

I wish to express my gratitude to Prof. Rajat Moona, without whom this thesis would not have been possible. His constant support, advise and guidance made it a pleasure to work on this project. I also thank the Prabhu Goel Research Center for Computer and Internet Security for supporting me and providing me with the excellent facilities to complete this project.

I also thank Abhay Khoje and Satyam Sharma for their help and suggestions throughout my work. Thanks are also due to Ajin George Joseph, Sijumon K, Harish B, Sanjoy C, Binesh J, Deepak Luckose and Hari for patiently listening to me and helping me flesh out my ideas. I also thank my entire class, the M.Tech. 2007 batch of CSE — it was a pleasure to be surrounded by a set of such helpful, fun-loving and talented individuals.

Finally, I thank my mother, father and sisters whose love, support and encour-agement made all of this possible.

(6)

List of Figures

1.1 Model of file access . . . 9

2.1 NFS Architecture . . . 15

2.2 LSM Hook Architecture [31] . . . 17

3.1 TransCrypt Architecture . . . 24

5.1 Model of File Access . . . 46

5.2 Man-in-the-middle attack . . . 48

5.3 Negotiation Protocol . . . 54

5.4 Authentication between Workstation (WS) & File Server (FS) . . . . 59

5.5 NFS file operations . . . 60

5.6 Protocol Headers . . . 64

(11)

Abbreviations used in the thesis

FS : File Server - Normally referred to a computer hosting TransCrypt services.

WS : Work Station - The host from where a user access his files on a FS.

PKS: Private Key Store - The PKS stores the private key of the subject and provides cryptographic operations related to the private key.

SCURI: Smart Card Uniform Resource Identifier - This identifier is used to identify the location of SmartCard uniquely and includes the IP address of the machine and part of the SmartCard reader, where the user’s SmartCard is inserted.

FEK: File Encryption Key - The randomly generated symmetric key for a newly cre-ated file to encrypt and decrypt file data.

FSK : File System Key - This symmetric key is unique for each volume and is used to provide further security to FEK.

EP

u(M): Asymmetric key encryption of the message, M with the public key of the en-tity, u.

(12)

Chapter 1 Introduction

1.1 Motivation

Security is quickly becoming a mandatory feature of data storage systems. Today, storage space is typically provided by complex networked systems. These networks have traditionally been confined to data centers in physically secured locations. But with the availability of high-speed Local Area Networks (LANs) and storage network-ing protocols, these networks are becomnetwork-ing virtualized and open to access from user machines. Hence, clients may access the storage devices directly, and the existing static security methods are no longer sufficient to protect the data from intruders. New, dynamic security mechanisms are required for protecting data in networked storage systems.

For data security, several solutions have been devised. This include File Vault [1], eCryptfs [12], dm-crypt [9], Microsoft EFS [14] etc. These encrypting file

(13)

systems provide security by encrypting and decrypting user data thereby addressing the problem of data security in many different ways [25]. However these encrypting file systems do not address the problem of accessing files over network from networked computers. Another encrypting file system TransCrypt [25] was designed to provide a very strong solution to the problem of securing data in a user transparant manner.

TransCrypt is an enterprise-class, kernel-space encrypting file system for the Linux operating system. It provides per-user access control, per-file encryption and per-volume managerial control. However it is not designed to work over network and hence does not address the security issues when the data is accessed over network from networked computers. Hence a need was felt for re-architecting TransCrypt so as to make it work over network as a network file system.

In addition, the TransCrypt implementation [18, 30] made a set of modifica-tions to the Virtual File System (VFS) layer in the Linux kernel. The Linux kernel code undergoes changes periodically and hence causes problems while porting Trans-Crypt to newer versions. Hence a need was felt for an improved TransTrans-Crypt file system which avoids the approach of VFS system call interposition for incorporating its access control methods.

1.2 Related Work

For remote file access, one can make use of any distributed file systems such as Andrew File System (AFS), CODA and Network File System (NFS). Encrypted File Systems (EFS) can be used to protect the file servers from intruders. This section explains in

(14)

1.2.1 Distributed File Systems

1.2.1.1 Andrew File System (AFS)

AFS [22] is a distributed filesystem that permits clients and servers to share filesystem resources across LANs and Wide Area Networks (WANs). One of the main design goal of AFS was scalability. Whenever an AFS client access any file on the server, the server passes the complete file to the client, which the client caches locally. Thereafter, all the operations are performed on the local copy. When the client saves the file, the local copy is sent to the server. Cache consistency is maintained by using a call back mechanism, in which the server informs the client whenever the file is updated by some one else. Some features of the AFS are mentioned below.

• Caching at clients to improve performance.

• Provides location Independence by mapping File names to location at server.

• Integrates security features like Kerberos for user authentication.

• Provides access control based authentication methods.

The AFS has however certain disadvantages. It is a complex system to develop and costly to setup. Further AFS does not support UNIX like permissions model which makes it hard to support UNIX semantics.

1.2.1.2 CODA

CODA [23] is a distributed filesystem developed at Carnegie Mellon University. It is the descendant of the Andrew File System (AFS). The main design goal for CODA

(15)

was to provide continuous data availability. This feature is achieved by using server replication and disconnected operations. A volume in a CODA filesystem can be shared among multiple servers. The clients can download files from any available servers. Whenever a client saves a file, it propagates the modifications to all the available servers. While servers are available, clients can also specify to cache some files for future use (a feature known as hoarding). Later when a client is disconnected from the servers, it can continue to work with the cached files. Once the client gets back the connectivity, it plays the cached operations log (i.e. file modifications) to the server. These modifications are merged at the servers. Sometimes human intervention is required if conflicts occurs while merging. The main features of coda are the following.

• It is designed for high scalability.

• It provides better data availability than other distributed file systems by server replication and hoarding techniques.

• It is mainly used by mobile users.

• It incorporates Kerberos [16] based authentication mechanisms for security

• It provides Access Control Lists for authentication.

CODA has certain disadvantages such as being slower than AFS and the fact that it trusts the underlying network for not altering the client authentication credentials.

(16)

1.2.1.3 Network File System (NFS)

NFS [19] is one of the DFS that is standard, matured and supported robustly across a variety of platforms. It is a client-server model filesystem, developed by Sun Micro system. NFS uses Remote Procedure Call (RPC) [27] for communication between servers and clients. RPC is built over eXternal Data Representation (XDR) [26] which provides portability across platforms. NFS provides centralized administration. NFS v4 [20] incorporated various features like delegation of files to clients for caching, mandates use of various strong security mechanisms.

1.2.2 NFS and Security

When NFS was originally designed, the main focus was to provide a simple mecha-nism for transparent remote file access. Hence little emphasis was placed on security concerns. A trusted network was assumed. Every host and every user were who they said they were. The server could specify which all hosts could mount its file systems and how to access the files. But, an attacker with control of an NFS Client could impersonate any other user if he is permitted to mount a file system.

Due to the widespread acceptance of the NFS these days, security became an important concern. It leads to redesigning its authentication and access control methods.

(17)

1.2.2.1 Traditional NFS security methods

NFS has evolved through time. The version 3 of NFS [4] provided the following security capabilities.

• Server authentication - None. The NFS v3 does not require any server authen-tication.

• Client authentication - Server is provided with a set of authorized clients (listed by either hostname or IP address). Thereafter the source IP address of the network file request packets will be validated by the server. This is a weak security mechanism as an attacker could falsify the source IP address and can get access to some other user’s files.

• User authentication - NFS used RPC authentication methods to determine whether the user requesting the operation is authorized to perform it or not. The available methods include

– AUTH NONE - No authentication.

– AUTH UNIX - here the server trusts the UIDs and GIDs provided by a client. But if the attacker can become a superuser on the client, he can use “su” command to trivially send any GID or UID.

Besides communication between NFS server and client are not encrypted and hence could give attackers information about valid GIDs and UIDs in clients and servers.

(18)

1.2.2.2 NFS version 4 Security Enhancements

One of the main factors to develop NFS v4 [20] was to provide strong security. A number of sophisticated security mechanisms were proposed in NFS v4 and mandated for implementation by all conforming clients. One of the main security enhancements was mandatory Kerberos [16] support.

NFS servers can be authenticated by a client by comparing server’s certificate with a list of trusted Certification Authorities. For user authentication, clients are required to present valid Kerberos credentials ie, a service ticket issued by Kerberos Key Dis-tribution Center (KDC). For a secure implementation, the KDC must be protected against attacks to maintain the integrity of the system. It is generally very hard to provide such a Kerberos setup in a public environment.

1.2.3 Encrypted File Systems

To prevent the attack on File Servers, encrypted file systems such as the Encrypting File System (EFS) [14], dmCrypt [9], eCryptfs [12], TransCrypt [25] can be used. EFS implements encryption at the kernel level, but all key-management operations are done at user space. This hybrid feature makes it vulnerable to user-space attacks. dmCrypt is a encrypting file system that is volume based and is part of the standard Linux kernel. But it lacks flexibility due to the use of a common mount-wide key. Additionally dmCrypt addresses a narrow threat model. eCryptfs is a kernel-native cryptographic file system for Linux. It is a stacked file system that encrypts and decrypts the files as they are written to or read from the lower file system. It is vunerable to user space attacks as it uses a user space daemon for key management. Additionally, super users are trusted in eCryptfs. TransCrypt is a secure, usable,

(19)

Figure 1.1: Model of file access

transparent, efficient enterprise-class encrypting file system for Linux. It excludes the super user from the trust model. It uses per-file encryption key and per-user authentication keys for confidentiality and access control.

The solutions available for the encrypting filesystem however do not tackle the attacks arising from the network and the user Work Stations, which are more vulnerable in general.

1.3 Contribution of this Thesis

TransCrypt was initially not designed to work over network and hence does not ad-dress the security issues when the data is accessed over network from remote com-puters. The earlier implementation of TransCrypt modified the VFS layer system calls to incorporate its permission related operations. This approach presented some drawbacks like lack of flexibility because TransCrypt changes have to be compiled into the kernel, and code maintenance against newer kernel versions.

(20)

This thesis discusses the issues when users access their files over network from a TransCrypt file system and proposes a solution for the same. We assume the model shown in Figure 1.1 to develop our solution. Implementation details of the solution at the File Server side are described. Performance tests conducted on the implemen-tation against the unsecured NFS file access methods are plotted and the results are analyzed. It also discusses how the Linux Security Module (LSM) Framework [31] can be used for TransCrypt for better flexibility and code maintenance. In addi-tion, the design and implementation of an in-kernel certificate cache for performance enhancements at the time of file creation and sharing is discussed.

1.4 Organization

The rest of the thesis is organized in the following manner. In chapter 2, we discuss the terminologies used in the remaining thesis. In chapter 3, we provide the overall design and implementation of the earlier TransCrypt version (version 0.2) [28]. In chapter 4, we describe how the LSM framework can be used for TransCrypt for better flexibility and code maintenance. In addition, the design and implementation of a certificate cache for performance enhancements is discussed. In chapter 5, we explore the TransCrypt’s vulnerabilities related to network wide usage and provide a mechanism for enabling TransCrypt to work over network as a networked file system. In chapter 6, we provide details about the performance results conducted on the new implementation. The results are compared with the insecure NFS file access methods. Finally this thesis is concluded in chapter 7 with a note on future work.

(21)

Chapter 2 Background

In this thesis, a method to enable TransCrypt to work as a network filesystem is discussed. In this scenario, users access TransCrypt volumes hosted on a Server from a public Work Station host using the NFS protocol [19]. Additionally, the new Trans-Crypt implementation makes use of the Linux Security Module (LSM) framework [31] provided by the Linux Kernel to remove the VFS layer system call modifications made by TransCrypt in the earlier implementations [18, 30]. This improves flexibility and code maintenance. The new implementation also provides a certificate cache to im-prove the performance during file operations. A user-interface is developed as part of the cache framework to make the administrative tasks simpler. TransCrypt uses the Configfs [2] pseudo filesystem to create this interface. In this Chapter, we briefly discuss these components used in the current implementation of TransCrypt.

(22)

2.1 Network File System (NFS)

Network File System (NFS) [19] is one of the distributed filesystems that is most popular and widely used. It was originally designed and implemented by Sun Mi-crosystems. NFS allows machines to share files and privileged remote users can access these files as if they were local to the user’s machine.

NFS is designed to work in a heterogeneous environment in which machines of different architectures, running different operating systems can share resources across network. NFS achieves this through the use of Remote Procedure Call (RPC) [27] primitives built on top of an eXternal Data Representation (XDR) [26].

2.1.1 NFS Protocol

NFS protocol represents the series of messages exchanged between an NFS server and the client. Information is exchanged between the server and the client using the underlying Remote Procedure Call (RPC) [27] protocol.

To start the NFS service on a machine, the NFS server software has to be initiated. This requires a Portmap daemon, the nfs daemon and a mount daemon to run in that order. The Portmap allows NFS clients to discover which port the server is listening to. The nfs daemon services the requests arising from NFS clients. The mount daemon checks to see if mount requests from NFS clients match with a currently exported filesystem.

Before accessing the files on an NFS server, the clients must mount the NFS filesystem locally. The client specifies the following arguments in the mount command.

(23)

• The IP address or the hostname of the server.

• The directory path name on the server that it wants to mount.

• The local mount point.

• The authentication mechanism to be used.

• The network protocol to be used (ie, TCP or UDP).

The server will then check the configuration files (/etc/exports, /etc/hosts.allow and /etc/hosts.deny) with the identification of the client host to determine whether access should be granted or not. Entries in the /etc/exports [11] file on the server indicates a volume that is shared and the mode in which it is shared. This file serves as access control list for file systems which are exported to NFS clients. Entries in the hosts.allow and hosts.deny specify the clients that can use services on the server. If the access is granted, the server provides a filehandle to the client. The filehandle has certain fields that uniquely represent the filesystem type, the inode of the file, the disk and the security information.

Subsequent NFS requests take the form of write and read requests, file cre-ation and deletion, modifying file permissions etc. These requests carry the following arguments to the server.

• The filehandle of the object on which to perform the operation.

• The identity of the user performing operation.

(24)

• Procedure specific arguments like the offset within the file to read from, data to be written etc.

When a client requests for an operation on a specific filehandle, the server verifies the permissions and the Access Control Lists (ACLs) associated with the file that this filehandle represents. This along with the user and client details is used to determine whether access should be granted or not.

2.1.2 NFS Architecture

Figure 2.1 shows the architecture diagram of the NFS. It contains mainly three layers.

1. System calls interface: This layer handles filesystem related calls like open, read, close etc. from the processes.

2. VFS interface: This layer decides whether the file being accessed is local or remote. If the file location is on a remote location, the VFS interface transfers the control to the corresponding NFS procedure.

3. NFS Client: This layer implements the NFS protocol described earlier. It is the bottom layer of the architecture. The NFS clients cache the filehandles obtained from servers for performance enhancements. All the requests from NFS clients are handled by the NFS servers. RPC protocol is used for the communication between the NFS servers and clients.

(25)

(26)

2.2 Linux Security Module (LSM)

2.2.1 Overview

Historically in Linux kernels prior to Linux version 2.6, there were no direct support for enhanced access control mechanisms in the Linux kernel. There was no infrastructure to mediate access to kernel objects externally. Enhanced access control mechanisms were implemented as kernel patches. It brought changes to the kernel source and hence was not a flexible solution. Hence, under the guidance of Linus Torvalds, LSM framework [31] was created with the following principles.

• The Linux kernel continues to do the normal security checks as being done earlier.

• When Linux kernel needs to decide whether the access should be granted or not, it also checks with the security modules to determine whether the action is okay.

• An administrator can pick the security module depending upon the needs and policy of the installation.

LSM was designed to provide for specific needs to successfully implement a manda-tory access control module, while imposing the fewest possible changes to the Linux kernel [13]. It inserted hooks in the kernel code just before accessing important ker-nel objects such as task control blocks and inodes (figure 2.2). LSM modules provide the functions called by these hooks. LSM framework provides APIs to allow kernel modules to register or unregister as security modules.

(27)

Figure 2.2: LSM Hook Architecture [31]

2.2.2 LSM Architecture

Five components were added or modified to support LSM [31] in the Linux kernel.

1. A generic interface for security functions.

2. Calls to security functions at various parts in the kernel.

3. Security related data structure components to various kernel data structures. 4. Functions to be called by kernel modules to register and unregister as security

(28)

5. Capabilities [5] logic migration into an optional security module.

2.2.2.1 Interface for security functions

The security operations structure in the kernel code defines the supported rity functions as function pointers. It defines a global variable ‘extern struct secu-rity operations secusecu-rity ops’. It has a set of static functions each of which correspond to a security related function.

2.2.2.2 Kernel security hook functions

The LSM framework inserts hooks to security functions at critical points in the kernel code to perform access control and to manage the security fields. An example of the first category of hooks is the inode permission hook, which checks permissions when accessing an inode. Examples of the second category hooks include the free security hooks and alloc security, which are used to free and allocate security structures for kernel objects.

2.2.2.3 Security fields in kernel objects

Security related data structure components are generic pointers which are added to various kernel data structures to associate security information. For example, fields are added in task struct data structure for supporting task related access control. The manipulation and use of these security fields are carried out by various security modules.

(29)

2.2.2.4 Module Registration

LSM framework is initialized with a set of dummy functions during the kernel boot sequence. When a security module is loaded, it registers with the LSM framework using the register security function. It causes the global security ops table to point to the module’s hook function pointers, resulting the kernel to call the security mod-ule for access control decisions. When the modmod-ule wants to unload, it must call unregister security to unregister with the framework.

The framework only registers one module as primary module. It provides mechanisms for stacking more security modules with a primary security module. The decision of module stacking is left to primary module. It can determine when to call other modules and it combines the results from other modules.

2.2.2.5 Process capabilities

Capabilities are a partitioning of the all powerful root privileges [5]. A process has three sets of bitmaps to implement permitted, inheritable and effective capabilities. A capability is implemented as a bit in these bitmaps which is either set or unset. The LSM project developed a separate security module for capabilities and migrated the earlier capabilities logic implementation to this security module.

2.3 Configfs

(30)

ker-completely managed by processes in user space. This is the widely accepted method for configuring a kernel subsystem from user space [7] in modern Linux kernels.

2.3.1 User space View

Any kernel subsystem that wants to use configfs for communication creates one or more directories within configfs. Directories in configfs represent objects in kernel [7]. Directories contain files, which represent the object attributes. Privileged user space processes can create or delete directories (using mkdir and rmdir) under the subsys-tem. This leads to a call back within the kernel and hence the corresponding action on the objects. Attributes can be seen or set from within user space using read or write system calls. Default directories can be made under any subsystem. These directories (and the files inside) will be created automatically, when the subsystem is loaded initially.

2.3.2 Kernel space View

Objects are represented as a config item [8] (represented by struct config item) in the kernel. Each config item has a type associated with it (represented by struct con-fig item type), which describes the attributes (files in userspace) and the operations permitted on those attributes. These operations are the call back methods in kernel that correspond to specific user actions in userspace.

struct config_item { ...other parameters...

(31)

struct config_group *ci_group; struct config_item_type *ci_type; };

A config item cannot exist by itself, it resides on a config group (represented as config group structure). It itself is a config item and can contain other config groups or items. It can create child items or groups through the group operations specified in group’s config item type. These methods will be called when a user performs ‘mkdir’ in the group’s directory in userspace.

struct config_group {

struct config_item cg_item;

struct configfs_subsystem *cg_subsys; struct config_group **default_groups; ...other parameters...

};

‘default groups’ under config group will be automatically created when the parent group is created. They are removed automatically when the parent group dies.

Config subsystem (represented by struct configfs subsystem) is the top level config group and it represents the client subsystem as a whole.

struct configfs_subsystem { struct config_group su_group; ...other parameters...

(32)

Chapter 3 TransCrypt Architecture

3.1 TransCrypt in a Nutshell

TransCrypt is a secure, usable, transparent, enterprise-class encrypting file system for Linux. It provides stronger security compared to other existing encrypting file systems and restricts its trust only to the kernel by excluding userspace (including processes with super user privileges) from the trust model. The architecture diagram of the TransCrypt is shown in Figure 3.1.

When a new file is created by a user on a transcrypt filesystem, a random File Encryption Key (FEK) is generated. This key itself is protected by providing confi-dentiality through encryption with a File System Key (FSK). FSK is a per-volume secret key provided during file system mount time, known only to the filesystem ad-ministrator. The protected FEK is then further encrypted with the public key of the user to form a “token”, which is then stored as the file metadata.

(33)

When a user opens a file, the kernel retrieves the token from the file metadata. It then sends the token to the user’s Private Key Store (PKS) for decryption through a userspace daemon, transcryptd. The token is decrypted at the PKS using the private key of the user to retrieve protected FEK. This protected key is then sent back to the kernel. The kernel recovers the FEK by decrypting this protected key. FEK is then stored in a kernel data structure and used for data encryption and decryption during file write and read operations, respectively.

When a user (file owner) wishes to share a file with another user ‘usr1’, the protected FEK is acquired using the owner’s token (as done during open). Then a token for ‘usr1’ is created by encrypting the blinded FEK with the public key of ‘usr1’ (as done during create). It is then stored along with the owner’s token in the file metadata .

3.2 TransCrypt Implementation

In the initial version of TransCrypt [25], the implementation was tightly coupled with the ext3 file system [29]. TransCrypt modified on-disk structures to store additional meta-data required for its functionality. These modifications also included changes to the userspace e2fsprogs package [10] which contains tools and libraries to work with ext3 volumes. A tight integration with ext3 file system made TransCrypt in-compatible with other advanced file systems. The newer version of TransCrypt was re-architectured [18] to employ a layered architecture, with its layers being filesystem independent. It used the extended attributes support provided by the file systems

(34)

(35)

for meta data storage. With this mechanism, a great deal of flexibility and code maintainability was achieved.

In addition, the earlier implementation of TransCrypt [25] also modified the file I/O functionality of the kernel. Hence it had several performance and maintenance related limitations. The implementation used page cache for its operations. The direct I/O operations where page cache is bypassed, were not supported by TransCrypt. For performance reasons, some applications such as database management systems, use direct Input/Output operations frequently. The new version of TransCrypt [28] uses a layer of cryptography to achieve modularity and direct I/O support [30]. This support is based on the device-mapper infrastructure [9] of the Linux kernel.

During the implementation of TransCrypt [28], modifications were carried out on the existing kernel space components as well as in userspace softwares. This following section discusses the TransCrypt implementation for Linux kernel version 2.6.23.

3.2.1 Kernel space Components

3.2.1.1 VFS Changes

The Linux kernel VFS layer was modified to incorporate transcrypt’s access control methods. It mainly included token and key-management functions. Changes were also made to store and retrieve configuration parameters to and from the extended attributes of the super block (user.transcrypt.params) during ‘mkfs’ and ‘mount’ time respectively.

(36)

File creation semantics of transcrypt were incorporated in the open namei create() procedure. File open semantics were incorporated in the may open() procedure. Sim-ilarly, file sharing semantics of transcrypt were incorporated in the vfs setxattr() pro-cedure in the VFS layer.

3.2.1.2 Configuration Manager

This module in the TransCrypt implementation manages the global and per-volume user configurable parameters. It uses a configfs [2] interface to pass parameters to the kernel. The per-volume secret key of TransCrypt (FSK) is passed to the kernel via this interface. FSK is generated from the passphrase given by the administrator at the time of creating the filesystem.

3.2.1.3 Public Key Infrastructure (PKI) manager

This module maintains an in-kernel storage of certificates for the trusted Certifying Authorities (CAs). The public key in these certificates are used to verify the user certificates. PKI manager provides support for parsing and verification of X.509 certificates by porting XySSL library to the kernel.

PKI manager extended the Crypto APIs [6] provided by the Linux Kernel to allow the use of asymmetric key cryptographic operations. TransCrypt uses asymmet-ric key cryptographic operations for user authentication and symmetasymmet-ric key operations for encryption and decryption of file data.

(37)

3.2.1.4 Keyring Manager

For every file opened by a user, transcrypt needs to store the FEK in memory. This is used for encryption and decryption during subsequent read and write operation on the file by the user.

Linux kernel provides a keyring infrastructure [15] to store keys and search them using a key description. It provides security through permission checks during every key access or store. TransCrypt uses this keyring infrastructure to implement a new keyring named ‘TransCrypt keyring’ where various FEKs are stored. The key description used in TransCrypt keyring is the inode address of the file being accessed. If the keyring does not have enough space to add new keys (FEKs), the keyring is purged by removing keys which are not used recently.

3.2.1.5 Communication Manager

This module takes care of the communication between the transcrypt-enabled kernel and the userspace daemon, transcryptd. It interacts with transcryptd to retrieve user certificates and to get the tokens decrypted during file operations. Kernel uses netlink sockets [21] to communicate with the userspace.

• When a file is created on a transcrypt volume, kernel needs the public key certificate of the user to create the token. Hence, the kernel interacts with transcryptd. Transcyptd retrieves the certificate from a public repository and sends it back to the kernel.

(38)

and sends it to the user PKS via transcryptd in a secure channel. The PKS decrypts the token using the private key and sends back the result to the kernel in the same channel through transcryptd.

3.2.1.6 Device Mapper module (dm-transcrypt)

This module incorporates a device mapper target that maps the transcrypt enabled volumes to another volume. Any further file operations will be performed on the logical volume. It implements fast bulk encryption (or decryption) at the bock layer. A virtual block device is created using the dmsetup [9] utility. This virtual device is mapped to one or more real block devices.

When the user does dm-setup, dm-transcrypt will be loaded into the kernel and it registers with the Device Mapper infrastructure. Thereafter it receives notifications about any I/O performed on the logical volume to which the target is attached.

3.2.2 Userspace Programs

TransCrypt uses some userspace utilities for its functioning as described here.

3.2.2.1 TransCrypt Daemon (transcryptd)

This daemon interacts with the kernel using netlink sockets and communicates with the user PKS using TCP connections. This daemon retrieves user certificates from public repositories and sends to the kernel when needed. It also acts as a router of messages between the kernel and the user PKS.

(39)

3.2.2.2 TransCrypt Authserver (transcrypt-auth)

This daemon acts as an interface to the user’s PKS. The PKS can be smart card, usb drive etc. In the current implementation, transcrypt uses a file based PKS.

When a request for token decryption comes to transcrypt-auth, it checks in a certtab file and retrieves the private key file. transcrypt-auth decrypts the token using the private key and sends the result back to the kernel through transcryptd.

3.2.2.3 TransCrypt Utilities

TransCrypt uses some utilities to make administrative tasks simpler. These include two wrapper utilities (mkfs.transcrypt and mount.transcrypt) above the standard mke2fs and mount programs.

mkfs.transcrypt accepts a passphrase from the administrator who creates the filesystem to derive FSK. FSK is derived using passphrase based key derivation method. The derived key is then passed to the mke2fs utility, which initializes the superblock accordingly. mount.transcrypt accepts a passphrase from the user who mounts a transcrypt volume and then computes FSK as done in mkfs.transcrypt. This key is then passed to the kernel through the configuration manager. The kernel compares this key to the one stored in the superblock and gives access only if both the hashes match.

Apart from the above wrapper utilities, transcrypt also makes use of some scripts to manage user certificates and private keys.

(40)

Chapter 4 Enhancements for

Modularity and Performance

TransCrypt implementation was carried out by modification of a set of system calls to incorporate its access control methods. This approach presented certain draw-backs such as lack of flexibility and code maintenance in consonance with newer kernel versions. This chapter discusses the suitability of LSM framework [31] used by TransCrypt to overcome these drawbacks.

Additionally, in the transcrypt implementation (version 0.2), whenever a new file is created or is being shared with another user, the kernel communicates with the userspace daemon, transcryptd to retrieve the certificate of the user. A huge performance improvement can be achieved, if the certificate are cached by the kernel. This reduces the interactions between kernel and user mode processes and therefore fewer context switches. This chapter also discusses the design and implementation of a certificate cache for TransCrypt.

(41)

4.1 TransCrypt-LSM Module

TransCrypt LSM module registers a set of call back functions with kernel to implement security operations (named as transcrypt security ops). This is done by invoking the register security() API provided by the LSM framework [31] in the kernel.

The functions from the list of functions in transcrypt security ops are invoked by the kernel through File System hooks implemented by the LSM. As discussed in chapter 2, LSM interface has incorporated security fields in important file system objects (super block, inode, file) and placed hooks to support fine grain access control methods at different places in the kernel code. Some of these are discussed here.

4.1.1 File open

While opening a file on a transcrypt volume, the kernel needs to retrieve the token from the extended attributes of the file and needs to derive the FEK from the token. Earlier TransCrypt implementation was through modifications in may open() func-tions in the kernel to incorporate token acquisition and FEK retrieval as shown in the following code.

int may_open(struct nameidata *nd, int acc_mode, int flag) { ...other code snippets...

error = vfs_permission(nd, acc_mode); if (error)

(42)

#ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (is_transcrypt_file(inode)) {

error = transcrypt_get_and_store_fek(nd->path.dentry); ...other code snippets...

} #endif

...other code snippets... }

This patch is now restored and implemented through security inode permission() security hook present in the vfs permission() function (which is called from the may open() system call during any file open operation) inside the kernel, as shown below.

int permission(struct inode *inode, int mask, struct nameidata *nd) { ...other code snippets...

return security_inode_permission(inode, mask, nd); /* LSM hook used by TransCrypt */ }

(43)

4.1.2 File Creation

When a user creates a file under a transcrypt volume, transcrypt has to create a token for that user and add that to the extended attribute of the file. TransCrypt imple-mentation had earlier modified the open namei create() system call to incorporate this logic as shown in the following code.

static int __open_namei_create(struct nameidata *nd, struct path *path, int flag, int mode) { ...other code snippets...

error = vfs_create(dir->d_inode, path->dentry, mode, nd); ...other code snippets...

nd->path.dentry = path->dentry; if (error)

return error;

#ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (is_transcrypt_file(path->dentry->d_inode)) {

error = transcrypt_init_token(path->dentry); ...other code snippets...

} #endif

(44)

TransCrypt requires the inode of the file to add the token to the extended at-tribute. The existing security hooks in the VFS create() path (security inode create() in the vfs create() function) don’t have access to the valid inode of the file. Hence a new LSM hook is created (named as security inode post create()) and the transcrypt modifications are carried out through this LSM hook as shown below.

int vfs_create(struct inode *dir, struct dentry *dentry, int mode, struct nameidata *nd) {

...other code snippets...

error = security_inode_create(dir, dentry, mode); ...other code snippets...

error = dir->i_op->create(dir, dentry, mode, nd); /* this is where the inode is instantiated */ if (!error)

fsnotify_create(dir, dentry); if (!error)

error = security_inode_post_create(dir, dentry); /* The new LSM hook added*/ }

4.1.3 File Sharing

When a file is to be shared with another user, token for the new user is created and added to the extended attribute of the file. TransCrypt implementation had modified

(45)

vfs set xattr() system call to incorporate this functionality as shown below.

int vfs_setxattr(struct dentry *dentry, const char *name, const void *value, size_t size, int flags) {

security_inode_post_setxattr(dentry, name, value, size, flags); ...other code snippets...

#ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ ...other code snippets...

error = transcrypt_update_tokens(dentry, value, size); ...other code snippets...

#endif

This code is now restored and an existing security inode post setxattr() hook is used that is already present in the vfs set xattr() system call as shown below.

int vfs_setxattr(struct dentry *dentry, const char *name, const void *value, size_t size, int flags) {

(46)

4.1.4 Mount filesystem

When a user mounts a transcrypt volume with an ‘encrypt’ option [18], kernel should match the FSK stored in the extended attribute of the root directory of the filesystem with the one passed by the user (through dmsetup). TransCrypt implementation had modified vfs kern mount() system call to incorporate this logic as shown in the following code.

struct vfsmount* vfs_kern_mount(struct file_system_type *type, int flags, const char *name, void *data) { ...other code snippets...

#ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ int encrypt = 0;

#endif

error = security_sb_copy_data(data, secdata); ...other code snippets...

#ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (data) {

(47)

encrypt = transcrypt_check_encrypt_option(data); }

#endif

error = security_sb_kern_mount(mnt->mnt_sb, secdata); ...other code snippets...

mnt->mnt_mountpoint = mnt->mnt_root; mnt->mnt_parent = mnt;

#ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (encrypt) {

error = transcrypt_get_volume_params(mnt); ...other code snippets...

} #endif

The check for an ‘encrypt’ option in the mount parameters is now removed and instead security sb copy data(data, secdata) security hook is used. In this hook, the parameter ‘data’ contains all parameters for mount. Security sb copy data() hook implementation for TransCrypt now retrieves the ‘encrypt’ option (if present) from ‘data’ and copies it to the parameter, ‘secdata’.

(48)

functions available in VFS mount() (security sb kern mount()) doesn’t have access to the root directory of the filesystem. Hence, a new LSM hook is created (named as security sb kern post mount()) and the TransCrypt modifications are moved into it as shown below.

struct vfsmount* vfs_kern_mount(struct file_system_type *type, int flags, const char *name, void *data) { ...other code snippets...

error = security_sb_copy_data(data, secdata);

/* LSM hook used by TransCrypt */ ...other code snippets...

error = security_sb_kern_mount(mnt->mnt_sb, secdata); ...other code snippets...

mnt->mnt_mountpoint = mnt->mnt_root; mnt->mnt_parent = mnt;

error = security_sb_kern_post_mount(mnt, secdata); /* LSM hook used by TransCrypt */ ...other code snippets...

}

4.1.5 File Delete

When a file is deleted from a transcrypt volume, the FEK of the file has to be removed from the keyring structure. TransCrypt implementation had modified the

(49)

delete inode() system call to incorporate this functionality as shown in the following code.

void destroy_inode(struct inode *inode) { ...other code snippets...

security_inode_free(inode);

#ifdef CONFIG_TRANSCRYPT /* TransCrypt Modifications */ if (is_transcrypt_file(inode)) {

transcrypt_delete_key(inode); }

#endif

This modification is now removed and instead LSM hook, security inode free() present in destroy inode() function is used as shown below.

void destroy_inode(struct inode *inode) { ...other code snippets...

security_inode_free(inode);

/* LSM hook used by TransCrypt */ ...other code snippets...

(50)

4.2 Certificate Caching

Whenever the kernel wants to create a token, it communicates with the user space to retrieve the certificate. If kernel can cache the certificates, it need not communicate with these processes whenever the certificate results in cache hit. This however poses a problem.

When a certificate expires or is replaced by the user, the corresponding cache copy in the kernel also needs to be invalidated. Hence a user interface is required as part of the cache, through which one can remove certificates from the cache. Additionally, memory availability is limited within the kernel. Hence, there should be a mechanism which removes the certificates from the cache whenever the cache gets closer to being full.

4.2.1 Protocol to Cache Certificates

We implemented a protocol as outlined in Algorithm 1 which describes the steps to get the certificate of a user inside the kernel.

When a request for a certificate comes from the kernel, the user space process transcryptd retrieves the certificate from the public repository (/etc/certs) and sends it back to the kernel. Transcryptd creates the user interface for every user certificate given to the kernel. The user interface keeps an attribute with ‘valid’ and ‘invalid’ values. The attribute is ‘invalid’ by default and set to ‘valid’ by the kernel once the certificate is verified. A ‘valid’ value therefore also indicates that the certificate is cached by the kernel. The cache management programs may just “invalidate” this attribute whenever the certificate is modified. When that happens, kernel removes

(51)

the certificate from the cache and frees up the associated memory.

Algorithm 1: Protocol to get user certificates inside kernel

Data: get user x’s Certificate

Result: Certificate OR NULL

if certificate in cache then

1

verify the certificate;

2

if verification successful then

3

return Certificate;

4

else

5

remove the certificate from cache;

6

unset valid attribute in the user-interface that corresponds to user, x;

7 return NULL; 8 end 9 else 10

retrieve the certificate through transcryptd;

11

verify the certificate;

12

if verification successful then

13

add certificate to the cache;

14

set valid attribute in the user-interface that corresponds to user, x;

15 return Certificate; 16 else 17 return NULL; 18 end 19 end 20

(52)

4.2.2 Caching details

Linux kernel provides a slab layer [3] to implement caches inside kernel. This layer acts as a generic data structure for caching and provides free lists, which are arranged continuously in memory without fragmentation. These caches are created using the kmem cache create() method. In our case, we create a cache of objects of type cert-cache item. In order to speed up the look up, these objects are arranged in a hash table. When collision occurs, entries mapped to the same entry are put in a list.

struct certcache_item { struct list_head list; u32 uid;

unsigned char *cert; size_t certlen; };

Whenever a new certificate is to be cached, a new object of type struct cache item is created using kmem cache alloc() function. Whenever there is lack of memory inside kernel, slab layer internally calls a shrinker function [3], which iterates through all the caches inside the kernel and frees up memory using kmem cache free() function. TransCrypt certificate cache registers with the shrinker by providing a method to iterate through the hashtable and remove unused certificates.

(53)

4.2.3 Invalidation Details

The user interface for invalidation is created using the configfs [2] communication manager. The communication manager contains TransCrypt’s global parameters (eg. FSK) and a directory ‘users’ for certificate invalidation as shown below.

#/config/transcrypt FSK

users/ /* default directory */

Whenever the transcrypt subsystem is loaded, “users” directory also get auto-matically created in the configfs. This group supports creation of child groups inside them (through the group operations specified in its config item type). Hence one can create sub directories through ‘mkdir’ command within the “users” directory. The sub directory so created shall contain a default attribute, by name ‘valid’. For example, when “mkdir uid1” and “mkdir uid2” commands are executed after loading transcrypt subsystem, the following hierarchy is created in the configfs.

#/config/transcrypt/

FSK /* already existing */

users/ /* default directory */

uid1/ /* user created directory */

valid /* default attribute (aka file) */

(54)

In order to invalidate a certificate in the kernel cache, the user space utilities can be used to set a value 0 (invalid) to the “valid” or by removing the subdirectory as given below.

# echo 0 > /config/transcrypt/users/uid1/valid OR

(55)

Chapter 5 TransCrypt as a Network File

System

TransCrypt was originally designed to work over local storage. Hence, users were expected to access files only at TransCrypt server. Due to the widespread use of remote file systems, an effort is made to re-architect TransCrypt to work as a Network File System. In this scenario, a user can log in at any public workstation to access files from TransCrypt servers over network. This brings certain kind of threats into focus.

This chapter discusses these issues and presents a new authentication protocol for TransCrypt to counter various threats arising from the environment. Implemen-tation details of the solution at the TransCrypt file server side are also provided. Another work by Abhay Khoje [17] discusses the implementation details of this pro-tocol on the public workstation.

(56)

Figure 5.1: Model of File Access

5.1 Remote access threats for TransCrypt

A model of remote file access is shown in Figure 5.1. Here, users can log on to any public workstation with their PKS (such as smart card) to access files stored at a TransCrypt based file server over network using NFS protocol. In this case, the workstation, the file server and the network between them are all vulnerable to many known attacks.

5.1.1 Threats on the File Server

An attacker can launch certain offline and online attacks to get access to the data stored at secure TransCrypt file server.

(57)

5.1.1.1 Offline attacks

In this kind of attacks, an attacker gets physical access to the storage device and may even connect it to another machine to bypass the access control mechanism on the victim’s filesystem. Encrypted file systems prevents such attacks by encrypting the data on the disc. However, the key used for encryption must be kept safe from attack-ers. The M’tech thesis by Satyam Sharma [24] discusses the various key management schemes for various encrypted filesystems and the possible threats on each scheme.

5.1.1.2 Online attacks

These are the attacks in which a malicious user can read the file encryption keys or even the file’s data from system memory, when encrypted file systems are mounted on a system. Some of the attacks might require the super user privileges, but in Trans-Crypt’s case, super users are not trusted. The M’tech thesis by Satyam Sharma [24] describes the possible online attacks on encrypted filesystems.

5.1.2 Threats from untrusted network

5.1.2.1 Eavesdropping

During NFS file operations, the request and the response packets travel unprotected over the network. In this kind of attacks, the attacker can monitor and even record the network traffic for the message content. These attacks are passive attacks in which the messages are not modified by the attacker. This is an attack that breaches

(58)

Figure 5.2: Man-in-the-middle attack

to or read from the file server travels in plain text over the network. Hence, attackers monitoring the network can easily view the contents of the messages. This attack would be a reality even when the TransCrypt with its security features is implemented over NFS.

5.1.2.2 Man-in-the-middle attack

In this attack, the attacker actively monitors the network traffic, captures and controls the communication transparently between two entities. For example, an attacker can install a malicious software on a router and re-route a data exchange. This malicious router as an attacker’s equipment can make independent connections with two entities and relay messages between them. The attacker can makes the two end points believe that they are talking directly to each other over a point to point connection when the entire conversation is seen, modified and controlled by the attacker.

(59)

Consider Fig 5.2, where user usr1 on machine WS1 wants to access its files from file server over the network. Meanwhile, userusr2 on machine WS2 may inter-cept on the conversation. To get started,usr1 sends the file identifier and his user ID to file server over the network. The userusr2 is able to intercept it, thereby initiating a man-in-the-middle attack. usr2 sends a forged message to file server claiming it to originate from usr1 at WS2. File server, believing this message to originate from

usr1 at WS2, sends the response to WS2. Nowusr2 depending on his wish, can send altered data to WS1. When usr1 receives the message, it believes the response to have come from the genuine file server. In this way, a malicious user can get access to a genuine user’s files and is even able to alter his data.

5.1.2.3 Replay Attack

Replay attack involves the re-use of captured data at a later time than originally intended, in order to reap benefits. For example, consider the case where user usr1

wants to get services from user usr2. User usr2 asks for the password as a proof of identity. When usr1 gives his password to usr2, usr3 eavesdrops the conversation betweenusr1 andusr2 and saves the password ofusr1 for later use. Next time,usr3

connects tousr2 posing asusr1 and proving the authenticity by sending the captured password. In our scenario, where NFS is used for file access, the eavesdropper may cache the NFS filehandles. Since NFS is a stateless protocol, these filehandles may be replayed by the eavesdropper later to get access to the files of a user.

Additionally, the implementation of server side TransCrypt looks for user’s PKS only on the file server and not on workstation where the user has logged in. Therefore the file server side kernel sends the user authentication messages to the file server instead

(60)

when the PKS is registered with the file server (i.e. the genuine user is accessing the files).

5.2 Approach

This section describes our approach to block the threats on the file server side and those originating on the untrusted network between the file server and the workstation. Another work by Abhay Khoje [17] analyzes the counter measures for the attacks arising from the workstation and proposes solutions to that.

5.2.1 Preventing Attacks on the File Server

Offline attacks can be prevented by keeping the data encrypted on the disk. In the model that we discuss, the FS is a TransCrypt enabled host. TransCrypt uses a secure key management scheme [25]. It provides per-user access control, per-file encryption and per-volume managerial control. This security framework protects TransCrypt from various offline and online attacks [25]. More details about TransCrypt’s defen-sive mechanisms against these threats can be found in the M’tech thesis by Satyam Sharma [24].

(61)

5.2.2 Preventing Attacks from the Network

5.2.2.1 Eavesdropping

Passive eavesdropping can be prevented by encrypting messages communicated be-tween the server and the client. In the case of TransCrypt, a session key can be established between the workstation and the file server during the user authentica-tion and used for communicaauthentica-tion. The attacker won’t be able to infer the content of the encrypted messages between the two entities thereby protecting against eaves-dropping.

5.2.2.2 Man-in-the-middle attack

Man-in-the middle attack requires eavesdropping and the ability to modify messages. While encryption can prevent eavesdropping, the encrypted message may still be tampered with. This can be protected through message integrity codes.

In case of TransCrypt, two session keys can be established between the file server and workstation kernel, one for confidentiality and another for integrity. There-after, all the messages between file server and workstation are encrypted with confi-dentiality key and added with integrity code derived using integrity key. The eaves-dropper cannot then decode the message or modify it without being noticed.

(62)

5.2.2.3 Replay Attack

Replay attacks can be prevented by providing some kind of freshness with every message.

In case of TransCrypt, replay attack can be prevented by sending the file opera-tion responses to the genuine user encrypted with a freshly generated random session keys. Only the genuine user will then have the correct credentials and the session keys. These keys are established with randomness during log-in time to maintain the freshness.

5.2.3 Additional TransCrypt Modifications

To enable TransCrypt to send the authentication messages to the user workstation, user has to register its PKS location with the file server. This is achieved at the time of log in by the user. Thereafter, the FS kernel will send the authentication messages to the registered PKS location.

Additionally, NFS is prone to user masquerading attack (as described in the thesis by Abhay Khoje [17]). Hence, we need to establish a new process credential between the user login process and the file server kernel to counter this attack. When a user logs in to a work station, unique credentials are established between the login process and the file server kernel. File server kernel stores these credentials in a kernel data structure. Workstation kernel must send the established credentials to the file server during any remote file access by the user. Only upon verification of these credentials, file server gives access to the data.

(63)

5.3 Protocols

We defined a Negotiation protocol between file server and workstation which estab-lishes the common cryptographic parameters and a secure protocol which enables TransCrypt work over network. We also describe the Trust Model which we assumed while developing the solution. Secure Protocol registers the user PKS, performs mu-tual authentication and establishes session keys between file server and workstation kernels.

5.3.1 Negotiation Protocol

Our solution is based on strong cryptographic methods to support mutual authentica-tion and establishment of session keys between file server and workstaauthentica-tion. It makes TransCrypt robust enough to work over network. For this protocol to work, the PKS and file server should agree upon the PKI algorithms and the lengths of cryptographic challenges prior to the start of communication.

PKS can be any secure device such as SmartCard, Mobile Phone, USB tokens etc., which supports public key infrastructure (PKI). In the description here we assume that SmartCard is the PKS in our environment, since it is one of the most secure tool to keep secret keys. Fig 5.3 explains the negotiation protocol.

When a SmartCard (SC) connects to the reader, the workstation sends a

HELO message with a list of supported parameters such as challenge lengths and set of algorithm identifiers for various cryptographic algorithms to the file server.

(64)

Figure 5.3: Negotiation Protocol

cipher specification etc. When file server gets theHELO message, it selects the most suitable algorithm and parameters from among those that it received from the client and sends a WELCOME message (which contains the chosen parameters) to the smart card.

5.3.2 Secure Protocol

The secure protocol enables transcrypt to work over NFS. It consists of mainly three steps.

5.3.2.1 PKS Registration

Location of the user’s PKS is conveyed during log in time to Transcrypt for sending the authentication messages when the user accesses the TransCrypt volumes. This is

(65)

done by a process of registration of user’s PKS location with the file server kernel. File server kernel stores this location (i.e. Smart Card Uniform Resource Identifier (SCURI)) and sends authentication messages for file access to the corresponding user’s PKS.

The file server needs the identification of the user on the workstation before giving access to the files. On NFS, this identification is provided by a common UID. However, this is not possible in our case since the workstation is usually a public one, not under the same administrative control. For the purpose of user identification, the file server uses the certificate of the user provided by the user’s smart card. This certificate is verified and the user’s name is extracted from the certificate. The login program on the workstation facilitates this by reading certificate from the smart card and sending the user’s name along with the UID at workstation and a uniform resource identifier to locate the user’s smart card (SCURI) to the file server. The file server locates the certificate from its repository by matching the certificate name and verifies the validity of the certificate. The workstation gets the file server address from a configuration file in the smart card to communicate with the file server.

5.3.2.2 Authenticated session between workstation kernel and smart card

In order to secure the smart card communication with the public workstation, Abhay Khoje [17] proposed and built a scheme where the smart card and workstation estab-lish session keys for encryption and message integrity. More details can be found in his M’tech thesis.

(66)

5.3.2.3 Authenticated session between workstation and file server kernels

To protect against threats mentioned earlier, the file server and the workstation need to mutually authenticate each other and establish session keys for encryption and message integrity before any file operation. The session keys are generated using equal contributions of key material from the hosts.

The sequence of steps are shown in Figure 5.4.

1. File server kernel sends a random challenge (r fs) and its contribution of the session key (k fs) to the login process on workstation encrypted with the public key of the user. The medium between the workstation and the smart card is vulnerable to many attacks [17]. In our trust model, the login process on the workstation is not a trusted entity as a malicious login process can intercept the messages between the workstation and smart card and can obtain credentials of a genuine user. It may also remember the session key being established between the workstation and file server and use it later to decipher messages flowing between them. Therefore in our design, we use the smart card to establish a session key between the workstation and file server. For this purpose, the gen-uine login process must send the challenge and key material to the kernel of workstation.

There is already a session established between the smart card and the worksta-tion kernel and the corresponding secret key (SK ws sc) is known only to these two entities. Therefore the smart card or the PKS is expected to receive mes-sages only on this secure channel. Hence a malicious login process cannot know the keys and other confidential data such as credentials. In order for the genuine login process to work, it must forward the message to the workstation kernel.

TransCrypt File Server Enhancements for Secure Remote Access

TransCrypt File Server Enhancements for

Secure Remote Access

Salih K A

Indian Institute of Technology Kanpur

TransCrypt File Server Enhancements for

Secure Remote Access

Salih K A

Indian Institute of Technology Kanpur

Abstract

Acknowledgments

Contents

List of Figures

Abbreviations used in the thesis

Chapter 1

Introduction

1.1

Motivation

1.2

Related Work

1.2.1

Distributed File Systems

1.2.2

NFS and Security

1.2.3

Encrypted File Systems

1.3

Contribution of this Thesis

1.4

Organization

Chapter 2

Background

2.1

Network File System (NFS)

2.1.1

NFS Protocol

2.1.2

NFS Architecture

2.2

Linux Security Module (LSM)

2.2.1

Overview

2.2.2

LSM Architecture

2.3

Configfs

2.3.1

User space View

2.3.2

Kernel space View

Chapter 3

TransCrypt Architecture

3.1

TransCrypt in a Nutshell

3.2

TransCrypt Implementation

3.2.1

Kernel space Components

3.2.2

Userspace Programs

Chapter 4

Enhancements for

Modularity and Performance

4.1

TransCrypt-LSM Module

4.1.1

File open

4.1.2

File Creation

4.1.3

File Sharing

4.1.4

Mount filesystem

4.1.5

File Delete

4.2

Certificate Caching

4.2.1

Protocol to Cache Certificates

4.2.2