Codecaps – Authentication for the cloud

The predominant way of providing discretionary access control in the cloud is through a combination of authentication and Access Control Lists (ACLs) that map principals, roles, or attributes of principals to a predetermined set of rights on available services. But such mechanisms are not without problems.  People and even entire companies end up with accounts in many different places, which quickly can become a security hazard.

Secure Abstractions in Sport Analytics

This problem with access control lists became apparent while developing Muithu, our sports analytics application, that runs on a federation of public and enterprise clouds. Much of the data is private and highly sensitive; this includes medical performance data, internal individual performance evaluations, and future training strategies. An important part of Muithu is abstraction. Raw data from various sources are processed and made available in another form, so that multiple layers of abstraction can be developed. With access control lists, each layer would need to have accounts with the lower layers, and also keep track of accounts of its own users. Much of the complexity then revolves around securely managing user accounts and correctly configuring the access control lists. Access control lists make it difficult to maintain fine grained control over distribution and access of data.


As an example, consider the situation where a team coach P1 wants to provide up-to-date information about each player object o to the local supporter club P2. However, P1 has no interest in running a large web site to share this information. Instead, P1 can obtain a codecap c1 from P0 for o and give P2 a library and a delegated codecap c2 for o. When P2 invokes the library, the library can use c2 to access the current version of o directly from P0 and generate the derived object o’ using the client’s computational resources. Code in c2 ensures that P2 can only access those parts of o that P1 allows it to access.

Now suppose that there are certain proprietary operations on o that P1 does not want to distribute in the library itself or using parts of the data in o that P1 does not want P2 to access directly. For instance, P1 might not want to give access to detailed heart-rate information, but instead provide only access to aggregated values. In that case the library can access a service run by P1 to execute the operation using codecap c2. P1 cannot use c2 directly to access $o$ because it does not have the corresponding private key and because it does not give the necessary access rights. However, P1 can reconstruct c1 from c2 and pair the resulting code cap with its own private key to obtain the correct access credentials to o. This is a case of rights amplification, a necessary ingredient of secure abstraction. It is not necessary for P1 to keep around all the intermediate codecaps, which would be inconvenient and waste computing resources.

Capabilities and Codecaps

Capabilities are unforgeable digital tokens that can be passed around, and possession of a capability grants specific rights to services independent of who the possessor is.  Consistent with the principle of least privilege, capabilities are given out on an as-needed basis.  Capabilities have been used in a variety of systems. But these capabilities still have the problem that, for each service, there is a predetermined collection of rights that can be turned on or off.

The instantiation of capabilities that we propose is novel in that the capabilities contain embedded code that allows fine-grained control over restricted delegation.  In other words, the set of rights that can be delegated is not predefined as in other capability-based (or ACL-based) systems, but can be evolved as needed. We call these capabilities “code capabilities” or codecaps. In addition, codecaps support rights amplification so they can be used to implement secure abstraction.

Our implementation requires no special trusted language, trusted operating system kernel, or other trusted infrastructure to develop applications-the capabilities are managed completely in user space using well-known public key cryptographic techniques.  Even though managed in user space, transfer of capabilities is implicitly mediated so that confinement can be supported.  A directory service provides a secure way for users to manage their capabilities, and to delegate restricted capabilities to other users.