HSM Cryptographic Key Sharding Enclave

Overview

The problem

A signing key held whole in one place, even briefly and even inside a hardware security module, can be taken by whoever compromises that place: an insider, a compromised host or a side channel. Conventional multi-signature setups split authorisation across several complete keys rather than splitting one key. Threshold signing splits a single key into shares so that an attacker has to compromise a quorum of separate machines.

What it does

• FROST(Ed25519) threshold signing per RFC 9591, with all curve and scalar arithmetic delegated to libsodium's constant-time Ed25519 functions; the signer checks the coordinator's commitment list as RFC 9591 requires.
• Identifiable abort for FROST: an invalid signature share is detected and the participant who sent it is named.
• Distributed key generation in which the full key is never formed (a trusted-dealer path also ships, for testing).
• Proactive share refresh: shares are re-randomised without changing the group public key, and a quorum mixing old and new shares does not verify. It is a library call; scheduling it is the operator's job.
• Single-use nonce vault backed by a crash-safe, sealed, append-only log, with rollback detection anchored to a pluggable monotonic counter.
• Attested peer sessions: messages are signed by a key bound into the sender's attestation quote, a confidential mode encrypts secret payloads such as DKG round-two shares to the recipient, and peers with an untrusted root, a disallowed measurement or an out-of-date TCB are refused (tested with a software root of trust).
• AMD SEV-SNP report parsing and ECDSA P-384 signature verification, with per-component TCB checks and rejection of debug-enabled guests and VMPL other than 0.
• Threshold ECDSA on secp256k1: semi-honest GG18 with Paillier, not constant-time, n-of-n key generation without a dealer and t-of-n key generation with a trusted dealer only.
• Assurance tooling in the repository: known-answer tests, adversarial tests, five libFuzzer targets, ASan, UBSan and TSan builds, ctgrind and dudect constant-time gates on the project's own comparison and select helpers, cppcheck, and a GitHub Actions workflow configured to run them (Vlaander has not run it on GitHub).

Value in your own metrics

Key exposure

On the distributed-key-generation path no participant ever holds the whole key, and an attacker needs a quorum of shares to sign.

Signature format

FROST output is a standard Ed25519 signature, so existing Ed25519 verifiers accept it without changes.

Audit material

Known-answer, adversarial, fuzz, sanitizer and constant-time gates ship with the source, so your auditors can rerun them.

Assurance and build

Language

C++20, built with CMake; depends on system libsodium and OpenSSL libcrypto, with no vendored third-party code

Cryptographic posture

FROST(Ed25519) per RFC 9591 on libsodium's constant-time primitives; threshold ECDSA is semi-honest and not constant-time

Attestation

Verification engine implemented and tested with a software root of trust; SEV-SNP report retrieval and AMD certificate-chain fetching are stubbed

Backends

One software backend; SGX and confidential VMs could be added through the interface but are not implemented

Tests

107 test cases in five suites; on 7 October 2026 Vlaander ran them on the delivered code with g++ 14 and with clang 16 under ASan, UBSan and TSan, all passing (shared 4-vCPU AMD EPYC 7763 Codespace); on 8 October 2026 the delivered archive built and passed all 7 CTest entries

Fuzzing

Five libFuzzer targets, 8 minutes each with ASan on 7 October 2026: 47.5 million executions with no crashes, leaks or timeouts. Coverage is shallow, and the DKG and nonce-log code are not fuzzed

Internal review

Vlaander quality gate, 7 October 2026: 0 critical findings, 4 high (all fixed in the delivered source), 4 medium (2 fixed; open are unbound envelope sender and session identifiers, and signing speed), 8 low (open). In a head-to-head on the same shared Codespace, a full 2-of-3 FROST session took about 3 times as long as the Zcash Foundation's frost-ed25519 2.1.0

Supply chain

A script that generates a CycloneDX software bill of materials is included; no bill of materials file ships with the source

Licence

Proprietary. The LICENSE file and the SPDX header in every source file (LicenseRef-Vlaander-Proprietary) state that ownership passes to the single buyer under Vlaander's terms of sale; no open-source licence applies

Certification status

None. FIPS 140-3 and Common Criteria appear only as roadmap items

Releases are not yet cryptographically signed, and no release manifests or external audit summaries are published. Check the source tarball you receive against its SHA-256 in Schedule 1 of your Sale and Assignment Agreement, which you see before you sign.

Scope and maturity

What is real today, what is deliberately excluded, and what is pending — published unprompted.

Who it's for

• Digital-asset exchanges and custodians building their own threshold-signing stack.
• Banks and payment institutions that want signing keys split across machines.
• Stablecoin issuers that want threshold control of mint and redemption keys.
• Defence and government integrators building attested, quorum-gated signing.

Before you buy

1. Treat this as an early-stage library to build on, not a product to deploy. If your control environment requires FIPS 140-3 or Common Criteria at go-live, it is not at that gate.
2. Commission your own cryptographic audit and price it into the acquisition.
3. Plan to supply a hardware-backed or quorum-replicated monotonic counter, and to exclude the trusted-dealer key generation from production builds.
4. Budget for the networking and node runtime you will need, and for the open envelope-binding finding, before any multi-host deployment.
5. Validate attestation on the exact production silicon you intend to deploy once the SEV-SNP hardware path is implemented.
6. When you rerun the gates, install libsodium-dev (the README does not list it), libc6-dbg for the ctgrind gate, and run TSan builds under setarch -R on recent kernels with clang 16.
7. Confirm the share-refresh protocol against your compromise-recovery playbook, including when a share holder is permanently lost.

What transfers

• The asset's sourceSubject to the Sale and Assignment Agreement, Vlaander assigns to the verified Buyer the transferable right, title and interest that Vlaander owns in the specified Asset. The assignment excludes Third Party Materials, open-source components, Vlaander’s pre-existing tools, generic know-how, development methods, trademarks, confidential information and any rights that cannot lawfully be assigned.
• Its testsThe test suite the published assurance claims rest on, as delivered in the source archive.
• Its audit artefactsSpecifications, model-checking output, reviews and the software bill of materials, where the asset has them.
• Not includedThird-party and open-source materials are not sold or assigned by Vlaander. They remain under their own licences, listed in each asset’s software bill of materials (SBOM.md in the archive), and the Buyer is responsible for complying with those licences.

Sale and ownership terms → Sale and Assignment Agreement →