Unbound CORE Terms

This section specifies the CORE-specific terms used in this guide.

Crypto Terms

Crypto Processing Modes

CORE server software includes two cryptography processing modes:

non-FIPS modeClosedUKC system advanced execution mode that hasn't yet received the FIPS certification
Crypto algorithms may be evolved beyond FIPSClosedFederal Information Processing Standards - standards developed by the United States federal government for use in computer systems by non-military government agencies and government contractors certification.
New key types and mechanisms are added.
FIPS modeClosedUKC system mode that allows processing FIPS-certified and not-certified keys
FIPSClosedFederal Information Processing Standards - standards developed by the United States federal government for use in computer systems by non-military government agencies and government contractors 140-2 certified crypto algorithms are signed and locked as certificated. They are applied to key material that, in its settings, demands to use the FIPSClosedFederal Information Processing Standards - standards developed by the United States federal government for use in computer systems by non-military government agencies and government contractors-certified algorithms. The other key material uses new or evolved algorithms.

By default, CORE servers are bootstrapped and operate in non-FIPS modeClosedUKC system advanced execution mode that hasn't yet received the FIPS certification. To use a CORE system in FIPSClosedFederal Information Processing Standards - standards developed by the United States federal government for use in computer systems by non-military government agencies and government contractors-mode, bootstrap it in FIPSClosedFederal Information Processing Standards - standards developed by the United States federal government for use in computer systems by non-military government agencies and government contractors-mode or upgraded to it.

Crypto Operation Classification

All crypto operations are classified as follows (Ref. KMIP v 1.4 section 3.22):

Crypto-processing
Decryption
Unwrapping
Verification of signature
Verification of MACClosedMessage Authentication Code - for example, CMAC, GMAC, HMAC.
Crypto-protection
Encryption
Wrapping
Signing
MACClosedMessage Authentication Code - for example, CMAC, GMAC, HMAC. generation
Derivation

Key Type Classification

Crypto object
Certificate, key, or secret.

Keys are further classified into the following categories:

Private key
imported or generated asymmetric key-pair.
Secret key
imported or generated symmetric key.
Public key
imported public key of an asymmetric key-pair.
Split key
imported part of a symmetric key.

Key Groups and Permissions

Key Group name
A name-tag attached to a crypto object. Indicates its membership in the group.
Non-default tags may be attached and detached.
Crypto object may be a member in multiple key groups.
Default key group
All crypto objects are members of the default key group. This membership can't be revoked.
Permission
Set of operations that may be performed using crypto object from the specified key group.
Permitted operations ("Purpose")
Set of operations that a crypto objects is permitted to be used for.

Key groups are created implicitly by attaching a new membership tag to a crypto object or by specifying a new tag-name in a permission. Key groups play a pivotal role in specifying the CORE user role. For example, a user may be permitted to execute a specific set of operations as long as the crypto objects used by these operations are members of the specified key group.

CORE Solution Components

Keystores

CORE keystore
MPCClosedMultiparty computation - A methodology for parties to jointly compute a function of their inputs while keeping those inputs private.-secured keystore embedded into a pair of the CORE servers and cloned to other pairs.
External Keystore
keystore located and secured outside of the CORE perimeter. CORE users transparently manage and use key material stored there. Two types:
  • Cloud keystores.
  • On-premise HSMs.

Servers and Devices

A CORE solution is comprised of the following nodes:

UKC Nodes

 Cluster

A CORE Cluster Foundation is the minimum set of servers required to provide CORE functionality.

Non-FIPSClosedFederal Information Processing Standards - standards developed by the United States federal government for use in computer systems by non-military government agencies and government contractors and FIPSClosedFederal Information Processing Standards - standards developed by the United States federal government for use in computer systems by non-military government agencies and government contractors clusters are bonded differently:

Types of Client Applications

CORE supports three categories of client-side applications that are classified according to the level of coupling with the CORE client-side software:

CORE Partitions

CORE partition enables multi-tenancy in a CORE cluster. Each tenant uses a partition where it:

  • stores the key material.
  • specifies the authorized users and their roles.
  • specifies the certified clients.

Each partition spreads across EP and Partner servers. It is replicated across all server pairs.

CORE Partitions

Partition types:

CORE Users

CORE user is a person or an application that makes CORE service calls. Based on the user authentication method, users are divided into two categories:

Internal user
credentials of this user are managed and validated by CORE.
SSOClosedSingle Sign-On user
credentials of this user are managed and validated by OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol Provider.

CORE User Roles

To perform a specific operation that uses a particular object, a user must have appropriate permission. Permissions are further packaged and managed as roles.

Permission
It ties up a group of objects with a group of permitted operations.
The granularity of permission allows pinpointing a specific crypto operation using a specific key.
Role
It is as a set of permissions.
It is managed by a partition SOClosedSecurity officer - UKC partition administrator role..
User group
It ties up a group of users with a set of roles that are granted to members of the group.

A CORE user may have an assigned role and/or be a member of a user group(s) and be entitled to all permissions that are granted to the group(s).

Default Roles

Each partition is created with two static roles:

User Role
This role allows unrestricted management and use of the partition's key material.
SOClosedSecurity officer - UKC partition administrator role. Role
This role puts no restrictions on managing the partition and key material but doesn't permit using the key material. In particular, it allows creating custom roles and user groups, clients and users, management of the partition's settings, and participation in the partition quorum.

These roles are static, permissions specified by these roles cannot be changed.

Default Users

Upon the creation of a partition, the system creates two default users known by the following names:

user
it is assigned the USER Role.
It may be reassigned to a custom and more restricted role, or granted membership in a user group with a subset of permissions reserved to SOClosedSecurity officer - UKC partition administrator role..
so
it is assigned the SOClosedSecurity officer - UKC partition administrator role. Role.
It can't be reassigned to a different role, but the scope of its permissions may be increased by including it in a user group that allows certain crypto operations.

Besides these users, the system bootstrap creates the Root partition and its SOClosedSecurity officer - UKC partition administrator role.:

Root SOClosedSecurity officer - UKC partition administrator role.
has the SOClosedSecurity officer - UKC partition administrator role. Role in the Root partition
In addition, the main objective of Root SOs is the creation of partitions, CORE cluster management, and control of the global system settings.

Key Material

Obfuscated Key

The term obfuscated key and Obfuscated PEMClosedBase64 encoded DER wrapped by "--- BEGIN <type> ---" and "--- END <type> ----" refers to the PEMClosedBase64 encoded DER wrapped by "--- BEGIN <type> ---" and "--- END <type> ----"-formatted file that contains a handle to the UID of an asymmetric key. The key material may be located in the CORE or external keystore. An obfuscated key serves applications (e.g. OpenSSL) that are

To create such a file from an asymmetric key located in the CORE or external keystore, use

A peek into the file shows the Base64 encoding of the handle to the UID and a filler pattern (UNBOUND).

cat myself.pem -----BEGIN PRIVATE KEY----- MIIEugIBADANBgkqhkiG9w0BAQEFAASCBKQwggSgAgEAAoIBAQCk3BH69F92Hosc i73tGHnHh715xR6aGG1+gYkorr7j9kIKP+HpjIJrdzgfcCY0/6NKyd9N9Jdy7R4k 2ypyGkd2jVzkxersIqOfrTfq0FO98nz0KlLXKOwl4dZRIU+fUuuJSefXmEeD/yK1 M4bMpFiDAgMBAAECgf9UNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNB
----------- truncated -----------
UNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUND UNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUNDUNBOUND UNBOUNDUNB= -----END PRIVATE KEY-----

Note
The filler pattern and the title line may change based on the key material type and the scenario that caused the creation of the key.

UB-PGP Proxy Key

UB-PGPClosedPretty Good Privacy - PKI implementation proxy key represents a CORE key in the GnuPG (GPGClosedGNU Privacy Guard - PGP cryptography implementation) keyring infrastructure. It allows GPGClosedGNU Privacy Guard - PGP cryptography implementation-based applications transparent use of an RSA key that is located in the CORE or external keystore and is processed there.

To create the UB-PGPClosedPretty Good Privacy - PKI implementation proxy key and embed it into PGPClosedPretty Good Privacy - PKI implementation key-rings, use the ucl pgp-key command.