Skip to main content

Cryptographic Protection

Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.

UbID evaluates cryptographic protection across three states of information:

  • data at rest while stored on a device or institutional system;
  • data in transit while moving between participants and services;
  • data in use while an authorized operation processes sensitive information.

Protecting only one state is insufficient. Encryption of a database does not protect a secret that is exposed to an over-privileged application, and secure transport does not correct poor key governance.

Protection at rest​

Holder and institutional data should be stored in encrypted form appropriate to its sensitivity. Public principles include:

  • authenticated encryption;
  • unique encryption context and non-reuse safeguards;
  • separation between encrypted data and key material;
  • device and application isolation;
  • versioned envelopes that support controlled migration;
  • backup and recovery tests;
  • secure deletion and lifecycle evidence.

A storage technology is not a secure vault by itself. The security property comes from how keys are derived, protected, used, rotated, and removed from memory.

Protection in transit​

Transport protection should provide confidentiality, integrity, peer authentication, and resistance to replay or misdirection.

Different UbID flows may use web protocols, secure agent messaging, or application-specific channels. In every case, the trust decision should be bound to the intended participant, purpose, and transaction rather than relying only on network location.

Protection in use​

Sensitive operations sometimes require stronger isolation while data is being processed. Governed cryptographic services and confidential execution can reduce exposure by ensuring that applications receive only the result of an approved operation rather than unrestricted key material.

Where protected execution is used, attestation and workload policy must establish that the expected code and environment are running before sensitive material is released. Confidential execution does not replace secure software, patching, access control, monitoring, or independent review.

Key purpose and separation​

Key purpose, owner, environment, algorithm, provider, and lifecycle are separate architecture dimensions.

Different purposes should use distinct key identities and policies, for example:

  • credential issuance;
  • service authentication;
  • protected document encryption;
  • recovery protection;
  • audit integrity;
  • test and production environments.

Using one key for unrelated purposes makes compromise harder to contain and evidence harder to interpret.

Controlled cryptographic operations​

Applications should request a narrow approved operation—such as signing, encryption, decryption, verification, or wrapping—without receiving the underlying institutional key.

The cryptographic control plane should evaluate:

  • caller identity and authorization;
  • key purpose and current version;
  • allowed operation and algorithm;
  • environment and transaction context;
  • lifecycle state;
  • evidence and rate controls.

Root or unrestricted administrative credentials should not be used by ordinary application services.

Key lifecycle​

A governed lifecycle includes:

  1. creation and ownership assignment;
  2. activation for an approved purpose;
  3. monitored use;
  4. rotation and coexistence;
  5. suspension or revocation after compromise;
  6. retirement and archival requirements;
  7. destruction where appropriate;
  8. tested backup and recovery.

Verifiers and relying parties must be able to distinguish historical validity from current key status.

Crypto-agility​

Crypto-agility is the ability to change algorithms, key sizes, providers, formats, and trust policy without losing control of historical evidence or breaking every integration at once.

It requires inventories, versioned policy, compatibility testing, migration plans, clear assurance labels, and rejection of unapproved downgrade behavior.

Holder and institutional keys​

Holder-controlled keys and institutional keys serve different purposes. Protecting an issuer signing key does not make the institution the owner of the holder's identity. Conversely, holder control does not authorize the holder to alter institutional claims.

Public documentation boundary​

The portal does not publish private keys, secret names, provider credentials, internal key paths, unsealing procedures, backup packages, recovery shares, exact production algorithms, or rotation schedules.

See UbID KeyVault, Post-Quantum Readiness, and Security Model.