This section outlines the specific security mechanisms offered by OKM.
Customers having encryption-enabled agents are primarily concerned with:
Disclosure of information in violation of policy
Loss or destruction of data
Unacceptable delay in restoring data in case of catastrophic failure (for example, in a business-continuity site)
Undetected modification of data.
The objective of the security features of Oracle Key Manager are to:
Protect encrypted data from disclosure.
Minimize exposure to attacks.
Provide sufficiently high reliability and availability.
The critical security features that provide protection are:
Authentication – Ensuring that only authorized individuals get access to the system and data
Access Control – Control to system privileges and data; this access control builds on authentication to ensure that individuals only get appropriate access
Audits – Allows administrators to detect attempted breaches of the authentication mechanism and attempted or successful breaches of access control.
For more information about the security and authentication aspect of the Oracle Key Manager, refer to the Oracle Key Manager Version 2.x Security and Authentication White Paper at:
http://www.oracle.com/technetwork/articles/systems-hardware-architecture/okm-security-auth-300497.pdf
The Oracle Key Manager architecture provides for mutual authentication between all element of the system: KMA to KMA, agent to KMA, and the Oracle Key Manager 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 the 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. Renewing the OKM root CA certificate when using OKM 3.3.2+ will result in a X.509v3 certificate. For brand new 3.3.2+ OKM clusters, all entities will use X.509v3 certificates. The default signature hash algorithm used on X.509v3 certificates is SHA256.
The OKM behaves as a root certificate authority to generate a root certificate that KMAs use in turn to derive (self-sign) the certificates used by agents, users, and new KMAs. OKM 3.3.2+ allows you to reissue (renew) the root CA certificate with the existing RSA key pair.
Access control consists of:
The Oracle Key Manager 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 determine which operations a user is permitted to perform on an Oracle Key Manager system. These roles are:
Security Officer – Performs Oracle Key Manager 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 – Views system audit trails
Quorum Member – Views and approves pending quorum operations
A Security Officer is defined during the QuickStart process, which sets up a KMA in an OKM Cluster. Later, a user must log in to the Cluster as a Security Officer using the Oracle Key Manager GUI in order to define additional users. The Security Officer can choose to assign multiple roles to a particular user and can also choose to assign a particular role to multiple users.
For more information about the operations that each role allows and how a Security Officer creates users and assigns roles to them, refer to the Oracle Key Manager 3 Administration Guide.
This role-based access control supports National Institute of Standards and Technology (NIST) Special Publication (SP) 800-60 operational roles to segregate operational functions.
Some operations are critical enough to require an additional level of security. These operations include adding a KMA to an OKM Cluster, unlocking a KMA, creating users, and adding roles to users. To implement this security, the system uses a set of key split credentials in addition to the role-based access described above.
Key split credentials consist of a set of user ID and passphrase pairs. You must provide a minimum number of these pairs to the system to enable completion of certain operations. The key split credentials are also referred to as ”the quorum” and the minimum number as ”the quorum threshold.”
Oracle Key Manager allows up to 10 key split user ID/passphrase pairs and a threshold to be defined. They are defined during the QuickStart process when the first KMA in an OKM Cluster is configured. The key split users IDs and passphrases are different from user IDs and passphrases that you use to log in to the system. When a user attempts an operation that requires quorum approval, the defined threshold of key split users and passphrases must approve this operation before the system performs this operation.
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.
Oracle Key Manager provides other security features. For more information about these and other OKM features, refer to the Oracle Key Manager 3 Administration Guide.
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 using 2048-bit RSA. The TLS protocol version is configurable for the management network and service network. Establishing this session results in the endpoints agreeing on an Advanced Encryption Standard (AES) 256-bit key. The TLS cipher suite is non-negotiable so KMA client endpoints may not negotiate a weaker suite. All subsequent communications are encrypted with this AES 256-bit key. 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.
KMAs can have an available Hardware Security Module (HSM), which is ordered separately. This 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. The HSM uses a FIPS-approved random number generator, as specified in FIPS 186-2 DSA Random Number Generator using SHA-1 for generating encryption keys.
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 release 3.3 supports two types of HSMs: the Sun Cryptographic Accelerator (SCA) 6000 card and nCipher nShield Solo Module. The SCA 6000 card was certified to FIPS 140-2 Level 3. However, this certification expired on 12/31/2015 and is not being renewed. The nCipher nShield Solo Module is available as an alternative HSM in OKM release 3.3. Either type of HSM can be installed in a SPARC KMA running this release, but a nCipher nShield Solo Module is not supported in a KMA running an older OKM release.
Oracle Key Manager 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 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. The KMA then replicates these database updates across the network 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.
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 KMA is based on Solaris 11.3. The Oracle Solaris Kernel Cryptographic Framework in an Oracle Key Manager 3.3 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.
This Oracle Key Manager release 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.
Oracle Key Manager supports the Oracle Hardware Management Pack (HMP) on SPARC T7-1, Netra SPARC T4-1 and Sun Fire X4170 M2 KMAs. 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.
Oracle Red Stack integration with Oracle Enterprise Manager through SNMP Receivelets and SNMP Fetchlets.
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 (http://docs.oracle.com/cd/E20451_01/pdf/E27799.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.