Missing explicit security requirements per component

Title Missing explicit security requirements per component

Submitted for: Mobil Krankenkasse (statutory public body under German law)
Contact: Sascha Block, IT Architect

Summary The current architecture documentation (decomposition, data flows, guidelines) describes the main components of the German National EUDI Wallet, but does not define explicit, verifiable security requirements per component (PAP, MDVMP, WB, RWSCD, etc.).
For implementers, evaluators and auditors, it remains unclear which concrete security properties each component must fulfil.

Relation to existing issues This issue is intended to complement and operationalize:

• “Comments on and recommendations for the German EUDI wallet architecture relating to cryptographic security” (Eric Verheul) – which calls for clear (cryptographic) security objectives and analysis against high attack potential.

Where Eric’s issue focuses on what type of security assurance is needed at system level, this issue focuses on where and how to document concrete per-component security requirements inside the existing architecture documentation.

Background The architecture concept under:

• Architecture → Decomposition
• Data Flows
• Guidelines → Establishing app integrity
• Guidelines → eID Flow

defines roles and components such as:

• Platform Attestation Provider (PAP)
• Mobile Device Vulnerability Management Provider (MDVMP)
• Wallet Provider Backend (WB)
• Remote Wallet Secure Cryptographic Device (RWSCD)
• Wallet Instance (WI) and Hardware-backed Key Store (HKS)

but does not yet provide a consolidated, component-wise overview of required security properties, controls and assurance levels.

Problem statement The components are structurally described, but it is not specified in a single, normative place:

• which security properties each component must guarantee,
• which attacker model / attack potential they must resist,
• which logging, auditing and replay-protection mechanisms are required,
• and how key lifecycle and operational constraints are to be implemented and evaluated.

This is critical for any Wallet implementation aiming at:

• conformity with CIR 2024/2979 / 2024/2981,
• eIDAS assurance level “high”,
• and future certification/evaluation.

Proposal: Add “Security Requirements per Component” section Add a dedicated section to the architecture documentation (e.g. under Architecture → Cryptography or as a new Security Requirements chapter) that defines explicit, testable security requirements for each relevant component.

At minimum, the section should cover:

1. Platform Attestation Provider (PAP) / MDVMP

• Required device integrity levels and signals (rooted/jailbroken, bootloader state, hardware-backed keystore availability, emulator detection, etc.).
• Minimum assurance level for attestation result used as input to WIA / registration flows.
• Requirements for freshness, binding and replay protection of attestation artefacts.
• Logging and auditability of attestation decisions.

2. Wallet Provider Backend (WB)

• Authentication and authorisation requirements for all WB APIs (including PoP/JWT expectations).
• Required protection level for Wallet Instance Attestation keys and related secrets.
• Logging of security-relevant events (registration, WIA issuance, revocation, failed integrity checks).
• Operational constraints (rate limits, lockout behaviour, incident response hooks).

3. Remote Wallet Secure Cryptographic Device (RWSCD / WSCA/WSCD)

• Required protection profile / assurance level (e.g. HSM-like behavior, AVA_VAN level or equivalent).
• Key isolation guarantees (keys never leave WSCD in plaintext; export only in wrapped form).
• Supported algorithms and key lengths, in line with EU crypto guidance.
• Requirements for multi-tenant separation, backup, restore, and business continuity.

4. Logging, auditing and replay protection (cross-cutting)

• Which events must be logged by which component (PAP, WB, RWSCD, WI).
• Time synchronisation and log integrity requirements (secure time source, tamper-evident logs).
• Explicit replay-protection requirements for all critical tokens (nonce usage, token binding, expiry rules).

5. Operational constraints

• Clear definition of trust boundaries between components and external providers.
• Requirements for monitoring, anomaly detection and incident handling (who is responsible for what).
• Dependencies on external platforms (e.g. Google/Apple app integrity services) and required fall-back behaviour.

6. Key lifecycle (creation, rotation, revocation)

For each key class (device keys, WIA keys, WSCD/WSCA keys, RP keys, etc.):

• Where the key is created (device, HSM, WSCD) and under which entropy requirements.
• How and when keys must be rotated (time-based, event-based, compromise-based).
• How keys are revoked, how revocation is propagated, and which components must enforce it.
• Requirements for secure destruction of deprecated key material.

Why this is a real gap

• The current architecture documentation describes what components exist and how they interact, but not which concrete security properties each component must fulfil.
• Without per-component security requirements, implementers and evaluators cannot derive a consistent threat model, assurance argument or test plan.
• This directly affects conformity assessment, certification readiness and cross-implementation interoperability.

Expected benefits

• Clear, testable security requirements for each component of the German National EUDI Wallet architecture.
• Better alignment with the concerns raised in “Comments on and recommendations for the German EUDI wallet architecture relating to cryptographic security”.
• Improved readiness for evaluation and certification (e.g. under CIR 2024/2981, Common Criteria, or equivalent schemes).
• Reduced ambiguity for Wallet Providers, PAP/MDVMP operators, QTSPs and auditors implementing or assessing the German wallet architecture.