Platform Cryptographic and Key Management Specification

1. Scope

ACRA provides cryptographic protection for platform-managed storage, service-to-service communication, and secret distribution inside enclaves. This specification defines:

• How secrets are stored and delivered
• How encryption is enforced for data at rest
• How encryption is enforced for data in transit
• How keys and certificates are rotated

This specification describes platform mechanisms rather than application-level cryptographic logic. Application teams may still implement workload-specific encryption where required, but the baseline protections described here are enforced by the platform.

Cryptographic Control Summary

Control Area	Platform Mechanism	Scope
Secret storage	Platform-managed secret store	Credentials, tokens, encryption keys
Encryption at rest	Storage-layer encryption (Ceph)	Databases, persistent volumes, object storage
Encryption in transit	Service mesh mTLS (Istio)	Service-to-service and boundary traffic
Key rotation	Platform lifecycle operations	TLS certificates, credentials, signing keys
Audit visibility	Control plane logging	Secret changes, credential injection, rotation events

2. Secret Storage Model

ACRA stores secrets in a dedicated secret and key management layer rather than embedding them in application code, static configuration, or container images. Platform operators inject credentials into workloads at deployment or runtime so that applications receive only the material they are authorised to use.

2.1 Principles

The secret storage model follows these rules:

• Secrets are stored centrally in a platform-managed secret store
• Secrets are not committed into source code or deployment manifests
• Workloads receive secrets through controlled injection paths
• Access to secrets is scoped by role, service identity, and enclave boundary
• Secret use and administrative changes should be auditable

This design reduces the risk of credential sprawl and limits the impact of a compromised workload.

2.2 Scope Boundaries

Boundary	Secret Access Behaviour
Control plane	Manages secret lifecycle, distribution, and policy
Enclave	Receives only secrets explicitly authorised for that enclave
Workload / service	Receives only the credentials required for its function
External systems	Do not receive direct access to internal secret stores

2.3 Secret Classes

The platform may manage several classes of secret material:

• Service credentials
• Database credentials
• API tokens
• Encryption keys
• TLS certificates and private keys
• Signing keys used by platform services

Each class should be stored, distributed, and rotated according to policy rather than manual handling.

3. Encryption at Rest

ACRA encrypts platform-managed storage at rest by default. Ceph provides encryption for storage services, allowing applications to inherit encryption without implementing their own storage-layer controls.

3.1 Protected Storage Surfaces

Encryption at rest applies to platform-managed persistence layers such as:

• Object and file storage
• Database volumes
• Persistent application data
• Stored artefacts used by enclave services

This ensures that data written to underlying storage remains protected if physical media, raw volumes, or storage backends are exposed outside authorised execution paths.

3.2 Enforcement Model

Encryption at rest is implemented as infrastructure and platform behaviour. Applications write data through the normal platform storage path, and the platform applies encryption beneath the workload layer.

Consequences:

• Encryption does not depend on each application team configuring it correctly
• Storage protection remains consistent across platform services and workloads

3.3 Operational Note

Where workloads implement their own application-level encryption, this is additive. It does not replace the platform requirement for encrypted persistent storage.

4. Encryption in Transit

ACRA encrypts traffic in transit across platform communication paths. Internal service communication is protected by the service mesh. Platform documentation identifies Istio as the mechanism providing encryption in transit and service-level authorisation.

4.1 Protected Communication Paths

Encryption in transit applies to:

• Service-to-service communication inside an enclave
• Communication between authorised platform components
• Ingress and egress traffic crossing enclave boundaries
• Replication or federation paths where explicitly allowed

4.2 Enforcement Model

Transport protection relies on platform-managed identities and certificates rather than developer-managed connection settings. This allows the platform to enforce:

• Authenticated service identities
• Encrypted service communication channels
• Policy-based authorisation

4.3 Expected Properties

The in-transit encryption layer provides:

• Confidentiality of traffic on network paths
• Integrity protection against tampering
• Authenticated peer identity
• Consistent baseline security across enclave workloads

5. Key Rotation

Key rotation ensures that long-lived cryptographic material does not remain valid indefinitely and that compromised or expired keys can be replaced without redesigning the application environment.

5.1 Rotation Objectives

Key rotation should:

• Reduce exposure from long-lived key material
• Support certificate expiry and renewal
• Enable rapid replacement after suspected compromise
• Preserve service continuity during rollover

5.2 Key Types in Scope

Key Type	Typical Use	Rotation Expectation
TLS certificates	Service identity and transport encryption	Regular scheduled rotation and renewal
Secret-store master keys	Protection of stored secret material	Rotated through controlled administrative procedures
Service credentials	Database, API, or inter-service access	Rotated on schedule or when roles change
Signing keys	Platform assertions or artefact signing	Rotated during controlled release processes

5.3 Rotation Model

The platform supports rotation through lifecycle operations rather than manual secret replacement:

1. New key material is generated or imported into the platform secret management layer
2. Services begin trusting or consuming the replacement material
3. Old key material is withdrawn after overlap or cutover
4. The change is logged for audit and review

5.4 Rotation Triggers

Rotation may be triggered by:

• Scheduled expiry windows
• Personnel or role changes
• Enclave rebuild or service redeployment
• Suspected compromise
• Cryptographic policy changes

5.5 Failure Behaviour

If rotation fails, the platform fails in a controlled manner rather than silently downgrading security. Possible behaviour includes:

• Preventing new sessions with invalid credentials
• Preserving existing service state until replacement keys are available
• Surfacing failures through platform health visibility
• Blocking rollout if dependencies cannot validate replacement keys

6. Audit and Control Considerations

Cryptographic and secret management actions should be observable through platform audit systems. Administrative events that should be auditable include:

• Secret creation
• Secret updates
• Credential injection
• Certificate renewal
• Key rotation
• Access denial due to invalid or expired credentials

This ensures traceability for operational investigation and security review.

7. Resulting Security Properties

The cryptographic and key management model provides the following platform properties:

• Secrets are centrally controlled rather than embedded in application code
• Platform-managed storage is encrypted at rest
• Service and boundary traffic is encrypted in transit
• Keys and certificates can be replaced through controlled operational processes
• Cryptographic control aligns with enclave boundaries and platform policy

Together these controls reduce configuration risk, limit credential exposure, and make cryptographic protection a platform responsibility rather than an application-by-application burden.

Platform Cryptographic Architecture

The diagram below represents the cryptographic control flow illustrated on page 6 of the specification.

Trust Boundary Model

Cryptographic controls operate across several platform boundaries.

The control plane manages secret lifecycle and certificate issuance. Enclaves receive only authorised credentials. Service-to-service communication is encrypted through the service mesh. Persistent storage is encrypted beneath the workload layer.

50%