Security measures

Summary. This page lists the technical and organizational measures of WKL TrustBridge as a catalog. Each measure states which requirement it satisfies, what it consists of, and how it is evidenced. The catalog bridges the security goals in Architecture derivation and the evidence in Audit and evidence. Technical security boundaries are safeguarded by automated checks in the build; organizational measures by roles, procedures, and exercises.

Terms

Technical measure – enforced by software or hardware.
Organizational measure – enforced by roles, procedures, and oversight.
Gate – an automated check in the build or test run that breaks the build when violated.

Catalog

Cryptography and keys

ID	Measure	Requirement	Evidence
M-01	CA keys only in the HSM, non-exportable, ML-DSA included	A-03	The worker's startup check (fingerprint, non-exportability); ceremony record
M-02	One key belongs to exactly one CA; new key = new CA generation	A-03, A-08	Rule set, ledger
M-03	Hybrid certificates with an ML-DSA alternative signature	A-07	Checking generated certificates with classical and PQ-capable verifiers
M-04	ML-DSA and ML-KEM tested against published NIST test vectors	A-06	204 test cases; test harness cross-checked with tampered inputs
M-05	Test vectors kept outside the repository, every file's checksum recomputed before use; a deviating file is a failure	A-17	Test run
M-06	No silent fallback to a weaker mechanism; every fallback requires a policy, an audit entry, a reason code, and telemetry	A-07	Architecture test
M-07	No key generation for requesters; only CSRs with proof of possession (for both keys if hybrid)	A-15	Check in the worker
M-08	No private keys in the database, transfer objects, logs, or error messages	A-03, A-16	Architecture test; review of logs

Separation and rights

ID	Measure	Requirement	Evidence
M-10	CA worker without inbound connections, never in the process or account of an HTTP service	A-02, A-03	Architecture test; network configuration
M-11	A separate database login per service with exactly the rights it needs	A-09	Permission review
M-12	Management without access to the HSM and without configuration for CA keys	A-03	Architecture test
M-13	Distribution without a private key and without write access; verifies signatures before serving	A-04	Architecture test
M-14	Tenant foreign keys `(mandant_id, id)` and row-level security on read	A-09	Tests with several tenants
M-15	Management client without a database connection	A-09, A-20	Gate on the Access application's sources

Authorization and integrity

ID	Measure	Requirement	Evidence
M-20	Approval as a signature over the order hash; approvers only in the local rule set	A-02	Ledger with approvals
M-21	Two approvers for security-relevant profile classes (CA certificates, approver and agent certificates, relationships)	A-02	Rule set
M-22	Orders byte-exact, identified by SHA-256; displayed from exactly those bytes	A-02	Tests of the management application
M-23	Every order checked against the rule set: profile class, CA, tenant, name, extensions, lifetime, expiry, single execution	A-01, A-02	Worker tests with invalid orders
M-24	Critical name constraint in every CA certificate, fixed in the root tool	A-01	Checking generated CA certificates
M-25	Relying-party contract for counterparts; test certificates to verify compliance	A-01	Test certificates, partner contracts

Availability and recovery

ID	Measure	Requirement	Evidence
M-30	CRLs valid for 72 h, issued every 6 h and immediately after a revocation	A-04	Measurement in operation
M-31	Second publication path bypassing the database	A-04, A-05	Failure drill
M-32	Emergency revocation at the console of the worker host	A-05	Exercise
M-33	Intent recorded in the ledger before signing; restart with the same serial number	A-18	Tests with forced aborts
M-34	Standby for worker and HSM; distribution highly available	A-04	Failure drill

Sign-in and access

ID	Measure	Requirement	Evidence
M-40	Personal key plus a second factor for every person at the management interface	A-10	Sign-in tests
M-41	Every permission change in one transaction together with its audit entry	A-11	Tests
M-42	Answer requests for other tenants' objects with `404`	A-09	Tests
M-43	Check permissions on every request, never cache them in the session	A-10	Revocation-of-rights tests
M-44	Sessions limited (default 8 hours); revoking a key ends every session bound to it immediately	A-10	Revocation-of-rights tests
M-45	Approval key separate from the sign-in secret, on a smart card or security key with PIV support, PIN per signature	A-02	Acceptance of the tokens
M-46	Check new namespaces for overlap with existing ones before every ceremony	A-01	Root tool

Logging and evidence

ID	Measure	Requirement	Evidence
M-50	Three levels: operations log, security audit log, ledger	A-11	See Audit and evidence
M-51	Chaining over all fields with unambiguous, length-prefixed encoding, per tenant	A-11	Chain verification with tampered inputs
M-52	External, append-only anchor for chain heads; continuous copy of the security audit log	A-11	Reconciliation
M-53	Reconciling the HSM's signature counters against the ledger	A-12	Alert on discrepancy

Development and software supply chain

ID	Measure	Requirement	Evidence
M-60	Warnings are errors; an undocumented public interface breaks the build	A-17	Build
M-61	Naming gate against legacy names and placeholders (forbidden patterns, open work markers, placeholder method bodies)	A-17	The build reports file, line, and pattern
M-62	No secrets in the repository, not even test keys	A-17	Secret scanning in the build; checking the test vector directory for key material
M-63	Verified provenance of every cryptographic library: provenance record, checksum recomputed in the build, entry in the bill of materials per target platform	A-17	Build, bill of materials
M-64	Dependencies only through central package management with pinned versions	A-17	Build
M-65	Documentation tests: evidence chain against pages and measure catalog, no internal references, resolvable links, page order, diagram rules	A-17	`dotnet test`; seen failing with deliberate violations

Organizational measures

ID	Measure	Requirement
M-70	Ceremonies with a lead, custodians (quorum 3 of 5), and witnesses; two safes	A-03, A-19
M-71	Four-eyes principle for changes to the worker's rule set	A-02
M-72	Compromise procedure for CA keys, rehearsed regularly	A-12
M-73	Relying-party contract as part of partner contracts	A-01
M-74	Retention and deletion periods for logs, set by each organization	A-16

Federation and post-quantum layer

ID	Measure	Requirement	Evidence
M-80	Relationships only through trust bundles signed by the CA worker, with an increasing number and a limited lifetime	A-21	Tests with unsigned, outdated, and foreign bundles
M-81	Relationship policy per direction; changes only with approval under the direction's right to change	A-21	Ledger; tests of the approval rules
M-82	No cross-certificates; the TLS adapter accepts only anchors of active relationships	A-21	Tests with third-party chains
M-83	External PSK per RFC 9973 with `psk_dhe_ke` and a hybrid group; abort without a confirmed extension	A-22	Packet captures; tests with wrong and suppressed PSK
M-84	Secrets only in the memory of the two hosts involved; hand-over only through the key broker's local interface	A-22	Architecture test; checking storage and logs for key material
M-85	Connection rotation at the relationship's maximum lifetime; no session resumption and no 0-RTT for relationship connections	A-22	Long-running test with packet capture
M-86	Partner identity passed to the target application; the target application is reachable only through the TLS adapter	A-23	Network test; test with headers set by the client itself
M-87	In the Managed model, no approval keys and no custodian roles at the operating partner; change of operator through a new CA generation	A-24	Rule set; trial change in a test environment

What this page does not prove

Completeness against any framework. The mapping to frameworks in Audit and evidence is not a claim of conformity.
Measures inside target applications. How the Database Gateway, for example, enforces permissions is described in its own documentation.