Schneier on Security
A blog covering security and security technology.
« Friday Squid Blogging: LOLSquid |
| Cheating on Tests, by the Teachers »
June 21, 2010
AT&T's iPad Security Breach
I didn't write about the recent security breach that disclosed tens of thousands of e-mail addresses and ICC-IDs of iPad users because, well, there was nothing terribly interesting about it. It was yet another web security breach.
Right after the incident, though, I was being interviewed by a reporter that wanted to know what the ramifications of the breach were. He specifically wanted to know if anything could be done with those ICC-IDs, and if the disclosure of that information was worse than people thought. He didn't like the answer I gave him, which is that no one knows yet: that it's too early to know the full effects of that information disclosure, and that both the good guys and the bad guys would be figuring it out in the coming weeks. And, that it's likely that there were further security implications of the breach.
Seems like there were:
The problem is that ICC-IDs—unique serial numbers that identify each SIM card—can often be converted into IMSIs. While the ICC-ID is nonsecret—it's often found printed on the boxes of cellphone/SIM bundles—the IMSI is somewhat secret. In theory, knowing an ICC-ID shouldn't be enough to determine an IMSI. The phone companies do need to know which IMSI corresponds to which ICC-ID, but this should be done by looking up the values in a big database.
In practice, however, many phone companies simply calculate the IMSI from the ICC-ID. This calculation is often very simple indeed, being little more complex than "combine this hard-coded value with the last nine digits of the ICC-ID." So while the leakage of AT&T's customers' ICC-IDs should be harmless, in practice, it could reveal a secret ID.
What can be done with that secret ID? Quite a lot, it turns out. The IMSI is sent by the phone to the network when first signing on to the network; it's used by the network to figure out which call should be routed where. With someone else's IMSI, an attacker can determine the person's name and phone number, and even track his or her position. It also opens the door to active attacks—creating fake cell towers that a victim's phone will connect to, enabling every call and text message to be eavesdropped.
More to come, I'm sure.
And that's really the point: we all want to know -- right away -- the effects of a security vulnerability, but often we don't and can't. It takes time before the full effects are known, sometimes a lot of time.
And in related news, the image redaction that went along with some of the breach reporting wasn't very good.
Posted on June 21, 2010 at 5:27 AM
• 31 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
It also enables economical fraud, since phone calls may be billed someone else... just by re-programming the sim-card to someone else's IMSI.
1) Knowing the IMSI doesnt give you much since the subscriber is authenticated with the Ki which is kept in the SIM's protected memory. Impersonating another subscriber needs both his ID (the IMSI) and his authentication key (the Ki). Having only the iMSI is pretty useless.
2) most of the networks make no use of the IMSI but rather use a TMSI which is a temporary ID assigned by the network once the subscriber is authenticated. The IMSI is used only at the 1st time the subscriber wants to use the network. From that point the TMSI is used.
3) The threat of active attacks is not necessarily related to the IMSI being known, and can be done without it.
I would LOL at the information release and follow on debates about it "not really being that bad" but it seems a bit premature and in bad taste.
My understanding of the IMSI number is that it isnt *that* secret but as Salach says the TMSI is normally used. Knowing the IMSI is still very useful for tracking and spoofing.
ISTR that a combination of knowing both IMSI and cellular provider is the key but its getting hazy now.
Salach is right – having the IMSI is like knowing a username, but not the password. With some GSM networks, that is enough though, because of an implementation detail: if the real user is signed in, and an attacker tries to sign in (and fails, because he doesn't have the Ki), *both* get kicked off the network in reaction to the failed attempt. DoS.
"Most of the networks make no use of the IMSI" - really? That is not my experience, but then again, I reside in Europe.
The AUC is not crack proof...
My interest was caught by how quick the FBI was to being an investigation.
It suggested either a desire to crack down on a known villian, a serious underlying problem, or the people disclosed about were VIPs who had both the ability to generate political heat on the DoJ AND the ability to be first adopters in spite of their organizational security policies.
I suspect the last.
i guess i could look it up, but what's the difference between an imsi and an imei?
i always considered the imei to be the unique serial number of a device; has this changed?
Wow. What a mess.
It actually makes the internet look much nicer in comparison. We already know that eavesdropping and MITM'ing are possible and rather frequent on the public internet, and that the proper way to protect oneself is to use end-to-end security of some sort.
Relying on the network to be smart is clearly a losing strategy.
IMSI is the subscriber's identity in the network for the 1st sign-in, stored in the SIM. IMEI is the handset identity and is used to track stolen hansets by those network operators that actually bothered to implement it.
IMSI is used rarely and usually only once. After that your network-assigned TMSI is used and is stored in a file on your SIM. The current generation of authentication algorithms are not that easy to crack. This was true for the old COMP128 V1 which is hardly used today. It may still be possible to make the network use it, but you still need PHYSICAL access to the SIM for a few hours to extract the Ki. Some SIM's also have a mechanism to detect such brute-force attempts and commit suicide.
Using it for DOS may work but will depend on network policies. One policy that is always valid for them is "Thou shall always make money" so i am not sure they will kick both of them from the network. Maybe they will flag them for better scrutiny, something like a "grey" list.
Overall it is not such a big deal if you know IMSI's.
@ BF Skinner,
"I suspect the last"
Yup it would be a reasonable bet and I might put a dollar down on it being the right guess.
The problem with security in phone networks is the infrastructure costs, and that the systems where designed over 20 years ago with not much in the way of an upgrade in that area.
It's got to the point where you have to assume that even LEA's don't need 'wire taps' at the exchange any more not just the bad guys.
The question becomes "how long" before something realy embarrassing happens to wake people up to the reality...
Oh and a second question is going to be how long before the iPad's need a serious security upgrade...
Let me see they've been out for a couple of months or so, so we should have about 8 by now ;)
The particularly interesting part to me the the bad redaction story, and this little fun snippet from the end:
"ValleyWag was sent a pre-release version of this post for review, and the server logs confirm that they have read it.
To date they have not changed the article imagery."
Clever, and damning.
@ BF Skinner
Your third explanation seems very probable. Like most head honchos, the politicos don't usually care until the problem falls in their laps. Then, "action this day!"
It reminds me of how router manufacturers would often use public serial numbers as the default secret key. It would be fairly easy to load unique random values for the passwords and keys at the factory, but they did a little cost cutting that let many routers be subverted out of the box.
Issues like this and the ICC-ID make a good case for strict liability laws to be applied to commercial software development. It seems that most of these disasters can be prevented by even the most minimal and basic security reviews. If the strict liability laws only enforced this minimum, our situation would greatly improve without the lawyer gold rush that would follow a total strict liability law.
"Overall it is not such a big deal if you know IMSI's."
What's your IMSI?
Surely if you have nothing to hide...
(apologies for the cheap shot)
@ Nick P, BF Skinner,
On a slightly different note one of the designers of AES Vincent Rijmen has published a little paper about an attack that reduces AES's effective key strength from 128Bits to 32bits entitled,
"Practical-Titled Attack on AES-128 Using Chosen-Text Relations"
As the papers author acknowledges 32bits can be worked through on a modern users PC in just a few seconds.
There is a small catch you effectivly need to use a "fault injection" attack.
So the question springs to mind about a "fault injection" signal modulated onto an RF Carrier....
I'm not entirely sure how the "tilting attack" effects other crypto using a similar structure as AES. And if it does if it also applies to the current Hash contest....
After last years debacle over his post about problems in the AES key schedule, I wonder if Bruce is going to post about this one.
Its not a cheap shot but rather a legitimate question.
I dont have a SIM card reader so i cant read my IMSI. Maybe there is a keyboard sequence for this but i couldn't find it for my model.
I wouldn't mind publishing it and its not a question of having something to hide.
My argument is that it is definitely bad publicity for them but no real damage. As someone else noted - its like having usernames without passwords (but with extremely hard to guess passwords).
Injecting faults is a very powerful attack against most if not all ciphers. The only (non-perfect) practical solution against them is dedicated hardware or in other name a smartcard. They are the only commercially available solution that has some sort (again: not perfect) solution against fault injection.
You are VERY correct about the remark on being able to introduce faults over the RF channel. You need physical access to mount a fault injection attack and very few scenarios spring to mind about doing it remotely. in practice, physical access = game over anyway.
Specifically about related keys or texts - hardly a practical risk but nevertheless it points out that security margins are not high enough. It is a disappointment that it happened so fast, after a lot of systems adopted AES. Nothing to panick about but some serious research should be pointed in this direction.
These problems have solutions. The bigger problem is that the government still has export controls on systems with the highest levels of assurance. If NSA can't break it, they don't really want it exported. The market for high assurance products is slim. I remember Honeywell only sold around 35,000 of their SCOMP A1-class systems, partly due to export controls. If the US market is small and export is risky, then US companies won't invest high upfront costs on highly secure products. There are companies that would tolerate a very low profit margin. Export controls usually mean they won't even get that. How can we expect companies to spend millions on high assurance systems development if they know it will be a loss?
I think the market for high security is small in nature and not just because of draconian export rules. High security will cost a lot of money and usually does not justify the expense if you look at the real risks you have to address.
The real problem is that a lot of poor products are putting up a facade of security with no real value behind them.
But then we all have a need for some entertainment and the security market provides it from time to time...
Like you I'm having trouble thinking up a way the attack could work against 99.999% of the real world systems.
However as they say "attacks only get better"
And surprise suprise somebody has already modified it to get around the "roll back" issue.
Which opens up the oportunity to attack a slightly larger range of systems.
My concern area is for embeded systems that are effectivly encapsulated as part of tamper evident / resistant systems. Usually the designers of such systems make assumptions about what the tamper resistance gives them, and are much more prone to be lax about the design than if it was a bare board solution.
And the majority of systems with tamper resistance sit right in the logical middle of a security system...
I think I will be keeping a cautious eye on this as I suspect if it's going anywhere it will do so within 12months.
It does however make my observation that NIST need to be thinking at the framework level more urgent and as others have observed there should be more than "one approved algorithm per function", not the current "there can only be one" mindset.
Time to dust off Serpent perhaps (which I actually prefered to Rijndael for several reasons)...
From the top of my head it seems a clever idea if it is indeed correct. Still, if the embedded world is what interests you there are some clever tricks and countermeasures against fault attacks.
In my opinion this is divided into two distinct categories:
1) invasive attacks - that require physical access, decapsulation etc. These attacks are risky and most of the time are a one-way path. you usually end up with a dead system or one that cannot be restored easily.
2) non invasive attacks - trying to influence the attacked system without going through a one-way process.
If your hardware is equipped with sensors for fault injection, tampering etc. the real question is how good are they?
Again i think the only affordable, secure & commercially available solution are smartcards. They are far from a perfect solution but they certainly are the best option the market can offer.
Designing around a smartcard as the "trusted anchor" of your system is a solid design decision in my opinion. If you can afford a full-blown HSM it is obviously even better but at a premium (and a hefty one!).
I fully agree with your comment about NIST but they probably want to avoid the Babel tower of too many options. Serpent is definitely a very good algorithm but in real life you have to balance a lot of tradeoffs. I guess that if you are looking for sheer cryptographic strength you can design a very good solution. It would probably crawl very slowly and will not be easily implemented across different hardware platforms. A standard should address all needs if possible.
Still, shit happens and a single approved algorithm is not ideal, even if it is a good one.
Old age and long hours might be getting to me, but isnt the IMSI number printed on the inside of most mobile phone' battery compartments?
Aren't we all suffering from long hours and Father Time laughing at us...
The IMSI is the SIM identity (your identity on the network). You are referring to the IMEI which is the handset identity, used for tracking stolen handsets. It is rarely used by the network and many network operators do not implement a registry of stolen handsets.
This is indeed printed inside the battery compartment and can be seen also with a keyboard sequence: *#06# on most handsets.
Rgr that - thanks for setting me straight.
Now I am out of the office and have my mobile phone back I would have been able to answer my own question.
*hangs head in shame*
Is the IMSI retrievable from the (in my case at least) 19 digits printed on the SIM card?
The printed number on the SIM is your ICCID. It is used for logistics only and is not used by the network at all.
Some operators might compute the IMSI from the ICCID, because it is unique. There is a known structure to the ICCID as well as the IMSI but for this you need to read a lot (& extremely boring) standards.
Other operators just use a random IMSI or a serial one - it depends on network policies.
The ICCID is also stored in a file on your SIM. I guess the reason is to allow reading of this number electronically.
There is also a file for the IMSI and a separate file for the TMSI which is assigned periodically by the network.
The bottom line: you have many identities on a phone network and none of them is your phone number...
Is that redaction at the bottom "email@example.com"?
Well funny enough I do work with network fraud and billing, and in those systems, the IMSI is used to identify the subscriber. We do not use the TMSI. So saying the IMSI is not (or rarely) used - that may be true in the radio network, but in the OSS it is definitely used.
Anyway, maybe it's a far way off getting the IMSI from an IPAD... to committing fraud in the mobile networks...
The TMSI is a short-lived identity that changes every fixed amount of time, every cell handover or every few calls, according to network policy. Thus, it cannot be used where long-term identity is needed, such as billing stuff.
You are correct in saying that it is a far shot to do monkey business over the network if you just know the IMSI.
What if your IMSI is your phone number? Which mine seems to be.
Wait...Gizmodo told me that it was Apple's worst security breach EVER. Who should I believe!
The way I look at it, there is a risk in everything we do.. ipad, cellphone, drinking water, mcdonalds, driving, and even basic, vital things like breathing..
IMSI exposure can be a bigger deal than you might think. It's true that the TMSI is used most of the time, but every time your device boots or loses network connectivity for some duration, the IMSI is retransmitted. So, jam the cellular frequencies of interest and suddenly everyone in range of the jammer is retransmitting their IMSI. This can then be thought of as a way of tracking phones with a known IMSI.
Also, Bruce mentioned the information could be used to 'eavesdrop,' not spoof or clone. Eavesdropping is very practical with an IMSI alone. Spoofing, however, would require knowledge of the target's authentication key, Ki. The most practical way to get a user's Ki would probably be to hack the network's authentication center.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.