Skip to content

Security: excid-io/immerse-dev

Security

docs/security.md

IMMERSE Security Architecture

Table of Contents

Overview

IMMERSE delivers an end-to-end, standards-based identity flow for immersive experiences. The Issuer produces Verifiable Credentials using OpenID for Verifiable Credential Issuance (OID4VCI) in the SD-JWT VC format, the Verifier requests and validates Verifiable Presentations using OpenID for Verifiable Presentations (OID4VP), and the Wallet (holder agent) runs inside a Confidential Virtual Machine (CVM) and stores credentials, creates VPs, and proofs. The Attestation Service signs client attestation JWTs establishing that wallet instances run inside a genuine CVM, and the Key Registry publishes issuer signing keys and status information so verifiers can check signatures and revocation. Security extends across nultiple layers: protocol (nonce/state, PoP, holder binding), platform (attestation service), and cluster layers with Kubernetes isolation (namespaces, RBAC, NetworkPolicy, sealed secrets).

End-to-End Trust and Threat Model

The ecosystem is designed to mitigate risks such as credential cloning, token replay, environment spoofing, and key misuse. From a high-level perspective, trust in the IMMERSE ecosystem is established through the following three mechanisms. Before any token exchange, the wallet obtains a client-attestation JWT from the Attestation Service, proving that the request originates from a wallet instance inside the CVM and an authorized wallet pod. Additionally, both credential proofs and later presentations utilize the holder's private key whose public JWK (cnf.jwk) is embedded in the credential and proofs, ensuring that only the entity controlling that key can produce valid proofs and VPs. Third, freshness is also considered and handled as mandated by the specifications and drafts considered during the implementation of the IMMERSE ecosystem. Specifically, issuers and verifiers issue short-lived nonces and state values, the wallet must include them in proofs and responses, reducing the risk of replay or cross-session substitution. The primary threats considered are malicious relying parties, and compromised pods. Note that host-level attacks are mitigated by CVM memory encryption (to the extent that they are mitigated by the AMD SEV threat model) and by keeping attestation signing keys behind a PKCS#11 boundary (SoftHSM) with non-exportability.

The IMMERSE ecosystem consists of several elements whose integrity and confidentiality must be preserved. Verifiable Credentials (VCs) themselves are the primary object of protection, which is achieved by demonstrating proof of possesion of the holder's private key. Platform trust is rooted in the Attestation Key (A-Key), which represents the CVM's identity, while each wallet pod maintains its own Client Instance Key (CI-Key) to distinguish instances within the same environment. Issuers rely on ephemeral signing keys to sign credentials, limiting exposure through regular rotation. Revocation lists and status endpoints provide ensure that compromised or outdated credentials can be detected. Finally, user consent and disclosure choices displayed in the wallet UI preserve privacy and ensure that no claim is revealed without explicit holder consent.

Within the IMMERSE ecosystem, several categories of adversaries are taken into account. At the protocol level, network attackers may attempt to intercept traffic or replay tokens to gain unauthorized access. At the application level, malicious relying parties could request excessive or correlating claims, undermining user privacy. At the infrastructure level, compromised pods pose risks if exploited through software flaws. Host-level threats also exist, where curious or malicious hypervisors might attempt to inspect CVM memory. Key misuse or leakage, such as accidental export or unauthorized signing, represents another critical risk. Finally, operational misconfigurations, including weak RBAC rules, mis-scoped NetworkPolicies, or stale secrets, can escape the intended isolation boundaries and expose sensitive components.

The IMMERSE ecosystem faces a range of potential threats, each addressed through layered mitigations. One concern is credential cloning and replay, where stolen VCs or old proofs might be reused. This risk is reduced through nonce and state binding in both OID4VCI and OID4VP flows, in-memory replay caches at issuers and verifiers, and the use of short-lived access tokens and proof-of-possession JWTs. Another threat is environment spoofing, in which a compromised or malicious pod outside the CVM attempts to impersonate a wallet. To address this, the Attestation Service issues client-attestation JWTs only after verifying namespace and service account identity through Kubernetes TokenReview, while the A-Key is stored in SoftHSM as a non-exportable, sign-only key.

Key misuse is also a critical risk, whether through extraction or unintended use of the A-Key, CI-Key, or Holder Key. Here, SoftHSM enforces PKCS#11 semantics to prevent export, Holder keys are generated only in CVM memory and never persisted, and issuer signing keys are ephemeral, rotated every 24 hours with registry retention of 48 hours (implementation specific timeframe for demo purposes). The risk of compromised pods attempting lateral movement is mitigated by namespace separation (cvm-wallets and cvm-security) with strict RBAC, Cilium NetworkPolicies that only allow wallet pods to reach the Attester on port 5000, and the use of Sealed Secrets to keep sensitive values encrypted at rest. At the host level, hypervisors or operating systems might attempt to read CVM memory. AMD SEV encrypts VM memory to resist such attacks, while SoftHSM adds a logical boundary for key usage, and the attestation chain ensures issuers only trust genuine CVMs.

Revocation and expiration present another challenge, where revoked or expired credentials might still be used. Verifiers mitigate this by querying the issuer's /.well-known/credential-status.json, while the wallet enforces expiration claims locally and removes expired credentials. Administrative endpoints allow immediate revocation when required. Finally, operational risks such as misconfiguration, stale secrets, or weak monitoring are addressed through Sealed Secrets for safe GitOps, timing logs across issuer and verifier for transparency, Kubernetes probes to ensure pods restart on failure, and explicit cleanup scripts to reduce residual artifacts.

Despite these measures, some residual risks remain. Replay caches are currently in-memory only, meaning persistence across restarts is not yet implemented. Metadata endpoints are served as unsigned JSON, the Key Registry accepts unauthenticated submissions in demo mode, which would need hardening for real deployments. External revocation checks, often routed through ngrok in development, add latency and potential exposure. Finally, while SoftHSM provides logical isolation, it is software-based; no hardware HSM integration is yet in place. These residual risks define the roadmap for future hardening and production-grade deployments.

Confidential Computing in Context

Running the wallet inside a CVM (AMD SEV family) encrypts memory and narrows the attack surface of a malicious or curious host. Confidential Computing does not, by itself, enforce cryptographic usage semantics or key lifecyclesm thus SoftHSM complements CVM isolation by providing a key usage boundary (sign-only, non-exportable handles, auditable access), and a PKCS#11 interface that can later map to a hardware HSM or a TEE KMS. If SEV-class hardware isn't available, the system still functions (issuance/presentation flows remain standard), but loses hardware-enforced confidentiality, however SoftHSM still adds logical isolation and non-exportability.

Known Limitations and Future Work

While the IMMERSE ecosystem demonstrates a secure, end-to-end credential lifecycle, certain aspects are implemented at proof-of-concept level to prioritize interoperability and provide a demo that can be adjusted to fit different use cases. The following limitations and future directions outline both operational improvements and research paths.

All discovery endpoints (e.g., /.well-known/openid-credential-issuer and /.well-known/openid-configuration) currently expose unsigned JSON metadata. While compliant for controlled environments, production systems should sign metadata (JWS) to ensure authenticity. Additionally, nonce and jti replay prevention caches are volatile (in-memory). They do not persist across pod restarts or scale horizontally. Stateless or distributed caches (e.g., Redis or etcd-backed CRDs) would allow replay protection to survive restarts and synchronize across replicas. The attestation service currently relies on a software HSM (SoftHSM). While this ensures non-exportability and PKCS#11 semantics, hardware-backed alternatives (e.g., CloudHSM, NitroKey HSM, or CoCo-integrated key stores) would provide measurable, attestable protection for signing keys. Furthermore, the container build pipeline produces reproducible but unsigned images. Provenance attestation following Supply-chain Levels for Software Artifacts (SLSA) would strengthen assurance that the running container images correspond to reviewed source and have not been tampered with during build or deployment. Finally, in the OpenID for Verifiable Credential Issuance (OID4VCI) 1.0 spec, credential responses can be returned either as plain JSON or as encrypted JWTs. The spec defines an optional mechanism where issuers encrypt the credential response so that wallets receive credentials in a protected form. This is intended to ensure confidentiality of credential payloads during issuance, especially in ecosystems where responses may pass through ubtrusted intermediaries or cross organizational boundaries.

An important avenue for future work is extending discovery endpoints to publish signed metadata (JWS) and register trusted keys. Key isolation could evolve from software tokens to hardware-protected enclaves by integrating Confidential Containers or Intel TDX/AMD SEV-SNP vaults. The Key Registry should be developed into an authenticated, decentralized service that ensures only legitimate entities can register keys. The registry should enforce checks so that private keys are never registered, and so that each key is tied to a verified entity identity. This would strengthen trust in the ecosystem by preventing accidental disclosure or malicious registration of invalid key material. Another important area to explore is through Kubernetes. PodSecurityStandards help ensure namespaces remain properly isolated by enforcing baseline security rules on pods. Admission webhooks can further validate that containers present attestation evidence through SPIFFE/SPIRE before they're admitted, ensuring that only workloads with verified identities and trusted environments are allowed to run. Supply chain traceability may be strengthened through SLSA Level 3+ compliance, integrating build and deployment pipelines with verifiable provenance and image signing using Sigstore Cosign or in-toto, ensuring that the entire trust chain from source to runtime is auditable. Finally, interoperability with ISO/IEC 18013-5, ISO/IEC 18013-7, and emerging ISO/IEC 23220 specifications for remote mDoc use seem promising. While the current wallet focuses on the SD-JWT VC model aligned with OID4VCI, future work may investigate implementing a dual-format wallet that can hold both W3C/SD-JWT VCs and ISO mDocs under a unified interface.

Conclusion

The current IMMERSE implementation successfully demonstrates that Verifiable Credentials and Confidential Computing can coexist. The next step is to expand from confidentiality to verifiability, not only proving that every IMMERSE wallet instance is secure, but that every build, deployment, and key in the system is traceable and attestable. By integrating supply-chain provenance (SLSA), confidential workloads (CoCo/SEV-SNP), and hardware attestation, IMMERSE could evolve into an end-to-end verifiable identity and compute fabric for the WebXR and extended reality ecosystems.

References

There aren’t any published security advisories