Slashdot Mirror
German Health Insurance Card CA Loses Secret Key
Christiane writes "The SSL Root CA responsible for issuing the German digital health insurance card lost its secret private key during a test enrollment. After their Hardware Security Module (HSM) dutifully deleted its crypto keys during a power outage, it was all 'Oops, why is there no backup?' All issued cards must be replaced: 'Gematik spokesman Daniel Poeschkens poured scorn on the statement that Gematik had insisted on the service provider carrying out a test without backing up the root CA private keys. "We did not decide against a back-up service. The fact of the matter is that the service provider took over the running of the test system, so it also has to warrant its continuous operation. How it fulfills this obligation is its own responsibility."'"
I'd rather the key be lost, than stolen, hacked, made-public, etc. At least it didn't breach security in the typical manner.
The summary even states that Gematik insisted on a back-up less operation, and then provides a quote explicitly stating that they did no such thing! Slashdot: doing for editorial accuracy what Fox does for editorial neutrality.
No kidding!!! What do you say at this point?
That's just silly. They obviously take security seriously enough that they found re-issuing all of their certs preferable to adding a second storage place for the private key, thus doubling the possibility of the system being compromised.
If the key had been compromised, that would be a breach of trust. This is more an example of the fact that as security increases, usability decreases.
I'm confused, isn't this sort of problem exactly why you carry out system tests?
Sending out new cards to card testers during a systems test is hardly extraordinary.
There must be exactly one party in effective possession of the private key of the root cert. If the number of parties becomes less than or more than one, fail.
No. The number of parties must be effectively ZERO. This is why the key is stored inside an HSM. Signing is performed by the HSM at the request of no fewer than 2 parties (each party monitors the other for suspicious or inappropriate behavior).
Key backups (in case of HSM failure) are encrypted (strength >= key) and can only be decrypted inside another HSM at the request of the >=2 parties who created the backup.
Breaking the HSM and having no backups of the root key ... fail.
The best part is it will all be contained in a single, monstrously large word. Ah, german efficience.
I never spellcheck and I freely admit it. Save your karma for more worthwhile "lol erorrs" replies
Well, we DO know that they are awfully good at writing numbers down. Sometimes even up the arm.
"I guess the moral of the story is, don't paint your airship with rocket fuel." -- Addison Bain
PGP Desktop has this option. You can share a key and split it among people, where x amount of y pieces are needed to recover the original key, where both x and y are user selectable values.
However, if a key is a top root CA key, you would not be using it on a general purpose computer. You would have the key generated in a HSM and stored there, where someone can perhaps use the key to sign and decrypt stuff, but would have to go to a lot of trouble to get past all the hardware tamper evident stuff in the HSM to access the raw private key material.
Most newer HSM devices I've seen have a way to back up keys generated on the device (usually to USB flash drives), provided at key generation time you set a flag allowing the key to leave the device. If this "allow private key material to leave the HSM" flag isn't explicitly set, you are screwed when it comes to backups, and your best workaround is to create another key with the flag set, then do some cross signing. Depending on task, you might be able to get away with revoking the old key, but sometimes (especially if the old key signed a lot of code certificates), this may be almost impossible.
This lost key should be a lesson to people. Making sure the keys that are in the armored box are backed up can be just as important to security as keeping them in the armored box in the first place. Ideally, consider multiple HSM hardware at multiple locations, including an offline HSM stored in padded packaging that goes in the Iron Mountain tub, as well as the means to access the key inside the box.
Even so, this line struck me as all too familiar: "The fact of the matter is that the service provider took over the running of the test system, so it also has to warrant its continuous operation. How it fulfills this obligation is its own responsibility."
This is why managers (especially the MBA types) love outsourcing of everything. It is also in part because numbers and KPIs are so much more easy to manage than actual people. But mainly, by outsourcing a function you also get to outsource the responsibility for that particular function. If things go tits up, the worst you'll be blamed for is picking the wrong service provider, or perhaps not monitoring a particular KPI properly. Minor stuff.
I've seen plenty of managers like that, and I have heard a variation of that one line all too often.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Actually, I can think of a reason, after all. Since this CA no longer has the ability to revoke prior signatures made with that key, then that key can no longer be trusted as a signer. You can check to see if a CA has certified something, but there's no way to check to see if the CA changed their mind, because the CA no longer has a way to say that.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Its usually backed up on a post-it note somewhere.
For a root CA private key, better be a big post-it note
(or written in really small letters)
I work for the Department of Redundancy Department.