stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 16 Releases Wiki Activity
Files
7e7be4d2fd30491b9fba6a9236af08fe1e9fd143
git.stella-ops.org/docs/product-advisories/28-Nov-2025 - Sovereign Crypto for Regional Compliance.md
StellaOps Bot b34f13dc03 up
2025-11-29 02:19:50 +02:00

11 KiB
Raw Blame History

Sovereign Crypto for Regional Compliance

Version: 1.0 Date: 2025-11-28 Status: Canonical

This advisory defines the product rationale, implementation strategy, and compliance mapping for regional cryptography support in Stella Ops, enabling deployments in jurisdictions requiring eIDAS, FIPS, GOST, or Chinese SM algorithms.

1. Executive Summary

Stella Ops must support sovereign-ready cryptography to serve customers in regulated environments where standard cryptographic algorithms are insufficient or prohibited. This includes:

  • EU/eIDAS: Qualified electronic signatures with HSM-backed keys
  • US/FIPS 140-2/3: Federal deployments requiring validated cryptographic modules
  • Russia/GOST: CryptoPro CSP and GOST R 34.10-2012/34.11-2012 algorithms
  • China/SM: SM2 (signing), SM3 (hashing), SM4 (encryption) national standards

The implementation uses a provider registry pattern allowing runtime selection of cryptographic backends without code changes.

2. Market Drivers

2.1 Target Segments

Segment Crypto Requirements Market Size
EU Government/Critical Infrastructure eIDAS QES, qualified timestamps Large (EU Digital Identity Wallet mandate)
US Federal/Defense FIPS 140-2/3 validated modules Large (FedRAMP, CMMC)
Russian Enterprise GOST algorithms, CryptoPro CSP Medium (domestic compliance)
Chinese SOE/Government SM2/SM3/SM4 algorithms Large (mandatory for PRC government)

2.2 Competitive Positioning

Most vulnerability scanning tools (Snyk, Trivy, Grype) do not offer sovereign crypto options. Anchore Enterprise provides FIPS builds. Stella Ops can differentiate by supporting all major regional standards through a unified provider registry.

3. Technical Architecture

3.1 Provider Registry Pattern

The ICryptoProviderRegistry abstraction enables runtime selection of cryptographic implementations:

┌────────────────────────────────────────────────────────────────┐
│                    Application Layer                           │
│  (Scanner, Authority, Attestor, Export Center, etc.)          │
└────────────────────────────┬───────────────────────────────────┘
                             │
                             ▼
┌────────────────────────────────────────────────────────────────┐
│                  ICryptoProviderRegistry                       │
│  - ResolveHasher(profile)                                     │
│  - ResolveSigner(profile)                                     │
│  - ResolveKeyStore(profile)                                   │
└────────────────────────────┬───────────────────────────────────┘
                             │
         ┌───────────────────┼───────────────────┐
         ▼                   ▼                   ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│ Default Profile │  │   RU Profile    │  │   CN Profile    │
│ - SHA-256/384   │  │ - GOST R 34.11  │  │ - SM3 hash      │
│ - ECDSA P-256   │  │ - GOST R 34.10  │  │ - SM2 signing   │
│ - AES-256-GCM   │  │ - Magma/Kuznech │  │ - SM4 encryption│
└─────────────────┘  └─────────────────┘  └─────────────────┘

3.2 Profile Configuration

stellaops:
  crypto:
    registry:
      activeProfile: "default"  # or "ru-offline", "cn-government"
      profiles:
        default:
          hashAlgorithm: "SHA256"
          signingAlgorithm: "ECDSA-P256"
          encryptionAlgorithm: "AES-256-GCM"
          providers:
            - "default"
        ru-offline:
          hashAlgorithm: "GOST-R-34.11-2012-256"
          signingAlgorithm: "GOST-R-34.10-2012"
          encryptionAlgorithm: "GOST-28147-89"
          providers:
            - "ru.cryptopro.csp"
            - "ru.openssl.gost"
            - "ru.pkcs11"
        cn-government:
          hashAlgorithm: "SM3"
          signingAlgorithm: "SM2"
          encryptionAlgorithm: "SM4"
          providers:
            - "cn.tongsuo"
            - "cn.pkcs11"

3.3 Provider Implementations

Provider ID Backend Algorithms Platform
default .NET BCL SHA-2, ECDSA, AES All
ru.cryptopro.csp CryptoPro CSP GOST R 34.10/11, Magma Windows
ru.openssl.gost OpenSSL + GOST engine GOST algorithms Linux
ru.pkcs11 PKCS#11 tokens GOST (hardware) All
cn.tongsuo Tongsuo (OpenSSL fork) SM2/3/4 Linux
cn.pkcs11 PKCS#11 tokens SM algorithms (hardware) All
fips OpenSSL FIPS module FIPS 140-2 validated Linux

4. Implementation Strategy

4.1 Phase 1: Registry Foundation (Complete)

  • ICryptoProviderRegistry interface published
  • Default profile with .NET BCL backend
  • Configuration binding via StellaOps:Crypto:Registry

4.2 Phase 2: GOST/RU Support (In Progress)

  • CryptoPro CSP plugin via forked GostCryptography library
  • OpenSSL GOST engine integration
  • Windows-only CSP tests with opt-in CI pipeline
  • RootPack RU distribution bundle

4.3 Phase 3: PQ-Ready Extensions (Planned)

  • Post-quantum algorithms (Dilithium, Falcon) for DSSE
  • Hybrid signing (classical + PQ) for transition period
  • Registry options for algorithm agility

4.4 Phase 4: SM/CN Support (Future)

  • Tongsuo integration for SM2/3/4
  • PKCS#11 support for Chinese HSMs
  • Compliance documentation for PRC requirements

5. Compliance Mapping

5.1 eIDAS (EU)

Requirement Stella Ops Capability
Qualified Electronic Signature (QES) HSM-backed signing via PKCS#11
Qualified Timestamp RFC 3161 via external TSA
Advanced Electronic Seal DSSE attestations with organizational keys
Long-term preservation (LTV) Audit bundles with embedded timestamps

5.2 FIPS 140-2/3 (US)

Requirement Stella Ops Capability
Validated cryptographic module OpenSSL FIPS provider
Approved algorithms only Profile restricts to FIPS-approved
Key management HSM or FIPS-validated software
Self-tests Provider initialization checks

5.3 GOST (Russia)

Requirement Stella Ops Capability
GOST R 34.10-2012 (signing) CryptoPro CSP / OpenSSL GOST
GOST R 34.11-2012 (hashing) Provider registry selection
Magma/Kuznyechik (encryption) Symmetric support planned
Certified CSP CryptoPro CSP integration

5.4 SM (China)

Requirement Stella Ops Capability
SM2 (signing) Tongsuo / PKCS#11
SM3 (hashing) Provider registry selection
SM4 (encryption) Symmetric support planned
GB/T certification Third-party certification path

6. Determinism Requirements

All cryptographic operations must maintain Stella Ops determinism guarantees:

  1. Same inputs + same profile = same output (for hashing/signing with deterministic algorithms)
  2. Timestamps in UTC ISO-8601 format
  3. Profile names and provider IDs in lowercase ASCII
  4. Audit material includes provider version and configuration hash

For algorithms with inherent randomness (ECDSA k-value, SM2), determinism applies to verification, not signature bytes.

7. Offline/Air-Gap Support

Sovereign deployments often require air-gapped operation:

Feature Offline Support
Provider initialization Local configuration only
Key storage Local HSM or file-based
Certificate validation Offline CRL/OCSP stapling
Timestamp authority Embedded timestamps or offline TSA
Algorithm updates Bundled in RootPack distributions

8. Testing Strategy

8.1 Unit Tests

  • Provider registry resolution
  • Algorithm selection per profile
  • Configuration validation

8.2 Integration Tests (Platform-Specific)

Test Suite Platform Trigger
Default profile All Default CI
GOST/CryptoPro Windows + CSP Opt-in pipeline
GOST/OpenSSL Linux + GOST engine Opt-in pipeline
FIPS Linux + FIPS module Opt-in pipeline
SM Linux + Tongsuo Future

8.3 Compliance Validation

  • NIST CAVP vectors for FIPS algorithms
  • GOST test vectors from TC 26
  • SM test vectors from GM/T standards

9. Distribution & Licensing

9.1 RootPack Bundles

Bundle Contents Distribution
rootpack-default Standard algorithms only Public
rootpack-ru GOST providers + CryptoPro plugin Restricted (RU customers)
rootpack-cn SM providers + Tongsuo Restricted (CN customers)
rootpack-fips FIPS-validated binaries Enterprise only

9.2 Licensing Considerations

  • CryptoPro CSP requires customer license
  • OpenSSL GOST engine under Apache 2.0
  • Tongsuo under Apache 2.0
  • Forked GostCryptography under MIT (with AGPL obligations from Stella Ops wrapper)

10. Related Documentation

  • docs/security/rootpack_ru_*.md - RootPack RU documentation
  • docs/security/crypto-registry-decision-2025-11-18.md - Registry design decision
  • docs/security/crypto-routing-audit-2025-11-07.md - Crypto routing audit
  • docs/security/pq-provider-options.md - Post-quantum options
  • docs/modules/signer/architecture.md - Signer service crypto usage

11. Sprint Mapping

  • Primary Sprint: SPRINT_0514_0001_0001_sovereign_crypto_enablement.md
  • Blocking Dependencies:
    • Authority provider/JWKS contract (AUTH-CRYPTO-90-001)
    • Windows CSP test runner for CryptoPro validation
  • Status: Phase 2 (GOST/RU) in progress with multiple tasks BLOCKED

12. Success Metrics

Metric Target
Profile switch without code change 100%
GOST signing/verification Working on Windows + Linux
FIPS validation coverage All signing/hashing paths
Offline kit reproducibility Deterministic across profiles

Last updated: 2025-11-28