up

docs/security/crypto-compliance.md

@@ -100,6 +100,7 @@ HMAC operations use purpose-based selection similar to hashing:
 ## Simulation paths when hardware is missing
 
 - **RU / GOST**: Linux baseline uses `ru.openssl.gost`; CryptoPro CSP can be exercised from Linux via the Wine sidecar service (`ru.winecsp.http`) built from `scripts/crypto/setup-wine-csp-service.sh` when customers supply the CSP installer. Windows CSP remains blocked until licensed runners are available.
+- **CN / SM2**: Software baseline (`cn.sm.soft`) plus a containerized remote microservice (`cn.sm.remote.http`) that simulates SM2 signing/verification; swap the endpoint to a hardware-backed service when licensed hardware is provided.
 - **CN / SM**: Software-only SM2/SM3 provider (`cn.sm.soft`) backed by BouncyCastle; enable with `SM_SOFT_ALLOWED=1`. Hardware PKCS#11 tokens can be added later without changing feature code because hosts resolve via `ICryptoProviderRegistry`.
 - **FIPS / eIDAS**: Software allow-lists (`fips.ecdsa.soft`, `eu.eidas.soft`) enforce ES256/ES384 + SHA-2. They are labeled non-certified until a CMVP/QSCD module is supplied.
 - **KCMVP**: Hash-only baseline (`kr.kcmvp.hash`) keeps SHA-256 available when ARIA/SEED/KCDSA hardware is absent.

docs/security/rootpack_ru_validation.md

@@ -29,6 +29,20 @@ This runbook documents the repeatable steps for validating the Russian sovereign
 1. Install OpenSSL with the `gost` engine (or vendor equivalent) on the validation host and import the PEM key/cert that will back `StellaOps:Crypto:OpenSsl:Keys`.
 2. Configure the `OpenSsl` section (PEM path plus `PrivateKeyPassphraseEnvVar`), keep `StellaOps:Crypto:Registry:ActiveProfile=ru-offline`, and restart the services.
 3. Execute a signing workflow and confirm `CryptoProviderMetrics` records `ru.openssl.gost` activity. Linux nodes should no longer attempt to load `ru.cryptopro.csp`.
+4. **2025-12-07 validation evidence (Linux, containerised OpenSSL GOST engine):**
+   - Ran `scripts/crypto/validate-openssl-gost.sh` (uses `rnix/openssl-gost:latest`) to generate deterministic digests and two md_gost12_256 signatures over a fixed message. Output folder: `logs/openssl_gost_validation_<timestamp>/`.
+   - Summary from the run at `20251207T220926Z`:
+     - Message SHA256: `e858745af13089d06e74022a75abfee7390aefe7635b15c80fe7d038f58ae6c6`
+    - md_gost12_256 digest: `01ddd6399e694bb23227925cb6b12e8c25f2f1303644ffbd267da8a68554a2cb`
+    - Signature SHA256 (run 1): `02321c5564ae902de77a12c8cc2876f0374d4225e52077ecd28876fbd0110b01`
+    - Signature SHA256 (run 2): `6564c7e0953dda7d40054ef46633c833eec5ee13d4ab8dd0557f2aed1b8d76c4`
+    - Determinism note: digests are stable; signatures vary per run (nonce-driven) but verify cleanly against the emitted public key.
+5. **Host defaults and toggles:** Authority/Signer/Attestor now bind `StellaOps:Crypto` via `AddStellaOpsCryptoRu` and fail-closed on Linux if `ru.openssl.gost`/`ru.pkcs11` are missing. Environment overrides:
+   - `STELLAOPS_CRYPTO_ENABLE_RU_OPENSSL` (default: on for Linux)
+   - `STELLAOPS_CRYPTO_ENABLE_RU_PKCS11` (default: on)
+   - `STELLAOPS_CRYPTO_ENABLE_RU_WINECSP` (default: off)
+   - `STELLAOPS_CRYPTO_ENABLE_RU_CSP` (Windows only; default on)
+   Disable both OpenSSL and PKCS#11 only when an alternate provider is configured; otherwise startup will fail.
 
 ## 3. Hardware Validation (PKCS#11 Tokens)