Key exchange in offline-capable terminals

Terminals in some deployments — transit, mobile vendors, parts of emerging markets — need to operate offline for extended periods. Key management for these devices is a different problem from an always-connected terminal, and the standard solutions don't always apply cleanly.

Written October 2024 from a set of offline-terminal deployments.

The problem shape

• The terminal needs to authenticate to the acquirer even after offline transactions.
• The keys used offline need to remain valid across the offline period.
• Key rotation must happen when connectivity returns, without disrupting subsequent transactions.
• The offline transaction log needs to be replayable and reconcilable.

Design patterns

Two patterns show up repeatedly:

• Session key pre-derivation. The terminal derives a set of session keys during its last online session, sufficient for a defined offline period. When connectivity returns, the terminal uploads offline transactions signed with those session keys, and receives new session material.
• Rotating master key with expiry. The terminal holds a rotating master key that's valid for a bounded window (typically 30–90 days). Offline transactions accumulate; on reconnect, the terminal uploads them and the master key rotates before the window expires.

Operational discipline

• Time skew tolerance. Offline terminals can drift; the reconciliation logic must tolerate reasonable clock skew without treating it as anomalous.
• Key expiry telemetry. The terminal should surface how close it is to running out of key material. A silent expiry causes a hard failure.
• Reconciliation batching. When a terminal reconnects after a long window, the batch of transactions can be large. The upload path must handle backpressure without dropping messages.

Offline-capable terminals are a smaller share of the market but a critical share for specific merchant categories. The key-exchange design is where the security posture and the operational discipline meet.