Chapter 1: About This Manual

Alliance Key Manager

Townsend Security’s Alliance Key Manager (AKM) provides a complete key management solution, including server setup and configuration, key lifecycle administration, secure key storage, key import/export, key access control, mirroring, and backup/restore. AKM supports compliance audit logging of all server, key access and configuration functions.

AKM can be deployed using VMware, as a cloud server in Microsoft Azure or Amazon Web Services, as a privately managed Hardware Security Module (HSM), or as a dedicated Cloud HSM.

Server management is accessed via a secure web browser interface and you can create and manage encryption keys using the AKM Administrative Console. The AKM solution supports the generation of certificates and private keys needed for authentication between client and server.

A number of client-side applications, pre-compiled libraries, and code samples are available to help developers and key clients on a variety of platforms retrieve data encryption keys or perform remote encryption and decryption on the AKM server. All materials needed for deployment can be found on the AKM Evaluation Page.

Who is this for?

The AKM User Guide is designed for project managers, system administrators, crypto officers, and developers as an overview of the various components and steps involved in the deployment of Alliance Key Manager. This guide will provide useful information if you are interested in key management, you are evaluating AKM, or you are deploying AKM in a production environment.

This guide begins with an introductory chapter summarizing the basic components of the AKM solution (Chapter 2), continues with a deployment guide (Chapter 3), covers each step of deployment in more detail with references to other technical documentation (starting with Chapter 4), and ends with a chapter on troubleshooting and support (Chapter 14).

Notices

This product and documentation is covered by U.S. and International copyright law. This product may incorporate software licensed under one or more open source license agreements. Government users please note that this product is provided under restricted government use license controls. Please refer to the AKM End User License Agreement for more information.

Change Log

The following table provides information on the changes to this documentation:

Version Date Description
0.01 1/21/2009 Initial draft.
0.02 1/25/2009 Update several sections.
0.50 1/26/2009 First preview release.
0.51 2/10/2009 Clarifications to several sections.
0.52 3/8/2009 Updates for file locations, new sections for configuration.
0.53 3/17/2009 The backup and recovery section has been updated to cover the [akmsystem] directory.
0.54 4/2/2009 Add additional information about restoring the license file, and licensing in general.
1.00 5/15/2009 Formal release of the documentation corresponding to version 1.0.3 of Alliance Key Manager.
2.0.0 2/15/2010 Final version for release 2.0.4 of Alliance Key Manager.
2.0.1 3/8/2010 Add additional sections on key access types and security.
2.0.4 2/21/2011 Additional information is added about performance and the use of Microsoft Active Directory Certificate Services.
2.0.4 3/1/2011 An addition section has been added about key change (key rotation, key rollover). The section on mirroring has been restructured and expanded.
2.1.0 10/12/2011 Added information about the new encryption and decryption commands.
2.1.1 11/10/2011 Added Appendix A with step-by-step instructions for configuring mirroring.
2.1.2 11/22/2011 Add information about intermediate certificates.
2.1.3 11/26/2011 Add additional information about CA certificates.
2.1.3.001 1/16/2013 New manual format.
2.1.3.002 12/26/2013 Add security warning for the use of self-signed certificates.
3.0.0.001 1/31/2014 Revise and update for AKM 3.0.0. Move the Mirroring Step-by-Step Guide to the AKM Server Management Guide. Add introductory chapter, deployment guide, and chapter on evaluation. Add certificate information from AKM QuickStart for Windows.
3.0.0.002 2/18/2014 Add information on AKM Cloud deployments. Update information on intermediate certificates.
3.0.0.003 4/23/2014 Update directory locations for documentation.
3.0.3.001 10/9/2014 Update information on ready to use cloud implementations of AKM.
3.0.3.002 1/5/2015 Update for the ready to use version of AKM for VMware.
4.0.0.001 2/16/2016 Update for AKM 4.0 and support for TLS 1.1/1.2. Add information about migrating to a new version of AKM. Add information about bidirectional mirroring.
4.0.0.002 5/24/2016 Update for AKM 4.0 HSM release.
4.0.0.003 7/12/2016 Update for AKM 4.0 Azure release.
4.5.0.001 10/18/2016 Update for AKM 4.5 and asymmetric RSA key support.
4.6.1.001 11/8/2019 Updated links and references to technical information.

 

Chapter 2: Introduction

This chapter is designed as a brief introduction to the core components of Alliance Key Manager (AKM). Other chapters cover these concepts in more detail.

Deployment options

Alliance Key Manager can be deployed using VMware, as a cloud server in Microsoft Azure or Amazon Web Services, as a privately managed Hardware Security Module (HSM), or as a dedicated Cloud HSM. Your choice depends on a number of factors, including tolerance for risk, compliance regulations, infrastructure, and others.

Server setup, licensing, and generation of all required AKM certificates and private keys is completed automatically during initialization, and you have the option to create several data encryption keys.

See Chapter 4: Preparation for more information on deployment options.

Licensing

You will need a temporary or permanent license to deploy AKM for evaluation or production use. A temporary license will supply you with a fully functional AKM server that you can run using VMware, Microsoft Azure, or Amazon Web Services.

If you are deploying AKM for VMware, AKM for Microsoft Azure, or the Hardware Security Module, a 30-day license is generated automatically on initialization. With AKM for Amazon Web Services, if you choose a BYOL (Bring Your Own License) model, a 30-day license is generated automatically on initialization; if you choose a fee-based model, AKM will generate a permanent license.

If your temporary license expires, you will need to purchase a permanent license from Townsend Security or your software vendor.

Compliance and standards

Alliance Key Manager helps customers meet a variety of compliance regulations including PCI Data Security Standard (PCI-DSS) for payments, HIPAA/HITECH Act for the healthcare industry, GLBA/FFIEC for the financial industry, Sarbanes Oxley for publicly traded companies, FISMA for federal agencies, EU data privacy regulations, and many others.

Alliance Key Manager HSMs and Cloud HSMs are compliant with NIST FIPS-140-2 Level 1 (certificate number 1449), and all other AKM solutions run the same binary identical key management application as the HSM solution. AKM is also certified to Key Management Interoperability Protocol (KMIP) version 1.0. For information on implementing KMIP with AKM, see the AKM KMIP Implementation Guide.

TLS version

AKM supports the use of TLS 1.0, 1.1, and 1.2 for client/server communication. The default minimum TLS setting is 1.0, but for enhanced security you can modify the AKM configuration file (akm.conf) to restrict connections to TLS 1.1 or 1.2, by raising the minimum allowed value. See the AKM Server Management Guide for information on modifying the AKM configuration file.

During client/server TLS negotiation, the client and server will attempt to connect at the highest TLS level available. AKM will default to the highest TLS version supported by the client. However, if the minimum TLS version is set to 1.1 or 1.2 in the AKM configuration file and the client does not support TLS 1.1 or 1.2, then the connection will fail. In this case you must set the minimum TLS version to 1.0 in the AKM configuration file.

Certificates and private keys for authentication

AKM requires the use of certificates and private keys for secure TLS client and server authentication. Certificates and private key files uniquely identify an instance of the AKM server, protect and control the distribution of encryption keys and data, and secure access to the AKM Administrative Console.

All required authentication certificates and private keys are generated automatically during initialization and stored on the AKM server. Admin and key client certificates may be immediately downloaded and distributed for use in client application setup, and additional certificates may be created if needed.

Certificates used for authentication should be distinguished from asymmetric RSA keys used for data encryption and decryption, although they are both asymmetric keys.

Supported encryption keys

Alliance Key Manager supports key retrieval and remote encryption using either symmetric AES encryption keys and asymmetric RSA keys. These keys may be created on the server or imported. See below for more information.

Secure key storage

The AKM server is the secure server on which your data encryption keys are stored. The encryption keys are stored within a key database and protected by two secret keys, the Key Encryption Keys (KEK) and Authentication Key (Auth Key), which are 256-bit symmetric AES keys.

The AKM server is accessed via an encrypted web interface where System Administrators can perform server management tasks, including setting up logging, backup and restore, firewall configuration, and problem determination. There is no access to encryption keys via the web interface.

When deployed as a Hardware Security Module (HSM), additional physical access controls protect your encryption keys. You can deploy any number of additional secondary AKM servers for real-time key mirroring, high availability, or failover support.

Key creation and management

Access to data encryption keys is restricted to one or more Crypto Officers via the AKM Administrative Console. The Admin Console allows for secure and efficient management of data encryption keys throughout their life cycles. A key life cycle includes key creation, activation, change, expiration, revocation, archival, and deletion.

Encryption keys are never stored or transmitted in the clear, and are not accessible outside of your organization; there is no administrative access by Townsend Security, your cloud provider, or the hosting company.

The AKM Administrative Console supports dual control of all key management activities to increase the security of your encryption keys and to help you meet compliance regulations for dual control.

All AKM platforms include the option to generate several encryption keys during initialization, and additional encryption keys may be created using the AKM Administrative Console at any time.

Key import/export

AKM supports data encryption key import and export functions through the AKM Administrative Console. Key import and export functions are protected by secure and encrypted TLS communication.

AKM can export symmetric keys in binary (raw), Base64 encoded, Base16 encoded (hex), and RSA encrypted formats. For asymmetric keys, the public key may be exported in binary DER format. The private key may not be exported.

When the AKM server is configured for PCI-DSS compliance, keys can only be exported in an RSA encrypted format.

AKM Key Service and AKM Encryption Service

Using the AKM Key Service, you can retrieve encryption keys from the AKM server for local encryption in your application. With the AKM Encryption Service, you send your data to the AKM server for remote encryption and decryption on the AKM server so that the encryption keys never leave the server. All communication is secured by TLS.

Townsend Security provides a number of resources to help customers set up client applications for key retrieval or remote encryption. These include ready-to-use client applications, software libraries, and sample source code for a variety of platforms and languages. You can also use the AKM Key Service or AKM Encryption Service API documentation to develop a custom client implementation.

Mirroring, failover, and high availability

AKM supports real-time secure and authenticated distribution of encryption keys to remote secondary servers. Real-time mirroring capabilities provide for high availability failover, data redundancy, and load balancing support.

Encryption keys can be selectively mirrored to the secondary server(s). AKM also supports bi-directional mirroring.

Mirroring is configured during the AKM initialization process.

Backup and restore

AKM supports backup and restore operations for the key management application, authentication certificates, key database, and secret keys (KEK and Auth Keys). Backup and restore functions are accessed through the web interface, and can be fully automated through flexible scheduling options. Data Encryption Keys (DEKs) are backed up separately from KEK and Auth Keys. Backup files are transferred using secure and encrypted transfer options.

Compliance audit logging

Built-in system logging allows administrators to track all key retrieval, remote encryption, key management, and system activity. Logging is configured via the web interface, and you can configure automatic log reporting to a central log collection and management server, or Security Information and Event Management (SIEM) product for active monitoring and a timely and permanent record of activity.

 

Chapter 3: AKM Deployment Guide

Implementing the Alliance Key Manager solution requires that you complete a number of steps in a specific order. These steps are outlined below, with short descriptions and references to other guides. See specific chapters for more information on each step or concept.

 

Chapter 4: Preparation

This chapter describes several steps you must take before starting your deployment of Alliance Key Manager. These include:

  • Choosing a deployment option

  • Determining encryption needs

  • Licensing

  • Downloading related software from AKM Evaluation Page

  • Understanding key management roles and responsibilities

  • Taking note of important information regarding software updates

See below for more information.

Choose a deployment option

Townsend Security currently offers the AKM solution as a VMware virtual machine, a cloud server in Microsoft Azure or Amazon Web Services, a Hardware Security Module (HSM), or a Cloud HSM.

For all deployments, server setup and the creation of all required AKM certificates is completed automatically on initialization, and you will have the option to create an initial set of encryption keys for immediate use in your client application.

VMware, Microsoft Azure or AWS

AKM is offered as a virtual machine that may be run using VMware, or in the Microsoft Azure or Amazon Web Services cloud. These deployment options are best for customers already using a virtualized environment or for those who do not wish to use traditional IT infrastructure. With these deployment options, enterprises can reduce hardware costs, lower operational expenses and minimize the IT footprint.

Considerations for VMware

Please note the following considerations when installing AKM for VMware:

  • AKM for VMware is intended for use by customers with an appropriate level of knowledge of VMware configuration, deployment, and management. You should only deploy the key manager solution if you have adequate internal support for VMware and a support contract with VMware, Inc.

  • The currently supported VMware platforms are: VMware ESX, VMware vSphere (ESXi), and VMware vCloud

Hardware Security Module (HSM)

The Alliance Key Manager Hardware Security Module (HSM) is offered as a tamper evident 1u server for customers with traditional IT infrastructure who would like the AKM server to run on their network. The HSM may be preferable if you would like to set up your own physical security controls and take advantage of internal network speed and protections.

Cloud HSM

The Cloud HSM protects your cryptographic keys with HSM (Hardware Security Module) appliances in the Townsend Security cloud data center. This option may be best for those who do not have traditional IT infrastructure and who need to protect information in cloud and hosted environments. Customers can enjoy all of the benefits of AKM without needing to manage hardware.

Determine encryption needs

A common mechanism for encrypting data is for an application to use the AKM Key Service to retrieve an encryption key from the AKM server and use it for encryption and decryption tasks within the client application. The encryption key is transferred securely and then discarded after use.

In contrast, the AKM Encryption Service allows you send your plaintext data to be encrypted and decrypted with AES encryption remotely on the AKM server. The resulting ciphertext is returned to you, and you send the ciphertext back to the AKM server for decryption. Data is transferred securely, and the encryption keys never leave the server.

The AKM Encryption Service may be attractive when there is greater risk of exposure of a key, such as web facing applications, ATMs, kiosks, or other exposed environments. While remote encryption supports encrypting large quantities of data, it is best used for small pieces of data such as credit cards, social security numbers, and email addresses. Remote encryption may also be advantageous if you have a smaller number of resources on the client side or do not have an encryption library present within your environment to perform encryption.

License file options for remote encryption

There are options within the license file that control remote encryption (encryption and decryption on the AKM server). By default, both encryption and decryption are enabled.

In some environments there may be a compliance advantage in allowing only encryption or decryption. For example, at a point-of-sale checkout location you may want to restrict operations to credit card encryption, but prevent decryption in that environment.

You can disable encryption or decryption in the AKM configuration file, but for enhanced security, you may request a custom license file. In this case the settings cannot be overridden in the AKM configuration file.

Download additional AKM resources

The AKM Evaluation Page contains all of the material you will need to evaluate or deploy AKM, including client-side applications, SDKs, and sample code for key retrieval and remote encryption, as well as the AKM Administrative Console for managing encryption keys.

Understand roles and responsibilities

For security purposes, it is recommended to divide responsibilities relating to key management among different personnel or organizational units. NIST defines operational, security, and user roles which may be present when using a key management solution. In Townsend Security documentation, the following roles names are used:

  • System administrator

  • Crypto officer

  • Key client

System administrators, often equivalent to network or server administrators, install, configure, and manage the AKM server using the secure web interface to the key manager. They may also create certificates and private keys needed for authentication between the client and key manager.

Crypto officers, also known as security administrators, create and manage encryption keys on the AKM server using the AKM Administrative Console (Admin Console). They may also create certificates and private keys needed for authentication between the client and key manager.

Key clients, also known as end users, key users, or application users, use client-side applications to encrypt and decrypt data with key retrieval or remote encryption.

Software updates

When deploying to production, you must not attempt to apply any software updates through automated patch facilities or any updates not directly provided by your software vendor. Townsend Security will provide you with any needed updates to the web interface, operating system, and key management application through the Townsend Security customer support group.

IMPORTANT: Applying any updates not provided by Townsend Security will void your warranty, and you may be required to restore your system from backup in order to continue operation.

For current Townsend Security customers migrating to a new AKM server from an older version of AKM, see the platform specific deployment guide of the platform you are migrating to for instructions on completing the migration. Open a support ticket with Townsend Security for assistance.

Return to the Deployment Guide.

 

Chapter 5: Evaluate AKM

AKM for VMware, Microsoft Azure, or AWS

In order to become familiar with Alliance Key Manager and perform a proof of concept for AKM in your environment, it is recommended that you first deploy AKM as an evaluation server. You can use AKM for VMware, Microsoft Azure, or Amazon Web Services to perform the evaluation. You will use a temporary license that provides you with a fully functional server for 30 days.

For more information on installing and setting up these AKM platforms, see Chapter 6: Install and Set up AKM.

The license file

Alliance Key Manager is a licensed application and requires a license file to operate. A temporary license file will be automatically downloaded from the Townsend Security licensing server during initialization; if you then migrate to a permanent license, follow the instructions in your specific deployment guide to do so.

IMPORTANT: If you replace your AKM server you will need a replacement license file. In the event that you need to replace your server, please contact Townsend Security or open a support ticket requesting a replacement license.

Migrate from a non-production to a production environment

If you have used AKM in an evaluation or development environment, it is recommended to use new security objects in your production AKM server. You should remove all key client and admin (Crypto Officer) certificates and private keys used in testing from any applications/systems that have been used to evaluate AKM. You should then create new client certificates and use these certificates in your client applications. Additionally, you should avoid using the same data encryption keys in your production environment that were used during testing.

Failing to follow these recommendations will include your test environment in the scope of your production environment which from a regulatory and security stance exposes your applications and the key manager to risk.

AKM for VMware, Microsoft Azure, and Amazon Web Services

If you are deploying AKM for VMware, Microsoft Azure, or AWS, it is recommended to use a new instance of AKM for production. Your new AKM instance will produce unique security objects that differ from the ones used during testing. Make sure to adjust your client configurations accordingly.

If you would like to migrate to a production environment using your original instance, be sure to remove all test data and accounts that have had access to AKM prior to deploying key management in a production environment.

HSM and Cloud HSM

Those deploying an HSM or Cloud HSM will generate new security objects during initialization, replacing the ones used during AKM evaluation. Be sure to update your client configurations accordingly.

Return to the Deployment Guide.

 

Chapter 6: Install and Set up AKM

Installation and setup includes two steps: first launching the AKM virtual machine (if using VMware, Microsoft Azure, or AWS) or installing the Hardware Security Module in your data center (if using HSMs), then initializing the primary AKM server and any additional secondary mirror servers. This is usually performed by a System Administrator.

See below for more information.

Installation

Each AKM platform requires different steps for installation.

AKM for Amazon Web Services, AKM for Microsoft Azure, and AKM for VMware

For these platforms, steps for launching the virtual machine are included in these deployment guides:

These deployment guides then continue with server setup and initialization.

HSM

For the Hardware Security Module, use the AKM Hardware Installation Guide and AKM Hardware Rails Specification to install the HSM in your data center.

These guides cover electrical and safety guidelines, site preparation, unpacking the appliance, rear panel connections, and front panel operation. Please note the following considerations when installing the hardware appliance:

  • The appliance should be physically secured in a locking rack and/or data center.

  • The appliance requires 1u of rack space.

  • The appliance should be attached to a reliable UPS power source.

SECURITY ALERT: In order to achieve the highest level of security for your encryption keys, it is important that you restrict access to the AKM server. If using the Hardware Security Module (HSM), it is best practice to install the server in a rack separate from applications that will use the key server, secure the server in a locking rack, and install the server in a room with appropriate physical security controls. For VMware deployments, these recommendations apply to the server which hosts the VM.

Once the HSM has been installed, follow the steps in the AKM HSM Quick Start Guide for initialization.

Cloud HSM

With the Cloud HSM, installation is performed for you in the Townsend Security cloud data center. You retain full control of your keys and cryptographic operations on the HSM while Townsend Security provides the cloud platform, hardware service and server monitoring. For more information, see the Alliance Key Manager Cloud FAQ.

Initialization

After installation, you will connect to the AKM server via SSH (or via the VMware console if using VMware). This will launch an Administrative Menu from which you will initialize the AKM server.

This process creates a unique certificate authority (CA) certificate and server certificate for AKM, generates client certificate and private key pairs needed for key clients and admin clients to connect to the AKM server, activates the license, and starts AKM. You will also have the option to create an initial set of encryption keys for use in your client application.

NOTE: By default, one client certificate and two admin certificates are created by the initialization process. The two admin certificates can be used for dual control of encryption key administrative functions. You can create additional client or admin certificates through the Administrative Menu at any time. These certificates and private keys are stored on the AKM server and can be downloaded for use in your client application.

After initializing the primary AKM server, you can connect via SSH to a secondary mirror AKM server to set up this server for real-time key mirroring, high availability, or failover support.

Once you have initialized each server in your mirroring configuration and set the password, you can log in to the web interface and download the certificates and private keys needed for client/server authentication.

NOTE: It may be necessary to install patches during the initial setup of the AKM server. If patches are required, it is critical to install them when first logging in to the web interface. Customers with permanent licenses may contact Townsend Security Support for assistance at https://townsendsecurity.com/support.

Migrate AKM

The initialization process has an option to “Initialize from backup” for customers migrating from an older version of AKM. This option migrates the key database and authentication certificates to the new AKM server. See your platform specific deployment guide for more information on performing a migration.

Next steps

After completing these steps and the server is operational, the Crypto Officer can create additional encryption keys using the AKM Administrative Console if needed, or manage existing encryption keys that were created during the initialization process.

After encryption keys are created, it is recommended to perform a backup of the key server. Backups are completed via the web interface and are usually performed by a System Administrator. See Chapter 11 for more information.

If additional authentication certificates are needed, these can be created using the Administrative Menu.

Return to the Deployment Guide.

 

Chapter 7: Authentication Certificates

Alliance Key Manager requires the use of certificates and private keys for authentication during secure TLS communication. This chapter describes authentication certificates, how they are used by AKM, and how to generate the required certificates.

What are certificates?

Certificates are used to verify the identity of their holders and authenticate two or more parties during secure TLS communication. A certificate file contains a public key and several pieces of information about the key, including validity dates, who the certificate is issued to, the identity of the issuer, what the certificate can be used for and a hash of the certificate. Private keys are confidential and must be restricted to authorized users, as they allow sensitive functions to be performed (key retrieval, administration, etc).

SECURITY ALERT: Private key files must be protected during creation, distribution, and storage to prevent loss. The loss of these files will compromise the security of the AKM server. Depending on the file format, the private key files may be bundled with a certificate or they may be separate files. Transfer the private key files by sharing them over a secure network, placing them in a password-protected zip file, sending them using SFTP, or another secure method. Use the same level of care you would employ to protect encryption keys, including encryption. In the event the private keys are compromised or lost, you should immediately replace the certificate authority on the AKM server and all client certificates in that chain of trust. See the AKM Certificate Manager Guide for more information.

How does AKM use certificates?

AKM uses certificates to verify identities during access to the AKM server by one or more Crypto Officers, access to the server by a System Administrator, key retrieval and remote encryption requests by client applications, high availability mirroring to secondary AKM servers, and key import and export functions.

Generating certificates for use with AKM

All required AKM certificates and private keys are created automatically on the AKM server during initialization, including a unique CA certificate and signed client and admin certificates. You can also create additional client and admin certificates or sign certificate signing requests if needed. See the specific guide for your deployment for more information.

Other methods for generating certificates

You can use a private or public certificate authority (CA) to manually create the required certificates for AKM. However, if you use this CA to sign other certificates outside of AKM, you create a security risk that allows anyone with a certificate signed by this CA to access the AKM server.

SECURITY ALERT: It is highly recommended to use AKM-generated certificates, and to not use these certificates outside of AKM. If you use a private CA, be sure to create a CA certificate solely for use with AKM.

Intermediate CA certificates

If you are using a private or public CA to manually create AKM certificates and you have used this CA certificate outside of AKM, it is not possible to use an intermediate CA certificate to limit access to the AKM server. It is highly recommended that you use a CA certificate created solely for use with AKM.

Self-signed client certificates

SECURITY ALERT: While it is possible to use self-signed client certificates and to update the AKM configuration file to make them trusted, it is strongly recommended that you do NOT do this. When this approach is taken, a self-signed client certificate can be used to sign other client certificates which can then be used to authenticate to the AKM server. This is an unacceptable security risk and you should not use this approach. Be sure to use a client certificate signed by AKM’s CA certificate.

What certificates does AKM use?

AKM uses a certificate authority (CA) certificate, server certificate and private key, KEK and Auth certificates and private keys, administrative (Crypto Officer) certificates, and client certificates. See below for more information.

Certificate authority (CA) certificate

The AKM server requires a certificate authority (CA) certificate in order to sign admin certificates, client certificates and AKM server certificates.

Server certificate and private key

Each AKM server requires a server certificate and private key. The server certificate must contain a Subject Distinguished Name with the first Organizational Unit (OU) field akm_server. AKM-generated certificates fulfill this requirement.

KEK and Auth certificate and private key

AKM requires a KEK (Key Encryption Key) certificate and private key and an Auth (Authentication) certificate and private key. These files are used on the AKM server to create the KEK and Auth Keys. These “secret keys” protect the AKM key database. The KEK is used to protect data encryption keys. The Auth Key is used to detect and prevent corruption or substitution of data encryption keys and key attributes.

Administrative certificates

To create and manage keys on the AKM server using the AKM Administrative Console or under program control, you must install both AKM’s CA certificate and an admin certificate/private key signed by AKM’s CA certificate installed on the admin client.

The admin certificate must have a subject distinguished name with the first Organizational Unit (OU) field that includes the value akm_admin. Administrative sessions will be rejected without both a valid and recognized certificate, and an OU name with the correct value. AKM-generated admin certificates fulfill this requirement.

Client certificates

Each key client that retrieves keys or uses remote encryption on the AKM server also requires a signed client certificate/private key and AKM’s CA certificate. The client certificate will contain a subject distinguished name with a Common Name (CN) and a first Organizational Unit (OU).

The CN and OU are used in the AKM Administrative Console to restrict access to encryption keys to certain Users and Groups. For more information on key access control, see (Chapter 10). For more information on key retrieval and remote encryption, see (Chapter 13).

The Windows platform has special requirements for certificates. Windows stores certificates in the Windows certificate store. Windows imports certificates in the PKCS#12 format for client certificates and private keys. The CA certificate must be in .pem or .der format. See the AKM Guide for Windows .NET Developers for more information on Windows certificates.

How do certificates work?

Mutual authentication with AKM uses X509 certificates. This is a brief overview of how X509 certificates are used for secure communication. Additional resources describing the X509 standard can be found online.

If you use standard AKM tools for certificate generation, a private certificate authority (CA) certificate is created for use with AKM. This is the root CA certificate, and it is used to sign key client and admin certificates for authentication with the AKM server.

If using a public or private certificate authority, a System Administrator (SysAdmin) creates an asymmetric key pair (public/private key pair), then submits the public key to the public or private certificate authority (CA) in the form of a certificate signing request (CSR). The CA signs the certificate. This means the CA runs the public key through a hash algorithm with its own private key, generating a signature. This signature is appended to the certificate.

The signature of the certificate can be checked by a client who possesses the CA certificate. In fact, certificates can be validated through a chain of signatures–one certificate signs another, which in turn signs a third, and so on. At the top of the chain, a root certificate authority (CA) is assumed to be secure and trusted. A client can validate these signatures up the chain as long as the last certificate–the root CA certificate–is in its store of trusted certificates.

The root CA can distribute its certificate to any number of clients, who will be able to validate any certificates as long as they are signed by a certificate chain leading back to the root CA.

In this diagram, the “Client” box represents the AKM client certificate, and the “CA” box represents the root CA certificate that issued, or signed, the client certificate. CA is the signing CA of the Client certificate. This is the simplest validation chain:

image alt text

In the next diagram, the CA1 box represents an intermediate, subordinate CA certificate that issued the client certificate. CA1 is the client certificate’s signing certificate. The CA0 box represents the root CA certificate that issued the intermediate CA certificate.

image alt text

Return to the Deployment Guide.

 

Chapter 8: Create and Manage Encryption Keys

Encryption keys can be created and managed using the AKM Administrative Console GUI application or via the AKM Admin API. See below for more information.

AKM Administrative Console

After setting up the AKM server you may use the AKM Administrative Console application available on the AKM Evaluation Page to create and manage encryption keys. This Windows application provides a GUI interface for key management tasks, including creating, rolling, revoking, listing, and deleting keys, importing and exporting keys, and managing key access. Key access is based on the Common Name (CN) and Organization Unit (OU) of the client certificate. The Admin Console also includes commands to determine key server status, set up mirroring, and other administrative functions.

See the AKM Administrative Console Guide for a full list of administrative and key management commands.

All AKM deployments include an option during initialization to create a set of encryption keys which can be used in client applications for proof of concept, development, or production.

These encryption keys are set for general access. That means anyone with a valid key client certificate for AKM can retrieve these keys or use them for remote encryption. If you have multiple clients and you would like to implement key access control, you can change the access level for these keys or create new encryption keys with a restricted access level in the AKM Administrative Console. Key Access is based on the Common Name (CN) and Organization Unit (OU) of the client certificate.

SECURITY ALERT: The Admin Console should be secured to known Crypto Officers, and care should be taken to physically secure the workstation where the Admin Console is installed. The loss or the compromise of these systems can mean the potential loss of encryption keys. Take the necessary precautions to secure access to the Admin Console.

IMPORTANT: Certificates created with AKM tools include two admin certificates two admin certificates for use by two Crypto Officers to enable the implementation of dual control. If only one Crypto Officer is needed, either admin certificate can be used. If you would like to create additional admin certificates, see your platform specific deployment guide. For instructions on enabling dual control, see the AKM Administrative Console Guide.

AKM Admin API

Townsend Security documents the AKM Admin API in order to enable customers to create custom administrative application or use admin commands under program control. See the AKM Admin API Reference for more information.

Return to the Deployment Guide.

 

Chapter 9: Cryptoperiod Concepts

This chapter covers information about key rollover and cryptoperiods. Key rollover is the process of creating a new instance (version) of a key. A cryptoperiod is the interval of time during which a key is authorized for use. This length of time will be determined by the security policy of your organization.

Alliance Key Manager supports key rollover for symmetric encryption keys. Asymmetric RSA keys cannot be rolled. See below for more information.

Key rollover

Key rollover, also called “key rotation”, “key change”, or “re-keying”, is the process of decrypting the protected data with an older key and encrypting it again with a new instance of the same key. It is required by some compliance regulations and is considered good security practice. AKM supports key rollover by providing for the automatic or manual generation of new key instances, while maintaining the older key instances and their relationship to the original key.

IMPORTANT: Implementing automatic or manual key rollover in AKM never actively changes your database or protected data. The role of AKM is restricted to managing the encryption keys through their life cycles, and in performing new key generation tasks when you request them.

Key names and key instances

Every encryption key created by AKM is given a key name and an instance (version) name. When a symmetric key is rolled, a new key is created with the same key name and a new instance name. This maintains the relationship of each instance to the original key.

A rolled key is technically a new key, but since the key name does not change, it is considered a new instance of the same key. Every time the key is rolled and a new instance is created, this becomes the “current” instance of the key (sometimes known as the “default” instance). All older instances of the key are retained until you explicitly delete them.

Asymmetric RSA keys cannot be rolled, but the public and private keys each have a key instance, as well as a “paired instance”. The paired instance indicates the key instance of the corresponding public or private key in the pair.

IMPORTANT: When performing a key retrieval or remote encryption request, you specify the key name, the key instance, or both. You can leave the key instance blank and supply only the key name, and AKM will retrieve or encrypt with the current instance of the key. The instance name used is always returned in the response data and can be stored in a column with the encrypted data. You can then specify the correct instance of the key to use on decryption. This use of the instance name means that you can easily roll the key without having to re-encrypt data that was protected with an older instance of the key. Data protected with older instances of keys can be re-encrypted in low priority batch jobs if desired.

You can also specify a key by instance name only and leave the key name blank. You can do this if you only want to store the key instance on key retrieval, for example.

Automatic and manual key rollover

AKM supports both automatic and manual rollover of symmetric keys. If you specify that the key rollover is automatic, you must also specify the number of days for the key rollover interval (the cryptoperiod). AKM will automatically create the new instance of the key after the number of days you specify. All of the original key attributes will be copied to the new instance, with the exception of metadata fields. If you choose manual key rollover, you will need to use the AKM Administrative Console to manually roll the key every time you want to create a new key instance.

Alternatives to key rollover

In some cases it is not possible or convenient to store the instance name in a new column in the database. In this case you could simply create brand new keys. For example, you could create an encryption key named “Orders2010” and another key named “Orders2011”. During the year 2010 you would use the key named “Orders2010” to protect data. On the first day of 2011 you would decrypt all of the rows in the table with the “Orders2010” key, and re-encrypt them with the key named “Orders2011”. With this type of implementation you rely on application controls and processes to manage the key change operation.

Return to the Deployment Guide.

 

Chapter 10: Key Access Control Concepts

This chapter covers information about setting policies for encryption key access. This is normally performed by a Crypto Officer using the AKM Administrative Console.

Encryption key access is based on information contained in client certificates.

Client certificates

The client certificate is used to secure the connection with TLS communications, validate that the user has a known and valid certificate, and validate the user’s access rights to the encryption key. Certificates are the most important element in ensuring the security of the encryption keys and the appropriate use of the keys.

When creating client certificates for key retrieval or remote encryption using AKM certificate generation tools, you must specify a subject distinguished name. The distinguished name may contain several fields including the Country, State or Province, City, Organization, Organizational Unit (OU) or Department, and Common Name (CN). An example of a subject distinguished name is:

C=US, ST=California, L=Pasadena, O=Big Company, OU=Accounting, CN=Bill Smith

AKM uses the first Organizational Unit (OU) field as the Group, and the Common Name (CN) as the User. In this case the OU field has the value “Accounting” and the CN field has the value “Bill Smith”, and depending on the key access policy, Bill Smith would have to be defined as a User and Accounting would have to be defined as a Group when defining key access in the AKM Administrative Console.

Users and Groups

“Users” and “Groups” are used in Alliance Key Manager to define key access. The term “User” in AKM should not be confused with the common definition of “user” as a logon to an operating system or application, although they can be set up to correlate. When defining key access in the AKM Administrative Console, the User and/or Group must match the Common Name (CN) and Organization Unit (OU) of the client certificate. In other words, it is not the user logging on to a workstation that can access a key, it is the holder of a certificate defined for key access via the Admin Console.

SECURITY ALERT: Protecting the private keys associated with client certificates is an important part of a comprehensive security strategy. It is crucial to limit access to these private keys during the creation, distribution, and storage of client certificates.

Key access policy

When you create a key, you can choose between five levels of key access policy:

  • Anyone

  • User

  • Group

  • User + Group Permissive

  • User + Group Strict

Anyone: The key is available to anyone holding a client certificate.

User: The key is available to anyone holding a client certificate that has a Common Name (CN) that matches one of the Users defined to have access to this key. You can give additional Users access to this key using the “Set User Access to Key” command in the Admin Console.

Group: The key is available to anyone holding a client certificate that has an Organizational Unit (OU) that matches one of the Groups defined to have access to this key. You can give additional Groups access to this key using the “Set Group Access to Key” command in the Admin Console.

User + Group Permissive: The key is available to anyone holding a client certificate that has a Common Name (CN) that matches one of the Users defined to have access for this key, and an Organizational Name (OU) that matches one of the Groups defined to have access to this key.

User + Group Strict: The key is available to anyone holding a client certificate that has a Common Name (CN) that matches one of the Users defined to have access for this key, and an Organizational Name (OU) that matches one of the Groups defined to have access to this key, if the User has been added to a Group defined to have access to this key. This must be done with the “Add User to Group” command in the Admin Console.

SECURITY ALERT: It is strongly recommended that you restrict encryption keys to specific users. In the event a user certificate is lost or misappropriated, you can remove the user’s access to encryption keys by removing the user and (optionally) group from access to a key, or to all keys. If you specify that a key is available to any user, you will not have the ability to revoke an individual user from key access.

Return to the Deployment Guide.

 

Chapter 11: Manage the AKM Server

System Administrators can perform server management tasks using the web interface. See the AKM Server Management Guide for instructions on the following tasks:

  • Backup and restore

  • System logging

  • AKM configuration

  • Firewall configuration

  • Network configuration

  • Manual mirroring setup

For further explanation of concepts relating to managing the AKM server, see the sections below.

Backup and restore

You can use the Backup and Restore option to recover from a hardware, software, or user error that results in the loss of your AKM server. The backup process creates two files:

  • Application backup (key database and application configuration files)

  • Secret keys backup (KEK and Auth Key)

All sensitive data in the application backup is encrypted before it is copied to the backup files. Once the backup files are created you can use the web interface to automatically export the files to an off-site server or download the files to your PC for secure storage.

SECURITY ALERT: The two backup files should never be stored together as the loss of both files together represents a compromise of the encryption keys. If you transport the backups to an off-site server, be sure that the files are transferred and stored separately .

If you are unable to perform a normal restore from backup, you may be able to recover some encryption keys from a mirrored key server. However, this option is limited and should not be considered a substitute for performing backups.

System logging

The AKM server implements system logging to record critical application and security events. It also records key access and retrieval activity. System logging can be configured when you install the AKM server, or at any time thereafter. It is recommended that you turn on system logging during server setup, and that you transmit system logs to a central log collection server to permanently store key server events. Note that many compliance regulations require or strongly recommend that you collect and store encryption key management and access events.

If you do not collect system logs to an external server, AKM will retain system log activity for a period of time. Automatic log rotation will eventually remove older events in the log.

If you are using a Security Information and Event Management (SIEM) system such as Alert Logic, ArcSight, Dell SecureWorks, LogRhythm, Novell Sentinel, or Solutionary, you can implement security alerts when AKM reports the denial of access to a key.

The AKM configuration file

The AKM configuration file (akm.conf) contains the basic configuration options for the AKM server. This includes IP addresses and ports for administrative, mirroring, and crypto services, names of certificates and private keys, and other administrative options.

The configuration file is created automatically during initialization, but may be customized via the web interface.

Network configuration

Alliance Key Manager uses standard TLS secure connections for all connections to the AKM server, including key management, server management, backup and restore, mirroring, key retrieval, and remote encryption services.

Network configuration is completed during server initialization, but may be customized via the web interface.

IMPORTANT: If you would like to use different ethernet ports for key management and key retrieval, you can configure the AKM server to use one Ethernet port for administrative functions and another for key retrieval and mirroring. See the section on modifying the AKM configuration file in the AKM Server Management Guide for more information.

Firewall configuration

The web interface to the AKM server runs on a SUSE Enterprise Linux platform and provides access to full Linux firewall facilities. Out of the box firewall protections limit inbound access to ports and services. You can add additional firewall rules to further protect access to the AKM server.

Mirroring

AKM supports real-time mirroring of keys, access policies, and user and group information to one or more secondary AKM servers. See Chapter 12: Mirroring Concepts for more information on mirroring.

Return to the Deployment Guide.

 

Chapter 12: Mirroring Concepts

The Alliance Key Manager solution includes high availability mirroring of encryption keys, access policies, and user and group information to one or more secondary AKM servers.

Mirroring is configured during server initialization. See platform-specific deployment guides for more information.

Mirroring can also be configured manually. See the AKM Server Management Guide for more information.

NOTE: If you manually configure mirroring after you have already created encryption keys, you will need use the “Force Key Sync” command in the Admin Console to cause the key and any previous instances to mirror. See the AKM Administrative Console Guide for more information.

Why mirror?

Mirroring of keys is recommended for AKM customers who:

  • need high availability recovery of key server operations in the event of a server failure, hardware problem, or network outage

  • wish to implement load-balanced key retrieval

  • need to distribute keys to remote key servers

Protect against server failure

For many users, a key management solution is a critical piece of infrastructure in their IT systems. In order to reduce the possibility of downtime due to a failure of the primary AKM server, customers may wish to implement high availability mirroring to a secondary AKM server.

Load balancing

Mirroring is also advisable for customers who need load-balanced key retrieval between two or more servers. This function is not implemented by AKM, but can be implemented using common network load balancing applications.

If you use load balancing with two or more AKM servers, it is recommended that you designate a primary AKM server to create and manage keys, and that you mirror the keys to the additional AKM servers. This will help avoid complexity in the key management strategy.

Please be aware that there may be a few seconds between the time that a key is created and the time that it is copied to a mirror server and committed to the mirror server key database. If you are using a load balancing strategy you should consider creating keys in advance of their use by applications.

Distributing keys to remote servers

You may also wish to implement mirroring to distribute keys to remote key servers. If your company maintains remote locations you can distribute encryption keys automatically while centralizing key management functions. Applications at remote sites can then access keys locally to perform encryption operations. The encryption keys retrieved from the remote server will also be available to applications at the central site.

Key level mirroring

Each encryption key has a mirror attribute that indicates whether the key should be mirrored or not. This means that you can create some keys that are mirrored to other servers, and other keys that are not mirrored. You define this attribute when you create the key using the AKM Administrative Console, and you can change it at any time. If you enable mirroring of a key, it will be mirrored to all of the secondary AKM servers that you configure. It will apply to previous instances (versions) of the key, and will automatically apply to future instances of the key that are generated by key rollover.

Real-time mirroring

Mirroring is performed in real time. That is, when you make a change to an encryption key’s attributes, create a key, or change access policy for a key, these changes are queued for immediate transmission to all of the secondary AKM servers. If there is a failure in the link between the primary AKM server and the secondary AKM server, the transactions remain queued for transmission, and AKM retries sending the transactions every six minutes. When the remote server is available the transactions will be sent. You can also use the “Trigger Put” command in the Admin Console to immediately retry sending all queued mirror transactions.

Topologies

AKM supports both hub-and-spoke and meshed network topologies, or variations on these types of network topologies. However, you must understand the flow of keys through your network and avoid potential collisions and duplications of key mirroring. Because key operations are very fast, it is recommended that you implement a hub-and-spoke design for key mirroring. This is usually the best design for both recovery and high availability.

Mirroring status

There are several commands available in the Admin Console to help you view the status of mirroring on your system. See the AKM Administrative Console Guide for more information.

Bidirectional mirroring

AKM supports bidirectional mirroring of keys between two AKM servers, also called active-active mirroring. Each server can be configured to send keys to the other server, and to receive keys from that server. Mirrored keys will not be redundantly transmitted back to the originating key server.

Bidirectional mirroring is helpful when you are creating and managing encryption keys under program control. In the event of a failure of a server you can continue to create and manage keys on the secondary server, and those keys will be mirrored to the primary server when the service is restored.

To configure bidirectional mirroring during server initialization, follow the steps in your platform specific deployment guide. To configure bidirectional mirroring manually, see the AKM Server Management Guide.

IMPORTANT: When you define bi-directional mirroring you should take care to avoid a collision in key names if you create keys on both servers. For example, if you create a key named “Orders” on one server, and then create a key with the same name on the secondary server, mirroring will not be able to resolve the name conflict. You should not create a new key with the same name on two different mirrored servers.

Client/server connections

Some client-side SDKs (.NET and Java) provide intelligent failover if you configure multiple secondary AKM servers in your client application. If there is a failure to connect to the primary AKM server, an automatic attempt is made to connect to the next AKM server in the array, and so on to the end of the array.

Backup and restore

Mirroring is not a substitute for normal backup of the AKM server. You should make periodic backups of your AKM servers, as well as after significant changes to keys, user access policies, and authentication certificates, to ensure that you can restore the servers if needed. Please see the section on Backup and Restore in Chapter 11: Manage the AKM Server for more information.

Return to the Deployment Guide.

 

Chapter 13: Key Retrieval and Remote Encryption

This chapter describes key retrieval and remote encryption, certificates needed for client/server authentication, and resources for client-side implementations, including ready to use client applications, software libraries, and sample code.

Key retrieval

Client applications can retrieve encryption keys from the AKM server through a secure and mutually-authenticated TLS connection. This is the highest level of session authentication necessary for complete end point security. A request/response data protocol is used in a single session environment for key requests and delivery. Permanent TLS sessions are not allowed for key retrieval and encryption keys are never communicated in the clear.

Encryption keys can be retrieved in one of three formats: Binary (raw), Base16 encoded (also known as hex encoded), and Base64 encoded. The last two data formats are designed to be friendly to applications that cannot receive binary information. Once an encryption key is retrieved it can be used for many encryption and decryption tasks. Additionally, it can be cached by your application for further use.

Remote encryption

With remote encryption (sometimes known as on-board encryption), you enable client applications to encrypt and decrypt data on the AKM server. For vulnerable client applications when there is more risk of exposure of encryption keys, you can use remote encryption which never exposes encryption keys in the user application environment. The encryption keys never leave the AKM server and all data to be encrypted or decrypted is protected by mutually authenticated TLS encrypted communications.

Authentication certificates and private keys

You must install AKM’s CA certificate and a valid client certificate/private key signed by AKM’s CA certificate onto the client in order to authenticate with the AKM server. The AKM server will validate your client certificate during TLS negotiation and when applying user and group key access policies.

Certificates are the most important element in ensuring the security and appropriate use of the encryption keys. See Chapter 7 for more information on authentication certificates.

SECURITY ALERT: Private key files must be protected during creation, distribution, and storage to prevent loss. The loss of these files will compromise the security of the AKM server. Depending on the file format, the private key files may be bundled with a certificate or they may be separate files. Transfer the private key files by sharing them over a secure network, placing them in a password-protected zip file, sending them using SFTP, or another secure method.Use the same level of care you would employ to protect encryption keys, including encryption. In the event the private keys are compromised or lost, you should immediately replace the certificate authority on the AKM server and all client certificates in that chain of trust. See the AKM Certificate Manager Guide for more information.

SECURITY ALERT: The standard approach to client/server authentication is to install the root CA certificate onto the client in addition to the client certificate/private key. However, with some client-side SDKs (.NET and Java) you can install AKM’s server certificate(s) onto the client instead of the CA certificate and reference the server certificate(s) in your application configuration. This process is called “certificate pinning” and it creates an additional layer of security on the client. See the AKM Guide for Windows .NET Developers or AKM Guide for Java Developers for more information.

Key names and key instances

When performing a key retrieval or remote encryption request, you specify the key name and the key instance. You can leave the key instance blank and supply only the key name, and AKM will send or use the current instance of the key. The instance name used is always returned in the response data and can be stored in a column with the encrypted data. You can then specify the correct instance of the key to use on decryption. This use of the instance name means that you can easily roll the key without having to re-encrypt data that was protected with an older instance of the key. Data protected with older instances of keys can be re-encrypted in low priority batch jobs if desired.

You can also retrieve a key by instance name only and leave the key name blank. You can do this if you only want to store the key instance.

For more information on encryption keys, see (Chapter 9: Cryptoperiod Concepts).

Resources

Townsend Security provides a number of client-side applications, pre-compiled libraries, and code samples to help key clients on a variety of platforms retrieve data encryption keys or perform remote encryption and decryption. See below for more information.

Applications

Townsend Security offers several ready-to-use client applications for key retrieval and remote encryption. These include:

  • Key Connection for SQL Server: Microsoft Extensible Key Management Provider for Transparent Data Encryption (TDE) and cell level encryption

  • Key Connection for Drupal: Encryption and key management for Drupal

  • Alliance AES/400: IBM i DB2 FieldProc automatic encryption support

Please contact Townsend Security for a current list of client applications. If a client application for your platform is not available, see the following sections on software libraries and sample code.

Software libraries

To assist developers in implementing key retrieval and remote encryption in their applications, Townsend Security provides several software libraries for a variety of platforms and languages. These include:

  • Shared library in C (can also be used in C++)

  • IBM i (AS/400) service program

  • IBM z Mainframe Dynamic Link Library

  • Java JAR file

  • Linux shared libraries

  • Microsoft .NET Assembly (DLL) and C# sample code

  • Perl modules

Please contact Townsend Security for a current list of available software libraries.

Sample source code

Townsend Security offers sample source code for a variety of languages to assist customers in writing their own client implementation. Sample source is available for:

  • .NET (C#)

  • COBOL

  • Java

  • Perl

  • PHP

  • PL/SQL

  • Python

  • RPG

Contact Townsend Security for a current list of sample source code offerings.

AKM key retrieval and encryption APIs

If AKM does not supply a pre-compiled library for your platform or if you have a need for special processing of the key request, you can create your own client implementation following the guidelines in the AKM Key Service API Reference or AKM Encryption Service API Reference.

You will use the following process to enable your client applications to encrypt or decrypt data on the AKM server:

  1. Format a data request to retrieve a key or perform encryption

  2. Open a TCP connection to the AKM server

  3. Secure the connection with TLS

  4. Send the request to the AKM server

  5. Receive a response from the AKM server

  6. Close the connection to the AKM server

  7. Read the response into your application

Development services

Townsend Security regularly develops new client applications, software libraries, and sample source code to assist with client implementations, and provides full technical assistance for all offerings. The company may also provide additional development services as needed.

Return to the Deployment Guide.

 

Chapter 14: Troubleshooting and Support

Troubleshooting

See the AKM Problem Determination Guide for information on performing external, installation, management, and system administration checks.

For Townsend Security customers with permanent licenses, start a support ticket on the Townsend Security website if you need further assistance.

Support

Technical support is available via the website at http://townsendsecurity.com/support/ticket for Townsend Security customers with permanent licenses.

Please see the Townsend Security Maintenance Policy you received with your purchase for information on fees, online technical support, documentation, license transferability and upgrades, software maintenance, hardware maintenance, customer responsibilities, limitations, disclaimers, lapsed maintenance, enhanced maintenance services, and other topics.

Enhanced maintenance services

Townsend Security offers an Enhanced Annual Maintenance contract that includes priority telephone support, 24/7 (24 hours a day, 7 days a week) support, and other benefits for an additional charge.

Return to the Deployment Guide.