stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 3 Releases Wiki Activity

Add support for ГОСТ Р 34.10 digital signatures

Browse Source 
- 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.
This commit is contained in:
master
2025-11-09 21:59:57 +02:00
parent 75c2bcafce
commit cef4cb2c5a
486 changed files with 32952 additions and 801 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/security/crypto-routing-audit-2025-11-07.md
View File

@@ -34,12 +34,14 @@ StellaOps:
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:
@@ -53,10 +55,27 @@ StellaOps:
- KeyId: ru-csp-token
ProviderName: "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
CertificateThumbprint: "<thumbprint>"
CertificateStoreLocation: LocalMachine
CertificateStoreName: My
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:
```bash
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.
@@ -65,10 +84,8 @@ Each deployment picks a profile (`activeProfile`) that resolves to a determinist
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. **CryptoPro CSP integration** – `StellaOps.Cryptography.Plugin.CryptoPro` currently reuses the PKCS#11 core and never talks to CryptoPro CSP / GostCryptography. Replace it with a real CSP-backed signer, including certificate-store lookup and DER/raw normalization.
2. **Ops CLI** – The promised `StellaOps.CryptoRu.Cli` (list keys, try-sign, emit determinism records) has not been implemented; operators are blind when staging PKCS#11/CryptoPro keys.
3. **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.
4. **Symmetric GOST** – Magma/Kuznyechik (RFC 5830 / RFC 7801) support is missing, so RU deployments cannot request sovereign symmetric encryption for exports/data-at-rest.
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.
5. **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.
6. **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.

3
docs/security/pack-signing-and-rbac.md
View File

@@ -73,12 +73,13 @@ Roles are tenant-scoped; cross-tenant access requires explicit addition.
- `stella pack push` → `packs.write`.
- `stella pack approve` → `packs.approve`.
- Offline tokens must include same scopes; CLI warns if missing.
- Approval flows must also pass `pack_run_id`, `pack_gate_id`, and `pack_plan_hash` when requesting `packs.approve`. The CLI exposes these via `stella pack approve --pack-run-id ... --pack-gate-id ... --pack-plan-hash ...` (see `docs/task-packs/runbook.md#4-approvals-workflow` for the full procedure). Authority rejects approval grants that omit or truncate any of these fields and tags the audit record with `pack.*` metadata for replay audits.
---
## 4 · Approvals & Fresh Auth
- Approval commands require recent fresh-auth (< 5 minutes). CLI prompts automatically; Console enforces via Authority.
- Approval commands require recent fresh-auth (< 5 minutes). CLI prompts automatically; Console enforces via Authority. When the `packs.approve` scope is present, `/token` demands `pack_run_id`, `pack_gate_id`, and `pack_plan_hash`, and the resource-layer scope handler verifies the metadata is present plus the `auth_time` timestamp falls within the five-minute window. Missing metadata or stale authentication produce `authority.pack_scope_violation` audit events with the offending field noted.
- Approval payload includes:
- `runId`
- `gateId`

17
docs/security/rootpack_ru_package.md
View File

@@ -6,7 +6,7 @@ This guide describes the reproducible process for assembling the sovereign crypt
| Directory | Purpose |
|-----------|---------|
| `artifacts/` | Published binaries for `StellaOps.Cryptography.Plugin.CryptoPro` and `StellaOps.Cryptography.Plugin.Pkcs11Gost` (targeting `net10.0`). |
| `artifacts/` | Published binaries for `StellaOps.Cryptography.Plugin.CryptoPro`, `StellaOps.Cryptography.Plugin.OpenSslGost`, and `StellaOps.Cryptography.Plugin.Pkcs11Gost` (targeting `net10.0`). |
| `config/rootpack_ru.crypto.yaml` | Opinionated configuration template that enables the `ru-offline` crypto profile and defines CryptoPro + PKCS#11 keys. |
| `docs/` | Validation runbook, audit report, and this packaging guide. |
| `trust/` | Russian trust-anchor PEM files copied from `certificates/russian_trusted_*`. |
@@ -29,6 +29,8 @@ The script performs the following steps:
4. Adds the Russian trust anchors from `certificates/russian_trusted_*`.
5. Emits `README.txt` and optionally creates a `*.tar.gz` archive (set `PACKAGE_TAR=0` to skip the tarball).
> **Temporary quarantine (2025-11-09).** To keep day-to-day builds free of the vulnerable GostCryptography dependency, the repository disables the CryptoPro plug-in unless you pass `-p:StellaOpsEnableCryptoPro=true`. RootPack packaging still works because this script publishes the plug-in directly, but any host/service build that needs CryptoPro must opt in with that MSBuild property until the patched package lands.
## 3. Attach deterministic test evidence
After running `scripts/crypto/package-rootpack-ru.sh`, execute the deterministic harness to capture logs:
@@ -65,13 +67,24 @@ Store these artifacts under `logs/rootpack_ru_<timestamp>/` (same directory as t
1. Import the bundled trust anchors into the target installation (Authority + Scanner).
2. Apply `config/rootpack_ru.crypto.yaml`, update certificate thumbprints, slots, and container labels to match the operator tokens.
3. Restart the services so `ICryptoProviderRegistry` reloads the `ru-offline` profile.
- Windows nodes will prioritize `ru.cryptopro.csp`; Linux nodes automatically fall back to `ru.openssl.gost` (PEM/private-key based) before consulting `ru.pkcs11`.
### 5.1 Diagnostics CLI
Use the diagnostics CLI to validate configs before rolling out changes:
```bash
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-default --alg GOST12-256 --file samples/message.bin --format base64
```
Ship the CLI binary inside the RootPack so operators in sealed environments can run the same diagnostics offline.
4. Re-run the validation runbook to confirm JWKS, telemetry, and RootPack evidence are aligned with the shipping bundle.
## Known gaps (2025-11-09)
The bundle and scripts above assume several pieces of functionality that have not landed yet:
- **Ops CLI:** The CLI referenced in the validation runbook (list/verify keys, emit determinism records) has not been implemented. Operators currently rely on manual pkcs11-tool / certmgr commands.
- **Integration tests:** `scripts/crypto/run-rootpack-ru-tests.sh` exercises only SHA/Ed25519 paths because CryptoPro/PKCS#11 integration tests are still TODO.
- **Symmetric GOST:** RootPack artifacts ship only signing plug-ins; Magma/Kuznyechik support for exports/data-at-rest is pending.

12
docs/security/rootpack_ru_validation.md
View File

@@ -2,7 +2,7 @@
## Purpose
This runbook documents the repeatable steps for validating the Russian sovereign crypto profile (CryptoPro + 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.
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
@@ -20,14 +20,20 @@ This runbook documents the repeatable steps for validating the Russian sovereign
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:
- `stellaops crypto providers --profile ru-offline --json > logs/ru_cryptopro_providers.json`
- `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 `stellaops crypto providers --profile ru-offline --json > logs/ru_pkcs11_providers.json`.
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.