Design and Implementation of a Secure Linux Device Encryption Architecture

Christian Stüble (Ruhr-Universität Bochum), Marcel Winandy (Ruhr-Universität Bochum), Ahmad-Reza Sadeghi (Ruhr-Universität Bochum) and Michael Scheibel (Sirrix Security Technologies AG)

Playlists: 'linuxtag06' videos starting here / audio / related events

1 Introduction Today, increasingly more sensitive data is stored on private and business devices such as PC's, Laptops and PDAs. The security critical data include business plans, authorization secrets, and email correspondence. In case the device is stolen or lost this data may be compromised. An approved security mechanism to mitigate this risk is to encrypt the data. There exist several software-based encryption systems. Some of them are shipped together with the operating system. One example is Linux and its dm_crypt, which allows dierent encryption algorithms to plug in and use them for encrypting le systems. Unfortunately, most software-based hard-disk encryption products suer from insecure storage and usage capabilities for security-critical cryptographic keys and operations. The underlying operating systems (OS) that control all data storage mechanisms, i.e. hard-disk, memory, USB, I/O etc., cannot prevent other (potentially malicious) applications from gaining access to the critical key data. This can be seen by the huge number of exploits and continuous security updates. The reasons are due to various conceptual weaknesses of common computing platforms, in particular due to the monolithic OS kernel architecture and thus increased complexity. This concerns Windows-based operating systems as well as Linux-based ones. A large part of the operating system and supporting processes are executed in a privileged mode, the so called kernel mode, which allows them to directly access the hardware and all other software processes. User applications are usually executed in a non-privileged mode, the so called user mode. Thus, the risk of security weaknesses is higher because of the huge amount of code executed in privileged mode. If such a process can be exploited it is possible to gain access to all kernel data, including the encryption keys used for the hard-disk encryption. An attacker may readout the encryption key from kernel memory or simply deactivate the encryption system by exploiting a common security hole. Runtime protections such as access control and user authentication may be easily circumvented by booting an alternate operating system. Furthermore, an untrusted system administrator usually has full access to all system resources including the cryptographic keys of the users. Countermeasures such as mandatory rolebased access control (e.g. SELinux) protect this information from a "root spy" but are much too complicated to maintain and evaluate [8]. We propose a solution to this problem by providing a security archtitecture that allows secure, reliable and user-friendly device encryption. The security architecture strongly isolates the secret key information and all related security-critical operations from the Linux operating system. This is similar to a hardware based solution but far more cost-eective. Moreover, the architecture is capable of using Trusted Computing (TC) functionalities (based on [13]) to protect the cryptographic keys and to assure software integrity during the booting process of the system. 2 Related Work The are a number of software device encryption systems available today. However, most of them either do not oer essential security properties such as isolation (of the encryption keys and operations from the operating system), or they are not open source and not being subject of public analysis. 2.1 Commercial Products Examples of commercial software device encryption systems available at the market are [1, 10, 11, 14]. These products oer variety of features.1 In this context some products already use the interfaces to Trusted Platform Module (TPM) to bind encryption keys to hardware and/or software components and for secure random number generation (partially). A further product is Microsoft's Secure Startup - Full Volume Encryption which will be integrated into the upcoming client version release of Microsoft's Windows Operating System ("Windows Vista") [10]. This encryption feature encrypts the entire Windows volume and uses a Trusted Platform Module (TPM) 1.2 to bind the encryption key to the boot stack, thus ensuring that system les have not been tampered with while the system was oine. However, it does not use TPM authentication mechanisms but relies on conventional OS authentication after the system integrity has been verified. 2.2 Enforcer Project The Enforcer [7, 8, 9] is a Linux Security Module (LSM) that binds the cryptographic key for an encrypted le system to long-lived system components, such as the Linux kernel, the boot stack, the Enforcer LSM, and the public key of a so-called "security admin". The security admin issues and digitally signs a list of le hashes. This security conguration is used by the Enforcer LSM to check the integrity of the applications before execution. The Enforcer even provides a mechanism to guarantee the freshness of a security conguration. To verify the integrity of the long-lived components the Enforcer enhances the LILO boot loader with TPM support. However, the encryption key information is still located within the Linux kernel since the Enforcer LSM itself is executed in the Linux kernel. Thus, a isolation of encryption keys and operations from the operating system is not supported. 2.3 Device Mapper Crypt Target The Device Mapper is a Linux 2.6 kernel feature that allows to create a virtual block device whose sectors are mapped to sectors on a physical block device, e.g. a hard-disk or USB device. Available mapping types include encryption. Thus data written to the virtual device is transparently encrypted and passed on to the physical device (and vice versa). The crypt target (dm_crypt) uses the Linux 2.6 Cryptographic API which provides stateof-the-art symmetric ciphers and hash computation algorithms such as AES and SHA-256. However, since the crypt target is a kernel feature, the encryption keys and operations are located within the kernel and there is no isolation from the operating system. Futhermore, there are no measures for checking the system integrity before execution. 3 The EMSCB Project The European Multilaterally Secure Computing Base (EMSCB) project aims at developing a trustworthy computing platform, based on open standards and open source, that solves many security problems of conventional platforms [3]. The platform deploys * hardware functionalities provided by Trusted Computing, * a security kernel and * an efficient migration of existing operating systems. The EMSCB platform allows, in the sense of multilateral security, the enforcement of security policies of dierent parties, i.e., end-users as well as industry. This is viatal property required for secure execution of a variety of distributed applications. Consequently, the platform enables the realization of various innovative business models, also in the area of Digital Rights Management, while averting the potential risks of Trusted Computing platforms concerning privacy issues. The source code of the EMSCB platform will be published under an opensource license, e.g., the GPL. The platform can be freely used as basis for application development. The EMSCB project is partly funded by the German Federal Ministry of Economics and Technology. Project partners include several universities and industry organizations. This consortium is lead by Ruhr-University Bochum (Applied Data Security Group). 4 Basic System Architecture One main design goal of EMSCB is the realization of a minimal and therefore manageable, stable and evaluable security kernel for conventional hardware platforms such as IBM-PCs, servers, embedded systems, and mobile devices like PDAs and smartphones. This requirement is fullled by extracting security-critical operations and data and integrate them into the security kernel [12]. The security kernel is composed of a Resource Management Layer, which runs on top of the hardware, and a Trusted Software Layer. The hardware may provide Trusted Computing functionality, e.g., based on TPM. The main task of the Resource Management is the provision of an abstract interface of the underlying hardware resources like interrupts, memory and hard-disk drives. Moreover, this layer allows to share these resources and can realize access control enforcement on the object types known to this layer. This layer can be implemented using a microkernel (e.g. [6]) or a hypervisor virtualization (e.g. [2]) approach. The Trusted Software Layer combines the services provided by the hardware layer and the resource management. It extends the interfaces of the underlying services with security properties and ensures isolation of the applications executed on top of this layer. On top of the Trusted Software Layer, security-critical and non-critical applications are executed in parallel. Legacy operating systems can be executed as isolated applications on top of the Trusted Software Layer to provide end-users a common user interface and a backward-compatible application binary interface (ABI) and allows application providers to reuse existing non-critical applications and components. To obtain full user transparency the encryption system has to be completely integrated into the security kernel, i.e., the Trusted Software Layer. 5 Secure Linux Device Encryption The Secure Linux Device Encryption is based on the microkernel-based EMSCB security kernel. The Linux operating system is executed as a separate EMSCB application. This allows an architecture where the key critical information of a device encryption system is stored and handled in a special EMSCB service outside of Linux but within the Trusted Software Layer. This special service is the EMSCB HDD-Encrypter. All key critical information is handled by this EMSCB service, that itself is fully independent from Linux. After a successful authentication process against the HDD-Encrypter, a Linux function that handles the device encryption just sends the plain text to the HDD-Encrypter service and receives the cipher text afterwards and vice versa without having access to the secret key information. We use the dm_crypt interface of Linux so that the device mapper support can be used transparently within Linux. The authentication process simply authenticates a qualied user, i.e. the data owner, and then provides access to the data to all applications of the respective user. The authentication is performed by providing a password, which is then used to derive an encryption key. Without the correct password the correct encryption key will not be accessible and hence condentiality is preserved. We use AES as a fast symmetric encryption algorithm in our implementation. We derive the key from a given password using a cryptographic hash function. The EMSCB HDD-Encrypter can be run in three operational modes: * Single-user mode (without Trusted GUI) * Single-user mode (with Trusted GUI) * Multi-user mode (with Trusted GUI) In single-user mode all encrypted devices are encrypted with one single key, which is derived from the single user's password. In multi-user mode every encrypted device has its own individual encryption key. The user's password is used to derive another encryption key, which is used to encrypt/decrypt the encryption key of the device. This allows multiple users to share a common encrypted device but having not to share a common password. In multi-user mode it is necessary to dene keys and user accounts. If users want to have access to certain encrypted devices their access rights to these resources, i.e., the cryptographic keys, must be specied. Thus, there is a need for user management, which is handled by the HDD-Encrypter as well. Trusted GUI When using the Trusted GUI, Linux runs in an extra window. The password and administration dialogs for accessing the device encryption keys or changing the conguration are displayed in a separated dialog box. On the one hand, the user can recognize that the password or administration dialog does not belong to any potentially malicious application inside the Linux operating system (trusted path to application). On the other hand, Linux is not able to access or manipulate these dialogs, either. For our prototype implementation we used a special GUI system [5] that provides a virtual framebuer to the Linux system. Linux applications draw their graphical user interface elements within this framebuffer. Security-critical applications, like the HDD-Encrypter conguration management console, have separated GUI windows that are isolated from the Linux system. Currently, this system is going to be improved to provide a secure GUI [4]. In single-user mode we do not need a special trusted GUI since the bootloader will already ask for the password that is used for key derivation. The bootloader will automatically pass the password to the EMSCB HDD-Encrypter service. After the system is booted there is no need to ask for the password again. All devices will be encrypted/decrypted with the key derived from the given password. Thus, Linux can be executed in full-screen mode in this case. TPM Support Our proposed system is able to bind device encryption keys to a user authorization secret, hardware components or the trusted software modules. Binding to hardware and/or software components requires a trusted hardware component. Our architecture deploys TPM sealing functionalities for this purpose. However, the architecture is not restricted to using the TPM and can oer the corresponding interfaces of any other hardware platform. The TPM uses on-chip registers (Platform Conguration Registers, PCRs) to securely store measurements (i.e., hash values) of hardware and software components. The TPM sealing command subsequently binds data to these PCRs. The resulting binary data is then stored persistently. For our application certain PCRs should reect the integrity of the trusted components. This can be achieved as follows: 1. A TPM-aware (trusted) BIOS measures the MBR (Mater Boot Record) before execution. 2. The bootloader measures each boot stage before execution. 3. The bootloader is completely loaded. The PCRs now reect the integrity of the boot process (authenticated boot). 4. The trusted software components are digitally signed. The bootloader checks their signatures before execution. The corresponding public key is hard-coded into the bootloader. If a signature check fails the PCR values are invalidated and the user is requested for interaction (secure boot). The alternation of authenticated and secure boot allows secure updating of system components without resealing of secrets [8, 9]. 6 Conclusion and Outlook We have introduced the EMSCB Security Architecture which is used as a trustworthy basis for implementation of secure distributed applications. Within the EMSCB project several application prototypes are being designed and developed. In this paper we introduce the prototype for a device encryption system based on the EMSCB security kernel. We are currently completing and improving the implementation with respect to system integrity protection and TPM integration. Furthermore, we are working on new improvements of the trusted GUI to provide user-friendly easy-to-use and secure user interfaces. References [1] SafeBoot Device Encryption for PC., 2005. [2] Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., and Neugebauer, R. Xen and the art of virtualization. [3] EMSCB Project Consortium. The EMSCB project. [4] Feske, N., and Helmuth, C. A Nitpicker`s guide to a minimal-complexity secure GUI. In Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC 2005) (2005). [5] Feske, N., and Härtig, H. Demonstration of DOpE - a Window Server for Real-time and Embedded Systems. In Proceedings of the 24th IEEE Real-Time Systems Symposium (RTSS 2003) (2003). [6] Liedke, J. On microkernel construction. In Proceedings of the 15th ACM Symposium on Operating Systems Principles (SOSP'95) (Copper Mountain Resort, Colorado, Dec. 1995). Appeared as ACM Operating Systems Review 29.5. [7] MacDonald, R., Smith, S., Marchesini, J., and Wild, O. Bear: An open-source virtual secure coprocessor based on TCPA. Tech. Rep. TR2003-471, Department of Computer Science, Dartmouth College, 2003. [8] Marche
ini, J., Smith, S., Wild, O., Barsamian, A., and Stabiner, J. Opensource applications of TCPA hardware. In 20th Annual Computer Security Applications Conference (Dec. 2004), ACM. [9] Marchesini, J., Smith, S. W., Wild, O., and MacDonald, R. Experimenting with TCPA/TCG hardware, or: How I learned to stop worrying and love the bear. Tech. Rep. TR2003-476, Department of Computer Science, Dartmouth College, 2003. [10] Microsoft Corp. Secure Startup - Full Volume Encryption: Technical Overview, April 2005. [11] PGP Corporation. PGP Whole Disk Encryption for Enterprises Data Sheet, 2005. [12] Sadeghi, A.-R., Pohlmann, N., Stüble, C., European multilateral secure computing base - open trusted computing for you and me. Datenschutz und Datensicherheit DuD, Verlag Friedrich Vieweg & Sohn, Wiesbaden 28, 9 (2004), 548554. [13] Trusted Computing Group. TPM main specication. Main Specication Version 1.2 In Proceedings of the 19th ACM Symposium rev. 85, Trusted Computing Group, Feb. 2005. on Operating Systems Principles (SOSP'03) (Bolton Landing, NY, USA, Oct. 2003), ACM, [14] Utimaco Safeware. SafeGuard Easy Technical Whitepaper, April 2005. pp. 164177.

Über den Autor Christian Stüble: Dipl.-Inform. Christian Stüble arbeitet seit 1998 im Bereich IT-Sicherheit mit den Schwerpunkten Sichere Betriebssysteme, Vertrauenswürdige Endbenutzergeräte und Trusted Computing. Nach dem Studium der Informatik in Hildesheim und Dortmund schloss er Mitte 2000 dieses mit einer Diplomarbeit über sichere mobile Endbenutzergeräte ab und leitete seitdem an der Universität des Saarlandes am Lehrstuhl für Sicherheit und Kryptographie das PERSEUS Projekt. Seit 2004 ist Herr Stüble Mitglied der Forschergruppe "Applied Data Security" am Europäischen Zentrum für IT-Sicherheit (eurobits) der Ruhr-Universität Bochum. Dort setzt er die Entwicklung des PERSEUS Forschungsprojektes fort. Weiterhin ist er Technischer Leiter des vom BMWA geförterten Projektes "EMSCB" zum Thema Open Trusted Computing. Über den Autor Marcel Winandy: Marcel Winandy is Research Assistant at Horst Görtz Institute for IT Security at Ruhr-University Bochum, Germany. He is involved within the European Multilaterally Secure Computing Base (EMSCB) project. Marcel Winandy studied Computer Science with emphasis on computer security and software technology at the University of Bonn, Germany, and got his diploma degree in 2004. From 2004 to 2005 he worked as Research Assistant at the same university, where he did research on the security of adaptive mobile applications. In 2005 he joined the Applied Data Security Group at Ruhr-University Bochum. His main research interests are secure operating systems and trusted computing. Über den Autor Ahmad-Reza Sadeghi: Ahmad-Reza Sadeghi is a Professor at Horst Görtz Institute for IT Security at Ruhr-University Bochum, Germany. He received his PhD in Computer Science from Saarland University in Saarbrücken, Germany. Prior to academia he has been working in Research and Development Department of several IT enterprises. Currently, he is leading the research group for Applied Data Security and a number of research and development projects in the area of cryptography, multimedia security, and design and implementation of trustworthy computing platforms including the EMSCB project. His research interests are privacy enhancing cryptographic systems, security architectures, Trusted Computing, and multimedia security. Über den Autor Michael Scheibel: Michael Scheibel works as a security systems architect at Sirrix Security Technologies AG in Bochum and is an external PhD student at the Applied Data Security Group at Ruhr-University Bochum. His research and development activities currently focus on modern operating system design and trusted computing technology with an emphasis on integrity measurement and validation. He is actively involved in the EMSCB project.