PoPP security measures

[Sascha-Block]

Background & problem definition

• The PoPP database is intended to be used for the secure authentication of contactless eHCs (G2.1 & G3) in the telematics infrastructure.
• G2.1 cards require contact-based activation in order to generate a hash value from the X.509 certificate, which is transferred to the PoPP database.
• The G3 card can be used directly contactless. It does not have to be activated by inserting it beforehand.
• Two options for filling the database:
  a) Lazy initialization: Filling when an eGK is inserted with contact.
  b) Delivery of the hash values by the payer/service provider.

Risk: The current use of CVC for the PoPP database presents a structural weakness (known from 38C3), as compromised CVC certificates cannot be revoked or identified as invalid.

Related gemSpecs:
Übergreifende Spezifikation
Spezifikation PKI
Technisches Konzept Proof of Patient Presence (PoPP)
Prerelease Draft_Smartcards_24_3

Significance of CVC in the context of the eGK & PoPP database

1. definition of CVC (Card Validation Certificates)
CVC stands for Card Validation Certificates that is used on contactless chip cards. It is used to verify the authenticity of the card without the need for online communication with a central certification authority. In the electronic health card (eGK), the CVC is used to enable authentication of the card in offline mode.

2. CVC in the context of the PoPP database
The PoPP database (Proof of Patience Presence) stores hash values to ensure that contactless use of the eGK is only possible for verified cards.
Previously, the CVC was used as the basis for identity verification.
The problem: CVC certificates cannot be blocked if they are compromised.
The comparison of CVC with X.509 does not represent an additional security layer, but merely serves to link the identity of the card and the insured person.

3. security risks due to CVC
Long validity period: CVC certificates remain unchanged for five years, which makes attacks easier.
No revocation possible: Unlike X.509 certificates, compromised CVC certificates cannot be revoked.
Abuse by attackers: If an attacker gains access to a private CVC certificate, it can be used for multiple cards.
Regular renewal of CVC would only be economically feasible through remote card administration.

4. Importance for the security strategy
The PoPP database must not rely exclusively on CVC, as this represents a single point of failure.
The certificate comparison with X.509 is intended to ensure that even compromised CVC cards can be recognized and excluded.
With PoPP, the photograph on the eHC is effectively abolished, which increases the risk of card misuse. Has this been agreed with gematik's shareholders?
Future improvements:
Regular renewal of CVC certificates to reduce the attack surface.
Strict access controls to minimize the risk of key compromise.
Conclusion: CVC certificates remain a proven technology, but there is no revocation option to exclude compromised CVC certificates. The combination with X.509 certificates is an important step, but additional measures for key management and revocation options are necessary. It is also questionable to what extent further efforts are proportionate in relation to outdated technologies and long-lived gematik specifications. There is a contradiction here with ever shorter certificate intervals, especially when accessing long-lived health data.

Planned measures
Removal of “lazy initialization” from the PoPP service specification to reduce the attack surface.
Introduction of a second security layer through certificate matching (X.509 vs. CVC).
The PoPP database does not recognize compromised CVCs as there is no revocation mechanism.
Check how existing cards can be included in the system without forcing a card exchange.
Cards without stored hash values do not work with the PoPP service, so a quick solution for existing cards is needed.

Security assessment & residual risks
Problem: CVC certificates cannot be revoked, so a vulnerability remains for keys that have already been compromised.
G3 cards are not affected as their identity is verified via the KVNR.
An attack could occur if an attacker gains access to a private key, as this can be used for several cards.
Changing CVC certificates could reduce the risk, but the cards remain valid for five years.
Practical significance: If PoPP does not work without stored database entries, a mass replacement action would have to be carried out for affected cards, which would be very cost-intensive

Why is CVC not insecure, but problematic?

• CVC is a proven authentication method that does not require online verification.
• Main problem: If a CVC is compromised, it cannot be revoked because there is no revocation mechanism.
• What does this mean? An attacker with a compromised CVC can access systems indefinitely as long as the certificate is valid.

Why does X.509 matching not provide a second layer of security?

• In the PoPP database, the corresponding X.509 is supplied for a CVC that has been authenticated.
• However, the system does not check whether the X.509 certificate itself has been compromised.
• This means that a compromised CVC can still identify itself with its correct X.509 certificate.

Why could PoPP increase card misuse?

• Currently, the photo on the eGK is used to enable insured persons 16 years and older to be checked when using the card.
• PoPP tacitly removes this mechanism from the system.
• This means that it would be easier for third parties to fraudulently access services using other people's cards.

Recommended additional protective measures

1. More frequent rotation of CVC certificates: Prevents long-term misuse of stolen certificates.
2. Strict authentication of database filling: Use only via secure interfaces with cryptographic verification.
3. Checking connector updates for G3: Ensure that the newer cards also work seamlessly with PoPP.
4. Field analysis of existing cards: Investigate which hash values for G2.1 cards can be added retrospectively.

My thanks for validating this information go in particular to Martin Tschirisch and although Bianca Kastl and all , who pointed out these not fundamentally new risks at 38C3, to all colleagues in the german GKV environment and all gematik stakeholders and all dedicated IT security specialists. This issue serves the goal of realizing and personally improving a trustworthy telematics infrastructure.

Mein Dank zur Validierung dieser Informationen geht insbesondere an Martin Tschirisch und gleichfalls an Bianca Kastl, die auf dem 38C3 auf diese gar nicht grundlegend neuen Risiken hingewiesen haben. Gleichfalls an alle Kolleginnen im GKV Umfeld und alle Stakeholder der gematik und alle engagierten ITSec-Spezialistinnen. Dieser Issue dient dem Ziel eine vertrauensvolle Telematik Infrastruktur zu verwirklichen und perspektisch zu verbessern.

[volkerdoerr]

I second that!

[Sascha-Block]

I have deleted the content of the issue to highlight an important issue on top, that we need to fix overarching:

The problem that exists with transparent, web-based commenting as well as in consulation processes as they are currently set up:

GitHub issues are not versioned in a revision-proof manner in the true sense of Git. This is because GitHub does not store previous versions of a comment or issue description in a publicly visible history.

I think it's a worthwhile goal to change this together.

[Sascha-Block]

Consideration: EUDI Wallet as a future-proof alternative

The concerns regarding the authentication process in PoPP are justified, particularly in view of the fact that service providers (LEIs) cannot check who is actually checking in with a digital identity. The envisaged PoPP solution is also not based on any standards such as Open ID Connect (OIDC), but should rather be seen as a proprietary stand-alone solution in the SHI environment.

The European use case is already clearly defined from a regulatory perspective through harmonization in the European environment such as the European Health Insurance (eHIC) and the eIDAS Regulation, which is to be implemented by law and will also apply to the healthcare sector in the foreseeable future.

If we accept a trusted EUDI wallet as the realized infrastructure, what would be required beyond verified identity attributes?

Instead of requiring LEIs to carry out biometric verification themselves, it would make sense for the necessary trust to be established by trust anchors such as these:

• Secure elements in end devices (e.g. via EUDI Wallet)
• HSMs in backend systems
• Biometric verification in the sectoral IDP of health insurers

The convenience signature based on biometric factors - which can be provided as a convenience procedure via the frontends - is already an integral part of the telematics infrastructure and the gematik specifications.

The risks - with potential attack vectors - always arise from a possible data outflow, which is why the express consent of the user must be provided in return for these convenience features service scenarios of the TI. In contrast, users always have the choice to opt for alternative and permanent offers of alternative login procedures with high security levels for a small additional cost.

It would therefore be desirable if the biometric procedures were also standardized in a trustworthy manner and also enabled pseudonymous logins, whereby state eID procedures would merely confirm the biometric attributes without data exchange.

PoPP vs. EUDI Wallet: The Challenge of a Trustworthy Architecture

Doesn't the federated IDP approach of the TI essentially replicate the same concept as the EUDI Wallet—only in an outdated, inconsistently standardized, and therefore incomplete form?

Instead of continuing with a fragmented approach based on CVC and X.509, a unified, federated digital identity infrastructure would provide:

• Trustworthy identity verification through a nationwide, standardized infrastructure

• Federated identity systems (the sectoral IDPs in the TI federation) within a zero-trust infrastructure based on the principles of confidential cloud computing

• Privacy-preserving attribute disclosure or minimal disclosure to ensure secure and verified identity attributes

• Self-Sovereign Identity (SSI) or Zero-Knowledge Proofs (ZKP) for maximum privacy and trustworthy selective disclosure—a key principle also in the context of eIDAS 2.0 and EUDI Wallets

• A reliable mechanism enabling service providers (LEI) to verify identities within their own context without exposing personal data—through minimal but trustworthy attribute verification. This ensures a secure and privacy-friendly identity confirmation process for LEIs, verifying only the necessary attributes without disclosing excessive information.

• Data integrity (immutability and authenticity of identity attributes) and real-time identity verification (preventing outdated or revoked identity credentials). This guarantees reliable and tamper-proof identity confirmation for LEIs at any time.
  Ensuring that LEIs can only access trustworthy and non-revoked identity credentials, preserving the integrity and security of digital identities.

If the EUDI Wallet is already set to become an established standard, why should massive investments be made in parallel structures that maintain outdated concepts?

The focus should be on a modern, interoperable, and secure identity infrastructure in combination with federated zero trust.

[Sascha-Block]

I believe that the way we handle participation and contradiction-free validation of requirements simply needs to improve.

Transparency, supported by modern technical tools and transparent audits, is a worthwhile goal for our digitalization.

We all make mistakes, myself included.

#Together

[volkerdoerr]

💪💪💪