Skip Headers
Oracle® Key Manager 3 Administration Guide
Release 3.0
E41579-02
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

1 Introduction

The Oracle Key Manager (OKM) creates, stores, and manages encryption keys. It consists of the following components:

OKM Concepts

The following OKM concepts are discussed:

  • OKM Clusters

  • Agents

  • Network Connections

  • Initial Setup - Direct Connection or Remote Console

  • Initial Setup - QuickStart Program

  • Key Lifecycle

  • State Transition

  • OKM Key States and Transitions

  • Users and Role-based Access Control

  • Data Units, Keys, Key Groups, and Key Policies

OKM Clusters

OKM supports clustering of multiple KMAs, which provides load balancing and failover. All KMAs in a OKM Cluster act in an active/active manner. All KMAs can provide all capabilities to any agent. Actions performed on one KMA are quickly replicated to all other KMAs in the Cluster.

Agents

Agents perform cryptographic operations, specifically, encrypting data as it is written and decrypting data as it is read. Agents contact the OKM Cluster in order to create and retrieve keys used to perform the cryptography.

Network Connections

The OKM uses TCP/IP networking for the connections between KMAs, Agents, and machines where the OKM Manager GUI is running. In order to provide flexible network connections, two interfaces are provided for network connections on the KMA:

  • The management connection, intended for connection to the customer network

  • The service connection, intended for connection to the tape drives.

With production KMA installation, library-specific accessory kits are available that include switches and cables for connecting to the drives and the KMA. This is shown in Figure 1-1.

Figure 1-1 Connections to the KMA

Surrounding text describes Figure 1-1 .

Initial Setup - Direct Connection or Remote Console

KMA initial setup is performed through the console connection. This can be done by using a monitor and keyboard connected directly to the KMA or by the remote console function in the Embedded Lights Out Manager (ELOM) or Integrated Lights Out Manager (ILOM). The ELOM or ILOM provides a remote connection to the console allowing you to perform server functions.

The ELOM/ILOM remote console function requires a third network connection, labeled the ”ELOM/ILOM Network” in Figure 1-1. The ELOM's or ILOM's IP address must be configured as described in "Accessing the KMA Through the Service Processor" in order to use the remote console function.


Note:

Most commonly, the ELOM/ILOM Network is actually the same network as the customer network.

Initial Setup - QuickStart Program

When a KMA in the factory default state is powered on, a wizard function called QuickStart runs on the console to perform the initial setup. Once complete, most other functions can be done from the OKM manager GUI. A limited function console interface remains active for a small set of functions.

Key Lifecycle

Keys undergo a lifecycle based on the key policy. The lifecycle imposed by the OKM is based on the NIST 800-57 guidelines. A few additional states are added to deal with nuances of the OKM.

The key lifecycle is based on two time periods defined in the key policies:

  • Encryption period

  • Cryptoperiod

The encryption period is the period after a key is assigned that can be used to encrypt data. The cryptoperiod is the period that can be used for decryption. The two periods start at the same time when the key is assigned.

Figure 1-2 shows the time periods in a key lifecycle.

Figure 1-2 Key Lifecycle Periods

Surrounding text describes Figure 1-2 .

State Transition

The encryption period and cryptoperiod, combined with other functions of the OKM, define a state transition for keys.

Figure 1-3 shows the state transitions. States and transitions shown in blue are defined by NIST 800-57.

Figure 1-3 State Transition Diagram

Surrounding text describes Figure 1-3 .

OKM Key States and Transitions

In Figure 1-3, states and transitions shown in red are added by the OKM. When examining keys in the OKM Manager, only the innermost state is listed. OKM states are listed below.

Pre-activation

This state indicates that the key has generated but is not yet available for use. Within the pre-activation state, the key can take two further states, generated and ready.

Generated

A generated state indicates a key that has been created on one KMA in a OKM Cluster. It remains generated until it has been replicated to at least one other KMA in a multi-OKM Cluster. In a Cluster with only a single KMA, a key must be recorded in at least one backup to transition out of the generated state.

Ready

A ready state indicates that the key has been protected against loss by replication or a backup. A ready key is available for assignment. The ”replicated” transition occurs when the key is replicated or (for a single OKM Cluster) backed up.

Active

This state indicates that the key may be used to protect information (encrypt) or to process previously protected information (decrypt) NIST states that an active key may be designated to protect only, process only, or protect and process. Further, it specifically states that for symmetric data encryption keys, a key may be used for some time period to protect and process information and once this time period expires, the key may continue to be used for processing only.

Within the active state, the OKM adds two substates. These states are described in NIST, but are not specifically identified as states.

Protect-and-process

A key in this state can be used for both encryption and decryption. A key is placed into this state when it is assigned. The assignment is done when an encryption agent requests a new key to be created.

Process only

A key in this state can be used for decryption but not encryption. When an agent determines that none of the keys available to it for a specific data unit that is being read or written are in the protect-and-process state, it should create a new key.

Keys move from the protect-and-process state to the process only state when the encryption period for the key expires.

Deactivated

This state indicates that the key has passed its cryptoperiod but may still be needed to process (decrypt) information. NIST specifically states that keys in this state may be used to process data.

The NIST guidelines state that if post-operational keys, including deactivated and compromised keys, need to remain accessible, they should be archived. This is a key recovery process that allows keys to be recalled from an archive and made available for use.

The OKM provides archives in the form of KMA backups but cannot recall a single key from a backup. Therefore, the OKM retains post-operational phase keys in the OKM Cluster and delivers them upon request from an agent.

Compromised

Keys are in the compromised state when they are released to or discovered by an unauthorized entity. Compromised keys should not be used to protect information, but may be used to process information.

Destroyed/Destroyed Compromised

Destroyed and Destroyed Compromised keys (keys that are compromised before or after destruction) no longer exist. However, information about the key may be retained. Key material from destroyed keys is removed from the OKM Cluster. Destroyed keys will not be delivered to an agent.


Note:

The only way to destroy a key is through the GUI or the management API.

The NIST guidelines do not provide any basis for destroying keys based on time.

Within the Destroyed and Destroyed Compromised states, the OKM defines two substates, incomplete and complete. These states are created because the OKM does not control the backups that it creates. A customer administrator must inform the OKM when a backup has been destroyed. Only after all backups have been destroyed can a key be considered truly destroyed.

Incomplete

This substate indicates that at least one backup still exists that contains the destroyed key. In this substate, the key does not exist in any KMA in the OKM Cluster. Keys in this state cannot be delivered to agents.

Complete

This substate indicates that all backups containing the key have been destroyed. The key does not exist in any KMA, nor in any backup. Strictly speaking, backups that contain the key may well still exist. Although the OKM identifies the backups as destroyed, it is the responsibility of the user to ensure these backups have actually been destroyed.

It is worth noting again that the ”destroyed” transition occurs only as the result of an administrative command. Further, keys may still be delivered to an encryption agent when the key is in the post-operational phase (Deactivated and Compromised states.) This interpretation is consistent with NIST's descriptions for the post-operational phase. The NIST guidelines specify that a post-operational key should be destroyed when it is ”no longer needed.” We believe that only you can determine when a key is ”no longer needed,” so only an external entity can initiate the destroyed transition.

Users and Role-based Access Control

The OKM provides the ability to define multiple users, each with a user ID and passphrase. Each user is given one or more pre-defined roles. These roles are:

  • Security Officer – performs OKM setup and management

  • Operator – performs agent setup and day-to-day operations

  • Compliance Officer – defines Key Groups and controls agent access to Key Groups

  • Backup Operator – performs backup operations

  • Auditor – can view system audit trails

  • Quorum Member – views and approves pending quorum operations.

A Security Officer is defined during the QuickStart process. Additional users may be defined using the OKM Manager GUI after QuickStart is complete.

Allowed Operations for Each Role

Table 1-3 lists the functions for each role. It displays only the allowed operations for the GUI and the console. Although you may see an operation, it may fail when you attempt it. This can occur if roles are removed from a user between the time of display and when the operation is attempted.

All roles except the Auditor's must create a functioning encryption system. A user can have one or multiple roles.

Quorum Protection

The OKM also provides quorum protection for certain operations. You can define a quorum of up to 10 users and a threshold from one to the number of quorum users. This information is called the Key Split Credentials (see "Entering Key Split Credentials").

The user IDs and passphrases are different from the user IDs and passphrases used to log into the system. When you attempt an operation that requires quorum approval, a screen is displayed that allows all quorum users to input their userid and passphrase. At a minimum, you must supply the specified threshold of userids and passphrases for the operation to be allowed.

Data Units, Keys, Key Groups, and Key Policies

Data units are used to represent data that is encrypted by agents. For tape drives, a data unit is a tape cartridge, and data units are always present. This is not a fundamental requirement, and future agents may operate without defining data units.

Keys are the actual key values (key material) and their associated metadata.

Key policies define parameters that govern keys. This includes lifecycle parameters (such as encryption period and cryptoperiod) and export/import parameters (for example, import allowed, export allowed.)

Key Groups associate keys and key policies. Key Groups have a specific key policy and are assigned to agents. Each agent has a list of allowed Key Groups. Agents are allowed to retrieve only the keys that are assigned to one of the agent's allowed Key Groups. Agents also have a default Key Group. When an agent creates a key (more specifically, assigns it to a data unit), the key is placed into the agent's default Key Group. There is functionality in place to allow more sophisticated control of Key Groups by agents. However, existing agents cannot leverage this functionality.

In order for the system to function, at least one key policy and one Key Group must be defined. That Key Group must be assigned as the default Key Group for all agents.

TCP/IP Connections and the KMA

If a firewall exists between the entities (OKM Manager, Agents, and other KMAs in the same Cluster) and the KMA, the firewall must allow the entity to establish TCP/IP connections with the KMA on the following ports:

  • OKM Manager-to-KMA communication requires ports 3331, 3332, 3333, 3335.

  • Agent-to-KMA communication requires ports 3331, 3332, 3334, 3335.

  • KMA-to-KMA communication requires ports 3331, 3332, 3336.


Note:

For users who configure their KMAs to use IPv6 addresses, configure IPv4-based edge firewalls to drop all outbound IPv4 protocol 41 packets and UDP port 3544 packets to prevent internet hosts from using any IPv6-over-IPv4 tunnelled traffic to reach internal hosts.

Refer to your firewall configuration documentation for details. Table 1-1 lists ports KMAs explicitly use or ports at which KMAs provide services.


Table 1-1 KMA Port Connections

Port Number Protocol Direction Description

22

TCP

Listening

SSH (only when Technical Support is enabled)

123

TCP/UDP

Listening

NTP

3331

TCP

Listening

OKM CA Service

3332

TCP

Listening

OKM Certificate Service

3333

TCP

Listening

OKM Management Service

3334

TCP

Listening

OKM Agent Service

3335

TCP

Listening

OKM Discovery Service

3336

TCP

Listening

OKM Replication Service


Table 1-2 shows other services listening at ports that might not be used.

Table 1-2 Other Services

Port Number Protocol Direction Description

53

TCP/UDP

Connecting

DNS (only when KMA is configured to use DNS)

68

UDP

Connecting

DHCP (only when KMA is configured to use DHCP)

111

TCP/UDP

Listening

RPC (KMAs respond to rpcinfo queries). This port is open to external requests only on KMS 2.1 and earlier

161

UDP

Connecting

SNMP (only when SNMP Managers are defined)

546

UDP

Connecting

DHCPv6 (only when KMA is configured to use DHCP and IPv6)

4045

TCP/UDP

Listening

NFS lock daemon (KMS 2.0 only)



Note:

Port 443 must be open to enable customers to access the Service Processor web interface and the OKM Console through the firewall. Refer to the Oracle Key Manager Installation and Service Manual to see ELOM and ILOM ports.

OKM in the Network

Figure 1-4 shows a typical deployment of the OKM solution.

Figure 1-4 Typical Deployment of OKM Solution

Surrounding text describes Figure 1-4 .

OKM Manager Software Requirements

To run the OKM Manager, you need a workstation that runs one of the following:

  • Solaris 10 10/09 (Update 8) x86

  • Solaris 10 9/10 (Update 9) SPARC

  • Solaris 10 9/10 (Update 9) x86

  • Microsoft Windows 7 Business

  • Microsoft Windows 7 Enterprise

  • Microsoft Windows Vista Business

  • Microsoft Windows XP Professional Version 2002

  • Microsoft Windows XP Professional

  • Microsoft Windows Server 2008 Version 6.0

  • Microsoft Windows Server 2003 R2 Standard Edition

  • Microsoft Windows Server 2003

You do not need to have Administrator (on Windows) or root (on Solaris) privileges to install and invoke the GUI.

Using Online Help

The OKM Manager includes comprehensive online help. To display help on any OKM Manager screen,

  • Click the Help button that is located at the top of the panel for general help.

or

  • Navigate to a panel by either pressing the Tab key or by clicking somewhere within the panel. Then, click F1 to view context-sensitive help.

Role-Based Access Control

OKM defines the following roles:

  • Security Officer – manages security settings, users, sites, and Transfer Partners

  • Compliance Officer – manages key policies and Key Groups and determines which agents and Transfer Partners can use Key Groups

  • Operator – manages agents, data units, and keys

  • Backup Operator – performs backups

  • Auditor – views information about the OKM Cluster

  • Quorum Member – views and approves pending quorum operations.

A single KMA user account may be assigned membership to one or more roles. The KMA verifies that the requesting user entity has permission to execute an operation based on the user's role(s). For more information on the roles, refer to "Logging into the KMA".

Role-Based Operations

Table 1-3 shows the system operations that each user role can perform. In the ”Roles” columns, the entries mean the following:

  • Yes – the role is allowed to perform the operation.

  • Quorum – the role is allowed to perform the operation but must also provide a quorum.

  • N/A – means the role is not allowed to perform the operation.

Table 1-3 System Operations/User Roles

Entity Operation Roles
Security Officer Compliance Officer Operator Backup Operator Auditor Quorum Member

Console


Log In

Yes

Yes

Yes

Yes

Yes

Yes


Set KMA Locale

Yes

N/A

N/A

N/A

N/A

N/A


Set KMA IP Address

Yes

N/A

N/A

N/A

N/A

N/A


Enable Tech Support

Yes

N/A

N/A

N/A

N/A

N/A


Disable Tech Support

Yes

N/A

Yes

N/A

N/A

N/A


Enable Primary Administrator

Yes

N/A

N/A

N/A

N/A

N/A


Disable Primary Administrator

Yes

N/A

Yes

N/A

N/A

N/A


Restart KMA

N/A

N/A

Yes

N/A

N/A

N/A


Shutdown KMA

N/A

N/A

Yes

N/A

N/A

N/A


Log OKM into Cluster

Quorum

N/A

N/A

N/A

N/A

N/A


Set User's Passphrase

Yes

N/A

N/A

N/A

N/A

N/A


Reset KMA

Yes

N/A

N/A

N/A

N/A

N/A


Logout

Yes

Yes

Yes

Yes

Yes

Yes

Connect


Log In

Yes

Yes

Yes

Yes

Yes

Yes


Create Profile

Yes

Yes

Yes

Yes

Yes

Yes


Delete Profile

Yes

Yes

Yes

Yes

Yes

Yes


Set Config Settings

Yes

Yes

Yes

Yes

Yes

Yes


Disconnect

Yes

Yes

Yes

Yes

Yes

Yes

Key Split Credentials


List

Yes

N/A

N/A

N/A

N/A

N/A


Modify

Quorum

N/A

N/A

N/A

N/A

N/A

Autonomous Unlock


List

Yes

N/A

N/A

N/A

N/A

N/A


Modify

Quorum

N/A

N/A

N/A

N/A

N/A

Lock/Unlock KMA


List Status

Yes

Yes

Yes

Yes

Yes

N/A


Lock

Yes

N/A

N/A

N/A

N/A

N/A


Unlock

Quorum

N/A

N/A

N/A

N/A

N/A

Site


Create

Yes

N/A

N/A

N/A

N/A

N/A


List

Yes

N/A

Yes

N/A

N/A

N/A


Modify

Yes

N/A

N/A

N/A

N/A

N/A


Delete

Yes

N/A

N/A

N/A

N/A

N/A

Security Parameters


List

Yes

Yes

Yes

Yes

Yes

N/A


Modify

Yes

N/A

N/A

N/A

N/A

N/A

KMA


Create

Quorum

N/A

N/A

N/A

N/A

N/A


List

Yes

N/A

Yes

N/A

N/A

N/A


Modify

Quorum

N/A

N/A

N/A

N/A

N/A


Delete

Yes

N/A

N/A

N/A

N/A

N/A

User


Create

Quorum

N/A

N/A

N/A

N/A

N/A


List

Yes

N/A

N/A

N/A

N/A

N/A


Modify

Yes

N/A

N/A

N/A

N/A

N/A


Modify Passphrase

Quorum

N/A

N/A

N/A

N/A

N/A


Delete

Yes

N/A

N/A

N/A

N/A

N/A

Role


Add

Quorum

N/A

N/A

N/A

N/A

N/A


List

Yes

N/A

N/A

N/A

N/A

N/A

Key Policy


Create

N/A

Yes

N/A

N/A

N/A

N/A


List

N/A

Yes

N/A

N/A

N/A

N/A


Modify

N/A

Yes

N/A

N/A

N/A

N/A


Delete

N/A

Yes

N/A

N/A

N/A

N/A

Key Group


Create

N/A

Yes

N/A

N/A

N/A

N/A


List

N/A

Yes

Yes

N/A

N/A

N/A


List Data Units

N/A

Yes

Yes

N/A

N/A

N/A


List Agents

N/A

Yes

Yes

N/A

N/A

N/A


Modify

N/A

Yes

N/A

N/A

N/A

N/A


Delete

N/A

Yes

N/A

N/A

N/A

N/A

Agent


Create

N/A

N/A

Yes

N/A

N/A

N/A


List

N/A

Yes

Yes

N/A

N/A

N/A


Modify

N/A

N/A

Yes

N/A

N/A

N/A


Modify Passphrase

N/A

N/A

Yes

N/A

N/A

N/A


Delete

N/A

N/A

Yes

N/A

N/A

N/A

Agent/Key Group Assignment


List

N/A

Yes

Yes

N/A

N/A

N/A


Modify

N/A

Yes

N/A

N/A

N/A

N/A

Data Unit


Create

N/A

N/A

N/A

N/A

N/A

N/A


List

N/A

Yes

Yes

N/A

N/A

N/A


Modify

N/A

N/A

Yes

N/A

N/A

N/A


Modify Key Group

N/A

Yes

N/A

N/A

N/A

N/A


Delete

N/A

N/A

N/A

N/A

N/A

N/A

Keys


List Data Unit Keys

N/A

Yes

Yes

N/A

N/A

N/A


Destroy

N/A

N/A

Yes

N/A

N/A

N/A


Compromise

N/A

Yes

N/A

N/A

N/A

N/A

Transfer Partners


Configure

Quorum

N/A

N/A

N/A

N/A

N/A


List

Yes

Yes

Yes

N/A

N/A

N/A


Modify

Quorum

N/A

N/A

N/A

N/A

N/A


Delete

Yes

N/A

N/A

N/A

N/A

N/A

Key Transfer Keys


List

Yes

N/A

N/A

N/A

N/A

N/A


Update

Yes

N/A

N/A

N/A

N/A

N/A

Transfer Partner Key Group Assignments


List

N/A

Yes

Yes

N/A

N/A

N/A


Modify

N/A

Yes

N/A

N/A

N/A

N/A

Backup


Create

N/A

N/A

N/A

Yes

N/A

N/A


List

Yes

Yes

Yes

Yes

N/A

N/A


List Backups with Destroyed Keys

N/A

Yes

Yes

N/A

N/A

N/A


Restore

Quorum

N/A

N/A

N/A

N/A

N/A


Confirm Destruction

N/A

N/A

N/A

Yes

N/A

N/A

Core Security Backup


Create

Yes

N/A

N/A

N/A

N/A

N/A

SNMP Manager


Create

Yes

N/A

N/A

N/A

N/A

N/A


List

Yes

N/A

Yes

N/A

N/A

N/A


Modify

Yes

N/A

N/A

N/A

N/A

N/A


Delete

Yes

N/A

N/A

N/A

N/A

N/A

Audit Event


View

Yes

Yes

Yes

Yes

Yes

N/A


View Agent History

N/A

Yes

Yes

N/A

N/A

N/A


View Data Unit History

N/A

Yes

Yes

N/A

N/A

N/A


View Data Unit Key History

N/A

Yes

Yes

N/A

N/A

N/A

System Dump


Create

Yes

N/A

Yes

N/A

N/A

N/A

System Time


List

Yes

Yes

Yes

Yes

Yes

N/A


Modify

Yes

N/A

N/A

N/A

N/A

N/A

NTP Server


List

Yes

Yes

Yes

Yes

Yes

N/A


Modify

Yes

N/A

N/A

N/A

N/A

N/A

Software Version


List

Yes

Yes

Yes

Yes

Yes

N/A


Upgrade

N/A

N/A

Quorum

N/A

N/A

N/A

Network Configuration


Display

Yes

Yes

Yes

Yes

Yes

N/A

Pending Quorum Operation


Approve

N/A

N/A

N/A

N/A

N/A

Quorum


Delete

Yes

N/A

N/A

N/A

N/A

N/A

Key List


Query

N/A

Yes

Yes

N/A

N/A

N/A


List Activity History

N/A

Yes

Yes

N/A

N/A

N/A

Agent Performance List


Query

N/A

Yes

Yes

N/A

N/A

N/A

KMA Performance List


Query

Yes

Yes

Yes

Yes

Yes

Yes

Current Load


Query

Yes

Yes

Yes

Yes

Yes

Yes


Setting Up and Managing the Key Management Appliance

For procedures on getting your OKM solution installed and configured, refer to the OKM Installation and Service Manual.