Key Heist Questions (UPDATED)

I’ve been reading about the purported GCHQ theft of SIM card keys. The more I read, the more I’m confused as to what was stolen and why.

UPDATE: Here is a better document describing what was stolen. It appears to be large volumes of the K_i, not any master key or other keys.

Here is how I understand the protocol —  each SIM card has a secret key, K_i. This secret key is properly understood as a Master Key, that is, it is used in a key derivation algorithm to generate an encryption key. It is also used as the input to a challenge-response authentication. This is done via a (typically) propriety set of keyed MAC and encryption algorithms, although some vendors use public protocols. K_i is unique to the card, and the carrier has it. Compromise of the key + interception of cell phone traffic would allow an eavesdropper to listen in on calls. Compromise of the key alone would allow an eavesdropper to make calls (impersonating the legitimate holder of the key). Interception requires being close to the party, but if you are close, you can already use other techniques to listen in on calls. For example, the base station doesn’t authenticate itself to the phone at all, so with a strong enough signal + proximity, you can force the phone to use your base-station, impersonating the base station of the carrier. That’s nice, but the phone will still want to send you encrypted data. Fortunately there is an option to default to an older protocol and to turn off encryption, at which point the phone sends everything to you in the clear and you can listen in on traffic.  But you would be listening in on all traffic, so perhaps this was an attempt to limit the scope of surveillance? Alternately, some phones (IIRC) warn users when the signal is not encrypted, or may refuse to work without encryption (is this true?) so perhaps there were fears that this would tip off the subjects under surveillance.

OK, let’s say that there is a reason why knowing K_i is important. First, the GCHQ could have demanded that a particular K_i be turned over using existing procedures, since this is a symmetric protocol and the carrier has the corresponding K_i. You don’t need to attack the card manufacturer.

However I’m still not sure what was stolen.

  1. If the K_i’s are generated randomly (whatever that means) and then sent to the carrier. Then GCHQ would need to *keep* stealing these keys, because if it stopped, a few more million SIM cards would be generated the next day with different K_i’s.   It seems really inefficient, when the contact-the-carrier approach is right there. On the other hand, if they were after a particular target which already had a phone, then they would need to get K_i’s generated in the past.
  2. Were the K_i’s generated randomly and then escrowed by Gemalto, and this key store, or a wrapping key that protects the escrow, was stolen. That would be poor key management on Gemalto’s part. Once the card and the K_i are sent to the vendor, Gemalto should delete all local copies of the key.
  3. What if the K_i’s are derived from a master key, K, and a SIM identifier, and K, is what was stolen. That would mean that all SIM cards in the present and future are now compromised. It would also be a really stupid way to generate keys (although key management is simplified). Stunts like this have been pulled in the past.
  4. Were keys used to protect the shipment of K_is to the carrier stolen? I.e. so that sniffing the traffic would allow GCHQ to get the K_i.

So you unless there is transparency, it all boils down to how well you trust Gemalto key management. Previously I had some dealings with Gemplus before they became Gemalto. I was trying to assess their smart cards, and I wanted to know how they generate the entropy for their pre-installed certificates. It was very difficult getting anyone who could answer this question. Finally I received a statement that this was a FIPS certified PRNG so I need not worry. I tried to tell them that I was concerned about what they put into the PRNG — do they have a TRNG source? Do they have any environment controls? Do they do factory seeding? What happens to xSEED when the card is zeroized? I didn’t get any answers here. That was a long time ago, so perhaps their policy vis-a-vis transparency has improved.

So how, in the light of these revelations, can you protect yourself? As a SIM user, there isn’t anything you can do other than notify your carrier and demand good key management practices from all the vendors they deal with. You might also ask them why they would allow the card manufacturer to even see the key.

But as a customer of Gemalto, you don’t need the vendor to generate keys for you and send them to you. You can have an enrollment/initialization process that occurs on your premises and under your control in which the K_i are generated. I.e. I am very suspicious of any key material generated and escrowed upstream in the supply chain. Keys should be generated as close to the end user that they are trying to protect as possible. A website, for example, would not let their server vendor generate the site’s private SSL key. The private SSL key belongs to the site, not the manufacturer of the equipment the site runs on. The K_i belongs to the Carrier/phone user not to whoever manufactures the SIM card.

My advice to Gemalto is to be honest. People are going to assume the worst, but you are the victim here. Unless you start spinning this while failing to acknowledge that the public has a legitimate need for re-assurance about your processes and this re-assurance has to consist of something meaningful, hopefully a third party review. Do not squander public sympathy with PR mind-tricks. And maybe we can move away from reliance on symmetric pre-shared keys?

Key Heist Questions (UPDATED)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s