30 October 2010

SMSC Address Caching in iPhones

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

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

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

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

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


28 October 2010

GSM Security Workshop in Lucerne

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

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

25 September 2010

The Man Burns in 341 Days

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:

  • 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.
  • Our second-generation radio worked like a champ.
  • Speech calls were limited to three minutes.
  • 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.
  • We encountered roughly 40,000 unique IMSIs. Really. We were shocked, too.
  • 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.
  • It was Tuesday before we had a stable backhaul.
  • 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.
  • 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.
  • We had about 4,000 autoprovisioned users, connected about 7,000 phone calls and processed about 50,000 text messages.

Heros of the Burn for 2010:

  • Arturo Mayorga Cerda, for setting up the tower with nothing but hand tools.
  • Jessica Burgess, for climbing the tower on the last day to connect the crane.
  • 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.

And general thanks for 2010:

  • DPW for driving and removing our anchors and for sending the boom truck to take down the tower.
  • 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.
  • Donald Kirker for on-site e-mail and SMS hacking.
  • Mark Petersen again for Asterisk support and camp photography.
  • 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.
  • Lisa Hyde for the great 3-minute warning message and our BMIR PSA, which I would like to find a copy of. (If anyone has a copy, that would be great.)
  • Jessica Burgess again for rounding up the groceries, organizing the bar and generally keeping the camp organized while we played with computers and radios.
  • Tim Bowden for loaning us the solar panels.
  • Ralf Muehlen for IP support and general moral support.
  • All of the well-wishers who stopped by the camp.

I'll add some photos later, but Donald posted a good set on the Flickr that will do nicely for now. We are already looking forward to next year.


24 August 2010

Taking it on the Road


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.

So what's new with OpenBTS at Burning Man this year?

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.

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.


(Harvind running one of the BTS units though its paces with the CMD-57.)

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.

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.

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.

A First Taste of Peru

I recently returned from the Latin American Workshop on Wireless Networks for Rural Areas 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.

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.

03 August 2010

Dieter Spaar Goes Public

Dieter Spaar has started a blog. 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 other people go out and grandstand and get a lot of attention showing off his work. I am glad to see him speaking up.

01 August 2010

The Man Burns in 35 Days

It'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 here and I'm sure I will have more to say as the project develops.

08 July 2010

Pfarrkirchen



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, Ali Gündüz posted some good ones on his blog. 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.

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.


(Workshop class session: SMS handling. Thanks to Mark P. for this photo.)

(We ate a hearty Bavarian menu, catered to the farm. Thanks to Mark P. for this photo.)

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.


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

26 April 2010

Did Anyone Else Notice That?

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

  • A5/0. No encryption at all.
  • A5/1. "Stronger" encryption. This option is supposedly provided only on basestation equipment delivered in North America and Europe.
  • A5/2. Weak encryption, exported to the rest of the world. The GSMA declared A5/2 obsolete in 2006 and mandated that it be phased out in networks and not supported in new handsets. I think.
  • A5/3. True strong encryption, being phased in for UMTS systems and proposed as an upgrade for GSM systems.
My first question for anyone who happens to be reading this: What, specifically, was the GSMA's 2006 mandate regarding A5/2? Can anyone point me to an authoritative document?

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

09 April 2010

Catch a Demo at eComm

The eComm conference 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.

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.