Main Page | Data Structures | File List | Data Fields | Globals

Key Escrow Service for TrueCrypt

Purpose

This project adds a key escrow service to TrueCrypt.

Synopsis

When a volume is mounted, the system checks whether escrow is necessary. If necessary, the user is authenticated and the header information is encrypted and sent to the server for storage. The server stores the information in its encrypted format. The server cannot decrypt the information. Recovery of key information is only possible by authorized users from authorized locations who possess the decryption keys. A modified ChangePassword() routine is used to write the header information back to the volume.

Overview

The user enters the pass-phrase to mount a TrueCrypt volume. During the mounting process, a CRYPTO_INFO structure is populated with the encryption key data and other essential data. At this point the escrow service is executed. If escrow is necessary for this volume, the user is prompted for username and password. After authentication, an RSA public key is obtained from the server. The CRYPTO_INFO data is encrypted with this RSA key, and the data is sent to the server for storage.

The server stores the RSA encrypted CRYPTO_INFO data for an authenticated user. The salt and header creation time are used to uniquely identify this volume with this user. The server does not have the RSA private key and cannot decrypt the escrowed data. SSL is used for all client-server communication. The client will verify the server's SSL certificate before sending any data to the server. The server performs authentication against an LDAP server using SSL and SASL.

The restore process uses a modified ChangePassword() routine to restore the header. Only authorized users can download escrowed data. The download function can only be issued from a designated network subnet. Furthermore, the client must have the RSA private key to decrypt the CRYPTO_INFO data.

The restore client can query the server by username or by salt. This allows for quick identification of the appropriate header to restore.

The CRYPTO_INFO is downloaded from the server, decrypted and used in the modified ChangePassword() routine. At this point, the regular change password functions are executed on this CRYPTO_INFO data.

This works with regular and hidden volumes, and will recover a volume that uses a keyfile.

Code

The code is partitioned into different components: common, client, server and restore. These files are compiled and archived into a library called libwfu.a. This library is linked with the Linux server and Linux client. A similar process is used to create a library for the Windows client.

Server

The server is created by compiling the inetd.c file and linking with the libwfu.a library. The server is spawned by the xinetd process. The server requires a configuration file as a parameter. The configuration file contains information such as the location of the SSL certificate and the MySQL database connection. The function WFU_server_dispatch(SSL*, char *) handles all server functions.

Linux Client

The libwfu.a file will be linked with the TrueCrypt client. The TrueCrypt client will include two header files: libconfig.h and WFU.h.

The libconfig.h file provides functions for parsing an XML configuration file: WFU_get_config_path() and WFU_parse_config(const char *). The configuration file contains information such as the server's DNS name, TCP port number and the location of the SSL certificate used to verify the server.

The WFU.h file provides a function to perform the escrow and functions that determine whether escrow is necessary: WFU_lib_escrow(char *, char*, struct wfu_uvid *, struct wfu_data *), WFU_lib_prepare_uvid(unsigned char *, unsigned char*, unsigned char *) and WFU_lib_verify_uvid(struct wfu_uvid *).

The inetd server

Patch file to add escrow ability to Cli.c

Patch file to add restore ability to Cli.c


Generated on Wed Oct 10 12:38:20 2007 for WFUCrypt by  doxygen 1.3.9.1