Security Model

The right enemy.

If you are still deciding whether Crypt-in is the right tool for you at all, who Crypt-in is for answers that question with concrete profiles. This page explains why the product is built the way it is.

Who should not buy Crypt-in

Crypt-in costs less than €100. It solves problems worth less than €100.

If you have known, serious security problems — confirmed industrial espionage, state-level adversaries, secrets worth millions — this product will not save you. Not because it is poorly made, but because your threat model requires a cybersecurity agency: physical surveillance, penetration testing, forensic analysis, and a budget in the order of €100,000 a year. Not a €5 dongle and a Windows app.

Crypt-in is for people who want to protect their data from device theft, unauthorised access and unwanted curiosity — not from intelligence agencies or professional attackers with unlimited resources.

If you are in the second group, call a specialised agency. Seriously.

Most people, most of the time, face threats on the left of this scale. Crypt-in was built for that.If your threat sits on the right, you need tools and expertise costing significantly more than €100 — and that is completely legitimate. The answer to that problem exists. It is just not us.

The three levels — economic, not technological

Anyone who wants your data has to pass three levels in sequence. Each one costs more resources, more time and more expertise than the one before.

Level	Function	Cost for the attacker
1 — PIN	Physical authentication	€0 — but only 3 attempts
2 — Firmware	Hardware resistance	€1,000–5,000 in lab equipment
3 — Seed	Master secret	€10,000+ and a coordinated operation

The barrier is not technological. It is economic.

By the time you reach the seed you are running a professional intelligence operation costing tens of thousands of euros and weeks of planning. For that there are specialised agencies charging €100,000 a year. We are not them, and we do not want to be.

Before the PIN — the paradox of theft

Without a PIN the dongle is the key to the castle. Whoever holds it walks in. No need to copy it, analyse it, or extract anything from it.

That was the problem. The PIN is the answer.

With the PIN — the arithmetic is on your side

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

PIN space:               1,000,000 combinations
Attempts available:      3
Probability of guessing: 3 / 1,000,000 = 0.0003 %
After 3 wrong attempts:  permanent lock
Unlock:                  only with your 24 words

Verified on real hardware — this is not theory. A test dongle with PIN 902579 locked after three wrong attempts and did not unlock when the correct PIN was entered afterwards. Only recovery with the 24 words restored access.

The PIN is not chosen by you. It is generated by the dongle at first boot, derived from your 24 words through HKDF-SHA256. You cannot change it and you cannot pick it, which also means you cannot accidentally pick 000000 or your date of birth.

Same seed, same PIN, always, on any dongle. That is what makes backup verification possible: if the backup dongle shows the same PIN, the backup is correct.

One more detail that matters: the wrong-attempt counter is stored in flash, not in RAM. Power-cycling the dongle between guesses does not reset it — which is the first thing anyone would try.

Technical note. The lock lives in firmware. An attacker with prolonged physical access and lab equipment — JTAG programmer, hardware debugger — can reset the attempt counter. Even then your data stays safe, for the reason in the next section.

Closing the security window

Once the dongle is unlocked, the session stays open for as long as the dongle is powered. Auto-lock kicks in after roughly 10 minutes of complete inactivity.

To close the window immediately:

1. Unplug the dongle.
2. Wait at least 5 seconds before plugging it back in.

Plugging it back too quickly may not power the chip down completely: the internal capacitors keep it briefly alive, and the unlocked state survives with them.

In practice: unplug, count to five, plug back in.

This matters when you step away from a machine you do not control, or hand the laptop to someone else. It is the same habit as locking your screen, applied to the dongle.

File binding — where the check happens

The “wrong dongle” check — verifying that a .crin file was encrypted by this specific dongle — happens in the app, not in the firmware.

The firmware decrypts for any unlocked dongle physically present, regardless of the public key declared in the .crin header. If the wrong dongle is used the GCM tag does not verify and decryption fails: the file does not open either way.

What the host-side check buys is a clearer error. The app compares the pubkey before sending any data to the dongle, so you get “wrong dongle” instead of “corrupted file”.

This is by design and declared, both here and in the red team report. Security rests on possession of the physical dongle, not on the identity claimed in a file header.

Chunk counters

seq and total are exactly 3 bytes each. Verified in red team Session 3 (F-WRAP): a ~3.63 MB file, about 66,000 chunks — past the 65,536 boundary a 2-byte counter would hit. Round trip identical, GCM tag verified. The wraparound described in older code comments was historical and has been corrected.

Three bytes puts the theoretical maximum at ~900 MB.

You will not reach it. The Windows client enforces a 4.8 MB limit (MaxEncryptBytes = 5,000,000 bytes), because USB HID throughput of roughly 27.8 KB/s makes larger files impractical: 4.8 MB already takes about three minutes, and the theoretical maximum would take over nine hours.

Developers using the SDK directly are not subject to that limit — it lives in the client, not in the firmware or the format.

Full details: red team report.

PIN transmission over USB

The PIN is transmitted in cleartext over the USB HID bus during CMD_VERIFY_PIN (0x08).

This is a confirmed finding from the August 2026 red team (F-003/B1): the PIN appears at offset 3 of the HID report as 6 ASCII bytes, with no challenge-response and no anti-replay.

This is out of the declared perimeter. It requires a compromised PC with an active USB sniffer — USBPcap or equivalent. If an attacker has that level of access to your machine, you have far larger problems than the dongle PIN.

Fix planned: challenge-response for CMD_VERIFY_PIN, Q2 2027, with the WiFi firmware release — after the Q1 2027 public launch.

Full details: red team report.

Known open finding: shared unlock session

During the August 2026 red team an open finding was confirmed, and it is the reason the section above matters more than a convenience habit.

The unlock state is global to the chip, not bound to the handle or the process that authenticated the PIN. A second, unauthenticated HID handle can reach gated commands during an active unlock window — including the 0x0E decrypt oracle.

Mitigation in place. Auto-lock after roughly 10 minutes of complete inactivity. But every HID command resets that timer, so an active attacker polling the session keeps it open indefinitely: auto-lock protects a genuinely idle chip, not a chip under attack. Unplugging closes the window immediately — wait at least 5 seconds before reconnecting.

Fix planned: session binding (handle and process authentication), Q2 2027 with the WiFi firmware release — after the Q1 2027 public launch. Until then the mitigations above are what stands between an unlocked dongle and a hostile process on the same machine.

What this finding does not do: it does not open a .crin file at rest. Without an active unlock window the file stays closed, and the attack needs code already running on your machine while the dongle is plugged in and unlocked.

Full details, with severities and exact response bytes: red team report.

F-004 — licence status pre-auth (remediated)

Prior to August 2026, CMD_GET_LICENSE_STATUS (0x0C) responded without PIN authentication, revealing licence validity and expiry to anyone with USB access to the dongle.

Status: remediated. 0x0C now requires the PIN and returns ERR_PIN_REQUIRED on a locked dongle. Verified on hardware.

Full details: red team report.

F-NEW-RAM — PIN transient in RAM (mitigated)

After PIN entry the PIN briefly exists in process memory as a .NET string — TextBox.Text is immutable by construction, so the control keeps its own copy until the garbage collector reclaims it.

Mitigation. The char[] buffer handed to the SDK is zeroed immediately after the HID exchange, and ShortcutsEnabled is disabled on the control so the PIN cannot be copied to the clipboard.

The TextBox control retains its own internal copy briefly until the .NET GC reclaims it — a platform limit, not a code defect. The application cannot zero what it does not own.

This is a reduction, not an elimination: it requires a compromised PC with ReadProcessMemory access, which is outside the declared perimeter.

Full details: red team report.

What lake8.dev receives, and what you choose

The keys never leave the chip. What does travel to lake8.dev, and how much of it, is partly your decision at activation time.

Anonymous activation is not a discount or a lesser tier: it is the same product, activated without telling us who you are. Registered activation exists because invoicing and VAT sometimes require it, not because we need the data.

Protection even against custom firmware

An attacker could flash custom firmware that removes the PIN check entirely. Your data would still be safe.

The keys that decrypt .crin files derive from your 24 words, which the attacker does not have. Without those words a compromised dongle cannot reach your data.

This is the architectural guarantee: authentication (PIN) and cryptography (seed) are separate. The PIN protects ordinary use of the dongle; the seed protects the data even when the dongle is physically compromised. Two independent layers — breaking one does not break the other.

Secure Boot — no exceptions. Every Crypt-in dongle in use — during the beta and after the public launch alike — runs with Secure Boot v2 and Flash Encryption active and the eFuses burned. There is no reduced configuration, no beta exception, and no flag that turns this off. Verified on real hardware, on a virgin chip rather than the development dongle:

• Secure Boot: enabled
• Flash Encryption: enabled
• JTAG: permanently disabled
• read-flash: refused, the chip is in Secure Download Mode
• write-flash with an unsigned binary: refused

There is no “unburned” dongle in anyone’s hands. Burning happens when the firmware is flashed, before the dongle is ever used — on a Kit Standard that leaves lake8.dev, and equally on the ESP32-S3 a beta tester sources and flashes themselves. An unburned chip is internal lake8.dev development hardware and is never handed to anyone.

Every dongle — beta and production alike — is burned when it is provisioned. No exception. The red team sessions ran on such a dongle: when that report says “no eFuses were burned”, it means no additional eFuses were burned during the tests, not that the test chip was unburned.

Only firmware signed with the lake8.dev production key runs. The attack described just above — flashing custom firmware to remove the PIN check — is therefore blocked on every dongle that exists outside our workbench, and the seed remains the second layer regardless.

Anti-rollback is not implemented yet. It needs OTA support, which the current firmware does not have, and will arrive before the public launch together with the update mechanism. Until then, a signed but older firmware image could in principle be installed.

Firmware update channel

Firmware updates are distributed exclusively through the releases page of github.com/lake8dev/cryptin-sdk, signed with the lake8.dev production key. The Windows app verifies the signature before flashing; the dongle verifies again at boot. Two independent checks, and the second does not depend on our software behaving correctly.

Flashing outside the official channel is possible but unsupported — you own the consequences. Unsigned images do not run at all, on any dongle: beta units are burned exactly like launch units.

→ Full firmware update security model

Three common mistakes to avoid

1. Nobody from lake8.dev will ever ask for your PIN or your 24 words. If someone does, they are a scammer. Report it to security@lake8.dev.
2. Do not photograph your 24 words. Photos sync to the cloud automatically. Write them on paper. Only on paper.
3. Watch out for cloud sync on your PC. Encrypt first, then move the .crin file. If Dropbox or OneDrive syncs a file before you encrypt it, the cloud already has the plaintext.

The backup procedure

At first boot the dongle shows, once and once only:

• your 24 words
• your 6-digit PIN

Write them down on paper now. They will never be shown again. Seed and PIN are born together, stored together, recovered together.

The 24 words are a human-readable backup of K_root. They are shown once at first boot over serial (UART0, 115200 baud) and never again — write them down immediately.

Creating a backup dongle

1. Get a second Kit Standard from lake8.dev — recommended, it arrives ready — or a compatible ESP32-S3 if you know what you are doing.
2. Windows app → Create backup dongle.
3. Follow the guided steps and enter your 24 words when prompted.
4. The app shows the backup PIN. It must be identical to your original PIN. If it differs, start again.
5. Backup verified and ready.

Where to keep things

• Main dongle: with you, daily use.
• Backup dongle: a physically separate location — a safety deposit box, or the home of a relative who does not live with you.
• Paper with the 24 words and the PIN: two copies, two separate locations.

Never digital. Never photographed. Never stored with the dongles.

Two copies because paper degrades. A second copy costs nothing; losing the only copy costs everything.

Recovery takes minutes with the backup nearby, or 3–5 working days if you have to order a new Kit Standard.

Licence note. Each recovery uses one of three annual licence transfers. It is an anti-abuse limit, not a cryptographic one. Write to info@lake8.dev for exceptional cases.

Annual maintenance checklist

• The backup dongle decrypts a test file
• The paper is still readable
• Both copies still exist
• The licence has not expired

Your 24 words are like crypto wallet keys

Millions of people manage 24 BIP-39 words to protect cryptocurrency. Same standard, same responsibility.

If you lose the 24 words and the dongle breaks, your files are permanently inaccessible. Nobody can help — not even lake8.dev. That is not a bug: it is the guarantee.

Vault

Vault extends Personal with a self-hosted document server. The same dongle and the same .crin format apply — nothing new is introduced at the cryptographic layer.

What is different: Vault requires network connectivity between the clients and the server holding the dongle. That link is part of your infrastructure, not ours, and it is inside your threat model rather than this page’s.

Full documentation at product launch.

What the lake8.dev server is for

The lake8.dev server handles three things:

1. Initial licence activation — one contact, when the dongle is first set up.
2. Annual licence renewal.
3. Licence transfer to a replacement dongle — at most three times a year.

That is the complete list. It is not contacted during normal use: no periodic check-in, no phone-home, no session validation.

Not needed to decrypt files. An activated dongle decrypts entirely offline, and would keep doing so if lake8.dev ceased to exist. A lapsed licence stops new encryption; it never touches decryption.

Summary — the right enemy

Scenario	Does Crypt-in solve it?
Laptop stolen from a car	✅ Yes
Nosy colleague at your PC	✅ Yes
Decommissioned hard drive still holding data	✅ Yes
Ransomware on already-encrypted files	✅ Yes
Breached cloud backup	✅ Yes
Stolen dongle, no PIN	✅ Yes — a piece of plastic
Custom firmware	✅ Yes — blocked by secure boot, active on every dongle in use, and the seed is still required
Files saved to the cloud before encryption	❌ No — encrypt first
PC with a keylogger or malicious hardware	❌ No — that is a PC problem
Fake tech support	❌ No — but we will never ask
Physical coercion	❌ No — no technology can
Coordinated industrial espionage	❌ No — call an agency
State-level intelligence	❌ No — change country
Your own chronic negligence	❌ No — nobody can
lake8.dev itself compromised	✅ Zero impact — we do not hold the keys

The technical detail behind all of this is in the threat model and in the HID protocol.