Connector exchange: technical background to the appeal to Karl Lauterbach

0
41
connector exchange technical background to the appeal to karl lauterbach.jpg
connector exchange technical background to the appeal to karl lauterbach.jpg

After the appeal to the Federal Minister of Health, we provide technical background for a purely software-based alternative to hardware replacement.

 

Especially in medical practices, 130,000 special routers – so-called connectors – for the transmission of patient data within the telematics infrastructure (TI) are to be exchanged – and that for 400 million euros. The reason for this is expiring crypto certificates in the devices. Gematik, which is responsible for digitization in healthcare, has been working on alternatives for the connector exchange since at least 2019 – but none of these have been implemented. According to analyzes by c’t, an extension of the term of the crypto certificates to 2025 could avoid the expensive replacement of hardware. Karl Lauterbach suggested. This article provides technical background to the proposal.

 

The extension of the term of the crypto certificates avoids a hardware exchange and is both more practical and sustainable. The certificate extension initially gives you the necessary time until 2025 to then implement the new generation of key material according to future standards that has been planned since 2017. Once that’s done, the connectors can work until they break.

On June 30, 2021, Gematik published the specification “Feature: runtime extension gSMC-K 1.0.0”. The concept briefly outlined: Central “Trust Service Providers” in the TI generate new certificates for the existing, old crypto keys in the device-specific security module cards type K (gSMC-K) of the connectors – this is easily possible from the existing data. The connectors, in turn, regularly check the existence of new certificates for their old crypto keys within the TI VPN and download them from the TI. The new certificates are presented by the connectors instead of the old ones. This effectively extends the service life of the connector security modules.

If a connector’s certificates have expired, the connector can no longer check the existence of new certificates via TI-VPN. For 996 KoCoBoxes – as the connectors from CompuGroup Medical (CGM) are called – any help comes too late in September, followed by 3594 in October, 7112 in November and 3350 in December.

That’s not really a problem. Because it is already planned to be able to load new certificates manually into the connectors. According to reports, this was intended more for reserve connectors in clinics, but it is an important fallback if there are problems with the telematics infrastructure, as was the case for eight weeks in 2020, for example.

It is unclear to what extent a temporary failure of the connectors is currently actually impeding practice processes. Our request to the National Association of Statutory Health Insurance Physicians (KBV) has so far remained unanswered. Doctors whose connectors had failed reported to us that this did not affect practice operations. Because according to the security requirements, there must also be a replacement process without a TI for all TI-dependent processes.

The extension to 2025 finds its natural limits with various security considerations, because crypto keys also age. Because the resilience of the key lengths suffers from general technical progress such as increasing computing power or leap innovations.

Against this background, it is understandable why crypto keys and the associated certificates have to expire in order to guarantee a permanently high level of security. From 2026, for example, ENISA (European Union Agency for Cyber ​​Security) will require RSA keys with more than 3000 bits instead of just 2048 bits.

The Federal Office for Information Security (BSI) tolerates this extension at least until 2025. Whether it is early 2025 for individual keys or the end of 2025 for all is irrelevant, because there is plenty of time until the end of 2024 for the next step of the solution.

On June 30, 2021, not only the specification “Feature: runtime extension gSMC-K 1.0.0” came into force, but also version 5.13.0 of the connector specification and the associated test specification for product type version 5 (PTV 5). In addition to version 2.0 of the electronic patient record (ePA 2.0), which is to come with access control by the patient and the comfort signature, both documents also called for the implementation of the extension of the certificate’s term.

According to Gematik’s approval overview of August 11, 2022, RISE and Secunet completed their updates on time and each received their first PTV5 approvals at the end of 2021. In contrast, CGM is only represented in this overview with PTV4 versions.

 

With this delay in implementation, CGM is not only preventing the extension of the certificate’s term, but also the electronic patient file 2.0 urgently required by the Federal Commissioner for Data Protection and Freedom of Information (BfDI). A query from voonze online as to whether CGM is delivering the new connectors with PTV 5 has so far gone unanswered.

We reported that the connector SMCs have to master the generation of new key material according to the security regulations – both for RSA and for ECC (Elliptic Curve Cryptography) as well as for key lengths and properties required from 2026.

The first 996 KoCoBoxes were personalized in September 2017. In our opinion, specification collection 1.6.4-1 was the binding source for “online productive operation phase 1” (OPB1) at that time. The specification of the “gSMC-K object system V3.10.0” dated October 28, 2016 already contains numerous requirements in order to replace both keys for RSA and ECC after their expiry with new keys with the key lengths of 3072 bits for RSA and 384 bits for ECC.

As an example, we quote the passage for the VPN key of the network connector in section “5.5.7 MF /DF.NK/ EF.C.NK.VPN2.XXXX”:

“This certificate file is created to issue a certificate with the public key PuK.NK.VPN.XXXX to PrK.NK.VPN.XXXX (XXXX from the set {R2048, R3072, E256, E384}) after the expiration of the usage period of the key PrK .AK.AUT.R2048 The decision as to which procedure from the set {R2048, R3072, E256, E384} is to be selected when the key material is changed will be made at a later date.

Other such requirements can be found by searching for “R3072” and “E384”.

New keys are generated using the card command “GENERATE ASYMMETRIC KEY PAIR”, which is specified in the OPB1-relevant version of the specification of the Card Operating System (COS) 3.10.0 of April 21, 2017 in section “14.9.3 GENERATE ASYMMETRIC KEY PAIR ” is described from page 356.

The connectors would only have to send the corresponding command packages to their gSMC-K via software. Already in the OPB1 normative specification of the connector 4.11.1 from April 27, 2017 it says:

“gSMC-Ks according to [gemSpec_gSMC-K_ObjSys] have the option of subsequently generating key pairs and reloading the associated certificates. This mechanism will only be supported by the connector in upcoming releases. Initially, all identities are already present on the gSMC-K.”

The question arises why this did not happen and why the discussion about the connector exchange arose. In any case, the specifications mentioned already applied when the first KoCoBoxes were personalized in September 2017. All KoCoBoxes or their gSMC-K should therefore support the new key generation. Our previous investigations into gSMC-Ks have also confirmed the existence of these placeholder certificate files.

In our view, there are no obstacles to our proposal, which is based solely on Gematik’s binding specifications, according to which the devices have been tested and approved. The functions required for our proposal must therefore be available. CompuGroup Medical is the only connector manufacturer that has not yet implemented the specified runtime extension.

Therefore, in our appeal to the Federal Minister of Health, we proposed obliging CompuGroup Medical to update to PTV 5 by October 1st. Typically, one would expect contracts to include contractual penalties in the absence of such critical updates. In this case, the company would have to bear the costs for unnecessarily exchanged connectors itself until it was able to deliver PTV 5 and extend the term of the crypto certificates.


(mack)