Modern Data Centers have hosts that run application services with minimal human intervention. These hosts and servers occasionally need to be restarted for maintenance and this is usually done in an unattended manner. Most of these application servers need to access services and data from other servers, like for example, database servers. If this data is sensitive, then the requesting server should provide security credentials to verify that it is authorized to access the data. These credentials are typically needed when the application server starts and establishes connections with other peer servers. They may also be needed at other times, like when the connections time out or the credentials expire. The problem is that there is no secure way to store the credentials on the host.
Most application servers today have a configuration file installed on the host along with the server software. Besides other configuration options, these files contain the security credentials that this server needs to authorize itself to other peer servers that it works with. This is a vulnerability because the credentials can be copied and misused by others. For example, someone who has legitimate access to the server for maintenance could use the server's credentials to gain unauthorized access to a personnel database. While there are techniques like tokens & capabilities that can be used to limit access to specific sources and operations, most of the services (like databases) require old fashioned username & passwords. The credentials can be safe guarded using currently available host security, but this is often insufficient and ineffective. What is needed is a way to securely store the credentials and control its distribution.
The term server refers to a software application service, and the term host refers to a physical or virtual machine. This note only addresses authorization for processes and does not deal with authorization for human users.
1. As always, the system should be convenient to use and should not impede legitimate use.
2. The logs generated by the system components should be sufficient to enable auditing that can unambiguously trace and identify any unauthorized access. In the rare cases where unauthorized access cannot be prevented, alerts should be generated quickly so that a perpetrator can be stopped before significant damage is done.
3. The solution must be usable by at least 90% of the existing application servers in the data center, specifically it should address Linux and Windows hosts. Implementing multiple disjoint solutions to this problem would be quite unsavory.
4. The solution should support different types of credentials, for example: username/password, tokens, public/private keys, time based token generators, ...
5. A specific instance of an unattended process running on a specific host should be recognized as the authorized requestor of credentials to specific peer servers.
6. It is assumed that the installation of the server on a host is performed securely by a trusted party. If the configuration is incorrect, or does not follow the guidelines, then secure operations cannot be guaranteed.
7. There should be convenient ways for application servers to get the credentials they need. For custom built applications, there will be an API library. For applications that cannot be modified, there will be separate executable modules to securely retrieve credentials and place them in the expected location before the application server starts. Think of these as shims between the server and the proposed authorization mechanism. The retrieved credentials could be good for single use only. Unfortunately, it is likely that there will be servers that will require more creative solutions.
The solution leverages the Trusted Platform Module 2.0 (TPM) that is available on most popular servers. All Dell platforms have this as an option and VMWare Virtual Machines seems to support it. TPM has several functions, but the most important function is that it securely houses a private key that is unique to the host. Items signed with this key can be validated by a matching public key that will be available to a Validator. The signature assures validators that it was created by an app server on the specified host. It is not possible to extract that private key to forge a signature. The items signed will include a millisecond timestamp, the name of the requesting app, and the host name. The signature helps assure validators that it was created on behalf of the authorized server and that it is not a re-played copy. Loop files can be used to securely transfer the credentials to the requesting app.
For application servers that can be modified to use this concept, the signature exchange should be sufficient to authenticate both parties, thereby bypassing the need for additional credentials. For legacy applications, the validator would be an Authorization app that stores passwords for multiple application server pairs. Once it is assured of the requestor's authenticity, it will return a suitable password credential. This can be used to set up the connection between the requesting app server and the peer server. Optionally, the Authorization app can set up a one time password for the peer server and return that to the requesting server.
The hard parts will be to adapt this solution to existing applications and to market the idea.
A quick market survey has found no product that uses the TPM facility to accomplish the objectives outlined here. This is despite TPM having been available for almost 10 years. Microsoft uses TPM for its BitLocker encryption product, but that is a totally different solution to a different problem.
We need to verify that VMWare supports this API for virtual hosts.
Lastly, we also need to verify the practical need for this solution and that there are no prior claims to it. I had discussed this concept more than 30 years ago so, unless WBD has forgotten all about the 'Walnut', this idea is not patentable.
A software prototype that uses TPM to generate a signature can be built. The protocol used by the solution can be documented and published for peer review.
© 1980, Vandana Nadkarni