Beta Red Team — Rules of Engagement

Session 4: Open Red Team

Effective	29 September 2026
Expires	31 March 2027
Applies to	all Crypt-in developer beta participants
Server-side red team	target 30 October 2026, clone redteam-license.lake8.dev only
Never in scope	license.lake8.dev — the production licence server
Contact	security@lake8.dev
PGP	cryptin.lake8.dev/security/pgp/
PGP fingerprint	published at cryptin.lake8.dev/security/pgp/

---

Status — target date 30 October 2026

Target date: 30 October 2026. Server-side red-teaming was to open on 15 October 2026 and did not. Since then two things changed, and the pending items are now ours:

• The provider has agreed, in writing. Before buying the server we asked Hetzner for permission to run a public test carried out by third parties on our own server. On 14 October 2026 the answer was yes, in these terms: «as long as you do not harm any customers and only attack your server», no advance notice required, no additional rules.
• The clone sits on its own box, outside our network. On 18 October 2026 redteam-license.lake8.dev was moved onto a Hetzner CX23 in Falkenstein, with its own name and TLS, and the DNS was detached from the production machine. Attacking the clone no longer touches license.lake8.dev by proximity.

At this point the opening depends on our acceptance tests of the clone. If any of them is not done by 30 October 2026, this page will say so, before that date.

One thing the provider will not switch off: automatic blocks. Hetzner confirmed in the same message that «that could be possible, it is not possible to avoid that» — their protection may kick in and the clone may become unreachable. A clone that stops answering is not a crash on our side, not a withdrawal, and not a denial of service that can be claimed as a result. See §2 and §3, and the stop-and-report rule attached to GET /health in §1.

Until it opens, the in-scope surface is your own hardware, your firmware binary, your client and the .crin format on your own machine — never the licence server.

What the opening does not change

The date moved. Everything else in this document stands as written.

• Production stays off the table, always. license.lake8.dev is not a target before the clone opens, not while it is open, and not after.
• Research on hardware, firmware and the .crin format is open now and covered by the safe harbour in §3, exactly as it is today.
• The extraction challenge is open and does not depend on the clone: it is a separate exercise, on a chip you own.
• The rules themselves are unchanged — the perimeter in §1, the exclusions in §2 (denial of service included) and the safe harbour in §3 all still apply word for word.

Two roles, one perimeter. By downloading and taking part, you accept both.

• You, the beta tester and builder. You flash your own ESP32-S3, set it up, encrypt files, take backups, move a licence. You connect to the production licence server,license.lake8.dev, only to use the product normally — activate, renew, transfer, recover. You are welcome to attack everything that is yours: your dongle, your flash (SPI dumps, NVS), the firmware binary (reverse engineering), your USB HID traffic, the Windows client on your machine, the .crin format on your machine. That is real security research and it is covered by the safe harbour below.
• The red team, against the server. It isnot open yet: target date 30 October 2026, dependent now on our acceptance tests of the clone. The clone sits on its own Hetzner server (CX23, Falkenstein) since 18 October 2026, outside our network, with its own name and TLS; the public test was permitted in writing by the provider on 14 October 2026, on condition that only our server be attacked and no other customer be harmed. Its target, when it opens, is the clone,redteam-license.lake8.dev, reached only by aseparate red-team build of the client — theRedTeam configuration ofgithub.com/jaffa2970/cryptin-sdk-beta. Until it opens there is no authorised server-side target. When it opens, only the clone is in scope, with the load-testing threshold in the rules and the cloud provider's host, hypervisor and other tenants off perimeter.

We set the rules, and we keep them. Stay on the table we provide — the clone, and only the clone, and only what is yours — and the safe harbour, the SLAs and the credit below are our word.

The production licence server (license.lake8.dev) and every lake8 production service are out of scope for everyone, always. Do not attack, load-test, fuzz, flood or probe them. Production shares infrastructure with unrelated services and real customers. Attacking production is not authorised, isnot covered by safe harbour, and carries real legal risk under Italian law and the EU frameworks cited in these rules — whether you call yourself a beta tester or a red teamer. If you find something that only reproduces against the server, report it and stop pulling on it; the VDP and its safe harbour cover that report exactly the same. The only server you may ever attack is the clone, once it opens, and nothing else.

---

What this is

The Crypt-in developer beta is Session 4 of our public red team program. Sessions 1–3 were conducted internally with Claude Opus 5, full source access, and a live dongle. The full report is public at cryptin.lake8.dev/security/red-team-2026-08/

Session 4 is you.

Every beta participant is officially part of our security program. These rules define what you can do, what you cannot do, and what protects you legally when you find something.

---

1. Scope — what you can attack

Everything in scope is yours: your hardware, your client, your files. You have permission to test it aggressively. The licence server is the one entry below that says what you may not do — read it.

Your hardware

• Your ESP32-S3 beta dongle (firmware -dev)
• Your flash memory — including SPI dumps, serial console access, NVS extraction
• Your firmware binary — reverse engineering, disassembly, Ghidra, IDA, Binary Ninja, anything you want
• Your USB HID traffic — capture, replay, manipulation, injection
• Any combination of your own dongles

Your client installation

• The Windows client (Personal v1) on your own machine
• The SDK on your own machine
• Memory inspection, debugging, patching, replacing DLLs, writing your own HID client — all permitted
• File system inspection, process instrumentation, API hooking

The licence server — the clone only, and not open yet

During the beta the licence server is not a target. Your beta client connects to the production server, license.lake8.dev, and you use it only to activate, renew, transfer and recover your own licence — as a user, not as an attacker. Do not attack it, and do not load-test it. Server-side red-teaming has not opened: target date 30 October 2026 — see the status note at the top of this page. When it opens, it opens against a clone, redteam-license.lake8.dev, reached by a separate red-team build of the client: the RedTeam configuration of the public SDK repository (github.com/jaffa2970/cryptin-sdk-beta, dotnet build -c RedTeam), which points at the clone and writes «⚠ RED TEAM — redteam-license.lake8.dev» in every window title.

From that date the clone — and only the clone — is in scope: activation, renewal, transfer, recovery, expiry, race conditions, replay, concurrency, timing, and load testing are all fair game on the clone. license.lake8.dev never is.

A beta dongle will accept the clone’s tokens. The clone signs licences with the beta key, the same one compiled into beta firmware — bench-tested on 20 October 2026 with a beta dongle, which accepted a personal-beta-v1 licence issued by the clone and rejected the same licence with the signature altered. The key is of the beta only and expires with it on 31 March 2027; the paid product will use a different key. Minting a licence that a real beta chip accepts, without our key, is a real target.

Load testing — where it ends and where flood begins. Load testing is authorised on the clone from a single host and a single source IP, up to the rate limit the server already applies: 120 requests per minute per IP globally, 20 per minute per IP on unauthenticated write endpoints. Receiving 429 RATE_LIMITED is a valid outcome — hitting it, seeing how it reports, and timing its recovery are all in scope. Forcing 429 on purpose, or working around it by rotating source IPs or distributing the same load across more than one source, is flood and falls under §2. At most 50 concurrent connections. Bursts of at most 5 minutes, with a pause between one and the next. No amplification, no reflection, no botnet, no stress-as-a-service.

If the clone stops answering GET /health, stop and tell us. That is a take-down (§2) — and it may also be the provider’s automatic protection kicking in on their side (see the status note). It is not a result to claim; the input that got there, instead, is a finding we want to see.

Accidental collateral effects during authorized testing on the clone are covered under safe harbour if reported immediately to security@lake8.dev.

The .crin format

• Malformed containers, fuzzing, parser attacks — in scope
• ZIP payload attacks (path traversal, ZIP bomb) — in scope, on your own machine only
• Do not send malicious .crin files to shared services or other beta participants — test only against your own installation

---

2. Out of scope — what you must not do

These are hard limits. Violating them removes your safe harbour.

• license.lake8.dev — the production licence server. The beta client talks to it for normal use; it is never a target. The only licence server you may attack is the clone, and only once it opens.
• Other users’ data or accounts — do not access, modify, or read any data belonging to another beta participant
• The lake8.dev production infrastructure — do not attack lake8.dev (the blog/product site), stats.lake8.dev, or any service not listed in scope
• Denial of service against shared infrastructure — do not attempt to take down any licence server, production or clone, and do not flood it. See the load-testing threshold in §1.
• Crashing the clone process on purpose — taking the clone down is not an objective of this programme. The input that happens to crash the server is a finding we want: stop, keep it reproducible, and report it. The outage itself is not a result to claim. See the safe-harbour clause for accidental collateral effects in §3.
• The cloud provider’s infrastructure — the host, the hypervisor, their internal network, their other tenants, and any service of theirs. The perimeter is the clone’s own service, reached by its name redteam-license.lake8.dev on ports 80 and 443; everything else at the provider is off-table, even when the clone sits on it. This matches the condition under which the public test was permitted at all.
• Physical attacks on third-party hardware — test only on hardware you own
• Social engineering — do not attempt to deceive lake8.dev staff or other participants
• Vulnerability disclosure before coordination — do not publish findings before the coordinated disclosure date; see §4

---

3. Safe harbour

lake8.dev grants the following protections to all beta participants who act within these rules, to the maximum extent permitted by applicable law.

We will not pursue legal action against you — civil, criminal, or contractual, including any claim under the EULA of the Windows client or the SDK licence — for:

• Any security testing conducted within the scope defined in §1
• Accessing, reading, or extracting data from your own dongle, your own client installation, or your own licence account
• Attempting to bypass, circumvent, or break any security control on your own hardware and in your own client installation — and, from the day the clone opens, on the clone with your own account
• Discovering and reporting vulnerabilities through these channels
• Accidental collateral effects during authorized testing, if reported immediately — including a process crash on the clone that a specific input happened to cause. The input and its circumstances are what we want to see; the outage itself is not an objective and not a result to claim.

This safe harbour covers testing conducted in good faith under these rules, regardless of whether you find a vulnerability.

This protection applies under:

• Italian law (lake8.dev is an Italian entity)
• EU NIS2 Directive provisions on security research
• Equivalent national cybersecurity research provisions

If you are unsure whether a specific test is in scope, ask first: security@lake8.dev

If you do not ask and the test turns out to be borderline, we will evaluate in good faith whether you acted within the spirit of these rules before making any determination.

This safe harbour does not extend to any test against the production licence server (license.lake8.dev) or any other lake8 production service. Those are out of scope (§2); attacking them is neither authorised nor protected, and may expose you to civil and criminal liability.

---

4. Reporting

Send findings to security@lake8.dev. Encrypt sensitive findings with our PGP key. Verify the key fingerprint out-of-band before sending sensitive material: the fingerprint is published at cryptin.lake8.dev/security/pgp/.

If email bounces or you receive no acknowledgment, use the contact details at cryptin.lake8.dev/security/pgp/ as a fallback channel.

Include:

• Steps to reproduce
• What you expected to happen
• What actually happened
• Impact assessment
• Your hardware revision and firmware SHA256

Response times:

• Every report: acknowledgment within 7 days, assessment within 21 days. The assessment is what assigns the severity.
• High and Critical: fix within 90 days of the assessment.
• Medium and Low: best-effort, with status updates, until the public launch (April 2027). We will revisit this as we go.
• Scale: Critical / High / Medium / Low — the same scale as the August red team report. We do the classification, and you are free to contest it.
• Applies to reports received from 29 September 2026. Findings already published in the August report (F-001-REV, F-ISO, F-003) keep the fix timeline declared there.

We will coordinate disclosure with you before publishing anything. Default embargo: 90 days from acknowledgment, or sooner if a fix ships.

If we miss the 7-day acknowledgment, send a follow-up. If we still do not respond within 7 additional days, you are free to disclose with 7 days advance notice to security@lake8.dev.

If no acknowledgment arrives and email appears to be failing, the embargo clock starts from the date of your first documented send attempt.

---

5. Known open findings

Before you start, read the current open findings:

ID	Severity	Description	Fix
F-001-REV	High	Session binding not implemented — unlocked state accessible to second HID handle	Q2 2027
F-ISO	Medium	Block-cipher accumulator not bound to a handle — a second handle can interleave chunks or abort a transfer. Fail-closed	Q2 2027
F-003/B1	Low	PIN transmitted in cleartext over USB HID	Q2 2027

These are known and accepted. Reporting them again is welcome if you have a new attack path or a bypass of the documented mitigation. Reproducing a known finding with a new method is a valid contribution.

---

6. Attribution

We will credit every researcher whose finding leads to a fix or a documented accepted risk — by name, handle, or anonymously, your choice.

The most significant finding from Session 4 will be acknowledged by name in the April 2027 public launch security report.

All findings will be published in our public register at cryptin.lake8.dev/security/red-team-2026-08/ with researcher credit.

We do not offer monetary bounties at this stage.

---

7. Beta hardware — security implications

Beta dongles run the -dev firmware track. eFuses are not burned.

This means:

• CMD_GET_SECRET (0x04) responds — file_secret can be extracted
• Flash is readable via SPI dump — K_root is extractable
• With K_root you can derive K_identity and decrypt .crin files offline without the dongle

A beta dongle protects against laptop theft. It does not protect against an attacker with physical access and an SPI flash reader.

Do not store data on a beta dongle that you cannot accept being readable by someone with physical access to the hardware.

Production dongles (April 2027) have eFuses burned at first boot, Secure Boot v2 and Flash Encryption active. The beta is intentionally open to enable deeper security research.

---

8. Scope validity

These rules are valid from 29 September 2026 to 31 March 2027, the end of the developer beta period.

After 31 March 2027 this document expires. Testing conducted after that date is no longer covered by this safe harbour unless a new programme is announced.

---

9. The mission

Read the red team report before you start. Try every attack described. Try attacks we have not described — on your own hardware, your own client and your own files. Not on the licence server.

“I broke it” — tell us how. “I couldn’t break it” — tell us that too.

Both answers are valuable. Session 4 feeds directly into the April 2027 public launch security report.

---

lake8.dev — Giantommaso Fogli, San Pietro in Casale, Italy security@lake8.dev · cryptin.lake8.dev/security/pgp/