jaseg/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

WIP

Browse source
This commit is contained in:
jaseg 2025-06-30 14:48:34 +02:00
parent bce789de7b
commit a324ba7b64
11 changed files with 63 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

36
content/blog/epa-sgd-crypto/index.rst
View file

@ -45,10 +45,44 @@ Healthcare providers in Germany need to be registered with GKV Spitzenverband to
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
@ -59,6 +93,8 @@ threat model or an adversary model. As a result of this, we will deduce an adver
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

21
content/blog/jupyterlab_notebook_file_oneliner/index.rst Normal file
View file

@ -0,0 +1,21 @@
---
title: "Getting the .ipynb Notebook File Location From a Running Jupyter Lab Notebook"
date: 2025-06-30T23:42:00+01:00
summary: >
If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It
seems chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to
me.
---
If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It seems
chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to me.
.. code:: python
import sys
Path(json.loads(Path(sys.argv[-1]).read_bytes())['jupyter_session'])
The way this works is that for each notebook, jupyter starts a python "kernel" process that actually runs the notebook's
code. That kernel gets a json file with info on the notebook's location on the disk passed through its command line.
Since we're running code in that exact python process, we can just grab that json file from sys.argv, and read it
ourselves.