DCENT_OS Firmware Security

Firmware security is a chain: source review, trusted build inputs, signed artifacts, a verified update path, safe defaults and a recovery route. DCENT_OS documents each boundary instead of treating “open source” as the whole answer.

Threats in scope

• Compromised or downgraded update packages.
• Unauthorized dashboard, API, WebSocket or MCP control actions.
• Credential or release-key leakage.
• Unsafe voltage, thermal, fan or PSU changes.
• Pool redirection and configuration tampering.
• Persistent-install failures that damage boot or recovery state.

Release and update controls

Verify a package

1. Download only the artifact for the exact model and control-board lane.
2. Compare its SHA-256 digest with the published checksum list.
3. Check the signed manifest yourself. Unpack the package and run both checks from inside the extracted directory:

   tar -xf DCENTOS_XIL1_S9_beta20260709.tar
   cd sysupgrade-am1-s9
   sha256sum -c SHA256SUMS
   openssl pkeyutl -verify -pubin -inkey release_ed25519.pub \
     -rawin -in MANIFEST.json -sigfile MANIFEST.sig

   You should see kernel: OK, root: OK, METADATA: OK and release_ed25519.pub: OK from the first command, then Signature Verified Successfully from the second. Proves every payload matches the digest the manifest declares, and that the manifest itself was signed by the release key. Undo nothing is written to a miner by these commands — delete the extracted directory. Ed25519 verification needs -rawin, which requires OpenSSL 3.x. DCENT_Toolbox performs the same two checks and is designed to fail closed on a mismatch.
4. Anchor the key out of band. release_ed25519.pub ships inside the package it authenticates, so on its own it is trust-on-first-use. Print its raw 32-byte value and compare it against the fingerprint we publish on the release page:

   openssl pkey -pubin -in release_ed25519.pub -outform DER | tail -c 32 | xxd -p -c 32

   You should see the single 64-character line 26985575eae77d56c490ceeb9054af012eab5ae59119cd20eaa70dd7e722df83, matching the release-key fingerprint printed on the beta20260709 release page. The -c 32 matters: without it xxd -p wraps at 30 bytes and prints the fingerprint across two lines, which looks like a mismatch when it is not. (No xxd? | od -An -tx1 | tr -d ' \n' prints the same 64 characters on one line.) Proves the key inside the package is the key we published.
5. Run a dry-run preflight and keep a known-good recovery image plus UART access.

Independent network-verification recipe

1. Record the artifact filename, SHA-256 digest, build/commit and exact miner/control-board lane.
2. Place the miner on an isolated test VLAN with packet capture at the gateway.
3. Exercise first boot, pool configuration, mining, dashboard/API reads, authenticated writes, update checks and a reboot.
4. Publish DNS lookups, destination IPs, ports, byte counts and the redacted capture; distinguish configured pool traffic from unsolicited traffic.
5. Repeat after a factory reset and disclose every test limitation. Do not turn a single quiet capture into a universal claim for other builds.

Disclosure and audit status

Report vulnerabilities through the repository's coordinated disclosure policy, not a public issue. The policy covers the firmware, dashboard, build/flash tooling and update path and includes safe-harbor language.

This page does not claim an independent security audit, a reproducible-build certification or a published SBOM unless those artifacts are linked from the repository for the named build. Independent researchers can use the reviewer and researcher kit; negative findings and failed reproductions are explicitly welcome.

Assurance ledger

Security surface reviewed 2026-08-29. See also D-Central's firmware verification guide.