stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 16 Releases Wiki Activity
Files
49922dff5ad4435420dac177e832ba4290ceaea9
git.stella-ops.org/docs/security/crypto-routing-audit-2025-11-07.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

9.0 KiB
Raw Blame History

Crypto Routing Audit — 07 Nov 2025

Scope. Inventory direct uses of System.Security.Cryptography (and related primitives) outside the StellaOps.Cryptography* stack to identify callers that must be routed through sovereign-aware providers (default, PKCS#11, CryptoPro, future PQC).

Method. rg -l "using System.Security.Cryptography" src | grep -Ev "__Tests|\.Tests/" (filtered for runtime code). Counts reflect unique files per top-level module.

Summary (runtime files by module)

Module/Area Files bypassing shared crypto
Concelier 34
Scanner 31
Authority 20
Excititor 18
Attestor 18
EvidenceLocker 10
Findings / Vuln Explorer 7
Zastava 6
ExportCenter 6
Policy 4
Scheduler 3
CLI 3
Bench 3
AdvisoryAI 3
Other (Notify, Registry, Signals, etc.) 11 combined

Configuring crypto.regionalProfiles

All hosts can now express provider ordering and profile overrides via configuration:

StellaOps:
  Crypto:
    Registry:
      PreferredProviders:
        - default
        - ru.openssl.gost
        - ru.pkcs11
      ActiveProfile: ru-offline
      Profiles:
        ru-offline:
          PreferredProviders:
            - ru.cryptopro.csp
            - ru.openssl.gost
            - ru.pkcs11
    Pkcs11:
      Keys:
        - KeyId: ru-slot-token
          LibraryPath: /usr/local/lib/librutokenecp.so
          SlotId: "0x1"
          PrivateKeyLabel: signing-key
          CertificateThumbprint: "<thumbprint>"
    CryptoPro:
      Keys:
        - KeyId: ru-csp-token
          ProviderName: "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
          CertificateThumbprint: "<thumbprint>"
    OpenSsl:
      Keys:
        - KeyId: ru-openssl-token
          PrivateKeyPath: /etc/stellaops/keys/ru-openssl.pem
          PrivateKeyPassphraseEnvVar: RU_OPENSSL_PASS
          SignatureFormat: Der

Windows hosts still prefer ru.cryptopro.csp, but Linux deployments automatically fall back to the new ru.openssl.gost provider (BouncyCastle/OpenSSL-backed) so sovereign GOST signing works without CryptoPro.

CLI quick check

Use the diagnostics CLI to inspect providers or produce test signatures without editing service hosts:

dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- providers --config etc/rootpack/ru/crypto.profile.yaml --profile ru-offline
dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- sign --config etc/rootpack/ru/crypto.profile.yaml --key-id ru-openssl-token --alg GOST12-256 --file samples/message.bin --format base64

The CLI accepts JSON or YAML configs, applies registry profile overrides, and prints the resolved provider name (for example, ru.cryptopro.csp on Windows and ru.openssl.gost on Linux).

Call builder.Services.AddStellaOpsCryptoRu(builder.Configuration) to bind this configuration and register the RU providers with the correct preferred order.

Each deployment picks a profile (activeProfile) that resolves to a deterministic provider order, and individual services call into ICryptoProviderRegistry rather than new-ing crypto stacks directly.

Known gaps (2025-11-09)

Even after the initial plug-ins landed, several sovereign-crypto deliverables remain outstanding. These items must be addressed before RootPack_RU can be treated as GA:

  1. Integration tests – There are zero CryptoPro/PKCS#11 tests in src/__Libraries/__Tests/StellaOps.Cryptography.Tests/. The RootPack validation script cannot validate hardware paths today.
  2. Symmetric GOST – Magma/Kuznyechik (RFC 5830 / RFC 7801) support is missing, so RU deployments cannot request sovereign symmetric encryption for exports/data-at-rest.
  3. Host adoption – Authority, Scanner, Concelier, etc. register only the default providers; none call the RU DI helpers or set ActiveProfile = ru-offline, leaving sovereign bundles inert.
  4. Docs/runbooks – RootPack docs reference the CLI/config/test harnesses, but they do not yet exist; we need explicit TODOs (see rootpack docs) and follow-up edits once tooling ships.

Inspecting providers from the CLI

stellaops crypto providers now lists the registered providers, signing algorithms, certificate metadata, and the current preferred order. Use --json for machine-readable output or --profile <name> to preview another profile (e.g., ru-offline) before flipping configuration.

High-priority hotspots

Concelier (ingestion + mirror connectors)

  • src/Concelier/StellaOps.Concelier.WebService/Services/OpenApiDiscoveryDocumentProvider.cs – builds SHA256 hashes for discovery docs inline.
  • src/Concelier/__Libraries/StellaOps.Concelier.Connector.StellaOpsMirror/Security/MirrorSignatureVerifier.cs – performs RSA verification directly.
  • src/Concelier/__Libraries/StellaOps.Concelier.Connector.Ru.Nkcki/RuNkckiConnector.cs and .Ru.Bdu – local hash/signature handling for regional advisories.

Action: Introduce ICryptoProviderRegistry consumption inside connector/lib assemblies (probably through lightweight adapter service). File follow-up tasks in src/Concelier/StellaOps.Concelier.WebService/TASKS.md and connector TASK boards to migrate hashing/signing to the new PKCS#11/CryptoPro providers (priority for RU feeds to unblock RootPack_RU).

Update (2025-11-08). OpenAPI discovery, advisory chunk IDs, SourceFetchService/SourceStateSeedProcessor, OSV/NVD + RU connectors, and the JSON exporter/mirror bundle writers now route hashing/signing through ICryptoHash + StellaOpsCryptoOptions. Remaining Concelier hotspots should now only appear inside the shared StellaOps.Cryptography* assemblies.

Scanner (web service, worker, Sbomer plug-ins)

  • src/Scanner/StellaOps.Scanner.WebService/Utilities/ScanIdGenerator.cs – direct SHA256 for id derivation.
  • src/Scanner/StellaOps.Scanner.WebService/Services/ReportSigner.cs – uses ECDsa.Create() directly for DSSE hand-off.
  • src/Scanner/StellaOps.Scanner.Worker/Processing/Surface/SurfaceManifestPublisher.cs – manual digesting before CAS writes.

Action: Create shared IScanCryptoService backed by ICryptoProviderRegistry so both web service and worker reuse sovereign providers. Add tasks under src/Scanner/StellaOps.Scanner.WebService/TASKS.md and src/Scanner/StellaOps.Scanner.Worker/TASKS.md.

Authority (plugins + signing host)

  • StellaOps.Authority/Signing/* classes still load PEM/PKCS#12 directly via X509Certificate2 and RSA.
  • AuthoritySecretHasher and AuthorityClientCertificateValidator maintain custom hashing.

Action: Wire Authority signing/loading paths to ICryptoProviderRegistry so active keys can point to ru.cryptopro.csp or ru.pkcs11. Open tasks in src/Authority/StellaOps.Authority/TASKS.md covering: signing key loading, JWKS generation, secret hashing migration.

Excititor / Attestor

  • Excititor connectors (e.g., src/Excititor/__Libraries/StellaOps.Excititor.Connectors.Ghsa/GhsaConnector.cs) re-hash payloads in place.
  • Attestor submission cache uses SHA256 for bundle ids.

Action: Introduce shared hashing helper that internally calls ICryptoProviderRegistry.ResolveOrThrow(CryptoCapability.Signing, SignatureAlgorithms.GostR3410_2012_256) for digest+sign combos; log follow-ups in respective TASK boards.

Evidence Locker / Export Center

  • Export packaging code manually builds SHA/V1 digests before signing manifests.

Action: Add backlog tasks for both modules to replace SHA256.Create() usage with provider-backed hashing (especially for offline bundle sealing).

Next steps

  1. Open remediation tasks per module referencing this audit (minimum: Concelier, Scanner, Authority, Excititor, Attestor, Evidence Locker, Export Center). Each task should specify which files to migrate and target provider (default vs sovereign).
  2. Provide shared helpers (e.g., ICryptoDigestService, ICasSigner) in StellaOps.Cryptography to ease adoption and avoid each module talking to the registry manually.
  3. Follow-up audit once migrations land; rerun the command and ensure only StellaOps.Cryptography* and vetted crypto libraries contain direct System.Security.Cryptography usage.
  4. RootPack validation runbook — see docs/security/rootpack_ru_validation.md for deterministic tests, hardware validation, and required audit artifacts before shipping RootPack_RU.

Remediation tracking snapshot (2025-11-08)

  • Authority: AUTH-CRYPTO-90-001 (Authority TASKS board)
  • Scanner: SCANNER-CRYPTO-90-001 (WebService TASKS board)
  • Concelier: CONCELIER-CRYPTO-90-001 (WebService TASKS board)
  • Excititor: EXCITITOR-CRYPTO-90-001 (WebService TASKS board)
  • Attestor: ATTESTOR-CRYPTO-90-001 (Attestor TASKS board)
  • Evidence Locker: EVID-CRYPTO-90-001 (Evidence Locker TASKS board)
  • Export Center: EXPORT-CRYPTO-90-001 (Exporter Service TASKS board)

Stored query artifacts: /tmp/crypto_runtime_non_tests.txt (157 runtime files) and aggregated counts above prepared on 2025-11-07.