Cryptography

Status: Implemented Source: core library src/__Libraries/StellaOps.Cryptography/; signing profiles and regional plugins under src/Cryptography/ Owner: Platform Team

Purpose

The Cryptography module provides StellaOps with pluggable cryptographic primitives that support regional standards (eIDAS, FIPS, GOST, SM, and post-quantum). It enables sovereign operation under country-specific crypto requirements while keeping signing operations deterministic and offline-capable.

Audience: operators selecting and configuring crypto providers for sovereign or air-gapped deployments, and module authors who sign or verify artifacts (Signer, Attestor, Authority, Evidence Locker).

Components

Core library (src/__Libraries/StellaOps.Cryptography/):

Signing profiles (src/Cryptography/):

Regional / provider plugins (src/Cryptography/StellaOps.Cryptography.Plugin.*): All extend CryptoPluginBase (PluginCapabilities.Crypto, PluginTrustLevel.BuiltIn):

Experimental provider packs:

Test-only simulator:

Post-quantum signatures (Dilithium, Falcon) are declared as SignatureProfile values and SignatureAlgorithms identifiers. The local pq.soft route remains experimental and is not production release evidence.

Configuration

Cryptographic profiles are configured through module-specific settings (Signer, Attestor, Authority).

Authorization scopes (canonical catalog StellaOps.Auth.Abstractions/StellaOpsScopes.cs) protect the Platform crypto-provider control plane:

The SM remote cryptography service (SmRemote) exposes its own scopes: sm-remote:hash, sm-remote:encrypt, sm-remote:decrypt, sm-remote:sign, sm-remote:verify.

Key features:

Dependencies

ARM64 Runtime Posture

Stella Ops first-party .NET service images are ARM64-ready on Debian/Ubuntu glibc linux-arm64. Base ARM64 builds must not require GOST, PKCS#11, OpenSSL GOST, or CryptoPro provider binaries. Regional routes are optional until an operator selects and configures them.

The managed PKCS#11 dependency is not the production ARM64 blocker; the native library referenced by LibraryPath is. Production linux/arm64 .NET service images stay on Debian/Ubuntu glibc so native NuGet assets and operator-supplied provider libraries are validated against the same ABI. Alpine/musl .NET service images require a separate dependency and provider audit before they can be part of the ARM64 readiness baseline.

GOST support is a regional cryptography route, not a bank-specific feature. Where certification rules allow substitution, prefer an open-source route such as OpenSSL GOST or an open PKCS#11 backend over a proprietary local provider. Russian vendor GOST providers are not supported for local ARM64 Stella Ops installations in this release unless the operator obtains a provider-supported Debian/Ubuntu linux-arm64 package and route evidence. Operators who require that path should contact their GOST provider for ARM64 Linux support.

Current Status

Core profiles. ECDSA P-256 and EdDSA (Ed25519) profiles are implemented.

Runtime dependency boundary. Auth.ServerIntegration no longer depends on StellaOps.Configuration, so services that only need Authority JWT validation do not inherit the shared crypto DI package or optional regional/simulator provider projects through that path. Shared crypto DI is also base-safe by default: optional regional, simulator, PQ, and proprietary provider source plus project references are compiled only when StellaOpsEnableOptionalCryptoProviders=true is set for explicit provider-pack builds. Hosts that call AddStellaOpsCrypto(...) get only the default local provider, hash/HMAC/random services, and registry unless they opt in at build time.

Fail-closed posture. Regional provider plugins are usable only when backed by configured key material or explicit local-harness flags. HSM simulation, generated FIPS/GOST/SM signing keys, derived symmetric keys, and default HMAC keys are not production defaults; HSM simulation is additionally gated by runtime environment and fails closed outside Development/Testing. Missing or unsupported provider-backed regional crypto fails closed rather than claiming verification or signing success. Explicit provider names are trust-root selections: unknown providers fail closed, and production Authority/Attestor signing rejects sim.crypto.remote and software-only cn.sm.soft so a simulator or local software key cannot become signing authority by fallback.

Provider readiness (2026-04-27 local provider map in architecture.md). GOST, SM, eIDAS, FIPS, HSM, and simulator surfaces are not uniformly missing. Production-capable GOST libraries, the HSM PKCS#11 client, SM software/remote adapters, and eIDAS plugin scaffolding exist; the continuation work is route wiring, service packaging, sealed provider packs, and end-to-end tests. The placement contract in architecture.md records where real providers, bridge services, and test simulators belong.

eIDAS evidence. Public JWK export is no longer synthetic: local keys export from configured certificate material, and remote TSP/QSCD keys fail closed unless public certificate metadata is configured. EvidenceProfile requests above BaselineB fail closed in the default provider — it checks for timestamp, OCSP/CRL, archive timestamp, and TSL references, then rejects the operation unless a real provider pack supplies evidence embedding and local validation.

Simulator and provider packs. The universal simulator service under devops/services/crypto/sim-crypto-service/ is the default Development/Testing fixture provider when STELLAOPS_ALLOW_UNSAFE_CRYPTO_SIM=1; it reports testOnly=true, production=false, and releaseEvidence=false, and the default smoke covers eIDAS, GOST, SM, FIPS, and PQ labels with tamper rejection. Deployment-specific provider packs supply real vendor/operator proof for eIDAS QSCD/QTSP/TSA/OCSP/CRL/TSL, licensed CryptoPro or OpenSSL/PKCS#11 GOST routes, SM HSM/SDF/PKCS#11 via SmRemote, and FIPS/HSM vendor PKCS#11 evidence. The default Signer compose profiles mount crypto configuration and trust-root directories only; they do not mount devops/plugins/crypto/base, recommended, or harness because core/default and offline.verification providers are host-owned. Explicit regional crypto overlays may mount signed provider packs and must fail closed when the selected pack or trust root is absent; docker-compose.plugins.crypto-eidas.yml, docker-compose.plugins.crypto-fips-hsm.yml, docker-compose.plugins.crypto-gost.yml, and docker-compose.plugins.crypto-sm-hsm.yml select their profile-specific Signer pack roots, while docker-compose.plugins.crypto-sm.yml mounts the signed cn.sm.soft pack into the opt-in SmRemote sidecar. The simulator overlay remains test-only and now routes Signer through the signed crypto-sim profile when the unsafe flag is explicitly set.

Provider-pack manifest/registry reconciliation (2026-06-12). The source catalog in src/Cryptography/StellaOps.Cryptography.Plugin/CryptoProviderPackCatalog.cs, devops/etc/crypto-plugins-manifest.json, devops/etc/plugins/crypto/registry.yaml, and devops/etc/appsettings.crypto.*.yaml now share the same contract: base is default plus offline.verification; optional packs are com.stellaops.crypto.{fips,hsm,eidas,gost,sm}, cn.sm.soft, cn.sm.remote.http, pq.soft, and sim.crypto.remote. The manifest uses packId when a signed bundle ID differs from its runtime provider IDs. AWS/GCP/Azure KMS remain future-only and are not registered in the base/default profile.