CryptOS Logo

CryptOS

  The goal of the CryptOS project is to explore the applicability of cryptographic access control to all aspects of operating system security. Cryptographic access control offers a completely decentralized access control abstraction, which improves scalability and makes it attractive for large scale open distributed systems, e.g., ubiquitous/pervasive computing and computational grids.


CryptOS Overview


  Computer security employs a number of different mechanisms to identify and authenticate subjects (people or programs that are active in the system) and control access to protected objects (passive entities in the system, e.g., files). The mechanism that verifies a principal's right to access a protected object is called the access control mechanism. Current access control mechanisms rely on the notion of a reference monitor, which is invoked every time a protected object is referenced. The reference monitor verifies that the subject has the right to perform the requested operation (e.g., read and/or write) on the specific object. The rules governing subjects rights to access objects are encoded in an access control policy.

Reference monitors are considered fundamental to access control and access control mechanisms are often considered synonymous with the reference monitor. However, the concept of reference monitors was originally developed in the context of centralised systems, e.g., mainframe computers, where such centralised access control mechanisms make sense. Different mechanisms have been introduced to extend the use of reference monitors to distributed systems, e.g., strong authentication mechanisms, such as Kerberos and X.509 certificate based systems, allow reference monitors to be used in a closed network environments where all users are known in advance. However, the reference monitor is inherently centralised, as the interpretation of the access control policy is restricted to the server that manages the particular object, and attempts to extend the notion of reference monitors to large scale open networks suffer from poor scalability and they are generally too static and restrictive for highly dynamic environments, such as computational grids, ambient intelligence, pervasive computing, sensor networks and the Internet.

We therefore need to rethink the notion of access control in large scale open networks in a way that provides the flexibility required, while globally ensuring the confidentiality, integrity and authenticity of the data stored in the system.

The CryptOS project investigates the use of public key cryptography to replace the traditional access control mechanisms in operating systems. Traditional access control mechanisms are based on the notion of a reference monitor that authorises access to data managed by the system. CryptOS manages encrypted data which means that read access can be granted to all principals without compromising confidentiality. Similarly, write access can be granted, if writes do not overwrite existing data, e.g. by using a journaled file system. Knowing the public key of a file allows reading the encrypted data, while knowledge of the private key is necessary in order to modify the file. Thus, the public key corresponds to a read capability and the private key to a write capability.


CryptOS People


  Christian D. Jensen   Principal Investigator
  Kristine Frank   CryptOS Architect
  Søren Hjarlvig & Jesper Kampfeld   CryptOS Peer-to-Peer Storage System
M.Sc. Dissertation  (in Danish)
  Declan O'Shanahan   CryptOS Network File System
M.Sc. Dissertation
  Anthony Harrington   CryptOS Network File System II
M.Sc. Dissertation
  Owen Kelly   CryptoCache

CryptOS Architecture


 

The CryptOS Architecture enforces end-to-end security at the application level, which means that the kernel footprint of the security mechanism and the trusted computing base (TCB) is negligible. We have therfore decided to base the CryptOS architecture on a microkernel design, which has a number of desirable properties. First of all, the microkernel approach helps ensure a minimal TCB, which is essential if we are to have confidence in the security of the developed system (we do not currently propose to perform a formal validation of CryptOS). Microkernels have inherent support for compartmentalisation, which means that most system services will operate without access to the user's keys. Modern microkernels, have excellent performance, which means that it is possible to develop a clean operating system design without sacrifising performance. Microkernels are relatively small and easy to understand, which facilitates the implementation of a new operating system architecture on top of a microkernel. Finally, most microkernels ahe very limited security architectures, which means that minmal modifications have to be made to the existing microkernel in order to replace the existing security mechanism with cryptographic access control.

The first version of CryptOS will be based on the L4 microkernel.

CryptOS File System


 

The ability to share files in distributed environment between different operating systems is facilitated by distributed file systems, such as the Network File System (NFS) from Sun Microsystems which is widely used in intranets. Current implementations of NFS are not suitable for Internet use, because they principals are not authenticated and because data is send over the wire in the clear meaning that attackers can compromise the secrecy or integrity of all data accessed over the Internet.

A number of extensions have been proposed to improve the security of NFS. Secure NFS introduces authentication through the use of Secure RPC calls and sNFS encrypts communication between client and server. When a NFS Client wishes to invoke an operation (read or write) on the NFS server, both operation and data have to be encrypted by the client before they are sent to the server. The server has to decrypt Both before it can perform the requested operation (assuming that the client has sufficient access rights). The server then encrypts the result and data before they are returned to the client, which in turn has to decrypt them before they are used. This design combines traditional servers that manage access control themselves and traditional secure communication mechanisms.

A client wishing to read a file will send the read request to the Server. The data is already encrypted so there is no need for the Server to encrypt the information before it is sent to the client. The server can send data to any client who requests them, because only a client that knows the file's public key is able to decrypt the data. Similarly, the private key is required to encrypt data before they are stored on the NFS server, otherwise decryption with the public key will result in garbage. A log structured file system should be used to prevent attackers from overwriting valid data. It is possible to optimise this scheme to encrypt and decrypt data using shared key cryptography, but the fundamental principles remain the same.


CryptoCache


 

CryptoCache is a file caching mechanism that allows roaming users to temporarily store files on untrusted servers. This improves availability and quality of service for roaming users with compact mobile devices. Moreover, the system allows users to share files with other usere and to grant selective access rights to the cached file (read, write or both).

All files are encrypted before they leave the home server and only decrypted by the client. This ensures confidentiality, integrity and authenticity of the stored data.

CryptoCache has been designed for small mobile devices, but it appears to have applications outside the area of mobile computing. Intelligent caching of application data inside the network is often presented as an attractive application for active networks. CryptoCache provides the same ability to push frequently used data onto strategically placed servers in the network. Collaborating servers can securely push data onto untrusted file hosting servers using CryptoCache. All servers participating in the collaboration must have decryption keys for all files, but only the server which actually hosts the file has the encryption key that allows it to update the file in the cache.