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.

The Terminal-State of the Telecom Industry?

Last week, I attended the OmsocomBB workshop in Berlin. Harald Welte was an excellent host and c-base was a fun venue. I got a chance to put faces to some of the names I see in email and got a much better picture of who is doing what in the world of open source cellular. I got to see Dieter Spaar show his work on writing his own RNC software for UMTS Node B equipment. It was like the early stages of OpenBSC all over again (except that the nauseating complexity of UMTS makes GSM look quaint). I finally met the Alexander Chemeris in person. And I got to spend a week in Berlin, one of my favorite cities.

One the last day of the workshop, H-Online published this article about the OpenBTS and OpenBSC, the two well-known public-release GSM projects. I assume the timing was coincidental (or maybe Jungian synchronicity?), but it was an appropriate terminus for the event.

By chance again, when I returned to California, I had a meeting with a former executive from a major cellular carrier, a big European carrier with a global reach. He told me horror stories about IMS complexity and licensing fees. He pointed me to this article about how big web service providers are buying "raw" network equipment, built to spec in Chinese factories, and then loading that equipment with their own firmware and software, usually a mix of open-source and in-house applications. This executive sees the same thing in the long-term future of telecom: commodification of hardware all the way down to the RAN head, networks based mostly on open source software and a core network protocol based on SIP but a lot simpler than current IMS attempts. In his mind, this is the inevitable "terminal state" of the telecom industry, an inevitability in which the current generation of NEPs have no place. It is a market that will be served by companies that look and work a lot more like Red Hat than like Nokia-Siemens. I see that vision too, and I see products (not projects, products) like OpenBTS and OpenBSC and yate having comfortable places in that world. If we are correct about this vision of the future, then that small gathering of hackers, freelancers and entrepreneurs in Berlin last week may have held the seeds of a revolution that will fundamentally change a multi-trillion dollar industry. That might sound very ambitious, but the software industry has seen revolutions from modest beginnings before and the telecom world is begging for this kind of disruption.

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

Fun Facts about Copyright Law

I am not a lawyer and this is not legal advice. The point of this post is to help you understand your rights well enough to know when to call a lawyer and to help avoid ambiguities that will lead to wasteful conflict later. The topic here is US copyright law, specifically as it applies to computer software written by independent contractors.

Under US law, copyright originates with the author. If you write something, you hold the copyright until it expires or until you transfer it to another party. This transfer can happen in two ways, either through an explicit transfer agreement or through a "work for hire" agreement.

The explicit transfer is easy to understand, but can suffer complications. Suppose you are an independent contractor who writes software for a living. A client hires you for a project. You have a consulting contract that states that all copyrights for the commissioned work are transferred to the client. Done. Right? Maybe, maybe not.

For example, what if the software you deliver includes a library that you wrote several years ago for which you hold copyrights? You can save yourself a lot of grief if you make it clear to your client, in the agreement and in copyright notices on the code itself, that the client will not receive copyrights to that previous work. Sure, if there's a lawsuit, you can present evidence that the prior work existed before the agreement and therefore was not commissioned by the client. That will take several months and cost several tens of thousands of dollars and even then you risk a bad outcome, even if you are in the right, since the legal process has a lot more to do with how fast you can write checks than where the facts actually fall. It is much better to make the history and status of that prior work clear before you even start. And that's just one example of the kind of thing that can go wrong.

The work-for-hire transfer is a little trickier. It really has no place in the software world. The work-for-hire concept is based on the idea that work performed as part of a master-servant relationship belongs to the master, so copyrights to works produced in such a relationship transfer automatically. In the situation of the independent software contractor there are two problems with the work-for-hire concept.

First, in today's world a master-servant relationship is usually interpreted to mean regular employment, not contracting. If you are an independent contractor or consultant, then you are probably not performing work for hire, regardless of what any contract might say. Just calling something "work for hire" in a contract does not automatically make it so.

Second, the automatic copyright assignment of a work for hire relationship does not apply to software. US copyright law transfers copyrights for certain specific classes of works if they are commission as part of a work for hire agreement. The important point, though, is that computer software is not in that list of specific classes of work. Therefore, even under a work for hire agreement, copyrights to computer software remain with the author in the absence of an explicit copyright transfer. Let's pause for a minute while all the software developers (and their managers) go look at their employment agreements.

The chances are very good that any client who is asking you to sign a consulting agreement will just assume that paying you money automatically creates a work-for-hire relationship and that such a relationship automatically applies to software. Neither of these assumptions is true and the facts of the matter, as seen by a court, may include a number of factors, such as your degree of independence in your work, how you bill the client, etc. You will probably prevail, but it would be far better to avoid the inhumane machinery of the legal process by starting with clear contract language defining the copyright status of your work.

Kestrel's standing rule for work on cellular projects is that we will hold all copyrights to all source code that we produce. That is not negotiable; either the client agrees or we refuse the job. We make this clear in our communications with clients, put it in every statement of work and print it on our quotes and invoices. Much of that code goes into OpenBTS and those copyrights are reassigned to the Free Software Foundation, which offers a whole raft of advantages that will be fodder for a future post.

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.

NDA and the Path to Servitude

I have a friend with a consulting client (who will remain unnamed) who is using a digital radio receiver (that will remain unidentified).  They are having a hell of a time getting the receiver to work for this client's application, but for a number of reasons that I won't detail here there's a strong motivation to use this particular receiver, regardless of the difficulties.

The problem appears to be in the receiver device driver.  So the client runs a test, and the receiver interface fails, and they send the results to the radio vendor.  The vendor sends back some questions about the test.  They send some answers.  The vendor recommends another test.  They try it.  The vendor asks more questions.  Since the client and the vendor are in radically different time zones, every step of this little dance takes at least a day.  This has been going on for weeks.

So I ask this friend, "Why wait for the vendor?  Why don't you just look at the source code for the device driver and fix this problem yourself?"  Damned good idea, but they don't have the source code because the interface to the radio is proprietary.  Make a nasally whining noise when you say that: proprietary.  No one is suggesting that the vendor should put everything under GPL and give it out to world in a free download.  Hell, my friend can even sign an NDA. 

Just show them the code.  I seriously doubt there's anything there he hasn't seen before.  He's worked with several of digital radio systems over the years and all of the interfaces look pretty much the same.  You have packets or frames of baseband samples.  The packets or frames are timecoded, maybe with sequence numbers, a sample clock, IRIG, SMPTE, whatever.  You've seen the G.711 steam in RTP?  Most digital radio interfaces look a lot like that.  It's the only approach that makes any sense.

On second though, to hell with the NDA.  Once anyone sees the code under NDA their careers are in mortal danger.  What's the problem?  Suppose you sign that NDA and see this proprietary interface and then go off and design another interface for another digital radio.  And since there's really only one way to build that interface that makes any sense, it will inevitably have similarities to the design you received under NDA.  You may well end up getting sued even though you've done nothing wrong.  Legally, those similarities are justified under the "merger" doctrine, but it's not like you just go stand in front of a judge and say "It's just merger, your honor."  Instead, there's a process, a process that takes many months and costs a frightful amount of money and has an uncertain outcome.  And since your ability to participate in this process is directly related to available funds (and not much else), and since if you fail to participate in the process you lose by default, you can easily get railroaded into signing away your intellectual rights to avoid personal financial ruin.  This can happen.  I've seen it happen.  No thanks.  Let them fix their own driver.

Getting back to the original problem, though, what my friend has isn't really a technical problem with the radio interface so much as a psychological problem with the vendor.  As an engineering consultant, maybe he should start charging double to deal with psychological problems.

GPL and Security Applications

It is no great secret that many intelligence gathering processes rely on the ignorance or carelessness of their targets.  That is why parties that engage in intelligence gathering are loathe to reveal the technical details of their tools.  If potential intelligence targets know the tools, they can know the limitations of those tools and take appropriate countermeasures.  Since law enforce and intelligence are (or at least should be) legitimate activities to preserve public safety, it is (arguably) in the public interest to protect information about "sources and methods."

So given that, is there a problem with using copyleft practices in an intelligence or security application?  Not really, at least not if you can trust your own customers to behave responsibly.  The key principle of copyleft open source software is that you must make your source code  available to the customers who receive your products.  That is not at all the same thing as making it available to the general public and even classified software can be copylefted if the license is drafted correctly.

For example, you could, in principle, produce classified software under a copyleft license and still be within the license and the law while delivering that software to a government customer within the same classified program.  You could, in principle, produce law enforcement products, not sellable to the general public, do so under a copyleft license and make the source code available only the the law enforcement agencies that actually buy the products.  Again, this can be fully legal and within the terms of the license.  The key concept here is that even though the end customer is free, under the license, to redistribute the work, they will do not so because of other practical and legal constraints outside of the license.  To be blunt, if you are being prosecuted for a national security violation, a lawsuit from a software vendor is the least of your worries.  Civil intellectual property law is not an appropriate tool for protecting state secrets anyway.

A Tale of Two Licenses

OpenBTS includes a partial implementation of the GSM air interface, Um, the radio link between a GSM handset and its serving basestation. (By "partial", I mean it includes the minimum set of features to support speech telephony and, in release 2.0 and later, text messaging.)

Now, before I go any further, let me say this it not legal advice. This is my best understanding of a situation based on discussions with some strong authorities in the FOSS world.

Since late September 2008, after some convincing from John Gilmore, all distributions of OpenBTS have been under GPLv3. We like GPLv3. We'd do everything under GPLv3 if we could, but that's a story for a different blog. With OpenBTS there's a catch, though. Even though GSM is a publicly available specification, it is not"open". Many essential elements of GSM are covered by patents. These patents are held by companies like Ericsson, AT&T and Alcatel and are registered in the ETSI IPR database. The current GPL distributions of OpenBTS are offered for only private experimental use, which is generally exempt from patent licensing. Furthermore, OpenBTS is presently distributed as software, not an actual, usable end product. Anyone using OpenBTS is expected to comply with all applicable laws, including patent laws.

But let's say you use OpenBTS in a complete product that provides GSM service. You got the source code under GPLv3. And you have licenses for GSM patents. And you sell your GSM product to network operators. Section 6 of GPLv3 requires that you make the source code available to your customers and Section 11 requires that you extend your GSM patent licenses to anyone to whom you distribute the source code. Because these GSM patent licenses cost money and are granted under limited terms, these requirements appear to be in conflict. (This is not a hypothetical situation, BTW.)

Thankfully, there's a loophole of sorts. Look closely at Section 6. It does not say you must distribute the source code. It just says that you must make sure that people who have your product know where to get that source code. So the key to delivering a commercial GSM system under GPLv3 is to make sure that there is at least one party to distribute the source code who

1. does not hold GSM patent licenses,
2. has up-to-date copies and
   
3. did not receive that code under GPLv3 from anyone who does hold GSM patent licenses.

Note the compound in requirement (3). A party can meet (3) by receiving the code from a party with no GSM patent licenses or by receiving the code outside of GPLv3. There are two parties in the world who have complete releases of OpenBTS who didn't get it under GPLv3: the authors (Kestrel Signal Processing, Inc.) and the Free Software Foundation, who were granted copyrights on 24 October 2008. Either party could fill the role of the distributor as long as that party does not hold GSM patent licenses.

So, here are some scenarios for equipment providers wanting to use OpenBTS:

• Kestrel distributes OpenBTS to an equipment provider under GPLv3 and then Kestrel makes the source code available to that equipment provider's customers in compliance with GPLv3. That works as long as Kestrel doesn't hold GSM patent licenses and the equipment provider does not want to add proprietary features.
• Kestrel distributes OpenBTS to an equipment provider under GPLv3 and the FSF makes the source code available to that equipment provider's customers in compliance with GPLv3. That works as long as the equipment providers' software is identical to some public release of OpenBTS. It does not work if the equipment provider wants to add proprietary features.
• Kestrel provides OpenBTS to an equipment provider under a different license that relieves the equipment provider of all GPL obligations. This would allow the equipment provider to add proprietary features to OpenBTS and operate with no ongoing reliance on Kestrel or the FSF. It is probably the option that most equipment providers would choose. This would cost money, though, since OpenBTS uses other GPL libraries that would need to be sub-licensed.

And here are some scenarios if the project founders want to get into the equipment business:

• Kestrel starts producing a complete turn-key GSM box, not just source code. Now Kestrel needs GSM patent licenses, so Kestrel no longer meets requirement (1) and can no longer distribute OpenBTS under GPLv3. But Kestrel could transfer source code to FSF let them distribute it under GPLv3 to preserve the open source project.
• Kestrels' owners set up a new, distinct company to produce and sell GSMequipment and hold the GSM patent licenses. Kestrel extends a non-GPL license to that new company. This last option preserves Kestrel's ability to release under GPLv3, but still allows the project founders to pursue the equipment business.

Is that complicated enough for everyone?

Free As In Freedom

I never used to have strong opinions about open source development. Then I got sued.

I started working as an independent consultant in late 2001. One reason I "went indy" was that I refused to ever again sign a standard engineering employment agreement that would give my someone else ownership of everything I do or think.  I would never again submit to servitude.

In my consulting work, I was careful to read NDAs. I knew not to sign "derivative works" agreements. I knew that most non-compete agreements were illegal in California. I was clear with my clients: "Your project is not the only thing I'm working on and you don't own those other things." I thought I was savvy enough to protect my intellectual freedom. I was wrong.

[...]

To avoid this situation in the future, Harvind and I now insist that any software work based on a publicly available specification be delivered under an open source license. And if a potential client refuses to do business that way?  We walk away because those people are not worth the trouble they will cause down the road.