Autonomous Identification System Part 1
Cloud services offer great economic value to organisations. Typically, as these services proliferate and become interconnected within an organisation’s business systems, a security risk develops when credentials must be stored in the service for a long duration without rotation.
We describe our Autonomous Identification System, which can be used to mitigate this security risk by issuing these services with short lived temporary credentials.
This allows organisations to get the desired economic benefit, while controlling risk
- Part 1 describes the problem, and the solution this system provides
- Part 2 discusses a number of common use cases, and introduces our open source reference implementation
Background
A common problem encountered with large-scale deployments using a serverless architecture is the need for clients to be able to access some infrastructure component, and an example of this is a client accessing an S3 bucket on AWS. In order to accomplish this, the client needs to have the proper credentials to authenticate. These credentials are often stored in third-party systems, such as CircleCI or AWS. The problem is compounded if there are many clients that require access to many infrastructure components, which results in the potential for the need to have many different sets of credentials. The more credentials that are stored in a third-party system, the greater the danger of one or more of them being used to launch an attack on the infrastructure.
Another issue with storing credentials within a third-party system, or together with deployed code, is that credentials of this type are often not rotated on a regular basis. When this happens, it increases the risk of an incident with those credentials occurring. The solution to this is that no credentials should be stored in third-party systems or otherwise together with deployed code. In order to facilitate this, we present here a method for allowing a client to identify itself dynamically to a server, which then issues the necessary credentials
Autonomous Identification
The system described in this article is designed to allow a client to be identified by a server, without the need for the client to authenticate with the server. For this to be possible, the client has to have a way to identify itself to a server. Ideally, such a system should mitigate the problems outlined above. Namely, it should be able to identify itself to a server in a manner that does not require full authentication and allows for simple and quick rotation of any identification token.
In our solution to this issue, there is a server that accepts connections from clients who wish to identify themselves and receive the credentials they need to perform the tasks for which they are used. Figure 1 outlines the process that follows. To identify itself, a client has an entropy file, which is a file that is filled with randomly generated text. It also has the public key of the server. The server has its own, unique copy of this entropy file. The client creates an identification hash by combining random sections of the entropy file and hashing them. This hash, along with the entropy file interval values that the server can use to select the same sections of its entropy file, is encrypted by the client using AES, with a randomly generated key.
The key and the AES encrypted payload are then encrypted with the server’s public key and then sent to the server. The server uses its public key to decrypt the payload, obtaining the AES key, which in turn is used to decrypt the hash information. The server uses the interval values to construct the string from its entropy file that is hashed and compared to the one received from the client. If they match, the server retrieves the credentials needed by the client, encrypts them with AES, using the same key that it received from the client, and replies with the credential payload. The client decrypts the payload with the AES key it initially generated and then can use the credentials it received.
Considerations
There are several important considerations that should be noted. Firstly, the entropy file that the client and server have must contain the same text, but each of them must have their own copy. This file should be as large as is practical and each client should have a different file, with it being more secure to implement it in this manner. The entropy file could be rotated very frequently. The more frequently it is rotated, the more secure this system is. This scales very easily, with, for instance, 1,000 clients each having a unique entropy file that is rotated every 10 minutes being almost negligible in terms of the computational, bandwidth, and storage resources needed.
Encryption
Two encryption algorithms are used in our system. We use AES, which is an symmetric-key algorithm that therefore uses a secret key to encrypt data. It is used to encrypt the payload that is initially sent to the server and the credentials that the server sends to the client. This establishes a secure communications channel between the client and server that will remain secure even when no other encryption is used (e.g. SSL). We use RSA for two purposes: firstly, it allows the client to get the initial payload to the server in a secure manner, even in the absence of a secure connection. Secondly, the client knows that if it received a response from the server using the AES key the client generated and sent to the server, the client has received a response from a legitimate server, provided the server’s private key has not been compromised. The reason for using RSA is that just mentioned, while AES is used because it has no practical limit to the size of the plain text that can be encrypted, and it is very fast.
Extensions of the System
Although this article focuses on using autonomous identification for clients to obtain credentials, the system could easily be extended for almost any purpose where secure communication were needed and where an entity required a client to identify itself. In the model presented here, there is only one exchange between the client and the server as that is sufficient for the client to receive the credentials it needs. For other use-cases, there may be situations where multiple exchanges would be used. The system provided here is ideal for such exchanges, since they are always guaranteed to be secure as long as the server’s private key has not been compromised and the entropy file is not known to a third party. Through frequent and regular rotation of the server’s key pair and the entropy file for the client and server, the system is useful as a method for secure transfer of information.
Part 2 discusses a number of common use cases, and introduces our open source reference implementation
