4Quays
Sign Up

Core Concepts

Understand the fundamental concepts of 4Quays - services, policies, keys, and the graph model

4Quays is built around a few core concepts that work together to provide centralized cryptographic control. Understanding these concepts will help you design your integration effectively.

Services

A service is any system registered in the 4Quays platform — whether it's the system initiating crypto operations or the system receiving them. Both the calling application and the external party it communicates with are services.

  • Your application is a service (source)
  • Your bank's API is a service (destination)
  • A tax authority's filing endpoint is a service (destination)

This unified model means 4Q does not distinguish between "applications" and "external parties" — they are all nodes in the same graph. Services that only require TLS (no payload-level encryption) don't need to be registered.

Policies

A policy is an edge in the graph — it binds two services to a specific cryptographic configuration:

  • Which algorithm to use
  • Which key to apply
  • Under what conditions

Each policy has a policy number that your application passes to /protect or /unprotect. When an administrator updates a policy, every subsequent /protect call using that policy number produces output with the new configuration. The calling application's code is unchanged.

Why policies matter: Instead of coordinating code changes across services, an administrator updates a policy and the switchover happens automatically.

Keys

4Quays centralizes the key lifecycle:

  • Provisioning: Import destination public keys
  • Storage: Secure key storage within the platform
  • Retirement: Safe key decommissioning

Applications never handle key material directly. When a service's public key is updated, 4Q manages the transition transparently.

The Graph Model

The 4Quays topology is a many-to-many graph:

  • Services are the nodes
  • Policies are the edges

Each policy defines the cryptographic relationship between two services — which algorithm to use, which keys are involved, and in which direction.

Example graph:

Your App ──[AES-256-GCM + RSA]──► Bank A
    │
    └──[AES-256-GCM + ML-KEM]──► Bank B

This model scales naturally:

  • Adding a new service = adding a node
  • Adding a new integration = adding an edge (policy)
  • Changing a cryptographic requirement = updating an edge

Cryptographic Layering

4Quays operates at the payload protection layer, not the transport layer:

Transport layer (TLS): All communication travels over TLS. This provides channel encryption and protection against eavesdropping. 4Q assumes TLS is already in place.

Payload protection layer (4Q): 4Q protects the payload itself, independent of transport. This uses hybrid encryption:

  • A symmetric cipher (e.g., AES-256-GCM) encrypts the payload for speed
  • An asymmetric mechanism protects the symmetric key

The asymmetric mechanism can be:

  • RSA key wrapping: The symmetric key is encrypted with the recipient's RSA public key
  • ML-KEM key encapsulation: A post-quantum mechanism that produces a shared secret

Why both layers matter: TLS protects data in transit. Payload protection ensures only the intended recipient (with the private key) can decrypt, even if the payload is stored, forwarded, or logged along the way.

Tenant and Organization Model

The platform uses a hierarchical structure for multi-tenant isolation:

  • Tenant: A single customer account (one per customer)
  • Organization: Created within a tenant for grouping (e.g., separate business units)
  • Policies: Defined within an organization

This means a single customer account can manage multiple organizations, each with its own policies and keys, while maintaining complete isolation between tenants.

Algorithm Agility

Changing a service's encryption scheme is a policy update, not a code change. This is the central value proposition.

When a bank announces migration to post-quantum cryptography, a 4Q administrator updates the policy. From that moment, every /protect call using that policy produces the new protected payload. No application code is modified, no services are redeployed.

Audit Trail

Every /protect and /unprotect call is logged with metadata:

  • Which tenant and organization
  • Which policy
  • Which algorithm and key version
  • Timestamp and response status

The audit trail never stores plaintext or ciphertext payloads — only operational metadata. This serves both compliance verification and operational debugging.

What's Next