Write Side-Channel-Aware Code

What you will learn

This lesson covers:

Timing leakage
Cache leakage
Page-fault leakage
Branch leakage
Input and output metadata
Constant-time programming
Data-oblivious execution
Padding and batching

Direct memory protection is not enough

A TEE may stop an attacker from directly reading protected memory.

The attacker may still observe effects produced by the computation.

These effects are called side channels.

Examples include:

Execution time
Memory-access pattern
Cache use
Page faults
Branch behaviour
Interrupt frequency
Request size
Response size
Power use
Network timing

The protected secret remains inside the TEE, but information about it escapes indirectly.

Side-channel leakage map showing a protected TEE secret while timing, cache access, page faults, branch behavior, network metadata, and output size remain observable to a privileged host.

Timing leakage

Consider:

`` function check_password(input, secret): for i in range(length(secret)): if input[i] != secret[i]: return false return true ``

The function stops at the first mismatch.

An attacker who measures execution time may learn how many initial characters match.

A safer comparison performs a fixed pattern of work:

``` difference = 0

for i in range(FIXED_LENGTH): difference |= input[i] XOR secret[i]

return difference == 0 ```

💡

Compiler behaviour and hardware effects still matter — use reviewed constant-time cryptographic libraries rather than inventing your own primitives.

Secret-dependent branches

A branch such as:

`` if secret_bit == 1: perform_operation_A() else: perform_operation_B() ``

may leak through:

Timing
Branch predictor
Cache
Instruction fetch
Page access

Replace secret-dependent control flow where practical with constant-time selection.

Secret-dependent memory access

This lookup may leak:

`` value = table[secret_index] ``

The attacker may infer which cache line or page was accessed.

Possible mitigations include:

Constant-time lookup
Scanning full table
Oblivious data structure
Bit-sliced implementation
ORAM-style access
Batching and shuffling

These mitigations may add large costs.

Controlled-channel attacks

A malicious operating system may manipulate page permissions and observe page faults to learn an enclave's page-level access pattern.

Research on SGX has shown that a privileged host can use page-table and interrupt control to learn detailed execution behaviour without directly reading enclave memory.

More recent work continues to show that controlled-channel and fine-grained interrupt techniques remain relevant to enclave analysis.

Cache attacks

Cores and processes may share caches.

An attacker can measure cache behaviour to infer:

Which code ran
Which table entry was used
Which key-dependent operation occurred
Which model layer or data path was active

Practical research has demonstrated cache attacks against SGX workloads, including cryptographic and genomic-processing examples.

Page-level versus cache-level leakage

Page-level

Coarser granularity
May reveal which 4 KB region was accessed
Host can induce and observe faults

Cache-level

Finer granularity
May reveal cache-line access
Often more difficult to measure
Shared hardware can amplify leakage

A defense against one channel may not defend against the other.

Page-level leakage reveals which memory page was accessed, while cache-level leakage can reveal finer-grained accesses within that page.

Network metadata

A perfectly constant-time enclave can still leak through its network behaviour.

Observers may learn:

When a user connects
Request size
Response size
Number of requests
Time between requests
Processing duration
Retry behaviour

Mitigations include:

Fixed-size messages
Padding
Batching
Delayed responses
Cover traffic
Request mixing

These protections add bandwidth and latency.

Output leakage

The application output may reveal more than the side channels.

Example:

A private medical query returns exact results for a group of one person.

The TEE correctly protected the input during execution.

The output reveals the person's condition.

Side-channel-safe execution does not replace:

Data minimization
Query restriction
Differential privacy
Minimum group size
Output filtering

Data-oblivious programming

A data-oblivious program aims to keep observable execution behaviour independent of secret values.

This may require:

Fixed iteration count
Fixed memory-access pattern
No secret-dependent branch
Fixed-size messages
Fixed output timing
Fixed resource allocation

Complete obliviousness can be expensive or impossible for a large general-purpose application.

Developers should identify the most sensitive operations and decide which leakage is acceptable.

Data-oblivious execution showing two different secret inputs producing the same observable branch pattern, memory-access pattern, iteration count, and message size.

Side-channel review questions

For every sensitive function, ask:

1. Does execution time depend on the secret? 2. Does control flow depend on the secret? 3. Does memory location depend on the secret? 4. Does output length depend on the secret? 5. Does the number of host calls depend on the secret? 6. Does error type depend on the secret? 7. Does storage access depend on the secret? 8. Does model execution path depend on the input? 9. Can the host interrupt at chosen points? 10. Can repeated queries amplify leakage?

Example: Private inference

A model may keep prompts and weights inside a confidential CPU and GPU environment.

The observer may still learn:

Prompt length
Number of generated tokens
Generation speed
Model size
Batching pattern
Whether a safety path was triggered

Possible mitigations include:

Input padding
Output buckets
Fixed generation limits
Request batching
Restricted telemetry

Side-channel testing

Testing methods may include:

Timing distributions
Cache-performance analysis
Page-fault traces
Differential input testing
Repeated-query analysis
Static analysis for secret-dependent branches
Dynamic instrumentation
Manual cryptographic code review

A successful test does not prove the absence of every side channel.

It provides evidence about tested channels and conditions.

Developer exercise

Review this operation:

`` function lookup_user(secret_user_id): record = database[secret_user_id] if record.is_vip: run_extended_analysis(record) return record.score ``

List leakage through:

Memory access
Branches
Timing
Output
Storage
Network

Rewrite the design to reduce two of those channels.

Common mistakes

⚠

**Assuming encrypted memory prevents side channels** — Encryption hides content, not access patterns. **Writing custom cryptography** — Use reviewed constant-time libraries. **Fixing timing while leaving output size variable** — Both dimensions must be considered. **Ignoring repeated-query attacks** — Repeated queries can amplify small per-query leakage. **Ignoring GPU and device-side leakage** — Device memory and PCIe bus activity may also leak. **Describing an application as "side-channel resistant" without naming tested channels** — The claim must name which channels were tested. **Applying expensive obliviousness to every operation without analysis** — Focus mitigations on the highest-sensitivity operations.

Key takeaways

Side channels reveal indirect information.
Secret-dependent branches and memory access are common causes.
Page-fault and cache channels can be controlled by privileged attackers.
Network and output metadata remain outside processor protections.
Mitigations have performance and usability costs.
Document which channels were tested and which remain.

Check your understanding

1. How can a page-fault trace reveal a secret? 2. Why can constant-time code still leak through output size? 3. What is a secret-dependent memory access? 4. Why are repeated queries dangerous? 5. What does data-oblivious execution attempt to hide?