tag:blogger.com,1999:blog-31250868538998980042024-02-06T20:24:50.470-08:00The OpenBTS ChroniclesThe adventures of the OpenBTS project, flattening the cellular core network.David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.comBlogger75125tag:blogger.com,1999:blog-3125086853899898004.post-60333882052298060062014-02-10T06:12:00.001-08:002015-02-27T08:13:08.777-08:00One Last Word...Since OpenBTS is a trademark of Range Networks, and since I am no longer at Range Networks, I do not use this blog anymore. I am now at <a href="http://blog.yate.ro/">blog.yate.ro</a>. See you there!David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com0tag:blogger.com,1999:blog-3125086853899898004.post-31669758758498810242013-05-27T23:41:00.001-07:002013-05-27T23:41:58.106-07:00Return to PfarrkirchenThree years ago, we ran an <a href="http://openbts.blogspot.com/2010/07/pfarrkirchen.html" target="_blank">OpenBTS workshop in Pfarrkirchen</a>, hosted by Dieter Spaar at his farm there. Everyone in attendance had a great time, learned a lot about GSM and OpenBTS and had some good opportunities to meet other OpenBTS users from around the world.<br />
<br />
We are doing it again at the end of June. For more <a href="http://www.rangenetworks.com/products/openbts-trainings" target="_blank">information follow this link</a>. I hope to see you there.David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com0tag:blogger.com,1999:blog-3125086853899898004.post-20526877116641580022013-04-11T15:09:00.005-07:002013-04-11T15:18:23.271-07:00Range and SS7Ware at CCA<a href="http://www.rangenetworks,com" target="_blank">Range Networks </a>and <a href="http://www.ss7ware.com/" target="_blank">SS7Ware</a> will be presenting their One Core Network solution for mobile networks, based on OpenBTS and Yate, at the <a href="http://competitivecarriers.org/" target="_blank">Competitive Carriers Association</a> Expo, 17-19 April in New Orleans.<br />
<br />
<span style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);">The Open Core Network is the first flexibile, scalable and affordable solution for mobile carriers in rural areas, both for new networks and for expansion of existing networks.</span> Come see us at booth #137. <span style="background-color: rgba(255, 255, 255, 0);">If you would like to meet with them please contact </span><span style="background-color: rgba(255, 255, 255, 0);">info @ </span><a href="http://rangenetworks.com/" x-apple-data-detectors-result="0" x-apple-data-detectors-type="link" x-apple-data-detectors="true">rangenetworks.com</a> or office @ ss7ware.com.<br />
<br />
<br />David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com0tag:blogger.com,1999:blog-3125086853899898004.post-66659998170769388162013-02-12T09:01:00.000-08:002013-02-12T09:05:14.392-08:00See You in Barcelona<span class="Apple-style-span" style="font-family: inherit;"><br /></span>
<br />
<div style="-webkit-text-size-adjust: auto; line-height: 24px;">
<span class="Apple-style-span" style="font-family: inherit;">OpenBTS is the only open source implementation of the 3GPP GSM/GPRS and UMTS radio access network (RAN). Yate's SS7 stack is the only open source core network solution certified by Deutsche Telekom's test lab. That's a powerful combination and that's why Range Networks and SS7Ware (the new US office of Null Team) have started a development partnership to provide full cellular networks based on their products.</span></div>
<div style="-webkit-text-size-adjust: auto; line-height: 24px;">
<div>
<span class="Apple-style-span" style="font-family: inherit;"><br /></span></div>
<div>
<div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875);">
<div>
<span class="Apple-style-span" style="font-family: inherit;">One exciting result of this US-European collaboration is a unified SIP-based network that supports 2.5G GSM/GPRS, 3G UMTS and 4G LTE RANs all on the same core, simplifying the network architecture and providing a higher return on investment. The Range-SS7Ware open source approach also answers concerns over the security of RAN and core network systems by allowing network operators to inspect the source code of their network software. This combination of open standards and open source gives operators tremendous flexibility in the development of new services and represents a new vision in the deployment of cellular networks.</span></div>
</div>
</div>
<div>
<span class="Apple-style-span" style="font-family: inherit;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: inherit;">Range and SS7Ware will be in Barcelona together later this month for the Mobile World Congress. If you would like to meet with them please contact</span><br />
<span class="Apple-style-span" style="font-family: inherit;">info @ <a href="http://rangenetworks.com/" x-apple-data-detectors-result="0" x-apple-data-detectors-type="link" x-apple-data-detectors="true">rangenetworks.com</a>.</span></div>
<div>
<br /></div>
</div>
David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com9tag:blogger.com,1999:blog-3125086853899898004.post-38835986309559782902012-10-09T17:57:00.002-07:002012-10-10T10:55:26.658-07:00China, Cyberwar and your Phone Company<br />
<b>Why we are not paranoid about Huawei</b><br />
<br />
Yesterday, the House Permanent Select Committee on Intelligence published a <a href="http://intelligence.house.gov/sites/intelligence.house.gov/files/documents/Huawei-ZTE%20Investigative%20Report%20%28FINAL%29.pdf" target="_blank">watershed report</a> 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 <a href="http://www.cbsnews.com/video/watch/?id=7424702n" target="_blank">60 Minutes</a> and <a href="http://online.wsj.com/article/SB10000872396390443615804578041931689859530.html" target="_blank">The Wall Street Journal</a>. 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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDlD3FNh6HdyEyXR9WINCwQSO86A5xjMFKTTraVcT1lRp7bXP9_SB4_U7qvlRYF7OxM4ibxza1qXpXIt7xwUlD5nzqxCC05Y9ahualpDFL1Q8ANI122IUPqYnW1L0fg9bW-Xs96QpMUDCF/s1600/cover.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDlD3FNh6HdyEyXR9WINCwQSO86A5xjMFKTTraVcT1lRp7bXP9_SB4_U7qvlRYF7OxM4ibxza1qXpXIt7xwUlD5nzqxCC05Y9ahualpDFL1Q8ANI122IUPqYnW1L0fg9bW-Xs96QpMUDCF/s320/cover.jpg" width="234" /></a></div>
<br />
Such back doors are not unheard of. Although few are reported publicly, there are publicly known examples of large-scale telecom exploits, like<br />
<br />
<ul>
<li> the <a href="http://security.sdsc.edu/self-help/alcatel/alcatel-bugs.html" target="_blank">Alcatel Speed Touch ADSL modem</a> that could be reprogrammed remotely to tunnel traffic out of a LAN, or</li>
<li>the 2004 "<a href="http://spectrum.ieee.org/telecom/security/the-athens-affair/0" target="_blank">Athens Affair</a>", where an insider hacked a back door into an Ericsson lawful intercept switch, or </li>
<li>the 2010 incident when <a href="http://arstechnica.com/security/2010/11/how-china-swallowed-15-of-net-traffic-for-18-minutes/" target="_blank">roughly 15% of all IP traffic, including most of the Washington, DC area, was diverted through China Telecom for 18 minutes</a>.</li>
</ul>
<br />
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.<br />
<br />
<b>Multiple threats to US carriers</b><br />
<br />
The internet was designed with the assumption that there are malicious actors inside the network, but telephone systems are different. The <a href="http://en.wikipedia.org/wiki/Signalling_System_No._7" target="_blank">SS7 network</a>, 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 <a href="http://www.fiercewireless.com/story/report-sprint-excludes-huawei-zte-bids-network-project/2010-11-05" target="_blank">stop large companies from purchasing suspect equipment</a>, but small companies may make such purchases and not be noticed until after the fact.<br />
<br />
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.<br />
<br />
<b>Solutions</b><br />
<br />
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 <i>any</i> 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 <a href="http://wush.net/trac/rangepublic" target="_blank">OpenBTS</a> and <a href="http://yate.null.ro/pmwiki/" target="_blank">yate</a>, and projects like <a href="http://osmocom.org/" target="_blank">Osmocom</a>. Security is just one more reason that these products represent the future of telecommunications.<br />
<br />
<i>(David Burgess is the lead developer of the the OpenBTS software and co-founder and CEO of <a href="http://www.rangenetworks.com/" target="_blank">Range Networks</a>.)</i><br />
<br />
<b>Follow-up Comment</b><br />
<br />
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 <a href="http://openbts.blogspot.com/2012/04/terminal-state-of-telecom-industry.html" target="_blank">as modern systems move toward commodity hardware</a>, 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.David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com4tag:blogger.com,1999:blog-3125086853899898004.post-49873554013420264562012-10-09T16:29:00.001-07:002012-10-09T17:57:59.479-07:00I Almost Forgot...The OpenBTS test network at Burning Man was a great experience. We had a world-class team and used the unique environment of Black Rock City to run a lot of experiments, with SMS applications, yate, Tropo, and handover. The detailed results are written up at <a href="http://papalegba2012.wikispaces.com/Results" target="_blank">in the public wiki</a>, including coverage estimates, traffic statistics, photos, and links to other reports.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_GE0UI8nb8lqoRWxp4rqXdNBB_A1_JVRDWuBl3Gvai_YLaKBWW4rFgY4pP6nEpQuRHS5vHIAFro_vXWEb_Ybjrm8BNOLVFz8ZQIRFO6wxhycnp-jMzbEQwj9HIscwHj7sOpb_7FUXox17/s1600/logo.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_GE0UI8nb8lqoRWxp4rqXdNBB_A1_JVRDWuBl3Gvai_YLaKBWW4rFgY4pP6nEpQuRHS5vHIAFro_vXWEb_Ybjrm8BNOLVFz8ZQIRFO6wxhycnp-jMzbEQwj9HIscwHj7sOpb_7FUXox17/s1600/logo.jpg" /></a></div>
<br />David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com0tag:blogger.com,1999:blog-3125086853899898004.post-89730438372207582812012-08-26T16:56:00.000-07:002012-10-09T17:58:10.760-07:00Greetings from Black Rock CityA few people have asked if we would be running an OpenBTS network at Burning Man this year. Well, we are. Six of us have been here since Wednesday 22 August. We have three cell sites running and are in the process of installing two more. We are making phone calls already, but have not yet opened the network to the public. Details are <a href="http://papalegba2012.wikispaces.com/Network">here</a> and <a href="http://papalegba2012.wikispaces.com/FAQ">here</a>. These pages will be updated as the system rolls out.<br />
<br />
See you on the playa. Have a good burn.David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com2tag:blogger.com,1999:blog-3125086853899898004.post-70544919072551034422012-04-04T09:21:00.007-07:002012-04-04T09:44:59.044-07:00The Terminal-State of the Telecom Industry?<div>Last week, I attended the <a href="http://laforge.gnumonks.org/weblog/2012/03/26/">OmsocomBB workshop</a> in Berlin. Harald Welte was an excellent host and <a href="http://c-base.org/">c-base</a> 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 <a href="http://www.mirider.com/weblog/2012/02/02">writing his own RNC software for UMTS Node B equipment</a>. 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.</div><div><br /></div><div>One the last day of the workshop, H-Online published <a href="http://www.h-online.com/open/features/Building-a-GSM-network-with-open-source-1476745.html">this article</a> 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.</div><div><br /></div><div>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 <a href="http://www.wired.com/wiredenterprise/2012/03/google-microsoft-network-gear/all/1">this article</a> 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, <i>products</i>) 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.</div><div><br /></div><div><br /></div><div><div><i><span class="Apple-style-span" style="font-size:85%;">(David Burgess is a lead developer in the <a href="https://wush.net/trac/rangepublic">OpenBTS project</a> and one of the founders of <a href="http://www.rangenetworks.com/">Range Networks</a>.)</span></i></div></div><div><i><span class="Apple-style-span" style="font-size:85%;"><br /></span></i></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com2tag:blogger.com,1999:blog-3125086853899898004.post-62438857476306472222012-03-14T15:53:00.010-07:002012-03-15T23:23:02.433-07:00GMR-1 Revisited<div style="text-align: left;"><i>(Do read the comments on this one and follow Sylvain Munaut's <a href="http://pastebin.com/tr38Sy3f">link</a> for an example of a GMR Channel Request captured in the wild. Is it technically possible for an unauthorized person to rig up an public Twitter feed of who's calling whom from where on GMR-1 phones all over the world? Yes!)</i></div><div style="text-align: left;"><br /></div><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjooZsTDg10pMXAHAylEs2njaerr7M8oSsHTdCncj4eSSJ26X8qgk1Bte15wxGOUb0iESKFsKxwOIen-v-SvfxqqXjX0EIXtD8ON04LXGjbmJro9CSZSJrYfhvE5s7YeE6HXj7KoCZWQWz/s1600/ChanReq.gif" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"></a>In a recent post, <a href="http://openbts.blogspot.com/2012/02/some-comments-on-satellite-phones.html">Some Comments on Satellite Phones</a>, I stated the following: <blockquote></blockquote><div><blockquote>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.</blockquote>By "GMR" I was specifically referring to GMR-1, the technology used by Thuraya, and possibly others. There seems to be some confusion about what is and is not encrypted in these systems. Personally, I think the fact that you are transmitting an identifiable GMR signal is enough of a security problem by itself, but there seems to be a lot of interest in what is and is not encrypted in these systems, so let me be clear: The Channel Request message is the first message sent from the handset to the satellite at the start of any transaction. This message cannot be encrypted. This message typically contains the following information:</div><div><br /></div><div><ul><li>the IMSI of the satellite phone handset</li><li>the called number (in the case of mobile-originated calls) and</li><li>the GPS location of the handset.</li></ul>Don't believe me? Go look at the specification yourself. The official document is TS 101 376-4-8, GMR-1 44.008. You can get it with <a href="http://pda.etsi.org/pda/queryform.asp">this search engine</a>. The radio access procedure is defined in Section 4.3.1.3, which, BTW, starts out with</div><div><br /></div><div><blockquote>The MES shall attempt to obtain the current GPS position before sending a CHANNEL REQUEST message on the RACH. A position shall be current if less than Page GPS Position Age (Mobile Terminated (MT) calls) or GPS Position Age (other accesses) time has elapsed since it was measured. If the last measured position is not current and the Establishment Cause is not IMSI Detach, the MES shall start the RACH Position timer and initiate GPS position calculation. If the position calculation is successful, the timer shall be stopped and the newly calculated position is used. If the timer expires or the Establishment Cause is IMSI Detach, the last available position (if any) shall be used. If no position information is available, an access attempt shall be made without position information. ...</blockquote>The Channel Request message is defined in Section 10.1.8. It looks like this:</div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjooZsTDg10pMXAHAylEs2njaerr7M8oSsHTdCncj4eSSJ26X8qgk1Bte15wxGOUb0iESKFsKxwOIen-v-SvfxqqXjX0EIXtD8ON04LXGjbmJro9CSZSJrYfhvE5s7YeE6HXj7KoCZWQWz/s400/ChanReq.gif" border="0" alt="" id="BLOGGER_PHOTO_ID_5719903581079698034" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 400px; height: 307px; " /></span></div><div>The "SP/HPLMN ID" is usually an IMSI and the "Number Digits" are the dialed number and the "GPS Position" is exactly what it sounds like. This message cannot possibly be encrypted. Why? Because GMR uses symmetric encryption, so it cannot engage encryption until the network knows your identity, and it does not know your identity until <i>after</i> it decodes this message.</div><div><br /></div><div>Are we all clear on that?</div><div><br /></div><div><b>It gets better...</b></div><div><br /></div><div>In the process of nailing down all of my facts on this, I also stumbled onto the GMR-1 3G specs. While GMR-1 is modeled largely after GSM, GMR-1 3G is modeled largely after UMTS. The ETSI document number for that radio resource control specification is TS 101 376-4-13, GMR-1 3G 44.118. "RRC Connection Establishment" is defined in Section 7.5.1. The first message from the terminal to the network is "RRC CONNECTION REQUEST", defined in Section 9.2.40. But 9.2.40 just refers back to TS 101 376-4-8 GMR-1 3G 44.008 Section 10.1.4.8, "Channel Request Type 3". And guess what? That message also contains an element called "MES Position" that encodes the terminal position relative to the center of the serving beam. Again, given the secret-key encryption of GMR, this message cannot possibly be encrypted. Furthermore, the terminal will need to expose some kind of identity token in the open before encryption can start.</div><div><br /></div><div><b>And now it gets <i>really</i> interesting...</b></div><div><br /></div><div>These Channel Request messages appear on the uplink. They go from the handset to the satellite. But where do they go from there? It turns out that they just go right back down to the Earth on a different radio frequency on a so-called "feeder link". What's so special about that? Well, the uplink from the handset is only visible for a kilometer or so, but the feeder link is visible over roughly 1/3 of the planet's surface to anyone with a C-Band dish and is not given any additional encryption. (Thanks Sylvain, for pointing this out.)</div><div><br /></div><div><i><span class="Apple-style-span" style="font-size:85%;">(David Burgess is a lead developer in the <a href="https://wush.net/trac/rangepublic">OpenBTS project</a> and one of the founders of <a href="http://www.rangenetworks.com/">Range Networks</a>.)</span></i></div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com12tag:blogger.com,1999:blog-3125086853899898004.post-20709851702137144732012-02-23T08:58:00.012-08:002012-03-15T23:28:13.185-07:00Some Comments on Satellite Phones<i>(There is now a <a href="http://openbts.blogspot.com/2012/03/gmr-1-revisited.html">follow-up</a> to this post that digs into some of the details of GMR-1 transmissions. The (in)security implications are stunning.)</i><div><br /><div>With the <a href="http://www.cbsnews.com/8301-202_162-57382796/syria-violence-intensifies-amid-journalist-deaths/">recent attack on journalists by Syrian troops</a>, there has been a lot of discussion on the security of satellite phones, especially <a href="http://en.wikipedia.org/wiki/GEO-Mobile_Radio_Interface">GMR</a>, the technology used by <a href="http://www.thuraya.com/">Thuraya</a>. Here are some basic facts on the security of GMR and satellite phones in general:<div><ul><li>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.</li><li>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.</li><li>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.</li><li>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.</li><li>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.</li><li>GMR encryption is not end-to-end, so the network operator normally has access to plaintext user traffic.</li><li>GMR handsets register with the network periodically, reporting identity and location, even when you are not "using" them.</li><li>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.</li><li>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.</li><li>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.</li><li>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.</li></ul>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.</div><div><br /></div><div><i><span class="Apple-style-span" style="font-size:85%;">(David Burgess is a lead developer in the <a href="https://wush.net/trac/rangepublic">OpenBTS project</a> and one of the founders of <a href="http://www.rangenetworks.com/">Range Networks</a>.)</span></i></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div></div></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com7tag:blogger.com,1999:blog-3125086853899898004.post-24921828054561914362012-02-12T16:15:00.000-08:002012-02-19T20:21:32.024-08:00The Man Burns in 202 DaysFor those who have not heard, <a href="http://blog.burningman.com/2012/02/news/burning-man-addresses-2012-ticket-situation/">the Burning Man ticket situation for 2012 is a real mess</a>. This mess might affect our plans for the BRC test network this year. We'll just have to see what happens over the next three months.David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com3tag:blogger.com,1999:blog-3125086853899898004.post-69042722798709622812011-12-08T12:24:00.000-08:002011-12-29T13:00:23.530-08:00UMTS: Truly, you have a dizzying intellect<div style="text-align: left;">We have spent a lot of time in recent months studying the specifications for "Uu", the UMTS 3G subscriber interface. The spec is an obfuscated mess and the experts who publish books seem to disagree on a lot of critical details. In fact, the literature is so inconsistent that we are starting a <a href="https://wush.net/trac/rangepublic/wiki/DecodingUMTS">public wiki-based documentation project</a>.</div><div style="text-align: left;"><br /></div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTHXCI01ggfQVSD9MahWzGjMharF20GYRpfXPRNn5VnrpBIbRfnhjSNpixU727eFUaqtftcStjQEqPWCKwSq_5OpPJrCC38jSrNIx4zDLjWJ-vlQvqaop5oeOMhk9KvCUiKlIbPsiE9TWu/s320/UMTSCover.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5683856695376225682" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 222px; height: 320px; " /></span></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><br /></span></div><div>In its basic form (non-HSPA), UMTS can deliver 384 kb/s per channel with up to 4 such channels active at once, assuming good link margins, small delay spreads, good power control, proper phase of moon, low traffic levels in surrounding cells, and generally clean living and happy thoughts on the part of everyone involved. That's just over 1.5 Mb/s on a really, really good day. To do this, UMTS musters just about all of the fancy math that the 1990's had to offer: orthogonal spreading codes (at least, orthogonal until they hit the real world), turbo codes, rake receivers, multisensor diversity demodulators. In exchange for all of this complexity you get roughly half (yes, half) the usable bit rate that you could get from an EDGE-style PSK/TDMA interface in the same bandwidth, except that the PSK/TDMA approach would provide more solid QoS guarantees, use a lot fewer transistors and be more power-efficient due to smaller crest factors in the amplifiers.</div><div><br /></div><div>So, you might ask, why all of the new complexity if we get no performance advantage? Because simple approaches don't produce enough new intellectual property to keep the usual suspects in business. If you just take the GSM/GPRS/EDGE specification and change some parameters (like symbol rate and number of timeslots) you can get a very efficient, flexible system, but you won't have a much fodder for IEEE papers. Worse yet, you don't generate a lot of new patents, and with a lot of the patents on 2.xG systems expiring early in this decade, the NEPs needed a new gravy train. This complexity also deters small players from building their own UMTS implementations. (We have taken that as a challenge, but then we are <a href="http://www.quotationspage.com/quote/2097.html">unreasonable people</a>.)</div><div><br /></div><div>And what did UMTS do for the carriers? It nearly killed them. They overbid for the spectrum, barely had enough money left to roll out these really expensive new networks and when it was over they discovered that all their customers really wanted was better coverage and lower bills, neither of which have anything to do with UMTS. (The iPhone later proved that lack of demand for data was mostly due to the carriers' walled-garden approach to the itnernet, but that's fodder for a different post.) The killer app for the next five years turned out to be text messaging and economists got to write lots of papers saying things like "We conclude that the rationalization of bidding in the United Kingdom’s UMTS auction remains problematic." And just as the carriers are starting to recover from UMTS, the usual suspects start pushing the next shiny, new thing: LTE/IMS.</div><div><br /></div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com11tag:blogger.com,1999:blog-3125086853899898004.post-47517098807382039312011-09-06T23:09:00.000-07:002011-09-25T12:24:54.111-07:00Burning Man 2011 - Yes we were there.<div style="text-align: left;">For those who are still wondering, we did go to Burning Man. We ran a DCS1800 cellular network based on OpenBTS. We actually posted our plans a couple of months ago in a <a href="http://papalegba2011.wikispaces.com/">pubic wiki</a>, but if you don't follow Jackrabbit Speaks, the Burning Man newsletter, you probably didn't know that. This year, the network was a real collaboration. The participants were:</div><div><ul><li>Range Networks, Inc., the San Francsico-based company that actually produces commercial basestation units based on OpenBTS. (That's us!)</li><li>MedWeb, Inc., a San Francisco-based telemedicine company involved in disaster response and humanitarian projects in several countries. MedWeb provided a lot of our technical infrastructure this year, in terms of mast trucks, satellite links and power systems.</li><li>The UC Berkeley TIER group, a research group focused on information technology for humanitarian and development projects. TIER people brought some experimental applications to run on top of the OpenBTS VoIP network and also provided a lot of labor for the deployment and tear-down.</li><li>Voxeo, a VoIP services company. Voxeo provided a lot of our off-playa call routing, along with some very clever call routing services.</li></ul></div><div>The other big difference from previous years was a that we ran a 3-site network instead of a single large site, making our 2011 plan considerably more ambitious than those of previous years. This year we also supported inbound call routing for everyone using a slick "NAT for telephone numbers" trick from Voxeo. We passed out expired China Mobile SIMs so that we would avoid accidentally catching handsets from the Commnet commercial network and we passed out about 150 Nokia C1 knock-offs for people who didn't have unlocked phones. Between the SIM requirement and the use of the DCS1800 band, we were deliberately limiting the user set to people who intentionally sought out our service, avoiding a lot of the congestion problems that has set in by Thursday or Friday on previous years.</div><div><br /></div><div>So how did it go? There were the usual aggravations and delays associated with any complex operation at Burning Man, but in the end the system worked and we had about 200 provisioned users. As usual, we learned a lot along the way. A lot of information is out there already, so instead of repeating it all, I'm just going to link to some of the more meaningful existing material.<div><ul><li><a href="http://www.youtube.com/watch?v=9kkQfSHSAzA">Interview by Chris Pirillio of David and the Voxeo crew.</a></li><li><a href="http://www.youtube.com/watch?v=QTJFgDpXigc">Video of David walking through the satellite van where we ran one BTS unit and our central servers, shot by our neighbor Soft Rock Dan.</a></li><li><a href="http://www.youtube.com/watch?v=7gdgTj9Kwgg">Mark talking about the system, with occasional breakaway shots of the constant parade of people and art cars passing the camp.</a></li><li><a href="http://papalegba2011.wikispaces.com/Network">The public wiki describing the technical details of the GSM network deployment.</a></li><li><a href="http://papalegba2011.wikispaces.com/FAQ">The pre-deployment public FAQ, which tells about the groups involved and describes the services we offered.</a></li></ul></div><div>We will post some performance statistics once we are finished compiling them. We are already planning next year's system.</div></div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTLAizGRbk07nvnFKKk8JdlTY24rLjHdT5QJdGPPrLKkBTdFm8oxZgQfCKNdY9AyMlS4yQ1pQlKw8L1nJZoHBA7TtV6JfOABYXYCUtkoJa5Of1yQeP69DImUsi-5tUAGDbEYQhidtdDovY/s320/DSC_0064.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5656380028451370578" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 214px; height: 320px; " /></span></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com2tag:blogger.com,1999:blog-3125086853899898004.post-3237713354411609862011-02-08T12:41:00.000-08:002011-02-09T16:18:06.802-08:00Making GSM Future-Compatible<div style="text-align: left;">Over the last few weeks, I have been reading through the 3GPP <a href="http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem">IMS</a> specifications. IMS is the core network for next-generation 4G/LTE mobile data and telephony. Going through the specs is more like bush-whacking than reading; I still can't look at most of the network diagrams without getting dizzy. But I am starting to get a feel for it. In it's essence, IMS is a SIP core network for cellular. Granted, it still looks <i>way</i> more complicated than it needs to be to serve that function, but that's what it is.</div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlhtZCyF3r7L4DCCP9gqHfLNJaJadEOGQUNulF7Y029gCE-NjG43P7CwtPGFxoCiUTl1dZcrA2UiMxju7dUq_iruuGvXSBD8vgov4wxqOUZrbP3yC9WT6KRUeHmJoxM1IC4YRm2JpZrQuM/s320/cover.gif" border="0" alt="" id="BLOGGER_PHOTO_ID_5562529686659040946" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 221px; height: 320px; " /></span></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><br /></span></div><div>Lucky for us, one of the key ideas of OpenBTS is to also use a SIP core network for cellular. So in terms of core networks, we are about five years ahead of the industry, even if the air interface is Um or Uu. We expect the commercial release of OpenBTS to "just plug in" to IMS core networks within a few weeks. IMS compatibility has two big implications for OpenBTS moving forward.</div><div><br /></div><div>First, it means that there is an application for OpenBTS in incumbent carrier networks that are moving to 4G in the next few years. I've had the opportunity to talk to executives and network engineers from a few carriers who are planning their 4G transitions and have heard the same story over and over. Here it is: "The 4G rollout is expensive, but the performance improvements justify the cost. Except in rural areas, where the subscriber density is too low to justify the expense. But if we keep running GSM/EPGRS or 3G in those areas, then we will have to continue running the old SS7-style core network in addition to the new IMS core network. So we either waste money running two core networks or we waste money installing 4G basestations in the middle of nowhere." The OpenBTS approach offers a solution: Refit your rural sites with an inexpensive OpenBTS-based RAN and then turn off all those BSCs and MSCs.</div><div><br /></div><div>Second, it eases the minds of carriers looking at greenfield rollouts in the developing world. These carriers need inexpensive networks, but don't want to feel like they are installing obsolete technology. Installing some low-end BTS/BSC/MSC combination just because it's cheap <b>is</b> installing obsolete technology because it will saddle you with an end-of-life core network that you will need to continue to support for years. Sure, you might run your circuit-switched protocols over 802.whatever, a la SIGTRAN, but all that means is that you're not completely stupid; Abis-over-IP is <i>so</i> 1998. On the other hand, installing an IMS-compatible OpenBTS-based network is a first step toward 4G, even if the initial rollout only supports 2G handsets. When the future arrives in your corner of the world, you'll be ready.</div><div><br /></div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com11tag:blogger.com,1999:blog-3125086853899898004.post-32693101100521075762010-10-30T16:11:00.001-07:002010-10-30T17:10:41.084-07:00SMSC Address Caching in iPhonesI'm going to make one of my increasingly-rare technical posts today.<div><br /></div><div>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.</div><div><br /></div><div>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 <a href="http://www.freefonefun.co.uk/ff/free_sms_numbers.htm">provide one of your own</a>. 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 <i>to</i> a given person, these iPhones appear to send the outbound message through the same SMSC used for the most recent message received <i>from</i> 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.</div><div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com13tag:blogger.com,1999:blog-3125086853899898004.post-55087967925633216702010-10-28T16:54:00.000-07:002010-10-28T21:49:08.695-07:00GSM Security Workshop in LucerneI should have posted something about this a few weeks ago, but next week <a href="http://en.wikipedia.org/wiki/Harald_Welte">Harald Welte</a>, <a href="http://www.virginia.edu/uvatoday/newsRelease.php?id=4321">Karsten Nohl</a> and I will be presenting a <a href="http://www.hashdays.ch/workshop.html#gsmattacks">workshop on GSM security</a> at the Lucerne <a href="http://www.hashdays.ch/">Hashdays</a> 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.<div><br /></div><div>And if you are already attending, I look forward to seeing you there.</div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com1tag:blogger.com,1999:blog-3125086853899898004.post-49884402198885911102010-09-25T22:33:00.000-07:002010-09-29T21:31:30.301-07:00The Man Burns in 341 Days<div style="text-align: justify;">We returned from Burning Man over two weeks ago and are still unpacking and recovering. The skin on my hands still feels like old leather, the rebar cuts and blisters on my legs and feet are still healing and Jessica is still sorting through the boxes of dusty camping gear and surplus food in the garage. It was a weird burn; some of our friends and campmates had powerful experiences, good, bad, transformative and moving. Even a weird time in Black Rock City leaves you looking forward to next year, and reminds you that the event is more than just a big party. But that's not what brought you to this blog, so here are the technical highlights:</div><div style="text-align: justify;"><br /></div><div><ul><li>We ran a 2-sector, 5-TRX system (3/2 configuration) from a 25 m tower. We ignored RACH bursts with TA>10, limiting our range to 5 km, deliberately excluding nearby towns from the test. Our coverage footprint was roughly 80 sq-km, solid over most of Black Rock City, with the exception of some of the outer streets past 3:00 & I. We could make very good-sounding calls from the airport, Center Camp, the gates and from 9:00 & the trash fence.</li><li>Our second-generation radio worked like a champ.</li><li>Speech calls were limited to three minutes.</li><li>We powered the BTS units from a PV solar array. We had a generator, too, but that was mostly for power tools and the blender.</li><li>We encountered roughly 40,000 unique IMSIs. Really. We were shocked, too.</li><li>We had challenges, even for Burning Man. Our neighbors advised us that Mercury was in a retrograde phase, putting a kind of curse on all communications systems, but we and Papa Legba prevailed.</li><li>It was Tuesday before we had a stable backhaul.</li><li>Commnet Wireless unexpectedly came online on Thursday afternoon. Even more unexpectedly, they did so in the license block for which we had previously been cleared by Verizon. So we lost half a day double checking our license and re-coordinating spectrum with the Commnet NOC.</li><li>We had congestion on Friday and Saturday. We were running nearly twice the capacity as in 2009, but there seemed to be at least twice as many phones in the environment, maybe more.</li><li>We had about 4,000 autoprovisioned users, connected about 7,000 phone calls and processed about 50,000 text messages.</li></ul></div><div><br /></div><div>Heros of the Burn for 2010:</div><div><br /></div><div><ul><li>Arturo Mayorga Cerda, for setting up the tower with nothing but hand tools.</li><li>Jessica Burgess, for climbing the tower on the last day to connect the crane.</li><li>Mark Petersen, for staying late to help pack up the camp, even though he was ill and feeling badly and probably should have been in bed resting.</li></ul><div><br /></div><div>And general thanks for 2010:</div><div><br /></div><div><ul><li>DPW for driving and removing our anchors and for sending the boom truck to take down the tower.</li><li>John Gilmore for supporting smqueue and loaning us a switch, Christmas lights and lots of other goodies. And for bringing some interesting people to the camp.</li><li>Donald Kirker for on-site e-mail and SMS hacking.</li><li>Mark Petersen again for Asterisk support and camp photography.</li><li>Glenn Edens for staying home, manning the office and dealing with the thousands of e-mails we have been receiving as a result of recent press coverage.</li><li>Lisa Hyde for the great <a href="http://ednixon.livejournal.com/467541.html">3-minute warning message</a> and our BMIR PSA, which I would like to find a copy of. (If anyone has a copy, that would be great.)</li><li>Jessica Burgess again for rounding up the groceries, organizing the bar and generally keeping the camp organized while we played with computers and radios.</li><li>Tim Bowden for loaning us the solar panels.</li><li>Ralf Muehlen for IP support and general moral support.</li><li>All of the well-wishers who stopped by the camp.</li></ul><div><br /></div><div>I'll add some photos later, but <a href="http://www.flickr.com/photos/dkirker/sets/72157624852257522/with/4946392977/">Donald posted a good set on the Flickr</a> that will do nicely for now. We are already looking forward to next year.</div><div><br /></div></div></div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com13tag:blogger.com,1999:blog-3125086853899898004.post-19444440842278041062010-08-24T22:15:00.000-07:002010-08-24T22:51:07.331-07:00Taking it on the Road<div style="text-align: center;"><br /></div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhd_qLVY1tzilUy0OcV63BNxmGmUjvXzpcwrrC4N-DpWEdfrhKoaEkMDVyrKzn_whqgEGRtxr7LJd0ysI_Rg6xVIbuggcX8lrp_6nSdXBP0N1NY7Rjw2icKviowV8ia_PV_npcqcHLoKT8y/s1600/IMG00025-20100824-1921.jpg"></a>So my garage is full of groceries and in front of Harvind's house there's a 16' moving van loaded up with oversized tents, radio tower segments and jugs of water. It must be time for Burning Man.<div><br /></div><div>So what's new with <a href="http://pagalegba2010.wikispaces.com/">OpenBTS at Burning Man </a>this year?</div><div><br /></div><div>First, we are moving into multi-ARFCN systems. Last year, we ran a 3-sector system with 1 ARFCN per sector. This year, we will run two sectors with 3 ARFCNs per sector. So with 33% less equipment and about half as much power, we will double our capacity.</div><div><br /></div><div>Second, we are using new hardware packaging. This will be our first real-world deployment of our second generation radio. In bench testing so far, this new radio is giving considerably better performance than the old USRP + RFX hardware, and at considerably smaller size, power consumption and cost. The BTS packaging is also more compact than 2009, using a 4U rack-mount chassis similar to the one used in Niue, placed in a weatherproof travel rack recycled from thePfarrkirchen workshop. And we are running a 90' tower instead of a 70' tower, using LMR-600 instead of LMR-400. Those changes should give an effective improvement of about 3 dB in overall performance.</div><div><br /></div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhd_qLVY1tzilUy0OcV63BNxmGmUjvXzpcwrrC4N-DpWEdfrhKoaEkMDVyrKzn_whqgEGRtxr7LJd0ysI_Rg6xVIbuggcX8lrp_6nSdXBP0N1NY7Rjw2icKviowV8ia_PV_npcqcHLoKT8y/s400/IMG00025-20100824-1921.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5509217642277614018" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 400px; height: 300px; " /></span></div><div style="text-align: center;">(Harvind running one of the BTS units though its paces with the CMD-57.)</div><div style="text-align: center;"><span class="Apple-style-span" style="color:#0000EE;"><br /></span></div><div style="text-align: left;">Third, we are hoping to have the air to ourselves. We know that Commnet will not be running a portable site from Frog Pond again. We have heard that they have a fulltime site in Gerlach, but hopeful that the coverage and capacity of that site will be too small to cause a lot of the complications we experienced last year. Here's to hoping. We'll see what happens when we get there.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">Fourth, we will actually and deliberately route calls to the outside world. We have not done that before but it will probably make the system a lot more useful. We will, however, time-limit calls to prevent abuses. We will not be routing inbound calls, which will do a lot to preserve the social nature of the event.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">We hit the road tomorrow and arrive on the playa at 4:30 & G on Thursday morning. Drop by for a visit if you are in the neighborhood. Just look for the tower.</div><div style="text-align: left;"><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com11tag:blogger.com,1999:blog-3125086853899898004.post-74292571057317362512010-08-24T20:40:00.000-07:002010-08-24T22:15:01.591-07:00A First Taste of PeruI recently returned from the <a href="http://corinto.pucp.edu.pe/encuentroredes/en/telefonica-rural">Latin American Workshop on Wireless Networks</a> <a href="http://corinto.pucp.edu.pe/encuentroredes/en/telefonica-rural">for Rural Areas</a> in Ica, Peru. Due to a very tight travel schedule this month, I spent more time on airplanes and buses than at the actual workshop, but I am very glad I went. The workshop brought together researchers, regulators and carriers to discuss current barriers to rural telecommunications service and review the activities of some exciting projects, especially in Peru and Brazil.<div><br /></div><div>My stay in Peru was short but enjoyable and the workshop organizers demonstrated remarkable hospitality. My first impression is that Peru is a fascinating land, inhabited by hard-working people who are rightfully proud of their heritage. I hope to visit again.</div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com2tag:blogger.com,1999:blog-3125086853899898004.post-85670457423368570182010-08-03T10:43:00.000-07:002010-08-04T17:01:16.544-07:00Dieter Spaar Goes PublicDieter Spaar has started a <a href="http://www.mirider.com/weblog/">blog</a>. For those who don't know about Hr Spaar, he is a consulting engineer in Germany and a serious contributor to the OpenBSC and OsmocomBB projects. Using tools from those projects, along with some of his private work, Dieter sometimes does very useful experiments that reveal security shortcomings in cellular handsets and network equipment. Dieter is a modest, quiet man and sometimes <a href="http://venturebeat.com/person/the-grugq/">other people go out and grandstand and get a lot of attention showing off his work</a>. I am glad to see him speaking up.<div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com0tag:blogger.com,1999:blog-3125086853899898004.post-83174227001374159412010-08-01T15:42:00.000-07:002010-08-01T15:50:17.007-07:00The Man Burns in 35 DaysIt's that time of year again and preparations are under way for Burning Man 2010. The enclosures are at the machine shop, groceries are stacking up in the garage and we have our early arrival passes. We are posting the official public information <a href="http://pagalegba2010.wikispaces.com/PublicInformation">here</a> and I'm sure I will have more to say as the project develops.<div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com5tag:blogger.com,1999:blog-3125086853899898004.post-30923130473297549562010-07-08T08:45:00.000-07:002010-07-08T09:05:14.886-07:00Pfarrkirchen<div style="text-align: center;"><br /></div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaL0ztKdWLirMMNtgLI8uLRf-SIRWbaKlakN9OmjFlh80tfAoRKhc_Vvt_2GnaKi1nO0kGrSmd_rzERPb7b7yfO9IWOA3lXkIXaOUwZDwwPpP9r6SKCF7M8K6lJz2XBa8dZUeh_0v1gJmo/s1600/IMG_8949.JPG"></a><div style="text-align: center;"><br /></div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQOWsI-ozzOcFSJIez2QXC-h7fmI-h0C2uQDQ-tFHsriAHe-kMUtfpsuY4bfl-cDTgFpFRlBBzU0Id5cStvYKAUon17a-nwLJXkUy2ijXf3UswTltkK2sR2XRUZ3Jc9My76omF1K50hxuX/s1600/IMG_8946.JPG"></a><div style="text-align: left;">I returned from the Pfarrkirchen OpenBTS workshop just over week ago and am finally sitting down to write about it. I hope everyone enjoyed themselves and learned a lot, which certainly appeared to be the case. Dieter Spaar offered his farm for event and made excellent preparations. If you want to see some photos, <a href="http://aligunduz.org/blog/snapshots_from_gsm_workshop.html">Ali Gündüz posted some good ones on his blog</a>. We also discovered a new way to test the robustness of our mechanical packaging: Check a BTS unit onto United Airlines and see what's left of it when you get it back. Their baggage handlers managed to slam one of our cases against the ground so hard that they broke the rack-mounting tabs on our Elma 2U boxes and even damaged the internal elements of a cavity filter.</div><div><br /></div><div>The general form of the workshop was to divide the class into small teams and assign each team a "pet" OpenBTS unit to configure and hack over the next three days. The material was broken into topic-oriented sessions, starting with an overview of the physical layer and ending with a multi-BTS network carrying phone calls and text messages. The presentation style was usually 30-45 minutes of theory followed by a live demonstration or class exercise on each team's BTS. The operating area of the network was a little smaller than hoped, mostly due to mud, but there's not much than can be done to control the weather and I think everyone was understanding about that.</div><div><br /></div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQOWsI-ozzOcFSJIez2QXC-h7fmI-h0C2uQDQ-tFHsriAHe-kMUtfpsuY4bfl-cDTgFpFRlBBzU0Id5cStvYKAUon17a-nwLJXkUy2ijXf3UswTltkK2sR2XRUZ3Jc9My76omF1K50hxuX/s400/IMG_8946.JPG" border="0" alt="" id="BLOGGER_PHOTO_ID_5491565546520907362" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 400px; height: 267px; " /></span></div><div style="text-align: center;">(Workshop class session: SMS handling. Thanks to Mark P. for this photo.)</div><div style="text-align: center;"><br /></div><div style="text-align: center;"><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaL0ztKdWLirMMNtgLI8uLRf-SIRWbaKlakN9OmjFlh80tfAoRKhc_Vvt_2GnaKi1nO0kGrSmd_rzERPb7b7yfO9IWOA3lXkIXaOUwZDwwPpP9r6SKCF7M8K6lJz2XBa8dZUeh_0v1gJmo/s400/IMG_8949.JPG" border="0" alt="" id="BLOGGER_PHOTO_ID_5491566662601459954" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 400px; height: 267px; " /></span></div><div style="text-align: center;">(We ate a hearty Bavarian menu, catered to the farm. Thanks to Mark P. for this photo.)</div><div style="text-align: center;"><span class="Apple-style-span" style="color:#0000EE;"><br /></span></div><div>One of the things I appreciated most about this workshop was the collection of attendees. They came from a range of backgrounds: network operators, academics, development specialists, security specialists -- a very broad mix. Together, this group produced some really great discussions during the breaks and meals. I felt very fortunate to have met them all in person and in one place. Plus, Harald Welte and Karsten Nohl came out to the farm as well to participate in the discussions and present some short demos of OpenBSC and OsmocomBB. Harald even (unintentionally) fuzzed our systems with malformed messages from one of his test phones, something that I now plan to make part of our regular testing.</div><div><br /></div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgprpLdzetBkYKHTBuflaXZY5StcLk5ZmrZinkWIe7lzEir1O7FtpLFEnmYVgfq4pqIjVjl7BKQU6W8ZPEmzsFq7zmDJLMqOkW3Tx48vhzRDFI1p8xC2tZzbGrMkYjVcr3JIymP8ZpIA49_/s400/OpenBTS_Cell.JPG" border="0" alt="" id="BLOGGER_PHOTO_ID_5491563971718908802" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 400px; height: 336px; " /></span></div><div style="text-align: center;">(Downlink signal strength from the BTS unit used by Ali's team. See his blog for a photo of the actual unit. Thanks to Dieter for taking these measurements and making this map.)</div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com3tag:blogger.com,1999:blog-3125086853899898004.post-62168420872255981812010-04-26T19:02:00.000-07:002010-04-26T19:28:25.104-07:00Did 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:<div><br /></div><div><ul><li>A5/0. No encryption at all.</li><li>A5/1. "Stronger" encryption. This option is supposedly provided only on basestation equipment delivered in North America and Europe.</li><li>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.</li><li>A5/3. True strong encryption, being phased in for UMTS systems and proposed as an upgrade for GSM systems.</li></ul><div>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?</div><div><br /></div><div>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?</div><div><br /></div></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com18tag:blogger.com,1999:blog-3125086853899898004.post-46616782691570205032010-04-09T18:41:00.000-07:002010-04-12T19:53:49.221-07:00Catch a Demo at eCommThe <a href="http://america.ecomm.ec/">eComm conference</a> starts on April 19 in San Francisco. I'm speaking. Last year was my first year there and it was a great conference for anyone interested in future directions and new thinking in telecommunications. I met a lot of people there who turned out to be very important for the project over the next year, like Tim Panton, who was our initial contact for Niue, or Rob Ullens from Voxbone who helped sponsor our Burning Man 2009 project. I will be in more familiar company this time around, and very much looking forward to it.<div><br /></div><div>I made the first public demo of an OpenBTS node at last year's conference. But that's old news, the speakers' slots are short and I have a lot of new things to talk about. I'm bringing the equipment, so if you are at eComm and want to see an OpenBTS demo, hunt me down and we can arrange something.</div><div><br /></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com3tag:blogger.com,1999:blog-3125086853899898004.post-81990362347779292112010-03-26T19:00:00.000-07:002010-03-26T20:27:48.430-07:00Niue #11: Don't Get Me Wrong...Don't get me wrong. Despite all the whinging about IUSN, Niue was a good experience over all. Niue is one of the few unspoiled places left on Earth and it was a privilege to go there. For the most part the installation is a success. Most of the people we dealt with were competent, friendly and supportive of the project. The system is up and running. I logged in remotely this morning (with Telecom's permission) and saw some control channel activity:<div><br /></div><div><div><span class="Apple-style-span" style="font-family:'courier new';">OpenBTS> chans</span></div><div><span class="Apple-style-span" style="font-family:'courier new';">TN chan transaction UPFER RSSI TXPWR TXTA DNLEV DNBER</span></div><div><span class="Apple-style-span" style="font-family:'courier new';">TN type id pct dB dBm sym dBm pct</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"> 0 SDCCH/4-0 1804303614 0.00 -61 33 15 -102 0.00</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"> 0 SDCCH/4-1 1804303619 0.00 -58 33 8 ----- ------</span></div><div><br /></div><div>So at that moment there were two handsets on control channels at distances of roughly 7.5 km and 4.0 km, they were both transmitting at 2 W and the channels were error-free. Not bad for a prototype. We will try to do a software update later this evening to make the task of provisioning a little easier for the Telecom staff and continue to monitor performance as conditions allow.</div><div><br /></div><div>And Tim's Xorcom box finally arrived, even though Tim himself is back in the UK. Installation has been a little more hairy than expected, but it is happening. When that is complete, Telecom Niue will be able to connect calls between OpenBTS and their wireline switch, which is one more step toward a public mobile network.</div><div><br /></div><div>Yes, there are still problems and loose ends. This is a test network and nobody expects everything to be perfect at this point. We understand the problems. We have a plan. It might take a few weeks for everything to come together, but it will happen.</div><div><br /></div><div>There are plenty of technical details that I'm leaving out for now. All of that will be released when it is ready. For now, I want to thank the people who have supported this project, especially Taiichi, Frank and the people at Telecom Niue and in the government. We look forward to working with you all as this project moves forward. And I thank those people of Niue who have show patience and offered kind words, because I know you outnumber those few who were cursing and blaming. Faka'aue lahi. We will do our best for you.</div><div><br /></div></div>David A. Burgesshttp://www.blogger.com/profile/14372434100222472756noreply@blogger.com9