Working with External Keystores

Introduction

CORE allows expanding the boundaries of a partition by attaching to it cloud keystores and on-premises HSMs.

We use the term external keystore to indicate a cloud keystore or on-premises HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing when the description applies to them both.

Deployment Options

CORE uses service architecture to implement interworking with the cloud keystore providers and on-premises HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing vendors. Each keystore has a dedicated service to handle interaction with the keystore. Such service may be:

  1. Coupled with CORE Server software and installed automatically during the CORE deployment.
  2. Deployed separately. Such services are tagged with the "deployed externally = true" setting.

CORE applies the following rule regarding these services:
- All cloud keystore services are coupled with CORE service software.
- Contrastingly, all HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing keystore services (HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing Connect) are "deployed externally".

Capabilities

CORE permits many-to-many relationships between partitions and external keystores:

  • A partition may attach to itself many external keystores.
  • Multiple partitions may be linked to the same external keystore.

CORE applications may generate, import, and use the linked keys using CORE UIDs or key names. Yet:

  • Only the external keystores may perform cryptographic operations using these keys.
  • The crypto capabilities of the linked keys depend on the capabilities provided by the vendor's API.

To summarize these capabilities and for configuration quickstarts, click the link in the CORE Specifications column.

Cloud keystore SDK name SDK version CORE specification
AWS KMSClosedKey Management System aws-java-sdk-kms 1.11.682 AWS KMS
Azure Key Vault azure-keyvault 1.2.4 Azure Key Vault
GCP KMSClosedKey Management System google-cloud-kms 1.43.0 Google Cloud KMS
On-premises HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing vendor HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing model HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing client version CORE specification
Thales Safenet Luna 7.4 HSM - Luna
Entrust (nCipher) nShield Connect HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing 12.71.0 HSM - nCipher

Prerequisites

To attach an external keystore to the CORE partition, the following prerequisites must be met:


In addition, certain features and keystores may require:

Keystore Service Settings

Cloud Keystore Service Settings

To attach a cloud keystore to a partition, the partition's SOClosedSecurity officer - UKC partition administrator role. must specify the cloud keystore and provide service account credentials that authorize accessing this keystore:

  • Access key ID - Service account ID that allows access to the external keystore.

    - Mandatory for AWS and Azure.

    - Not applicable for GCP.
  • Secret key - mandatory. The secret part of the access key (AWS and Azure), or the access token (GCP).
  • Cloud keystore specification method (Parameters) is unique to each keystore provider. CORE addresses such a variety of options by using key-value pairs.
  • Cloud keystore parameter names and values are case-sensitive. They depend on the keystore provider as follows:

    • AWS KMSClosedKey Management System
    • Parameter-name Value   Example of value
      REGION Name of the region US_WEST_2
    • Azure Key Vault
    • Parameter-name Value   Example of value
      URL URL of the key vault https://hello-world.vault.azure.net/
    • GCP KMSClosedKey Management System
    • Parameter-name Value   Example of value
      location Name of the region us-east1
      keyring_id Name of the keyring my-keyring

In addition, a partition SOClosedSecurity officer - UKC partition administrator role. must specify CORE-specific attributes of external keystore:

For the detailed UI description, see New Keystore.

HSM Keystore Service Settings

HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing keystore service (HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing Connect) settings are defined into two groups:

For the detailed UI description, see Register HSM Connect Agent.

Synchronization Options

To sync keys in the CORE partition with the changes that occurred in its external keystore, the partition's SOClosedSecurity officer - UKC partition administrator role. has two options:

  • Manual update:
    • Use the UI link command to add a link to a new key in the keystore.
    • Use the UI relink command to update the existing key.
  • Automatic update:
    • Launch the partition's key-sync service. It is a scheduled job that runs periodically according to the specification provided on its launch. The default interval is 30 minutes. The minimum period is one minute.
    • Control the synchronization scope by managing the sync policy of each keystore specified in the partition's configuration (see Edit Keystore):
    • NONE
      do not synchronize this keystore (default). The sync service makes no changes in the partition.
      ONLY_LINKED_KEYS
      as needed, re-sync already linked keys.
      ALL_ACTIVE_KEYS
      1. as needed, re-sync already linked keys.
      2. link to the new keys that were created in the external keystore.

      Note
      The key-sync service withholds from synchronizing the CORE keys with the deleted, destroyed, or revoked keys in the external keystore.You must explicitly perform the corresponding CORE command to synchronize CORE with the deleted, destroyed, or revoked external keys.

External Key Indicators in CORE

isExternal Setting

An external key is identified in CORE by the following settings:

Note
All crypto functions of an isExternal key are executed by the external keystore. The BYOKClosedBring Your Own Key setting of a key is not relevant.

BYOK Setting and Requirements

Unlike cloud keystores, we assume that on-premises HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing is managed by the organization that uses the CORE partition, and therefore, the BYOKClosedBring Your Own Key in such a case is redundant.

  1. BYOKClosedBring Your Own Key and Exportability
  2. BYOKClosedBring Your Own Key and Import:
    • CORE key import procedure for a key designated to a cloud keystore includes the following steps:
      1. Key is imported to CORE, where it starts the BYOKClosedBring Your Own Key process.
      2. The cloud keystore provides a wrapping key used by CORE to forward the wrapped material to the keystore.
      3. Key types that cannot be imported to the keystore due to wrapping limitations are declined.
  3. BYOKClosedBring Your Own Key delivery process and user's permissions.
    A user involved in the BYOKClosedBring Your Own Key delivery process (either by generating a BYOKClosedBring Your Own Key key or importing a key) must be authorized to perform all the necessary crypto operations required to protect the forwarded material. In particular, the user must be authorized to wrap a key using the type of key specified by the keystore provider.

Keystore Troubleshooting

Ping

CORE periodically checks the responsiveness of the keystores referred from a partition and the validity of the credentials used to access the keystore. The result appears in the keystore's status setting. It has two values {STOPPED, RUNNING}. To check the reason for being STOPPED, use the UI command Show the Last Error.

In addition, UI allows a partition SOClosedSecurity officer - UKC partition administrator role. to manually trigger this test by clicking the Ping command that performs the same test. The test's implementation is specific to each keystore provider:

AWS Ping
Send a request to generate a random number.
 
Azure Ping
Send key list request.
 
GCP Ping
Send Get request to the keyring.
 
HSMClosedHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing (Luna) Ping
Open a session, login, close the session.

Log files

See External Keystore Trace Logs.