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."'"
Wrong Title, Wrong summary (Score:4, Informative)
Once again, misleading title to a different summary.
For fuck's sake, the Germans didn't lose the key.
The SSL Root CA lost that.
Get the facts right.
For a second i was wondering how Germans could that stupid. That is unlike the Germany i know. And exactly as i suspected, the German insurer had been insisting the root CA for backup while the CA thought it was unnecessary.
Is it the German company's fault?
Re:An HSM That Requires Continuous Power? (Score:4, Informative)
Don't blame the cards for the stupidity of their administrators.
Re:Wrong Title, Wrong summary (Score:5, Informative)
Any stereotype missing?
yes.
we British are all of the above.
Re:Wrong Title, Wrong summary (Score:3, Informative)
Gematik commissioned D-Trust to provide the root CA as a service. D-Trust managing director Matthias Merx stated "Gematik decided to 'do without a back-up'. As a service provider, we have to accept that."
From the article and summary:
"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 ..."
Indeed. Two sides claiming different things. Must be Slashdot's fault.
Re:Wrong Title, Wrong summary (Score:1, Informative)
No, we're also loud, obnoxious, and generally socially clueless.
Best practices (Score:2, Informative)
Best practices about CA management says you should have your secret key in a (physical) safe. Better yet, divide it in two pieces and put it along the passphrase in three different safes (part1+pass,part2+pass,part1+part2), so you can't lose key access even if you lose one safe, and nobody can take the key by opening a single safe.
Re:What is "CA"? (Score:5, Informative)
I will simplify, but basically a CA (Certificate Authority, that much of the parent wasnt a joke) is a server that creates encryption certificates. In this case, SSL certificates. For example, when you goto https://mail.google.com/ [google.com] that SSL certificate was created by the Thawte SGC CA. Thawte is one of many companies that you can pay to create you an SSL cert, so your users can communicate with your server via https.
The CA itself also has an encryption key, which is stored on hardware. In some cases its a PCIe board, others its a removable PCMCIA card, etc. This particular CA used an add-on board which lost power during operation, wiping out its only key. The board seems to have been working as intended, preventing attack (removal of board, which would cause power loss) by wiping itself.
Without that key, the CA can no longer create revocation lists (CRLs, lists of certs a CA has created that have since been revoked or expired) or any new certs. They are dead in the water, also causing every cert they have ever made to become invalid as they can no longer be checked against a recent CRL. They have to start from scratch, recreating every_single_cert.
This was only a test system, but if this happened in reality 80 million Germans would have invalid health cards. At least they discovered the value of a backup during testing.
Re:Wrong Title, Wrong summary (Score:3, Informative)
The title/summary are not necessarilly incorrect, just ambiguous. English can do that, and if you aren't paying attention your meaning can be taken in a way other than you intended.
In this case, there are a few ways to read "German Health Insurance Card CA":
1.) The Health Insurance Card CA of German origin
2.) The CA for the German Health Insurance Card
3.) The Card CA for German Health Insurance
4.) The Insurance Card CA for German Health
Obviously they aren't saying 3 or 4, those work gramatically but don't make a lot of sense in the context of health insurance and certificate authorities. 1 and 2 though, work pretty well either way. They should have used the unambiguous form, obviously with a small amount of research we can see that 2 is the correct meaning, but a number of people will read the sentance to mean 1 instead, as you did.
It's poor writing, not an attack or attempt to slight Germans. Remember the old saying: Never ascribe to malice what can be explained by incompetance.
Lastly, while it was the CA's responsibility to ensure they have backups and the like, it is the client company's responsibility to ensure they can maintain their business. If the health insurance company never asked for or verified a disaster recovery plan, it's their ass that is in hot water if they cannot provide service.
Make no mistake, they WILL lose business over this, even if the failure isn't directly their fault.
Re:You can fall off the road on either side (Score:3, Informative)
As an optimist, I'd say that least they didn't fail in the worst possible way.
The pessimist in me thinks I should get a bit more than "not failing in the worst possible way" when I pay somebody a barrel of cash to hash a couple numbers for me.
No, that's also the optimist in you.
Cheers. :)
Re:Wrong Title, Wrong summary (Score:1, Informative)
Did anybody notice the parent is modded as Informative, not Funny?
I take it at least 50% of the current mods are French?
Re:Wrong Title, Wrong summary (Score:1, Informative)
My advice in the past (Score:3, Informative)
First, all security experts will tell you that you should not keep copies of that stuff around.
Second, that's not a realistic expectation, stuff happens. The IT guy goes on vacation, has an accident, or dies. (Seen all 3 numerous times.) You fire the Admin for some reason. This building burns down. Etc.
A reasonable thing to do, is keep a password/key log with that critical information that is kept up to date at all times. You have two copies of it. Both are kept secure in good quality safes (not a $200 lockbox).
Both safes are in different physical locations, at least separate buildings, preferably miles apart.
The reason for this is pretty easy. Once again, things happen. I've seen buildings burnt down, flooded, inaccessible due to chemical hazards from a truck wreck, etc. You don't know what will happen, but if you have them stored at separate physical locations, you at least know you will be able to get to one of them if you need to, assuming nobody uses a nuke.
It all falls under that old techie saying, "So, when did your data become important to you? Before or after you lost it...".
Re:I'm confused (Score:4, Informative)
Matthias Merx, the firm's managing director, told heise online that following a voltage drop, something happened in D-Trust's "Trustcenter" that does occasionally occur. "The HSM independently deleted the data because it suspected an attack."
Translation? "Someone unplugged the backup power supply before setting the proper mode in the card because we didn't fully understand how sensitive the card is for root CA certs"
Merx explained that "Gematik decided to 'do without a back-up'. As a service provider, we have to accept that,"
Translation? "We asked Gematik that it might be a good idea to back it up and they said its fine its just for testing." or "We recommended to Gematik to back up the card before shipping it to us. They shipped it to us and we just shrugged our shoulders." Bonus points if you guessed they asked a low level manager at Gematik who thinks CA is the first two letters of a cat.
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 fulfils this obligation is its own responsibility."
Traslation? "Gematik is taking NO RESPONSABLITY WHATSOEVER for doing any safty checks before giving our root ca to an outside vendor."
All in all its not a big deal though. It looks like they just lost the issuing CA and not the revoke keys. It looks like they can still authenticate too. Now if this was the MAIN system germany with 80+ million plus medical cards? I think people are going to be shot:P
Re:What is "CA"? (Score:2, Informative)
A few points first:
- A CA doesn't only create encryption certificate. It can create a variety of certificates, including Windows Logon, Signing certificates, etc. It all depends on the Certificate Policies that are configured on the CA.
- We have no information the CA was indeed issuing SSL certificates. More likely, they were encryption certificates used to decrypt the patient's medical files. According to this link [aloaha.com] the card also contains a signing certificate.
- There are a lot of different types of HSMs. Some will encrypt their data (Security World, for nCipher) on a remote filesystem (RFS, especially in the case of netHSMs) that can be on any machine. As long as you have the Administrator Card Set (or a quorum of those, m of n cards required to perform specific tasks), you can reload the Security World, reload the keys, and are good to go. Other HSMs provide in-hardware "protection" of the keys, such as SafeNet HSMs, and the data in these can be backed up through hardware tokens (which are just very secure PCMCIA cards). HSMs usually have built-in hardware protections so you can't break it open or something, without destruction of the data.
- It is stupid for both the service provider and the customer to have gone without backups of the Root CA. What is the point of replicating your production environment in a reference/test environment, if you're not going to do a full replication?
- As each company looks like an idiot, they will try to blame each other, and they already do. Quite typical. The Service Provider is saying "we did what the customer wanted", and the customer says "The service provider was taking care of the tests". They are both stupid and wrong.
- Smartcards are protected by master keys. When the smartcard manufacturer creates the cards, he initialises them, usually with a "Manufacturer Key". This key is known by anyone who ever worked in the industry. In a normal setup, when the customer (the company issuing the cards to their users) gets the cards, during the card personalisation, they swap the Master Keys using their own keys. This is probably the most important part. Without those Master Keys, nobody can access the card's applets, or perform administrative actions on the card. Not even the owner with the PIN. It is very likely that for a solution of this size, the card manufacturer (according to this link [cardtechnology.com], GnD and Gemalto are part of the project. GnD will supply their 80k card) were using the customer's Master Keys initially, so that the key swapping wasn't needed (or simply, the cards wouldn't be usable anywhere else).
If in the same accident, the Master Keys for the smartcards were lost, then they can effectively throw away all the cards that were created in that batch, as nobody will be able to access the applets on the cards, thus, nobody will be able to update the certificates, or even erase the cards. This doesn't mean the certificates are dead, the certificates can still be used on a daily basis without any issue, but considering the CA will not be able to publish its CRL (which needs to be published every x hours/days, and has an expiry threshold), the certificate chain would become untrusted after some time (probably a few years, considering the Root CA should NOT be connected, but rather locked in a safe, and never need to publish its CRL for the length of the certificate's lifetime), and only then will problems start to arise.
I do hope for the sake of the companies involved in this project that they didn't ask the manufacturers to produce the test batches with the customer's Master Keys and that the Master Key was lost,