China, Cyberwar and your Phone Company

Why we are not paranoid about Huawei

Yesterday, the House Permanent Select Committee on Intelligence published a watershed report highlighting the strategic importance of telecommunications equipment and recommending that US companies not buy gear from either Huawei or ZTE. News coverage of this topic has been widespread, including 60 Minutes and The Wall Street Journal.   The primary fear is that Huawei and ZTE will insert "back doors" into telecom equipment that will allow the Chinese government to disrupt or intercept communications inside American networks.

Such back doors are not unheard of.  Although few are reported publicly, there are publicly known examples of large-scale telecom exploits, like

•  the Alcatel Speed Touch ADSL modem that could be reprogrammed remotely to tunnel traffic out of a LAN, or
• the 2004 "Athens Affair", where an insider hacked a back door into an Ericsson lawful intercept switch, or 
• the 2010 incident when roughly 15% of all IP traffic, including most of the Washington, DC area, was diverted through China Telecom for 18 minutes.

Whatever Huawei says about "just being a business", do not doubt that the Chinese government can induce a Chinese company into supporting its missions, through coercion, payment, regulatory favors or even simple patriotism.  While some may try to pass off these concerns of the US government as xenophobia or paranoia, there are enough publicly-exposed precedents just in recent years to justify concern, and you can be sure that the people in the intelligence community who raise these concerns are aware of other incidents that were never publicized.  This is not paranoia.  The concerns raised by this report must be taken very seriously.

Multiple threats to US carriers

The internet was designed with the assumption that there are malicious actors inside the network, but telephone systems are different.  The SS7 network, on which the public telephone and cellular networks run, is a true "network of trust", with few internal security controls.  Once malicious code is introduced into a telephone company's core network, there is very little that can be done to control it.  This is what Rep. "Dutch" Ruppersberger, ranking Democrat on the intelligence Commitee meant when he said, "In the telecommunications world, once you get the camel's nose under the tent, you can go anywhere."  This is why the introduction of suspect equipment into US telephone networks raises such serious alarms, much stronger alarms than in the IP routing world.  In some cases, the government has already intervened directly to stop large companies from purchasing suspect equipment, but small companies may make such purchases and not be noticed until after the fact.

Not being noticed does not mean there isn't risk for carriers.  The government could take actions post-facto to limit the perceived security threat.  One measure might be to refuse new spectrum licenses to limit geographic extent of the threat.  Another measure might be to prevent the merger or purchase of the company to prevent the suspect equipment from infiltrating into larger networks.  Either of these actions would be devastating to the growth and valuation of the affected company.  Whether the suspect equipment is a real threat to security or not (and I would wager that it is), just having the government take such a strong position against these vendors makes their equipment a threat to the businesses who use it.

Solutions

The immediate solution, and the strong advice of the government today, is for carriers avoid Huawei or ZTE equipment.  But this issue of Chinese back doors raises a larger question of how to determine the trustworthiness of any telecom system, Chinese or otherwise.  The real answer is open source software.  By "open source", I am not necessarily referring to software that is released to the public, but simply referring to software that can be provided to customers in source code form.  The license may be GPL or may be something more restrictive, but by allowing end users to review source code and build their own binaries, either for installation or comparison, everyone involved in the process can insure that the software is what it claims to be.  So far, the selection of open source software for cellular and core networks is limited, but it is growing, with products like OpenBTS and yate, and projects like Osmocom.  Security is just one more reason that these products represent the future of telecommunications.

(David Burgess is the lead developer of the the OpenBTS software and co-founder and CEO of Range Networks.)

Follow-up Comment

An advisor to our company read this post and asked some questions: Why is the open source solution adequate? What about hardware? Those questions go to an excellent point, that the open source approach cannot end just with the application source code, but must go down to "bare metal", including operating systems, device drivers, firmware and device schematics. For an "old school" approach, with custom chips and lots of special-built circuit boards, that is anathema, because astronomical development costs and hazy legal standards (like the copyright status of a circuit board) justify strict non-disclosure controls on the intellectual property. But as modern systems move toward commodity hardware, this becomes less of an issue, since more and more of the functionality (and value) of a system can be expressed in source code and protected with well-established copyright law.

Some Comments on Satellite Phones

(There is now a follow-up to this post that digs into some of the details of GMR-1 transmissions. The (in)security implications are stunning.)

With the recent attack on journalists by Syrian troops, there has been a lot of discussion on the security of satellite phones, especially GMR, the technology used by Thuraya. Here are some basic facts on the security of GMR and satellite phones in general:

• GMR uses geostationary satellites. Downlink signals from this system are visible over large areas of the Earth's surface, especially for someone looking at the sky with a dish antenna.
• GMR handsets use wide-beam antennas. Uplink signals from the handsets are visible from space, not just at the serving satellite, but over really big regions of space, occupied by lots of other satellites.
• Uplink signals from satellite phones are also visible on the ground in a vicinity of the handset, probably at ranges of several kilometers for interceptors with directional antennas. These handsets are easy to detect in a radio environment because they transmit distinctive patterns and are relatively rare (much rarer than cellular handsets, for instance). And any transmitter that can be detected can be located, using any of a number of techniques commonly practiced by most intelligence services.
• The level of air interface security on GMR handsets is probably lower than on cellular handsets. But even if the air interface were absolutely secure, a GMR handset would still be easy to locate by it's distinctive radio signature.
• GMR handsets include GPS receivers and transmit identity and location information to the network operator. These transmissions are completely in the clear, but even if they were encrypted, the network operator would have access to this information.
• GMR encryption is not end-to-end, so the network operator normally has access to plaintext user traffic.
• GMR handsets register with the network periodically, reporting identity and location, even when you are not "using" them.
• Even if a GMR operator, as an organization, is sincerely dedicated to the security and privacy of its customers, it is difficult to completely protect a large organization from infiltration by criminal organizations or state intelligence services, through technical hacking, social engineering, bribery, blackmail, political/religious recruitment, etc.
• Everything I just said about GMR is at least mostly true (if not completely true) of any civilian satellite telecom product and even a lot of military satcom systems.
• Satellite phone users tend to be more interesting than the general population. Because satellite phones are relatively expensive and mostly used by international travelers, the conversations they carry tend to have interesting content, things that the users thought were important enough to spend real money talking about. So, for an intelligence service, eavesdropping on satellite phones is a more effective use of resources than eavesdropping on most other kinds of networks. They get less "mom and pop crap" and a lot more useful information.
• In any given country, the users of satellite phones are mostly foreigners, who are often subject to a lower legal standard for eavesdropping, especially for international telephone calls.

Just some things to think about the next time you use your GMR phone, BGAN terminal, Iridium 2-way pager, etc., especially in a war zone. Regardless of encryption, authentication, etc., the mere existence of one of these radio signals sends a message to an observing military force: There's someone over there with fancy comms and it's not us. That can be a very dangerous message.

(David Burgess is a lead developer in the OpenBTS project and one of the founders of Range Networks.)

SMSC Address Caching in iPhones

I'm going to make one of my increasingly-rare technical posts today.

When we got back from Burning Man this year we received a few instances of a really interesting bug report. It goes like this: "My friend X and I texted each other on the playa with your system, but now that we are back home, we can't text each other anymore. Texts to and from other people still work. We both have iPhones." After some head-scratching, I recommended a brute-force fix: "Delete all of the messages you exchanged through our system at Burning Man." It worked.

So what happened? When you receive or send a text message via SMS, it has two E.164 addresses. One address, in layer 5, is the mobile phone number of the subscriber sending or receiving the message. The other address, in layer 4, is the SMSC that processes the text message. (SMSCs are to text messages what SMTP servers are to e-mail, and they have E.164 addresses just like telephones.) Normally, the SMSC address for your outgoing text messages is set by your carrier. In some phones, you can also override the carrier's SMSC address and provide one of your own. Here's my working theory: It appears that certain models of iPhone, under some set of conditions, remember the SMSC addresses from which you received a text message and then use that SMSC address for future outbound messages. When you send a text to a given person, these iPhones appear to send the outbound message through the same SMSC used for the most recent message received from that person, or, possibly, the SMSC address used for an error message associated with an attempt to send to that person. Since the OpenBTS system doesn't have a real SMSC address, we were just filling in the SMSC address field in the L4 header with a fake number. When people got home, these iPhones continued to use this fake SMSC address to send texts to anyone from whom they received text messages through our network. Those send attempts failed. When they deleted the messages with the fake SMSC address, everything worked normally again.

So what do we do to prevent this? One solution would be to stick a known SMSC address into the L4 header, instead of the fake one, but that might have unexpected effects of its own. A better solution is to preserve the L4 SMSC address end-to-end, even though we don't use it, which is what we will do in the future.

Live and learn. It is interesting to know, though, that you can use a BTS tool like OpenBTS or OpenBSC to control SMSC settings in a closed device like the iPhone. That probably deserves more investigation.

GSM Security Workshop in Lucerne

I should have posted something about this a few weeks ago, but next week Harald Welte, Karsten Nohl and I will be presenting a workshop on GSM security at the Lucerne Hashdays conference, the Swiss counterpart to DEFCON. Under a test license from the Swiss regulator, we will be demonstrating a range of GSM attacks and countermeasures against them, using systems derived from OpenBSC, OpenBTS and OsmocomBB. Online registration is closed already, but there is still space available. This workshop should be especially illuminating for journalists, aid workers, diplomatic and corporate security specialists and anyone else concerned about the risks associated with using mobile handsets in unfriendly countries.

And if you are already attending, I look forward to seeing you there.

Did Anyone Else Notice That?

There are 4 variants of GSM's A5 stream cipher, the algorithm used to secure subscriber connections over the radio link:

• A5/0. No encryption at all.
• A5/1. "Stronger" encryption. This option is supposedly provided only on basestation equipment delivered in North America and Europe.
• A5/2. Weak encryption, exported to the rest of the world. The GSMA declared A5/2 obsolete in 2006 and mandated that it be phased out in networks and not supported in new handsets. I think.
• A5/3. True strong encryption, being phased in for UMTS systems and proposed as an upgrade for GSM systems.

My first question for anyone who happens to be reading this: What, specifically, was the GSMA's 2006 mandate regarding A5/2? Can anyone point me to an authoritative document?

My second question is more vexing. Let's assume for a minute that I really do have my facts right. Suppose you are using a post-2006 GSM phone somewhere outside of North America and Europe. The carrier's equipment isn't supposed to support A5/1. Your handset isn't supposed to support A5/2. A5/3 isn't available yet in non-UMTS networks. So what A5 variant are you using?

Still Spinning

(This post disappeared from the blog a couple of days ago. I don't know why. It's back now.)

A little over a week ago, I posted some comments on Karsten Nohl's public A5/1 attack and the GSMA's response. Reuters & MSNBC think that carrying what is essentially a GSMA press release should somehow pass for journalism. (Thanks, Foneswitch, for bringing this to my attention.) I thought that the links to ads for cellular service were a particularly ironic touch. I hope a real person actually thought to put them there. Irony aside, two things about this press release strike me.

First, the GSMA is admitting that there are simple things that carriers can do to make their networks more secure and that they just haven't bothered doing those things yet. If that's really the case, then Dr. Nohl's public announcements are already having their intended effect of forcing the GSMA to pay attention the security security practices of its members. I'd really love to hear the specifics of these improvements, though, since traces of transactions in most EU and US networks show that they are already just about as secure as their current equipment allows. There's not much left to do.

Second, many GSM networks in other parts of the world, outside the US and EU, are not encrypted at all, not even with A5/2. Many governments simply do not allow their publics to use encrypted cellular networks. This is an issue that is not addressed by Dr. Nohl's project, by the GSMA or by the various media outlets who are providing free publicity for the GSMA's damage control campaign. For nearly half of the world's GSM users, all this bickering and posturing over A5 cracking is irrelevant because they are not even allowed that level of security. Worse yet, most of them probably don't even know that. That's a much bigger story that doesn't get covered.

Given all the recent spin, I think we should probably stop listening to the GSMA and just find out for ourselves how these networks are configured. In that spirit, I would like to propose a new crowd-sourcing project on GSM security: a public catalog of the security and encryption policies of all of the world's public cellular networks. A good place to put this might be somewhere in Wikipedia, where it will be very hard to censor once published. If anyone is interested in organizing something like that, please let me know.

The Democratization of Communications Warfare

So I am in Berlin for the second time in two weeks, fresh back from DeepSec in Vienna, lounging on the main deck of c-base and looking back on the week. I'm waiting for a new passport and the consulate isn't open on weekends. Harald Welte has been kind enough again to let me use his living room and I'm looking forward to seeing some Cold War museums with him tomorrow.

For many years, the telecommunications industry has relied on the cost and complexity of network equipment to achieve many of its security goals. Sure, the standards had big security holes, but you needed really expensive equipment and a lot of expertise to exploit those holes. The problem, though, is that cost and complexity were often the only security measures. If you had network equipment, network exploitation was usually just a question of how you configure that equipment, and the attack configurations were usually obvious.

Right now, there are genuinely bad people using the public communications networks to plan genuinely bad things. There are state actors using network exploits to monitor or track these bad people. There are state actors using network exploits to abuse the privacy of their citizens. There are criminals using network exploits to commit fraud. There are targets using knowledge of network exploits to confound the state actors who are targeting them. When we see this cycle of measures and countermeasures in the world of radar systems, we call it "electronic warfare". To describe this cycle of exploits and counter-exploits in telecom networks, I'll introduce a new phrase: "communications warfare". The weapons in this type of warfare are IMSI-catchers, jammers and hacked handsets. Thanks to cost and complexity, communications warfare in the cellular networks has largely been the domain of large, well-funded organizations. Even hackers usually stayed out of this game because the equipment and know-how are at a premium, so much so that some mistake the most basic techniques for trade secrets.

Moore's Law and the open source movement are removing the cost and complexity of network equipment. VoIP projects have been doing that for wireline networks for several years now, but projects like OpenBTS and OpenBSC are starting to do the same for cellular. These projects remove barriers that prevent people from experimenting with cellular technologies in their homes and classrooms. They demystify the systems. They have the potential to democratize cellular communications, but thanks to the inherent failings of cellular security, these projects also have the potential to democratize cellular communications warfare.

I don't think that democratizing communications warfare is a good thing, but I think that democratizing cellular is a very good thing. I have spent some time this week wondering if it is possible to achieve the first without unleashing the second.

GSM Security Workshop

On November 17 & 18, at the DeepSec conference in Vienna, Harald Welte and I will present a workshop on GSM security. Because I was under an injunction at the time the original workshop description was drafted, the material on the official schedule is very limited, which harms me and DeepSec by limiting advertising. Now that my speech rights have been restored, I'd like to use this blog for a shameless plug.

The DeepSec GSM security workshop will begin with an overview of the GSM air interface, Um, sufficient for those not yet familiar with cellular protocols to follow the subsequent material. We will then describe standard Um security mechanisms, their fundamental flaws, common operational mistakes and known techniques for exploiting these flaws and mistakes. We will describe the mechanisms, capabilities and limitations of passive interception, jamming, active attacks on Um and the use of other public networks for higher-layer attacks. More importantly, we will describe best security practices, means of identifying various attacks and the countermeasures available to carriers and to individual subscribers. Going beyond theory, we will demonstrate many of the attacks and countermeasures using a private GSM network built with commercially available components, software from the OpenBTS and OpenBSC projects, and additional software components not found in the public distributions of those projects. We will also take this opportunity to blow away a lot of the trade secret claims that typically surround this field by reviewing publicly available sources, including patents, academic papers and even the court records of intellectual property disputes, that describe these attacks and countermeasures in sufficient detail to allow their recreation by engineers of ordinary skill.

Of course, that's assuming we get at least three people to sign up for the workshop, which is the minimum number to justify the cost to the conference. For more information, see the conference registration page. Early bird registration ends September 7.

A Big, Dangerous Assumption

Lately, I've been exchanging thoughts with people in the OpenBSC project about a specific class of DOS attacks against cellular networks. We discussed GSM vulnerabilities specifically, and tried and failed to think of ways to harden our systems against them.

The DOS attacks we discussed would made from the subscriber side of the cellular air interface. These "rogue handset" attacks have a fundamental commonality with false-basestation attacks: the key to performing either type of attack is having a GSM device that allows you to control layer 3 (L3), the layer where most of the resource management and call signaling actually happen. This observation touches on a huge shortcoming of many ISDN/SS7 systems, that they are built with the assumption that any entity in L3 can be trusted to follow the protcol. (I had a related conversation with Jacob Appelbaum a couple of weeks earlier where he made a broader comment about the error of "trusting the infrastructure".) The ugly truth is that if you can take control of an L3 entity you can make a lot of networks do a lot of strange things.

In a recent appeals case in England, MMI v. CellXion, the UK high court upheld a ruling that the function of an IMSI-catcher was sufficiently non-obvious to justify patent protection. Part of that decision was based on testimony from so-called experts that GSM security was once thought to be "unbreakable". It is unfortunate that the high court was mislead by such testimony. To be blunt, anyone who ever thought that GSM security was unbreakable must not have tried. Heck, you can build an IMSI catcher by accident just by misconfiguring certain cellular equipment. But the important point here is that the representations of these so-called experts reflect the long-standing assumption that rogue parties cannot get their hands on the equipment they need to spoof elements of the system. That assumption may have been reasonable in early days of SS7, when these technologies were new, the equipment was expensive and all of the networks were run by governments and megacorporations. Even then, though, breaking the security was merely expensive, far from impossible. The cost is down now. Today anyone with a few hundred dollars can get their hands on a trace phone, a surplus micro-BTS, a SIM kit, a used cellular network test set or an account with a commerical VoIP-PSTN gateway. All of these products can be used to attack cellular and PSTN networks in various ways, ranging from identity spoofing to shutting down whole cells. Most people are unaware of these risks, continue to trust the network and continue to carry potentially dangerous misconceptions about what is secure and what is not.

Some Comments on IMSI-Catchers

Update 30 Jan 2012: Since originally writing this post in mid-2009, there have been some noteworthy developments in this area, the biggest of which is that UK patent case MMI & CellXion, referenced below, went to appeal with the result that the IMSI-catcher was deemed too obvious to patent in light of known prior art. For anyone to claim secrecy here is, I think, becoming something of an intelligence test. Enjoy the original post.

I'm going to comment briefly on IMSI-catchers. These are devices that perform false-basestation attacks on cellular networks, including man-in-the-middle call interception. Here's an example of one.

First, I wrote software for IMSI-catchers in the past. That is now a matter of public record.

Second, the GSM protocol operations of an IMSI-catcher are not trade secrets. The IMSI-catcher was patented by Rohde & Schwarz (R&S) in 2003 under the name "virtual basestation" and the implementation of the device is explained in this patent to a degree sufficient to allow a cellular engineer of reasonable skill to construct one, as is the standard for patent applications worldwide. Most of the patent is in German, but this recent ruling from the UK high court summarizes the R&S patent in English for a non-engineering audience. Moreover, that MMI v. CellXion ruling references an earlier published patent application from Nokia, and although I cannot find a copy of that particular document on the web, the high court clearly accepts its existence. Either way, R&S or Nokia, once something is published in a patent application, it is no longer a trade secret. So here's a quick lesson on IP law as relates to 2G-2.5G GSM IMSI-catching:

• It's no secret. There are public documents distributed by UK & EU governments that describe how to do it.
• Even if it were a secret, that secret would belong to Nokia or R&S, because they appear to have started working on that problem not long after the GSM standard was published.
• If you are selling IMSI-catchers in the UK or Europe without the blessing of R&S, you are setting yourself up for a lawsuit, with MMI v. CellXion as a precedent.

Third, I cannot build IMSI-catchers for anyone outside of a verified US government contract. So the next time some unauthorized party contacts me asking for one, I will publish your contact information in this blog.

Fourth, the most common way to build an IMSI-catcher comes directly from the R&S patent itself and is based entirely on off-the-shelf commercial equipment. Nearly any BTS or BTS simulator can be used as the basis of an IMSI-catcher.

Protocol Bugs in GSM Handsets

[Mass-produced consumer goods with software faults?!  Say it's not so!]

Nearly all GSM handsets have bugs in their protocol stacks.  If your GSM network is sufficiently complete and correct, it will not exercise those bugs to any degree that will affect service.  But the bugs are there and if you are experimenting with GSM network equipment (like these good people) you will see them.  It would be useful, informative and (now) possible for us to start a public discussion of specific bugs in specific handset models.  To that end, the old OpenBTS sourceforge wiki is offered for that purpose.  It's very much a work in progress, but I would invite anyone with first-hand GSM implementation experience to use and contribute.

The most common handset bugs I have seen are in idle-mode behavior and the handling of the TMSI.  These bugs normally do not affect service, but can represent security threats for high-profile individuals who carry the wrong phones.  Here's one example it gross detail.

A GSM subscriber is ultimately identified by IMSI.  (The IMEI, common in IS-95 and IS-136, is rarely used in GSM.)  Subscriber identities are frequently sent across the air interface in unencrypted form.  That's because encryption cannot be activated until the subscriber's identity is known.  In fact, nearly every transaction in GSM L3 begins with an uplink message that carries the mobile identity, and the LAPDm contention resolution procedure causes the network to echo that first message back verbatim.

If an attacker knows the subscriber identity associated with a person and can intercept GSM control channels, the attacker can use these open identity exchanges to track that person's movement and calling activity from cell to cell through a GSM network. An attacker could also use the IMSI for direct toll fraud in networks that do not perform authentication, which is more common that you might think in some parts of the world. To mitigate these risks, the GSM specification introduces the TMSI, an arbitrary 32-bit tag that can be used in place of the IMSI for anonymizing transactions.

Exposure of the IMSI-TMSI relationship would make the TMSI useless, so in a well managed network these two identifiers never appear in the same unencrypted transaction.  Typically, the handset will use the IMSI for an initial access, the network will then perform authentication and engage encryption, and then assign a TMSI through the encrypted channel.  All future accesses will use the TMSI.  That's what you'll see in most American and European networks, which tend to be well-managed from a security standpoint, A5/1 weaknesses aside.

Now, the TMSI is valid only in the "location area" (LA) in which it is assigned.  The LA is normally the area served by a common base station controller (BSC).  In American networks, this usually means an area with a population of 100,000 to 250,000 people.  When a handset moves to a new location area it is supposed to invalidate its TMSI, forcing the use of the IMSI on the first access in the new LA.  Why?  Because if the phone initiates access with a TMSI, that TMSI will be useless in the new LA.  The network will just have to turn around and request the IMSI in order to authenticate the handset.  When that happens, the previous IMSI-TMSI relationship is exposed, unencrypted, on the air interface.  An attacker who keeps good records of CCCH transactions over several cells can then go back and reconstruct the user's movement and pattern of calling activity in the previous LA.

So there's an example of a common handset bug with security implications.  I welcome reports of others on the new wiki.