stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 16 Releases Wiki Activity
Files
f30805ad7f5457dac581340d20d3f7a1d3afcbf6
git.stella-ops.org/docs/security/rootpack_ru_validation.md
master cef4cb2c5a Add support for ГОСТ Р 34.10 digital signatures 
- Implemented the GostKeyValue class for handling public key parameters in ГОСТ Р 34.10 digital signatures.
- Created the GostSignedXml class to manage XML signatures using ГОСТ 34.10, including methods for computing and checking signatures.
- Developed the GostSignedXmlImpl class to encapsulate the signature computation logic and public key retrieval.
- Added specific key value classes for ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012/256, and ГОСТ Р 34.10-2012/512 to support different signature algorithms.
- Ensured compatibility with existing XML signature standards while integrating ГОСТ cryptography.
2025-11-09 21:59:57 +02:00

5.0 KiB
Raw Blame History

RootPack_RU Crypto Validation Runbook

Purpose

This runbook documents the repeatable steps for validating the Russian sovereign crypto profile (CryptoPro on Windows, OpenSSL/Bouncy-managed on Linux, plus PKCS#11) prior to publishing a RootPack bundle. It supplements the crypto routing audit by covering deterministic tests, hardware validation, and the audit metadata artifacts that must be attached to each release.

1. Deterministic Test Harness

  1. Run scripts/crypto/run-rootpack-ru-tests.sh (optional ROOTPACK_LOG_DIR=/tmp/rootpack_ru_logs to override the output path). The script executes:
    • src/__Libraries/__Tests/StellaOps.Cryptography.Tests/StellaOps.Cryptography.Tests.csproj
    • src/Scanner/__Tests/StellaOps.Scanner.Worker.Tests/StellaOps.Scanner.Worker.Tests.csproj
    • src/Scanner/__Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests.csproj and emits .log + .trx pairs plus README.tests under logs/rootpack_ru_<timestamp>/.

    Note: CryptoPro/PKCS#11 integration suites have not landed yet; the harness currently covers only default SHA/Ed25519 paths. Hardware validation (sections 2–3) is still manual until those tests exist.

  2. For ad-hoc runs (CI or IDE) ensure the same three projects succeed; the cryptography tests validate SHA-256/SHA-512 against BCL implementations and both Streebog variants against BouncyCastle digests.
  3. Archive the generated log directory (logs/rootpack_ru_<timestamp>/) along with any additional test outputs inside the RootPack evidence bundle.

2. Hardware Validation (CryptoPro CSP)

  1. Install CryptoPro CSP (v5.0 or later) on the validation host and import the qualified certificate configured for the deployment.
  2. Configure StellaOps:Crypto:CryptoPro:Keys with the container handle and certificate thumbprint and set StellaOps:Crypto:Registry:ActiveProfile=ru-offline.
  3. Run the provider diagnostics to confirm the key material is visible:
    • dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- providers --config etc/rootpack/ru/crypto.profile.yaml --profile ru-offline --json > logs/ru_cryptopro_providers.json
  4. Issue a JWKS fetch (curl https://authority.local/.well-known/jwks) and verify the kid and crv values match the CryptoPro-backed key.
  5. Capture the Authority logs showing AuthoritySecretHasherInitializer startup and the CryptoProviderMetrics counters for ru.cryptopro.csp usage.

2.1 Hardware Validation (OpenSSL/Bouncy Linux path)

  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.

3. Hardware Validation (PKCS#11 Tokens)

  1. Install the vendor PKCS#11 library (e.g., Rutoken rtPKCS11ECP.dll or JaCarta) and configure the slot/PIN inside StellaOps:Crypto:Pkcs11:Keys.
  2. Switch the registry profile to prioritize ru.pkcs11 and rerun dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- providers --config etc/rootpack/ru/crypto.profile.yaml --profile ru-offline --json > logs/ru_pkcs11_providers.json.
  3. Execute a signing workflow (Authority JWKS refresh or Scanner manifest publish) and confirm the CryptoProviderMetrics counters record ru.pkcs11 activity.
  4. Export the token audit logs (if available) and store them with the RootPack evidence bundle.

4. RootPack Audit Metadata

Create a metadata bundle per validation run and store it under logs/rootpack_ru_<timestamp>/ containing:

  • providers_ru_offline.json – output from stellaops crypto providers --profile ru-offline --json.
  • crypto_tests.txt – snippets from the unit-test executions listed above.
  • hardware_notes.md – human-readable notes describing token serials, firmware, and operator initials.
  • jwks_snapshot.json – raw JWKS response captured after sovereign providers are active.
  • metrics_snapshot.json – scrape of CryptoProviderMetrics Prometheus samples for both providers.

Attach this directory to the RootPack artifact and reference it from the release checklist.

Refer back to docs/security/crypto-routing-audit-2025-11-07.md for the full inventory of components that must consume the shared cryptography stack, and docs/security/rootpack_ru_package.md for packaging/attachment steps.

Known gaps (2025-11-09)

  • The stellaops crypto providers ... CLI referenced above is still pending implementation—operators must capture PKCS#11 slot info manually.
  • No automated CryptoPro/PKCS#11 integration tests exist; sovereign hardware validation relies on manual signing runs.
  • Symmetric GOST (Magma/Kuznyechik) validation is not covered yet.

These items are tracked in Sprint 514 and will be reflected in this runbook once the corresponding tooling lands.