> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zerokeyusb.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security whitepaper

> ZeroKeyUSB's security architecture in one document: offline design, signed firmware, hardware-backed encryption, and PIN protection — with an honest statement of scope.

This whitepaper summarizes how ZeroKeyUSB protects credentials, for security
teams, auditors and procurement. It describes what the device does and,
explicitly, the boundaries of what it protects. For the deeper technical detail,
each section links to the [Software](/firmware/architecture) documentation, which
is fully open-source and verifiable.

## What ZeroKeyUSB is

A hand-held, **offline** credential device based on an ATSAMD21 microcontroller
and an ATECC608A secure element, encapsulated in epoxy resin. It stores logins,
TOTP secrets and short notes, and types them to a host over **USB HID** on a
physical press. It has **no Wi-Fi, Bluetooth, NFC, battery or cloud account**.

## Security architecture

| Layer                     | Mechanism                                                                                                                                                                                                                                          |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Secure boot**           | The bootloader verifies an **ECDSA P-256** signature over the application firmware (via the ATECC608A) before running it. The bootloader region is hardware write-protected (`BOOTPROT`).                                                          |
| **Credential encryption** | Credentials are stored **AES-128-CBC** encrypted in an external EEPROM. The AES key is generated by the ATECC608A's hardware TRNG and **stored inside the chip** (`IsSecret=1`) — it never crosses the I²C bus or reaches host software.           |
| **PIN**                   | A 1–16 digit Master PIN is verified as `SHA-256(PIN ‖ chip-serial)` with a constant-time compare, and rate-limited by a **persistent exponential backoff** re-applied on every boot (see [PIN verification](/firmware/security/pin-verification)). |
| **Randomness**            | All key material, IVs and generated passwords come from the ATECC608A **hardware TRNG**.                                                                                                                                                           |
| **Physical**              | The PCB is **epoxy-encapsulated**; there is no debug path to the application after provisioning, and the config/data zones of the secure element are permanently locked.                                                                           |
| **Airgap**                | Credentials are entered/exported only over USB, on user action. No network stack exists.                                                                                                                                                           |

## Security properties

* **No cloud, no account, no telemetry.** Nothing is transmitted to any server.
* **Secrets stay off the host.** The host receives keystrokes, never the vault.
* **Tamper-resistant key custody.** The AES key and the device are bound; ciphertext from one unit cannot be decrypted by another.
* **Verifiable firmware.** Only ECDSA-signed images run; the source is open for audit.

## Scope and limitations

A credible security statement names its boundaries. ZeroKeyUSB does **not** claim
to protect against:

* **A trusted-host compromise during use.** When you type a credential, it lands
  on the host; if that machine is already compromised, it can capture what is
  typed. The device reduces *storage* exposure, not *in-use* exposure.
* **Plaintext backup on an untrusted host.** The USB backup exports credentials
  in clear text to the connected computer; do it only on a trusted, offline host.
* **A determined physical/lab attacker.** The PIN hash is readable over the I²C
  bus, so an attacker who defeats the epoxy encapsulation and reaches the bus can
  attempt an offline PIN crack. The epoxy and a long PIN are the mitigations;
  there is no destructive self-wipe.

See the [Threat model](/compliance/threat-model) for the full analysis, and
[Security frameworks](/compliance/frameworks) for how this maps to ISO, NIST and
ENS controls.