White Paper. Deploying CKMS Within a Business

White Paper Deploying CKMS Within a Business

1 Introduction The Cryptomathic Crypto Key Management System (CKMS) is a market-leading lifecycle key management product that can manage cryptographic keys for a wide variety of applications within a business. CKMS provides a centralized and automated architecture that enables an organization to effortlessly generate, distribute and update keys across its distributed security network. The central management and automated key distribution capabilities can eliminate paperwork and remove the need to manually update keys on individual security targets. In other words, key ceremonies can be done securely at your desk. listen for encrypted keys sent (or pushed ) from CKMS. Received keys are decrypted and placed in local key storage, which is accessed by a business application. For example, a PKCS #11 HSM may have an associated AR that receives keys sent from CKMS and unwraps them into the HSM with C_Unwrap (see Figure 1). Cryptomathic can provide ARs for several common use cases, including PKCS #11 HSMs and Java key stores. In other cases, ARs can be developed on a case-by-case basis by either the business or Cryptomathic. CKMS is hardware-vendor agnostic and supports current standards and emerging protocols, such as PKCS#11 and KMIP, making it the most flexible and adaptable solution available. CKMS is designed to meet various compliance requirements, such as FIPS 140-2, PCI DSS and payment schemes. Its central tamper-evident audit logs provides controlled access to the relevant information, which greatly simplifies proof of compliance. CKMS Encrypted Key Originally developed in 1998 for a global payments provider, CKMS is now the leading key management solution for the financial sector. Companies that use CKMS include First Data, Swedbank, Unicredito as well as global card payment schemes. WAN With the ever-increasing number of cryptographic keys that an organization needs to manage combined with the mounting pressure of internal and external compliance, businesses are looking for ways to improve efficiency and reduce overheads on their key management operations. Before the right solution for a business can be selected, the deployment and integration capabilities with existing systems must be taken into account. Key Target Storage This document describes how a typical CKMS deployment is designed and implemented, including integration with existing business applications. 2 Key Distribution with CKMS Load Key PKCS#11 Token Before we go much further, a quick recap on key distribution with CKMS will provide a reminder of the terminology and capabilities of the product. CKMS can deliver key material in two ways: across the network to an Automated Recipient (a.k.a. target), or physically to a Manual Recipient (a.k.a. client). Business Application 2.1 Automated Recipients Automated Recipients (ARs) are network-accessible applications that Figure 1: Key distribution to Automated Recipient 2

3 Key Discovery Phase Two levels of key encryption keys (KEKs) are used to encrypt keys sent to ARs. The top-level key is known as a root KEK and is shared in XOR components between CKMS and the AR. Typically CKMS generates this key, but it is also possible to import key components generated by an AR. The second-level key is known as a transport KEK. The transport KEK is delivered to the AR across the network, encrypted with the root KEK. The transport KEK is used to protect the application keys sent from CKMS to the AR. The process of identifying potential CKMS integrations within a business is known as a key discovery phase. This phase requires examination of each project and associated infrastructure to find places where cryptography is used. In each instance, the purpose of the cryptography, the key properties (size, algorithm) and the way the key is stored should be noted. Once a list of keys has been produced, the next step is to prioritize the list. The prioritization process will be business specific, but common factors include: 2.1.1 Key Requesting ARs can also request keys from CKMS. A message is sent from the AR to CKMS, requesting generation of a particular key type. Once authorized, the key is then sent back to the AR automatically. 2.2 Manual Recipients In contrast to ARs, Manual Recipients (MRs) are not network-accessible and so receive keys in XOR components or encrypted files. MRs are typically external entities that need to share key material with the business for instance, a payment processor sharing a PIN encryption key (PEK). CKMS supports a wide range of different MR import and export formats, including: Format Export mport Atalla Key Block Yes Yes Atalla Variant Yes Yes Cryptogram under ZMKP Yes No Multos Public Key Yes No The risk associated with the key or certificate if it is not renewed Whether the current manual key management meets compliance requirements The current cost associated with managing the key manually Before finalizing the prioritized list of keys to manage, thought must be given to the way CKMS will deliver keys to each system. If the distribution is to be over the network, then a suitable AR application must be developed or purchased. If the distribution is manual (i.e. to an MR), then the correct delivery format must be understood. The final result of this discovery phase should be: A list of all key usage within the business, including algorithm and length information (preferably validity too). This is a useful asset that should be kept up-to-date. A prioritized list of which keys will be managed by CKMS. A decision about how each key will be distributed. If necessary, a target application should be developed or licensed. PKCS#8 Cryptogram Yes Yes XOR components via PIN pad Yes Yes Self-signed Certificate No Yes Standard Cryptogram Yes Yes To share encrypted keys with an MR, CKMS must first establish a shared zone master key (ZMK) between the MR and CKMS. Typically this is generated by CKMS, then exported in XOR components to the MR. Once this is established at both ends, application keys can be sent encrypted under the ZMK. In order to offer assistance during the key discovery phase, Cryptomathic can provide a key scanning tool to determine the type of cryptographic resource accessed and the name and algorithm type of each key accessed via that cryptographic resource for each target system. Figure 2 overleaf shows the typical discovery lifecycle for cryptographic keys. From an initial unknown state, the key is discovered during project examination and subsequently prioritized. High priority keys should be managed by CKMS sooner than lower priority keys. The next stage is the distribution of the key, which is often done manually at first, although some projects will immediately move to automatic distribution. 3

Examine project Automatic Distribution Undiscovered Discovered Deploy automated recipient High priority Low priority Manual Distribution Configure in KMS Managed by CKMS Priority increases Unmanaged Figure 2: Key discovery lifecycle 3.1 Key Management Policies Now is an excellent time to update the key management policy (or create one, if the business lacks a formal policy). This policy should define the rotation frequency of cryptographic keys and prescribe allowed algorithms and minimum key lengths. It should also describe how keys are to be handled and distributed, including defining roles and responsibilities for staff. Many of these policy decisions can then be enforced by CKMS. The flexible role-based access control in CKMS can be configured to match the decisions made in the security policies. 4 Training Once the discovery phase is finished, the next phase is to train the staff to use CKMS. By completing this training before deployment, the staff will learn the skills necessary to install the system themselves. Even if the intention is to use professional services installation assistance from Cryptomathic, there are still benefits to training the staff ahead of this activity as it will increase their participation and understanding of what is being done. Cryptomathic offers a two-day CKMS training course that covers: Software installation System configuration and user management AR and MR configuration Key lifecycle management Protocol information System maintenance Bespoke training courses are available upon request. 5 Deployment The deployment phase is where CKMS is installed, AR applications are configured and existing key material is migrated into the system. The basic software installation procedure is well documented in the CKMS manuals and will not be repeated here. Instead, the focus will be on configuration of AR applications and key migration. 5.1 Automated Recipient Configuration Before an AR application can be used, it must be added to CKMS and several keys must be exchanged with the CKMS server. Adding the AR to CKMS involves giving the AR a name and configuring the hostname and port number that it will be listening on. 4

The keys exchanged with the AR are listed below: CKMS Authentication Key this is the key used by CKMS to sign messages sent to the AR. The AR must import the public key so that it can verify messages are coming from the real CKMS server. AR Authentication Key this key is generated by the AR and the public half is imported into CKMS. This key signs messages sent from the AR back to CKMS. Root KEK this key is shared in XOR components with the AR and is used to encrypt transport KEKs. Transport KEK these keys are sent to the AR encrypted under the root KEK. Once a transport KEK is installed, the AR can receive application keys. 5.2 Manual Recipient Configuration To configure an MR in CKMS, one assigns a name to the MR and selects the list of import/export formats that it supports. In addition to a name, MRs can have up to five pieces of meta-data associated with them, which are stored as simple strings. Once the MR is configured, the final task is to share a ZMK. Typically CKMS will generate this ZMK, split it into XOR components which are then loaded into the MR. It is possible, though, for CKMS to import ZMK components generated by the MR. 5.3 Migration of Existing Key Material Migrating existing key material is optional. In some cases, it may be preferable to completely re-key the system with keys generated in CKMS. Another approach is to generate all future keys using CKMS and gradually phase out the non-managed keys. If migration is deemed necessary, then the options available differ depending upon whether the keys are imported from an MR or an AR. Once an application key is imported, it can be distributed to any MR or AR. Manual Exchange Shared in components CKMS Root KEK Root KEK Automated Recipient Automated Distribution Encrypted under Root KEK (SOAP message) Transport KEK Transport KEK Encrypted under Transport KEK (SOAP message) Application Key Application Key Application Key Transport KEK 5

5.3.1 Manual Recipient Key Import Before keys can be imported, a ZMK must be established between the MR and CKMS. This can either be generated by CKMS and exported in XOR components through the PIN pad, or generated by the MR and imported in XOR components into CKMS. With a ZMK in place, CKMS can import keys in a variety of formats: 6 Using CKMS Whether a business chooses to manage their cryptographic keys using manual or automated techniques, CKMS offers a flexible approach to deploying centralized key management within a business and delivers the fine-grained controls to simplify procedures and streamline operations. Atalla Key Block Atalla Variant PKCS#8 Cryptogram XOR components on PIN pad (no need for ZMK in this case) Standard Cryptogram 5.3.2 Automated Recipient Key Import Before importing keys, a root KEK must be established between the AR and CKMS. This KEK will be generated by either the AR or CKMS and shared in XOR components. A transport KEK is required to encrypt any application keys imported by CKMS. This can either be shared in XOR components or imported from an XML file, encrypted under the root KEK. Application keys can be imported, in bulk, from an XML file. These keys must be encrypted by the currently active transport KEK. Once successfully deployed, CKMS provides the business users with a centralized and unified view of the cryptographic key estate throughout the life-cycle of each key. CKMS delivers the most comprehensive key management toolset combined with automated and asynchronous workflows to allow a business to administer large numbers of keys, across various business applications, in a straightforward and compliant manner. Contact us: For more information on key management, please contact your Cryptomathic representative OR Email: enquiry@cryptomathic.com sales_enquiry@cryptomathic.com technical_enquiry@cryptomathic.com Disclaimer 2017 Cryptomathic A/S. All rights reserved Jægergårdsgade 118, DK-8000 Aarhus C, Denmark This document is protected by copyright. No part of the document may be reproduced in any form by any means without prior written authorisation of Cryptomathic. Information described in this document may be protected by a pending patent application. This document is provided as is without warranty of any kind. Cryptomathic may make improvements and/or changes in the product described in this document at any time. The document is not part of the documentation for a specific version or release of the product, but will be updated periodically. ABOUT CRYPTOMATHIC Cryptomathic is a global provider of secure server solutions to businesses across a wide range of industry sectors, including banking, government, technology manufacturing, cloud and mobile. With over 30 years' experience, we provide systems for Authentication & Signing, EMV, Key Management and PKI & ID, through best-of-breed security solutions and services. We pride ourselves on strong technical expertise and unique market knowledge, with 2/3 of employees working in R&D, including an international team of security experts and a number of world renowned cryptographers. At the leading edge of security provision within its key markets, Cryptomathic closely supports its global customer base with many multinationals as longstanding clients. 6 Learn more v1.0