Building Runevault: An Open-Hardware Authenticator Platform for the Modern Web

Authentication has evolved dramatically over the past decade. We moved from plaintext passwords to hashed credentials, layered on SMS one-time codes, and eventually embraced software-based TOTP apps. Yet, as reverse-proxy phishing kits become more accessible, software-based authentication is no longer the gold standard it once was.

Hardware security tokens represent the highest tier of defense against account takeover. However, most commercial solutions exist as closed ecosystems. Runevault was conceived to explore a different angle: what if a hardware authenticator platform was fully transparent, easily auditable, and engineered specifically around developer ergonomics?

The Architecture: Bridging Silicon and the Browser

Runevault is an end-to-end authentication ecosystem comprising dedicated hardware, custom firmware, and high-level client libraries. Rather than relying on black-box proprietary implementations, Runevault leverages standard cryptographic primitives implemented over open specifications like FIDO2 and WebAuthn.

At the hardware level, Runevault separates operational logic from cryptographic storage:

• Microcontroller Core: An embedded processor handles USB Human Interface Device (HID) communication, NFC transmission, and interface state logic.
• Secure Element: High-risk operations—including private key generation, ECDSA/Ed25519 signing, and monotonic counter increments—are delegated to a tamper-resistant secure enclave.
• Physical User Presence: Physical verification requires capacitive touch sensing to defeat automated malware execution attempts on the host machine.

FIDO2 and CTAP2 Implementation

The heart of Runevault’s firmware lies in its implementation of the Client-to-Authenticator Protocol (CTAP2). When a web browser initiates a navigator.credentials.create() or navigator.credentials.get() request via the WebAuthn API, the operating system routes that payload directly to Runevault over USB HID.

The device validates the origin hash against the stored credential metadata. If user presence is verified via touch, the secure element signs the challenge using the corresponding origin-bound private key. Because keys are mathematically tied to a specific domain name, man-in-the-middle phishing attacks fail completely; an attacker hosting an identical clone of a service cannot coerce Runevault into signing for the legitimate domain.

Developer Tooling and Lifecycle Management

A major design goal of Runevault was eliminating the friction often associated with hardware token administration. In addition to native browser compatibility, the platform includes an extensible CLI and a companion local daemon built in Rust.

Through this interface, developers and system administrators can:

• Provision device certificates and inject custom attestation chains.
• Inspect resident credentials (passkeys) stored on the device with fine-grained revocation controls.
• Configure device-level fallback options, such as customizable PIN policies and brute-force lockouts.
• Integrate hardware-backed challenge-response signing into terminal workflows, such as Git commit signing and SSH agent bridging.

Lessons from the Full-Stack Frontier

Designing a system like Runevault offers unique challenges that rarely appear in traditional web development. Memory constraints on embedded chips require extreme care with dynamic allocation, especially when parsing nested CBOR payloads transmitted during CTAP2 exchanges. Furthermore, cross-platform USB driver quirks require thorough abstraction layers to ensure stable communication across Linux, macOS, and Windows.

Runevault demonstrates that security does not have to come at the expense of developer curiosity. By marrying modern web authentication standards with transparent hardware architecture, we can build identity verification systems that are both resilient to sophisticated attacks and open to community scrutiny.