Framework for accessing TransCrypt File System over Untrusted Public Network

(1)

Framework for accessing TransCrypt File

System over Untrusted Public Network

Abhay Khoje

(2)

(3)

(4)

(5)

Abstract

Data security is the foremost necessity for sensitive applications, especially at the enterprise level. Several mechanisms have been devised for security both at filesystem level and application level. At the file system level, many encrypting file systems (EFS) such as eCryptfs, dm-crypt, FileVault and TransCrypt are available which store file data securely and allow access only to authenticated and genuine users.

All these EFSs however, do not address many serious threats which result when their files are being accessed from public computers (workstations) over an untrusted network. In this thesis work, we have analyzed the possible issues/attacks on public computers (workstations) while accessing an EFS volume over network. To address these problems, we have proposed a secure framework using strong cryptographic methods. We have also implemented this proposed framework in a Linux-based en-vironment for the TransCrypt EFS. The secure framework can be used with any standard EFS with minimal changes.

We also enhanced TransCrypt by eliminating dependency onmkfs.transcrypt

(6)

(7)

Acknowledgements

I would like to thank my thesis guide Prof. Rajat Moona. I would also like to thank Prof. Arnab Bhattacharya, Satyam Sharma and Salih K A.

(8)

(9)

List of Figures

1.1 File access scenario in Public Networks . . . 2

3.1 TransCrypt Architecture . . . 25

5.1 Masquerading attack over Network . . . 39

5.2 Eavesdropping between Smart card and Workstation . . . 40

5.3 Protocol for Negotiating parameters . . . 43

5.4 PKS Registration . . . 44

5.5 Secure Channel between Workstation & Smart card . . . 46

5.6 Secure Channel between workstation & TransCrypt server . . . 49

5.7 NFS create request . . . 50

5.8 NFS access request . . . 51

5.9 Protocol Headers . . . 55

6.1 Write and Read Performance . . . 61

(13)

Chapter 1 Introduction

1.1 Motivation

Today, many organizations like governments, military, different private organizations, financial institutions and hospitals store enormous amount of confidential data. For the purpose of ease of access, this information must be available anytime anywhere. However this poses a problem of security of data. The information must be kept securely and must be accessible only to authorized persons or devices. A survey [1] conducted by Brocade to evaluate the security priorities for data centers noticed many data breach problems. This survey involved various organizations from different parts of the world and covered various different sectors. Some of the organizations were victims of data thefts/loss problems. Some organizations faced identity theft of resource centers. Data thefts/loss imposes risk of losing important personnel and organization data, and hence securing this data is of utmost importance.

Some of the commercial solutions designed to address data security problems include dm-crypt [2], eCryptfs [3], FileVault [4], Microsoft Windows Encrypting File System [5], TransCrypt [6] and so on. They address the problem of protecting the data

(14)

Figure 1.1: File access scenario in Public Networks

in several ways, such as flexible key sharing, per-file per-user encryption mechanism and inclusion of super user in the trust model. These different solutions are explained in brief in the next section.

The aforementioned EFSs fail to solve the issues arising when files are accessed from public computers over untrusted networks. In such a scenario, the public host, the actual file server host as well as the network are vulnerable to attacks. This thesis discusses the major problems and proposes their solutions using strong cryptographic methods. The model that we have assumed is depicted in Figure 1.1.

1.2 Related work

For accessing files from remote hosts Distributed file systems [7] are used. These include Network File System (NFS) [8], Coda [9], Andrew File System (AFS) [10] etc. EFSs secure the file server against various forms of malicious attacks. This section explains distributed and encrypted file systems in brief.

(15)

1.2.1 Distributed File Systems (DFS)

1.2.1.1 Network File System (NFS)

This file system allows a machine to share file volumes with other hosts over a network. It is developed by Sun Microsystem and uses a standardized NFS protocol. It uses Remote Procedure Calls (RPC) for client-server communication. The NFS protocol is stateless. Some salient features of this file system are the following:

• NFSv4 allows servers to delegate directories to clients so that client can perform operations on that files.

• The RPC communication mechanism built over eXternal Data Representation (XDR) is portable across platforms.

1.2.1.2 Andrew File System (AFS)

This file system is a location independent DFS. It mainly consist of two entities namely vice and venus. Venus is client side entity which caches files from AFS servers for better performance. Vice is a group of AFS servers that share a common file volume. Salient features of AFS are mentioned below.

• Caching files and directories on local disk to increase the performance. • Kerberose is used to authenticate the users.

• Scalability is achieved through a collection of servers that present a single co-hesive file system.

(16)

1.2.1.3 Coda

Coda [9] supports high data availability and is resilient to network failures. In Coda, server and client communicate through the Remote Procedure Call (RPC) mechanism. The client runs a process which handles a remote file systems request. The Coda client caches the files and directories on the local disk as in AFS. Once these files are cached, server notifies the client when any other client tries to modify the cached files through the callback mechanism. Salient features of this file system are the following.

• It is resilient to network failures by maintaining copies of a file at multiple servers.

• Kerberos is used for authentication of users.

1.2.2 Encrypted File Systems (EFS)

An encrypting file system attempts to prevent several attacks on the file server as dis-cussed earlier. Some encrypting file systems are File Vault [4], dm-crypt [2], eCryptfs [3], TransCrypt [6] etc.

1.2.2.1 eCryptfs

eCryptfs [3] is a kernel space enterprise-class EFS. eCryptfs can register in the kernel VFS as a lower file system (for example, ext2, ext3, NFS etc). The operations under the eCryptfs mount point go to eCryptfs implementation in the kernel. This imple-mentation first retrieves keys from the user space and then using the Linux Kernel CryptoAPI encryption and decryption of file contents is performed.

eCryptfs uses a unique File Encryption Key (FEK) which is randomly gener-ated and used to encrypt and decrypt individual data in each file. The File Encryp-tion Key is encrypted with another system wide key known as File EncrypEncryp-tion Key

(17)

Encryption Key (FEKEK). The encrypted FEK (EFEK) is maintained in the file’s metadata. Users can send the file encrypted by the eCryptfs to other users. The recipients can get the contents of the file (plain text) through eCryptfs if they have the proper key for decryption.

1.2.2.2 dm-crypt

It is a device based EFS and is a part of the standard Linux kernel. It is implemented as a device mapper (DM) infrastructure in Linux kernel space. It encrypts data to be stored in block devices. User space utilities like cryptsetup and cryptmount are used to create and activate the encrypted volumes. The main advantages of block device encryption mechanism are in its simplicity in concept and implementation, and that the attackers can not have any information about the file system. However the major disadvantages of such block device encryption are in key management. — difficult to change the keys and ciphers, and in the inability to encrypt files of different users with different keys. In such systems, it is highly inconvenient to resize the partition once created.

1.2.2.3 TransCrypt

TransCrypt [11, 12, 13] is a secure, transparent, usable and efficient enterprise-class EFS for Linux. It has a stronger trust model and hence provides stronger security than other existing solutions. In this system only the kernel remains under the trust domain of the user. It includes a set of simple user space daemons and support utilities for administration. It reuses pre-established enterprise security frameworks such as Public Key Infrastructure for user access control and provides support for data recovery, backups etc.

(18)

Crypt [6] was aimed only at the ext3 filesystem. Such integration with a particular file system implementation made TransCrypt non-generic. Arun Raghavan’s work [12] modified the core TransCrypt architecture into a file system independent layer using extended attributes supported by the underlying file systems for meta data storage. This greatly improved code maintainability and flexibility.

Earlier implementations of TransCrypt [6] had several maintenance and per-formance limitations. Sainath Vellal’s work [13] removed the limitations related to file Input/Output performance and maintenance issues. His work also added support for direct Input/Output operations that bypass the page cache.

1.3 Contribution of this Thesis

Earlier versions of TransCrypt [11, 12, 13] were not designed to work over public networks. The user had to login to TransCrypt server to access the files of TransCrypt volume. This is because TransCrypt was designed to send authentication tokens to the TransCrypt server instead of sending it to the user workstation.

In this work, a protocol that makes TransCrypt volume accessible over network with protection against the vulnerabilities of the channel between TransCrypt server and workstation is designed. This designed protocol also protects the TransCrypt volume from the Masquerading attack by using the process credentials approach. In addition to this, the utilities for creating and mounting of TransCrypt volume,

mkfs.transcrypt and mount.transcrypt are removed. The configuration parameters of TransCrypt are passed during creation of device mapper layer throughdmsetup.

(19)

1.4 Organization

This thesis is structured as follows. In chapter 2, we give an overview of the back-ground literature in the field of Network File System, Process credentials and device layer of Linux kernel used in this work. In chapter 3, the system design of the Trans-Crypt version 0.2 is explained. In chapter 4, we discuss our design which aims to remove the dependencies on helper utilities, mkfs.transcrypt and mount.transcrypt. In chapter 5, we describe issues of the previous version of TransCrypt, approaches to address the same and the new secure protocol which solves the issues explained. In chapter 6, the performance strategy and analysis of the results comparing with the plain NFS with the TransCrypt over NFS are discussed. Chapter 7 concludes the thesis and provides pointers to future work.

(20)

(21)

Chapter 2 Background

Asecure protocol is developed to make TransCrypt volumes network-accessible. This

secure protocol is free from several attacks such as eavesdropping, masquerading at-tack, IP spoofing etc. This is achieved by registering the Private Key Store (PKS) of the user to TransCrypt server, establishing a secure channel between the kernels of TransCrypt server and the workstation and assigning process credentials to gen-uine login session. PKS registration is done during login time by using PAM module. PAM module communicates with the WS kernel throughioctl to establish session key with FS kernel. This chapter describes the essentials of NFS protocol, ioctl, Process Credentials and PAM module.

2.1 Network File System

NFS [14] gives the privilege of accessing a remote file systems by mounting them on workstation and by using them as local file systems. This allows the organization to store their data in a central repository and give access to the users. NFS operates on heterogeneous environments of different computers, operating systems and network

(22)

architectures. This is attained through the use of RPC mechanism built over the external data representation (XDR) protocol. Network file system makes use of two protocols, mount protocol and NFS protocol for remote file access.

• Mount Protocol: The initial connection between client and server is established by the mount protocol. A mount operation requires the name of the remote directory to mount and the server name where that directory is located. A mount request containing this data is dispatched to the NFS server machine which maintains a list of file systems that it permits for mounting (i.e. exports) along with the names of the machines that are permitted to mount them. This list is typically maintained in /etc/exports file. During any mount request, the NFS server checks in the exports file and returns a file handle data structure to client if the basic permissions are satisfied. This file handle is used by the client for further access to the files within the mounted file system.

• NFS Protocol: The NFS protocol provides a set of RPCs to access files remotely. An important feature of the NFS protocol is that NFS servers are stateless. Servers do not maintain the information about the clients. This feature avoids the crash recovery mechanism and simplifies the NFS protocol. Further implica-tion of this stateless nature is that modified files must be written to the disk at the server before returning the results to client. As mentioned earlier, RPCs are used for the client-server communication to provide a platform independence to the protocol. To map RPC requests to the appropriate services, aportmap dae-mon is used. Portmap daedae-mon maintains a program number and port mapping provided by an RPC providers. This information is provided during the time of registration. The role of the portmap daemon is to redirect the NFS client to the appropriate RPC service provider at server. The portmap daemon also

(23)

uses some configuration files for verifying the authenticity of the NFS client.

2.1.1 NFS Procedures

An NFS server is an RPC service provider. The NFS protocol is defined by a set of procedures which accept input arguments and return results defined in an RPC language. The following section explains in brief some of these procedures and their arguments.

• NFS LOOKUP: This procedure is used to search a file for a specific name and returns the corresponding file handle. The input and output arguments struc-tures of this procedure are the following.

struct LOOKUPargs { diropargs file; }; struct LOOKUPres { nfs_fh object; post_attr obj_attr; post_attr dir_attr; };

• NFS ACCESS: This procedure is used to determine the access rights for a file system object. NFS client sends a set of permissions that are to be checked in a bit mask. NFS server checks for the permissions encoded in the bit mask and returns a result. The input and output arguments structures of this procedure are the following.

(24)

struct ACCESSargs { nfs_fh object; uint32 access; }; struct ACCESSres { post_attr obj_attr; uint32 access; };

• NFS READ: This procedure is invoked while reading data from a file. It ac-cepts the structure READargs as input and returns the response in READres structure as shown below.

struct READargs { nfs_fh file; offset offset; count count; }; struct READres { count count; bool eof; opaque data<>; };

• NFS WRITE: This procedure is used by a client to write data in a remotely located file. The input and return arguments structure are shown below.

(25)

struct WRITEargs { nfs_fh file; offset offset; count count; opaque data<>; }; struct WRITEres { wcc_data file_wcc; bool eof; writeverf verf; };

2.2 Process Credentials

Linux operating system supports a variety of credentials for processes. Each process or task carries credentials by which the authenticity of a process is established to perform permitted operations. For example, a process has credentials [15] such as effective user and group id. These credentials preserve the integrity of the user’s personnel and confidential data and form context known as subjective context. This context is used when the process accesses objects like socket, files etc. The objects carry objective context which indicates the users/groups which have permission to use the object. The subjective context is compared with the objective context to find whether the operation on the object is permitted or not. As an example, consider file as an object. Each file is owned by a specific user and/or specific group of users. The filesystem checks the permissions established by the file owner and the process credentials, when any process tries to access the resource. If it is legal then only the user gets the access to the file.

In the earlier design of Linux, a process carried only UID and GID as creden-tials. These credentials are called as traditional process credentials, which are shown

(26)

in Table 2.1.

Name Description

uid and gid User and Group Real identifiers euid and egid User and Group Effective identifiers

esuid and esgid User and Group Effective identifiers for File Access groups Supplementary Group Identifiers

suid and sgid User and Group Saved identifiers Table 2.1: Traditional process credentials

However thesetraditional process credentials of the process would not prevent an attacker to perform the masquerading attack. To prevent such an attack, process should carry some new credentials which should be established only during login time. The design of Linux kernel (version 2.6.26) supports such a feature by having an extra generic pointer in the process structure. This pointer can be used to refer to a variable that stores new credentials (established during login time) of the process as shown below.

struct task_struct { uint_32 uid; uint_32 gid; uint_32 euid;

... several other parameters ...

void *security; /* This variable is used for new creds */ };

2.3 ioctl Module

User space and Kernel space are the two layers of the Linux operating system. Ap-plications like text editor, movie player etc. reside in the user space. On the other hand underlying facilities of the OS such as system calls, network stack, device drivers etc. reside in the kernel space. Operating system protects kernel resources from user

(27)

space applications for direct access. Such protection is implemented by the processor hardware and managed by the operating system.

User space applications communicate with the kernel through system calls. These system calls are implemented in the kernel space. A systems call is in the form of vector known as “system call vector”, in which the system call is stated with a number. For example, read system call has the system call number 3, and write has the system call number 4 in Linux kernel 2.6.26. The system call vector is used by the kernel to find the desired kernel code to instantiate when user space application makes a system call.

System calls are used for accessing standard kernel facilities like reading data from a file or writing data to a file. However to access non-standard devices or services from user space, standard system calls cannot be used. This problem is solved by Linux Kernel through a new design which accepts an extra module called a device-driver. This device driver runs in kernel space and addresses the device. An ioctl is a system call through which the user space processes communicate with device-drivers. The requests that come for the device-driver are identified by a handle (open file descriptor) and the request number. The Linux Kernel allows the user space processes to access a device-driver through a generic ioctl system call.

2.3.1 Implementation of

ioctl

Module

Linux ioctl [16] system call takes the following three parameters: 1. fd: an open file descriptor

2. num: a request code number

(28)

The Linux Kernel sends anioctlsystem call straight to the device driver. The device driver then interprets the code request number and the data in the way they required. These request code numbers are fixed and are specific to a device driver. There is also a provision that the request number can be assigned dynamically to the device driver. The device drivers may use the non-specific but fixed request numbers for the ioctl system call in the following structure.

static long gen_cred_ioctl(struct file *file,

uint command, ulong u) {

/* Code to execute for ioctl system call*/ }

static const struct file_operations _ctl_fops = { .unlocked_ioctl = gen_cred_ioctl,

.owner = THIS_MODULE };

static struct miscdevice _device_misc = { .minor = MISC_DYNAMIC_MINOR, .name = "gen_cred",

.fops = &_ctl_fops };

2.4 Pluggable authentication Module (PAM)

User authentication is done by verifying credentials of user such as user name and password, when the user attempts to log on to a machine. In Linux, user authentica-tion has tradiauthentica-tionally been performed by a user space login program that can set the credentials of the login process to the user’s credentials after successful verification

(29)

of provided password against the one stored in /etc/passwd file. The newer Linux versions have externalized the setting up the credentials and user authentication by al-lowing various other authentication schemes such as smart card-based authentication, authentication servers etc. The externalization is facilitated by the use of pluggable modules called Pluggable Authentication Modules (PAM) [17]. A system administra-tor can specify the required PAM module to be used for user authentication in the configuration file.

2.4.1 PAM Concepts

A Pluggable Authentication Module has four groups of authentication and authenti-cation related management submodules which are explained below.

1. Authentication: The authentication submodule performs tasks related to the authentication of a user and establish the user credentials. It provides two primitive methods for doing this, pam_authenticate and pam_setcred.

2. Account management: It handles user’s account related issues. It provides one primitive function pam_acct_mgmt.

3. Session management: It provides two primitive functions as explained below. • pam_open_session: This primitive is used when a user logs in to the

system. It performs operations when user log on to a machine.

• pam_close_session: This primitive is used when the user logs out of the

system. It performs operations when user log out from a machine.

4. Password management. This module is used to modify the credentials of the user, either because password is no longer valid or he/she wants to modify it.

(30)

To build an authentication scheme, the system administrator may use different li-braries for these submodules. Consider the following example as specified in the configuration file.

login auth optional pam_nologin.so warn login auth optional pam_env.so warn

This sample configuration file indicates that for the login service, invoke two modules serially pam nologin.so and pam env.so.

2.4.2 Implementation of PAM module

In TransCrypt, we have implemented the Session Management primitives, namely pam close session and pam open session as part of secure protocol implementation. This subsystem will perform the functions required for authentication task when a user logs in to the system in pam open session primitive and cleanup operations when a user logs out in pam close session primitive. There is a structure known as pam module which needs to be defined in the PAM module code. Pam module

structure contains six function pointers for the six functions to be executed.

Sample module code which has implemented the Session Management primi-tives is shown below. The module code defines the pam module structure where two function pointers are assigned for session management primitives. These two functions are pam sm open session and pam sm close session. pam sm open session function is assigned for pam_open_session session primitive, which is called when user logs in. Hence, this function is used to perform authentication tasks (other than default authentication). Pam sm close session function is assigned for pam_close_session

session primitive, which is called when user logs out. Hence, this function is used to do the session cleanup tasks.

(31)

struct pam_module _pam_transcrypt_modstruct = { "pam_transcrypt", /* Module Name */ NULL, /* Auth Primitive */ NULL, /* Auth Primitive */ NULL, /* Account Primitive */ pam_sm_open_session, /* Session Primitive */ pam_sm_close_session, /* Session Primitive */ NULL /* Password Primitive */ }

PAM_EXTERN int pam_sm_open_session(pam_handle_t *pamh, int flag, int argc, const char **argv) {

/* Do Work to set up the session */ return PAM_SUCCESS;

}

PAM_EXTERN int pam_sm_close_session(pam_handle_t *pamh, int flag, int argc, const char **argv) {

/* Do Work to close the session */ return PAM_SUCCESS;

(32)

(33)

Chapter 3 TransCrypt Implementation

The initial prototype of TransCrypt was developed by Satyam Sharma [11] for Linux environment. The cryptographic layer of the TransCrypt was developed by patching the Linux kernel code. Later, TransCrypt was modified to make it independent of underlying file system (like ext2, ext3, JFS and so on) by Arun S R [12] and a new layer of cryptography was implemented [13] to achieve file Input/Output performance enhancements. This chapter gives a brief overview of this version of TransCrypt on Linux kernel 2.6.23.

3.1 TransCrypt Features

TransCrypt EFS was implemented with a strong trust model in Linux kernel space. The superuser account is excluded from the trust model. The main design goals of TransCrypt are confidentiality and shareability of user’s files. Some of the salient features of the TransCrypt are as following.

(34)

3.1.1 Per-file Encryption

Whenever any file is created, a unique File Encryption Key (FEK) is generated ran-domly for that file. This per-file confidentiality mechanism is supported by other mechanisms to make a robust access control and to implant confidentiality of keys.

3.1.2 Block level Encryption

The cryptographic layer of TransCrypt is implemented with the help of the de-vice mapper (DM) infrastructure of Linux Kernel through a loadable module, dm-transcrypt. This module provides a virtual device that maps to the TransCrypt volume through the block layer device mapper mechanism in Linux that does fast bulk encryption and decryption. The dmsetup utility is used to create the virtual block device which maps to the TransCrypt volume on a real block device. While setting up the virtual block device the name of the virtual device is specified along with the real target device. Further operations are then performed on the virtual block device which causes the dm-transcrypt layer to be invoked.

3.1.3 Strong Cryptographic Scheme

FEKs are generated randomly for each newly created file. When the file owner wants to give access to users, he/she has to share the corresponding FEK with them. This sharing creates a problem later for access revocation of such users. Therefore, in addition to the per-file encryption, the access control mechanism needs to apply on a per-user basis as well. This mechanism is achieved by encoding FEK with subject’s public key. The whole blob is then called atoken. When user wants to access a file, he needs to decrypt the token and sends back the FEK for that file to the TransCrypt kernel. This scheme of encrypting FEK with a public key has a small flaw, the user

(35)

can deduce the FEK using his/her private key when user gets token for decryption. Thus, even if access is revoked for the user, he/she can still continue to access the file through a previously cached FEK. Therefore, in TransCrypt we use a “blinded” FEK in place of the actual FEK. The blinding is achieved by encrypting the FEK with another file system-wide symmetric key (FSK). The FSK is provided to the kernel at the time of mounting the TransCrypt volume through a passphrase mechanism, and is known only to the kernel. The file encryption key (FEK) blinded by encryption (through FSK) is then converted to a per-user token by using the subject’s public key as follows.

token=E_uP(E_fskS (F EK))

The user tokens are then stored in the “user.transcrypt.tokens” extended attribute.

3.1.4 Minimal trust model

We employ a minimal trust model in TransCrypt such that only the least number of entities are required to be trusted. Trusted cryptographic operations are implemented in the kernel and are used by TransCrypt. Specifically, TransCrypt excludes super user from its trust model and user space daemons are untrusted even when they run with the super user privileges.

3.1.5 Data Recovery Agent (DRA)

To cope with the typical enterprise requirement of recovering data when an encryp-tion key is lost, a DRA is added as a special user while creating the filesystem. A “default” token entry for the DRA is made in root directory’s EA. This is subsequently

(36)

(automatically) copied to all files and directories on the file system. The private key corresponding to DRA is broken among multiple users for greater security.

3.2 TransCrypt Architecture

TransCrypt architecture is shown in Figure 3.1. It includes a set of user space utilities and and a set of enhancements to kernel space software. The kernel space software includes the VFS-Core, dm-transcrypt layer, PKI implementation along with CA store and certificate cache.

3.2.1 VFS-Core

Earlier work on TransCrypt [12] introduced changes in generic file system layer (VFS) to incorporate TransCrypt security semantics. These changes were in the form of patches to VFS procedures. Modifications were made to the vfs_kern_mount pro-cedure to store and retrieve TransCrypt’s configuration parameters during mkfs and mount operations respectively. The open_namei_create and may_open VFS proce-dures in the kernel were modified to include TransCrypt-related changes in the create and open file operations respectively. Groups ACL entries are not supported in Trans-Crypt; therefore changes were also made in the posix_acl_valid VFS procedure to disable group-level or other-level file access in TransCrypt.

3.2.2 File system Operations

File system operations are initiated by a user process through VFS-system call. These system calls are then redirected to the TransCrypt component through the VFS. We provide the steps taken by TransCrypt for these file system operations.

(37)

Figure 3.1: TransCrypt Architecture 3.2.2.1 Create

TransCrypt performs the following operations when a process creates a file. 1. FEK is generated randomly for the file.

2. This FEK is then blinded by encrypting with the symmetric file system key (FSK).

(38)

4. Kernel verifies the certificate and extracts the public key from that.

5. The subject’s public key is used to encrypt the blinded FEK and form the token. 6. This token is then stored as meta data in user.transcrypt.tokens EA.

3.2.2.2 Open

The following operations are performed during the open operation.

1. Token for the user corresponding to the UID of the process is retrieved from the extended attribute of the file.

2. Kernel creates a secure channel with the corresponding subject’s Private Key Store (PKS) through an auth server.

3. This token is then sent to the smart card through the secure channel.

4. PKS decrypts the token and sends blinded FEK back to the kernel on secure channel.

5. The kernel then decrypts blinded FEK to recover the FEK.

6. This FEK is then stored in the TransCrypt keyring for further read and write operations on the file.

3.2.2.3 Read/Write

The following steps are carried out by TransCrypt when a process makes read or write system call or perform an I/O through memory mapped files.

1. FEK is retrieved from the TransCrypt keyring.

(39)

2. In write operation, encrypted data (with FEK) is written to the TransCrypt volume.

3. In read operation, encrypted data is read from the TransCrypt volume and is then decrypted with the FEK before passing it to the user process.

3.2.2.4 Changing Permissions for files

The permission may be changed either to provide or to revoke access to files.

1. Providing Access: A user can only provide access to a subset of those permissions that he has on the file to others. When such a user performs asetfacloperation for sharing access, its token is sent for decryption to get blinded FEK. The new subject’s public key is used to encrypt this blinded FEK and form the new token. The new token is then maintained in file’s EA along with previous tokens. 2. Revoking Access: This is done by removing the token of that user from the

extended attribute. Access may be revoked by the user himself or by the owner of the file, or by another user who has a write access to the directory.

3.2.3 Keyring

TransCrypt generates a FEK for each newly created file. This FEK is used for encod-ing and decodencod-ing of the contents of the said file. To allow fast use durencod-ing subsequent read and write operations, FEKs need to be cached in kernel memory when file is opened. For this purpose, the a keyring [18] infrastructure is provided in the Linux kernel where keys can be stored along with their descriptions. A key description is used later to search keys from the keyring. TransCrypt utilizes this infrastructure to implement a separate TransCrypt keyring to store its FEKs.

(40)

Opening a file the first time leads to the retrieval of the FEK by decrypting the subject’s token. This FEK is then stored in the TransCrypt keyring. The address of the in-core inode of the file is stored as the description for the key, as the inode address is unique for every file. Hence, for the write/read operations on that file, the FEK is searched in the keyring using the in-coreinode address. If new FEKs cannot be accommodated in the keyring, then least recently used keys are evicted from the keyring. The procedure of removing the least recently used keys from the keyring is calledkey reaping.

3.2.4 Enhanced CryptoAPI

The Linux kernel CryptoAPI [19] supports only symmetric cryptographic operations. These symmetric cryptographic operations are used in TransCrypt for data encoding and decoding. TransCrypt requires asymmetric cryptographic operations for authen-tication and token acquisition. Hence, the CryptoAPI was enhanced to add support for the following features.

1. Support for the asymmetric cryptography algorithm, RSA. 2. Support to parse and verify X.509 certificate.

3.2.5 User space Modules

TransCrypt uses two daemons Transcryptd and Transcrypt-auth to help the kernel for key management tasks.

3.2.5.1 TransCrypt daemon

Transcryptd is a mechanism for the kernel to get certificates for the users and to do private key operations implemented in program to run in user space. It performs the

(41)

following two tasks.

• Retrieval of user certificates from the certificate repository (/usr/local/etc/transcrypt/certs) when there is a miss in the kernel certificate cache.

• Forwarding of all messages for private key based operations to auth server.

3.2.5.2 Transcrypt authserver

This is an interface to subject’s PKS, such as Smart Card, USB drive, etc. Earlier version of TransCrypt auth [12, 13] supported only file based PKS. In these versions a token decryption request is sent by transcryptd to transcrypt-auth. It checks the

certab file (This file stores the mappings of subject’s certid and the corresponding private key file location) and gets the private key to decrypt the token that is then replied back to transcryptd for forwarding it to the kernel.

3.2.5.3 Utilities

There were two wrapper utilities to mount and mkfs programs, namelymount.transcrypt

and mkfs.transcrypt for mounting and creating TransCrypt volumes.

1. mkfs.transcrypt: This program is a wrapper over the standard mke2fs [20] pro-gram for creating a TransCrypt volume. This propro-gram prompts the adminis-trator creating the new file system for a passphrase and derives the FSK from it using the standard Passphrase Based Key Derivation Function (PBKDF2). This FSK is then passed to mke2fs that initializes the extended attribute. 2. mount.transcrypt: This program is a wrapper over the standardmount [21]

util-ity for mounting a TransCrypt volume. This utilutil-ity accepts the pass phrase from the user and then generates the FSK from it as was done in mkfs.transcrypt.

(42)

FSK is then hashed and then passed to the kernel using configfs [22]. After passing the FSK through the configfs, it mounts the file system using the stan-dard mount mechanism. The kernel then checks the FSK with the one stored in the extended attribute. It succeeds only if both FSK hash values match.

Apart from these utilities, there are some helper scripts for adding and removing the user certificates from the certificate store. Similar helper scripts are written to add private keys information to be used by TransCrypt authserver.

(43)

Chapter 4 TransCrypt Configuration

Earlier versions of TransCrypt [11, 12, 13] used themkfs.transcrypt and mount.transcrypt

utilities to pass configuration parameters such as cipher specification, key lengths etc to the TransCrypt kernel. In this thesis work, we remove the dependency on these helper utilities by passing these configuration parameters through a standard utility called dmsetup.

4.1 Configuration Parameters

TransCrypt requires the following parameters to be configured before it can be used. FEK Cipherspec: This field corresponds to the cipher specification containing the algorithm, the chaining method and the IV options for file encryption. The format of this field is“<FEK algorithm>–<Chaining mode>–<iv options>”. For example, “aes-cbc-plain” denotes AES encryption algorithm with cipher-block chaining (CBC) mode and plain mode of IV (i.e. the initial vector is the sector number, padded with zeros if necessary). The possible values for algorithm, chaining mode and IV options are shown in the following table.

(44)

FEK Algorithm aes, des Chaining mode ecb, cbc

IV options null, plain, essiv

FEK size: This field corresponds to the length of the File Encryption Key (FEK) in bits such as 128, 256 etc.

FSK Cipherspec: This field corresponds to the cipher specification containing the algorithm, the chaining method and IV options to encrypt FEK. The format of this field is same as that of theFEK_Cipherspec.

FSK size: This field corresponds to the length of the File System Key (FSK) in bits such as 128, 256 etc.

FSK: FSK is a system wide key. This symmetric key is used to blind the FEK preventing its exposure. It is passed through a configfs [22] subsystem into the kernel.

4.2 Design

In the earlier implementation of TransCrypt, the configuration parameters were com-bined as a single byte array and were stored the root directory’s “user.transcrypt.params” extended attribute. This attribute is created by themkfs.transcrypt when initial-izing the volume. This user.transcrypt.params is read by TransCrypt kernel at mount time and extracts parameters in the in-core struct.

The earlier implementation [11, 12, 13] was therefore dependent on two helper utilities, mkfs.transcrypt and mount.transcrypt for handling configuration pa-rameters. As a part of this work, we remove the dependencies on these user space

(45)

wrapper utilities. In our implementation, the standard mkfs and mount utilities can be used for creating and mounting TransCrypt volumes.

The configuration parameters are now passed through the standard dmsetup

command to the device mapper module, dm-transcrypt. dm-transcrypt module’s constructor parses these parameters and stores them in in-core kernel data struc-ture. When the TransCrypt volume is mounted for the first time, these parameters are extracted from dm-transcrypt’s in-core structure and stored in the root direc-tory’s extended attribute. In subsequent mount operations, the parameters stored in extended attribute and parameters provided by the user (through dmsetup) are compared. The mount operation (Algorithm 1) succeeds only if both these sets of configuration parameters match. If a user does not provide configuration parameters through dmsetup in subsequent mount operations, then the TransCrypt kernel uses parameters from the extended attribute.

(46)

Algorithm 1: TransCrypt Mount Operation Data: Mount Point

Result: error or success

if Mount point 6= transcrypt volume then

1 return success; 2 end 3 transcrypt-ea-params ← vfs-get-xattr(); 4 transcrypt-dm-params ← get-dm-params(); 5

if transcrypt-ea-params not set then

6

if transcrypt-dm-params not set then

7

/* Use default transcrypt params */

transcrypt-params ← transcrypt-default-params;

8

else

9

/* Use dmsetup transcrypt params */

transcrypt-params ← transcrypt-dm-params;

10

end

11

/* Store params in the extended attribute */ vfs-set-xattr(transcrypt-params);

12

else if transcrypt-dm-params not set then

13

/* Store transcrypt params from extended attribute */

transcrypt-params ← transcrypt-ea-params;

14

else

15

/* Compare both the params */

if transcrypt-dm-params 6= transcrypt-ea-params then

16

/* If they are not matched then return an error */

return error; 17 else 18 transcrypt-params ← transcrypt-ea-params; 19 return success; 20 end 21 end 22 return success; 23 34

(47)

4.3 Implementation Details

4.3.1 User space Changes

The mkfs.transcrypt and mount.transcrypt are now not necessary. The standard mkfs and mount commands can instead be used to create and mount TransCrypt volumes.

4.3.2 Kernel space Changes

Two Linux Kernel Modules namely dm-transcrypt and lsm-transcrypt [23] are modi-fied to implement the proposed design.

1. dm-transcrypt: TransCrypt configuration parameters are parsed in the device mapper module, dm-transcrypt. The following steps are performed while map-ping a virtual device to a real device through dmsetup.

(a) The dm-params flag is set if a user has provided the configuration param-eters during dmsetup.

(b) The FEK Algorithm, FEK Chainmode and FEK ivopts parameters are extracted fromFEK_Cipherspecand stored in thecrypt_configstructure of dm-transcrypt.

(c) The similar parameters for FSK are extracted fromFSK_Cipherspecstring and stored in thecrypt_configstructure of dm-transcrypt.

(d) FEK_length and FSK_length are converted to integers and stored in the

(48)

2. lsm-transcrypt: Linux Security Module (LSM) [24] provides hooks in the VFS layer. These hooks are implemented in the lsm-transcrypt [23] security module. There is an LSM hook for post mount operation known assb kern post mount. Our changes are implemented through sb kern post mount hook to provide a corresponding handler in the module. The following steps are performed during mount operation (Algorithm 1).

(a) Check the encrypt option in the mount parameters. If this option is not passed, then returnsuccess(since the volume is not a TransCrypt volume) else continue with step (b).

(b) Retrieve configuration parameters from dm-transcrypt’scrypt_config struc-ture (dm-params) and from the extended attribute (ea-params).

(c) If both dm-params and ea-params are not set then use default configura-tion parameters.

(d) If only one of dm-params or ea-params is provided, then it is used to provide configuration parameters.

(e) If both dm-params and ea-params areprovided, they are compared. If they match, then the success is returned else appropriateerror is returned.

(49)

Chapter 5 TransCrypt over NFS

In this chapter we discuss various vulnerabilities in TransCrypt due to access from a workstation (public computer) over untrusted network. We also analyze the corre-sponding threats and attacks in detail. Our new design addresses these issues and we show how the new secure protocol effectively addresses such issues. In the following discussion we use the notations as given below.

• E_uP(m): This indicates the message m is encrypted with subject’s (u) public key.

• ES

k(m): This indicates the message m is encrypted with symmetric key, k.

5.1 Threats

TransCrypt authentication mechanism is a challenge response authentication mech-anism. TransCrypt throws a challenge to the subject’s PKS encrypted with his/her public key. The PKS then decrypts the challenge and sends back an appropriate re-sponse to TransCrypt. In comparison, NFS usesUID based authentication when user

(50)

accesses remote files over the network. This UID based authentication is not as se-cure as that of TransCrypt, which usespublic key cryptography. However TransCrypt volumes were not accessible over network, users had to login to TransCrypt server to access files of TransCrypt volume. This is because it was designed to send authenti-cation tokens to TransCrypt enabled kernel and not to workstation. The transcrypt server, the public workstation and the network medium are vulnerable to attacks. Such issues were not addressed earlier since TransCrypt was designed to work on the file server only. This section discusses the major attacks due to vulnerable network. Salih K A [23] also addresses the attacks possible on TransCrypt server.

5.1.1 Masquerading attack

A masquerading attack takes place when an entity poses itself as another entity. This is the attack in which a privileged user can acquire the identity of another user (e.g. using ‘su -’) and can access the files of a genuine TransCrypt user. The NFS suffers from this problem due to its UID based authentication.

Consider Figure 5.1 where userusr1 is logged in on machine WS1. User usr1

has inserted his smart card in WS1 to get access files from TransCrypt server. At the same time if user usr2 has super user credentials of machine WS2 then he can get maliciously access to files of userusr1. For this, Userusr2 logs in to machineWS2 and acquires the identity ofusr1 (using ‘su - usr1’). In order to get access to files of usr1, usr2 would send an access request to TransCrypt server as usr1. TransCrypt server host uses the TransCrypt access control mechanism to get access to the operations with private key of usr1 (earlier registered at WS1) and thus provides access to user usr2.

(51)

Figure 5.1: Masquerading attack over Network

5.1.2 IP spoofing attack

In this kind of attack the remote machine acts as a node on LAN to find attacks on the servers. The attack mechanism is to fabricate data in a manner that makes it appear to originate from a trusted host when it did not.

5.1.3 Eavesdropping between Private Key Store and

Work-station

This is a network attack in which an attacker monitors or listens to the traffic between workstation and smart card and interprets the unprotected data. In our design, we establish credentials between the kernels of TransCrypt server and workstation to protect against a masquerading attack as explained later. The TransCrypt server generates credentials and communicates it to the workstation. This communication is secured by encryption with the subject’s public key (Figure 5.2) and for decryption, this message is sent to PKS. If the decrypted credentials are sent back in plain text, an

(52)

attacker can eavesdrop the traffic and can get hold of the credentials. An attacker can assign these credentials to his/her malicious session and get access to the TransCrypt files. This attack is illustrated in the Figure 5.2.

Figure 5.2: Eavesdropping between Smart card and Workstation

5.2 Approach

The earlier implementation of TransCrypt did not look for the subject’s PKS on the workstation. We solve this problem by registering the PKS of the user with the TransCrypt server kernel. TransCrypt server saves this location and for the future file operations, authentication tokens will be sent to the user’s registered PKS location.

In this section we describe an approach to solve the attacks files are accessed over networks using NFS.

5.2.1 User masquerading attack

The NFS protocol is susceptible to a masquerading attack. The processes of the masqueraded session can have the UID same as that of the genuine user. In a public network the UID can not be the same at two sides. Therefore, UID based authenti-cation is not sufficient to protect TransCrypt volume from this attack. TransCrypt

(53)

server kernel must have mechanisms to differentiate between the genuine session and a masqueraded session in order to mitigate this attack. To differentiate between these two sessions, we establish some unique credentials between the TransCrypt enabled kernel and the user login process. These are also sent to the TransCrypt server by the user’s workstation during file access. TransCrypt server kernel will verify these credentials and give access to only those operations coming from a genuine user. Since the masqueraded sessions will not have the correct credentials, it will not get access to the files.

5.2.2 IP Spoofing

IP spoofing from malicious host can be prevented by mutually authenticating both computers i.e. workstation and TransCrypt server prior to perform any file opera-tions. Along with the authentication, session keys are also established between the hosts. The TransCrypt server’s responses will be encoded with the key that is already established. Only the genuine workstation can decrypt that response. Therefore even if an IP address is spoofed, the session key is not available to the fake machine. The use of the session key provides security against the man-in-middle attack also; since the attacker does not have the session key to decrypt the response, it will not able to extract the information. Further the messages are protected against modifications by message integrity code. The attacker will not be able to compute this without knowing the corresponding session key.

5.2.3 Eavesdropping between Workstation and Smart card

This threat is mitigated by establishing a session key between workstation and smart card. The traffic between workstation and smart card is encrypted with the session key

(54)

established between them. Hence only the genuine workstation and smart card can decrypt the messages between them. An attacker can not interpret the communication between them.

5.3 Trust Model

This thesis gives the design of the access mechanism on workstation side to enable secure netaccess of TransCrypt volumes. The assumed trust model for the work-station is as described below.

• Super user on workstation is partially trusted not to install a malicious kernel image over a system reboot.

• Workstation kernel is trusted, not to maliciously assign credentials to unrelated processes and to send the correct credentials only when the genuine processes access TransCrypt volumes.

A similar trust model exist for the TransCrypt server kernel as described by Salih K A [23] in his M.Tech thesis.

5.4 Protocol

5.4.1 Negotiation Protocol

TransCrypt uses a strong negotiation protocol to facilitate mutual authentication and session-key establishment between the TransCrypt server and the PKS. The key steps in the negotiation protocol is the initial handshake where the TransCrypt server and the PKS mutually agree on the algorithms, length of cryptographic challenges etc. during their subsequent communications.

(55)

In our model, we use a smart cardas the private key store for the user, as it is a very secure entity to store private keys. The negotiation protocol is as explained in Fig 5.3.

Figure 5.3: Protocol for Negotiating parameters

When a smart card is inserted into the reader, a HELO message is sent by the workstation to the TransCrypt server listing identifiers for cryptographic algorithms that it supports as well as values for other parameters such as lengths of the challenges. An algorithm identifier includes the algorithm name and associated parameters such as key length, cipher specification etc. On receipt of the HELO message, the Trans-Crypt server chooses an appropriate algorithm and parameters from those specified in the HELO message and replies back to the workstation with a WELCOME message listing its choice.

(56)

5.4.2 PKS Registration

TransCrypt was designed such that authentication tokens were sent to TransCrypt server instead of the user’s workstation. This problem is solved by registering the location of subject’s smart card with the TransCrypt server kernel which stores the registered smart card location (known as SCURI) in a table. During a file access, TransCrypt server sends authentication tokens to appropriate subject’s smart card using the information stored in the aforementioned table.

Before allowing access to a file, the server checks the identity of the subject. For this purpose, TransCrypt server cannot use a UID-based approach as implemented in NFS. For this purpose we use the name in X.509 certificate of the subject’s public key. The smart card registration procedure is carried out as follows.

First, the subject’s certificate is retrieved by the workstation login program that is then verified. The subject name is extracted from the certificate and is sent along with the UID of the user on that workstation (U IDws) and the SCURI to the TransCrypt server host by the workstation login program. Figure 5.4 shows the PKS registration protocol.

Figure 5.4: PKS Registration 44

(57)

5.4.3 Establishing a secure channel between SmartCard &

Workstation

To prevent eavesdropping between the smartcard and the workstation, both ends need to authenticate mutually and establish a secure channel. This protocol is illustrated in Figure 5.5. On the workstation side the key is established by the kernel since in our trust model we do not trust the user space utilities such as login program. The following are the steps to perform this action.

1. Workstation kernel asks smart card for a challenge through GET_CHALLENGE

request.

2. When smart card receives GET_CHALLENGE request, it sends its challenge R SC

and its session key’s partK SC encrypted with the workstation kernel’s public key.

3. This message is decrypted by the workstation kernel using its private key. The workstation then replies back challenge response R SC, K WS and R WS to the smart card encoded with the subject’s public key.

4. The smart card decodes the packet using the subject’s private key. It verifies the challenge, issued by itself and if it is successful, workstation is considered authentic. The smart card then replies back to workstation containing the challenge R WS encoded with the workstation’s public key. The session key

SKws−sc is then computed by the smart card usingK WS and K SC. It finally stores this session key for future use.

5. This message is decrypted by the workstation kernel using its private key. Work-station verifies the response to its challenge to authenticate the user. The session

(58)

keySKws−sc is also computed by the workstation kernel usingK WS and K SC. It also maintains this session key for future use.

Figure 5.5: Secure Channel between Workstation & Smart card

5.4.4 Establishing a secure channel between kernels of

Trans-Crypt server and workstation

To counter the aforementioned attacks, the workstation and TransCrypt server must authenticate mutually and establish a secure channel before commencing any file op-erations. This authentication and session establishment process between workstation and TransCrypt server is illustrated in Figure 5.6.

1. The TransCrypt server initiates the mutual authentication and session key es-tablishment task by performing the following operations.

(a) generates a challenge, R FS.

(b) generates its session key’s part, K FS.

(c) encrypts K FS and R FS using the subject’s public key 46

(59)

(d) routes the packet to the workstation’s login process

2. Upon receiving the message, the login process forwards it to the workstation kernel through ioctl system call for pseudo device driver created for this pur-pose. The device driver is a loadable module that plugs into the workstation kernel.

3. Workstation kernel then encrypts the received message with the session key

SKws−sc and sends it to the smart card.

4. When the smart card gets the message, it,

(a) decrypts the message using SKws−sc.

(b) decrypts the TransCrypt server’s challenge using the subject’s private key and recoversR FS and K FS.

(c) encrypts R FS and K FS using SKws−sc and sends it to the workstation kernel.

5. After receiving the message from smart card, the kernel of the workstation,

(a) decrypts the message using SKws−sc to getR FS and K FS. (b) generates a challenge, R WS.

(c) generates its session key’s part, K WS.

(d) encryptsR FS, R WS andK WS with the TransCrypt server’s public key and sends it to the TransCrypt server through login daemon.

(60)

(b) verifies the response to its challenge and if it is successful, the workstation kernel is considered authentic to the TransCrypt server else aborts the protocol.

(c) generates a unique random credential SIDfor the current session.

(d) encrypts the workstation challenge response (R WS) and SID with sub-ject’s public key and forwards it to the login daemon.

(e) calculates the session key SKf s−ws using K FS and K WS and maintains in a table.

7. This packet is then forwarded by the login daemon to the kernel of workstation through ioctl.

8. Workstation kernel then encrypts the received message usingSKws−sc and sends the encrypted packet to the smart card.

9. When smart card receives the message, it,

(a) decrypts the message using SKws−sc and then using the subject’s private key to extract the response from the TransCrypt server i.e. R WS and

SID.

(b) encrypts the extracted R WS and SID usingSKws−sc and sends it to the workstation kernel through login daemon.

10. After receiving the message from smart card, the kernel of the workstation,

(a) decrypts the message usingSKws−sc to get R WS and SID.

(b) verifies the response to its challenge R WS and authenticates the Trans-Crypt server if successful.

(61)

(c) calculates SKf s−ws (session key) using K FS and K WS. This key is used subsequently for all NFS operations between TransCrypt server and work-station.

Workstation kernel attaches SID to the subject’s login process so that all of its children inherit the same credentials.

(62)

5.5 NFS Operations

All NFS file operations pass through eitheraccess or createNFS procedures. Hence only these two NFS procedures are modified to pass the established credentials to the TransCrypt server. If a user on workstation wants to access TransCrypt volume lo-cated on TransCrypt server, user has to mount the corresponding TransCrypt volume on the workstation. After mount is successful the create and access procedure work as described below.

5.5.1 Create

When user creates a file on workstation host which is actually mounted from an Trans-Crypt volume on TransTrans-Crypt server host, NFS client sends the create call arguments and the credentials encrypted with SKf s−ws to the TransCrypt server. After receiv-ing this, the received data is decrypted by the TransCrypt server usreceiv-ing the session key maintained in the table. Also, the credentials and SCURI are verified. If this verification fails, the TransCrypt server drops the request and sends the Permission Denied error to Workstation. Figure 5.7 shows how NFS create operation works in our protocol.

Figure 5.7: NFS create request

(63)

5.5.2 Access

All the parameters of this call are encrypted using the session key. TransCrypt server decrypts the incoming parameters of the access call and verifies these with the one stored in the table. Figure 5.8 shows the steps in NFS access.

Figure 5.8: NFS access request

5.6 Effectiveness

The secure protocol handles the following cryptographic attacks effectively.

1. Eavesdropping between Workstation and Smart card: These are avoided by standard mutual authentication and session key establishment mechanisms which are performed before any operations can be attempted between them. The session key is used to secure all responses from the smart card; only a genuine workstation would be able to read these secured responses using the session key.

2. User masquerading attack: The secure protocol offers protection against rogue processes trying to perform operations on the TransCrypt server mas-querading as a genuine user. This is done by attaching user credentials to each

(64)

process spawned by the user after login. The TransCrypt server expects all file operation requests from genuine user processes to carry these credentials; these are validated and only then file operations are permitted.

5.7 Implementation

This thesis discusses the workstation side implementation details that has been done to make TransCrypt volumes securely accessible over networks and the thesis [23] by Salih K A gives the implementation details on the TransCrypt server. The workstation side implementation needs certain changes to support the secure protocol. These changes are done in kernel space and user space components of the workstation. The changes in the user space components of the workstation include the mechanisms to support the login protocol and support to contact PKS interface through the smart card daemon. The changes in the kernel space components include the mechanism to assign the credentials to the processes and perform authentication and session establishment tasks as explained earlier. These changes are described below.

5.7.1 User space Components

1. Daemon: It has to take care of the full duplex communication between worksta-tion kernel and PKS interface (transcrypt-auth). It integrates socket support to communicate with PKS interface and Netlink Socket support to communicate with the workstation kernel.

2. PAM Module: The changes in the login process must incorporate the PKS registration and also initiate two the mutual authentication tasks, first is be-tween workstation and smart card and second is bebe-tween TransCrypt server

(65)

and workstation, through ioctl system call. This is done using the Pluggable Authentication Module (PAM) [25]. This module provides two methods to per-form tasks associated with session set-up and to perper-form tasks associated with session tear-down. In our implementation session set-up method is used for two purposes, first to perform steps of PKS registration and second to initiate both the mutual authentication and session key establishment tasks. During the session tear-down, the TransCrypt server kernel is informed about the ses-sion termination so that it may remove the corresponding state information. Messages sent to ioctl module to initiate the authentication tasks and for PKS registration are explained in the section 5.7.3.

5.7.2 Kernel space Components

1. lsm-transcrypt Changes: To mount a transcrypt volume from workstation, user provides the encrypt mount option. This option is parsed from the mount parameters and MS_ENCRYPT flag is set for that mount point in the mount call. These changes are done in the Linux Security Module (LSM) of transcrypt, lsm-transcrypt [23]. lsm-transcryptmodule provides sb_copy_datahook for mount operation. We have implemented this hook which does the parsing of the mount parameters and sets the MS_ENCRYPT flag accordingly. This flag is used in the NFS Client code.

2. Changes in the NFS client: The kernel of workstation passes the SID to the TransCrypt server. SID along with other parameters is relayed to the Trans-Crypt server through the secure channel established earlier between NFS client and server. These modifications are done by patching the NFS client code in the Linux kernel.

(66)

This is done by simply augmenting the input structure of access and create

procedures with the additional SID parameter. The modified structures are shown below. struct ACCESSargs { nfs_fh file; uint32 access; char *SID; }; struct CREATEargs { nfs_fh dir; const char *name; uint32 createmode; char *SID;

};

Modifications done in theNFS_access and NFS_create procedures of the NFS client to perform the following steps.

(a) Verify whether the file accessed (created) is from TransCrypt volume by checking the MS_ENCRYPT option. If the file accessed (created) is from TransCrypt volume then continue with step (b) else perform the regular NFS access (create) operation.

(b) Extract the credentials from the current process’s task_struct and copy it to the SID field of input argument structure.

(c) Encrypt the whole input argument structure with SID field withSKws−f s.

3. ioctl Module: The login process initiates both the mutual authentication tasks. Such changes are done through an installable device driver. The login process uses an ioctl [16] call to perform this functionality. The following two tasks are done in the ioctl module.

(67)

(a) Establishing a secure channel between kernel of workstation and smart card

(b) Establishing a secure channel between kernels of workstation and Trans-Crypt server

5.7.3 Protocol Messages

This section explains in detail the formats of protocol messages implemented in the PAM Module, ioctl module and TransCrypt authserver. The messages which com-municates with kernel are prepended with the two headers, kernel header (KH HDR) and transcrypt header (TCPT HDR). Other messages are prepended only with the TCPT HDR. These two headers are shown in Figure 5.9.

Figure 5.9: Protocol Headers

5.7.3.1 PAM Module

As described earlier PAM module implements PKS registration protocol and initiates both the authentication tasks.

Framework for accessing TransCrypt File System over Untrusted Public Network