Limiting Encryption Key Access on Alliance Key Manager

I am often asked about how one can restrict access to Alliance Key Manager (AKM), our encryption key manager.  There are a few different options available here in relation to locking down and controlling who has access to which keys.  This often is a concern for bigger organizations that have multiple departments authenticating to the encryption key manager and performing key retrieval operations, but I’ve known smaller companies as well that take advantage of the granularity AKM provides in this area.

One way you can restrict access to Alliance Key Manager is by restricting keys to specific users or groups of users. The users and group access can be defined on a system level, or at the level of each key. When you create a key you can define the restrictions on user and group access.

Since all connections to AKM are mutually authenticated over a TLS session, you as a client (key requestor) must present an X509 digital certificate to AKM that is signed by a trusted Certificate Authority (which needs to be known to the key server).  Within your client certificate are multiple fields of user data collectively known as the Distinguished Name (DN). Further, within the DN you'll define fields with information regarding who you are, what organization you are with and where you're located. There are two fields in particular that the AKM server will look at to determine your Group or User privileges. These are the Common Name (CN) field and the Organization Unit (OU) field. We look at the common name to determine user access and the organization unit to grant group authority.

Lets look at an example.  There is an AES encryption key available on an AKM server used to protect an employee's personal data. It is restricted so that only members of the Human Resources group can use that key. So any individual with "Human Resources" defined as their OU can successfully request that key, all others are turned away. This is Group Restricted Access.

To further this example, the director of Human Resources, Sam, needs access to a specific key only he can use. There would then exist an encryption key on AKM that has group and user policy defined as "Sam / Human Resources" and Sam's X509 digital certificate would have the CN of "Sam" and the OU of "Human Resources." This would ensure only he is allowed to access that key. This is strict group and user control of key usage and deters other "Sams" in the company from getting the key, as well as other individuals within the "Human Resources" department.

There are a few other ways to restrict access. You can specify just specific users who can access keys and ignore the group altogether. This would require defining a user table within AKM and tying specific keys to it. Then any user with the appropriate CN can authenticate and use those keys. The same can be done for groups as mentioned previously or any combination of group or user status as defined by the group or user table laid out on AKM.

And lastly you can allow anyone with an authenticated x509 digital certificate that can latch up to the key server successfully request a key. This method ignores the CN and OU altogether and is the least restrictive level of key access. However it still locks down key control as only authenticated clients with proper certificates can gain access to encryption keys.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.