SIM Cards Have Finally Been Hacked, and the Flaw Could Affect Millions of Phones | Hacker News Reader

SIM Cards Have Finally Been Hacked, and the Flaw Could Affect Millions of Phones

forbes.com

262 pointsmdewinter95 comments

Karsten Nohl: also the real deal.

Here, for us, are the nut grafs:

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.

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.

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.

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.

At one point he says that he thinks it will take the black hats six months or so to figure out the exploit, but then, in the passage you have quoted, he gives what sound (to my non expert ear) like fairly massive clues. Is it possible he has revealed too much?

Well, he's talking about it at Black Hat, right? Black Hat talks are usually full-disclosure.

Looks like it. https://www.blackhat.com/us-13/briefings.html#Nohl

He'll be presenting the same subject at OHM on 03/08/2013 too: https://program.ohm2013.org/event/169.html

Its all about full disclosure for ethical reasons. Can't say that about them white hats.

I don't know what this comment means. Could you, or someone else, explain it? Who are the "white hats"? Why do they have different perspectives on full disclosure than other people? Who are those other people?

I think hondje's comment was intended to be sarcastic, for the rest see

https://en.wikipedia.org/wiki/White_hat_(computer_security)

Maybe a riff on the burgeoning "green hat" practice of selling exploits instead of simply disclosing them, versus black hats releasing them publicly for free?

I wouldn't have revealed that the second bug is a buffer overflow. The knowledge of the existence of a buffer overflow vulnerability on SIM cards is much more dangerous than knowledge of a buffer overflow on, say, a desktop O/S. Six months is a long time for a well funded organization to fuzz such a small piece of software.

On a different note, I find it extremely frustrating that the community still has to deal with buffer overflow bugs in 2013. Hardware bounds checking architectures have existed for half a century, and SIM cards are a perfect example of special use devices that would benefit from this.

The buffer overflow is only accessible after you have broken the crypto stuff, no?

I'm guessing its more the latter (send an error an then use the result to deduce the key) That being the case, then someone duplicating the Raspberry Pi micro cell site could passively attack any phone that came within range.

Makes you wonder if the FBI snooping cell tower already does this :-)

Makes me wish I had the burner phone concession at DefCon.

Yep, that appears to be the case:

http://www.theregister.co.uk/2013/07/22/mobile_gsm_sim_card_...

An attack similar in spirit to this breaks RADIUS.

I strongly suspect that the attack uses the known plaintext of the error message to solve directly for the DES key (which is only an effective 56 bits). I wouldn't be surprised if it used the old FIPS DES-based MAC.

This appears to be confirmed - from https://srlabs.de/rooting-sim-cards/ :

  A rainbow table resolves this plaintext-signature tuple to
  a 56-bit DES key within two minutes on a standard computer.
  The cracked DES key enables an attacker to send properly
  signed binary SMS, which download Java applets onto the SIM.

It's particularly sad that the same key is used for the MAC in both directions (network-to-SIM and SIM-to-network).

Also sad that it's refereed to as a signature.

I still haven't been able to find the particular documentation around class 2 SMS verification. Most of the things I'm finding talk about IMSI using HMAC-SHA1 for OTA validation. Is this at a lower level?

Edit: Found this: http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_33_Beijing...

In my company I started to issue smart cards instead of simple magnetic cards, because the tech is so hard to implement I started to question if this was a mild case of security through obscurity. I really hope this isn't the case, many banks store passwords in those cards, including us. This password cannot be easily transported back to our servers.

Anyway, there is something missing, as a security measure SIM cards should burn out if you keep calling it.

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.

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.

+1; I worked on SIMs in the past, and all our customers were using 3DES. They also all required OTA messages to be signed, so I think the chances of half a billion being accurate is crazy talk

Would (root) access to a microcell work?

Good question. SMS are transmitted over the NAS layer of the 3GPP stack, which terminates beyond the cell (NB/eNB). There is NAS level security but I don't know if it's end-to-end or only over the air link. Hopefully it's the former but one should dig the specs at 3gpp.org to confirm.

Operators sometimes think they are using the good stuff but aren't. Same thing happened with COMP128, operators were unknowingly using it for years and years after it was broken and thought fixed in new SIMs.

Hurray for Java applets.

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.

Imagine... an open platform. Oh gosh, that would be terrible, wouldn't it?

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.

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.

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?

It uses DES, but hey, DES is good enough for SIM cards, so...

How would you extend the functionality? Programming in JavaCard is really not fun (my opinion) and the space and processing power are really limited. The biggest use of it is verifying information (like pins or certificates), but what else would you do that your phone can't?

Consider that some might not program for "fun".

They might do it out of necessity: to "scratch itches".

Limitation breeds creativity. This is true in general, but certainly in computers. Ever heard of demoscene? By comparison to the constraints we had to work with in the 80's, the power of today's handheld computers (one usage of which is as a "phone") is hardly a limitation. But I guess it would depend on what you are trying to do. I have no idea what you would want to do. Only you know that.

As for what others might do, were they to be able to upload their own software to their phones, well, the only way to answer that question is to let them and see what comes out of it.

Only a fool would believe he could direct, let alone predict, all the uses that might be made of a particular software program, a particular language or a particular computer.

One use of a computer is as a communications device, aka a "phone". Another is a "game console". There are plenty of other uses for handheld computers even if you yourself cannot think of them.

But you can already upload your software to phones. You don't need the simcard for that.

I thought we were talking about SIM cards.

Can I upload software to my SIM card? No.

Most phones accept some type of SIM card, while not all phones have a means of user-controlled offline external storage (microSD, etc.).

Why can't the user access a SIM card? Why can't she look at the software stored on a SIM card?

The SIM card slot is pretty much off-limits to the user. Yet the user owns the phone.

This is like buying a computer that has a special card slot owned by a single company or a consortium of companies that produce special cards only for their own use. The user is effectively denied access to the slot.

Do you program your PC BIOS or firmware?

http://www.coreboot.org

How many PCs ship with it?

Usually, whatever software PC's "ship with" is crapware. Go figure.

"Crapware" is just my opinion. Although I've heard others note the same thing.

I think at least some Chromebooks use it. It finds use in HPC clusters and embedded/industrial settings as well.

All Chromebooks except for the ARM model and the CR48 prototype use coreboot.

The ChromeOS developers are currently porting coreboot to ARM, too.

I wish! I hate my PC's bios. So many superfluous timeouts, so much waiting around (clearly braindead programming that doesn't do hardware well). A stupid text based config interface. Nothing about the BIOS is good.

You mean, besides providing a standard way to access hardware that ARM systems still don't have to this day?

And all this time, I thought my x86-64 workstation was BIOS free!

http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Int...

> UEFI is meant to replace the Basic Input/Output System (BIOS) firmware interface

Hence firmware to replace BIOS, with the same purpose as BIOS.

So do you re-program your UEFI firmware?

And since when is x86-64 an ARM system, since that was my remark?

Having a specification and a reference implementation is possible without the reference implementation being proprietary... Personally I would much prefer that.

According to https://news.ycombinator.com/item?id=6083583, Coreboot is being ported to ARM.

Yes.

You do not own the SIM card, it remains full property of your network operator. As such, they have a right to keep you off-limits.

FYI: the main Javacard applet on a SIM card is the GSM applet, the one you use to authenticate against your network. Other applets are useful for network operators: IMEI tracking sends them your phone ID to help them configure it correctly -- it is also used to track stolen phones. Another useful one updates your preferred foreign network list when you change countries, connecting you automatically to a cheaper network when available.

Uploading your own software will not do you much good. As mentioned above, CPU and memory are very limited on SIM cards, and Javacard is basically a glorified assembler you do not want to touch. SIM cards are mostly there to perform some simple crypto operations for network authentication and that's it.

Imagine reversing the direction of reporting: allowing the user to learn more about the network, for example. That would be just one reason to put custom firmware on a SIM card. Another might be running a known-secure firmware for security-conscious users (corporations, governments, kidnapping/extortion targets, etc.).

SIM cards don't know anything about the network they are running on, this all happens inside your terminal. They hold an IMSI (=contract #), a set of private keys, and some utility applets. SIM cards don't even know their own phone number.

As for running a known-secure firmware: in the end a SIM card only authenticate you against a Mobile Operator with a pre-shared key. If you believe your SIM is running a non-secure firmware, how can you trust your Mobile Network Operator not to do fancy stuff on their network behind your back?

Who says there can only be one SIM card? What if the user can have her own SIM card? Who says SIM cards are only useful with cell networks? What if the user has her own network? Is that impossible, now and forever? What if she has her own authentication and encryption needs, apart from some telecom's network?

Yes, the telecom owns the card they give you. Indeed, that is their property. But they don't need to own the smart card standard and use it to exclude users from using the slot.

Imagine if the motherboard you bought would had certain slots that were off-limits to you and open to use only by certain companies.

As for "glorified assemler", have you considered something more succinct, like FORTH. There's nothing glorious about Java.

SIM cards are just your average smart cards dedicated to do mobile network stuff. You can buy your own blank smart cards from Gemalto and Oberthur if you so wish.

Javacard is not Java. No OO, no classes, no GC, no floats, no strings, the only data type you can use is int16. Have fun.

I'm no authority on JavaCard, but I'd guess it's verbose like Java and expects some sort of auto-completion capable "IDE". I took a quick peek at a JavaCard standard and I could swear it said there are classes.

I don't want no stinking Java, whether it's a small subset of the language or the full blown monster. For the task at hand, I'd have more fun with assembly language than anything prefixed with "Java".

The blank smart card possibilities are enticing. If we can use our own crypto.

Doesn't OpenMoko's WikiReader run FORTH?

I would like to be able to take an older smartphone and use it as a smartcard-like device but with a full-fledged computer on it. For example, being able to use a Motorola Droid with a USB cable as a password manager. Keep the key secured on the SIM card. Use the touchscreen to enter the unlock password, and choose a password off a list. Send the password to a computer over USB by emulating a keyboard, or a custom driver that creates a secure channel to a specific app for authentication.

Sounds like a lot of work. I don't trust LastPass et al., and really just need a single encrypted password file. My method doesn't provide a driver secure channel, but it is achievable today.

1) Buy a slim ipod touch 2) Jailbreak (unnecessary) 3) App CryptMe allows transfer of plaintext from your computer through iTunes, password unlock on the device, quick search (nice), and according to Firewall iP (Cydia program) doesn't connect to the internet (or you could just always keep wifi off).

Look at the OpenPGP card. You can get a smartcard reader with a PIN-entry pad for like $50, and boom, you have a secure certificate store with GPG.

GPG isn't pretty, and support lags with OS X releases but you can do alot with it.

I've been using this methodology for securing cloud backups for several years. Using tools like Duplicity, you can safely encrypt data on potentially untrusted devices or networks using a public key, and keep the private key safely stored somewhere on the smartcard.

The downsides to these sorts of approaches is that encrypting data is easy, key management for decrypting it is a pain.

I don't think this is a reasonable assessment at all. SIM manufacturers use 3DES, not DES, which - while not recommended for new systems - is still pretty damn secure.

I don't think you've really understood the complexity of the SIM - there are literally thousands and thousands of pages of specification, which means that any sim will interoperate with any phone.

A SIM is not an "MVP" by any stretch of the imagination - it costs millions of dollars to enter the market; there are stringent security and compatibility controls, and no-one will consider selling you silicon unless you're ordering millions of units per year.

You're right. DES repeated thrice is better than DES. But I wonder why 3DES is not recommended for new systems? Hmmm....

You're wrong on the SIM as an MVP idea. I guess I'm not communicating clearly enough. What I mean is the computer ("phone") itself, of which the smart card subsystem (e.g. SIM card system) is a part, is of inferior quality. This is only my opinion.

I understand there are barriers to entry in place. But how does that relate to low quality, minimally viable products? I'll let you or someone else answer that.

Maybe we need to remove the barriers, lower the cost of entry and lower the complexity (simplify)? No, those sound like ignoble pursuits.

Not recommended for new systems: Mostly because it's slow (vs. AES), and 3DES is effectively 112 bits, which is a bit weaker than you'd want for a new system deployed today (which might be in service for...20-30 years?)

I don't know of any attacks on DES better than brute force and on 3DES better than brute force w/ meet-in-the-middle.

The 64-bit block length is more of a problem than the 112-bit key length.

For instance, if 3DES were used in OFB mode, one would expect on average to have a unique 64 GB keystream before entering a repeating 32 GB keystream. If the attacker is able to choose the data being encrypted, CFB could have similar limitations. With CBC mode, you'd expect only 32 GB of encrypted data before you got your first self-collision in ciphertext. CTR mode with perfectly random IVs does much better, at 64 exabytes. Even 64 EB isn't as big as it used to be, especially for a key that can't be changed.

For many uses, you'd much rather have an ideal block cipher with a 128-bit block and 112-bit keys than an ideal block cipher with a 64-bit block and 512-bit keys.

We've read here recently, re: Snowden in Hong Kong, (rooted?) phones and ($5?) SIMs are inexpensive and popular in HK. Are there varieties of --I don't know, what-- `rooted(?)', `unformatted(?)' SIMs that become desirable to a knowledgeable hacker community, beyond what consumers get with their service?

edit: I just now found on HN front page:

https://srlabs.de/rooting-sim-cards/

It's a "known plaintext" attack on DES. Via google translate, here is an article from Heise with more details:

http://translate.google.com/translate?sl=auto&tl=en&js=n&pre...

Unfortunately, "known plaintext" is just about the most general term you can use to describe a crypto attack; it covers a huge number of different attack scenarios.

Sorry, I'm not a crypto guy. It seems that he sends an "Over The Air" SMS that has an incorrect signature and then always recieves a response that he already knows.

EDIT: Ok, I just read your other comment and must say that you probably understand a million times more about this than me, so disregard this comment.

Oh, sorry, I wasn't sniping at your comment!

This isn't new, but I wonder if it's related:

"All SIMs could reject OTA message without Digitial Signature (DS), but this is rarely done as it brings additional pain to gsm providers. Most of the SIMs are correctly secured. Most of the SIMs accept OTA messages that are not encrypted. Some SIMs accept OTA messages that only have a correct Cryptographic Checksum (CC) and some SIMs only require a correct Redundancy Check (RC) and also require counter increase N+1. Most of the SIMs dont require any security feature and accept OTA messages without no RC, CC or DS, for example - Globul. (by marek, TODO: name the networks!)."

http://wiki.thc.org/gsm/simtoolkit#head-1c0ca2c9ebd6ac101c90...

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.

I always presumed that these sim java applets are crapware that is mercifully hidden on todays smartphones.

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.

Anybody know of an application in the western world, on smart phones, where these java applets are really used?

Pretty sure Blackberry does in Canada, and I assume everywhere else that their Mastercard payment NFC (paypass) works. They touted it as being extra "secure" due to being on the SIM instead of the phone. No idea if carriers selling Bold and Curve handsets are using DES SIMs vuln to this.

Yes, ISIS uses SIM applets: http://en.wikipedia.org/wiki/Isis_(mobile_payment_system)

Google Wallet uses the same type of applets but stored in the phone's SE rather than the SIM card.

I know Telenor in Norway provides a service called BankID that is tied to Telenor SIM cards -- but I don't know anything about the implementation details (or how they've managed to lock the other providers out of the game).

BankID is a centralized service for authentication used by banks, and the "other" implementation is based on a (browser) java applet.

vaguely related question ... is it safe to insert an arbitrary sim card in a phone ?

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 ?

I don't know much about SIM-cards, but in general I would say, no, it's not safe. First there's the possibility of a problem with the phones interface to the SIM-card (possibility of direct exploitation) -- secondly, it's the possibility of putting "other stuff" on the SIM-card.

A friend of mine implemented a wifi-posistioning system that got power from the phone's GSM signals (it wasn't using a full wifi stack, just enough to broadcast an 802.11b frame that access points could pick up and triangulate). It was used for positioning in museums, and the phones where used for guiding information (so it wasn't a malicious hack) -- but it does illustrate that there are many possibilities.

Put a flash storage chip on there, and record all GSM traffic for example?

I can't guarantee there's no risk. But in Europe there are hundreds of virtual network operators - dozens in most countries - and I've never heard of any cases of operators (or anyone working for them) "messing with" sim cards, and people here newer think twice about switching sims.

It won't harm the phone, but it won't work either. You can find generic SIM card that you can program yourself, but that's not what is used in a phone. Your phone will only work with a SIM card embedding specific applications called SIM for 2G (that's where the name comes from as you see, the physical thingy is named UICC) or USIM for 3G/LTE. And this application embeds security components that will authenticate the card to the operator, either as a direct customer or as a customer of another telco which is a roaming partner. If this authentication fails, you'll have no access. If there's no valid SIM or USIM application your phone modem won't do anything with the card.

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)?

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...

>what would be the challenge? //

Maybe creating the rainbow tables? [I'm not familiar with any of the details here FWIW, just guessing as that seems the most likely thing that could be estimated to take 6 months].

     *Verizon did not specify why its SIMs were not vulnerable*

I was under the impression that Verizon phones don't use SIM cards because their network is CDMA instead of GSM.

Verizon's LTE phones have a SIM.

Their 4G LTE network uses sim cards.

LTE SIMs don't use DES encryption.

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?

That's a separate sandboxing system. The SIM has its own sandboxes.

From what I could gather, the sandboxing was actually referring to the SIM card itself. It was hard to tell through the layman-ified description, but it sounded like he used some sort of buffer overflow to break out of the sandbox and access other parts of the SIM's memory which he shouldn't have been able to.

This is at the SIM card level.

Most SIM cards are actually micro computers that communicate with the host system for certificates, encryption and some provider specific information, besides the common address stuff.

Usually the software is done in Assembly, C or JavaCard, with JavaCard use getting increased in the last years.

The JavaCard exploits are related to the VMs running the system, which are usually coded in a mix of Assembly and C. JavaCard VMs don't have a JIT due to memory constraints.

A beautiful, although not really accurate, explanation of a buffer overflow:

> 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.

What are the implications?

Can't stand Forbes and their over the top ads, tldr would be appreciated.

Why don't you get an ad blocker - e.g. Ad Muncher is a great one.

I prefer to allow sites to monetise their visits within reason. If they go insane like Forbes then I just avoid them.

You can do that easily with any decent adblocker. You could disable it for all sites but Forbes if you like.

Right now, you are just leeching other people's time.

Thanks for the modbombing :-)

I'm not leeching other people's time more than any other comment. If you're not interested proceed with the next post.

Comments with insights to the article, that don't ask people for favors, are not leeches. Your comment was a leech.

Refer to GP for instructions.

You just wasted my time with your pointless comment. Well you didn't, I could have chosen to ignore it.

In general I find it wiser to realize that we only give other people our time; they never take it.

It is very hard to take someone's time without their permission.

Now give me back the time I spent responding to you.

I prefer to save advertisers money by blocking ads which I am not clikcing anyway. Truth to be told, I did not bother to install ad blocker, but would feel no guilt if I did, for the reason above.

Why should we be forced to download third party applications/plugins in order to read a news post without any unnecessary interruptions?

No one is forcing you, just don't visit the site, then..

Because the site is a private property and not obliged in any way to offer reading without interruptions.

Here's the primary bit the article says about implications:

"The two-part flaw, based on an old security standard and badly configured code, could allow hackers to remotely infect a SIM with a virus that sends premium text messages (draining a mobile phone bill), surreptitiously re-direct and record calls, and —with the right combination of bugs —carry out payment system fraud."

Any SIM? Remotely how? through a call or a message?

Just trying to figure out the scope of this problem. Journos seem to care more about sensation than facts.

Figs summarised, if you want the details can't you read up on it (eg via the article posted)?

I actually went ahead and read it, and it's extremely obscure.

I'm asking just in case someone has a better source.

This is basically all the detail about the actual flaw in the article:

"In his study, Nohl says just under a quarter of all the SIM cards he tested could be hacked, but given that encryption standards vary widely between countries, he estimates an eighth of the world’s SIM cards could be vulnerable, or about half a billion mobile devices."

"his team tested close to 1,000 SIM cards for vulnerabilities, exploited by simply sending a hidden SMS. The two-part flaw, based on an old security standard and badly configured code, could allow hackers to remotely infect a SIM with a virus that sends premium text messages (draining a mobile phone bill), surreptitiously re-direct and record calls, and — with the right combination of bugs — carry out payment system fraud."

Seems like it would only affect a very specific subset of mobile phones.

Reply on news.ycombinator.com