This section outlines the specific security mechanisms offered by the product.
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
This section of the security guide should give a high level overview of the threats that the system is designed to counter and how the individual security features combine to prevent the attacks.
The critical security features that provide these protections are:
Authentication – Ensuring that only authorized individuals get access to the system and data
Authorization – Access control to system privileges and data; this access control builds on authentication to ensure that individuals only get appropriate access
Audit – 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 3.0 Security and Authentication White Paper at:
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.
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.
Access control is of following types:
Users and Role-Based Access Control
Quorum Protection
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 into 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 Administration Guide included in the Oracle Key Manager documentation libraries at:
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
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 consists of a set of user ID and passphrase pairs, together with the minimum number of these pairs necessary 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 are used to log into 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.
A user must properly log into 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 Overview at:
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 (secure sockets) channel using 2048-bit RSA. Establishing this session results in the endpoints agreeing on an Advanced Encryption Standard (AES) 256-bit key. The TLS cypher 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.
KMAs have an available Hardware Security Module, which is ordered separately. This Hardware Security Module -- a Sun Cryptographic Accelerator (SCA) 6000 card – is FIPS 140-2 Level 3 certified and provides Advanced Encryption Standard (AES) 256-bit encryption keys. The SCA 6000 card supports a FIPS 140-2 Level 3 mode of operation and OKM always uses the card in this manner. When the OKM Cluster operates in FIPS compliant mode, encryption keys do not leave the cryptographic boundary of the SCA 6000 card in unwrapped form. The SCA 6000 card 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 SCA 6000 card, cryptography is performed using the Solaris Cryptographic Framework (SCF) PKCS#11 soft token.
Oracle Key Manager uses AES Key Wrapping (RFC 3994) 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.