Available to:
All roles
Procedures:
From the System Management menu, select KMA List. See "Filtering Lists" to filter the list.
KMA List - Field Definitions
Version of the KMA software. For OKM 3.0 KMAs, the version string shows the following format: <OKM release>-5.11-<OKM build>. For example, 3.0.0-5.11-2012.
Indicates whether the KMA is running. The values shown indicate whether each of the KMAs listed (that is, the remote KMAs) are responding to requests from the local KMA.
True — KMA is responding to requests from the local KMA.
False — Remote KMA is not responding to requests, perhaps because the remote KMA is down or the communications link to the remote KMA is down.
Indicates whether the KMA is responding on the service network. The values indicate whether each of the KMAs listed (that is, the remote KMAs) are responding to requests from the local KMA. Possible values are:
Responding — Remote KMA is responding to requests from the local KMA.
Not Responding — Remote KMA is not responding to requests, perhaps because the remote KMA is down or the communications link to the remote KMA is down. If the local KMA has configured a default route, then it is considered to have a route to remote KMAs. Other KMAs are shown as "Not Responding" if they do not respond on the service network.
Not Accessible — Remote KMA is not accessible to the local KMA, perhaps because the service network configuration does not provide a default or static route to that KMA. If a default or static route is not defined, then other KMAs may be shown as "Not Accessible." Older KMAs (OKM 2.3.x or earlier) are shown as "Responding."
Time (in milliseconds) the KMA takes to respond to a request on its management network. This is typically a few hundred milliseconds. It can be larger if a WAN connection exists between the local KMA and a remote KMA or if the communications link between KMAs is busy.
Number of updates before replication takes place. This number should be zero or a small value. Larger values indicate that replications are not completing in a timely manner, the communications link between KMAs is down or busy, or a remote KMA is down. This value will also be very large when a new KMA has just been added to the cluster.
Percentage of unallocated keys that are ready.
Percentage of the Key Pool that has been backed up. N/A indicates that the KMA cannot determine this value, because either the KMA runs down-level software or it is currently using a lower Replication Version.
If true, the KMA is locked. N/A indicates that the KMA cannot determine this value, because either the KMA runs down-level software or it is currently using a lower Replication Version.
If true, the KMA has successfully been added or logged into the cluster. This value is False when the KMA is first created and will change to True once the KMA has logged into the cluster. It can also be False when the KMA passphrase is changed. Once a KMA has logged in, the passphrase used to log in can no longer be used. The passphrase must be changed before the KMA can log in to the cluster again.
Status of the hardware security module. Possible values:
Unknown The KMA is running a software release older than KMS 2.2.
Inactive The KMA currently does not need to use the hardware security module, typically because the KMA is locked.
Software The hardware security module is not functional, and the KMA is using the software provider to generate keys.
Hardware The hardware security module is functional, and the KMA is using it to generate keys.
SW Error/HW Error The KMA encountered an error when it tried to query the status of the software provider (SW Error) or the hardware security module (HW Error).
Note:
Normally, the hardware security module is functional (Hardware). However, if the hardware security module becomes non-functional (Software) and the FIPS Mode Only security parameter is set to Off (see "Review and Modify the Cluster Security Parameters"), then the KMA switches to using the software provider to generate keys.If the hardware security module becomes non-functional and the FIPS Mode Only security parameter is set to On, then the KMA cannot generate keys or return AES wrapped key material to agents.
If the value is Software, SW Error, or HW Error, check the hardware security module on this KMA (see "Check the Hardware Security Module").
Not Present The hardware security module is not present and the KMA is using the software provider to generate keys.
Available to:
Security Officer (requires a quorum)
Procedures:
From the System Management menu, select KMA List. Click Create...
Enter the following within the General tab:
KMA Name — Uniquely identifies the KMA in a cluster (can be between 1 and 64 characters).
Description — Describes the KMA (can be between 1 and 64 characters)
Site ID — The site that the KMA belongs to (optional)
Click the Passphrase tab, and then enter the passphrase for the user. See "Passphrase Requirements".
Click Save.
Creating a KMA requires a Quorum. Within the Key Split Quorum Authentication dialog, the quorum must type their usernames and passphrases to authenticate the operation. See "Key Split Quorum Authentication" for more information.
Run the QuickStart program on the KMA(s) you created so that they can join the cluster. For procedures on joining a cluster, refer to "Join an Existing Cluster".
Available to:
Security Officer (requires a quorum)
All other roles (can view only)
Procedures:
From the System Management menu, select KMA List. Double-click a KMA entry (or highlight a KMA entry and click Details...).
Modify the information as required.
Click Save.
Modify KMA details requires a quorum. Within the Key Split Quorum Authentication dialog, the quorum must type their usernames and passphrases to authenticate the operation. See "Key Split Quorum Authentication" for more information.
Note:
You must not be connected to the KMA that you want to change the passphrase on.If you set the passphrase of a KMA that has been added to this cluster, this KMA is now effectively logged out of the cluster. This means that it cannot propagate information to peer KMAs in this cluster. To log this KMA back into the cluster, see "Log the KMA Back into the Cluster".
Available to:
Security Officer (requires a quorum)
Procedures:
From the System Management menu, select KMA List. Double-click the KMA entry (or highlight a KMA entry and click Details...).
Click the Passphrase tab and modify the passphrase. Confirm the passphrase (retype the same passphrase). The phrase must meet the requirements listed in "Passphrase Requirements".
Click Save.
Within the Key Split Quorum Authentication dialog, the quorum must type their usernames and passphrases to authenticate the operation. See "Key Split Quorum Authentication" for more information.
Using the Console on the KMA with the changed passphrase, select the function to log the KMA into the cluster. The KMA is not able to communicate with the cluster until it is logged back in
If the KMA has been logged out of the cluster for at least a few hours, then lock the KMA before logging the KMA back into the cluster. After recent updates have been propagated to this KMA, as shown by the Replication Lag Size in the KMA List panel, unlock the KMA.
Refer to the following topics for detailed information: "Lock/Unlock the KMA".
Normally, you would only use this command to delete a failed KMA from the cluster. However, you can also use this command to remove a KMA that is being decommissioned.
Available to:
Security Officer
Procedures:
Before deleting a KMA, take it offline using the Console "Shutdown KMA" function. If you fail to do this, the KMA continues to function outside of the cluster and sends "stale information" to agents and users.
From the System Management menu, select KMA List. Highlight the KMA you want to delete, and then click Delete.
Confirm the deletion.
The system removes any entries associated with the KMA and not used by any other entity. If you want a deleted KMA to rejoin a cluster, you must reset the KMA to the factory default and select option 2 from the QuickStart program.
Available to:
All roles
Procedures:
From the System Management menu, select KMA Performance.
Rate values — The rate at which this KMA processed these requests within the selected time period. They are expressed as the average rate of these requests extrapolated over the selected rate display interval unit of time (for example, extrapolated average number of key requests per day). If you set the rate display interval to "entire time period," then the panel instead displays the count of requests this KMA processed within the selected time period.
Processing times — The average time in milliseconds this KMA has taken to process the requests issued within the selected time period. These processing times are from the perspective of the KMA and describe the amount of time required to process requests internally. They do not include transmission times over the network or the amount of time required to establish an SSL connection.
The OKM cluster must use replication version 15 or later before request processing times are available.
Server Busy — information about Server Busy conditions that the local KMA encountered within the selected time period. This condition indicates that other OKM threads are currently accessing OKM information in a local database and can occur during long-running OKM operations (such as OKM backups).
Click Details... (or double-click a KMA) to display performance information about that KMA.
Available to:
Backup Operator (can modify)
All other roles (can view)
Procedures:
From the System Management menu, select KMA List.
Click Modify Key Pool Size.
Enter the new Key Pool size. Click Save.
A locked KMA can not unwrap the Root Key Material, and thus is unable to access the data unit keys. As a result, the KMA is unable to service agent requests to register new data units or retrieve data unit keys for existing data units.
An unlocked KMA can use the Root Key Material to access the data unit keys and service agent requests for data unit keys.
Available to:
Security Officer (unlocking requires a quorum)
Procedures:
In the left navigation menu, expand System Management, expand Local Configuration, and then select Lock/Unlock KMA.
Click Lock KMA or Unlock KMA.
Unlocking the KMA requires a quorum. Within the Key Split Quorum Authentication dialog, the existing quorum must type their usernames and passphrases to authenticate the operation. See "Key Split Quorum Authentication" for more information.
In the left navigation menu, expand System Management, expand Security, expand Core Security, and then select Autonomous Unlock Option.
Click either Enable Autonomous Unlock or Disable Autonomous Unlock.
You must provide a quorum to enable or disable the Autonomous Unlock Option.
This change requires a Quorum. Within the Key Split Quorum Authentication dialog, the existing quorum must type their usernames and passphrases to authenticate the operation. See "Key Split Quorum Authentication" for more information.
Available to:
All Roles
Procedures:
In the left navigation menu, expand the Local Configuration menu, select Software Upgrade.
View the version in the Current Replication Version column.
Upgrading software requires two separate phases:
The Operator uploads a software upgrade file to the KMA and immediately applies the upgrade. See "Upload and Apply Software Upgrades".
The Security Officer activates the inactive software version the Operator uploaded and applied. See "Activate a Software Version".
Software updates are signed by Oracle and verified by the KMA before they are applied.
Use a GUI release that matches the version you want to load on the KMA(s). 2.x GUIs cannot activate a software version on an 3.0.x KMA. Install and use an 3.0.x GUI before uploading or activating a software version on an 3.0.x KMA.
You cannot upgrade OKM 2.x KMAs to 3.0.x. You must upgrade KMAs running KMS 2.1 or earlier to 2.2 before upgrading to OKM 2.3 and later.
What to do if the upgrade process is really slow
The upload and apply process can be lengthy if the OKM Manager is remotely connected to the KMA or if the connection between the OKM Manager and KMA is slow. To mitigate this, the software upgrade file can be downloaded to a laptop or workstation that has the OKM Manager installed and the laptop or workstation connected to the same subnet as the KMA. The presence of a router between the OKM Manager and the KMA may slow down the upgrade process.
The upload and apply processes, with a good connection between the OKM Manager and the KMA, optimally take about 30 minutes. The activate process optimally takes about 5 to 15 minutes. If the uploading process is very slow, try connecting to the same subnet as the KMA.
Upload and apply the software upgrade file on each KMA one at a time (to help to spread out the network load), and then activate the software upgrade on each KMA one at a time (to minimize the number of KMAs that are offline concurrently).
If any of the upgrade processes fails (upload, verify, apply, activate, switch replication version), the OKM Manager generates audit messages describing the reason for the failure and a suggested solution.
Note:
Since the upload process adds some traffic to the network, you may not want to upload KMAs simultaneously in a busy cluster.Available to:
Operator
Procedures:
Before upgrading, backup your system (see to "Create a Database Backup").
Download the software upgrade file, and save it to a location accessible to the OKM Manager GUI.
From the Local Configuration menu, select Software Upgrade.
Click Browse, and locate the upgrade file.
Click Upload and Apply.
Available to:
Security Officer
Procedures:
Verify the Operator has uploaded the correct software version. For OKM 3.0.x KMAs, the version string has the following format: <OKM release>-5.11-<OKM build>. For example, 3.0.0-5.11-2027.
For OKM 3.0.x KMAs, the Software Upgrade screen displays software versions in reverse chronological order. That is, the newest version appears at the top of the list. Check the Active column to see which version is active.
Before activating software, ensure there is a current backup of the OKM cluster.
In the left navigation menu, expand System Management, expand Local Configuration, and then select Software Upgrade.
Select the new version, and then click Activate.
Note:
The KMA restarts as part of the activate process. Since the KMA is offline while it restarts, you may not want to activate KMAs simultaneously in a cluster.Software activation requires a quorum. Within the Key Split Quorum Authentication dialog, the quorum must type their usernames and passphrases to authenticate the operation. See "Key Split Quorum Authentication" for more information.
The Technical Support account is disabled on the upgraded KMAs, and the accounts must be reenabled if needed.
Some features in the current software version are available only when the OKM cluster replication version is set to the highest value supported by that software version. The Security Officer can manually set the Replication Version. OKM never changes the versions automatically.
Available to:
Security Officer
Procedures:
Log in to a KMA that has been activated. In the left navigation menu, expand System Management, expand Local Configuration, and then select Software Upgrade.
If the Supported Replication Versions column includes a higher version than the Current Replication Version column, click Switch Replication Version.
Select a new replication version, and click OK.
A successful replication switch is sent to all other KMAs in the OKM cluster.
Note:
All KMAs in the cluster should be responding and all KMAs must run a KMS or OKM version that supports the replication version that the Security Officer wants to set.Table 10-1 summarizes the features that require a particular replication version (or higher) across the KMS and OKM releases.
Table 10-1 Replication Versions/Features
| Replication Version | KMS/OKM Version | Features Enabled |
|---|---|---|
|
8 |
2.0 |
Everything related to initial release |
|
9 |
2.0.2 |
Keys In Backup (ready keys appear in backups) |
|
10 |
2.1 |
IPv6 addresses AES Key Wrap (FIPS Mode) |
|
11 |
2.2 |
ICSF integration Distributed Quorum SNMP Protocol version 2c |
|
12 |
2.3 |
Accelerate initial updates |
|
13 |
2.4 |
Agent Roaming |
|
14 |
2.5.2 |
Allow Agents to revoke keys |
|
15 |
3.0 |
Processing times available in performance reports |
|
16 |
3.3.2 |
Renew Root CA Certificate Acceptable TLS Versions SNMPv2 Community String |
Available to:
All roles
Procedures:
In the left navigation menu, expand System Management, expand Local Configuration, and then select Network Configuration.
This shows network configuration for the KMA you are currently connected to.
Network Configuration - Field Descriptions
Displays whether the related information applies to the Management or Service Network Address.
The Management or Service Network Hostname established in the QuickStart program.
The IP address of the Management or Service Network.
The Subnet Mask address for the Management or Service Network.
One or more DNS name servers (if any) used by this KMA.
The DNS domain (if any) used by this KMA.
An indication whether these DNS settings were configured implicitly by DHCP.
When the Oracle Key Manager GUI is connected to an OKM 3.0 KMA, the Network Configuration Panel does not show the DNS Configured by DHCP check box. QuickStart displays DNS information acquired by DHCP, but the user must enter static DNS information or disable it entirely, as described in "QuickStart Network Configuration Task 5: Set DNS Configuration (Optional)". Thus, the DNS Configured by DHCP check box does not appear.
Indicates whether the Management or Service Network uses DHCP.
The subnet that network traffic goes to from this KMA.
The Gateway IP address that network traffic is routed to for the Management or Service Network.
Indicates whether the Gateway configuration is modifiable. Gateways that are configured automatically are not modifiable.
The security officer can set the system clock. To ensure the correct operation of the OKM solution, it is very important to maintain the times reported by each KMA in a cluster within five minutes of each other. You can provide an IPv6 address for an external NTP server.
You can only adjust a KMA clock once a day by a maximum of plus or minus 5 minutes. A positive (+) adjustment slowly moves the clock forward, whereas a negative (-) slowly moves the clock backward.
Available to:
Security Officer
All other roles (can only view the system time)
Procedures:
In the left navigation menu, expand System Management, and then select System Time.
To change the time, click Adjust Time.
Select the "Move System Time Forward (+)" or "Move System Time Backward(-)".
In the Offset Minutes text box, select a numeric value.
In the Offset Seconds text box, select a numeric value.
Note:
If the specified offset is too large, you will receive an Error message. Click OK and enter a new value.To sync to an NTP server, click Specify NTP Server. Enter the IPv6 address (must not include square brackets or a prefix length).
It is possible that an existing KMA in a cluster may contain a failed hardware security module. To identify a failed card, examine the rear of the KMA server and check the LEDs on the card.
A functional SCA 6000 card on a KMS 2.1, KMS 2.2, or OKM 2.3 and later KMA that has been initialized through the QuickStart program displays a flashing green Status LED (identified with an S) and solid green FIPS (F) and Initialized (I) LEDs.
If the Status LED is not flashing green and the FIPS and Initialized LEDs are not solid green, then the KMA has a faulty SCA 6000 card, which must be replaced if FIPS mode is required.
See the SCA 6000 User Guide for a description of the LEDs on an SCA 6000 card.
Checking a nCipher nShield Solo Module
An existing SPARC KMA in a cluster may contain a failed nCipher nShield Solo module. To identify a failed nCipher module, examine the rear of the KMA server and check the Status LED on the nCipher module.
A functional nCipher nShield Solo module on an OKM 3.3 or later KMA that has been initialized through the QuickStart program displays a solid-blue Status LED that blinks occasionally.
If the Status LED displays a different pattern, contact Oracle Support.
A Site is a physical location with at least one KMA, to which several agents (hosts and OKM cluster) connect. Sites allows agents to respond to KMA failures or load balancing more effectively by connecting to another KMA in the local Site rather than a remote one
Available to:
Operator
Security Officer
Procedures:
In the left navigation tree, expand System Management, and then select Site List. See "Filtering Lists" to filter the list.
Available to:
Security Officer
Procedures:
In the left navigation tree, expand System Management, and then select Site List. Click Create...
Enter the following:
Site ID — Uniquely identifies the site. This value can be between 1 and 64 (inclusive) characters.
Description — Uniquely describes the site. This value can be between 1 and 64 (inclusive) characters.
Click Save.
Available to:
Security Officer
All other roles (can view only)
Procedures:
In the left navigation tree, expand System Management, and then select Site List. Click Details...
Change the Description field.
Click Save.
Note:
If the site is in use, that is, agents or KMAs are specified to be at the site, you must delete or change them to a different site before you can delete the site.Available to:
Security Officer
Procedures:
In the left navigation tree, expand System Management, and then select Site List.
Highlight the site to delete, and then click Delete.
Confirm the deletion by clicking Yes.
Available to:
Compliance Officer
Operator
Procedures:
From the Agents menu, select Agent List. Select a key group from the drop-down menu. See "Filtering Lists" to filter the list.
Agent List - Field Descriptions
The user-specified unique identifier that distinguishes each agent.
Describes the agent.
Unique identifier that indicates the Site to which the agent belongs.
The key group associated with all keys created by this agent if the agent does not explicitly specify a different key group.
Indicates the status of the agent. Possible values are True or False. If this field is False, the agent cannot establish a session with the KMA.
The number of failed login attempts.
Indicates whether the agent has enrolled successfully with the OKM cluster. Possible values are True or False. This field is False if the agent is the first created or if the agent's passphrase is changed.
Available to:
Operator
Procedures:
From the Agents menu, select Agent List. Click Create...
On the General tab, complete the following:
Agent ID — Uniquely identifies the agent (can be between 1 and 64 characters).
Description — Describes the agent (can be between 1 and 64 characters).
Site ID — Select a site from the drop-down list. This field is optional.
One Time Passphrase (checkbox) — If selected, the agent cannot retrieve its X.509 certificate without resetting its passphrase and re-enrolling with its agent ID and new passphrase. This is the default.
If unselected, then the agent can retrieve its X.509 certificate at any time, use CA and certificate services, and successfully authenticate through its agent ID and passphrase.
Tape drive agents should specify the default value. PKCS#11-type agents will find this setting to be more convenient, especially in cluster configurations where users may authenticate to the OKM from multiple nodes.
Default Key Group ID — If you also have Compliance Officer privileges, click the down-arrow and highlight the default key group. You should define a default key group so that this agent can use keys in this key group to encrypt and decrypt data. See "Assign Key Groups to an Agent" for instructions on how to enable this agent to use keys in other key groups to decrypt data (read only).
On the Passphrase tab, enter a passphrase. For requirements, see "Passphrase Requirements".
Click Save.
Complete the agent-specific enrollment procedure using the agent-specific interface. For example, for StorageTek drives, you must use the VOP (Virtual Operator Panel) to complete the enrollment procedure.
Available to:
Operator
Procedures:
From the Agents menu, select Agent List.
Select an agent from the list, and then click Details... (or double-click the agent).
Modify the fields, as required (see "Create an Agent" for field definitions).
Note:
Do not change the passphrase unless you believe it is compromised (see "Set an Agent's Passphrase" for more info).When finished, click Save.
When you set an agent's passphrase, you are effectively revoking the agent certificate that enables the agent to authenticate itself with the KMA. As the Operator, you may want to set an agent's passphrase certificate if you believe that the agent certificate and/or passphrase has been compromised.
Available to:
Operator
Procedures:
From the Agents menu, select Agent List.
Select an agent from the list, and then click Details... (or double-click the agent).
On the Passphrase tab, modify the passphrase.
Click Save.
Re-enroll the agent using the agent-specific procedure. For example, for StorageTek tape drives, the VOP (Virtual Operator Panel) must be used to re-enroll the agent with the OKM cluster. After changing an agent's passphrase, the agent is not able to make requests to the OKM cluster until it is re-enrolled.
Assigning a key group to an agent determines the storage devices the agent can access. This process accomplishes the same result as "Assign Agents to Key Groups".
Available to:
Compliance Officer
Operator (can view-only)
Procedures:
In the left navigation area, expand Agents, and then select Key Group Assignment.
Select an agent in the "Agents" list
Move key groups between the "Allowed Key Groups" or the "Disalowed Key Group" column. To move, highlight the key group, and then click < or > to allow or disallow access.
Note:
You must set a default key group for an agent before that agent can allocate keys.To assign a default key group, select a key group and then click < Default Key Group.
Available to:
Operator
Procedures:
From the Agents menu, select Agent List.
Select the agent you want to delete, and then click Delete.
Click Yes to confirm.
This panel displays performance information about the create key, retrieve key, and register key-wrapping-key requests that have been issued by each agent. This information includes rate or count values and processing times. Import key requests are not included in these values.
Note:
HP and IBM LTO tape drives do not issue create key requests. They issue retrieve key requests instead.Available to:
Operator
Compliance Officer
Procedures:
From the Agents menu, select Agent Performance List. See "Filtering Lists" to filter the list.
Rate values — the rate at which this agent issued these requests within the selected time period. They are expressed as the average rate of these requests extrapolated over the selected rate display interval unit of time (for example, extrapolated average number of Create Key requests per day). If you set the rate display interval to "entire time period," then this panel instead displays the count of requests this agent issued within the selected time period.
Processing times — the average time in milliseconds taken to process the requests that this agent has issued within the selected time period. These processing times are from the perspective of the KMA and describe the amount of time required to process requests internally. They do not include transmission times over the network or the amount of time required to establish an SSL connection. The OKM cluster must use replication version 15 or later before request processing times are available.
To display more information about an agent, select an agent and click the Details button (or double-click an agent).
Data units represent data that is encrypted by agents. For tape drives, a data unit is a tape cartridge. Data units are secured by valid key policies that are associated with their key groups. Agent must have access to the selected data unit.
Note:
An Operator can perform all functions except modify a data unit's key group. Only a Compliance Officer can modify a data unit's key group.Available to:
Operator
Compliance Officer
Procedures:
From the Data Units menu, select Data Unit List. See "Filtering Lists" to filter the list.
Data Unit List Field Descriptions
System-generated unique identifier that distinguishes each data unit.
Unique external identifier for the data unit.
This value is sent to the OKM by the agent and may not be externally visible to an end user. For LTO Gen 4 and Gen 5 tapes, this is the cartridge serial number burned into the cartridge when it is manufactured. Do not confuse this value with a volser on an optical barcode or in an ANSI tape label. This value is not used for StorageTek tape drives.
Describes the data unit.
Unique external tag for the data unit.
For tapes that are in a StorageTek tape library, or tapes that have ANSI standard labels, this field is the volser. If the tape is in a library and has an ANSI label, the library volser (that is, optical bar code) is used if it differs from the volser contained in the ANSI label. For tapes written in stand-alone drives without ANSI labels, this field is blank.
Note:
For data units written by LTO Gen 4 and Gen 5 tape drives, this field is padded on the right with blanks to fill in 32 characters. It may be more convenient for you to use the "Starts With ~" filter operator instead of the "Equals =" filter operator, so that you do not have to add the blanks to pad the External Tag. For example, if you use the "Starts With" filter, you could enter: "External Tag" ~ "ABCDEF". If you use the "Equals" filter for the same example, you would need to enter: "External Tag" = "ABCDEF " (padded to fill 32 characters)Date and time when the data unit was created/registered.
If true, the keys associated with this data unit have been exported.
If true, the keys associated with this data unit have been imported.
State of the data unit. Possible values are:
No Key: Set when the data unit has been created, but has not yet had any keys created.
Readable: Set when the data unit has keys that allow at least some parts of the data unit to be decrypted (read).
Normal: Set when the data unit has keys that allow at least some parts of the data unit to be decrypted (read). In addition, the data unit has at least one protect-and-process state key that can be used to encrypt data. The data unit is therefore writable.
Needs Re-key: Set when the data unit does not have at least one protect-and-process state key. Data should not be encrypted and written to this data unit until the data unit is rekeyed and a new, active key is assigned to it. It is the responsibility of the agent to avoid using a key that is not in protect-and-process state for encryption. The data unit may have keys that are in process only, deactivated, or compromised state. A key in any of these three states can be used for decryption.
Shredded: Set when all of the keys for this data unit are destroyed. The data unit cannot be read or written. However, a new key can be created for this data unit, moving its state back to Normal.
Available to:
Operator
Compliance Officer (can view and only modify Key Group and Compromise keys)
All other roles (view-only)
Procedures:
From the Data Units menu, select Data Unit List.
Select a data unit, and then click Details...
On the General tab, modify the information as required.
IMPORTANT:
If the Description field contains the string "PKCS#11v2.20," this represents a special key used for Oracle Database Transparent Data Encryption (TDE). Do not change this field. Doing so can alter the way OKM interacts with TDE.Click Save.
Available to:
All roles
Operator (can change In Use By Data Unit checkbox)
Procedures:
From the Data Units menu, select Data Unit List.
Select a data unit, and then click Details...
Click the Key List tab (see below for a description of field).
Select a key, and then click Details...
If the Replication Version is at least 14, the Operator can change the In Use By Data Unit check box that indicates the relationship between this key and its associated data unit. Selecting this check box can help when a key policy that is used by tape drive agents is inadvertently updated to enable its Allow Agents To Revoke Keys attribute. See "View Key Policies" for a description of this attribute.
Key List - Field Descriptions
Uniquely identifies the data unit.
Describes the data unit.
Key information for the data unit.
The type of encryption algorithm that this key uses. The only possible value is AES-256.
Date and time when the key was created.
Date and time when the key was activated. This is the date and time when the key was first given to an agent. It is the starting date and time for the key's encryption period and cryptoperiod.
Date when the key was destroyed. If the field is blank, then the key is not destroyed.
User-supplied information about the destruction of the key. If the field is blank, then the key is not destroyed.
If true, the key has been exported.
If true, the key has been imported.
If true, the Key has been derived from a Master Key generated by the Master Key Provider. Refer to the "OKM-ICSF Integration" for detailed information.
If true, the key(s) associated with the data unit has been revoked by an agent. See "Modify a Key Policy".
If the KMA to which the OKM GUI is connected runs OKM 2.5.2 or higher but the OKM cluster currently uses Replication Version 13 or earlier, then this attribute is shown as "(Unknown)."
Key group associated with the data unit.
Date and time when the key will no longer be used or was stopped from being used for encrypting data.
Date and time when the key will be or was deactivated.
Date when the key was compromised. If the field is blank, then the key is not compromised.
User-supplied information about compromising the key. If the field is blank, then the key is not compromised.
Data unit's key state. Possible values are:
Generated — Set when the key 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, the key remains generated until it has been recorded in at least one backup.
Ready — Set when the key has been protected against loss by replication or a backup. A ready key is available for assignment.
Protect and Process — Set when the key has been assigned when an encryption agent requests a new key be created. A key in this state can be used for both encryption and decryption.
Process Only — Set when the key has been assigned but its encryption period has expired. A key in this state can be used for decryption but not for encryption.
Deactivated — Set when the key has passed its cryptoperiod but may still be needed to process (decrypt) information.
Compromised — Set when the key has been released to or discovered by an unauthorized entity. A key in this state can be used for decryption but not for encryption.
Incompletely Destroyed — Set when the key has been destroyed but it still appears in at least one backup.
Completely Destroyed — Set when all of the backups in which the destroyed key appears have been destroyed.
Compromised and Incompletely Destroyed — Set when the compromised key still appears in at least one backup.
Compromised and Completely Destroyed — Set when all of the backups in which the compromised key appears have been destroyed.
Indicates whether the key has been linked to the data unit by a recovery action. This condition occurs when a key is used for a data unit by one KMA in a OKM cluster and then, due to a failure, the key is later requested for the data unit from a different KMA. If the failure (such as a network outage) has prevented the allocation of the key to the data from being propagated to the second KMA, the second KMA creates the linkage to the data unit. Such a key is "recovery activated," and an administrator may want to evaluate the system for KMA or network outages. Possible values are True and False.
A data unit cannot be considered "completely destroyed" until you destroy all backups containing the data unit key(s). To view backups that contain destroyed keys:
Available to:
Operator
Compliance Officer
Procedures:
From the Data Units menu, select Data Unit List.
Select a data unit, and then click Details...
Click the Backups with Destroyed Keys List tab.
How OKM Determines if a Backup Contains a Data Unit Key
A backup contains a data unit key if the backup occurred after creating the data unit key but before destroying the data unit key.
The clocks of various KMAs in a cluster might not be synchronized (if an NTP server is not specified). To account for the possible time discrepancies , OKM uses a fixed five minute backup time window when comparing date-times.
The backup time window minimizes falsely reporting that a data unit does not exist in a particular backup when in fact it does. Such a case is known as a "false negative" and seriously undermines compliance requirements for data destruction. Unlike "false negatives," "false positives" do not undermine compliance requirements for data destruction, hence the five minute window.
From the Data Units menu, select Data Unit List.
Select a data unit in the list, and then click Destroy Keys.
Specify the keys to destroy:
Deactivated keys — Select this check box if you want to destroy the keys that have passed their cryptoperiod but still may be needed to process (decrypt) data information.
Compromised keys — Select this check box if you want to destroy the keys that have been released to or discovered by an unauthorized entity.
Type a comment about the destruction of these keys.
Click Destroy. Click Yes to confirm.
Available to:
Operator
Compliance Officer
Procedures:
From the Data Units menu, select Data Unit List. Click Key Counts. By default, the display shows all data units associated with more than one key. See "Filtering Lists" to filter the list.