Regional Crypto Route Matrix

This matrix defines the route evidence Stella Ops expects when regional crypto provider selection is configured for signing surfaces. It is a routing and evidence contract, not a provider implementation guide.

Simulator rows are smoke-test only. They must never satisfy release evidence, production attestability, or compliance proof requirements.

Signing Surfaces

Surface	Route configuration	Route fields that must be preserved
Authority OIDC/JWKS	`Authority:Signing:*`, notification ACK signing, revocation and permalink signing options	Provider id, key id or certificate `kid`, algorithm, and JWKS/public key metadata
Signer DSSE	`Signer:Dsse:*`, key resolver output, preferred provider order	Provider hint, key id, algorithm, and signer metadata
Attestor DSSE	`Attestor:Signing:Keys[]` with `Provider`, `ProviderKeyId`, and `Algorithm`	Configured provider id, provider key id, algorithm, and emitted logical bundle key id
Platform health	`/api/v1/admin/crypto-providers/health`	Configured provider id, observed provider id, observed key id when advertised, algorithm inventory, simulator flags, and drift reasons
Compose smoke	`devops/compose/docker-compose.crypto-provider.*.yml` overlays	Readiness payload, production/test-only flags, required vendor inputs, and fail-closed readiness states

Provider Route Matrix

Profile	Provider id	Expected algorithms	Key id source	Health/readiness source	Release evidence	Required operator inputs	Fail-closed states
eIDAS QTSP/QSCD	`eidas` behind the eIDAS TSP/QSCD HTTP contract	`ES256`, `PS256`, CAdES/QES profile-specific algorithm labels	Configured eIDAS key `KeyId`; TSP/QSCD certificate-derived public `kid`	eIDAS TSP/QSCD adapter contract and sealed trusted-list evidence	Yes only when QSCD/QTSP evidence is present and trusted-list/timestamp/revocation requirements are satisfied	TSP endpoint, TSP credentials, configured public certificate/JWK, sealed EU trusted-list fixture, evidence profile	Missing public certificate/JWK; missing timestamp, revocation, archive, or trusted-list evidence; simulator-shaped TSP response; LT/LTA evidence requested before embedding support
eIDAS local software	`eu.eidas.soft` or local `eidas` PKCS#12 mode	`ES256` or configured AdES algorithm	Local keystore key id	In-process provider diagnostics	No for QES/QSCD release evidence; development or non-qualified AdES only	`EIDAS_SOFT_ALLOWED`, local PKCS#12/PEM material, local certificate	Soft provider used where QSCD is required; missing keystore; certificate/key algorithm mismatch
GOST CryptoPro CSP	`ru.cryptopro.csp`	`GOST12-256`, `GOST12-512`	Operator CryptoPro container/key alias	`cryptopro-csp` `/health` from `docker-compose.crypto-provider.cryptopro.yml`	Yes only with licensed customer packages, CSP health proof, and operator key/container evidence	`CRYPTOPRO_ACCEPT_EULA=1`, customer package directory, CSP container/key name, licensed runtime	EULA not accepted; customer packages missing; `csptest` unavailable; key container missing; simulator or local generated key used as release evidence
GOST OpenSSL or PKCS#11	`openssl.gost`, `ru.pkcs11`	`GOST12-256`, `GOST12-512`	Configured key file, token label, or PKCS#11 object id	Provider diagnostics or HSM/PKCS#11 health	Yes when provider diagnostics and operator key evidence identify the real backend	OpenSSL engine/provider configuration or PKCS#11 library/slot/PIN/key id	Provider not registered; unsupported algorithm; token/library missing; key id not declared
SM Remote HSM	`cn.sm.remote.http`	`SM2` for signing/verification; SM3/SM4 for hash/encrypt surfaces	`SMREMOTE_KEYS` logical-to-remote key mapping	SmRemote `/status`, `/keys`, and vendor adapter health	Yes when production HSM adapter reports `cn.sm.remote.http`, non-simulator metadata, and explicit key mapping	`SMREMOTE_PROVIDER=cn.sm.remote.http`, `SM_REMOTE_HSM_URL`, optional `SM_REMOTE_HSM_API_KEY`, `SMREMOTE_KEYS`	Missing HSM URL; empty key mapping; adapter unavailable; adapter kind mismatch; simulator/test-only response; software provider reported in production
HSM PKCS#11	`com.stellaops.crypto.hsm` in PKCS#11 mode	`HSM-RSA-PSS-SHA256`, `HSM-RSA-SHA256`, `HSM-ECDSA-P256`, configured HSM algorithms	PKCS#11 token/object key id from configured key allow-list	HSM plugin health details with `providerMode=pkcs11`, `pkcs11=true`, `testOnly=false`	Yes when backed by an operator device or certified slot evidence	PKCS#11 library path, slot id, token label, PIN/secret, signing key ids	Missing library, slot, token label, PIN, or key id; no token present; simulation mode used for release evidence
FIPS software or HSM	`fips.ecdsa.soft`, `com.stellaops.crypto.fips`, or HSM-backed FIPS route	`ES256`, `ES384`, `PS256`, `RSA-PSS-SHA256`, configured FIPS labels	Configured local key, KMS/HSM key, or FIPS provider key id	Provider diagnostics plus OS/FIPS mode or HSM evidence	Yes only with OS/provider FIPS mode proof or certified HSM evidence	FIPS mode setting, configured RSA/ECDSA/HMAC/AES keys, or HSM/KMS key reference	FIPS mode required but unavailable; generated or derived local harness keys used as production evidence; key material missing
Universal simulator	`sim.crypto.remote`	`SM2`, `sm.sim`, `sm2.sim`, `GOST12-256`, `GOST12-512`, `ru.magma.sim`, `ru.kuznyechik.sim`, `fips.sim`, `eidas.sim`, `pq.sim`, `DILITHIUM3`, `FALCON512`	`sim-key` from `/keys`	`sim-crypto` `/keys`, `/sign`, and `/verify` from `docker-compose.crypto-provider.crypto-sim.yml`	No. Development/Testing smoke coverage only.	`STELLAOPS_ALLOW_UNSAFE_CRYPTO_SIM=1`	Any release evidence attempt; `production=true`; `testOnly=false`; `releaseEvidence=true`; missing `sim-key`; missing advertised smoke algorithms

Platform Health Contract

/api/v1/admin/crypto-providers/health is a route-readiness endpoint. It reports configured provider route metadata alongside what the probe observed:

providerId is the observed provider id when reported, otherwise the configured id.
keyId is the observed route key when the backend advertises one. Simulator smoke must report sim-key.
algorithms are the observed algorithms when available; otherwise configured route algorithms are shown so operators can see the intended route.
production, testOnly, and releaseEvidence separate smoke readiness from release evidence eligibility.
drift is non-empty when provider id, required key id, required algorithm, or simulator flags do not match the route contract. A non-empty drift list means the provider fails closed for release decisions.

Compose Smoke Notes

Overlay	Smoke check	Expected result without licensed or hardware packages
`docker-compose.crypto-provider.crypto-sim.yml`	Start with `STELLAOPS_ALLOW_UNSAFE_CRYPTO_SIM=1`; query `sim-crypto` `/keys`; run `dotnet run --project ../services/crypto/sim-crypto-smoke` from `devops/compose/`	Payloads report `provider=sim.crypto.remote`, `keyId=sim-key`, `production=false`, `testOnly=true`, and `releaseEvidence=false`. The default smoke signs, verifies, and tamper-checks SM, GOST, eIDAS, FIPS, and PQ labels. This is Development/Testing evidence only.
`docker-compose.crypto-provider.smremote.yml`	Start production SM Remote with `SMREMOTE_PROVIDER=cn.sm.remote.http`; query `/status` and `/keys`	Production without `SM_REMOTE_HSM_URL` and `SMREMOTE_KEYS` must fail closed. A ready production route reports `provider=cn.sm.remote.http` and `SM2`.
`docker-compose.crypto-provider.cryptopro.yml`	Start `cryptopro-csp` wrapper and query `/health`	Without EULA acceptance, customer packages, and `csptest`, the wrapper reports unavailable/degraded readiness. It does not simulate signing evidence.

Operators attach real regional provider evidence to a release by preserving the provider id, provider key id, algorithm, backend readiness payload, and device or vendor proof in the release evidence bundle. Simulator smoke output can be stored as test evidence only and must be excluded from production release decisions.

Production Provider Preparation

Regional release evidence remains real-provider pending unless the route has operator proof:

eIDAS: QSCD/QTSP/TSA integration, qualified certificate chain, timestamp tokens, OCSP/CRL, TSL/LOTL, and archive timestamp evidence through the eIDAS bridge contract.
GOST: an open-source substitution route such as OpenSSL GOST or an open PKCS#11 backend where policy/certification allows, or a licensed provider such as CryptoPro CSP where the deployment requires vendor-backed evidence. All routes still need key/container evidence and provider health.
SM: SmRemote cn.sm.remote.http backed by an SM HSM, SDF service, or PKCS#11 bridge with explicit SMREMOTE_KEYS.
FIPS/HSM: certified HSM/KMS/vendor PKCS#11 route or OS/provider FIPS-mode proof. SoftHSM is test-only unless replaced by operator hardware evidence.

ARM64 Provider Readiness

The managed Pkcs11Interop package is not itself the ARM64 blocker. It loads the operator-configured PKCS#11 library at runtime, so release readiness depends on the actual provider artifact named in configuration.

Stella Ops first-party .NET service images are ARM64-ready on Debian/Ubuntu glibc linux-arm64. GOST is treated as a regional cryptography standard route, not as a bank-specific feature, and the route matrix keeps an open-source substitution path for deployments that do not require a specific certified vendor package.

For ARM64 deployments:

Base Stella Ops images must compile and start without a GOST, OpenSSL GOST, CryptoPro, or PKCS#11 provider installed.
GOST remains an optional regional route. It fails closed only when an operator enables a GOST route and the configured provider cannot prove ARM64 readiness.
Local Russian vendor GOST providers, including CryptoPro-style CSP packages, are not supported on ARM64 Stella Ops installations in this release unless the operator obtains a vendor-supported Debian/Ubuntu linux-arm64 package and matching route evidence. Operators who require this should contact their GOST provider and request ARM64 Linux support for the exact container ABI.
Route diagnostics must record the configured library path or remote provider endpoint, provider id, key id, algorithm inventory, and whether the provider artifact is compatible with the running architecture.
Acceptable production routes are an ARM64 open-source OpenSSL engine/provider or PKCS#11 library when certification rules permit substitution, a vendor ARM64 package with provider evidence, or a remote/sidecar provider that exposes the Stella provider contract from a supported architecture with explicit route evidence.
In-process provider libraries loaded by .NET services must match the runtime image ABI: linux-arm64 and Debian/Ubuntu glibc for the ARM64 baseline. An amd64-only .so must be isolated behind a remote provider or kept on an amd64 service lane.
Simulator output is still development/test evidence only and cannot satisfy ARM64 production GOST or PKCS#11 release evidence.

Operator-Mutable Active Profile (Sprint 503_007)

Persistence: platform.tenant_compliance_profile (single row per tenant, sibling to platform.tenant_crypto_preferences).
Endpoint: PUT /api/v1/admin/crypto-providers/compliance-profile (payload { "profileId": "world|fips|gost|sm|kcmvp|eidas" }).
Auth scope: crypto:profile:admin (distinct from crypto:admin for provider routing) so the region-changing capability can be granted separately.
Audit action: platform.update_compliance_profile with before/after captured server-side via previous_profile.
Console surface: Setup -> Crypto Providers (typed-confirmation dialog showing the algorithm delta).
CLI surface: stella crypto profiles select (Sprint 503_006).

Changing the profile mutates algorithm selection across hashing/MAC/AEAD for the entire tenant (see ComplianceProfiles.cs). The route-matrix rows above remain authoritative for the provider route; the profile column simply selects which set of algorithms a given route is expected to advertise.