Protect Persistent State and Prevent Rollback

What you will learn

This lesson covers:

Sealed state
State versions
Replay
Rollback
Forking
Monotonic counters
External state services
Crash recovery
Migration

Encryption does not prove freshness

A TEE may encrypt and authenticate data before storing it outside the trusted boundary.

This protects against:

Unauthorized reading
Unauthorized modification
Forged ciphertext

It does not automatically prove that the ciphertext is the newest valid state.

A malicious host can restore an older file that was genuinely created by the application.

Example: Balance rollback

State 8:

`` balance = 100 version = 8 ``

State 9:

`` balance = 20 version = 9 ``

Both states are encrypted and authenticated.

The host replaces state 9 with state 8.

The authentication check passes because state 8 is genuine. The application now operates on stale state.

Rollback attack showing a malicious host replacing current state v9 with an older authenticated state v8, which still passes authentication and is mistakenly accepted as current.

Replay, rollback, and forking

Replay

An old valid message or request is submitted again.

Example:

Reusing an old withdrawal request

Rollback

The system's state is restored to an older valid version.

Example:

Replacing a current sealed database with an older snapshot

Forking

Different clients are shown different valid state histories.

Example:

Client A sees version 10.
Client B sees a separate version 10 derived from version 9.
Both histories appear locally valid.

Forking is especially important in distributed and Web3 systems.

Visual comparison of replay, rollback, and forking, showing repeated valid requests, restoration of an older valid state, and multiple conflicting histories from the same state.

State-continuity invariant

Define a rule that must always hold.

Example:

`` accepted_version > previously_accepted_version ``

Or:

`` new_state.previous_hash == current_state.hash ``

The TEE needs a trusted way to remember or verify the current state.

State-continuity check showing how a TEE accepts a newer valid state while rejecting an older state that would break forward state progression.

Hash-chained state

A state record may contain:

`` version state_data previous_state_hash current_state_hash signature ``

The new state commits to the previous state.

This detects modification of the chain.

It does not stop the host from presenting an older valid chain unless the TEE knows which version is current.

Hash-chained state showing how each version references the previous state hash so tampering or an unexpected old state breaks continuity.

Monotonic counters

A monotonic counter moves only forward.

A stored state can include the expected counter value.

The TEE checks:

`` stored_counter == trusted_counter ``

Then increments the trusted counter when saving new state.

Possible counter sources include:

Hardware counter
Secure platform service
Remote consensus service
Distributed database
Blockchain contract

Hardware counters may have limits involving:

Performance
Wear
Availability
Migration
Platform dependence

Monotonic counter showing valid forward progression from 10 to 13 and rejection of an older counter value during rollback.

External freshness service

A TEE may store the latest state hash with an external service.

The service may provide:

Latest version
Signed checkpoint
Append-only log
Quorum confirmation

This creates a new trusted component.

Ask:

Can the service lie?
Can it fork clients?
Can it become unavailable?
Can the host block access to it?
Can multiple operators collude?

Blockchain as a state anchor

A public blockchain can record:

State commitment
Sequence number
Enclave identity
Update transaction
Recovery authorization

Benefits may include:

Shared state visibility
Ordered updates
Tamper-evident history
Multiple independent observers

Costs include:

Public metadata
Transaction fees
Confirmation delay
Smart contract risk
Chain reorganization assumptions
Censorship risk

The blockchain does not automatically protect the privacy of the committed metadata.

Atomic state update

The application should avoid partial updates.

A basic flow may be:

1. Read current protected state. 2. Verify authentication. 3. Check version. 4. Perform operation. 5. Create new state. 6. Commit new external checkpoint. 7. Write sealed state. 8. Confirm success. 9. Mark previous state obsolete.

The exact order depends on recovery requirements.

A crash between steps can create inconsistent state.

Write-ahead log

A write-ahead log records intended changes before the main state is updated.

The TEE may:

1. Write signed intent. 2. Confirm durable storage. 3. Apply state change. 4. Write completion record. 5. Update current checkpoint.

The log must also have anti-rollback protection.

Duplicate TEE instances

Two valid instances may start from the same sealed state.

Both may produce new valid state.

This creates a fork even without breaking encryption.

Possible controls include:

Lease service
Leader election
Distributed lock
Consensus protocol
Single-use state token
Threshold authorization
On-chain sequence number

Two valid TEE instances start from the same sealed state and independently produce different successor states, creating conflicting histories and a state fork.

Recovery and migration

Recovery may require moving state to:

New machine
New TEE platform
New software version
New cloud provider
New region

A migration protocol may:

1. Attest old workload. 2. Attest new workload. 3. Check migration policy. 4. Establish a protected channel. 5. Transfer state and keys. 6. Record migration checkpoint. 7. Revoke old instance. 8. Confirm that old state cannot continue.

Secure TEE migration showing a single attested handover of state to one successor instance, contrasted with unsafe recovery that restores the same state into multiple TEEs and creates a fork.

Example: Validator signing state

A validator key is protected inside a TEE.

The TEE tracks the latest signed block height.

The host restores an older signing-state snapshot.

The enclave may now sign a conflicting message for a height it had already signed.

The key was never extracted.

The rollback still caused a security failure.

The correct protected asset is:

Key bytes
Signing policy
Signing history
Current state version

💡

Protecting a key is not the same as protecting key usage. Rollback can cause double-signing without ever extracting the key material itself.

Developer exercise

Design state continuity for a private auction.

The application must prevent:

Bid replay
Deadline rollback
Duplicate winner selection
Two enclave instances publishing different winners

Choose one state anchor and explain:

Trust assumptions
Failure mode
Recovery process
Metadata leakage
Availability cost

Common mistakes

⚠

**Assuming authenticated encryption prevents rollback** — Authentication only confirms a ciphertext was created by the approved key; it does not confirm the ciphertext is the newest. **Storing the version only inside the sealed file** — The version counter must be anchored to a source the host cannot substitute. **Starting multiple instances from the same snapshot** — Duplicate instances create forks even without breaking encryption. **Using host time as the only deadline source** — A malicious host can roll back or freeze time. **Ignoring crash consistency** — A crash between write steps can leave state inconsistent. **Allowing old software to open new state** — Update migration should reject states created by newer versions unless explicitly allowed. **Migrating keys without revoking the old instance** — Both old and new instances could sign concurrently until revocation completes.

Key takeaways

Authentic storage does not prove that state is current.
Replay, rollback, and forking are different problems.
State continuity needs a trusted forward-moving reference.
External counters and blockchains introduce new assumptions.
Crash recovery and migration must be designed before production.

Check your understanding

1. Why does an authenticated old state still pass verification? 2. What is the difference between rollback and forking? 3. Why is a version stored only inside sealed data insufficient? 4. How can two valid TEE instances create a fork? 5. What new risks appear when a blockchain is used as a state anchor?