The Heartbeat Protocol

At the core of every dead man's switch is a heartbeat protocol — a system that periodically verifies the operator is still active. The elegance of this approach lies in its simplicity: do nothing, and the switch activates.

Modern digital heartbeat systems use multiple channels for verification:

Web-Based Check-In: A simple button click on a dashboard that resets the countdown timer. This is the most common method and works well for daily or weekly intervals.

Email Confirmation: The system sends an email containing a cryptographically signed link. Clicking the link confirms your presence without requiring a login.

API Ping: For technical users, an API endpoint can accept authenticated heartbeat requests. This enables integration with scripts, IoT devices, or monitoring systems.

Each heartbeat resets the system's internal timer. The timer counts down from your configured interval (e.g., 7 days, 30 days) and transitions through defined states if no heartbeat is received.

State Machine Architecture

A well-designed dead man's switch operates as a state machine with clearly defined transitions:

Active State → Everything is normal. The user is checking in regularly, and the countdown timer resets with each heartbeat.

Warning State → The check-in interval has elapsed without a heartbeat. The system sends increasingly urgent notifications. This state typically lasts for a configurable grace period (often 50-100% of the check-in interval).

Released State → The warning period has also elapsed without a heartbeat. The system irreversibly releases the vault contents to designated recipients. This state is final — once released, the vault cannot be re-secured.

The unidirectional nature of the Active → Warning → Released flow is critical. A heartbeat during the Warning state returns the system to Active. But once Released, there's no going back. This immutability is what makes the system trustworthy.

Cryptographic Foundation

The security of a dead man's switch depends entirely on its cryptographic implementation.

Client-Side Encryption: Files are encrypted in the user's browser using AES-256-GCM before being uploaded. The encryption key is derived from a password that never leaves the user's device. The server stores only ciphertext — meaningless bytes without the key.

Key Derivation: The encryption password is processed through PBKDF2 with a unique salt, producing a 256-bit key. This makes brute-force attacks computationally infeasible.

HMAC-Signed Tokens: Heartbeat confirmation links use HMAC signatures to prevent forgery. A valid signature proves the link was generated by the server and hasn't been tampered with.

Timing-Safe Comparisons: All cryptographic comparisons use constant-time algorithms to prevent timing attacks — a subtle but critical security measure that prevents attackers from inferring correct values by measuring response times.

The Release Mechanism

When a dead man's switch triggers, the release mechanism must be reliable, timely, and verifiable.

Notification Dispatch: Recipients receive email notifications containing the vault access link. These emails include the vault's public identifier but NOT the decryption password — that must be communicated separately (e.g., written in the vault's message field, stored in a physical safe).

Time-Limited Access: Released vaults typically have a download window (e.g., 30 days) after which the files expire. This prevents indefinite exposure of sensitive data.

Audit Trail: Every action — heartbeat, warning, release, download — is logged in an immutable audit trail. This provides accountability and helps recipients verify the authenticity of the release.

The separation of access (the download link) from decryption (the password) means that even if the notification email is intercepted, the files remain encrypted and useless without the password shared through a separate channel.