AKM for AWS Quick Start Guide

Page Information

Last updated: 07.31.2018

Chapter 1: About This Manual

AKM for AWS

Alliance Key Manager for Amazon Web Services (AKM for AWS) is deployed as an Amazon Machine Image (AMI) in the AWS cloud. AKM for AWS is offered both as a BYOL (Bring Your Own License) model and a fee-based model. AKM for AWS allows you to quickly set up key retrieval or remote encryption in your client application. Initialization of the AKM server is controlled through a text interface Administrative Menu. A license and all of the certificates and private keys needed for TLS will be generated through the menu, and you will have the option to generate an initial set of encryption keys which can be used in client applications for proof of concept, development, or production. After initialization of the primary AKM server you can create additional certificates and private keys for client/server connections if needed. Additional encryption keys can be created and managed using the AKM Administrative Console.

Alliance Key Manager can also be deployed as a Hardware Security Module (HSM), hosted HSM, or VMware instance, and you can create a custom implementation across platforms to integrate with your existing applications or for high availability mirroring.

Who is this for?

This guide is intended to help Project Managers, Crypto Officers, System Administrators, and Application Developers deploy and use AKM for AWS. It covers deploying AKM for AWS, setting up AKM, starting to use AKM, creating and managing encryption keys, creating additional client and admin (Crypto Officer) certificates, managing the AKM server, obtaining a permanent license, and support.

Client applications and SDKs

Townsend Security provides the following applications and SDKs to assist with client-side key retrieval or remote encryption:

Other resources

Typical customer deployments

Redundant AKM key servers for high availability Most AWS customers deploy a production key server and a failover key server located in a different AWS region. AKM mirrors encryption keys and access policies in real time between the primary and secondary key servers. Special bundle pricing is available for Production/HA key server configurations.

On-premise key management Some AWS customer want to maintain full control over the management and protection of their encryption keys. AKM can be deployed as an on-premise VMware software appliance or as a hardware security module (HSM). On-premise deployments of AKM fully support primary and secondary key servers for high availability support for AWS cloud applications.

Cross cloud key management Some AWS customers want to implement key management outside of the AWS cloud, but do not have the on-premise infrastructure to support AKM key management deployments. AWS customers can deploy AKM in a different cloud platform to serve applications running in AWS. Likewise, AKM can be deployed in AWS to server application security requirements in other cloud platforms.

Bring Your Own Key (BYOK) Many AWS services support the option to bring your own encryption key. However, AWS customers may lack good encryption key management facilities to generate and protect strong encryption keys. AWS customers can deploy AKM as a compliant key management facility and use keys for AWS services that support BYOK.

Architecture diagram

The following diagrams show the overall architecture of the AKM for AWS solution:

Resources that get installed on the AMI

The AKM Amazon Machine Image (AMI) contains the Linux operating system, the AKM encryption key management application, AKM configuration files, AKM audit and log files, and helper applications. In addition, AKM in the AWS cloud includes the requirement AWS APIs to support AWS resource management, billing, and other AWS functions. In certain circumstances you can install third party monitoring applications in the AKM instance. Please contact Townsend Security for more information.

Client applications and SDKs

Townsend Security provides the following applications and SDKs to assist with client-side key retrieval or remote encryption with AKM for AWS. In addition to the applications and SDKs there is additional document and sample code that can help developers implement AKM services quickly.

SQL Server UDF for all editions of SQL Server. Implementation of the AKM Windows .NET UDF software allows for the deployment of SQL Server stored procedures and triggers for data protection.

Key Connection for Drupal. The AKM Key Connection for Drupal software provides an easy configuration and deployment option for Drupal developers who want to leverage the Drupal Key and Encrypt modules to protect information in a Drupal web application.

Key Connection for Encryptionizer. Through a partnership with NetLib Security, Microsoft SQL Server Express and Web Edition customers can deploy file/folder encryption to protect information. More information can be found here:

Windows SDK for .NET applications. Windows .NET developers can use the AKM Windows .NET SDK to add encryption key management and encryption services to their Windows and Web applications.

Encryption solutions for Linux. AKM provides an extensive set of language SDKs and sample code to help Linux developers implement encryption in their applications. Languages supported include Java, Python, PHP, Perl, C and others.

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:

IMPORTANT: For AKM to activate the license, your AWS instance must have a route to the internet. If licensing fails, contact Townsend Security or your software vendor to manually license AKM. Then, see the section Install a new license in Chapter 10 for instructions on manually installing the license.

Once you have initialized the primary AKM server and set the password, you can log in to the web interface and download the certificates and private keys needed for client/server connections.

If you set up a secondary mirror server, you should download certificates and private keys after setting up mirroring.

SECURITY ALERT: Since the certificates and encryption keys are dynamically generated upon initialization, no one except you has access to these components.

See below for more information.

Licensing

AKM for AWS supports two licensing models: BYOL (Bring Your Own License) and fee-based. With a BYOL model, a 30-day license is generated automatically on initialization of AKM, and you will need to contact Townsend Security to purchase a permanent license. If you choose a fee-based licensing model, AKM will generate a permanent license, but your use of the license will be determined by Amazon. You can evaluation AKM for free for 30 days, after which you will be charged by Amazon Web Services for the then-current hourly or monthly license fee for AKM. See Chapter 10: Obtain a Permanent License for information on migrating from a temporary to a permanent license.

Certificates

The following certificates are created automatically on initialization and stored on the AKM server:

Authentication Key (Auth Key) and Key Encryption Key (KEK) certificates and private keys: The KEK and Auth certificate and private key pairs are used by AKM to create the Key Encryption Key (KEK) and Authentication Key (Auth Key), two symmetric keys that are stored on the AKM server. These “secret keys” are used by AKM to protect your data encryption keys. You will not need to use or distribute the KEK and Auth certificates and private keys.

Server certificate and private key: These are used by AKM servers to authenticate with each other for mirroring, and to authenticate with client applications.

Certificate authority (CA) certificate: This is a unique CA certificate that is used to sign admin and key client certificates. Admin and key clients usually install the CA certificate along with a client certificate to authenticate with the AKM server. The CA certificate will also be used to sign additional admin (Crypto Officer) and client certificates if needed. See Chapter 8: Create Additional Admin and Client Certificates for more information.

Admin certificates and private keys: Admin certificates and private keys allow for authentication between admin clients and the AKM server, and are used by crypto officers for key creation and management in the AKM Administrative Console. Two admin certificates are created by default to support dual control. See the AKM Administrative Console Guide for information on key creation, key management, and enabling dual control.

Client certificate and private key: Client certificates and private keys allow for authentication between key clients and the AKM server when retrieving keys or sending sensitive data to the AKM server for remote encryption. One client certificate/private key is created by default and additional client certificates and private keys can be created at any time.

After deploying AKM for AWS, you can immediately download and distribute certificates and private keys to Crypto Officers and client application developers for client configuration. After you initialize the primary AKM server, you will be presented with the option to create additional admin and client certificates and private keys if needed. See Chapter 8: Create Additional Admin and Client Certificates for more information.

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 all client certificates in that chain of trust. See the AKM HSM Quick Start Guide for more information.

Chapter 3: Before You Begin

If deploying to production, see below for important information on software updates

See below for more information.

Pre-requisites

Alliance Key Manager runs as a stand-alone AWS EC2 instance. It is self-contained and requires no additional software from Townsend Security, third party software providers, or Amazon Web Services. Your applications integrate with AKM through Software Development Kits (SDKs) provided by Townsend Security, purpose-built applications such as the Townsend Security SQL Server support for Transparent Data Encryption (TDE) and the Drupal encryption and key management module, and support for the Key Management Interoperability Protocol (KMIP).

Sizing the EC2 instance

Allaince Key Manager is a light-weight service that includes the Linux operating system, the encryption and key management services, and supporting applications. For a minimal implementation it is recommended that you deploy in a “small” or larger EC2 instance. The “micro” EC2 instance is not suitable for an AKM deployment.

If you application will use a large number of encryption keys, or will service a largement of key retrieval or encryption/decryption services you should consider a larger EC2 instance size.

Software updates

Your subscription to AKM for AWS includes the ability to receive software patches and updates. 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.

Amazon Web Services will NOT notify you of the availability of new software features, applications or non-essential patches. In the event of an important security update, Townsend Security will work with AWS to notify you through the email address provided with your AWS account. It is strongly recommended that you register with Townsend Security to receive other important product information.

Migrating to new versions

For current Townsend Security customers migrating to a new AKM server from an older version of AKM, see the section on migration in this guide for instructions. Open a support ticket with Townsend Security for assistance.

Chapter 4: Launch AKM for AWS

First you will launch the AKM AMI from the Amazon Marketplace. During the launch process you will configure regions, availability zones, and other options specific to AWS. See below for more information.

Locate AKM for AWS in the Amazon Marketplace

AKM for AWS is available as a BYOL (bring your own license) on the Amazon Marketplace:

Note that the screenshots displayed refer to the BYOL listing, but instructions for the fee-based option will be similar.

Click Continue.

The following page is displayed:

1-Click Launch

If you would like to perform a 1-Click Launch, select the configuration options you want to use in the left panel. The exact configuration options will be particular to your application needs, but be sure to select at least a size of m1.small for EC2 Instance Type. If you are deploying more than one AKM server for real-time key mirroring, high availability, or failover support, we recommend that you deploy your AKM instances in separate regions.

For more information on configuration options or to perform a Manual Launch, see the (Manual Launch) section below.

Select licensing options in the right panel. Click Accept Terms & Launch with 1-Click. The following dialog is displayed:

The AKM AMI has been added to your Software Subscriptions.

Manual Launch

From the launch page, select Manual Launch:

In the Launching Options pane, select a region in which to launch the AKM AMI by clicking the Launch with EC2 Console button next to your desired region. If you are deploying more than one AKM server for real-time key mirroring, high availability, or failover support, we recommend that you deploy your AKM instances in separate regions.

Regions, Availability Zones, and Virtual Private Cloud

Regions and Availability Zones in AWS are used to provide high availability failover support. Amazon describes regions and Availability Zones as follows:

Amazon EC2 is hosted in multiple locations world-wide. These locations are composed of regions and Availability Zones. Each region is a separate geographic area. Each region has multiple, isolated locations known as Availability Zones. Amazon EC2 provides you the ability to place resources, such as instances, and data in multiple locations. Resources aren’t replicated across regions unless you do so specifically.

Amazon operates state-of-the-art, highly-available data centers. Although rare, failures can occur that affect the availability of instances that are in the same location. If you host all your instances in a single location that is affected by such a failure, none of your instances would be available.

Amazon further states:

When you launch an instance, you can select an Availability Zone or let us choose one for you. If you distribute your instances across multiple Availability Zones and one instance fails, you can design your application so that an instance in another Availability Zone can handle requests.

We recommend that you deploy your AKM instances in separate Availability Zones to maintain high availability.

See the link above and the following website for more information about deploying in EC2-VPC (Virtual Private Cloud):

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html

Click Next: Add Storage. The following page is displayed:

Use the default storage options. Click Next: Tag Instance.

The following page is displayed:

While not necessary, setting a tag will help you identify the instance, if you have more than one VM running in AWS. Click Next: Configure Security Group.

The following page is displayed:

Configure your Security Group. See below for more information.

Security Group

AKM uses the following ports:

22 for SSH

3886 for the web administrative interface

5696 for key requests formatted in KMIP

6000 for key retrieval requests formatted in AKM’s protocol

6001 for key management commands formatted in AKM’s protocol

6002 for mirroring between AKMs

6003 for AKM’s encryption service

Best practice dictates that you use the most restrictive security group that your application allows. We recommend that you open only those ports for which you need external access. For port 3886, we recommend closing the port until you need to access AKM’s web administrative interface. After initializing AKM through the SSH menu, we recommend that you close port 22 unless you need to access the Certificate Manager again.

IMPORTANT: To configure mirroring between a primary AKM server and a secondary server, the security group of the primary AKM server must allow connections from the secondary server on port 22, and the security group of the secondary server must allow connections from the primary on port 6002.

Click Review and Launch.

The following page is displayed:

Review your instance launch details and click Launch.

Select or create a key pair

The following dialog is displayed:

Select Create a new key pair, give the key pair a name, and click Launch Instances. You will be prompted to save the newly created key to your workstation. If you prefer to use an existing key, select Choose an existing key pair and select the key pair you would like to use. Click Launch Instances.

The private key you select or create here will be used when connecting to the AKM server via SSH.

Note the IP address or hostname

The AKM IP address or hostname is displayed on the AWS dashboard. Take note of this value as it will be used to connect to the AKM server via SSH.

Chapter 5: Set up AKM for AWS

Setting up AKM for AWS includes the following steps:

Initializing the primary AKM server

Providing a name for the AKM server

Creating an initial set of encryption keys (optional)

Setting the admin password for each AKM server

Initializing the secondary AKM server (optional)

Creating additional admin and client certificates (optional)

Exiting to a shell (optional)

Disconnecting from AKM

These steps are completed through a text interface Administrative Menu.

Overview

First, you will initialize the primary AKM server and set the admin password. The initialization process sets up the AKM server, creates a unique CA certificate for use with AKM, creates all certificate and private key pairs needed for server/client communication, and activates the license. You will also have the option to create an initial set of encryption keys to use during testing or production.

After initializing the primary AKM server and setting the admin password, you can set up a secondary AKM server if needed. A secondary AKM server can be used for real-time key mirroring, high availability, or failover support. To set up a secondary AKM server, you will have to disconnect from the primary AKM server and reconnect using the IP address or hostname of the secondary AKM server.

After you initialize the primary AKM server, you will have the option to create additional admin and key client certificate and private key pairs via the Certificate Manager option on the text interface Administrative Menu if needed.

Other administrative options include exiting to a shell and disconnecting from AKM. You can exit to a shell if you need direct access to the OS for control over Linux options and facilities. You should disconnect from AKM when you are finished with the session.

Initialize the primary AKM server

Open an SSH connection to the primary AKM server using the private key you specified during the launch of your AKM virtual machine and the AKM IP address or hostname (which you can find on the AWS dashboard). For example:

SECURITY ALERT: For Linux users, be aware that user permissions on the private key file must be read and write only. If the private key file has different permissions you may be presented with the following error:

@@@ WARNING: UNPROTECTED PRIVATE KEY FILE! @@@
Permissions 0644 for ‘privatekey.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

To modify the private key file for the correct user permissions, execute the following command:

chmod 600 privatekey.pem

Indicate that you have read and accept the AKM End User License Agreement (available [here])(http://townsendsecurity.com/downloads/misc/TS-EULA.pdf) to continue with initialization:

Enter option 1 to Initialize as PRIMARY. This will designate this server as your primary AKM server and start the initialization process.

NOTE: In the context of mirroring, a primary AKM server either operates alone or sends mirrored keys and metadata to any number of mirror servers. You must initialize a primary server first and can then initialize any additional mirror servers. A server initialized as a primary can also receive mirrored keys in a bidirectional mirroring configuration.

You will be prompted to enter the two-character country code, the name of your state or province, your city/locale, and your organization name (for example, your company name), and a unique name for this AKM server:

Create an initial set of encryption keys

You will be prompted to create an initial set of encryption keys:

Enter y if you would like to create an initial set of encryption keys. You can use these encryption keys for proof of concept, development, or production. Enter N if you do not want to create encryption keys at this time. You can also create encryption keys at any time using the AKM Administrative Console. See Chapter 6: Create and Manage Encryption Keys for more information.

NOTE: Creating encryption keys at this point is optional and does not affect the operation of AKM. However, it may be convenient to have keys available for development or proof of concept without having to use the AKM Administrative Console to manually create encryption keys.

AKM will now initialize. Make sure you do not interrupt this process. The following screen is displayed:

The primary AKM server has now initialized and AKM is running. The server time has been synchronized with a time server (time.nist.gov).

The initialization process has created a unique certificate authority (CA) certificate and server certificate for AKM, activated the license, and generated client certificate and private key pairs needed for key clients and admin clients to connect to the AKM server.

By default, one client certificate and two admin certificates are created by the initialization process. Two admin certificates are created in order to support dual control of encryption key administration. You can create additional client or admin certificates at a later time.

IMPORTANT: The CA certificate created during this process is unique and should only be used with AKM, and you do not need to create an additional CA certificate for use with AKM.

Press any key to return to the main menu. After initialization, the following menu is displayed:

Set the admin password

After initialization you should change the password for the server. This password will be used to access the Administrative Menu on all future sessions and to log in to the AKM server via the web interface.

From the Administrative Menu, enter option 6 for Manage SSH Authentication. this will display another set of options including Set admin password. Take this option:

When prompted to enter a “New Password”, enter your new admin password. This is the password you will use when logging in to the AKM web interface as the “admin” user for server management. Set a strong, safe password and protect it carefully, as the compromise of this password breaches the security of AKM.

IMPORTANT: Do not lose this password, as there are no backdoors to recover it. If you lose the password please do not contact your software vendor to recover it for you, as this is not possible.

When prompted, reenter the password. The password has been changed. You can now log in to the primary AKM server as the “admin” user with the password you created above. See the AKM Server Management Guide for information on server management functions, including backup/restore, logging, and firewall configuration.

Initialize a secondary mirror server

After initializing the primary AKM server, you can set up additional mirror AKM servers for real-time key mirroring and high availability failover support.

See Chapter 4: Launch AKM for AWS for information on Regions and Availability Zones in AWS. Setting up the secondary server at this point is optional and can be completed at a later time.

Setting up mirror servers at this point is optional and can be completed at a later time.

NOTE: If there is a firewall in place between the primary AKM server and any mirror servers, be sure that ports 22 and 6002 are open before setting up mirroring.

IMPORTANT: For mirroring setup to be successful, the security group of the primary AKM server will need to allow connections from the secondary server on port 22, and the security group of the secondary server will need to allow connections from the primary on port 6002.

SSH key pairing options

During mirroring setup, you will be prompted to establish authentication between the two servers using an SSH key. You can accomplish this in one of three ways: by copying the primary AKM server’s public SSH key and pasting it into the menu of the secondary AKM server, by downloading the public SSH key from the primary and uploading it to the secondary, or by using an already established SSH key.

1: Paste the SSH public key

This is the most common option to exchange an SSH key between a secondary and primary AKM server.

Open the Administration Menu on the primary AKM server and select option 2) Mirroring after initializing the server. The Mirror Configuration Menu is displayed:

Select 1) Add mirror. Copy and save the SSH public key displayed on the screen.

Open an SSH connection to the secondary AKM server using the IP address or hostname of the secondary AKM server. For example:

ssh -i ~/.ssh/privatekey.pem admin@secondaryakmhostname

Enter user “admin” and default password “OOHXPq6r530N6re”, or the current password. The Administrative Menu is displayed.

SECURITY ALERT: It is recommended to change the admin password for the mirror server at this time if you have not done so already.

Enter the IP address of the secondary mirror server to complete mirroring setup. Verify the fingerprint of the mirror server and enter yes to continue. Wait for mirroring setup to complete. Do not interrupt this process.

2: Upload the public SSH key to the server

Instead of copying and pasting the SSH public key, you may download the SSH public key from the primary AKM server, then upload it to the secondary mirror AKM server.

Open the Administration Menu on the primary AKM server and select option 2) Mirroring after initializing the server. The Mirror Configuration Menu is displayed:

Select 1) Add mirror.

Open an SSH connection to the secondary AKM server using the IP address or hostname of the secondary AKM server. For example:

Enter the locality information and unique name for this server, then wait for the server to initialize.

Return to the main menu. Selection the option for Mirroring and then select the option to Accept mirrored keys. You will see three options for establishing authentication using an SSH key:

Select option 3 from the SSH menu of the secondary AKM server:

You should see the name of the primary AKM server under the list of public keys that are already trusted. If not, establish trust using one of the previous authentication options.

Enter y to confirm that you want the secondary AKM server to receive keys from this server. Wait for mirroring setup to complete.

Once mirroring setup is complete, press any key to return to the main menu.

Disable automatic rollover on the secondary AKM (IMPORTANT)

The automatic rollover attribute must be disabled on any secondary mirror servers. That way, keys with the automatic rollover attribute are only rolled on the primary server, and the new keys then mirrored to the secondary server. You would not want the mirrored keys on the secondary server (which are mirrored with the same automatic rollover attribute) to roll once again on the secondary, independent of and without the knowledge of the primary server.

Log in to the secondary mirror server via the web interface and select File Manager from the left navigation menu. Navigate to the /etc/akm directory and select akm.conf, then click the Edit button in the Action column.

Locate the [AutomaticRollover] section and set Enabled to N. Click the Save and Close button. Stop and restart AKM via the Custom Commands link.

Next steps

After setting up mirroring, bundled CA certificate files are created which contain the CA certificates of both AKM servers. These must be installed on any client connecting to AKM along with the client certificate and private key.

If you have previously set up clients before setting up mirroring, the CA certificates installed on the client must be replaced with the CA certificate bundle. See the section Set up admin and key clients for more information. The client certificate and private key files do not need to be replaced.

Certificate Manager

After initialization, you will be presented with the option to Start Certificate Manager when you return to the Administrative Menu. On initialization, AKM generated one client certificate and private key pair for a client application to authenticate with the AKM server to perform key retrieval or remote encryption. Two admin certificate and key pairs were created for Crypto Officers to manage encryption keys on the AKM server. You only need to run the Certificate Manager if you need to create additional admin or client certificates or sign a CSR. See Chapter 8: Create Additional Admin and Client Certificates for more information.

IMPORTANT: Initialization of the primary AKM server creates a unique CA certificate which is used to sign all client certificates. This CA certificate should only be used with AKM, and you do not need to create an additional CA certificate for use with AKM. By default, one client certificate and two admin certificates are created by the initialization process. Two admin certificates are created in order to support dual control of encryption key administration.

Other administrative options

This section describes other Administrative Menu options.

Migrate (Initialize from backup)

Current Townsend Security customers can migrate the key database and authentication certificates from an earlier version of AKM to a new AKM.

Start a support ticket on the Townsend Security website for assistance with the migration, including information about transferring your permanent license to your new AKM. Follow the steps below to migrate the key database and authentication certificates.

Log in to the web interface of the server you wish to migrate from and run both an application and a secret key backup, selecting a local folder on AKM as the destination. For more information on running a backup, see the AKM Server Management Guide.

Navigate to the directory in File Manager where you saved the backups, and double click to download both files.

Launch the new AKM VM, then log in to that AKM server via the web interface. Use the File Manager to upload both files to the /home/admin/uploads directory.

Launch the Administrative Menu on the new AKM VM and select the option to Initialize AKM. Select the option to Migrate (Initialize from BACKUP). Press Enter.

Wait until the migration is successful and AKM has started. Do not interrupt this process.

This initialization option does not include the creation of new client and admin certificates. Use the Start Certificate Manager option in the main menu if new certificates are needed. See the next chapter for information on downloading these certificates.

Client certificates already in use in client applications will still be valid to connect to AKM. However, if the new AKM has a different IP address than the previous AKM, this will need to be updated in the client application configuration.

Start/Stop AKM

After initializing the server, the main Administrative Menu will include the option to Stop AKM. This stops key services and prevents all clients from connecting to AKM. When AKM is stopped, you can select the option to Start AKM to restart key services.

Disable Webmin

You will use the web interface to download key and admin client certificates and private keys in the next chapter. However, it is recommended to disable the web interface to the AKM server when not in use. From the Administrative Menu, select the option to Disable Webmin. Follow the prompts to disable the web interface.

Support

Collect logs for troubleshooting

For problem determination, you can view logs. From the Administrative Menu, select the Support option to Collect logs for troubleshooting. See Chapter 10: Support for more information.

Print System Info

Selecting this option will display system version information.

Fix akm.conf

This option will appear if there is a conflict between the IP address assigned to the AKM server and what is listed in the AKM configuration file (akm.conf). Selecting this option will resolve the conflict by resetting all IP addresses to default (0.0.0.0). This will remove any manual changes you have made to the AKM configuration file IP addresses.

Exit to shell

You can exit to a shell if you need direct access to the OS for control over Linux options and facilities.

Disconnect from AKM

You should disconnect from AKM when you are finished with the session.

Next steps

You can now log in to the AKM server and download admin and client certificate and key pairs for distribution to admin and key clients. See Chapter 6: Start Using AKM for AWS for more information.

Chapter 6: Start Using AKM for AWS

To get started using AKM, you will first need to log in to the AKM server web interface. You will check that AKM is running, then download the certificates and private keys needed for client applications to perform key retrieval or encryption and decryption on the AKM server.

Log in to the web interface

Open a web browser and connect to the AKM virtual machine via a secure HTTPS connection. You will use the IP address or DNS name of the primary AKM server and the port number for the web interface (3886). Your web browser address might look something like the following:

https://ec2-54-184-129-209.us-west-2.compute.amazonaws.com:3886

NOTE: AKM generates a private SSL certificate during initialization, so you will likely be presented with a browser security warning. Choose the option to proceed.

The login page is displayed:

Enter the default username “admin” and the password you set during initialization. Click Login.

The following status information is displayed:

The navigation options are available on the left side of the status page:

The navigation pane contains different options for managing the AKM server, including backup/restore, mirroring and logging. See the AKM Server Management Guide for information on these tasks.

To verify that AKM is running, click on the link for Running Processes in the navigation pane. Click Search in the Display menu at the top of the page. Select Matching, enter “akmd”, and click Search. If AKM is running, you will see it listed as a running process:

If AKM is not running, click on the link for Custom Commands in the navigation pane. Click on the Start AKM button to start the AKM process and click Return to commands. Check the Running Processes tab again for the the “akmd” process.

If the “akmd” process is still not running, navigate back to Custom Commands and click on the Display AKM Error Log Snippet button. This will display a list of recent errors to help with problem determination. Contact Townsend Security or your software vendor if you need assistance.

IMPORTANT: If you are deploying AKM for AWS in a production environment, you may need to install software patches. Contact Townsend Security or your software vendor to find out if there are any necessary software patches, and if so, install them now.

Set up admin and key clients

Setting up clients for key retrieval or remote encryption includes downloading and distributing client certificates and giving the name of an encryption key to your client application developer.

For key management in the AKM Administrative Console, you will download admin certificates and private keys.

SECURITY ALERT: The private key files associated with admin and key client certificates must be protected during creation, distribution, and storage. The loss of these files will compromise the security of any encryption keys this client has access to. Depending on the file format, the private key files may be bundled with a certificate or they may be separate files. Transfer these 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 certificates 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 HSM Quick Start Guide for more information.

In the web interface for the primary AKM server, click on the link for _ File Manager_ in the navigation pane. File Manager is used for managing files on the AKM server.

Download key client certificates

Key client certificates are used in client applications for key retrieval or remote encryption and decryption on the AKM server.

Your client application developer will need AKM’s CA certificate or a CA certificate bundle (when implementing mirroring), a client certificate/private key pair, and any associated passwords to set up client applications for key retrieval or remote encryption on the AKM server.

The format of the certificate files your client application developer will need depends on the platform and language of the client application environment.

NOTE: If you do not need to control access to keys, you can use the same client certificate/private key in each client application. If you need to control access to keys, each client application will need a unique client certificate/private key. See Chapter 8: Create Additional Admin and Client Certificates for information on creating additional client certificates.

Certificates to use prior to setting up mirroring

In File Manager, navigate to the /home/admin/downloads/ directory.

Client certificates are located in <AKMServerName>_user.zip. Select <AKMServerName>_user.zip and double click to save. Unzip this archive.

The following certificates and private keys can be used to set up key clients before mirroring setup:

<PrimaryAKMServerName>.AKMServerCertificate.pem (the primary AKM’s server certificate, used for “certificate pinning”)

Certificates to use after setting up mirroring

After mirroring setup, you will need to use a bundle containing the CA certificates of both AKM servers along with the client certificate and private key.

Log in to the web interface and redownload <AKMServerName>_user.zip to gain access to the new mirroring configuration certificates used in client applications after a mirroring pair has been established.

If you have previously set up clients before setting up mirroring, the CA certificates installed on the client must be replaced with this new CA certificate bundle (.pem or .jks) for seamless client failover when AKM is unreachable. The client certificate and private key files do not need to be replaced.

NOTE: When setting up clients in a Windows environment, Windows Certificate Store will not import all of the CA certificates in the bundle. In this case, the primary and secondary mirror CA certificates must be imported individually.

In File Manager, navigate to the /home/admin/downloads/ directory. Client certificates are located in <AKMServerName>_user.zip. Select <AKMServerName>_user.zip and double click to save. Unzip this archive.

The following certificates and private keys can be used to set up key clients after mirroring:

Download Crypto Officer certificates

Crypto Officer certificates are used to connect to AKM for key management operations.

Your Crypto Officer will need the AKM CA certificate truststore or truststore bundle (when implementing mirroring), and an admin client certificate/private key keystore in .jks format, as well as any associated passwords, to use the AKM Administrative Console to create and manage encryption keys.

.pem files can be used for admin clients under program control if needed. See the AKM Admin API Reference for more information on using admin commands under program control.

Certificates to use prior to setting up mirroring

In File Manager, navigate to the /home/admin/downloads/ directory. Crypto Officer certificates are located in <AKMServerName>_admin1_<date>.zip and <AKMServerName>_admin2_<date>.zip in the /home/admin/downloads/ directory on the primary AKM server.

Two unique sets of admin certificates are provided if you want to implement PCI requirements around dual control of key management operations.

The following files can be used to set up admin clients before mirroring setup:

/PEM

AKMAdminCertificate.pem (admin certificate)

AKMAdminPrivateKey.pem (admin private key)

AKMRootCACertificate.pem (AKM’s CA certificate)

/Admin_Console

AKMAdminKeystore.jks (admin keystore)

AKMAdminKeystorePassword.txt (admin keystore password)

AKMRootCATruststore.jks (admin truststore with AKM’s CA certificate)

AKMRootCATruststorePassword.txt (admin truststore password)

Certificates to use after setting up mirroring

After mirroring setup, you will need to use a truststore bundle containing the CA certificates of both AKM servers, along with the keystore file.

Log in to the web interface and redownload <AKMServerName>_admin1_<date>.zip and <AKMServerName>_admin2_<date>.zip (if implementing dual control) to gain access to the new mirroring configuration certificates used in the admin application after a mirroring pair has been established.

If you have previously set up the admin client before setting up mirroring, the CA certificates installed on the client must be replaced with the new CA certificate bundle (.pem or .jks) for seamless client failover when AKM is unreachable. The client certificate and private key (.pem or .jks) do not need to be replaced.

NOTE: If setting up an admin client under program control in a Windows environment with .pem files, Windows Certificate Store will not import all of the CA certificates in the bundle. In this case, the primary and secondary mirror CA certificates must be imported individually.

The following files can be used to set up admin clients after mirroring:

Give the name of the appropriate encryption key to your client application developer.

SECURITY ALERT: 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 which you entered earlier. See Chapter 7: Create and Manage Encryption Keys for more information.

Chapter 7: Create and Manage Encryption Keys

If you created a set of encryption keys during initialization of the primary AKM server, you can use one of these encryption keys. If you would like to manage these encryption keys (for example, to change the access policy) or create new encryption keys, you can do so using the AKM Administrative Console.

AKM Administrative Console

The AKM Administrative Console is a Windows application with a GUI interface for one or more Crypto Officers to create and manage encryption keys. See the AKM Administrative Console Guide for detailed instructions on installing and using the AKM Administrative Console.

To set up the Admin Console, you will need the AKM CA certificate truststore or truststore bundle and an admin client certificate/private key in .jks format and passwords for these files.

If you are using the Admin Console after setting up mirroring, you will need to use the CA certificate truststore bundle which contains the CA certificates of both AKM servers (AKMTruststoreBundle.jks) and the associated password.

IMPORTANT: By default, two sets of admin certificates and private keys are generated for two Crypto Officers in order to support dual control (<AKMServerName>_admin1_<date>.zip and <AKMServerName>_admin2_<date>.zip). To authorize a second Crypto Officer to use the Admin Console, you will need to follow the same steps using the <AKMServerName>_admin2_,date>.zip file. See the AKM Administrative Console Guide for information on implementing dual control.

When opening the AKM Administrative Console for the first time, the following dialog is displayed:

This dialog allows you to define the AKM server to which you want to connect using the AKM Administrative Console.

Server Name: Enter a name of your choosing for this key server.

Server Address: Enter the IP address or host name of this key server (example: ec2-54-189-40-74.us-west-2.compute.amazonaws.com).

Server Port: Enter the admin port number (the default is 6001).

Key Store File: Click Browse and select AKMAdminKeystore.jks.

Passphrase: Enter the password contained in the AKMAdminKeystorePassword.txt file.

Trust Store File: Click Browse and select AKMRootCATruststore.jks (or AKMTruststoreBundle.jks if you have already set up mirroring).

Passphrase: Enter the password contained in the AKMRootCATruststorePassword.txt file (or AKMTruststoreBundlePassword.txt if you have already set up mirroring).

Verify the connection to AKM server

In the AKM Administrative Console you will see a list of options in the left pane. Expand the option for Status and select the link for Administrative NoOp. Click Submit. You should see the following output in the right pane:

If you receive an error message contact Townsend Security Support for assistance.

You are now ready to use the AKM Administrative Console to create and manage encryption keys.

Create a new encryption key

To create a new encryption key, expand the option for Manage Keys in the left pane and select the Create Symmetric Key command. Next you will define attributes for the encryption key in the middle pane. First give your key a user-friendly name and a key size. For evaluation purposes check the box next to Activate key immediately and Key never expires, and select the option for Anyone to access the key. For production encryption keys, the expiration date of the key should be determined by your organization’s policy on cryptoperiods, and you should use a restricted access policy. Define additional options for the key and scroll down to click the Submit button to create the key. You should receive the following output:

You will now be able to use this encryption key in your client application.

Set key access policy on an encryption key

To modify the key access policy on an existing encryption key, expand the option for Manage Key Attributes in the left pane and select the Set Key Access Flag command. Enter the key name and select the desired key access policy. See the AKM User Guide for more information on key access control.

If you need to create additional key client certificates, admin certificates, or import certificate signing requests, you can do so using the AKM Certificate Menu.

After initializing the primary AKM server, reconnect to the primary AKM server via SSH. After initialization of the primary server has been completed, the Administrative Menu displays the following options:

Enter option 1 to Start Certificate Manager.

The Certificate Menu is displayed:

Create an admin certificate

Enter option 1 to Create an admin client certificate and key pair. This will create an additional admin certificate and private key for a Crypto Officer to manage encryption keys. You will be prompted to enter a unique Common Name (CN) for this admin certificate. The Common Name must be a valid host name:

The admin certificate files have been created and are available in the /home/admin/downloads/ directory on the AKM server.

IMPORTANT: Note the validity date of the certificate. You will not be able to use this certificate after that date. This may impact your access to the key manager and may impact production applications.

Create a key client certificate

From the Certificate Menu, enter option 2 to Create a key client certificate and key pair. This will create an additional client certificate and private key for key clients to perform key retrieval or encryption and decryption on the AKM server. You will be prompted to enter a unique Common Name (CN) and Organizational Unit (OU) for this key client certificate:

The key client certificate files have been created and are available in the /home/admin/downloads/ directory on the AKM server.

IMPORTANT: Note the validity date of the certificate. You will not be able to use this certificate after that date. This may impact your access to the key manager and may impact production applications.

SECURITY ALERT: If you are using an encryption key created on initialization of the primary AKM server and you want to use key access control, you will need to modify the key access policy of the encryption key and enter User and Group information that matches the Common Name (CN) and Organizational Unit (OU) of the key client certificate. See Chapter 7: Create and Manage Encryption Keys for more information.

Import and sign certificate signing requests

If you are on the IBM i platform, you will need to import a certificate signing request (CSR) to be signed by AKM’s CA certificate to create a signed key client certificate. For information on creating a certificate signing request, see the document AKM DCM Configuration for IBM i.

From the Certificate Menu, enter option 3 to Import and sign certificate signing requests. The following screen is displayed:

Log in to the AKM web interface as the “admin” user with the password you created above. Click on the link for _ File Manager_ in the left navigation pane. Upload the CSRs to the /home/admin/uploads/ directory. You can upload multiple CSRs. After uploading the CSRs, return to the Certificate Menu and press Enter. The following screen is displayed:

AKM will detect the Common Name (CN) of each CSR and use it to name the client certificate files. The signed client certificate files are available in the /home/admin/downloads/ directory on the AKM server.

Chapter 9: Manage the AKM Server

Server management

Backup and restore, system logging, and firewalls can be configured via the web interface. See the AKM Server Management Guide for information on these tasks. See the AKM User Guide for more detail on these concepts.

IMPORTANT: You should perform a backup of the AKM server as soon as you have finished setting up AKM for AWS, and periodically after any significant changes to keys, user access policies, and certificates.

Routine maintenance

Alliance Key Manager is designed to be highly available to applications that need encryption and key management services. There is no requirement to perform periodic software maintenance or log management functions. By default AKM rotates and deletes logs under its control.

Software updates

Each time you log into the Webmin UI, you will see new package updates available on the dashboard.

When you click on the package updates section you will be taken to a list of the available updates. You should see something similar to the image below.

You can apply all available updates by selecting the select all option. Once you have made your selection you can click the button to Update Selected Packages. You can specify to be alerted of new updates via email if you need. This feature can be found by scrolling to the bottom of the list. You will be able to set an interval to check for updates, as well as provide an email and specify any action to be taken.

After clicking Update Selected Packages you will be taken to the screen below to confirm and install the updates. Click on Install Now when you are ready to begin the update.

You will see the output similar to what is shown below. The update process is done when you see install complete at the bottom of the output window.

Your updates will be complete at this point and any future updates can be applied in this manner as well.

NOTE: An alternative method to update your AKM can be completed via the AKM shell. This method requires accss to the AKM shell using SSH, Putty, your VM console, or a dummy console.
Once connected, you can issue the command sudo apt-get update to list the available packages for update. When you are ready to apply the update, you will issue the command sudo apt-get upgrade. The process may take a few moments to finish.

Backup and recovery

AKM fully supports both manual and automated secure backup of the AKM application, key files, configuration, web interface, and other operational components of AKM. For more information about AKM backup and recovery, see the AKM User Guide AKM User Guide

Monitoring AKM

The status of your AKM EC2 instance is visible on the AWS EC2 console. If the EC2 instance has been suspended or stopped, you can view this status on the console. Additionally, AWS EC2 APIs allow you to inspect this status automatically in your AWS applications.

AKM also implements a No Operation (NOOP) health check API that you can use to monitor the application health of AKM. If the application has stopped but the EC2 instances is active, the NOOP command can detect this condition. The AKM API reference describes the NOOP command.

Subject to the conditions of the AKM license agreement, you may also install monitoring applications on the AKM EC2 instance. For example, you can install the Nagios client for monitoring. Other monitoring applications can also be installed.

Lastly, AKM creates an audit log of all key retrieval, encryption, and key management activity. You can use the integrated syslog-ng application to send the audit log to a monitoring facility.

Certificate backup

SECURITY ALERT: Private key files must be protected during creation, distribution, and storage. The loss of these files will compromise the security of the AKM server. Transfer the certificate 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 from loss, including encryption. In the event the client certificates are compromised or lost, you should immediately replace the certificate authority on the AKM server and all client certificates in the chain of trust. See the AKM HSM Quick Start Guide for more information.

Chapter 10: Obtain a Permanent License

Cost model and discounts

Both Bring Your Own License and Fee-based deployments of AKM provide a predictable license cost model for the deployment that does not increase as you increase the AWS EC2 resources that you use. When deploying the Fee-based instance of AKM you will have access to a discount when subscribing on an annual basis. For AWS customers and partners deploying multiple instances of AKM in the AWS cloud, volume discounts are available.

BYOL

If you choose a BYOL licensing model, AKM for AWS is deployed with a 30-day temporary license. Please contact your account manager to receive a permanent license if you wish to continue using AKM for AWS. You will need to provide your Instance ID. This can be found in the AWS dashboard or by running the following command from the command line:

ec2-instance-id

Install a new license

Once you receive the license, you can upload it to the AKM server.

IMPORTANT: The license file must have the name License.txt when it is installed on the server. If you receive a license with a different name, rename the file to License.txt.

Log in to the web interface and expand the navigation pane. Click on the link for File Manager. Navigate to the /var/lib/townsend/akm directory. Select License.txt and click the Delete button.

Now you will need to restart AKM. Click on the link for Custom Commands in the navigation pane, click the Stop AKM button, then click the Start AKM button.

Fee-based

If you choose a fee-based licensing model, AKM will generate a permanent license, but your use of the license will be determined by Amazon. You can evaluate AKM for free for 30 days, after which you will be charged by Amazon Web Services for the then-current hourly or monthly license fee for AKM.

Migrate from a test environment to a production environment

If you have used an AKM instance in a test or development environment, it is recommended to use a new instance of AKM for production. Your new AKM instance will contain unique keys and PKI components 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. It is recommended that you remove all client and admin 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.

SECURITY ALERT: Failure 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.

Chapter 11: Support

There are two levels of technical support available for AKM for AWS customers. The basic level of support comes with your permanent AKM license and includes technical documentation as well as email support, during business hours, Monday through Friday. Contact Townsend Security to purchase premium level support.

Townsend Security customers with a permanent license can collect logs and send them to Townsend Security support for assistance. From the Administrative Menu, select the Support option to _Collect logs for troubleshooting. Then start a support ticket on the Townsend Security website at http://townsendsecurity.com/support/ticket.

Customer support

Your subscription to AKM for AWS entitles you to business hour support Monday through Friday from 7:30am Pacific to 4:00pm Pacific using email. This is the Basic support plan and is included at no extra cost with your AKM for AWS subscription. A paid, annual Premium support plan is available from Townsend Security that provides telephone and web support on a 24/7 basis. You can get more information about the Premium support plan here: http://www.townsendsecurity.com/contact

You can find more information about AKM for AWS customer support and SLA here:

Enter the AKM server IP address. Leave the default port 22. You can save this configuration by entering a name (example: AKM1) in the Saved Sessions field and clicking Save. Click Open.

You will be prompted to log in:

Enter “admin” as the username, and when prompted, the default password “OOHXPq6r530N6re”. If the login is successful, the Administrative Menu will be displayed. Return to Chapter 5: Set up AKM for AWS to continue with initialization.

Appendix B: Set up Bidirectional Mirroring

To set up bidirectional mirroring, first initialize the primary AKM server, then initialize a secondary mirror server as described in the section Initialize a secondary mirror server.

In the secondary server menu, select the option for Mirroring and select 1) Add a mirror. Copy the SSH public key of the secondary server.

In the primary server menu, select Mirroring and select 2) Receive mirrored keys. Paste the SSH public key of the secondary into the menu.

Return to the secondary server’s Mirror Configuration Menu and press Enter to continue.

Enter the IP address of the primary server. Verify the fingerprint of the primary server and enter yes to continue.