Security Assurance

TKeeper security assurance currently comprises 346 automated scenarios, including 81 failure-injection scenarios, executed against multi-node Keeper deployments.

The Testcontainers topology runs a 2-of-3 quorum with peer communication, storage, SoftHSM, restarts, and malicious protocol injection. A three-node production topology exercises TLS, mTLS, JWT/JWKS, peer authentication, and SPKI pinning with per-run PKI.

Every pull request targeting main and every commit pushed to main runs the Release Gate. A passing revision completes all 346 scenarios, artifact isolation, and both container builds.

In short: TKeeper tests cover production identity and transport, authorization and four-eye policy, malicious coordinators and Byzantine peers, FROST/GG20/ML-DSA transcript attacks, ECIES contribution integrity, tamper-evident key state and lifecycle, generative and coverage-guided binary parser and protocol-state testing, concurrent duplicate delivery, crash-safe session cleanup, audit persistence, recovery after rejected contributions, and production artifact isolation.

Every claim below maps to an executable scenario, generated property, fuzz target, or release check.

Security posture

The tests demonstrate these properties:

• Quorum-enforced key use. Threshold signing and decryption operate on shares while key material remains distributed.
• Fail-closed peer validation. Peers validate signer sets, proofs, commitments, contributions, and one-shot protocol state at the consuming trust boundary.
• Intent-bound authorization. Authorities, typed commands, policy, and four-eye approvals are bound to the requested cryptographic operation and cannot be substituted or replayed through the tested paths.
• Authenticated transport identity. Production public access uses TLS and JWT validation; peer access combines mTLS, signed peer authentication, and per-peer certificate pinning.
• Tamper-evident state. Signed metadata, location-bound key records, generation pointers, migrations, and audit records fail closed under the tested storage mutations.
• Production build separation. Development authentication and failure-injection capabilities are verified absent from production artifacts.

Evidence quality

Assurance by domain

Adversarial protocol coverage

Each adversarial vector is reported as a separate JUnit invocation. The FROST, GG20, and ML-DSA suite contains 53 negative cases and three valid controls:

FROST commitments and signature shares are produced by a remote Keeper. GG20 controls generate valid Paillier and zero-knowledge proof material before each mutated input is sent to the production respondent. ML-DSA probes exercise the stored-key commit/reveal state machine. The exact vectors and expected failure contracts are listed in the exact protocol vector catalog.

ECIES adds participant-set validation, DLEQ verification of partial decryptions, and negative ciphertext and tweak coverage outside the 56 signing cases above.

Research lineage and interpretation

Reproducing the assurance

Run the release gate:

./gradlew releaseGate

This builds the integration and production transport images, runs module and functional tests, and verifies artifact isolation. A shorter command for the protocol-input package is documented under Integration Tests.

The property and coverage-guided parser layer can be reproduced separately:

./gradlew :platform-ecc:test \
  --tests 'org.exploit.keeper.platform.ecc.property.SecuritySerializationProperties' \
  --tests 'org.exploit.keeper.platform.ecc.fuzz.SecurityBinaryParserFuzzTest'
./gradlew :platform-ecc:fuzzSecurityParsers

Run the generated and coverage-guided protocol-state layer with:

./gradlew :platform-ecc:test \
  --tests 'org.exploit.keeper.platform.ecc.property.ProtocolStateMachineProperties' \
  --tests 'org.exploit.keeper.platform.ecc.fuzz.SecurityProtocolStateFuzzTest'
./gradlew :platform-pqc:test \
  --tests 'org.exploit.keeper.platform.pqc.property.MLDSAStateMachineProperties' \
  --tests 'org.exploit.keeper.platform.pqc.fuzz.MLDSAStateMachineFuzzTest'
./gradlew :test \
  --tests 'org.exploit.keeper.tests.temporary.InMemoryTemporaryMapConcurrencyTest'
./gradlew securityFuzz

Deployment and operational boundaries

The following conditions require deployment or operational controls outside the Keeper process:

• compromise of at least the configured threshold, or compromise of the host, HSM, cloud unseal authority, build pipeline, or deployment control plane;
• broad denial of service, physical side channels, fault injection, entropy failure, and platform-specific constant-time behavior;
• coherent full-database rollback without an external monotonic control;
• unsafe authority policy, use of raw arbitrary signing where semantic governance is required, or a downstream verifier that ignores identity, intent, expiry, or replay requirements.

The Threat Model specifies the corresponding trust assumptions and mitigations. Exact test traceability continues below in Executable evidence.

Executable evidence

This catalog maps each demonstrated security property to executable evidence and records the exact adversarial protocol vectors. Threat identifiers refer to the Threat Model. Evidence is revision-specific: the test names identify the executable contract, while the release gate determines whether that contract passes for a given artifact.

Threshold protocols

The FROST participant, proof, commitment-set, signature-share, duplicate, and nonce-consumption invariants execute in the ciphersuite-independent shared signing state machine. Ciphersuite-specific valid signing and verification paths are covered in SignatureTests.

Byzantine peers and recovery

Identity and transport

Authorization and policy

State, lifecycle, and audit

Output integrity

Operational controls

Exact protocol vector catalog

Shared signing-package boundary

Each vector runs independently against FROST, GG20, and threshold ML-DSA.

FROST transcript

GG20 MtA and proofs

Every negative below produces IdentifiableAbortException attributed to the initiating peer.

Threshold ML-DSA transcript

After every negative FROST and ML-DSA transcript probe, the functional suite produces and verifies a normal distributed signature with the same stored key.