IBM Enterprise Key Management Foundation Web Edition
In this chapter we describe the following:
•Introduction to EKMF Web
•EKMF Web requirements
•Importance of key hierarchy
•Roles and responsibilities
•Keystores
•Key template
•Key lifecycle
•EKMF Web view of Data Sets
|
Note: The tasks described in this chapter are based on EKMF Web version 2.0. Always check the latest product documentation for the current EKMF Web version.
|
10.1 Introduction to IBM Enterprise Key Management Foundation - Web Edition (EKMF Web)
IBM Enterprise Key Management Foundation (EKMF) is a flexible and highly secure key management system for the enterprise. It provides centralized key management on IBM Z and distributed platforms for streamlined, efficient and secure key and certificate management operations.
EKMF serves as the foundation on which remote cryptographic solutions and analytics for the cryptographic infrastructure can be provided. EKMF is available as EKMF Workstation and EKMF Web:
EKMF serves as the foundation on which remote cryptographic solutions and analytics for the cryptographic infrastructure can be provided. EKMF is available as EKMF Workstation and EKMF Web:
•EKMF Workstation
Implemented as a self contained hardware appliance (including a dedicated workstation and Linux operating system), EKMF Workstation is feature rich, supporting many key types, with authentication done using smart cards with PINs. The security controls enable EKMF Workstation to have higher security rating and administer more complex key types.
|
Note: EKMF Workstation is a service-based offering.
|
•EKMF Web edition
Officially released as a product in April 2020, EKMF Webwas developed out of the IBM's Crypto Competence Center in Copenhagen, Denmark. Both EKMF Web and EKMF Workstation use the same EKMF Agent, which communicates with ICSF through APIs.
EKMF Web edition (see Figure 10-1 on page 219) runs in a z/OS LPAR (image) and is accessible through a Web browser. EKMF Web has much lighter functionality. Currently, EKMF Web supports generation and management of keys used in data set encryption, as well as setting up keys for cloud deployments.
|
Note: EKMF Web is an orderable software product.
|
Figure 10-1 EKMF Web architecture
10.1.1 EKMF Web Edition overview
EKMF Web provides a centralized key management solution for file and dataset encryption key stores. The GUI for EKMF Web is provided by Websphere Liberty application server deployment running on z/OS.
EKMF users can log in using a RACF ID. EJB Roles define the authorization to EKMF Web functionality. Keys are generated by EKMF Web and stored in the EKMF’s own key repository. Keys are secured by a key hierarchy protected by the master key residing in the HSM, which means that EKMF Web never gets to see the key in the clear.
The EKMF key repository backend is provided by Db2 database running on z/OS. Normal resiliency, backup and recovery process and procedures for z/OS Db2 should be used to protect the repository.
Keystores are defined to the EKMF Web for remote distribution. Based on policies defined in key templates, keys are distributed to the keystores wherever they may be needed. If a key is lost or deleted from a particular keystore, EKMF Web can restore the key by redistributing it.
If a key needs to be archived or deleted, EKMF Web can remove the key from the connected keystores.
10.2 EKMF Web edition requirements
EKMF Web is a native IBM z/OS solution leveraging core capabilities of the z/OS operating system and IBM Z hardware. The z/OS requirements include the following (Figure 10-2 on page 220):
•System requirements.
– z/OS 2.3, or later.
– WebSphere® Liberty 18.0.0.1 or later
– A task configured on the hosting z/OS LPAR to start an instance of the WebSphere Liberty Application Server.
– A task is configured on the relevant z/OS LPAR to start the Liberty Angel1 process.
•Crypto adapter (Crypto Express5S and newer)
– A crypto adapter is assigned to the LPAR where the WebSphere Liberty is installed.
– The crypto adapter is fully initialized with master keys set. EKMF Web uses AES, RSA, and EC keys
•The CKDS is configured to use variable-length key tokens.
•The required databases, tables, and views are created (Db2 for z/OS).
•EKMF Agent
– KMG and KMG-PE are installed in version HKMGAS0 with PTF level KMGS006 or later, or version HKMGAL0 with PTF level KMGL010 or later.
•The user account that installs and configures the Websphere Liberty must have write access to the configuration files.
Figure 10-2 EKMF Web requirements
EKMF web Graphical User Interface
EKMF Web access is performed via a web browser. User must log in using credentials which can be authenticated using RACF or LDAP. The authorizations are handled by EJBROLES which will be discussed further in 10.2.2, “EKMF Web authorization roles” on page 222.
Once logged in, the navigation tabs on the left side allow you to navigate between functions. The Main Menu for the EKMF Web is shown in Figure 10-3 on page 221.
Figure 10-3 EKMF Web Main Menu
10.2.1 Key hierarchy
Security and integrity of EKMF Web's, generation and distribution of keys is based on a key hierarchy (see Figure 10-4).As long as the master keys and web recovery keys are generated securely, there is never a time any of the keys are in the clear.
Figure 10-4 Key hierarchy
Trusted Key Entry Workstation (TKE) is strongly recommended as it will enable secure generation of keys never in the clear. EKMF Web requires master keys to be loaded into the AES, RSA and ECC registries for each cryptographic processor for each LPAR.
EKMF Web Disaster Recovery Key
EKMF Web also requires the secure creation of the EKMF Web Disaster Recovery Key (DRK). The DRK must be created in such a way that it is recoverable. The recommended approach is to store the DRK in parts, such that it can be reconstructed from these key parts.
Options for creating the DRK includes:
•Use TKE: When using TKE (recommended, especially for production systems), these key parts can be securely generated and stored on smart cards. Subsequently, the key parts can be loaded from the smart cards and can installed in the CKDS keystore using ICSF. Restoring the DRK follows the same key loading process using the existing key parts on smart cards.
•Use ICSF and the ICSF API: If TKE isn't available, key parts and their corresponding key check values can be created and calculated using ICSF and then recorded on paper. Note that key part creation for the EKMF Web DRK using ICSF isn't considered secure.
Keeping track of the paper copies of the key parts and storing them securely will be critical to prevent data loss in case the CKDS is corrupted. Each key part should be stored separately, such that no single individual has access to all parts.
Entry of these key parts to build the EKMF Web DRK will require the use of the ICSF API.
•Use the EKMF Web DRK utility: EKMF Web provides a utility that can be used to create a known, fixed-value Disaster Recovery Key that can be used for initial testing and isolated proof-of-concepts.
The tool will create a 256 bit AES Importer key with the key value 3DF4B30AE33ED6E22EEBA06359512ACB2B7F9AA006105943C93E8BF30EACF700 and ENC-ZERO key check value '5D7DDC'.
In case the DRK is lost from the CKDS, re-running the utility will recreate the key and allowing recovery of the keys stored in the EKMF repository.
As the key value is known, this utility is only appropriate to use for functional testing and proof-of-concepts. A setup based on this key should not be considered secure. Do not use this key in production.
10.2.2 EKMF Web authorization roles
EKMF Web uses EJBROLES defined in RACF to authorize users to perform different functions in EKFM Web. These roles are defined during setup. EKMF web provides a sample of four different types of user groups to be created based on these roles.
These are: Key Administrator, Key Custodian 1, Key Custodian 2, and Auditor. The function of each role is introduced in the following list:
•Key Admin: sets up key hierarchy, controls key stores, creates key templates, as well as performs special key state actions
– EJBROLE access: templates:write
•Key Custodian 1: can generate keys in Pre-Activation state, but cannot activate and distribute them. Can also destroy keys and mark keys as compromised.
– EJBROLE access: keys:generate
•Key Custodian 2: cannot generate keys, but can activate and distribute them into key stores. Can also destroy keys and mark keys as compromised.
– EJBROLE access: keys:active:install
•Auditor: can view the audit log as well as keystores, templates, key list, data set dashboard
– EJBROLE access: auditlog:read
10.3 Key management with EKMF Web
This section provides a overview of the key management process using EKMF Web.
10.3.1 EKMF Keystores
EKMF Web is a centralized key manager. Keys are generated by the EKMF Web server and stored in the EKMF Web repository (Db2). Based on the policies and GUI requests, keys are then installed into the local keystores. For this to work, the EKMF Web must connect to z/OS CKDS keystores.
On each LPAR, EKMF has an agent that listens for request and issues the underlying ICSF API calls to load the keys into the CKDS (see Figure 10-5). This requires an EKMF agent to be installed on each system that has a unique CKDS. If you are sharing a CKDS in a sysplex you need one agent up per sysplex.
Figure 10-5 EKMF Web deployment - multiple z/OS images
10.3.2 Key template
All keys that are generated by EKMF Web must be generated from a template. The template defines the key label name, keystores where keys should be installed, and key characteristics. Typically, the key administrator role has access to create the key template, whereas the key custodians have access to use the template. The auditor role would have read only access to template.
10.3.3 Key label
When creating the key label, it is important to have in mind the key usage and meaningful label parts (see 3.5.7, “Creating a key label naming convention” on page 53). The key label typically describes the type of key, area where the key would be used, application key that would be used, and the sequence number.
It is considered a best practice to have a sequence number as a tag. EKFM Web will provide the next sequence number during request.
In the key label shown in Figure 10-6, an AES256 bit key on system TEC2MVS is used in a Db2 subsystem DB1A with a sequence number.
In addition, custom tags can be added that need to be resolved during key generation. If for example the tags <ENV> and <APPID> are defined, those two need to be specified as parameters during every key generation based on this key template.
Figure 10-6 Key label example
Using custom tags in the key label in a key template means that a key label can be used to enforce a key label naming convention.
Specifying a key label as:
AES256.TEC2MVSF.<APPID>.<ENV>.SEQ<seqno>
means that the resulting key label used for the key in the CKDS will begin with the literal string 'AES256.TEC2MVSF.' but will be followed by three variable values (separated by dots). The last will always be 'SEQ' followed by the (5 digit) key sequence number.
10.3.4 Keystores
The key template will have a drop down listing all available keystores (see Figure 10-7). By checking the keystore, EKMF Web will install the keys generated by this template into all specified keystores.
Figure 10-7 Key store list in EKMF Web
10.3.5 Characteristics of the key template
There are a number of key characteristics to consider when creating the key template (see Figure 10-8 on page 225). A short description of each can be found below.
•Key Size: Data Set Encryption requires a 256 bit key
•Key Type: CIPHER Keys are consider more secure than DATA keys if you have a z14 or higher then select Cipher
•Key State: If you select Active upon generation, the key will be distributed to all keystores. If you select Pre-activation, the key will not be distributed automatically.
•Key Template state: If ACTIVE, it can be used, and if ARCHIVED, it cannot be used.
•Export: this setting allows key to be exported. Only select if you have a valid reason to export the key template.
•Key Activation: This is setting a period for how long the key will be active and from when it will be expired. Use this setting in accordance with policies but be careful of implications. Encrypted data can be archived. If you call back years later you might have to use an expired key. For this reason it is never recommended to delete keys rather to archive them.
Figure 10-8 Key characteristics
10.3.6 Key lifecycle
The lifecycle of keys is one of the most important aspects of the key management. NIST has a defined process for the key lifecycle, which defines flows for key generation (Generate), activation (Activate), deactivation (Deactivate), marking the key as compromised (Compromise), and destroying a key (Destroy).
EKMF Web provides the functionality to manage the key lifecycle. Figure 10-9 on page 226 depicts the EKMF Web lifecycle. The key actions are:
•Activate: install the key in the keystore first time.
•Restore: will ensure key is in all defined keystores.
•Deactivate: removes the key from all keystores.
•Compromised: marks the key as compromised.
•Destroy: removes permanently the key from EKMF Web Centralized Key repository.
Figure 10-9 Key lifecycle
Generate key
The template is the basis for any key generation. A key can be generated from the template (Figure 10-10) or from an existing key (Figure 10-11).
Figure 10-10 Generate key from template view
When generating a key, the base naming convention and key characteristics are set by the key template. Based on the template definition, you can create tags that can be changed each time a key is generated.
Figure 10-11 Generate key from existing key
The following example (Figure 10-12 on page 227) shows a cipher key with an active period of one (1) year starting today that will be created in pre-activation state to be installed in the TEC2MVS keystore.
The inputs allowed are the application ID and the sequence number. EKMF Web provides a recommendation on the next available sequence number.
Figure 10-12 Key creation example
Activate key
Key activation means that the key will be installed into the key stores defined by the template. This can be done upon generation, or, if a key is generated in the pre-activation state, it can be done in the key view.
The pre-activation state provides the ability to have separation of duties where a key custodian can have ability to generate key but is not allowed to install it in key stores. Figure 10-13 shows a screen shot of a key in pre-activation st ate, and how to install it into the keystore(s).
To load a key into the keystore, you must first select (1) Change state and (2) then select the ACTIVE option.
Figure 10-13 Key activation
Deactivate
When a key is deactivated it is removed from the keystore. The key, however, is not deleted from EKFM Web key repository so it can be reactivated or reinstalled.
If you uninstall a key, it will be uninstalled from keystores it was distributed to and it can be restored upon request. The key can stay active though. If you deactivate a key, it will uninstall the key as well.
To deactivate a key you can select change state for key and click deactivate or you can click “Uninstall” as indicated in the screen shown in Figure 10-14.
Figure 10-14 Key deactivation (uninstall)
To reactivate or restore a missing key from a keystore, you can either change the state of the key to ACTIVE or restore the key as shown in Figure 10-15. This will restore the key into the key store defined in template.
Figure 10-15 Key restore
Compromise and destroy
A key can be marked as compromised or can be destroyed in any state. Note that once a key is marked as compromised it can never be changed to uncompromised (to be reused).
A compromised key can only be destroyed. Once a key is destroyed, it is removed from the EKMF Web Centralized Key repository and cannot be recovered. As such, all data encrypted with a key which has been destroyed should be considered cryptographically erased.
10.3.7 Key rotation
Rotating a data set encryption key starts with creating a new key to replace the old.
EKMF Web has a function called 'Generate Again'. This function allows generation of a new key based on the parameters of an existing key. At the end of each row of keys in the key list overview, there is a menu symbolized by three dots, arranged vertically.
To generate a key again, find the key in the key list overview and open the menu for the key and select 'Generate Again' (as shown in Figure 10-16).
Figure 10-16 Re-generating key
This will start a key generation (see “Key generation with EKMF Web” on page 125) with the key template and values for key label tags pre-filled based on the values used for the selected key. The key label tag <seqno> will be incremented to the next available key sequence number, to make the key label unique
Complete the key generation, then return to z/OS to complete the key rotation, as described in 7.2.2, “Rotating data set encryption keys” on page 160.
|
Note: For users of the EKMF workstation, the corresponding function is called 'renew key', which is available from functions menu and the right click context menu for a key in the key list overview.
|
10.4 EKMF Web view of data sets
EKMF web provides a dashboard view of data sets on the system. To archive this, EKMF Web provides two JCL jobs:
•The first job reads the master catalog to create a detailed extract of datasets on system.
•The second job takes this extract and loads into Db2.
These jobs should be run on each LPAR (z/OS image) at an interval which is agreed upon by the business. Once a day should be sufficient for most reporting requirements.
In EKMF Web you can review results by going to the dashboard found in the datasets tab. Datasets are viewed at sysplex level. You can refine the search by specifying:
•Creation after date
•Data set state
•Data set name
•Key label
Figure 10-17 provides a view of the data sets and their encryption status.
Figure 10-17 Data set view
Additional details for individual data sets can be viewed by clicking on the data set name. Figure 10-18 on page 231 provides detailed view of a data set (EKMFWEB.DATA.LAB01). The data set is identified as “encryptable”. However, the Reason provided at the bottom of the screen informs that, to enable encryption, this data set needs to be changed prior to allocating a key label.
Figure 10-18 Data set view - unencrypted data set
Figure 10-19 shows an encrypted data set (EKMFWEB.DATA.LAB02ENC). For an encrypted data set, the associated key label is also shown. You can also click on the encryption key label. If the corresponding key is under EKMF Web control, you will be able to see further details.
Figure 10-19 Encrypted data set view
10.5 Summary
This chapter covers the basics of EKMF Web and the capabilities it has for key management lifecycle. NIST 800-57 defines the capabilities need for a key manager which was incorporated into the design. There are deeper topics that can be explored such as the roles/responsibilities, EJBROLE definitions for key management function authorizations, availability design, and audit.
For additional details refer to EKMF documentation.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.