German Health Insurance Card CA Loses Secret Key 174
Posted
by
timothy
from the your-replacement-papers-please dept.
from the your-replacement-papers-please dept.
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."'"
Could be worse (Score:5, Insightful)
Re:Wrong Title, Wrong summary (Score:3, Insightful)
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.
Re:Public Key Infrastructure (Score:2, Insightful)
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 (Score:5, Insightful)
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.
Re:You can fall off the road on either side (Score:1, Insightful)
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.
Re:Rootkeylosin! (Score:3, Insightful)
Re:Wrong Title, Wrong summary (Score:3, Insightful)
Well, we DO know that they are awfully good at writing numbers down. Sometimes even up the arm.
Re:Public Key Infrastructure (Score:3, Insightful)
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.
Re:Wrong Title, Wrong summary (Score:5, Insightful)
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.
Re:Public Key Infrastructure (Score:3, Insightful)
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.
Re:Could be worse (Score:1, Insightful)
You don't understand what this "key" is for, do you?
Re:Oh c'mon, be fair! (Score:3, Insightful)
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)