Analyze Side-Channel and Shared-Resource Risk

Assets and security objectives

List secrets and protected facts: key bits, password validity, account existence, object presence, policy result, tenant activity, data length, request type, workload identity, or high-domain state. Define how long each value remains useful and how quickly it can rotate.

Write the objective as an observable distinction. Example: a remote caller must not distinguish whether a named account exists from status, body, size, connection behavior, or response-time distribution. For co-tenants, one workload must not infer another tenant's cryptographic key or request pattern through shared resources.

Actors and components

Name victim, observer, deliberate sender if any, network position, scheduler, host, hypervisor, runtime, processor, caches, memory, devices, cryptographic library, application caller, gateway, logging system, and physical environment.

For the observer, record:

• Local, co-tenant, network, management, or physical access.
• Chosen inputs and ability to repeat or reset the victim.
• Time precision, cache or performance counters, power or emission probes, error access, and resource controls.
• Sample count, observation duration, noise, cost, and chance of detection.

Trust boundaries

Draw where secrets enter and leave hardware, kernel, process, library, protocol, proxy, and application boundaries. Mark shared CPU cores, caches, memory buses, NUMA nodes, devices, clocks, queues, allocators, quotas, files, logs, and networks.

Treat error handling, retry, length, compression, pagination, rate limits, and connection reuse as part of the observable interface. Mark compilation and hardware generation because constant-time properties can change across them.

Normal request path

Trace one secret operation from parsed input through identity lookup, key selection, authorization, cryptographic work, storage, response, log, and retry. For each step, ask whether secret state changes branch, loop count, memory address, allocation, I/O, error, packet size, resource use, or completion time.

For a covert-channel case, trace how a cooperating sender can modulate shared state and how a receiver samples it. Estimate symbols, bandwidth, error correction, and the smallest useful message.

Failure path: remote distinction oracle

An authentication or object lookup returns the same status and text for missing and unauthorized objects, but a database lookup and password operation occur only for existing records. A remote attacker sends many requests, controls connection reuse, and separates the latency distributions.

Mitigate through uniform work where feasible, fixed validation order, safe credential verification for nonexistent accounts, response and size normalization, rate and abuse controls, and short secret lifetime. Test end-to-end at realistic network noise and load. Review logs and upstream behavior for remaining distinctions.

Failure path: hostile co-tenant

Two workloads share cores, last-level cache, memory bandwidth, or an accelerator. The victim's secret-dependent implementation changes shared-resource use. The attacker schedules repeated chosen operations and correlates its own measurements.

Use a reviewed implementation for the stated hardware, remove secret-dependent access, avoid hostile co-tenancy where consequence warrants it, partition or pin resources when supported, disable unnecessary counters and shared devices, and rotate exposed keys. Test on the actual processor, compiler, hypervisor, and deployment mode.

Failure path: deliberate covert signal

A high-domain process cannot write to a low-domain channel, but it can vary CPU load or a shared quota. A low-domain process observes scheduling or allocation and decodes a small message.

Reduce shared state, constrain scheduling and resource visibility, rate-limit transitions, monitor suspicious coordination, and minimize the sender's access to secrets. Decide whether the residual bandwidth can leak a valuable value during its lifetime.

Test and evidence plan

Use known fixed and varying secret groups, large sample sets, distribution analysis, and independent review. Control for warm-up, frequency scaling, network reuse, caches, garbage collection, and load. Repeat across builds and hardware. Add regression tests for source and compiled artifacts where practical.

Record confidence and limits. A non-detection result covers only the tested channel, environment, sample count, and analysis. Combine statistical testing with implementation review and deployment isolation evidence.

Design tradeoffs and residual risk

Constant-resource behavior can reduce performance. Hardware partitioning reduces density. Uniform errors can reduce support detail. Noise and jitter can harm availability and may not remove a signal. Dedicated hosts reduce co-tenancy and retain firmware, management, and physical channels.

Prioritize by secret value, attacker access, bandwidth, measurement cost, and exposure time. State the channels you do not address and the resulting rotation, monitoring, or placement requirement.

Pomerium boundary

Pomerium can normalize documented access failures and restrict reachability. It cannot make an upstream cryptographic or identity implementation constant-time, remove shared-host channels, or protect physical hardware from probes. Include Pomerium, load balancers, upstreams, and identity providers in end-to-end response measurements because any layer can recreate a distinction.

Exercise

Choose one login, token validation, key use, or tenant workload. Build the secret-signal-observer table. Capture at least two candidate signals and estimate attacker sample cost. Implement one software mitigation and one deployment control.

Run fixed-versus-varying tests before and after the change. Then create one deliberate low-bandwidth covert signal through an available shared resource. Record what the result proves, what it does not prove, and how key or fact lifetime changes the risk.

Evaluation checklist

• Are secret, victim or sender, observer, signal, measurement access, samples, noise, and useful lifetime explicit?
• Does the model cover caller, protocol, error, compiler, hardware, scheduler, co-tenant, and physical behavior as applicable?
• Does each mitigation remove or bound the exact signal instead of only adding unmeasured noise?
• Are tests end-to-end on the actual build and platform, with stated statistical and environmental limits?
• Is the residual channel capacity compared with the smallest valuable secret and its rotation time?