Hardware Key Lifecycle Management (HKLM) in IBM Z is the end-to-end management of cryptographic keys entirely in hardware and tightly controlled system services, covering how keys are:

generated → stored → protected → distributed → used → rotated → revoked → destroyed

The key idea is that keys are never exposed in plaintext to applications or general-purpose memory. They remain protected inside secure hardware boundaries throughout their lifecycle.

1. Core idea

Hardware Key Lifecycle Management ensures cryptographic keys are created, stored, and used inside secure hardware (CPACF / Crypto Express / secure enclaves) so they cannot be extracted or tampered with in software form.

2. Why it is needed

Without hardware lifecycle management:

• keys could be copied from memory
• malware or privileged software could extract them
• audit and compliance gaps exist

With HKLM:

• keys are non-exportable or tightly controlled
• usage is hardware-enforced
• lifecycle actions are auditable and policy-driven

3. Where keys live in IBM Z

A. CPACF (on-chip cryptography)

• Fast symmetric key operations (AES, SHA)
• Keys used in encrypted form internally

B. Crypto Express adapters (CEX)

• Secure key storage (especially private keys)
• Supports PKCS#11 and secure key tokens

C. Secure key containers (ICSF)

• Keys wrapped and stored in encrypted form
• Managed by ICSF (Integrated Cryptographic Service Facility)

4. Key lifecycle stages

A. Key generation

• Keys generated inside hardware (preferred)
• Uses strong entropy sources
• Never exposed in plaintext outside secure boundary

B. Key wrapping (protection)

• Keys are wrapped (encrypted) using master keys
• Stored as secure key tokens

👉 Even if extracted, they are useless without master key

C. Key storage

Keys are stored:

• in encrypted form in memory or disk
• inside secure hardware modules

Master keys are stored in:

• Crypto Express secure hardware registers

D. Key distribution

• Keys can be securely shared across sysplex systems
• Always in wrapped (encrypted) form
• Never transferred in plaintext

E. Key usage (most critical step)

When a key is used:

1. key is loaded into hardware secure area
2. decrypted internally (not exposed to OS)
3. used for encryption/decryption operations
4. immediately discarded from working memory

👉 Applications never see the raw key

F. Key rotation

• keys are periodically replaced
• new keys rewrap old data or coexist during transition
• controlled by policy (ICSF / security admin)

G. Key revocation

• compromised or expired keys are invalidated
• CF and crypto services stop accepting them
• access logs are recorded

H. Key destruction

• cryptographic material is securely erased
• master key re-issuance may invalidate all dependent keys
• ensures no recovery from storage

5. Role of ICSF (key manager)

The Integrated Cryptographic Service Facility (ICSF) manages:

• key generation policies
• key storage formats (CKDS, PKDS, TKDS)
• access control rules
• cryptographic APIs for applications

👉 ICSF is the software control plane, but keys stay in hardware-protected form.

6. Master key concept (very important)

IBM Z uses master keys stored in Crypto Express hardware:

• Data keys are wrapped under master keys
• Master keys never leave hardware
• Changing master key can instantly invalidate or rewrap large key sets

👉 This creates a hierarchical trust model

7. Security model

A. Non-exportability

• keys cannot be extracted in usable form

B. Separation of duties

• security admin controls keys
• application only requests usage

C. Tamper resistance

• hardware enforces boundaries

D. Auditability

• all key operations can be logged

8. Impact on performance

Even though security is strong:

• CPACF provides near-native CPU speed encryption
• crypto operations are pipelined in hardware
• key access overhead is minimal

👉 Result: strong security with low performance penalty

9. Relationship to sysplex and CF

In a Parallel Sysplex:

• keys may be shared across LPARs (securely wrapped)
• CF structures can coordinate encrypted data consistency
• DB2 and CICS use shared keys for encrypted data access

10. Simple mental model

Think of hardware key lifecycle management as:

A secure cryptographic ecosystem where keys are born, live, and die entirely inside protected hardware boundaries, with software only requesting their use but never seeing their raw form.

Key takeaway

Hardware Key Lifecycle Management in IBM Z ensures:

• Keys are generated and stored inside secure hardware
• Keys are always protected (wrapped/encrypted)
• Keys are only used inside cryptographic engines
• Keys are rotated, revoked, and destroyed under strict control
• Applications never directly access raw cryptographic keys