The OKM architecture provides for mutual authentication between all elements of the system: KMA to KMA, agent to KMA, and the OKM GUI or CLI to KMA for user operations.

Each element of the system (for example, a new encryption agent) is enrolled in the system by creating an ID and a passphrase in OKM that is then entered into the element to be added. For example, when a tape drive is added to the system, the agent and KMA automatically run a challenge/response protocol based on the shared passphrase that results in the agent obtaining the Root Certificate Authority (CA) certificate and a new key pair and signed certificate for the agent. With the Root CA certificate, agent certificate, and key pair in place, the agent can run the Transport Layer Security (TLS) protocol for all subsequent communications with the KMAs. All certificates are X.509 certificates.

OKM 3.3.2 and above supports X.509v3 certificates. After upgrading to OKM 3.3.2 or later, you can renew the OKM root CA certificate to convert X.509v1 certificates to X.509v3 certificates. For newly configured 3.3.2+ KMAs, all entities will use X.509v3 certificates.

Access control consists of user role-based access and quorum protection.

• Users and Role-Based Access Control
• Quorum Protection

The KMA logs events for operations it performs. Use this log to view potential security violations.

Each KMA logs audit events for operations that it performs, including those issued by agents, users, and peer KMAs in the OKM Cluster. KMAs also log audit events whenever an agent, user, or peer KMA fails to authenticate itself. Audit events that indicate a security violation are noted. A failure to authenticate is an example of an audit event that indicates a security violation. If SNMP Agents are identified in the OKM Cluster, then KMAs also send SNMP INFORMs to these SNMP Agents should they encounter a security violation. If Remote Syslog is configured, then a KMA also forwards these audit messages to configured servers. See Remote Syslog.

A user must properly log in to the OKM Cluster and must have a role assigned to it before it is allowed to view audit events.

KMAs manage their audit events. KMAs remove older audit events based on retention terms and limits (counts). The Security Officer can modify these retention terms and limits as needed.

OKM uses TLS to secure communications.

The communication protocol between an agent and a KMA, a user and a KMA, and a KMA and a peer KMA is the same. In each case, the system uses the passphrase for the entity initiating the communication to perform a challenge/response protocol. If successful, the entity is provided with a certificate and its corresponding private key. This certificate and private key can establish a Transport Layer Security (TLS) 1.0, 1.1, or 1.2 channel.

The TLS protocol version is configurable for the management network and service network. The TLS cipher suite is non-negotiable so KMA client endpoints may not negotiate a weaker suite. Mutual authentication is performed; each end of any connection authenticates the other party. OKM KMAs running OKM 3.1 or later will always use TLS 1.2 for their peer-to-peer replication traffic.

Optionally add a cryptographic card to provide a provide a FIPS 140-2 Level 3 certified cryptographic device.

KMAs can include a Hardware Security Module (HSM), which is ordered separately. OKM release 3.3.3 supports two types of HSMs: the nCipher nShield Solo+ Module and the Entrust nShield SoloXC Module. Either type of HSM can be installed in a SPARC KMA running this release. An Entrust nShield Solo XC Module is not supported in a KMA running an older OKM release.

Te nCipher nShield Solo+ HSM has been FIPS 140-2 Level 3 certified and provides Advanced Encryption Standard (AES) 256-bit encryption keys. Check the NIST site for certification status or contact Oracle as firmware levels change over time. The HSM supports a FIPS 140-2 Level 3 mode of operation and OKM always uses the HSM in this manner. When an HSM is installed in a KMA, encryption keys do not leave the cryptographic boundary of the HSM in unwrapped form.

When a KMA is not configured with an HSM card, cryptography is performed using the Solaris Cryptographic Framework (SCF) PKCS#11 soft token. Encryption keys do not leave the cryptographic boundary of the SCF in unwrapped form. The SCF is configured in FIPS 140 mode per the most recently published Solaris FIPS 140-2 security policies.

OKM uses AES Key Wrapping (RFC 3394) with 256-bit key encrypting keys to protect symmetric keys as they are created, stored on the KMA, transmitted to agents or within key transfer files.

When additional KMAs are added to the cluster, keys are replicated to the new KMAs.

When the first KMA of an OKM cluster is initialized, the KMA generates a large pool of keys. When additional KMAs are added to the cluster, the keys are replicated to the new KMAs and are then ready to be used to encrypt data.

Each KMA that is added to the cluster generates a pool of keys and replicates them to peer KMAs in the cluster. All KMAs will generate new keys as needed to maintain the key pool size so that ready keys are always available for agents.

When an agent requires a new key, the agent contacts a KMA in the cluster and requests a new key. The KMA draws a ready key from its key pool and assigns this key to the agent's default key group and to the data unit. Key metadata is replicated to the other KMAs in the cluster. Later, the agent can contact another KMA in the Cluster in order to retrieve the key. At no time is any clear text key material transmitted across the network.

These FIPS security policies apply to the Solaris configuration used with OKM.

In August 2016, the National Institute of Standards and Technology (NIST) awarded FIPS 140-2 Level 1 validation certificate #2698 for the Oracle Solaris Kernel Cryptographic Framework module in Solaris 11.3 and awarded FIPS 140-2 Level 1 validation certificate #2699 for the Oracle Solaris Userland Cryptographic Framework. The Oracle Key Manager 3.3.x KMA is based on Solaris 11.3. The Oracle Solaris Kernel Cryptographic Framework in an Oracle Key Manager 3.3.x KMA is configured in accordance to the Oracle Kernel Cryptographic Framework Security Policy. Similarly, the KMA is also configured in accordance with the Oracle Solaris Userland Cryptographic Framework Security Policy. OKM will update to newer Solaris security policies as they become available.

All KMA software upgrade bundles are digitally signed to prevent loading rogue software from unapproved sources.

OKM provides support for remote syslog servers.

You can configure KMAs to send messages in RFC 3164 or RFC 5424 message format to a remote syslog server using TCP unencrypted or Transport Layer Security (TLS). RFC 5425 describes the use of TLS to provide a secure connection for the transport of syslog messages in RFC 5424 message format.

A Security Officer can configure a KMA to send messages through TCP unencrypted or TLS. It is more secure to use TLS, as TLS uses X.509 certificates to authenticate and to encrypt the communication between the KMA and a remote syslog server. The KMA authenticates the remote syslog server by requesting its certificate and public key. Optionally, you can configure the remote syslog server to use mutual authentication. Mutual authentication ensures that the remote syslog server accepts messages only from authorized clients (such as KMAs). When configured to use mutual authentication, the remote syslog server requests a certificate from the KMA to verify the identity of the KMA.

OKM supports the Oracle Hardware Management Pack (HMP).

The HMP product is a member of Oracle Single System Management along with the ILOM. A Security Officer can enable the HMP on a KMA to use a management agent in Solaris to enable in-band monitoring of the KMA over SNMP. The HMP software is pre-installed but disabled with the SNMP agent configuration. Consequently, the SNMP agent listening port is not open until the HMP is enabled. The HMP is disabled by default.

Enabling the HMP provides you with:

• Event notification of hardware issues before they appear as Oracle Key Manager specific SNMP notifications or as a KMA outage.
• Ability to enable HMP on any, or all, supported KMAs in an OKM cluster.
• Ability to use read-only SNMP Get operations to SNMP MIBS on the KMA, including MIB-II, SUN-HW-MONITORING-MIB, and SUN-STORAGE-MIB.

You should keep the following security considerations in mind when you choose to enable the HMP on a KMA. When enabled, the HMP:

• Leverages any enabled, protocol v2c SNMP Managers configured in the Oracle Key Manager cluster. The SNMP v2c protocol does not have the security enhancements that appear in the SNMP v3 protocol.
• Enables a SNMP management agent on the KMA, allowing read-only network access to SNMP MIB information on this KMA.
• Security risks identified in the Oracle Hardware Management Pack (HMP) Security Guide (https://docs.oracle.com/cd/E72066_01/pdf/E72069.pdf) are mitigated by:
  • “System management products can be used to obtain a bootable root environment" - The hardening of KMAs disables root access to users of the system. SNMP is configured for read-only access. Therefore, SNMP Put operations are rejected.
  • “System management products include powerful tools that require administrator or root privileges to run" - root access to KMAs is disabled. Therefore, system users cannot run these tools.