Regional hardware provider activation (GOST / SM) — operator procedure

Status: Software composition DONE; production hardware proof requires operator-supplied hardware and a Stella Ops activation (OSK-P6, sprint SPRINT_20260718_009_Authority_operator_signing_key_lifecycle.md). Audience: operators standing up a regional (Russian GOST / Chinese SM) production signing deployment. Related: regional-signing.md (which tree signs and how registration works), hsm-pkcs11-deployment-health.md (PKCS#11 health/fail-closed), sm-remote-vendor-adapter-contract.md (the SM HTTP adapter contract — read-only reference; do not duplicate here), ADR-025 (operator-signed decisions; the SM_SOFT_ALLOWED verify-gate caveat).

Why this page exists

The regional signing holders are already delivered as plugins/libraries and composed into the production hosts and the regional CLI distributions — no rebuild is needed to obtain the wiring. What is not free is the hardware: a GOST PKCS#11 token or licensed CryptoPro host, and an OSCCA-certified SM HSM reachable through the SmRemote bridge. Those are procured, provisioned, and (for the licensed distribution builds) activated with Stella Ops. This page is the controlled hardware sign → verify → tamper procedure an operator runs to produce genuine production evidence, and it names exactly which knobs and credentials that requires.

The software providers (ru.openssl.gost, cn.sm.soft) are evaluation only. A signature they produce is never production proof — the environment/production guards refuse them outside Development/Testing (see regional-signing.md).

What already ships (no operator build)

The default-ALC ICryptoProvider registry composes the production holders when a regional profile is active and a certified backend is confirmed:

• GOST verification: ru.bouncycastle.gost (managed, verify-only) — always registered for gost (src/__Libraries/StellaOps.Cryptography.HostProviders/RegionalCryptoRegistration.cs:134).
• GOST production holder: ru.pkcs11 (PKCS#11 token) is registered in Staging/Production (RegionalCryptoRegistration.cs:157); ru.cryptopro.csp (CryptoPro CSP) is kept in the preference order when a distribution supplies it (RegionalCryptoRegistration.cs:162-163).
• SM verification facade: SmVerificationOnlyCryptoProvider (cn.sm.soft hint, cannot sign even if SM_SOFT_ALLOWED is set) (RegionalCryptoRegistration.cs:197-198).
• SM production holder: cn.sm.remote.http (SmRemoteHttpProvider over a typed SmRemoteHttpClient) with the production probe/contract/key-mapping guards forced on (RegionalCryptoRegistration.cs:200-222).
• CLI distributions: CliRegionalCryptoComposition.AddDistributionProviders (src/Cli/StellaOps.Cli/CliRegionalCryptoComposition.cs:23) registers the GOST holders (AddBouncyCastleGostProvider/AddOpenSslGostProvider/AddPkcs11GostProvider/AddCryptoProGostProvider, lines 35-38, under STELLAOPS_ENABLE_GOST) and the SM holders (AddSmSoftCryptoProvider/ AddSmRemoteCryptoProvider, lines 42-43, under STELLAOPS_ENABLE_SM), called once from src/Cli/StellaOps.Cli/Program.cs:74.

All of the above live under src/__Libraries/StellaOps.Cryptography.Plugin.* and src/SmRemote/ — they are plugins/libraries, activated by composition/configuration, not by editing code.

Prerequisites (operator-supplied)

Also required: network reachability + credentials for the token/HSM, a maintenance/rollback window (migrations are forward-only; recover by snapshot), and — for the licensed regional distribution builds — activation with Stella Ops (see Activation contact).

Configuration (production)

Set these on the signing hosts (Signer, Attestor) and the regional CLI. Verify every key against src/ before relying on it — config keys drift.

Select the profile and confirm the certified backend

# gost | sm (aliases russia | china normalize). Set on every signing-aware host.
STELLAOPS_CRYPTO_PROFILE=gost           # or: StellaOps:Crypto:Profile
StellaOps:Crypto:CertifiedBackendConfirmed=true

Without CertifiedBackendConfirmed=true (or a profile alias that names the backend, e.g. gost-hsm, china-sm-hsm, russia-cryptopro), a regional profile in Staging/Production fails closed at startup and never falls back to ES256 — this is the sovereignty guarantee, not a bug (RegionalCryptoRegistration.cs:138-148,181-190).

GOST — PKCS#11 token (StellaOps:Crypto:Pkcs11:Keys[])

Per-key descriptor (src/__Libraries/StellaOps.Cryptography.Plugin.Pkcs11Gost/Pkcs11GostKeyOptions.cs):

GOST — CryptoPro CSP

Bind StellaOps:Crypto:CryptoPro (CryptoProGostProviderOptions), build/deploy the host with StellaOpsEnableCryptoPro=true, and set the signing-key entry provider: "ru.cryptopro.csp".

SM — SmRemote HSM bridge (StellaOps:Crypto:SmRemote)

src/__Libraries/StellaOps.Cryptography.Sm.Contracts/SmRemoteProviderOptions.cs:

The three forced flags are applied by the host PostConfigure (RegionalCryptoRegistration.cs:201-209); operator config cannot downgrade a Production SM host to a skipped/simulator-shaped probe. The SmRemote endpoint/response contract itself is specified in sm-remote-vendor-adapter-contract.md — follow it, do not re-derive it here.

Signing-key entries (Attestor)

Attestor:Signing:Keys[] = { keyId, provider, algorithm, providerKeyId }
#   GOST PKCS#11 : provider "ru.pkcs11"          algorithm "GOST12-256"
#   GOST CryptoPro: provider "ru.cryptopro.csp"  algorithm "GOST12-256"
#   SM HSM       : provider "cn.sm.remote.http"   algorithm "SM2"   providerKeyId = mapped RemoteKeyId

The controlled forcing run (sign → verify → tamper)

Run this against the real token/HSM, capturing raw command output as evidence. It mirrors the earlier software-token live proof (2026-07-16-regional-signing-live) but must be executed on certified hardware to count for OSK-P6.

1. Bring up the regional stack with the certified backend mounted:

   # GOST: docker-compose.compliance-russia.yml + docker-compose.crypto-provider.cryptopro.yml
   # SM:   docker-compose.compliance-china.yml  + docker-compose.crypto-provider.smremote.yml
   docker compose -f devops/compose/docker-compose.stella-ops.yml -f <region-overlay> -f <backend-overlay> up -d
   

   Confirm the host started (no fail-closed error) and the provider resolves: stella crypto profiles --details lists ru.pkcs11 / ru.cryptopro.csp / cn.sm.remote.http as a signing-capable provider.
2. Sign a fixture artifact with the hardware provider and the mapped key:

   stella crypto sign --input artifact.tar.gz --provider gost-cryptopro --key-id <prod-key>   # GOST
   stella crypto sign --input artifact.tar.gz --provider sm-remote      --key-id <prod-key>   # SM
   

   Confirm the DSSE/JWS algorithmId is GOST12-256/SM2 and the keyid resolves to the enrolled hardware key (never ES256).
3. Verify the signature end-to-end:

   stella crypto verify --input artifact.tar.gz --signature <sig> --provider <same> --key-id <prod-key>
   

   Expect a pass with the regional algorithm reported.
4. Tamper — flip one byte of the payload (keeping it valid JSON where applicable) and re-verify; expect a hard verification failure. A tamper that still verifies is a stop-the-line defect.
5. Restore the stack to healthy and record the run.

Evidence to capture

• Provider-resolution output showing the certified provider (not a software token).
• Sign output with the regional algorithmId + hardware keyid.
• Verify pass, then the tamper-induced verify failure.
• The token/HSM model + adapter kind, and confirmation CertifiedBackendConfirmed was set (or a backend-naming alias was used). No PINs/secrets in the evidence.

Store under docs/qa/feature-checks/runs/<date>-regional-hardware-<region>/ and link it from the sprint Execution Log.

Activation contact

The Russian GOST and Chinese SM regional holders ship as licensed plugins/libraries. Turning them on for production — obtaining the CryptoPro-enabled/regional distribution build, the vendor adapter, and the activation for a specific deployment — is a supported action, not a self-service console toggle. From the console the regional hardware provider blocks surface an honest activation note rather than dead-ending in inert controls (see the Cryptography Configuration page, system/cryptography).

To activate regional hardware providers, contact support@stella-ops.org.

(That address is the canonical Stella Ops crypto-support contact — see docs/modules/cli/guides/crypto/crypto-commands.md.)