Karsten Nohl: also the real deal.<p>Here, for us, are the nut grafs:<p><i>In early 2011, Nohl’s team started toying with the OTA protocol and noticed that when they used it to send commands to several SIM cards, some would refuse the command due to an incorrect cryptographic signature, while a few of those would also put a cryptographic signature on this error message.</i><p><i>With that signature and using a well known cryptographic method called rainbow tables, Nohl was able to crack the encryption key on the SIM card in about one minute. Carriers use this key to remotely program a SIM, and it is unique to each card.</i><p>This is a little vague and I don't understand the OTA protocol like, at all, but what it sounds like is that there is a case in some implementations of SIM OTA where (a) errors for improperly signed messages are noisy, (b) those errors include some of the plaintext of the improperly signed message, and (c) the error message itself has a signature that is intended to be valid only for the error.<p>Possible next steps: (i) you can table-solve for the signature (presumably this is a MAC, not a signature) for your intended message due to the way plaintext hits the error message, or (ii) you can table-solve for the plaintext of a previously unknown ciphertext by taking that ciphertext, flipping a bit to invalidate the signature, and collecting the error signature.
I have been working on OTA platforms for years with Mobile Network Operators worldwide, and I have yet to meet one that is only using DES for OTA keys. All the ones I know are using 3DES. Not sure where Nohl is getting his estimations from. Half a billion SIMs? Show me the data.<p>For this attack to work remotely you need to send a binary SMS and be able to read the SIM answer, which probably requires some privileged access to an operator's SS7 network. Far from obvious. Since Network Operators are in complete control of SMS traffic, blocking anything that has not been issued by their own OTA platform is just a matter of configuring a filter on an SMS-C -- if not already done.
Hurray for Java applets.<p>But seriously, there is a sunny side to this story: a user could load her own programs onto her SIM. She could gretaly extend the functionality of her phone... with programs that she trusts. Maybe even ones she wrote herself.<p>Imagine... an open platform. Oh gosh, that would be terrible, wouldn't it?<p>Otherwise this story highlights the concept of "minimum viable product" not in the startup world, but as it exists among major industry manufacturers. For example, if SIM manufacturers can get away with using DES, then why invest their time and money in using stronger crypto? There are so many examples of this type of thinking... it's certainly not limited to imlementations of cryptography or SIM cards. No doubt, some would say this is simply Business 101... ask any used car salesman. But it's particularly acute in hardware and software.<p>Do hardware and software worlds makers need higher standards and more serious "quality control"? Beyond the cosmetic appearance of their work, no. Because users are generally indifferent to all else. What they don't know won't hurt them.<p>Did you know you can type encrypted messages directly with a text editor called ed(1)? How cool is that? It's so easy. Who needs PGP?<p>It uses DES, but hey, DES is good enough for SIM cards, so...
It's a "known plaintext" attack on DES. Via google translate, here is an article from Heise with more details:<p><a href="http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.heise.de%2Fsecurity%2Fartikel%2FDES-Hack-exponiert-Millionen-SIM-Karten-1920898.html" rel="nofollow">http://translate.google.com/translate?sl=auto&tl=en&js=n&pre...</a>
Article mentions "credit card java applets on SIM cards". I've never used one of those, and I know nobody in the western world who does.<p>I always presumed that these sim java applets are crapware that is mercifully hidden on todays smartphones.<p>It's also my impression that Mastercard and Visa paid a hefty stupidity tax by thinking in the 2000s that it would be important to have their software on SIM cards, not foreseeing that smartphone apps would just bypass that whole layer.<p>Anybody know of an application in the western world, on smart phones, where these java applets are really used?
vaguely related question ... is it safe to insert an arbitrary sim card in a phone ?<p>i want to try out some of the gsm mvnos in the states (eg airvoice, ptel and h2o). an at&t or comcast or microsoft has a reputation that's worth billions, so i "trust" them to only be semi-evil and at least semi-responsible. i don't know much of these mvno companies, but assume they're living on the margins and don't have too much to risk. could they, or an enterprising engineer working for them, mess with the sim card to take something of value from me ?
What I'm curious about is what Nohl meant when he said that it would take six months from the time of his presentation at Black Hat for crackers to develop working exploits based on his findings. And if he is (as the article suggests) working with the phone companies, why not simply wait until they've implemented their patches (if they in fact need them)?<p>If indeed it is as simple to force a sim to run these malicious applets as using some sort of rainbow-table-powered replay attack, what would be the challenge? Or perhaps he was referring to the more lucrative aspect of breaking out of the sim sandbox...
<p><pre><code> *Verizon did not specify why its SIMs were not vulnerable*
</code></pre>
I was under the impression that Verizon phones don't use SIM cards because their network is CDMA instead of GSM.
I don't understand the article's description of the sandbox vulnerability. On the iPhone app sandboxing is done by iOS, not in the SIM. Does the reporter just not understand, or is there another layer I'm not aware of?
A beautiful, although not really accurate, explanation of a buffer overflow:<p>> The way this works is somewhat complex, but Nohl’s virus essentially gave the infected Java software a command it could not understand or complete – eg. asking for the 12th item in a 10-item list, leading the software to forgo basic security checks and granting the virus full memory access, or “root,” in cyber security parlance.