Threat Model

Not sure whether this product is meant for your situation at all? Start from who Crypt-in is for — the same profession can land on either side of this threat model depending on who the adversary is.

Scope

Protects against

• Theft of device — PC, laptop, external drive
• Unauthorized physical access to PC or server
• Remote exfiltration of encrypted files
• Ransomware targeting already-encrypted files
• Clone of dongle identity via same seed

Does not protect against

• Advanced physical chip attacks — side-channel, fault injection, electron microscope
• Malware with system privileges active during a session
• Server compromise with K_vault already loaded in RAM
• Manual copy of content during an authorized session

Physical attacks requiring chip-level equipment are out of scope — declared, not hidden.

Kit Pro — BLE attack surface

The Kit Pro adds Bluetooth Low Energy for the proximity lock and mobile access. The radio is in the hardware today; the proximity lock feature itself ships Q1 2028 via firmware update. What follows is the threat model it will have. BLE is a wireless attack vector that wired USB simply does not have, so it gets its own threat model.

Protects against

• Passive eavesdropping. The BLE channel uses Ed25519 authentication, X25519 ephemeral key exchange and AEAD encryption. Intercepted BLE traffic yields no access to K_root or to any file key.
• Replay. Ephemeral keys per session mean captured traffic cannot be replayed.

Does not protect against

• Relay attacks. An attacker can relay BLE signals to make the dongle appear present when it is not. The proximity lock is a convenience feature, not a cryptographic guarantee — critical operations always require the USB connection.
• Jamming. An attacker can prevent the proximity lock from triggering. The USB kill switch remains the primary mechanism precisely because it cannot be jammed.
• Pairing attacks on unpatched BLE stacks. Keep your OS and drivers updated.

Recommendation. For maximum security use the Kit Standard, USB only, and rely on physically removing the dongle as the kill switch. Treat Kit Pro BLE as a convenience layer on top of that, never as the primary security mechanism.

The clone of a dongle identity via the same seed is mitigated by K_attestation, which is generated from hardware entropy and is not derivable from the BIP-39 seed — see the key hierarchy.

Zero-knowledge guarantee

lake8.dev is architecturally incapable of providing decryption keys to third parties. This is a construction property, not a policy promise.

“The root secret never leaves the dongle. lake8.dev cannot decrypt your files — not by choice, but because it is technically impossible.”

PIN authentication (July 2026)

Every dongle now requires a PIN on insertion. The PIN is derived from the seed, not chosen by the user, and three wrong attempts lock the dongle permanently — the counter survives a power cycle, so guessing cannot be reset by unplugging. Unlocking after that requires BIP-39 seed recovery and nothing else.

A stolen dongle without the PIN is a piece of plastic.

Dongle binding — where the check happens

The “this file was encrypted with a different dongle” check happens in the app, not in the firmware.

The firmware never receives the dongle public key from the file header. It only verifies that decryption produces a valid GCM tag.

The implication, stated rather than left to be discovered: an attacker with direct access to the HID bus can attempt decryption on any file, regardless of the public key written in the header. The firmware answers to the dongle that is physically connected and unlocked, and to nothing else.

This is consistent with the model as declared elsewhere on this page: security rests on the physical dongle and on the seed inside it, never on the identity claimed by a file header. A header is data an attacker already holds — treating it as an access control would be security theatre.

Practical consequence: the thing to protect is the unlocked dongle, not the .crin file. That is what closing the security window is for.

Secure boot

Production dongles. Secure Boot v2 and Flash Encryption are enabled on production dongles (Kit Standard, Kit Pro — April 2027) and verified on real hardware. The eFuses are burned at first boot, so the dongle runs only firmware signed with the lake8.dev key, JTAG is permanently disabled, and the chip refuses read-flash because it is in Secure Download Mode.

Developer beta units do not. Since 24 August 2026 beta units run the -dev firmware track with the eFuses not burned, which keeps the board reversible but also means CMD_GET_SECRET (0x04) responds and an SPI dump of the flash is readable. Against this threat model a beta dongle covers device theft, not an attacker holding the dongle. The distinction is deliberate and documented on the beta page.

On production dongles the custom-firmware bypass is therefore blocked at the first step. Even if it were not, it would not reach your files: firmware without the seed cannot decrypt existing .crin files, because the file keys derive from the seed and not from anything the dongle hands over. Two independent layers.

Anti-rollback is not implemented yet. It requires OTA support absent from the current firmware and is planned before the public launch; until then a signed but older image could in principle be installed.