(mOSAIC) Credential service


This document is part of the SPECS deliverable D4.4.1, thus superseded by it.


This document was created in January 2015, thus its contents might be currently outdated.


This document is still a draft!

1   Introduction

1.1   Overview

The main focus of the SPECS project is application security, mainly IaaS and PaaS, starting from the design phase, throughout development and finally to deployment and execution, taking into account a variety of aspects such as user authentication and authorization, communication channel security, to stored data security. Therefore each of these issues is tackled in a dedicated report, and many also have software implementations. The current report focuses on a class of such issues, namely authentication (and in future versions possibly also authorization) of (software) clients to their corresponding services.

As hinted above, in the context of this report, the clients are not "humans" but instead software components which act as clients to various services, some part of the deployed SPECS applications, acting on behalf of real persons which are EU (end-user) in the SPECS terminology. At the opposite end the services are either other software part of the same SPECS applications, or even services offered as SaaS by CSP (Cloud Service Provider).

The tackled problem is the most basic one encountered when one wants to consume remote services, namely how to authenticate the requester (the client) to the service provider (the service in our case); and the available options vary on one axis from no authentication to strong cryptographically-based techniques, and from shared-secrets to third-party authenticator.

Moreover there is another aspect that further complicates the problem, namely the flexibility that is offered during development by the various software solutions, ranging from existing software with limited configuration, up to complete access to the source and the possibility to enhance the software. This factor limits what the developer is able to achieve, and what the SPECS credential services are able to provide, and in essence it boils down to:

  • (open) standard compliant solutions -- where the SPECS services have to implement a few existing protocols, thus the security is limited by the capabilities of the protocol;
  • proprietary compliant solutions -- where the SPECS services have to deal with a multitude of different protocols, with security prospects similar to the previous case;
  • SPECS-tailored solutions -- which allow the greatest flexibility in terms of design and implementation, which in turn yield a better match with SPECS security requirements;

1.2   Deliverable structure

Thus the current report gives details about two SPECS solutions (plus two evolutions), each tailored for a specific purpose:

  • security tokens service -- which is a SPECS-tailored solution, allowing not only authentication of clients through signed tokens, but also privilege delegation by conveying assertions about the authenticated entity, and revocation of issued authentication tokens;
  • credential service -- which is the currently available prototype, tailored to handle the credentials needed for CSP (Cloud Service Provider) service interactions, or other standards compliant protocols;

Before moving to each of these sections, we must note that the term "credential" does not refer strictly to a pair of account identifier and password, but also includes other sensitive information such as shared secrets, public / private keys, X.509 certificates; in essence any kind of data --- used by the services and not part of their usual logic, but instead used to access the infrastructure or other services --- which should be kept safe is considered a credential.

Each of the sections is roughly structured as follows:

  • Scenarios -- which provides a few examples of the problems and implied solutions that are relevant to each particular module;
  • State of the art -- giving an overview of the existing solutions and alternatives, discussing their advantages, disadvantages, and appropriateness in the SPECS context;
  • Requirements -- formally summarizing a set of functional and non-functional requirements that each particular module should provide;
  • Design -- which presents a rough view of the module's (technical) architecture, specifying the main involved components and the communication patterns between them;
  • Usage -- which gives a few usage scenarios and links to the module's on-line documentation;
  • Installation -- which lists the steps needed to install the software solution;

1.3   Relation with other deliverables

The solutions presented in this report, namely the security tokens and credential service, are tailored to fulfill the requirements identified during the SPECS analysis [cite-specs412] (which are pertinent to this topic), and follow the specific enforcement design [cite-specs422] and generic project design [cite-specs112].

2   Scenarios

2.1   Overview

The following scenarios try to highlight some of the situations where the proposed credential service can prove a valuable asset to the EU (end-user).

It must be noted that in all these situations there are perhaps simpler ways to achieve the desired result, however none of these offer the same level of security and flexibility than the credential service can provide.

In summary the credential service handles the aspect of authenticating (possibly even authorizing) requests coming from software clients, either part of the SPECS platform or the application itself, targeted towards the CSP (Cloud Service Provider) target service, however executing on behalf of the EU (end-user), through the usage of the EU (end-user)'s credentials.


We can not stress enough the fact that in the context of the credential service, the clients we speak about are not "humans" but instead software components or agents which interact with various external services on behalf of the EU (end-user). These clients are part of the deployed SPECS applications, acting on behalf of real persons which are EU (end-user) in the SPECS terminology; meanwhile at the opposite end of the spectrum, the target services are other software components or agents part of either the same deployed SPECS applications, or most likely services offered as SaaS by external CSP (Cloud Service Provider)'s.

2.2   Secure web container deployment on Rackspace

2.2.1   Overview

In this scenario the EU (end-user) has just signed an SLA which on implementation will trigger the provisioning of a few secure web containers, that in this scenario, and in accordance with the signed SLA, are to be deployed on Rackspace's cloud infrastructure as VM's under the control of the SPECS platform.

The key aspect on which we focus in this scenario, pertaining to the subject of credential management, is how the request to create the needed VM's on Rackspace is to be authenticated against the desired Rackspace credentials which, depending on the interacion model, although not important for this scenario or the credential service, could belong to either the EU (end-user) or the SPECS platform owner.

Technically during the SLA implementation phase, there will be a component, part of the enforcement module, that will need to trigger the provisioning of the required VM's, and following that, the their proper configuration. By looking at the Rackspace API reference [pafu] we know that the implementation component in question will need to first obtain the credentials (consisting of a user name and matching password); following with a call to a Rackspace service to obtain an authentication token; only after which it can continue with the actual provisioning requests, by passing along the obtained authentication token.

2.2.2   Security concerns

Functionally there is no issue with the above workflow, except the concerns related to proper handling of the Rackspace credentials (i.e. the user name and password).

The first issues that are to be tackled are related to the conveying of those raw credentials, from either the EU (end-user) or a specialized SPECS component, to the implementation component that has to use them. This includes mutual authentication between the two parties, and the credential data exchange through a secure channel.

However once these credentials are passed over to the implementation module, all control over their usage relies solely on the correct implementation and behaviour of that delegated module, which could use those credentials for any other purpose, for as long as the credentials are valid (usually a matter of months on end).

Therefore the EU (end-user) is exposed to quite a few major risks, including improper credential usage, or even worse leakage to other parties, all of which could have, besides business disruption, also monetary losses.

2.2.3   Proposed solution

Unfortunately not much can be done to obtain proper security in absolute terms, which includes restricting the credential usage only for the purpose of VM creation and nothing else. This impossibility stems due to the way the Rackspace security model has been designed, namely once authenticated, the obtained token can be used for any purposes until it either expires (a matter of days) or it is explicitly revoked.

However SPECS, through the introduction of the credential service, could at least reduce the time frame in which the authentication token can be used for other purposes.

The solution is quite straight forward and implies running half the Rackspace authentication process by the credential service, and only the other half delegated to the implementation component.

Specifically, the credential service which holds the Rackspace credentials, will upon being requested by the implementation module, authenticate to Rackspace and obtain the needed authentication token, passing it in response to the implementation module, which in turn will use it to provision the required VM's for the secure web container deployment. However at the same time the credential service sets a timer on the obtained token, on whose triggering will revoke the authentication token, thus rendering it unusable after revocation.

Needless to say that the interactions between the credential service and the implementation module are themselves authenticated and secured, just like between any two SPECS components, possibly by the usage of the SPECS security tokens service for authentication (and possibly also for authorization), and TLS for confidentiality.

2.2.4   Discussion

Thus, like previously described, the proposed credential service can not solve the issue of leakage of the authentication token by the implementation module, but it can instead reduce the time frame during which an attack might successfully use it; nor does it solve the issue of improper usage of the token for other operations than VM creation.

As noted these limitations are not the fault of the proposed solution, namely the credential service, but that of the shortcomings of the Rackspace authentication scheme.

2.3   Secure storage over Amazon S3

2.3.1   Overview

A second scenario where we highlight the potential usage of the proposed credential service, is that when the EU (end-user) has signed an SLA, which at implementation requires the provisioning of a secure storage module that will allow the EU (end-user) (or a delegated party) to securely store data on Amazon S3.

For this scenario the security module consists of a service which is handed the encrypted data to be stored on Amazon S3 on behalf of the EU (end-user). Technically this implies that the storage service will require to gain access to the EU (end-user) Amazon AWS credentials consisting of an access key (similar to an user name) and secret key (similar to a password) that are to be used each time a request is to be made to Amazon S3 on behalf of the EU (end-user).

By looking at the Amazon API reference [yixe] we observe that, unlike Rackspace's authentication scheme, the storage service needs for each individual request the actual Amazon AWS credentials, which are cryptographically combined with the request data to uniquely authenticate each individual request.

2.3.2   Security concerns

Just like in the previous scenario, the main issues are related to conveying the credential data, and the lack of control over their usage, therefore no other discussion is required, all the previous observations applying.

It must however be granted that Amazon does provide quite extensive access control policies which could limit the actions that can be carried with a certain set of credentials. However the usage of such policies are quite involving, requiring the switch to Amazon IAM, proper policy creation and enforcement, and proper credential life-cycle.

Therefore although it is practically possible to limit the allowed operations for a given set of credentials, like only being able to read and write in a given Amazon S3 bucket, this however limits only the types of operations that can be done with a potential leaked set of credentials, and not the time frame during which an attack is possible.

Moreover the type of operations, an the target resources, are quite coarse, and in some scenarios, like possibly the secure storage, there might be a need for a more fine-grained approach.

2.3.3   Proposed solution

Just like in the case of Rackspace our proposal is to delegate the actual authentication procedure to the credential service, meanwhile leaving the actual enactment of the request to the implementation module (in this case the secure storage service).

Although at a first glance there is even less that can be done by the credential service, because according to the Amazon API reference [yixe] the actual credentials are needed for each individual request, therefore once exposed to the implementation service, they can't be "taken" back. (One could revoke the actual credentials, but this is not an operation to be done time and time again.)

However on closer inspection of the mentioned API, we can observe that the credential service could have an even greater role in how the credentials are used. The solution requires the implementation service to execute the first half of the authentication procedure by computing all the required fingerprints of the request meta-data and data, and passing this along to the credential service with other information identifying the requested operation (like the region, operation, resource, etc.). Then based on this partial data uniquely identifying the each request, the credential service can complete the authentication process by cryptographically combining the partial data with the actual credentials, obtaining the authenticating signature unique to the request in question, which then can be passed back to the implementation service.

2.3.4   Discussion

As described above, the proposed solution not only completely eliminates the need for the implementation module to have access to the Amazon AWS credentials, but allows the credential service to impose further restrictions on their usage, which possibly are not provided by the generic Amazon AWS policies.

Furthermore if the implementation service does leak the obtained authenticating signature, it is useless to an attacker because they can only be used to authenticate an identical operation to the signed one (thus in the worst case the same operation is executed twice), and furthermore the authentication token has only a time-window of about 30 seconds.

3   Requirements

3.1   Overview

Starting from the scenarios described earlier, but also based on our experience on the topic of credential management in developing cloud-based applications, we describe in what follows a set of functional and non-functional requirements that should be fulfilled by the credential service in order to meet the expectations set forth.

It must be noted up-front that some of these requirements are generic in the sens that they apply to different heterogeneous technologies (in our cases target services), therefore their achievement depends mostly on the nature of the targeted technology. In some situations the requirement can be fully achieved, meanwhile in some other only basic functionality can be provided.

Furthermore we must be aware at all times that although we strive for full control over the credentials, given that the resulting solution will run in a cloud environment, therefore on virtualized systems, perfect security is not achievable. Moreover there must be a balance between security and performance or practicality, therefore implying certain trade-offs in the guarantees that are asked for.


We can not stress enough the fact that in the context of the credential service, the clients we speak about are not "humans" but instead software components or agents which interact with various external services on behalf of the EU (end-user). These clients are part of the deployed SPECS applications, acting on behalf of real persons which are EU (end-user) in the SPECS terminology; meanwhile at the opposite end of the spectrum, the target services are other software components or agents part of either the same deployed SPECS applications, or most likely services offered as SaaS by external CSP (Cloud Service Provider)'s.

3.2   Functional requirements

3.2.1   Target service authentication schemes support
Description:Implement the relevant part of the chosen target service authentication schemes, namely the one involving the usage of credentials.

Obviously the most important requirement is that of implementing the relevant part of the authentication protocol of the chosen target service, namely the one that requires access to the credentials.

However this requirement can not be fulfilled by the credential service alone, but in cooperation with the actual client of the target service, especially since for some target services (like those of Amazon AWS) the authentication scheme requires as input meta-data uniquely characterizing the request in question.

As stated in the overview, with this requirement a generic one, not clearly indicating a list of target services. However this list will be identified as part of other SPECS deliverables and activities, and once that list of target services is finalized, this requirement will actually translate into a couple of requirements, one per target service, stating "support AWS services authentication scheme", or "support OpenNebula services authentication scheme", etc. Therefore in analyzing the achievement of this requirement, each of the resulting concrete requirements must be taken in isolation and not as a whole.

It must also be noted that not all the target services could benefit from the credential service in the same amount. Like we have described in the sections related with security concerns in each of the two possible usage scenarios, the level of sophistication, and therefore the inherent flexibility and security, of various target services varies from almost none (i.e. where the actual credentials are sent in plain with each request), to a token-based level (like in the case of Rackspace services), to a per-request signature level (like in the case of Amazon AWS services). Therefore the level of achievement of each specific requirement will vary in comparison from case to case, depending on the particularities of the target service, and as such being outside the control of the developer.

3.2.2   Access control policies to the credential usage
Description:Provide support for limiting the usage of certain credentials to a well defined set of clients.

In addition to eliminating the need for target service clients to get access to the credential data, there should be a way to limit their access to the actual usage of such credentials.

Therefore there should be a way to impose access policies at two levels (desirably, but the second one being optional). The first level, implementable in all cases, would control if a certain client can actually use the credentials for a certain target service. Meanwhile the second level, implementable only in some cases, controls for what purposes should the client be allowed to use the credentials in question.

For example in case of Rackspace credentials only first level policies can be applied, given that once a token is generated its usage can not be controlled further (except revoked). Meanwhile for Amazon AWS credentials the policies could expand not only to the second level, namely the allowed actions, like say creating or destroying a VM, or accessing a certain Amazon S3 bucket, but even a third level controlling to which resources should the operations be applied to, like say create an Amazon S3 object, but not be able to delete or overwrite it. (Granted that in the case of Amazon S3 these policies could be directly enforced by the target services themselves, as discussed in the corresponding scenario.)

3.2.3   Multiple credentials for the same target service
Description:Allow the concurrent usage of different credentials for the same target service.

Taking into account that one of the interaction models targeted by SPECS is that in which a single SPECS platform instance plays the role of a shared PaaS, by offering the same services to multiple EU (end-user), thus sharing the same infrastructure and consequently the same software components. It is therefore mandatory to be able to handle multiple credentials for the same target service, one (or perhaps multiple) credentials belonging to an individual EU (end-user) and being delegated to SPECS to act on behalf of the EU (end-user).

As such the same software component, playing the role of target service client, might concurrently interact with the same target service, but on behalf of different EU (end-user)'s, hence the requirement of being able to concurrently access different credentials of the same target service, which the credential service must be able to provide.

However it must be noted that this requirement is as much for the credential service as it is for the clients of the target services, and thus clients of the credential service itself.

3.3   Non-functional requirements

3.3.1   Credential usage auditing
Description:Provide credentials usage auditing, providing enough information to identify the software component that requested access.

Due to the cloud's model of "pay as you go", any interaction with a target service most likely results in costs being incurred on behalf of the EU (end-user) owning the credentials. Moreover most of the actions are irreversible, and no recovery is possible (without possibly interacting directly with the cloud provider support team), like for example removing data from an Amazon S3 bucket or terminating a VM.

Therefore in the case of incident management an audit of the usage of the credentials is invaluable, and should contain enough information to pin-point the software component that issued the request (and possibly enough information to track the initial request that triggered the chain of actions).

Like in the case of access control policies, multiple levels of auditing would prove useful, the first one indicating when and by whom certain credentials ware used; the second level indicating which specific operations were authorized. Unfortunately, just like in the access control policies, the ability to achieve these levels depends mostly on the actual authentication scheme in question.

3.3.2   Disjoint credential data management and storage
Description:Separate the actual credentials usage from their long term storage, in order to, possibly, prevent or reduce losses and risks in case of successful attacks on any of the credential service components.

Because no software is without faults, even the proposed credential service might be the target of (successful) attacks. Therefore in order to mitigate the amount of leaked data it would prove useful to separate the different concerns of credentials handling as follows.

One software component should store the credential data (itself or by delegation to a third component), encrypted without having access to the decryption keys. Another software component should have the decryption keys, and each time credentials are needed, requesting them from the first component that just stores them, using them and afterwards discarding them. (A certain small period of caching is foreseen as a solution to performance issues.)

4   State of the art

4.1   Overview

As can be observed from both the scenarios and requirements sections, the topic at hand is highly technical, involving many actors spread across both space (over the network interactions) and time (asynchronous interactions), and relates to the authentication and authorization of actions, specifically API calls initiated by software components, whose target are cloud resources, hosted by CSP (Cloud Service Provider)'s and owned by EU (end-user), on behalf of which the software components may act, requiring thus privilege delegation from the EU (end-user) towards these software components.


We can not stress enough the fact that in the context of the credential service, the clients we speak about are not "humans" but instead software components or agents which interact with various external services on behalf of the EU (end-user). These clients are part of the deployed SPECS applications, acting on behalf of real persons which are EU (end-user) in the SPECS terminology; meanwhile at the opposite end of the spectrum, the target services are other software components or agents part of either the same deployed SPECS applications, or most likely services offered as SaaS by external CSP (Cloud Service Provider)'s.

Unfortunately, to our knowledge, this topic has not yet been explicitly touched by any of the cloud related scientific literature, perhaps only hinted to in some works covering cloud security. However this topic is actively discussed in the non-academic world, especially in blog posts by various engineers, like for example [yeda], although due to practical reasons they stop at the level of securely distributing credentials by leveraging CSP (Cloud Service Provider) provided services.

On the other hand the Grid community has already tackled and solved quite elegantly this topic by using X.509 proxy certificates, as described in [rfc3820], but unfortunately it is not applicable in the current cloud ecosystem for the simple reason that CSP (Cloud Service Provider)'s have chosen proprietary, non-interoperable, and sometimes weak, authentication schemes that in almost all cases do not rely on public key infrastructure but instead on shared secrets. (The only notable exception is the X.509 authentication for a handful of Amazon AWS services, and only when accessed through SOAP calls.)

Therefore the only solutions, remotely resembling our requirements for the credential service, are Amazon STS (Security Token Service) (not related with SPECS's service with the same name), the SASL and GSS-API mechanisms, and Plan9 factotum and secstore services.

4.2   Amazon Security Token Service

As previously noted in the scenarios section, Amazon has perhaps the most powerful and flexible security related features for their cloud management API, something yet unmatched by any of the existing cloud providers. As a further example of their focus towards security, they offer free of charge a dedicated service, namely Amazon STS (Security Token Service) [yagi] (unrelated to SPECS's service with the same name), which allows the credential holder (either human or a software component) to create a set of new temporary credentials, restricted to a sub-set of the permissions allowed for the initial credentials.

There are two major ways in which one can put this Amazon STS service to good use, the first being through the usage of Amazon IAM roles via Amazon EC2 VM profiles, meanwhile the second involving the usage of Amazon STS by a delegation service creating and conveying the resulting temporary credentials to the service needing them. In what follows we shall briefly discuss each of these two variants, highlighting their limitations and the main differences between these approaches and our proposed credential service.

4.2.1   STS via IAM roles assigned to EC2 VM profiles

The simplest, and most secure, method of leveraging Amazon STS is through the usage of Amazon IAM roles for Amazon EC2 VM's. Technically this involves defining an Amazon IAM role, then assigning it a set of permissions through Amazon IAM policies, followed by creating an Amazon EC2 VM profile bound to this Amazon IAM role, and finally by choosing the this profile when launching a VM. Once the VM has started, through a series of Amazon STS API calls, the applications running on the VM can use the resulting temporary credentials, achieving thus access delegation.

It must be noted right from the start that if one strictly (and fully) follows the cloud deployment best practices, namely having one and only one service per VM, and furthermore that each service has always the same security access requirements, then by the usage of Amazon IAM roles and Amazon STS, one can obtain a (practically) sufficiently secure solution.

There are however certain limitations to this solution, especially in the case when on the same VM one needs to run multiple services, like in the case of shared PaaS (one of the SPECS's main interaction models), where each service with its own security clearances. And because any process running on the given VM can use any of the privileges that have been granted to that VM, it implies that one can not delegate different privileges to different services.

Furthermore this solution works best when the resources, that are the target of API calls, belong to the same Amazon AWS account, therefore cross-account delegation, although not impossible, is pretty difficult to set-up. (Moreover for some services cross-account delegation is not possible.)

4.2.2   STS via delegation service

Despite the limitations of the previous technique, one of the big advantages is the out-of-the-box functionality, in that everything can be achieved only by using native Amazon AWS services and API's without requiring extra work from the EU (end-user).

However in order to solve the flexibility limitations, one could leverage Amazon STS in a software component, which when asked would create a temporary set of credentials and delegate them to the requesting service, which in turn would use them to control the targeted resources. This would allow for example to have a cluster of services that are delegated access to a large number of credentials, not necessarily part of the same Amazon AWS account.

The way such a solution would work is very similar to our proposed credential service, and therefore does not need to be discussed further.

4.2.3   Discussion

Although Amazon STS is a very powerful tool when it comes to cloud access delegation, it does have deeper disadvantages that the limitations pretested previously. In what follows we shall highlight some of these disadvantages, which are in play regardless of the variant in which Amazon STS is used, either via Amazon IAM roles or via a delegation service.

It must be noted however that in itself, and disregarding the issues presented hereafter, Amazon STS is practically sufficient, offering much better security than any other existing solution.

However perhaps the greatest disadvantage of Amazon STS is its lack of interoperability, in that it is useful only when dealing with Amazon services. Even though Amazon's API, especially the one for Amazon EC2 and Amazon S3, has been copied by other software vendors, like Eucalyptus or OpenStack, the Amazon STS service is unique to Amazon and is not available in any other compatible solution.

Putting aside the interoperability issues, and focusing solely on security aspects, there are further limitations which could negatively impact its usefulness. The first issues is related to the time frame in which temporary credentials (potentially leaked by a compromised service) can be used to inflict damage, mainly due to the fact that there is no way to revoke these temporary credentials once issued. Therefore a compromise has to be made between availability and security, because in order to increase the security one needs to decrease the time frame in which these temporary credentials are active, therefore their expiration interval, which in turn requires more frequent temporary credential creation, that in the case the delegation service is down would imply reduced availability.

The second issue is related to how specific the privileges can be for the temporary credentials (or any Amazon AWS credential for that matter). Although one can assign standard Amazon AWS policies to further restrict the access of the temporary credentials, they can go only so far as specifying actions to be taken and in some cases coarse rules to match the affected targets. It is however difficult to pin-point access to say only terminate a certain VM, or give access only to certain Amazon S3 paths that match a given regular expression.

Nonetheless, even disregarding all of these interoperability and security issues, there still remains the fact that a piece of software has access to credentials, even though temporary and tightly restricted, which can be easily leaked due to a software bug.

4.3   GSS-API and SASL

Both GSS-API (Generic Security Service API) [rfc2743] and SASL (Simple Authentication and Security Layer) [rfc4422] are two similar and widely deployed solutions for securing client-server protocols, alleviating the issues of authentication from both protocol designers and implementors. GSS-API goes even further by providing message integrity and confidentiality, or even delegation through specific API's; meanwhile SASL is used mainly for authentication (sometimes in conjunction with GSS-API as an authentication mechanism), although it to provides support for delegation.

All this is achieved by providing a well defined API in terms of inputs, outputs and state transitions, that only requires from the protocol the ability to convey certain data back and forth between the two parties, the result being usually authentication of the client party, or possibly mutual authentication of both the client and the server.

Although these two technologies are not used in today's cloud ecosystem, they are good candidates for standard cloud service authentication mechanisms, and their purpose is similar to our proposed credential service, in that both solutions hide the credential management from the application, usually behind a dynamically linked library, but possibly even behind an RPC.

4.4   Plan9 factotum and secstore services

Perhaps the closest existing solution to our proposed credential service are Plan9 factotum and secstore services [zoti], both of which being the main inspiration source for our solution.

In essence the secstore service is tasked only with securely storing secret data, and guarding access permitting only authorized clients, in most likely instances of factotum. The actual storage is achieved by employing cryptographic techniques, namely symmetric key encryption algorithms, which based on a password provided by the human operator at service start-up, allows the secure storage of the secret data over an insecure file-system, either local or remote.

On the other side, factotum implements a series of security protocols that involve the credential data safely managed by secstore, and exposes these protocols to interested clients without exposing the actual credential data, furthermore confining operations to authorized clients only. In functional terms factotum is an equivalent of either GSS-API or SASL, except that it provides almost infinite extensibility in terms of supported security protocols and operational flexibility in being a service rather than a library.

The main highlight of these two services, something which sets them well apart from either GSS-API and SASL or any other solution from that matter, is that their interfaces are exposed as Plan9 file-systems mounted at certain points in the overall file-system hierarchy, therefore all the interaction, including authentication and authorization, being mediated by Plan9's standard file-system access controls. Moreover, based on Plan9's capabilities, namely the 9P file-system protocol, these interfaces can easily be exported to remote hosts, therefore achieving a fully capable client-server solution.

It must be noted that although technically it would be possible to implement our proposed credential service as an extension to the factotum service, due to the peculiarities of the Plan9 ecosystem, especially the 9P file-system protocol, and the nature of cloud services revolving mainly around HTTP-based API's, such an undertaking would be far more complex than just building upon these ideas and providing a completely new solution, thus more compatible with the cloud philosophy.

4.5   Conclusion

Although we can not assert with 100% certainty that the subject of credential management and delegation to, and by, software agents in a cloud environment has not been addressed by the current scientific literature, we are certain our endeavor is unique, at least in the cloud environment.

We did identify a few solutions, one specifically targeting the topic at hand, namely Amazon STS, however they are only starting points which offer unique ideas, not solutions we are able to build upon or extend to other cloud services.

5   Design

5.1   Overview

As opposed to the SPECS security tokens service, which is a completely new SPECS solution, designed and implemented from ground-up, the current credential service is tailored to handle existing security protocols, which in the current phase of the project are mainly CSP (Cloud Service Provider) target service authentication schemes.

Because the main targeted CSP (Cloud Service Provider)'s are Amazon AWS and Eucalyptus, both implementing the same de-facto standard (namely the one proposed by Amazon), the current prototype implements only the needed procedures to authenticate requests for this common security protocol. However the design presented below is generic enough that it can be tailored for other security protocols.

We shall first present a brief introduction into the current authentication schemes used by most CSP (Cloud Service Provider)'s, followed by a brief description the concepts used by the credential service. Then we present the overall current and future architecture, and conclude with brief discussions about architectural, security and implementation concerns.


We can not stress enough the fact that in the context of the credential service, the clients we speak about are not "humans" but instead software components or agents which interact with various external services on behalf of the EU (end-user). These clients are part of the deployed SPECS applications, acting on behalf of real persons which are EU (end-user) in the SPECS terminology; meanwhile at the opposite end of the spectrum, the target services are other software components or agents part of either the same deployed SPECS applications, or most likely services offered as SaaS by external CSP (Cloud Service Provider)'s.

5.2   Authentication schemes

Before going further into the details, we make a small detour and present how the usual (as in implemented by most CSP (Cloud Service Provider)'s) authentication schemes work.

Basically most CSP (Cloud Service Provider)'s provide the EU (end-user) (developer or operator) a set of shared secrets that must be used when making calls to the services. For each individual call (in almost all cases HTTP calls conveying REST-ful requests or SOAP messages) the caller (a custom library provided by the CSP (Cloud Service Provider), operating on behalf of the EU (end-user)) generates a fingerprint which uniquely identifies the call in question. Then this fingerprint is cryptographically combined (still by the CSP (Cloud Service Provider) provided library) with the shared secret to obtain an authenticator, again, unique to the current call. Afterwards the call is submitted with the authenticator attached (in case of HTTP calls most likely as a header).

Technically in almost all cases the fingerprint involves a series of cryptographic hash function applications, and the authenticator involves a series of cryptographic HMAC function applications. The providers which implement such a scheme are all those compliant with the Amazon AWS de-facto standard (including Eucalyptus, OpenStack, newer versions of OpenNebula, etc.) [xiwe].

On the other side some CSP (Cloud Service Provider)'s use much more simple authentication schemes (again completely proprietary and not interoperable), many simply involving a cryptographic hash function application over the shared secret and timestamp (like in case of GoGrid [zowu]); some even require just sending the shared secrets with each call (like in the case of older versions of OpenNebula); meanwhile others imply obtaining a temporary access token (like in the case of Rackspace [yete]).

5.3   Concepts

The following are the concepts used by the credential service, which are essential for understanding the way this solution works and how it should be integrated into clients, and possible target services.

As hinted in the overview of this report, credentials are any "secret" data that are used to access remote services (either provided by CSP (Cloud Service Provider) or other applications), and which should be protected against leaks. For example in case of Amazon AWS they are pairs of "access-key" and "secret-key", but they can be any kind data which is expressible with the JSON syntax, including binary data as Base64 strings, from private / public key pairs, to shared secrets, etc.
It is an internal concept to the credential service (therefore not related with the module concept in the global SPECS terminology), and represents the set of operations that can be executed over a certain credential. Thus it is mostly just a logical grouping of operations, a kind of namespace in procedural programming languages or class or type in object oriented ones. However in terms of implementation, all the operations of a module are written inside the same file and loaded as a unit (see below in listing providing the implementation of the Amazon AWS module).
It is an algorithmic procedure (in most cases involving cryptographic functions), which based on inputs derived (by the client) from the actual request, returns a set of outputs that should be used to complement and authenticate the request. For example in case of Amazon AWS we have the authentication scheme described in [xiwe].

5.4   Architecture

The architecture of the current prototype is quite simple, on the credential service side having only a single process (which internally uses an embedded database for storing the credentials), and on the client side a simple library which implements the HTTP-based REST-ful API needed to execute part of the security protocol and delegate the rest.

It must be noted the exposed API is so simple, that one can directly use the credential service directly from the console by invoking curl, just as seen in the listings in the section dedicated to its usage.

The current architecture are heavily influenced by the Plan9 factotum service [zoti], which fulfills a similar role.

5.4.1   Current architecture

For a sketch of the architecture one can look at the figure below, where the involved entities and the sequence of the calls are clearly identified.


Architecture of the credential service (current version)

Phases of the credential service (current version)

  1. The target service client executes part of the security protocol, namely all the steps that do not require the actual credential data. (Sometimes this phase is non-existant, depending on the security protocol.)
  2. The target service client provides the credential service the partial (and other required) data.
  3. The credential service executes the remainder of the security protocol, by combining the partial data with the actual credential data. (This phase might involve actual calls to the target service, depending on the security protocol.)
  4. The credential service replies to the target service client with the rest of the security protocol data. (This phase might actually require the credential service to provide the actual credential data, thus a no-operation, depending on the security protocol.)
  5. The target service client makes the actual request, sending besides the request also the required security protocol data.

As seen from the previous phases, the actual operations involved, and the level of security, depends solely on the security protocol at hand.

5.4.2   Future architecture

Although functionality wise the current architecture is good enough to fulfill the practical needs of any target service client, the following figure presents an evolution which also fulfills the non-functional requirement of separating the credential management from its storage, which is mandated by the need to limit the amount of damage caused by a possible successful attack on any of the credential service components.

However in practical terms, the evolution towards this future architecture does not impact in any way existing credential service clients, as the API between the client and the current credential service will remain the same as the one between the client and the credential manager, the credential store being hidden.


Architecture of the credential service (future version)

Phases of the credential service (future version)

Just like in the current version, the client implements part of the security protocol, delegating to the credential service only the actual credential usage. Therefore we jump over the common phases.

  1. The target service client provides the credential manager the partial (and other required) data.
  2. The credential manager determines the required credentials (based on the partial inputs).
  3. The credential manager requests from the credential store the encrypted credentials.
  4. The credential store retrieves (from an embedded database or another service) the encrypted credentials.
  5. The credential manager receives from the credential store the encrypted credentials.
  6. The credential manager decrypts the credentials.
  7. The credential manager executes the remained of the security protocol like in the current version.
  8. The credential manager replies to the target service client with the security protocol data like in the current version.
  9. The credential manager disposes (possibly after some delay) of the decrypted credentials, and possibly even of the encrypted variant.

5.5   Architectural concerns

As seen from the previous section, there are a multitude of non interoperable procedures to authenticate calls, each depending on the target CSP (Cloud Service Provider), and for some there are even multiple variants (like in the case of Amazon AWS); then for each client that needs to make such calls, a different library might be used (especially if each client is written in a different programming language). Moreover the involved shared secrets have to be conveyed from the deployment, through the client code, to the used library. Therefore the potential of credential leak is quite high, and the purpose of the credential service is to minimize such issues.

As such the credential service is built in such a way that the actual shared secrets remain confined inside the credential service, and potential clients delegate only the authentication operations to the service. (For an example see listing for the implementation of the Amazon AWS authentication scheme.)

It must be noted that the credential service does not act as a proxy for the call, but instead it should be perceived as an internal procedure that executes part of the authentication scheme (although remotely). Unfortunately this also implies that one has to change the code of the libraries provided by the CSP (Cloud Service Provider) to extract the authentication execution and delegate it to the credential service.

5.6   Security concerns

Although the credential service solves the issue of leaking the actual credentials, it opens up a second problem, that of authenticating and authorizing the clients that need to have their requests authenticated.

In order to solve this new issue, the clients should use only HTTPS for securing the communication channel, and for authentication and authorization there are two broad options: using the SPECS security tokens service; or using X.509 client certificates (as part of the HTTPS / TLS channel).

The current implementation does not use any kind of authentication and authorization, because the focus of the prototype is on the credential management, the other issues being a crosscutting concern that can be solved independently of the solution, and it is also required for other SPECS services. (Moreover the future evolutions will have an even tighter security model as mandated by one of the requirements of the credential service.)

5.7   Implementation concerns

The current prototype is implemented in a JavaScript-based asynchronous environment, namely NodeJS, which by providing a dynamically typed and interpreted environment, allows us to register and unregister modules at will, without requiring compilation or restarting the whole service.

The full source code of the service can be found on GitHub, under the Apache 2.0 license, at the following URL: https://github.com/ieat/mosaic-credential-service.

In the listing below one can analyze the implementation of the Amazon AWS module which currently only provides the Amazon AWS authentication scheme described in [xiwe].

Amazon AWS module implementation

function _queryAuthenticate4 (_credential, _inputs, _onSuccess, _onError) {
    transcript.traceDebuggingObject ("signing query...", _inputs);
    var _accessKey = _credential["access-key"];
    var _secretKey = _credential["secret-key"];
    var _timestamp = _inputs.timestamp;
    var _region = _inputs.region;
    var _service = _inputs.service;
    var _request = _inputs.request;
    var _termination = "aws4_request";
    var _date = new Date (_timestamp);
    var _date1 = printf ("%04d%02d%02dT%02d%02d%02dZ",
            _date.getUTCFullYear (), _date.getUTCMonth () + 1, _date.getUTCDate (),
            _date.getUTCHours (), _date.getUTCMinutes (), _date.getUTCSeconds ());
    var _date2 = printf ("%04d%02d%02d",
            _date.getUTCFullYear (), _date.getUTCMonth () + 1, _date.getUTCDate ());
    var _credentialScope = [_date2, _region, _service, _termination].join ("/");
    var _credential = [_accessKey, _credentialScope].join ("/");
    var _target = [
    ].join ("\n");
    var _signedDate = crypto.hmac ("sha256", "AWS4" + _secretKey, _date2, "binary", "binary");
    var _signedRegion = crypto.hmac ("sha256", _signedDate, _region, "binary", "binary");
    var _signedService = crypto.hmac ("sha256", _signedRegion, _service, "binary", "binary");
    var _signatureKey = crypto.hmac ("sha256", _signedService, _termination, "binary", "binary");
    var _signature = crypto.hmac ("sha256", _signatureKey, _target, "binary", "hex");
    var _outcome = {
        credential : _credential,
        signature : _signature,
    _onSuccess (_outcome);

module.operations.register ({
        identifier : "query-authenticate-v4",
        execute : _queryAuthenticate4,

Regarding the handling of the actual credentials they are currently stored in memory (thus they do not leak into the host storage layer, except perhaps swap if not encrypted); the only way to extract them is if a module directly exports them (not as part of a cryptographic procedure), or in case there is a security issue (or bug) that affects the environment itself or one of the libraries used (in addition to the actual implementation). However this issue will be mitigated in the future version which decouples the credential storage from its usage, as is mandated by one of the credential service requirements.

6   Usage

6.1   Credential management

The following shell code snippet shows how one can list the available credentials. (Of course initially it will be empty, and after one imports a set of credentials their identifiers will appear.)

Listing available credentials

$$$ curl

>>> ["amazon"]

The following snippet shows how one can import an Amazon AWS compliant credential; the identifier of the credential is amazon, however one can import multiple Amazon AWS credentials under different identifiers.

Importing a new credential

$$$ curl \
        --request PUT \
        --header 'content-type: application/json' \
        --data-binary @/dev/stdin \ \
    "access-key" : "AKIDEXAMPLE",
    "secret-key" : "wJalrXUtnFEMI/K7MDENG+bPxRfiCYEXAMPLEKEY"

>>> true

6.2   Modules and operations management

The following snippet shows the available modules, which in the current version only the one for Amazon AWS is implemented.

Listing available modules

$$$ curl

>>> ["aws"]

The following snippet show the available operations, in the current case the ones for Amazon AWS, for which only the forth version of the signature scheme exists.

Listing available operations for a module

$$$ curl

>>> ["query-authenticate-v4"]

6.3   Authenticating a call

The following snippet shows how one can ask the credential service to sign an Amazon AWS call with the credentials identified by the token amazon. The meaning of the inputs is the following:

  • region represents the targeted region; (on the Amazon AWS documentation there is a complete list of such constants;)
  • service represents the identifier of the targeted region; (on the Amazon AWS documentation there is a complete list of such constants;)
  • timestamp represents the timestamp at which the request was signed, and the time drift between the client and the Amazon AWS service must be at most 30 seconds; (moreover the credential service must check that the timestamp is not too far in the future or in the past;)
  • request is the fingerprint of the request, which depending on the actual request is computed in various ways;

Executing an operation over a credential

curl \
        --request POST \
        --header 'content-type: application/json' \
        --data-binary @/dev/stdin \ \
    "region" : "us-east-1",
    "service" : "host",
    "timestamp" : 1315611360000,
    "request" : "0846c2945b0832deb7a463c66af5c4f8bd54ec28c438e67a214445b157c9ddf8"

>>> {
    "credential" : "AKIDEXAMPLE/20110909/us-east-1/host/aws4_request",
    "signature" : "56c054473fd260c13e4e7393eb203662195f5d4a1fada5314b8b52b23f985e9f"

It must be noted that basically the library code has to be updated so that instead of using these inputs and combining them with the credentials, it makes a call to the credential service providing these inputs, and obtaining the outputs it would normally compute itself in-process.

7   Installation

Like most SPECS modules, there are two deployment modes: one as a standalone service, or as a component deployed on-top of the execution platform. In the later case, both the installation, configuration and execution are automatically handled by the execution platform, requiring thus no manual intervention.

In the case of a standalone service, the installation is almost trivial and just involves installing the desired package and activating the service. Because SPECS leverages mOS --- a specialized OpenSUSE-based Linux distribution developed as part of the mOSAIC project --- all the required repositories are already registered and one only needs to:

Credential service installation snippet

mos-packages install mosaic-credential-service

Then starting the service only implies the following simple invocation:

Credential service execution snippet

mos-packages execute mosaic-credential-service run

Regarding the "mosaic" prefix

As a side-note, although the package name contains the prefix mosaic, this module is part of the SPECS platform, but because it is reusable independently (of the rest of the SPECS platform), we wanted to include it in the core mOSAIC platform that SPECS leverages, thus raising the chance of its reusage in other non-SPECS-related projects (such as MODAClouds). (Moreover the ideas behind this module started during the mOSAIC project while identifying the difficulties faced at that time while interacting with CSP (Cloud Service Provider)'s.)

8   Future directions

8.1   Credential Manager

Although the current credential service is enough to fulfill the requirements for which it was designed (that is to reduce the likelihood of credential leaks) we believe that it is lacking in a few key departments. Therefore the current section proposes an evolution of the credential service, which only handles the credential operation execution, meanwhile delegating the storage of the actual credentials to the credential store (described in the next section).

However we do not intend to enter into the technical details, only focusing on the key architectural and technical concerns.

8.1.1   Credential service API issues

First of all, we believe that the HTTP API that the clients have to use to obtain the call authenticators is both too "heavy" (especially in the case when the calls are made quite often), and opens a new set of potential security issues, in addition to exposing yet another running process to the network.

Secondly, the usage of the HTTP protocol is almost unnecessary, the reason being solely because almost any programming language (including shell scripting) provides a technique to execute such HTTP calls. However the burden of correctly implementing the handling of status codes, content negotiation, content encoding, and other technicalities is pushed to the developer of the credential service library (at least one for each programming language).

8.1.2   A simple portable solution

Therefore looking at how a similar project solves this issue, namely factotum from the Plan9 ecosystem [zoti], we propose to use a synthetic file-system mounted on each host, one that the clients shall use to delegate the credential operations. (In essence we are only replacing the "transport layer" if we might say so.)

At first sight it might seem a more complex solution than the HTTP-based one, however absolutely all programming languages offer access to the file-system, usually through a well established API|'s, like the POSIX open / read / write / close family of operations.

8.1.3   Example usage snippets

For example one could envisage the following usage of the credential manager directly from the shell, which mirrors the curl calls presented in the previous section.

Listing available modules

$$$ ls /mos/services/credential-manager/modules

>>> aws

Listing available operations

$$$ ls /mos/services/credential-manager/modules/aws/operations

>>> query-auntenticate-v4

Executing an operation over a credential

$$$ declare _token="$( uuidgen -r )"

$$$ mkdir "/mos/services/credential-manager/modules/aws/operations/execution/${_token}"

$$$ cat \
     >"/mos/services/credential-manager/modules/aws/operations/execution/${_token}/inputs" \
// the same input JSON like in the case of `curl` example

$$$ echo "execute" \

$$$ cat \

>>> // the same output JSON like in the case of `curl` example

$$$ rmdir "/mos/services/credential-manager/modules/aws/operations/execution/${_token}"
8.1.4   Advantages

Although looking at the previous examples, one could conclude that the process is more involved and thus the overhead is greater (there are 5 operations instead of 1), however the actual number of system calls is comparable to the HTTP-based API (if not lesser in practice). For example, per credential operation execution, in the case of the HTTP API we have one socket creation, binding and connection, at least one read and write, one socket shutdown and one close system calls, thus 7 in total. In the case of the file-system based API we have one directory creation, two open and close, one read and write, and one directory deletion, thus 8 in total. However we are removing the network overhead, and if needed one can reduce the number of system calls to only four in total (one open, write, read and then close).

But the efficiency is not the only reason, in fact it is just a by-product of the technology. Instead the main advantage is that of a much more constrained and well defined access control, because now the authentication and authorization is done by the operating system kernel (which implements the system calls), meanwhile the credential manager only having to implement the operations. (Not to mention that the service is not exposed to the network.)

Therefore the only way in which an attacker can gain access to the credentials is if the operating system itself is compromised.

8.1.5   Disadvantages

There are however drawbacks, especially since now we require one credential manager to run on each host. However this is not a major one, because mOS (the OpenSUSE-based Linux distribution that SPECS leverages) eases the execution of such specialized services.

Another potential issue is how the credential manager obtains the credential data, which gets us to the credential store (presented in the next section), that is a remote service which provides access to such credential data, which the manager caches for performance reasons. However even this interaction follows the same pattern of file-system mediated communication (as the credential store will have on each host a proxy).

Therefore in this new scheme, as opposed to the current credential service prototype, we only need to secure the interaction between two services (the credential store and credential store proxy), both of which are designed and implemented with security in mind.

8.1.6   Implementation concerns

In terms of implementation we consider that FUSE [xoce] is the best approach (9P [gihu] being the runner-up), because we have access to more information about the caller (such as process identifier, and knowing that we can easily obtain user and group information, executable, etc.)

The programming language is not important as long as there is a FUSE library available; it must however allow dynamic code loading.

8.2   Credential Store

As presented in the previous section, the one about the credential manager, there is the need to safely store and access credential data.

For this purpose we propose the following simple solution: there is a credential store service which has the purpose of retrieving encrypted credential data from an already existing general purpose storage service (we propose another mOSAIC-related solution, namely the mOSAIC object store, which is a replicated / distributed key-value database); the credential store service is queried over the network by a credential store proxy running on each host where such credential data is needed.

8.2.1   Security concerns

The set of hard to solve security-related issues are briefly presented in what follows.

How the credential store service obtains the encryption key?

Basically in a cloud environment this is the weakest link, and no fully secure solution exists. One possibility is to convey, via the so called "user-data", the private key used to decrypt the credential data obtained from the general purpose store. Another possibility is to use a HSM that provides access to operations on such a private key; however such a solution is prohibitively expensive.

How to secure the communication between the credential store service and credential store proxy?

The obvious solution is a TLS-based communication channel with both client and server certificate-based authentication. However in such a case the problem is transformed into how to convey the required private keys to the two entities, which can be solved in a similar fashion like the previous problem.

How to enforce access policies to the credentials?

One potential solution is to encode, besides the actual credential data, also an access policy which states who is able to obtain access to that data. Such a policy can then be enforced by the credential store service, based on the identity of the credential store proxy (which is taken to be either the client public key obtained from the TLS negotiation, or a special attribute thereof.) Moreover such policies can be further conveyed, through the proxy, to the credential manager, which can further narrow down the kind of processes that can execute operations on them.

8.2.2   Implementation concerns

Although not many implementation details have been ironed out, there already exists previous work, namely secstore also from the Plan9 ecosystem [zoti].