Software Bill of Materials (SBOM)

Note

Three SBOMs are published here: one for the firmware, one for the Linux x64 CLI and one for the Windows x64 CLI. They are separate documents because they describe separate artefacts with separate dependency trees — not because one supersedes another.

The firmware SBOM lists the open-source components used to BUILD the firmware. The compiled firmware is distributed as a binary — signed on production dongles, unsigned in the -dev build that ships with the developer beta — and its source code is not published. The component list is here for transparency and CRA compliance, and because anyone tracking an upstream vulnerability needs to know whether it affects this device.

Artefact	Components	Document
Firmware, ESP32-S3	10	cryptin-firmware-sbom.json
CLI, Linux x64	8	cryptin-cli-linux-x64-sbom.json
CLI, Windows x64	5	cryptin-cli-win-x64-sbom.json

All three are SPDX 2.3 JSON. The two CLI documents are regenerable with an internal script, which is not part of the published repository.

Firmware

lake8.dev publishes the Software Bill of Materials for the Crypt-in firmware to meet the SBOM requirement of the EU Cyber Resilience Act. That is one obligation met, not the whole Regulation: Crypt-in is not CRA compliant today, and two obligations are still open — see CRA status.

Format: SPDX 2.3 JSON  |  Scope: Crypt-in firmware for ESP32-S3  |  Firmware version: beta-2026-10-13  |  Platforms: Windows and Linux — one SBOM, valid for both  |  Last updated: October 2026

This document is not platform-specific. Every version listed below is pinned exactly, so a Windows host and a Linux host resolve to the same components: one SBOM describes both, and there is no second document to look for.

⬇ Download SBOM (SPDX 2.3 JSON)

Firmware components

Component	Version	License
Monocypher	4.0.3	BSD-2-Clause OR CC0-1.0
arduino-esp32	3.3.9	LGPL-2.1-only
TinyUSB	dd31ba45… (v0.20.1 snapshot)	MIT	modified
arduino_tinyusb (ESP-IDF component wrapper)	ee57070c…	Apache-2.0	modified
ESP-IDF	5.5.4+sha.735507283d	Apache-2.0
platform-espressif32 (pioarduino mirror)	55.03.39	Apache-2.0

Two components carry local modifications, and the SPDX document says so in their sourceInfo field — the CRA asks for an inventory you can act on, and a patched dependency that reads as pristine is worse than no entry at all.

• TinyUSB is vendored as source and compiled into the firmware since beta-2026-10-13; before that the build used the precompiled, unmodified library shipped with arduino-esp32. The changes are security fixes for red team findings H1/B1, J1 and K0: HID and standard control requests whose direction does not match the specification are now STALLed, the control buffer is zeroed after the SET_REPORT callback, an OUT data stage longer than the handler’s buffer is STALLed instead of copied past its end, and EP0 OUT is never armed with a NULL buffer. Each one is marked CRYPT-IN LOCAL MODIFICATION in the source. The pinned commit is the exact snapshot arduino-esp32 3.3.9 was built against.
• arduino_tinyusb is Espressif’s build wrapper, and the change is build-only: priv_requires arduino main reduced to priv_requires arduino, because this project’s app component is not named main. No functional change to the USB stack.

Host tools (Python — not in the firmware image)

Component	Version	License
hidapi (Python)	0.15.0	BSD-3-Clause OR GPL-3.0-only
PyNaCl	1.6.2	Apache-2.0
cryptography (Python)	49.0.0	Apache-2.0 OR BSD-3-Clause

All Python tool versions are pinned exactly in tools/requirements.txt — no >= ranges — so this table is reproducible rather than indicative: a fresh install on Windows and one on Linux both resolve to these versions and no others. That is what makes a single SBOM valid for both platforms.

Monocypher ships vendored under firmware/src/crypto/, and its header carries an unsubstituted __git__ placeholder instead of a version string. The 4.0.3 version above was established by SHA-256 comparison of monocypher.c, monocypher.h, monocypher-ed25519.c and monocypher-ed25519.h against the official 4.0.3 release tag: all four files are byte-for-byte identical to that release.

CLI — Linux x64

Format: SPDX 2.3 JSON  |  Scope: cryptin CLI 1.0.0, self-contained .NET 9 build for linux-x64  |  Last updated: August 2026

⬇ Download SBOM (SPDX 2.3 JSON)

Bundled in the binary (CONTAINS)

Component	Version	License
CryptinSDK	1.0.0	Apache-2.0
HidSharp	2.6.4	Apache-2.0
System.IO.Ports	9.0.0	MIT
runtime.linux-x64.runtime.native.System.IO.Ports	9.0.0	MIT
runtimepack.Microsoft.NETCore.App.Runtime.linux-x64	9.0.10	MIT

System libraries, not bundled (DEPENDS_ON)

Component	Version	License
libudev	provided by the host	LGPL-2.1-or-later
OpenSSL	provided by the host	Apache-2.0

Caution

libudev and OpenSSL are declared DEPENDS_ON, not CONTAINS. The binary is self-contained for .NET, not for the operating system: these two remain system libraries supplied by the host distribution and are not shipped inside the executable.

Do not read “self-contained” as “no external dependencies” — on Linux it is not true, and a packaging process that assumes it will produce a binary that fails on a minimal image.

Caution

Track CVEs against the .NET runtime 9.0.10, not against the target framework net9.0. The target framework is a compilation contract and carries no vulnerabilities of its own; the runtime pack is the code that actually ships inside the binary. An advisory feed keyed on net9.0 will stay silent while the bundled runtime is affected.

Packaging note

The CLI binary is self-contained for .NET but requires two system libraries:

• libudev — USB HID access
• OpenSSL — TLS

They are declared DEPENDS_ON in the SBOM, not CONTAINS: they are not bundled in the binary and must be present on the target system.

After copying the binary to a target machine, test the commands that touch the device, not only the ones that touch files:

# Following packaging/LINUX.md
cryptin status     # talks to the dongle over HID  -> needs libudev
cryptin reset      # device operation
cryptin recover    # device operation

encrypt and decrypt can succeed on a system where HID access is broken, because they do their work on files. A packaging error in the libudev dependency therefore shows up only on status, reset and recover — which is exactly why those three are the ones to run.

CLI — Windows x64

Format: SPDX 2.3 JSON  |  Scope: cryptin CLI 1.0.0, self-contained .NET 9 build for win-x64  |  Last updated: August 2026

⬇ Download SBOM (SPDX 2.3 JSON)

Bundled in the binary (CONTAINS)

Component	Version	License
CryptinSDK	1.0.0	Apache-2.0
HidSharp	2.6.4	Apache-2.0
System.IO.Ports	9.0.0	MIT
runtimepack.Microsoft.NETCore.App.Runtime.win-x64	9.0.10	MIT

There is no DEPENDS_ON section here: on Windows the equivalents of libudev and OpenSSL are part of the operating system itself, so the Windows document has five SPDX packages where the Linux one has eight. Those totals include the described artefact itself, as SPDX requires — the cryptin binary is package one, and the tables on this page list only what comes after it. Count a table and you get one less; count the packages array in the JSON and you get the number quoted here. The difference between the two SBOMs is that, not a difference in what the CLI does.

The same CVE note applies: track the runtime 9.0.10, not net9.0.

Scope

This SBOM covers the firmware running on the ESP32-S3 dongle and the internal Python host tools used to test it. Those tools are cross-platform — the same code runs on Windows, Linux and macOS wherever Python and hidapi are available — but they are a test harness, not a distributable SDK. See Python tools.

The Windows client (Personal v1) is a different program entirely — not the Python tools on Windows — with its own language and its own dependency tree. It is open source under GPL-3.0 — the SDKs are Apache-2.0, see Licence — but it is not covered by this SBOM.

The CLI is covered by its own two documents above — one per platform — since August 2026. Until then this page stated that the CLI had no SBOM: that is no longer true, and the sentence has been corrected rather than left standing.

Still not covered:

• The Windows client, Personal v1 — a separate program with its own dependency tree. It is GPL-3.0, but it has no SBOM of its own yet
• The licence server (proprietary, closed source)

Build environment

The firmware is built with the PlatformIO / pioarduino toolchain listed under Firmware components. The reference build for beta-2026-10-13 was produced on Windows; the toolchain itself is cross-platform, and the component versions above are what determine the resulting image, not the operating system that ran the compiler.

Vulnerability reporting

If you discover a vulnerability in any listed component, report it to security@lake8.dev under the Vulnerability Disclosure Policy.

We will coordinate disclosure with the upstream maintainer and issue a firmware update within 90 days of confirmation.