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.3, “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.

The ML-KEM parameter set and the TOE component performing KeyGen.

The randomness source and corresponding FCS_RBG.1 claim.

The representations and storage locations of the encapsulation key, decapsulation key, and any retained KeyGen seed.

How the decapsulation key and KeyGen seed are protected and destroyed under FCS_CKM.6.

The DBMS function and FCS_COP.1/KeyEncap role for which the key pair is generated.

Whether DEKs are derived from existing keying material or other non-password derivation inputs (FCS_CKM.5), from a password/passphrase (FCS_CKM_EXT.8), or whether an ML-KEM shared secret is used as the input to FCS_CKM.5 to derive an MEK or KEK.

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. For ML-KEM input, the description shall identify the context that binds the derived key to the TOE and peer identities, the selected key purpose, and the applicable establishment transaction or protected-key record.

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, or how an ML-KEM-derived MEK or KEK is bound to its key-establishment or key-transfer purpose.

How derived keys are protected after derivation and whether any derived key material is cached, persisted, rotated, or destroyed. Where ML-KEM input is used, the TSS shall explain when the raw shared secret is destroyed and demonstrate that it is not used directly as an MEK, KEK, or data-encryption key.

Any administrator-visible configuration that affects key derivation, including password/passphrase policy when FCS_CKM_EXT.8 is claimed and ML-KEM derivation context or key-purpose configuration when FCS_CKM.5 consumes an ML-KEM shared secret.

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", "Externally Managed", or "Established through Key Encapsulation") 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 FCS_CKM_EXT.1.2 protection model selected for the stored MEK and the evidence that the implementation satisfies that model.

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, including the FCS_CKM_EXT.1.2 protection model selected for that storage path.

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 external entity with which the TOE establishes the ML-KEM shared secret, the ML-KEM parameter set, and whether the TOE performs encapsulation, decapsulation, or both under FCS_COP.1/KeyEncap.

Whether an ML-KEM key pair used by the TOE is generated within the TOE under FCS_CKM.1/KEM and FCS_RBG.1, or is provisioned from an external source. Externally performed KeyGen, encapsulation, or decapsulation shall be clearly identified as outside the TOE and shall not be claimed as a TOE cryptographic operation.

For encapsulation, how the TOE authenticates the recipient encapsulation key; for decapsulation, where and how the TOE protects the decapsulation key and how it is destroyed under FCS_CKM.6.

How the TOE passes the ML-KEM shared secret to FCS_CKM.5, the context bound by the derivation, the resulting MEK size and purpose, and when the raw shared secret is destroyed.

How the mutually authenticated channel in FDP_ITC_EXT.1 protects the key-establishment exchange. If the exchange occurs inside a higher-level protocol such as TLS, the applicable protocol Functional Package, rather than FCS_COP.1/KeyEncap, shall own that protocol use.

Each Master Key storage or use path and the corresponding protection model selected in the first selection of FCS_CKM_EXT.1.2: cryptographic protection under FCS_COP.1/KeyWrap or FCS_COP.1/AEAD, non-exportable hardware-backed key storage within the TOE boundary, or no persistent Master Key material within the TOE boundary. If more than one model is selected, the TSS shall map each model to the applicable key path.

For cryptographic protection, the protecting key, claimed Catalogue operation, one-time values where applicable, and separation between the protected MEK and the protecting key. For non-exportable hardware-backed storage, the evaluated interface, TOE-boundary allocation, authorization enforcement, and non-exportability property. For no-persistent-material handling, the lifetime, clearing, and restart behavior of transient copies and the locations examined to establish that no plaintext or reversibly encoded MEK persists.

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.

Step-by-step instructions for ML-KEM establishment (if "Established through Key Encapsulation" is selected), including peer and trusted-key configuration, the TOE’s selected role, local ML-KEM key-pair generation or provisioning where applicable, derivation-context configuration, rotation or replacement, and how to verify that the derived MEK is active.

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.

How to configure each selected Master Key protection model, restrict Master Key use to authorized TSF functions and roles, and verify that cryptographic protection, hardware-backed non-exportability, or transient-only handling is active as claimed.

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.

The selected ML-KEM parameter set and whether the TOE performs encapsulation, decapsulation, or both.

The source, storage location, authentication, protection, rotation, and destruction of each ML-KEM encapsulation or decapsulation key used by the TOE.

Whether the TOE generates an ML-KEM key pair under FCS_CKM.1/KEM; if KeyGen is external, the TOE boundary and provisioning interface shall be identified without claiming external generation as a TOE operation.

For encapsulation, the FCS_RBG.1 source used by the operation. For a decapsulation-only implementation, the evaluator shall verify that no RBG dependency is asserted merely for decapsulation.

How the resulting shared secret is passed to FCS_CKM.5, the derived MEK or KEK purpose, and how the raw shared secret is destroyed under FCS_CKM.6.

When a KEM-derived KEK protects transferred keying material, the FCS_COP.1/KeyWrap or FCS_COP.1/AEAD operation that protects the existing MEK or DEK; ML-KEM shall not be described as directly encapsulating that existing key.

Any externally performed ML-KEM operation and any ML-KEM use owned by a protocol Functional Package, such as TLS, so those operations are not also claimed under this component.

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.

The FDP_ITC_EXT.1.4 selection: where supplementary end-to-end protection is selected, whether transferred keying material is directly protected by FCS_COP.1/KeyWrap, or whether ML-KEM establishes a shared secret from which FCS_CKM.5 derives a KEK and FCS_COP.1/KeyWrap or FCS_COP.1/AEAD protects the existing MEK or DEK. The TSS shall identify the TOE’s ML-KEM role, the locations of the ML-KEM keys, derivation inputs, KEK, and transferred key, and where unwrapping, authenticated decryption, or decapsulation occurs.

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).

When supplementary ML-KEM protection is selected, how to configure the TOE role and peer keys, establish the KEM-derived KEK, select the KeyWrap or AEAD protection operation, rotate the relevant keys, and diagnose failed decapsulation, derivation, unwrap, or authenticated-decryption operations.