Chapter 1: About This Manual

AKM for Microsoft Azure

AKM for Microsoft Azure is deployed as a virtual machine in the Microsoft Azure cloud. AKM for Microsoft Azure 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.

AKM for Microsoft Azure protects data in IaaS and PaaS environments and can be deployed in either a public or private cloud. Alliance Key Manager can also be deployed across platforms as a Hardware Security Module (HSM), hosted HSM, or VMware instance for integration with your existing applications or for high availability mirroring.

AKM supports integration with client applications running as Azure Virtual Machine instances or in Azure Cloud Services. See Appendix B: Create an Azure Service Project in Visual Studio and Appendix C: Configure AKM Certificates for Use with Azure Cloud Services for more information. Please note that Azure App Service Web App is not a supported platform for running the client application.

Who is this for?

This guide is intended to help project managers, crypto officers, system administrators, and application developers deploy and use Alliance Key Manager for Microsoft Azure. It covers deploying AKM for Microsoft Azure, 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:

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

  • Windows SDK for .NET applications

  • SQL Server UDF for all editions of SQL Server

  • Key Connection for Drupal

  • Key Connection for Encryptionizer

In addition to these offerings, Townsend Security provides software libraries and code samples to assist with custom implementations. Please contact Townsend Security for a current list of client applications, software libraries, and code samples.

Other resources

The following documents provide additional information on the installation and use of Alliance Key Manager:

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
3.0.1.001 2/13/2014 Initial release.
3.0.1.002 2/19/2014 Updates.
3.0.1.003 3/4/2014 Updates.
3.0.1.004 3/19/2014 Update information on client certificates. Add information on backing up certificates. Add security note about protecting private keys.
3.0.1.005 8/12/2014 Update chapter on obtaining a permanent license.
3.0.3.001 11/21/2014 Update for AKM 3.0.3 and the text interface Administrative Menu.
3.0.3.002 1/20/2015 Updates.
3.0.3.003 2/18/2015 Updates. Add appendix on connecting to the AKM server using PuTTY.
3.0.3.004 8/26/2015 Add appendix on creating an Azure Service Project in Visual Studio. Add appendix on configuring AKM certificates for use with Azure Cloud Services.
*3.0.3.005 2/26/2016 Update for new Azure Portal.
3.0.3.006 5/24/2016 Remove references to demo apps.
4.0.0.001 7/12/2016 Update for AKM 4.0, including new mirroring setup and migration option. Add appendix on setting up bidirectional mirroring.
4.5.0.001 10/26/2016 Update for asymmetric RSA key support. Update for Azure ARM support.
4.6.0.001 10/19/2018 Added new authentication requirements
4.6.0.002 12/11/2018 Added Software Update section

Chapter 2: Introduction

This chapter briefly describes the deployment process for AKM for Microsoft Azure. Subsequent chapters describe these steps in more detail.

Deploy AKM for Microsoft Azure

Deploying AKM for Microsoft Azure includes the following steps:

  • Creating a virtual machine with the AKM image

  • Configuring the virtual machine (VM) with the needed availability set, endpoints, and other configuration options specific to Microsoft Azure

Set up AKM for Microsoft Azure

Setting up AKM for Microsoft Azure begins with connecting via SSH as the admin user to your primary AKM server. This will launch an Administrative Menu from which you can complete the following tasks:

  • Initialize the primary AKM server

    • Automatically activate the license and create all certificates and private keys needed to set up client/server connections

    • Create an initial set of encryption keys (optional)

  • Set the admin password

  • Initialize a secondary mirror AKM server for real-time key mirroring, high availability, or failover support (optional)

  • Migrate to a new AKM server from a previous version of AKM (optional)

  • Create additional certificates and private keys for client/server connections if needed (optional)

  • Collect logs for troubleshooting and print system if needed

IMPORTANT: For AKM to activate the license, your VM 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

The AKM license generated on initialization provides you with a fully functional AKM server that you can run for 30 days. 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 must install the CA 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 Microsoft Azure, you can immediately download and distribute certificates and private keys to client application developers and crypto officers 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 and all client certificates in that chain of trust. See the AKM HSM Quick Start Guide for more information.

Encryption keys

On initialization, you will be given the option to generate an initial set of encryption keys. You can use these encryption keys in client applications for proof of concept, development, or production. If you need to create additional encryption keys or manage existing keys, you can do so at any time using the AKM Administrative Console.

Chapter 3: Before You Begin

Download the AKM Supplemental

Townsend Security or your software vendor will provide you with a link to download the AKM Supplemental. The AKM Supplemental contains everything you will need to deploy AKM, including related software such as the AKM Administrative Console for creating and managing encryption keys, and applications and SDKs for key retrieval and remote encryption.

Software updates

Townsend Security or your software vendor 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: Make sure to backup your AKM before applying system updates. AKM Backup and Restore Process

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: Deploy AKM for Microsoft Azure

Deploying AKM for Microsoft Azure includes the following steps:

  • Creating a virtual machine (VM) with the AKM image

  • Configuring the virtual machine with the needed availability set, endpoints, and other configuration options specific to Microsoft Azure

Create a Virtual Machine with the AKM image

Log in to the Azure Portal. Click Virtual machines on the left, then click Add:

image alt text

Once you’ve clicked add, you will need to click the text Create VM from Azure Marketplace

image alt text

You can then search for and select “AKM” or “Alliance Key Manager”. Select the image with the support level you purchased (standard or premium), or if this is a secondary high availability / failover server, select “AKM Secondary HA”.

image alt text

Review the description that appears on the right:

image alt text

Create a new resource group (example: “akm”) for the virtual machine or use an existing resource group.

Click Create to continue configuring the image.

Configure the virtual machine

image alt text

Enter a Name for the virtual machine (example: “DemoAKM”).

Select a region for the virtual machine.

If you are using additional secondary mirror (failover) servers, you will now configure an availability set. The Availability Options section will by default show No Infrastructure Redundancy Needed to define an availability set, select Availability set from the dropdown list. This will create a new drop down allowing you to choose between availability sets.

image alt text

If you are currently setting up the primary AKM server, select Create new, enter a name for the availability set, and click OK.

image alt text

If you are currently setting up a secondary mirror server, select an existing availability set.

See the sections on availability sets and mirroring in Microsoft Azure for more information.

Next, Select a pricing tier and size for your VM. It is recommended that you select A2_v2 Standard size (2 CPU, 4GB RAM) for the VM. If you need to increase the size of this VM in the future, you can change it using the configuration options for this VM.

Click Select.

Azure requires a user be defined during setup, but will not be used beyond initial setup. Enter a new username (example: “Cat”). When you log in to AKM for the first time you will log in as the admin user, regardless of what was specified here as username.

Once you have specified a username, you may paste in an SSH public key for authentication.

image alt text

Alternatively, if you select password as your authentication method, you will need to provide and confirm the desired password. When you log in to AKM for the first time you will log in as admin using the password specified here.

image alt text

Click OK.

You will now configure optional features of the virtual machine:

If you click on Next to move onto Disk, you will be able to select your OS disk type. For this example I’ve selected Standard HDD

image alt text

Click Next to move on to Networking

image alt text

Just below the drop down menu for Public IP address, you will see, Create new. You can use this to specify a static IP for the AKM. The name is populated automatically. Select Static.

image alt text

Click OK.

Now you will configure ports needed by AKM.

image alt text

There will be a default populated here, but to configure your own click the Create new text beneath the Network security group (firewall), drop down. Enter a name for this port configuration, for example, “AKMPorts”.

The following endpoints are created by default: port 22 for SSH, port 3886 for the web interface, and port 6001 for key admin (Crypto Officer) connections.

If mirroring to a secondary server, the primary AKM server’s endpoint configuration should include port 22 and the secondary server’s endpoint configuration should include both ports 22 and 6002.

The other endpoints you add will depend on what services you need to be available from outside this cloud service. If your key retrieval or remote encryption client applications are running within the same Azure cloud service as your AKM server, then you will only need to configure the SSH, web interface and key admin ports. If your client applications are running outside of the Azure cloud service you will need to define additional endpoints. See the section on endpoints for more information on AKM endpoints.

To add additional endpoints, select Add an inbound rule. Click OK.

Click Next to continue.

Review the summary:

image alt text

Click Next to continue.

The AKM image will start being created in your storage account:

image alt text

Wait for the image to finish being created.

 

Availability sets

Microsoft’s Service Level Agreement (SLA) guarantees that if two VMs are in an availability set, one or both of the VMs will be available. Each member of the set is run in different server racks, making the set resilient against a power supply or network component failure that may affect one rack. This provides high availability recovery of key management operations. Townsend Security recommends that you use a pair of AKM servers in an availability set to take advantage of this feature. Please refer to the Microsoft SLA for more information (www.windowsazure.com/en-us/support/legal/sla/).

Regions

Using an availability set does not provide geographic redundancy or high availability in the event of data center-wide problems. There is no built-in mechanism in Microsoft Azure to provide geographic redundancy for virtual machines or cloud services. For an application to be geographically redundant, it would have to be duplicated in another data center. Please contact Townsend Security for guidance on the architecture of mirroring key management between data centers.

 

Configuring mirroring in AKM for Microsoft Azure

A virtual machine in a Microsoft Azure cloud service has a public and a private (internal) IP address. Whether you use the public or private IP address depends on your mirroring architecture. See the section on endpoints below for detailed information on configuring endpoints for AKM, including mirroring endpoints.

 

Endpoints

The endpoints you create depend on what services you need to be available from outside of the Microsoft Azure cloud service hosting your AKM server. In the simplest configuration where all AKM servers and client applications are hosted in the same cloud service, you will only need to configure the SSH, web interface and admin ports. These ports allow for connections for initialization via SSH, server management via the web interface, and key management via the AKM Administrative Console.

If you are using services external to one cloud service, for example if your client application is external to the cloud service hosting your AKM servers, you will need to open additional ports.

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 endpoints that your application needs. 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 Administrative Menu again.

See below for information on different configurations.

Two AKM servers and a client application within one cloud service

The simplest configuration involves two AKM servers (a primary which will mirror to a secondary) and a client application, all hosted within the same cloud service. The following example shows the necessary endpoints for this configuration:

Primary AKM server:

Name/Function Public Private
SSH 22 22
Web interface 3886 3886
Admin 6001 6001

Secondary AKM server:

Name/Function Public Private
SSH nnnnn* 22
Web interface 4886 3886
Admin 7001 6001

*Autogenerated

IMPORTANT: When both AKM servers are within the same cloud service, they cannot use the same public ports. For the secondary AKM port configuration, numbers 1000 greater than the public ports of the primary are used for convenience for the public web interface and admin endpoints. The public SSH port for the secondary AKM server will be autogenerated.

Take note of these ports, as you will use the public web interface port when connecting to AKM server via the web interface, and the public admin port when connecting to the AKM server via the AKM Administrative Console for encryption key creation and management.

To view the autogenerated public SSH port of the secondary AKM server after setup, click on the Virtual Machines tab and select Settings to view the endpoints.

Mirroring configuration:

When both AKM servers are within the same cloud service, you do not need to define the mirroring port in the endpoints configuration. When setting up mirroring during initialization of the secondary AKM server, you will specify the private IP address and port number of the primary AKM server. Subsequent chapters describe this step in more detail.

Client application configuration:

Likewise, since the client application is within the same cloud service, you do not need to add the key retrieval and/or remote encryption ports in the endpoints configuration. However, you will supply the private IP addresses of the primary and secondary AKM servers and the private ports for key retrieval (the default is 6000) and/or remote encryption (the default is 6003) in your client application configuration.

Client application external to the cloud service hosting both AKMs

If your client application is external to the cloud service hosting both the primary and secondary AKM server, you will also need to add the key retrieval and/or remote encryption ports to the endpoints configuration:

Primary AKM server:

Name/Function Public Private
SSH 22 22
Web interface 3886 3886
Admin 6001 6001
Key Retrieval 6000 6000
Remote Enc 6003 6003

Secondary AKM server:

Name/Function Public Private
SSH nnnnn* 22
Web interface 4886 3886
Admin 7001 6001
Key Retrieval 7000 6000
Remote Enc 7003 6003

*Autogenerated

IMPORTANT: When both AKM servers are in the same cloud service, they cannot use the same public ports. In this example, a number that is 1000 greater than the public port of the primary AKM server is used for convenience. This allows you to maintain the default private port configuration on your secondary AKM server and provides a simple adjustment for configuring failover in your client applications.

Client application configuration:

You will supply the public IP addresses of the primary and secondary AKM servers and the public ports for key retrieval (in this case, 6000 for the primary and 7000 for the secondary) and/or remote encryption (in this case, 6003 for the primary and 7003 for the secondary) in your client application configuration.

Alternate mirroring configurations

If you are mirroring from one AKM server to an AKM server in a different cloud service, you will also need to add the port for mirroring to the endpoints configuration on both servers:

Primary AKM server

Name/Function Public Private
SSH 22 22
Web interface 3886 3886
Admin 6001 6001
Mirror 6002 6002

Secondary AKM server:

Name/Function Public Private
SSH 22 22
Web interface 3886 3886
Admin 6001 6001
Mirror 6002 6002

Since they are in different cloud services, they can use the same public port numbers.

Mirroring configuration:

When setting up mirroring during initialization of the secondary AKM server, you will specify the public IP address and public port number of the primary AKM server. Subsequent chapters describe this step in more detail.

Client application configuration:

Your client application configuration will depend on where your client application is hosted. For a client application in the same cloud service as an AKM server, you will supply the private IP address and port number. If the client application is in a different cloud service as an AKM server, you will supply the public IP address and port number.

For example, consider a situation where you have your primary AKM server “AKM1” and a client application in one cloud service (“CS1”). AKM1 mirrors to a secondary AKM server (“AKM2”) in another cloud service (“CS2”). You want your client application to retrieve encryption keys from AKM1, but fail over to AKM2 in the case of a connection problem with AKM1. In your client configuration, you will supply information for AKM1 and AKM2 as follows: you will specify the private IP address and private port number of key retrieval for AKM1, and you will supply the public IP address and public port number for key retrieval for AKM2. Note that in this situation you would also need to open the port for key retrieval on AKM2.

Using KMIP

If you are using KMIP , you will also need to add the KMIP port to the endpoints configuration in addition to your other required endpoints:

Primary AKM server

Name/Function Public Private
KMIP 5696 5696

Secondary AKM server

Name/Function Public Private
KMIP 6696 5696

IMPORTANT: When both AKM servers are in the same cloud service, they cannot use the same public ports. If the AKM servers are not in the same cloud service, they can use the same public ports.

The exact endpoints you use should match your desired configuration. For help with more complex configurations than the examples listed above, please contact the Townsend Security customer support group.

Load balancing

Microsoft Azure’s supports load balanced endpoints (Standard Tier only). This means an application can use your cloud service’s public hostname and a single port to access both the primary and secondary AKM servers. This can be useful for key retrieval or remote encryption in that it reduces potential code changes in your application.

Sometimes, it is not possible to access the AKM server for retrieval or remote encryption, such as during a key database backup or if Microsoft Azure takes down a VM for maintenance. During these times, it is important that your application can still access your encryption keys. In a standard hardware deployment of AKM, this requires using a failover mechanism in your application, either through one of Townsend Security’s client libraries or modules, or through coding changes to your application.

Microsoft Azure’s load balanced endpoints simplify this task. During normal operations, Microsoft Azure will send your key retrieval or encryption requests to either of your AKMs. During a period where one of your AKMs is inaccessible, Microsoft Azure will send your request to the AKM which is still available without your application having to adjust.

The following endpoints can be load balanced: key retrieval and remote encryption. If you use the KMIP port for key retrieval, you can load balance that port as well. Do not load balance the admin or mirror ports. If you use KMIP to perform administrative functions, do not load balance the KMIP port unless your mirroring is bidirectional (the primary AKM mirrors to the secondary, and the secondary mirrors to the primary). For information on setting up bidirectional mirroring, see Appendix D.

For key retrieval from applications within the same cloud service as AKM, you can improve performance by sending requests to the private (internal) IP address of your AKM servers. This confers the additional security advantage of allowing you to leave the key retrieval endpoint closed. It does mean that you must integrate failover into your application rather than using load balancing.

Monitoring

Because your application cannot see which AKM it is using, it will not raise any flags in the infrequent circumstance that your AKM is not available. You will need to monitor the health of your Azure-based AKMs. Please see the Microsoft documentation on monitoring:

Private cloud

Microsoft Azure supports private cloud deployments of virtual machines such as AKM for Microsoft Azure. A private cloud provides additional security and isolation of the operating environment. Please refer to the Microsoft guidance on private clouds.

Next steps

Click the right arrow button, then click the checkmark button on the final screen. If you are using one or more secondary AKM servers, follow the same steps to launch these servers.

You are now ready to set up AKM for Microsoft Azure.

Chapter 5: Set up AKM for Microsoft Azure

Setting up AKM for Microsoft Azure 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, collecting logs for troubleshooting, 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 primary AKM server’s public DNS name or public IP address. For example:

ssh admin@akmpublicDNSnameorpublicIPaddress

The default password is OOHXPq6r530N6re.

IMPORTANT: For AKM to activate the license, your VM 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.

NOTE: Windows users can connect to the server via SSH using PuTTY. See Appendix A: Connecting with PuTTY for more information.

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:

image alt text

The Administrative Menu is displayed:

image alt text

Enter option 1 to Initialize AKM. The Initialization Menu is displayed:

image alt text

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. See Appendix D for more information.

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:

image alt text

Create an initial set of encryption keys

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

image alt text

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 7: 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:

image alt text

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 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:

image alt text

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 the option to Set admin password. You will be prompted to change the admin password:

image alt text

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 password and protect it carefully, as the compromise of this password breaches the security of AKM. If you set a weak password you will receive a warning, but the password will still be accepted. It is recommended to set a password of at least 15 characters that includes upper and lower case letters, numbers, and symbols.

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 now been changed and will be used to access the primary AKM server via SSH for all future sessions. You will also use this password to log in to the primary AKM server web interface with username “admin”. 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: Deploy AKM for Microsoft Azure for information on regions and availability sets in Microsoft Azure.

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 endpoint configuration of the primary AKM server should include port 22, and the endpoint configuration of the secondary server should include ports 22 and 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.

Option 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:

image alt text

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 public DNS name or public IP address of the secondary AKM server. When both AKM servers have the same public DNS name or IP address, you will also need to include the public SSH port of the secondary AKM server (you can find this information in the Azure Portal). For example:

ssh -p nnnnn admin@secondaryDNSnameorIPaddress

Where nnnnn is the public SSH port of the secondary AKM server.

Enter user “admin and the default password “OOHXPq6r530N6re“. 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.

Select option 1) Initialize AKM, then select option 2) Initialize as MIRROR.

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:

image alt text

Select option 1 and press Enter. Paste the SSH public key of the primary AKM server into the console.

NOTE: If you are using PuTTY on Windows, right-click in the console to paste the SSH public key.

After pasting in the SSH public key, press Enter, then press Ctrl-D to continue mirroring setup:

image alt text

Copy the fingerprint of this AKM for later verification. Press any key to return to the main menu.

Return to the primary AKM server’s Mirror Configuration Menu and press Enter:

image alt text

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.

 

Option 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:

image alt text

Select 1) Add mirror.

Open an SSH connection to the secondary AKM server using the public DNS name or public IP address of the secondary AKM server. When both AKM servers have the same public DNS name or IP address, you will also need to include the public SSH port of the secondary AKM server (you can find this information in the Azure Portal). For example:

ssh -p nnnnn admin@secondaryDNSnameorIPaddress

Where nnnnn is the public SSH port of the secondary AKM server.

Enter user “admin and the default password “OOHXPq6r530N6re“. 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.

Select option 1) Initialize AKM, then select option 2) Initialize as MIRROR.

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:

image alt text

On the secondary AKM server select option 2 from the SSH menu:

image alt text

Log in to the primary AKM server web interface and navigate to File Manager.

The SSH public key is located in /home/admin/.ssh/ and is called id_rsa.pub.

Select this file and double click to save. Log in to the secondary AKM server web interface and upload this file to /home/admin/uploads/ via File Manager.

Return to the SSH menu on the secondary AKM server and press any key to continue:

image alt text

Enter y to confirm that you would like this secondary AKM server to accept mirrored AKM keys from the primary.

Note the fingerprint of the secondary AKM for later confirmation.

Return to the primary AKM server Administrative Menu, then use the mirroring menu to select the secondary AKM as its mirror. Confirm the fingerprint of the secondary AKM server.

Mirroring setup is complete.

Option 3: Use an established SSH key

Use this option if the public SSH key has already been authenticated but mirroring setup was not completed.

Open an SSH connection to the secondary AKM server using the public DNS name or public IP address of the secondary AKM server. When both AKM servers have the same public DNS name or IP address, you will also need to include the public SSH port of the secondary AKM server (you can find this information in the Azure Portal). For example:

ssh -p nnnnn admin@secondaryDNSnameorIPaddress

Where nnnnn is the public SSH port of the secondary AKM server.

Enter user “admin and the default password “OOHXPq6r530N6re“. 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.

Select option 1) Initialize AKM, then select option 2) Initialize as MIRROR.

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:

image alt text

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

image alt text

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 in the Actions 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.

NOTE: If a bidirectional mirroring configuration is desired, continue with the steps in Appendix B: Set up Bidirectional Mirroring.

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 save.

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.

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 web interface and download admin and client certificate and key pairs for distribution to admin and key clients. See Chapter 6: Start Using AKM for Microsoft Azure for more information.

 

Chapter 6: Start Using AKM for Microsoft Azure

Overview

To get started using AKM for Microsoft Azure, you will need to set up your key clients for key retrieval and/or remote encryption. You will first log in to the AKM server web interface and download the client certificates and private keys needed for client/server connections. You will then give a key client certificate and private key plus the name of one or more encryption keys to your client application developer. You can also download admin client certificates for encryption key management in the AKM Administrative Console.

Log in to the web interface

Open a web browser and connect to the primary AKM virtual machine via a secure HTTPS connection. Use the public cloud service DNS name or IP address and the public web interface port number for the primary AKM server. For example:

https://cloud-service-name.cloudapp.net: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:

image alt text

NOTE: A different IP address may be displayed.

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

The following page is displayed:

image alt text

Click the green arrow next to “AKM” to expand the navigation pane:

image alt text

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:

image alt text

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 Microsoft Azure in a production environment, you may need to install software patches. If there are any necessary software patches available from Townsend Security or your software vendor, you should 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.

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.

If using a secondary mirror server, follow the steps in the section Certificates to use after setting up mirroring.

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.zipand double click to save. Unzip this archive.

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

  • /JKS

    • AKMClientKeystore.jks (client certificate/private key)

    • AKMClientPassword.txt (client certificate/private key password)

    • AKMRootCATruststore.jks (AKM’s CA certificate)

    • AKMRootCATruststorePassword.txt (the CA certificate password)

  • /KeyConnection

    • AKMClientCertificateAndPrivateKey.p12 (client certificate/private key)

    • AKMClientPassword.txt (client certificate/private key password)

    • AKMRootCACertificate.pem (AKM’s CA certificate)

  • /P12

    • AKMClientCertificateAndPrivateKey.p12 (client certificate/private key)

    • AKMClientPassword.txt (the client certificate/private key password)

  • /PEM

    • AKMClientCertificate.pem (client certificate)

    • AKMClientPrivateKey.pem (client private key)

    • AKMRootCACertificate.pem (AKM’s CA certificate)

    • <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:

  • /JKS

    • AKMClientKeystore.jks (keystore containing the client certificate/private key)

    • AKMClientPassword.txt (keystore password)

    • /Mirror_Config_Certificates

      • AKMTruststoreBundle.jks (truststore bundle containing both AKM’s CA certificates)

      • AKMTruststoreBundlePassword.txt (truststore password)

  • /KeyConnection

    • AKMClientCertificateAndPrivateKey.p12 (client certificate/private key)

    • AKMClientPassword.txt (client certificate/private key password)

    • /Mirror_Config_Certificates

      • <PrimaryAKMServerName>.AKMRootCACertificate.pem (the primary AKM’s CA certificate)

      • <MirrorAKMServerName>.AKMRootCACertificate.pem (the mirror AKM’s CA certificate)

  • /P12

    • AKMClientCertificateAndPrivateKey.p12 (client certificate/private key)

    • AKMClientPassword.txt (the client certificate/private key password)

  • /PEM

    • AKMClientCertificate.pem (client certificate)

    • AKMClientPrivateKey.pem (client private key)

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

    • /Mirror_Config_Certificates

      • <PrimaryAKMServerName>.AKMRootCACertificate.pem (the primary AKM’s CA certificate)

      • <MirrorAKMServerName>.AKMRootCACertificate.pem (the mirror AKM’s CA certificate)

      • AKMRootCertificatesBundle.pem (bundle with both AKM’s CA certificates)

 

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.

If using a secondary mirror server, follow the steps in the section Certificates to use after setting up mirroring.

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.zip and <AKMServerName>_admin2.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.

Select <AKMServerName>_admin1.zip and/or <AKMServerName>_admin2.zipand double click to save. Unzip the archives.

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.zip and <AKMServerName>_admin2.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:

  • /PEM

    • AKMAdminCertificate.pem (admin certificate)

    • AKMAdminPrivateKey.pem (admin private key)

    • /Mirror_Config_Certificates

      • <PrimaryAKMServerName>.AKMRootCACertificate.pem (the primary AKM’s CA certificate)

      • <MirrorAKMServerName>.AKMRootCACertificate.pem (the mirror AKM’s CA certificate)

      • AKMRootCertificatesBundle.pem (bundle with both AKM’s CA certificates)

  • /Admin_Console

    • AKMAdminKeystore.jks (admin keystore)

    • AKMAdminKeystorePassword.txt (admin keystore password)

    • /Mirror_Config_Certificates

      • AKMTruststoreBundle.jks (truststore bundle with both AKM’s CA certificates)

      • AKMTruststoreBundlePassword.txt (truststore bundle password)

Give the name of an encryption key to your client application developer

If you created a set of initial encryption keys on initialization of the primary AKM server, the following keys are immediately available for use:

  • AES128 - 128-bit symmetric key, general access

  • AES192 - 192-bit symmetric key, general access

  • AES256 - 256-bit symmetric key, general access

  • EKM128 - 128-bit symmetric key for use with SQL Server EKM, enabled for EKM

  • EKM256 - 256-bit symmetric key for use with SQL Server EKM, enabled for EKM

  • EKMSS - 2048-bit RSA key for use by SQL Server EKM, enabled for EKM

  • RSA1024 - 1024-bit RSA key

  • RSA2048 - 2048-bit RSA key

  • RSA3072 - 3072-bit RSA key

  • RSA4096 - 4096-bit RSA key

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 GUI application 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.

See the section Download Crypto Officer certificates for information on downloading the truststore and keystore.

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.zip and <AKMServerName>_admin2.zip). To authorize a second Crypto Officer to use the Admin Console, you will need to follow the same steps using the <AKMServerName>_admin2.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:

image alt text

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: cloud-service-name.cloudapp.net).

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).

Click Add. You are now authorized to create and manage encryption keys on the AKM server. See the AKM Administrative Console Guide for more information.

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:

AKM_222 (10.0.1.230 port 6001)
------------------------------------------
Command: Administrative NoOp
------------------------------------------
Server: AKM_222 (10.0.1.230 port 6001)
  Transaction Length: <00008>
  Transaction Id: <1044>
  Return Code: <0>
  Command completed successfully.
Command Output: 
  No additional command output
---------------------------------------
End Command Administrative NoOp
---------------------------------------

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 key 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:

Command: Create Symmetric Key
------------------------------------------
Server: 10.0.1.230 (10.0.1.230 port 6001)
  Transaction Length: <00072>
  Transaction Id: <1002>
  Return Code: <0>
  Command completed successfully.
Command Output: 
  Key Name: <TEST KEY               >                 
  Key Instance: <SAZ4he9kkZYjmF5+n2A6Mg==>
---------------------------------------
End Create Symmetric Key Command
---------------------------------------

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.

 

Chapter 8: Create Additional Admin and Client Certificates

AKM automatically generates a certificate authority (CA) certificate, two admin (Crypto Officer) certificates and one client (key retrieval or remote encryption) certificate. For information on using these certificates, see Chapter 6: Start Using AKM for Microsoft Azure and Chapter 7: Create and Manage Encryption Keys.

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

After initializing the primary AKM server, reconnect to the primary AKM server via SSH. After initialization of the primary server has been completed, you can select the option to Start Certificate Manager from the Administrative Menu. The Certificate Menu is displayed:

image alt text

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:

image alt text

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

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:

image alt text

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

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:

image alt text

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:

image alt text

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 Microsoft Azure, and periodically after any significant changes to keys, user access policies, and certificates.

Software updates

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

image alt text

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.

image alt text

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.

image alt text

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.

image alt text

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.

image alt text

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.

Certificate backup

You should back up all certificate and private keys using by AKM. See the AKM Server Management Guide for more information.

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

 

Chapter 10: Obtain a Permanent License

AKM for Microsoft Azure 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 Microsoft Azure.

You will need to give your account manager the private or internal IP address of your AKM instance.

Log in to the Azure Portal and select Virtual machines on the left. Select the AKM image and select IP addresses in the “Settings” pane to view the private IP address.

Alternatively, run the IFCONFIG command from the command prompt or reference the IP address found in the AKM configuration file (akm.conf).

 

Install a new license

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

IMPORTANT: Do not change the name of the license file. It must have the name License.txt when it is installed on the server.

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.

Click the Upload button. Click Choose File, select the permanent license, and click okay.

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.

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. Failing to do so 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. 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.

Additionally, you should avoid using the same data encryption keys in your production environment that were used during testing (see Chapter 7: Create and Manage Encryption Keys).

Chapter 11: Support

There are two levels of technical support available for AKM 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.

 

Appendix A: Connect with PuTTY

If you are a Windows user, you can use PuTTY to connect to the AKM server via SSH for initialization.

First, download PuTTY at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html and run the executable. When you open PuTTY for the first time, you will be prompted to enter configuration information for the AKM server:

image alt text

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:

image alt text

Enter “admin” as the username, and when prompted, the default password “OOHXPq6r530N6re”. To paste the password, right click in the PuTTY console.

If the login is successful, the Administrative Menu will be displayed. Return to Chapter 5: Set up AKM for Microsoft Azure to continue with initialization.

 

Appendix B: Create an Azure Service Project in Visual Studio

This chapter gives an example of how to prepare the AKM SDK for .NET DLLs in Visual Studio for use in the Azure Cloud Service. Before launching an instance in a Cloud Service, you must create and configure a web role, package and build the DLLs in Visual Studio, and configure the application to launch in an Azure Cloud Service. The application is configured with test data and shows an example encryption and decryption in the last step.

Required installations

  • Microsoft Visual Studio
  • AKM for Microsoft Azure
  • AKM SDK for .NET

Create the Web Role

Start Microsoft Visual Studio and select File, New, Project from the menu bar. Under “Templates”, select Visual C#, then select Azure Cloud Service for the .NET framework. Enter the location of the project and the name of the solution. Click OK:

image alt text

On the “New Microsoft Azure Cloud Service” dialog box, select ASP.NET Web Role and select the right arrow button to add it to your solution. As many web roles as are needed can be added to the solution. Hover over the web role and select the edit icon to rename the web role. Select OK to create the solution:

image alt text

NOTE: If the Solution Explorer does not appear, select View, Solution Explorer from the menu bar. In the Solution Explorer navigate to References under the web role. Right click References and select Add Reference.

Browse to the location of the TownsendSecurity.EncryptDecryptUdf.dll and the TownsendSecurity.KeyClient.dll. Select the box next to each DLL and select OK:

image alt text

The web role is listed under “Roles” in the Solution Explorer. Right click the web role and select Properties. Select the Configuration tab and select the desired settings for the Windows Server instance that will populate to the cloud:

image alt text

Select the Endpoints tab and add the desired endpoints with the “Add Endpoint” option:

image alt text

Select the Certificate tab. Use the “Add Certificate” option to add certificates. Create descriptive names for the certificates and enter the certificate thumbprint for each certificate:

image alt text

Right click the project name listed in the Solution Explorer and select Configure Remote Desktop. Create a username and password for the Windows Server VM that will populate the instance tab of the Azure Cloud Service:

image alt text

Once the remote login configurations are defined, the “Settings” tab will update to show the username and password configurations:

image alt text

To test encryption and decryption using an AKM key for key retrieval, edit the default.aspx and default.aspx.cs files in the Solution Explorer. Below is sample code for the default.aspx and default.aspx.cs files. To avoid errors, ensure that all pages have the same namespace. Make sure to save each file after making changes.

Default.aspx

<%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestRole._Default" %>

<asp:Content runat="server" ID="FeaturedContent" ContentPlaceHolderID="FeaturedContent">
</asp:Content>
<asp:Content runat="server" ID="BodyContent" ContentPlaceHolderID="MainContent">
    <ul runat="server" id="x" />
</asp:Content>

Default.aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Cryptography.X509Certificates;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
using System.Text;
using TownsendSecurity.KeyClient;
using System.Security.Cryptography;

namespace TestRole
{
    public partial class _Default : Page
    {
        void print(string text)
        {
            var li = new HtmlGenericControl("li");
            li.InnerText = text;
            x.Controls.Add(li);
        }

        static void SetServerConfiguration(ServerConfiguration serverConfiguration)
        {
            serverConfiguration.ServerCertificateThumbprint = "1D781C0B6D46A142F618A1925ECEC27FD6A5B2F4";
            serverConfiguration.AllowCertificateNameMismatch = true;
            serverConfiguration.Hostname = "23.99.52.96";
        }

        static void SetClientConfiguration(ClientConfiguration clientConfiguration)
        {
            clientConfiguration.ClientCertificateThumbprint = "C6714B6BC65B4193F145C4CDC926C16E86731B9D";
            clientConfiguration.ServerConfigurations = new ServerConfiguration[] { new ServerConfiguration() };
            SetServerConfiguration(clientConfiguration.ServerConfigurations[0]);
        }


        protected void Page_Load(object sender, EventArgs e)
        {
            X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
            store.Open(OpenFlags.ReadOnly);
            print("Certificates available:");

            foreach (var cert in store.Certificates)
            {
                print(cert.Thumbprint);
            }

            store.Close();

            string instance;
            byte[] plaintext;
            byte[] initializationVector;
            byte[] ciphertext;
            byte[] roundtrip;
            var keyName = "AES256";
            var data = "Hello World";

            plaintext = Encoding.UTF8.GetBytes(data);

            try
            {
                using (var encryptionService = new EncryptionService())
                {
                    SetClientConfiguration(encryptionService.ClientConfiguration);
                    using (var encryptor = encryptionService.CreateEncryptor(CipherMode.CBC))
                    {
                        initializationVector = encryptor.IV;
                        encryptor.KeyName = keyName;
                        ciphertext = encryptor.TransformFinalBlock(plaintext, 0, plaintext.Length);
                        instance = encryptor.Instance;
                    }

                    using (var decryptor = encryptionService.CreateDecryptor(CipherMode.CBC))
                    {
                        decryptor.KeyName = keyName;
                        decryptor.Instance = instance;
                        decryptor.IV = initializationVector;
                        roundtrip = decryptor.TransformFinalBlock(ciphertext, 0, ciphertext.Length);
                    }

                    var result = Encoding.UTF8.GetString(roundtrip);

                    print("data: " + data);
                    print("plaintext: " + BitConverter.ToString(plaintext));
                    print("keyName: " + keyName);
                    print("instance: " + instance);
                    print("initializationVector: " + BitConverter.ToString(initializationVector));
                    print("ciphertext: " + BitConverter.ToString(ciphertext));
                    print("roundtrip: " + BitConverter.ToString(roundtrip));
                    print("result: " + result);
                }
            }
            catch (KeyClientException ex)
            {
                print("Key client error, " + e.GetType().Name + ": " + ex.Message);
            }
            catch (Exception ex)
            {
                print("Exception caught: " + ex.Message);
            }
        }
    }
}

Right click the project name under Solution Explorer and select Build to build the project:

image alt text

The project should build without errors.

Right click on the project in the Solution Explorer and select Publish. Select the username that will be used to sign in to Azure Portal. Click Next:

image alt text

Select the cloud service in the “Settings” tab and select other settings as needed. Click Next: image alt text

Ensure all settings are correct on the “Summary” tab and click Publish:

image alt text

Enter the URL for the cloud service in a web browser to view the test encryption/decryption results:

image alt text

 

Appendix C: Configure AKM Certificates for use with Azure Cloud Services

If the client application will run in Azure Cloud Services, you must configure the cloud instance for integration with AKM. This involves uploading the AKM certificate authority (CA) certificate and client certificate/private key to the Cloud Service certificate store, and moving the certificates to the correct certificate stores. The last step in this appendix describes testing key retrieval from the AKM server.

To locate the necessary certificates, see Download certificates needed for client connections in Chapter 6. The certificates are called AKMClientCertifcateAndPriavteKey.p12 and AKMRootCACertificate.pem and will need to be converted to different formats for use with Azure Cloud Services.

Convert certificate files to the correct format

The client certificate/private key (AKMClientCertifcateAndPriavteKey.p12) must have a .pfx extension, and can simply be renamed.

The AKM CA certificate (AKMRootCACertificate.pem) must be converted to DER format with a .cer extension. This can be done using the OpenSSL command line tool as described here. It can also easily be converted using Windows Certificate Manager:

Converting a PEM file to a DER file in Windows Certificate Manager

Enter certmgr.msc in the run box to access Windows Certificate Manager. Use the Action, All Tasks, Import menu option to import the PEM certificate into the Trusted Root Certification Authorities store. Right-click on the newly imported certificate and select All Tasks, Export.

A dialog box for the Certificate Export Wizard will appear. Click Next:

image alt text

Select DER encoded binary X.509 (.CER) as the format:

image alt text

Click Browse to specify a destination for the file and name the file:
image alt text

Click Finish to complete the conversion:

image alt text

Once the CA certificate has been converted, continue with the following steps.

Create a Cloud Service

If you have not yet created a Cloud Service to host the client application, follow these steps.

Log in to the Azure Portal and select New, Compute, Cloud service:

image alt text

Select the Create button at the bottom of the Information screen: image alt text

Enter the DNS name, select the Resource group, and select the Location. Then click the Create at the bottom of the screen:

image alt text

Configure an Azure Cloud Service for AKM

In the Azure Portal select Cloud services (classic) on the left, then select the desired cloud service:

image alt text

Select the Certificates tab and upload the AKM CA certificate in DER format (.cer extension) (AKMRootCACertificate.cer) and client certificate/private key in PFX format (AKMClientCertificateAndPrivateKey.pfx):

image alt text

Copy and paste the CA and client certificate thumbprints from the Azure Certificate Store into the “Certificates” area of the Visual Studio web role. Be sure to select “My” for the client certificate Store Name and “Trust” for the certificate authority Store Name:

image alt text

NOTE: Installing directly into the trusted root store is restricted. Certificates that require installation must manually be moved from a non-trusted store to a trusted store in the Windows Certificate Manager.

Right-click the web role and select Publish: image alt text

Review the summary and click Publish to create the web cloud instance:

image alt text

Connecting to a Cloud Service VM

Once the web role is published, “Roles and instances” will populate with the name of the instance at the bottom of the panel. Click on the instance that shows “Running” under the “Status” option. Select Connect at the top of the next panel.

An RDP (Remote Desktop Connection) file will download. Click on the RDP file and click Connect:

image alt text

Log in as a user for the Virtual Machine:

image alt text

When prompted, select Yes to proceed with the remote desktop connection:

image alt text

Work with certificates in Windows Certificate Manager

Enter “mmc” in the search box and select the mmc option:

image alt text

From the File menu, select Add or Remove Snap-ins, then select Certificates. Click Add:

image alt text

Select Computer Account under the “Certificate Snap-in” dialog box and click Next:

image alt text

Select Local Computer and click Finish:

image alt text

Click OK on the “Add or Remove Snap-ins” dialog box:

image alt text

The client certificate should automatically populate in the Personal store of the Windows Certificate Manager:

image alt text

The CA certificate will initially upload into the “Enterprise Trust” store. It will need to be moved to the “Trusted Root Certification Authorities” store:

image alt text

Drag the CA certificate from the Enterprise Trust store to the Trusted Root Certification Authorities store:

image alt text

Confirm encryption works

Enter the URL for the Cloud Service in a web browser to confirm that key retrieval is working:

image alt text

 

Appendix D: 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.