deploy.py auto-commit

1 files changed, 0 insertions, 100 deletions

diff --git a/content/blog/epa-sgd-crypto/index.rst b/content/blog/epa-sgd-crypto/index.rst
deleted file mode 100644
index ccbf648..0000000
--- a/content/blog/epa-sgd-crypto/index.rst
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: "75 Million Lives, Two Keys"
-date: 2025-01-05T23:42:00+01:00
-draft: true
----
-
-2025 has begun. In this new year, with its new national healthcare record system, the country of Germany will start one
-of the largest rollouts of a cryptographic system in history. While the system has received scrutiny as well as
-resulting harsh criticism from a number of parties ranging from NGOs to everyday civilians, the system has received
-surprisingly little attention from the academic applied cryptography crowd. Additionally, previous criticism of
-the system has largely revolved around organizational issues. While valid, we belive that some cryptographic issues at
-the core of the system have escaped attention unitl now. In particular, at the core of the system is a key escrow system
-that contains several questionable design choices and that in its overall design seems out of place in 2025.
-
-The aim of the system is to serve as a shared storage for all healthcare records of a person. In the system, a person's
-entire patient file with all documentation on the treatment process including test results, images and other raw data
-will be stored in something vaguely resembling cloud storage such that all healthcare providers that the person visits
-can access the entire file. This centralized, synchronized storage eliminates the need for transferring this data
-between hospitals and doctors offices by fax, mail or physical media as it was common practice until now. After a
-development and testing phase lasting approximately five years, the German government decided to roll out the system to
-everybody insured under Germany's mandatory national health insurance scheme, totalling approximately 75 million people,
-on January 15th 2025.
-
-In this article, we will give an overview of the system's cryptographic design before highlighting a few odd
-design choices that could amount to a viable attack vector to the powerful adversaies 
-
-## Context and involved parties
-
-Germany has a national, mandatory health insurance system. The system is open to any permanent resident of the country
-irrespective of citizenship. The system is mandatory in that while residents can choose between a number of both
-publically owned as well as private healthcare providers, it is not possible to opt out of the system. The public health
-insurance providers cover approximately 90% of German residents. These providers are organized in an umbrella
-organization named "GKV Spitzenverband". The resposibility of this umbrella organization largely revolves around
-negotiating prices with pharmaceutical companies and with healthcare providers as a publically sanctioned cartel, but
-also includes the specification and operation of shared IT infrastructure for billing and data exchange between
-healthcare providers.
-
-While GKV Spitzenverband is the party that ultimately holds responsibility for the regulatory administration of national
-healthcare IT infrastructure, it has delegated large parts of both the technical specification of this infrastructure as
-well as its day-to-day operation to Gematik GmbH, a state-owned limited liability corporation created specifically for
-the purpose of developing and implementing national healthcare IT standards. The electronic healthcare record system we
-describe in this article was standardized and implemented by Gematik GmbH under the direction of GKV Spitzenverband.
-
-Healthcare providers in Germany need to be registered with GKV Spitzenverband to serve members of public health
-insurance providers. Since these public providers constitute approximately 90% market share, the vast majority of
-healthcare providers are registered this way.
-
-Before the new national health record system, a number of healthcare IT processes have already been standardized and
-implemented by the parties above. In particular, every insured person already owns a cryptographic smartcard that acts
-as their proof of identity when accessing healthcare services. On the other side of such transactions, healthcare
-providers are likewise identified by cryptographic smartcards. Until now, these cards were used to facilitate billing of
-services from healthcare providers to insurers and to transfer prescriptions from prescribing doctors to pharmacies.
-
-A central role in this existing infrastructure is assumed by VPN gateways that link healthcare providers to
-the centrally-run backend infrastructure. Gematik GmbH calls these devices "Konnektor". They are specially-built
-hardware devices that contain multiple smart cards to authenticate the VPN connection towards the backend, and besides
-acting as a standard VPN gateway for client applications in the healthcare provider's network to tunnnel their backend
-requests through, the Konnektors also perform cryptographic operations in some of Gematik GmbH's protocols, such as
-authenticating certain requests using signatures.
-
-## Design principles
-
-The new health record system was built on top of the existing infrastructure described above. In particular, access to
-health records is managed through keys stored in the patient's and the healthcare provider's existing smartcards, and
-all backend communication is tunneled through the existing VPN. Access to the files is mediated through the healthcare
-provider's existing patient management software. While in early drafts of the system, access to healthcare records
-through the patient's smartcard was gated behind a PIN, the impracticality of making the entire patient populace
-remember PINs led the implementors to scrap this provision, meaning that the patient's smartcard is all a healthcare
-provider needs to access the patient's record.
-
-A critical cornerstone in the system's design is that the system's designers decided that a lost smartcard should not
-lead to any data loss. As a consequence of this decision, while some of the record's access keys are kept on the
-patient smartcard, in contravention to conventional smartcard designs the same keys are kept accessible in a centralized
-key escrow system named "Schlüsselgenerierungsdienst" and abbreviated as SGD. Furthermore, these keys are not generated
-on the smartcard either -- instead, the key escrow system generates these access keys, one copy of which is then
-transmitted and stored inside the smartcard.
-
-The system supports re-issuing a smartcard to gain access to a healthcare record. Since the record's privacy pivots on
-this process, the system incorporates some organziational countermeasures that aim to make it hard to gain access to a
-re-issued copy of a patient smartcard without the patient's help or otherwise multiple colluding parties.
-
-## Cryptographic design
-
-
-
-## The implied adversary model
-
-While Gematik GmbH publishes detailed specifications of the systems they standardize, these specifications and some
-associated implementation guidelines are about the extent of public information. Software implementations are being kept
-secret, and while standardization results are available, a large fraction of design rationale is discussed behind closed
-doors. From an academic perspective, the most glaring omission in Gematik GmbH's public documents is any definition of a
-threat model or an adversary model. As a result of this, we will deduce an adversary model below by contextualizing the
-published standards in the national healthcare setting. We will base our further analysis of the system on this
-adversary model.
-
-
-
-## Previous reviews and audits of the system
-
-[0] https://www.destatis.de/DE/Themen/Arbeit/Arbeitsmarkt/Qualitaet-Arbeit/Dimension-2/krankenversicherungsschutz.html