Leakage outside the intended interface
A side-channel attack infers a secret from characteristics of implementation or operation rather than from the intended output. Signals include execution time, cache and memory access, branch behavior, power, electromagnetic or acoustic emissions, temperature, resource contention, packet size, error differences, and retry behavior.
The attacker observes a correlation between secret-dependent work and a measurable signal. Repeated observations, chosen inputs, or co-location can turn a small difference into useful information.
Threat conditions
State what the attacker can control and measure: local process scheduling, shared cores or caches, network requests, high-resolution time, physical proximity, power input, device access, or error output. State the number of samples, noise, secret lifetime, and whether the attacker can adapt inputs.
A remote timing attack and a laboratory power attack have different costs and controls. Do not dismiss a channel only because one measurement is noisy.
Prevention and reduction
Use reviewed implementations designed for the relevant side-channel model. Avoid secret-dependent branches, memory access, early exit, error text, and variable work where the signal matters. Isolate high-risk workloads from hostile co-tenants and shared devices. Rate-limit observations, rotate secrets, reduce precision and unnecessary output, and use hardware countermeasures for physical adversaries.
Measure the complete system. A constant-time primitive can still leak through key selection, parsing, allocation, logs, caches, protocol errors, or caller behavior.
Failure and residual risk
Artificial random delays often add noise without removing the signal and can be averaged out. Compiler optimization and new hardware can invalidate source-level assumptions. Virtualization can create shared-resource channels. A mitigation for timing may leave power, cache, or error leakage.
Testing can show a detectable leak under tested conditions. Failure to detect one is not proof of absence. The accepted residual risk must name attacker access, measurement quality, secret value, and mitigation coverage.
Pomerium boundary
Pomerium normalizes and protects documented access flows, but timing, size, error, cache, host, and application behavior can still reveal information. Upstream applications and operators own constant-time secret handling, co-tenant isolation, error design, resource limits, and hardware threat decisions. A Pomerium denial must not be treated as proof that no indirect signal escaped.
Evaluation checklist
- Which secret-dependent time, memory, cache, power, emission, resource, size, or error signal can the attacker observe?
- What access, precision, number of samples, chosen inputs, and co-location does the attacker have?
- Does the reviewed implementation and deployment address the exact channel, compiler, hardware, and caller behavior?
- Can a negative result be distinguished without revealing whether an identity, key, object, or policy condition exists?
- Which signal and adversary remain after the mitigation, and how quickly can the exposed secret be rotated?
