Supporting Document: Evaluation Activities for collaborative PP-Module for DBMS Cryptographic Functions

If the TOE directly generates DEKs, the mechanism for directly generating Data Encryption Keys (DEKs), consistent with FCS_CKM.1.1/SKG and the claimed FCS_RBG.1 component.

If the TOE directly generates DEKs, the supported DEK key sizes in bits, consistent with the assignment in FCS_CKM.1.1/SKG and the claimed FCS_COP.1/SKC or FCS_COP.1/AEAD parameters.

If the TOE directly generates DEKs, the key hierarchy: how generated DEKs are immediately protected (wrapped or encrypted) by the Master Encryption Key (MEK). The TSS shall explicitly state that DEKs are never stored in plaintext on persistent storage.

If the TOE directly generates DEKs, when DEKs are generated (e.g., at tablespace creation, at column encryption enablement) and the conditions under which they may be regenerated or rotated.

The source of randomness used for direct key generation, identifying FCS_RBG.1 and its selected seeding component.

If the TOE derives DEKs instead of, or in addition to, directly generating DEKs, the applicable FCS_CKM.5 or FCS_CKM_EXT.8 component and the derivation path evaluated under Section 5.2, “FCS_CKM.5 / FCS_CKM_EXT.8 Key Derivation (Consumed Catalogue Components)”.

If the TOE directly generates DEKs, any administrator-visible steps associated with DEK generation, such as enabling encryption on a tablespace, database, or column set.

If the TOE directly generates DEKs, how to verify DEK generation has succeeded (e.g., via system views, status commands, or log entries).

Any configuration parameters that affect claimed direct key generation behaviour (e.g., key size selection, algorithm mode selection where multiple options are supported).

A statement that DEKs are managed automatically by the TOE and that administrators should not attempt to access or export DEK material directly.

Whether DEKs are derived from existing keying material or other non-password derivation inputs (FCS_CKM.5) or from a password/passphrase (FCS_CKM_EXT.8).

The derivation inputs used by the DBMS, including salts, labels, context strings, key identifiers, tenant/database identifiers, counters, iteration counts, memory or work factors, and any other values required by the included Catalogue component.

The supporting Catalogue primitive components used by the derivation function (for example, hash, keyed hash, CMAC, SKC, or AEAD components), and how those components match the ST assignments.

The output key sizes and how derived DEKs are bound to the encrypted database object, tenant, table, column, or storage scope.

How derived DEKs are protected after derivation and whether any derived key material is cached, persisted, rotated, or destroyed.

Any administrator-visible configuration that affects DEK derivation, including password/passphrase policy when FCS_CKM_EXT.8 is claimed.

How derivation parameters are generated, stored, backed up, restored, and migrated during upgrade or rotation.

How administrators verify that derived-key encryption is enabled for the intended database objects.

Which option is selected in FCS_CKM_EXT.1.1 ("Generated Internally", "Imported from External Entity", or "Externally Managed") and the rationale for that selection.

The algorithm and randomness source used for MEK generation, referencing FCS_CKM.1/SKG and the applicable Catalogue RBG component (FCS_RBG.1).

The generated MEK key sizes and how they match the ST assignments and selected DEK protection operation.

The storage location of the generated MEK (e.g., software keystore/wallet, filesystem-protected keyfile, platform key store integration).

The protection mechanism applied to the stored MEK (e.g., password-based encryption of the keystore, filesystem ACLs, OS keyring or HSM integration).

How the TOE ensures the MEK storage location is accessible only to authorized roles.

The type of external entity from which the MEK is imported (e.g., Key Management Service, HSM, cloud key vault).

The protocol used for the import channel (referencing FDP_ITC_EXT.1).

The mutual TLS authentication requirements for the import operation, including the TOE certificate or credential used to authenticate to the external entity.

How the imported MEK is stored and protected within the TOE boundary after import.

The external key management service used (e.g., a KMIP-conformant key manager) and whether the TOE retrieves the MEK for transient use or invokes MEK operations by reference.

The protocol used for the key-management channel (referencing FDP_ITC_EXT.1) and the key-management message protocol carried over it (the message protocol itself is not evaluated).

How the TOE ensures plaintext MEK material is not persistently stored within the TOE boundary, including the handling and lifetime of any transient in-memory copies.

Where MEK operations are invoked by reference, which cryptographic operations are performed by the external service rather than the TSF, consistent with the FCS_COP components claimed in the ST.

The TOE’s behavior when the external service is unreachable or denies use of the MEK (e.g., whether protected data becomes inaccessible, whether cached material allows continued operation and for how long).

The DEK protection method selected in FCS_CKM_EXT.1.2 (FCS_COP.1/KeyWrap, FCS_COP.1/SKC, or FCS_COP.1/AEAD) and the corresponding Catalogue component claims. Where FCS_COP.1/SKC is selected, the evaluator shall examine any compensating integrity mechanisms for stored DEKs described in the TSS (for example, keystore-container integrity protection); the module does not require such mechanisms under the General-Purpose use case.

Any IVs, nonces, tweaks, or other one-time values used for DEK protection and whether FCS_OTV_EXT.1 is included.

How the MEK is protected against disclosure and modification while in use (in-memory protection).

The MEK destruction procedure, including the method by which MEK material is overwritten or otherwise rendered unrecoverable (consistent with the consumed FCS_CKM.6 component) and the effect of MEK destruction on data encrypted under DEKs that were protected by the destroyed MEK.

Step-by-step instructions for MEK generation (if "Generated Internally" is selected), including prerequisite configuration (e.g., keystore location), the command or procedure to generate the MEK, and how to verify generation succeeded.

Step-by-step instructions for MEK import (if "Imported from External Entity" is selected), including prerequisites for establishing the mutual TLS connection to the external KMS (network access, trust anchor configuration, TOE/client certificate configuration), the command or procedure to initiate and complete the import, and how to verify the import succeeded and the MEK is active.

Step-by-step instructions for external key-management integration (if "Externally Managed" is selected), including prerequisites for establishing the mutual TLS connection to the key management service, endpoint and credential configuration, and how to verify the integration is active and the MEK is usable.

The DEK protection method used by the TOE and any administrator-visible controls that affect whether DEKs are key-wrapped, symmetrically encrypted, or authenticated-encrypted under the MEK.

The MEK rotation procedure, including the steps to generate or import a new MEK, how DEK re-protection occurs (automatically or requiring an administrator action), how to verify data remains accessible after rotation, and any operational impact or downtime considerations.

The MEK destruction procedure, including the command or procedure to destroy the MEK, a clear warning that MEK destruction renders all data encrypted under dependent DEKs permanently inaccessible, and the method used for key material zeroization (consistent with the FCS_CKM.6 claims).

How to restrict access to the MEK storage location to authorized roles only.

That the destruction method is consistent with the included FCS_CKM.6 operations.

The specific destruction method selected (e.g., single overwrite with zeros, overwrite with a pseudo-random pattern) and confirmation that it applies to both MEK and DEK material.

When key destruction occurs (e.g., explicit administrator command, expiry-triggered destruction, key rotation completion) and whether any keys are excluded from destruction requirements.

The key destruction commands or procedures available to authorized administrators.

A clear statement of the irreversibility of key destruction and the impact on encrypted data.

Which strategy is selected in FDP_DAR_EXT.1.1: Storage-Scope Encryption or Granular Data Encryption.

Defines the scope of encryption - which persistent database storage objects are encrypted. At minimum, the TSS shall address: data files, transaction/redo log files, undo/rollback segment files, temporary tablespace or temp files, backup artifacts generated by the TOE, export artifacts generated by the TOE, snapshots under TOE control, and database-managed diagnostic or spill files that can contain user data.

Identifies any excluded storage-object categories and provides a rationale showing that each exclusion either does not contain plaintext user data or is protected by an equivalent claimed mechanism.

Identifies the encryption algorithm and mode, including any IV, nonce, tweak, tag, or other one-time-value handling, consistent with the included FCS_COP.1/SKC, FCS_COP.1/AEAD, and FCS_OTV_EXT.1 components.

Describes how encryption is applied transparently to the DBMS (i.e., applications do not need modification to benefit from encryption).

Defines the granularity level (column-level, row-level, cell-level, or a combination).

Identifies which encryption modes are supported (e.g., deterministic, randomized/probabilistic) and the security implications of each:

Describes how encrypted columns or data elements interact with database indexing, query processing, and backup/restore operations.

Identifies any data types, storage formats, indexes, generated columns, logs, exports, or backups that are excluded from granular encryption and provides rationale.

Identifies the encryption algorithm, key size, mode of operation, and one-time-value handling, confirming consistency with the included FCS_COP.1/SKC, FCS_COP.1/AEAD, and FCS_OTV_EXT.1 Catalogue components. The evaluator shall verify that the components selected in FDP_DAR_EXT.1.2 are included in the ST and are the cryptographic operations actually performing the FDP_DAR_EXT.1.1 encryption.

Explains how compression, deduplication, encoding, or page formatting affect storage inspection tests, and how the evaluator can obtain representative raw artifacts for inspection.

Step-by-step instructions for enabling encryption (Storage-Scope or Granular) appropriate to the selection made in the ST.

For Storage-Scope Encryption:

For Granular Data Encryption:

Performance considerations and tuning recommendations related to encryption.

How to disable or re-encrypt data and the impact on key management.

Any steps needed to disable or account for compression, deduplication, external encoding, or application-layer transformations during evaluator storage-inspection tests.

identifies each channel over which the TOE transmits data to or from external entities, including client-to-database connections, database-to-database connections, management and administrative channels, audit export channels, and connections to external services;

identifies the protocol protecting each channel: TLS (including HTTPS over TLS where applicable), which is mandatory for every conforming TOE, or a supplementary protocol claimed in the FDP_DIT_EXT.1.1 selection — the evaluator shall verify the TLS Functional Package claim is present regardless of any supplementary protocol, and that any supplementary protocol is claimed from an applicable Functional Package and implemented within the TOE boundary (not by the underlying operating system or kernel);

identifies the TLS and X.509 components included from the Functional Package for TLS v2.1 and the Functional Package for X.509 Certificates that implement each protected channel; and

describes how channel endpoints are authenticated, including certificate validation, where required by the selected protocol.

The specific mutual TLS protocol used for the trusted channel and consistency with the components included from the Functional Package for TLS v2.1.

The certificate infrastructure used for mutual TLS, including TOE/client certificate configuration, KMS server certificate validation, trust anchors, certificate revocation handling if claimed, and where TOE/client certificates and private keys are stored within the TOE.

How the TOE handles channel establishment failures, including rejection of KMS connections presenting untrusted or expired certificates, handling of TLS negotiation failures (e.g., protocol version mismatch, cipher suite mismatch), and behavior when the KMS is unreachable (timeout, fail-closed vs. fail-open consideration).

That key material transmitted over the channel is protected by the TLS layer and is never transmitted in plaintext.

Prerequisites for establishing the trusted channel, including certificate requirements (CA certificates to be trusted, TOE/client certificate generation and installation, KMS server certificate requirements) and network access requirements (ports, firewall rules).

Instructions for configuring the TOE to connect to the external KMS, including KMS endpoint configuration (hostname/IP, port) and certificate or credential configuration for the channel.

The procedure for rotating or updating certificates used in the channel.

How to test channel connectivity before performing a key import, and how to diagnose channel establishment failures.

The TOE’s behavior when the KMS is unavailable (e.g., whether cached key material allows continued operation or whether the TOE fails to start or denies new connections).