Harald Welte's blog

A real-world practical A5/1 attack using airprobe and Kraken

At Blackhat USA 2010, Karsten Nohl has been presenting on a practical real-world A5/1 cracking attack. For recent years, Karsten, myself and others have been speaking at various opportunities, indicating that a practical attack using readily-available information and tools from the Internet is very possible, and that it is only a matter of time for somebody actually does it.

While Karsten has focused on the actual cryptographic attack, I've been putting in some time in projects like airprobe (a GSM receiver/decoder).

Now finally, a team of friends at the new Security Research Labs (founded by Karsten) in Berlin has put the pieces of the puzzle together.

Airprobe has been extended to fully support decoding of TCH/F (FACCH, SACCH and traffic), as well as SDCCH/SACCH control channels, and to specify the timeslot and physical channel configuration from the command line. Using this, you can

decode the AGCH, wait for an IMMEDIATE ASSIGNMENT of a SDCCH
decode that very SDCCH and wait until encryption is turned on
dump an encrypted burst where you have sufficient known plaintext
use a different program to actually recover the A5/1 ciphering key
feed that key into airprobe and decrypt+decode the ASSIGNMENT COMMAND of the TCH
use airprobe to decrypt+decode that assigned TCH/F

The external program to recover the A5/1 ciphering key is called Kraken and is also available from the SRLabs website.

So what are the limitations? Well, so far this only works on non-hopping cells with a single ARFCN. The limitations are those of the receiver hardware (and SDR software), and not really limitations of the airprobe GSM decoder or the actual software tools.

In the past I would have assumed that non-hopping and/or single-ARFCN cells are rare, but in fact we can find them even inside a big city like Berlin, from at least two of the four German GSM operators. So that's why this attack is very practical, no matter what the GSMA might say.

I'm still alive ;)

In case you're wondering why there is such a long period with no updates: I've been travelling over the last week and barely had sufficient time to follow my e-mail and get the most high-priority work done. Hope to update the blog soon.

More musings on locked-down mobile phones

In recent days, the story about Motorola locking out its users (and developers) from their more recent Droid phones has made big news. As it seems, the exact functionality implemented by eFuses remains unclear, and the behavior of Motorola might thus not be too different from what has more or less become the industry standard.

For those of you who are not following the mobile world as close on a technical level as people like me do: In the last five years, more and more cellphone manufacturers have used cryptographic code signing to lock-down the software that you can run on the phone. Major parts of the system including the software update mechanism and the bootloader on the device contain a verification process of those cryptographic signatures to ensure that you can only software signed by the phone manufacturer.

I have seen this with the MotoMAGX phones like the ROKR2 v8, various Windows Mobile handhelds from HTC, The non-developer (non-ADP) version of the Google/Android G1 and many other phones.

This puts the user into a strange situation where he buys some hardware from the manufacturer, but yet doesn't have control over what this device does. Just imagine buying a computer, but being limited to run Windows 98 and Office 97 on it. You could not update to a later version of the operating system, and you could not install an alternative operating system such as a version of GNU/Linux. If the computer vendor decides that he will drop support for it, you will not even be able to install security updates to the operating system.

From my point of view, this is an abusive, anti-competitive behavior by the manufacturer. For no reason but his ever-growing hunger for power he makes you completely dependent on his decision. It is not in the control of the user, what operating system or even applications you can install. It is under the control of the manufacturer.

I would accept this if the phone was rented. In this case, I would only pay a small rental fee, but the phone is the property of the manufacturer and I am only using it. But the manufacturer actually sells the device. He wants to be paid the full price, but still not actually hand control over to the buyer.

Compare this with buying a CD-player that has arbitrary restrictions so it would only play CDs from one of the major music labels/distributors like EMI, but not CDs from any of the other publishers, for no technical reason whatsoever. Or buying a TV set that is locked down so you can only watch one TV channel, while you need to buy another TV for a different channel.

I actually think the antitrust authorities should investigate this behavior of the mobile phone industry. Simply compare it with the PC situation and look at the fact how often Microsoft has been judged in some kind of anti-competitive behavior in the PC world. In the mobile phone industry, the situation is worse than it ever was in the PC world, yet we do not see big antitrust cases being brought forward.

And please don't buy those pseudo-arguments that this has any relation to regulatory/FCC approval or the safety of mobile networks themselves. The entire software stack interacting with the mobile network runs on a separate processor (the baseband processor) anyway. It doesn't matter what you install on the application processor. Once again, compare it to laptops: You can insert a 3G miniPCI, expressCard or USB dongle. Inside this dongle you run the communications stack on a processor that is completely different from your main processor that runs your regular OS (be it GNU/Linux, OS X, Windows, Solaris or whatever makes you happy).

Motorola locking down the DroidX and Droid2 in a nasty way

There are plenty of reports in recent days about the level of locking-down that Motorola is apparently doing on their most recent Android products, the Droid 2 and the Droid X.

This goes as far as to an (I believe unconfirmed) slashdot.org report claiming that not only there is the more or less typical DRM on software (i.e. cryptographic signature validation chain), but there also is an eFuse that that is blown if something happens wrong during the booting process.

To the best of my knowledge (and I'm doing mobile phone reverse engineering for about 6 years now), this is the first time I hear of something like this. If true, it sounds pretty dangerous to me. What if something goes wrong during an update (such as a power failure during software update)? What if you really have a non-correctable multi-bit error in your NAND Flash? In that case, cryptographic verification of the firmware fails and the eFuse would be blown, resulting in your device being a brick. This could eventually backfire massively to Motorola.

The best comment from the slashdot.org thread:
You can legally buy a gun that only shoots in the direction of the person pulling the trigger, but it doesn't mean it's a good idea.

Reading something like this almost makes me very depressed. Motorola is benefitting from the billions-of-dollar-worth development of existing Free Software projects like the Linux kernel, but they now want to take away the fundamental right to run modified versions of that very software. Somebody needs to slap them with a very large trout.

I'm not really surprised that they are doing it, though. Motorola has shown that direction even years ago when they first used SELinux as part of their later pre-Android Linux phones (EZX and MAGX). They didn't use it to enhance the security of the user, but to enhance the security _from_ the user.

Please also note this great post by Bradley M. Kuhn on the subject matter. If you don't know Bradley, he's been doing GPL enforcement for the last 12 years - for the Free Software Foundation and the Software Freedom Law Center. In his post, he actually thanks Motorola to publicly state that they actually want to lock their phones down (as opposed to Apple).

What's even more interesting though is his elaboration on the scripts to control compilation and installation clause of GPLv2. This is indeed something that most people tend to overlook when it comes to GPL[v2] compliance and we see this a lot during our gpl-violations.org work.

And in fact, for a very long time, I have been teaching and educating this fact during my GPL related talks and trainings: In software specific for embedded devices, the scripts to control installation are incomplete, if you do not provide a means to install the software onto the actual device. Where else would you be reasonably install the Linux kernel image that is made specifically to work on such a particular mobile phone model? Due to the custom nature of Linux kernels for embedded targets, it wouldn't even run anywhere else.

I've never taken any such issue to court so far - but it was a frequent dispute in out-of-court GPL enforcement we've been doing at gpl-violations.org. I'm definitely curious to see what will be the first court case addressing that issue. The ever power-hungry manufacturers of mobile phones seem like they deserve it.

UPDATE:
Apparently Motorola has released some statement that denies they use eFuses to brick the device. All it does is to render the device unable to boot until some Motorola-certified/signed/authorized software is loaded on the device again. They did not specify how that could be done, though. Still, even without the eFuse bricking, I find it outrageous that the Industry (including Motorola) expect their customers pay hundreds of dollars for a device that is then still owned by Motorola rather than that very customer. It's like selling something but still retaining ownership of it. Doesn't that make you feel strange, too?

Implementing the TCAP protocol, heading towards OsmoSGSN SS7 support

The protocol by which traditional GSM core network components interact is called MAP (Mobile Application Part). MAP itself is a user of the TCAP (Transaction Capabilities Application Part) protocol, which in turn runs on a SS7 protocol stack (i.e. SCCP over MTP or M3UA or SUA over SCTP).

For those users of OpenBSC who have a need to interoperate with other GSM networks (roaming), the circuit-switched part of OpenBSC has so far relied on the use of a proprietary MSC (by means of the A interface). This closed MSC then talks MAP/TCAP/SS7 to roaming partners.

However, on the GPRS front, we now have OsmoSGSN. However, as opposed to the BSC on the circuit switched side, the SGSN directly interacts with the core GSM network components (both of the home network and the roaming partners).

So in order to run OsmoSGSN interacting with existing HLRs, we need to add a MAP/TCAP/SS7 interface to it. Once this has been done for the SGSN, we of course can do the same for the MSC-part that is currently integrated with OpenBSC.

As there are existing implementations of SCTP (inside the Linux kernel) and SUA (sualibrary), TCAP is the next step in the protocol stack that needs to be implemented. I've been digging into TCAP for the last week(s), and believe I finally understood every part of its operation.

You can think of TCAP as something that facilitates the transport of request-response type transactions over a datagram oriented transport layer. It intends to have lower overhead than a connection-oriented service (e.g. establishing TCP sessions) and supports features such as aggregating multiple user-messages (called components) in a single actual transport-layer message. The idea is to reduce the overhead of message headers and routing.

TCAP is (unfortunately) specified in ASN.1 and thus requires significant effort to parse and construct. Right now I'm using Lev Walkin's asn1c ASN.1 C code generator to generate the parser and constructor functions. The actual TCAP protocol logic is once again implemented in plain C, using the various concepts and utility functions established in OpenBSC (and now part of libosmocore).

The implementation is making good progress and I hope I can do some early testing in about a week from now, and successively move straight to the MAP protocol, implementing at least those parts that we need for GPRS authentication and attach / routing area updates.

COSCUP 2010 conference schedule has been posted

The Schedule of the COSCUP 2010 conference has been posted on the conference homepage. I'm happy to see such a large number of talks from a wide range of speakers - including many friends from my time in Taiwan a couple of years back for Openmoko...

As it seems from this chinese blog entry, the organizers were overwhelmed by the number of attendee registrations, with all 610 available seats being occupied within 85 minutes of opening the registration. It seems they are in need of a bigger venue next year ;)

Family visit is keeping me busy

In case you're expecting a quick response from me these days, please apologize. I'm currently having family visiting me in Berlin, and I very much enjoy being the personal tourist guide for some days...

I shall be back to normal by the end of the week.

Major update in OpenBSC GPRS/EDGE support

Through the last couple of days, I've been in extreme bug-squashing mode for the GPRS/EDGE code base in OpenBSC (mostly the OsmoSGSN program). I'm now at a point where I can reliably establish PDP contexts and access the Internet from a variety of different phones with different baseband chipsets and GPRS protocol stack implementations. All so-far-known bugs regarding fragmentation/reassembly, sequence numbering and other issues have been fixed. There definitely are plenty more, but we first need to find them.

Since it's working reliably now, it's quite fascinating what the various phones do after connecting to the GPRS network. Like Windows Mobile phones sending Netbios Name Service updates (and requests), which I think is funny considering that they are sent to a network that is typically considered to be the public Internet.

But to be fair and not anti-Windows, my Google/Android G1 also makes some https connections back to Google - and I don't know what they are for [yet].

In any case, with OpenBSC, OsmoSGSN and OpenGGSN anyone interested in doing true security (and privacy) research with mobile phones is now able to do so. Using those programs, you can run your own GPRS+EDGE network and can see first hand what your phones are doing on a cellular network, what kind of data they are sending back home. In this setup, there is no packet filtering, NAT, deep packet inspection and no intrusion detection systems between your PC and the IP stack on your phone.

The reason why you see paging by IMSI in real-world GSM networks

During my work on airprobe and OsmocomBB I've been wondering why you see paging by IMSI in real-world GSM networks.

A quick recap: The IMSI is the world-wide unique serial number of your SIM. Since it is easy to identify and track people, the TMSI was introduced as a temporary identifier that is frequently re-allocated over encrypted channels. The only reason for the TMSI to exist is to prevent tracking of a subscriber by watching where his IMSI appears on the paging channel.

According to the theory, the IMSI is only used when first registering to any GSM network. At that time, a TMSI is allocated to the SIM card in the phone, and this TMSI is used for the next transaction(s). Later, this TMSI is re-allocated and re-allocated, but the IMSI shouldn't show up again in any paging requests.

Even if you switch mobile networks (i.e. in the roaming case), you would once send the IMSI as part of a LOCATION UPDATE REQUEST or IDENTITY RESPONSE, but the network has no need to page the SIM by IMSI.

So far the theory. If you look at the Paging Channel (PCH) of cells in real-world networks, you see a significant (10-20%) amount of paging requests that contain paging by IMSI. This seems strange on first sight, given the theory described above.

I have the following plausible explanation for this:

The VLR keeping the IMSI-TMSI mappings doesn't have non-volatile storage. This means at a VLR restart, all the TMSI allocations will be lost, and the network has to resort to paging by IMSI.
The VLR has a limited amount of RAM, which can store a limited number of IMSI-TMSI mappings. Especially if the operator is interested in saving money, the amount of memory is insufficient for all subscribers in the network. This means, the VLR will expire some old entries in the mapping table to store new entries. Thus, mobile phones whose last transaction with the GSM network was relatively long ago are likely candidates for such VLR expiration. Once a phone for an expired entry needs to be paged again, paging will happen by IMSI.
Last, but not least: GSM networks do not page a phone by the last known cell, but by the last known location area of the phone. A location area might be relatively big. This means that at any cell you will see a lot of paging messages, even for phones that are not even anywhere near this cell. If there is no response within the location area, the MSC might decide to do paging on a larger radius, possibly the entire MSC area. Since such MSC-wide paging is likely to occur for phones that haven't shown activity for a long time (and thus might have moved or disappeared without properly unregistering from the network), those are the exact same phones for which the IMSI-TMSI mappings have expired from the VLR. Thus, the rate of paging-by-IMSI looks disproportionately high.

So the relatively high percentage of paging by IMSI vs. TMSI should not be taken as a measurement with regard to the total number of transactions or even the total number of subscribers. It is simply the mechanics of the network resulting in a distortion of those figures caused by phones that have never properly unregistered from the network.

Back from OpenBTS workshop

I've just returned back from the First OpenBTS workshop held by David Burgess and hosted by Dieter Spaar in south-east Bavaria (Germany). While I'm not involved with OpenBTS so far (except from using it occasionally), I still thought the community surrounding Free Software / Open Source in the GSM field is small enough to make me participate.

On the request of the participants, I also did a short demonstration of both OpenBSC and OsmocomBB. And just like I managed to crash OpenBTS by accidentally sending invalid messages, my OpenBSC demo crashed at some point [due to a not-yet-known bug regarding SMS delivery. I suppose the intrusive changes of the BSC/MSC split are to be blamed for that. But I don't mind, we need that split...

I definitely had a great time meeting the participants of the workshop. There definitely is a very diverse crowd with equally diverse reasons for their interest in using and/or deploying OpenBTS.

Finally, there was a chance to discuss the need for a common 'application interface' in both OpenBSC and OpenBTS. Using that interface, external applications (e.g. implementing USSD or RRLP) could be written in a way to work with both OpenBTS and OpenBSC. I hope we can get started on this soon and remove another bit of fragmentation in what is already a fairly small special interest community...

Given the excellent weather conditions, the motorbike ride to and from the venue went fine - despite being at 650 km distance from my home.

Adding frequency hopping support to OpenBSC

During the last couple of days, I've been adding the bits required to support frequency-hopping BTSs in OpenBSC. Now everything looks great in the protocol traces - but unfortunately it still doesn't work, at least not with the Siemens BS-11 that I have access to.

Will continue to try to make it work. The big advantage of having a hopping BTS under our control is that we can define the hopping sequence - something quite useful once we get to the point where we'd like to add frequency hopping to the telephone-side stack (OsmocomBB).

The good news is that I had to fix lots of bugs in the A-bis OML dissector for wireshark that I wrote some time ago. It's now much more complete and definitely a big step further towards eventually getting it included in wireshark mainline.

A fairy tale about ICCIDs, IMSIs and iPads

One of the big news of the last week is AT&T's leak of 114,000 iPad customer records including the e-mail address and ICCID

While that leak is certainly a big issue in itself, there are some people, most notably Chris Paget, who claim that this is much more serious than generally assumed. The main claim here seems to be that ...in order to translate an ICCID into an IMSI, you need to query the HLR.

I have been reading GSM protocol specifications on every level for the past years, and never have I seen the ICCID being mentioned anywhere. The GSM specifications do not require this information to be stored in the HLR, and the MAP protocol (used on the C interface between MSC and HLR, see 3GPP TS 29.002) does not even know how to encode/specify it.

Also, there is no technical need for it. The ICCID is never used nor needed in any part of the GSM protocol. Also, the GSM network typically doesn't store any information that is not absolutely necessary for its operation. The only identifier of a SIM card that the network protocols care about is the IMSI.

So unless the US operators in question have either some kind of proprietary extensions to both their HLR and the MAP protocol, there is to the best of my knowledge no way how you can relate the ICCID to the IMSI.

And thus, as a result, the IMSI-catcher attack described will not work since you don't know the IMSI of the SIM card (associated with the customer record) that you want to catch.

If anyone can show me hard technical facts about ICCIDs being used in the HLRs of the operators in question, I am happy to post here I was wrong. Otherwise, I would hope everyone else could also come down to the hard technical facts, i.e. which particular MAP message is used for this alleged ICCID-to-IMSI query.

UPDATE: As some people have discovered, the three US operators themselves have decided that they use the same number to generate both the ICCID and the IMSI. So if you have one, you can compute the other. No need for HLR access, no need for the MAP protocol. So the information leak is in fact unrelated to the GSM protocol but simply a matter of how unfortunate those particular three operators assign their unique identifiers.

More thoughts on FSF action against Apple over GNU Go

Last week, I blogged about the FSF action against Apple. This week, I intend to add a bit to that.

As it has been pointed out to me, Apple has immediately removed the GPL-infringing software from its app store. This of course means they have refrained from further infringing the GPL. It is not publicly known if they have made a declaration to cease and desist or not.

So yes, by removing the software that was distributed in violation of the GPL terms, Apple has done legally the right thing: Reduce the danger/risk of committing further (knowing) infringement.

The FSF (and probably the Free Software community in general) of course want something else: For Apple to alter their app store terms in a way that would enable software authors to have Apple distribute their GPL licensed software in it. While this might be possible very easily with small modifications to their legal terms and to the implementation of the app store, it is probably not quite easy to make a legal claim and try to force this upon Apple.

Anyone always has the choice to either distribute GPL licensed software compliant with its license terms - or not distribute it at all. If Apple prefers the latter, this is very unfortunate (and you might call it anti-social or even anti-competitive) but something that they can very well do.

The only questions that I see remaining from a legal point of view: What about the previous GPL infringements? What can (and/or has) Apple to do in return to the previous distribution of infringing software? This is where the legal pressure of the copyright holders leaves room for negotiation. Instead of monetary damages (which don't really resolve what the GPL aims to do), there could possibly be a solution where Apple has to provide the GPL license text and complete corresponding source code to the Go program through their app store. And while they're at it, they might just solve the distributing source code for copyleft style licensed software problem in a generic way. Or they might just decide that they're stupid and stubborn and not interested in solving any problems in the first place.

My take on the FSF action against Apple over GNU Go

About two weeks ago, the FSF announced that it has taken action against the Apple App Store over their distribution of GNU Go. This has apparently set off some people like lefty and triggered a length and wide debate.

I personally very much support the action the FSF has taken. Anyone involved in distribution of copyrighted material is required to do due diligence on checking that he actually has a license to do so. This is not really related to the GPL.

Yes, this means that I can take GPL enforcement action to a retail store that is selling/distributing infringing products, and I can make them provide a declaration to cease and desist from further infringements. Of course, that declaration would only be valid for this single retail store. This is why in our gpl-violations.org work, we always try to go after whatever entity is responsible for the majority or all of those infringements, rather than after a single store owner.

The reason for this is simple: In many cases, it is impossible for you as the rights holder to find out who sold the product to the retail store, and track the entire supply chain back to whoever caused the GPL violation in the first place. Also, some of those entities might reside in a different jurisdiction, so you go after the first element in the supply chain that is in your own jurisdiction, to minimize the legal risk for you as plaintiff and maximize the output in terms of your local market.

But the case with Apple is different. They are not a small retailer down the road, but the entity responsible for providing the infringing software to (almost?) all of its users. They are running that App store as a commercial company and earn money from running it (even if individual apps might be free of charge). Free Software and copyleft licenses like the GPL are a very real phenomenon in the software industry today, so they should better have thought about a proper solution, not just for GNU Go but for the tens of thousands of existing GPL licensed software projects which people might want to port or re-use in iPhone applications.

They are already doing all kinds of verification/checking/review of software for other reasons (things many people might call censoring), and as part of that process they could just as well determine the license of the software, and provide a source code download link from their store. What is the big deal? If they (or other similar app store / market / ... providers) had thought how to address the problem, there are easy and pragmatic solutions to solve them in the architecture of such a app store / marketplace system.

Also, the fact that the FSF is taking legal steps is not wrong. Even if some people might dispute whether they actually have a valid case or not (I believe they do): This is what legal cases are for: To create a clear legal situation for all participants in the dispute, and to set precedent for future similar cases. Even only from that point of view it is good that they're doing this case. At the end of it, the legal situation will be more clear, both for Apple as well as for people who want to distribute GPL licensed software through their store.

Wanted: Packet traces of the MAP+TCAP based C/Gc interface

I'm looking for any example pcap files (packet traces) of the so-called "C" and "Gc" Interfaces, i.e. the interfaces of the HLR (Home Location Register). If anyone has such pcap files or can generate some, I would very much appreciate it.

The protocol levels I'm interested in is SCCP, TCAP and MAP. The lower layers (MTP) are not important now.

Specifically, I'm looking for traces of any of the following MAP operations:

updateLocation
cancelLocation
restoreData
sendParameters
updateGprsLocation
sendAuthenticationInfo
purgeMS
sendRoutingInfo
sendRoutingInfoForSM
reportSM-DeliveryStatus
readyForSM
noteSubscriberPresent
sendRoutingInfo
anytimeInterrogation
statusReport
{register,erase,activate,deactivate,interrogate}SS
sendIMSI
sendRoutingInfoForGprs
insertSubscriberData
deleteSubscriberData
checkIMEI

If anyone is able to produce the respective traces, I would appreciate it a lot. I'd need them as examples to make sure I fully understand the TS 09.02 in combination with Q.77x before actually starting to implement it...

First functional HTTP transfer in my own GPRS/EDGE network

Today marks the day where finally, after months of (non-full-time) work, I have made the first successful HTTP connection through my own GPRS/EDGE network.

Ever since we started to seriously get into OpenBSC to run GSM networks, I've been looking forward to running GPRS networks, too. What most people don't know: GPRS is radically different from GSM. It basically only shares the frequencies and timeslot architecture of the physical layer, while having it's own layer1, layer2 and various other protocol layers. Also, its signalling and data completely bypass the usual BSC and MSC components of a GSM core network.

So what I've been working on is now called OsmoSGSN. Using OpenBSC, you can provision an ip.access nanoBTS (or any other BTS with a Gb Interface) to broadcast the GPRS/EDGE capabilities to the handsets. The BTS then establishes the Gb interface (consisting of NS and BSSGP) to the SGSN.

The SGSN takes care of GPRS Mobility Management (GMM) and Session Management(SM) in the signalling plane, as well as the LLC + SNDCP protocol layers. On the other end, it uses the GTP protocol to connect to a GGSN. In our case, this is the OpenGGSN project which I recently adopted.

OpenGGSN then creates a virtual network device (tun0), through which the actual IP packets are entering/leaving the GPRS network. From there you can route and/or NAT them just like any other IP packets.

The current code is still incomplete in many places and known to be unstable. But it's really rewarding that after a long time of development, layer after layer of the stack, finally actual TCP/IP can be provisioned to phones.

The code is in the current master of the openbsc git repository, but I don't think there's much point in trying it just yet. I suppose in a week from now things should be much more stable.

The Linux-Kongress 2010 CfP is about to close

The Linux-Kongress 2010 Call for Proposals is about to close.

So if you have anything interesting related to Linux that you would like to talk about at the 2010 incarnation of one of the most traditional Linux conferences, this is your last chance. There is no excuse, do it right now!

UPS sends me an invoice over 1 Euro-cent

Yesterday I received this letter from the local UPS subsidiary in Germany.

This is nothing uncommon, as I often import some electronics parts or other equipment from outside the EU, on which I need to pay customs duties and/or import VAT. In such cases, they typically collect an estimated amount as COD (cash on delivery) and then send an invoice about the difference (if any).

The funny part in this case now is: The grand total after subtracting my COD payment is EUR 0.01 - in words: One Euro-cent. They really want me to do a bank transfoer or write them a cheque over 1 cent !?!

One wonders to what grand total the expenses for the paper, printing, postage, banking transfer fees and accounting fees on the UPS side will amount to for processing something like this.

I wonder what would happen if I didn't pay that 1 cent. Would they actually try to sue me? Probably simply stop delivering packets to me, which I cannot afford and thus rather pay that single cent...

OpenGGSN Version 0.90 released

Only three weeks ago I blogged about OpenGGSN, a seemingly-abandoned Free Software implementation of the GGSN node of the GPRS core network.

Things have developed quite a bit ever since. As the original author didn't respond to any of my mails and sourceforge.net was not able to reach him either, they have approved my the 'abandoned project takeover' (APT) request.

I've now switched the project from CVS to git, removed links to the non-existing openggsn.org homepage and released version 0.90, containing nothing less than a fix for remote DoS vulnerability that was pending for more than 5 years.

So far I'm only exercising the PDP context activation/deactivation parts of OpenGGSN from OsmoSGSN (the SGSN I write as sister-project to OpenBSC), but I hope we can use OpenGGSN in a production GPRS network soon...

dfu-util release 0.1 has been announced

Back in the early days of my work at Openmoko, I had come up with the idea to use the standardized USB Device Firmware Upgrade (DFU) protocol for flashing firmware to the Neo1973 and later FreeRunner phones. This encompassed a DFU device implementation that is part of the Openmoko u-boot variant (and has meanwhile been merged in one of the u-boot successor projects) as well as a tool for the host PC called dfu-util.

Since DFU is meant to be device and vendor-agnostic, I tried to code closely to the spec. This meant that it in fact was compatible to other devices, and some folks e.g. used it to flash firmware into their USB-Bluetooth controllers from CSR.

However, there never was any official information how to use dfu-util outside the context of Openmoko, and even more specifically: There never were any official releases.

Stefan Schmidt has stepped up to change this and maintain dfu-util as well as make official releases. The first such release has now been made at the new dfu-util project homepage.

I'll be presenting at COSCUP 2010 in Taiwan

I have just received the great news that my attendance of the COSCUP 2010 conference in Taiwan is now confirmed. Thanks to COSCUP for inviting me!

I'll be participating in the legal track and presenting on GPL license compliance. The exact title and abstract is not yet decided.

As usual, I'm really looking forward at any chance to visit Taiwan, and the trip this August is definitely no exception. Now I only need to decide how long I'm going to stay before/after the conference...

Heading off to Europe's largest Goth festival

Despite lots of very exciting work at this time, and a distinct lack for progress on my various 'just for fun' software/hacking projects, I'll be visiting Wave-Gotik-Treffen from tomorrow on. This means that I'll be listening to some fine music and will hopefully have a most enjoyable time offline.

Don't expect me to read or answer e-mails or get any work (paid or unpaid) until at some point Tuesday next week.

Doing even more encapsulations than the GPRS Gb interface already has

Back in October 2009, I blogged about the incredibly deep protocol stack on the GPRS Gb interface between a BSS and the SGSN.

Today I had the pleasure of implementing an even more odd variant of the Gb interface, where NS does not get encapsulated in UDP/IP/Ethernet, but in FrameRelay/GRE/IP/Ethernet. The total protocol stack thus then looks like: HTTP/TCP/IP/SNDCP/LLC/BSSGP/NS/FR/GRE/IP/Ethernet, with an optional PPP between IP and SNDCP. If anyone does the math to calculate the total protocol overhead, please let me know[...

The reason for that oddity is apparently that there are Cisco and other routers that can encapsulate Frame Relay in GRE. So using a old circuit-switched SGSN with E1 interfaces and such a router, you can convert from Frame Relay on E1 to Frame Relay on GRE/IP/Ethernet.

Both the Gb Proxy as well as the upcoming OsmoSGSN use the same NS implementation, i.e. they can now both talk NS/FR/GRE and the NS/UDP variants - even at the same time, as the encapsulation is a property of each individual NS-VC.

Back from a week of GSM/GPRS protocol coding/testing in Iceland

With only 16 hours delay (which isn't all that much considering the volcanic ash situation) I arrived back in Berlin from one week of OpenBSC software hacking, particularly on the GPRS side of things.

It was really nice to see to what extent OpenBSC software is already used at On-Waves, providing GSM and now also GPRS services to thousands of users.

My work was mostly focused on the Gb-Proxy, a multiplexer/proxy for GPRS Gb links running the NSIP (NS-over-IP) protocol. It combines elements of the idea of a network address translator with that of a proxy, combined with a little bit of packet-based routing. This really makes me feel like I'm back to packet-switched networking, which is great. Especially the fact that we use the VTY code from quagga and its interactive command line sometimes lets you forget that you're not working with classic TCP/IP routing daemons or the like ;)

Aside from that, I continued my work on the upcoming OsmoSGSN, using which we will be able to run an autonomous GPRS network with no dependency on external proprietary components. In this setup, the PCU in the BTS connects over Gb/IP to OsmoSGSN, which then talks over GTPv1 to the OpenGGSN.

Also, work was spent on an abstract rate_counter implementation (now part of libosmocore). The idea is to have a counter that will count certain events (like number of packets/bytes, number of link failures, etc), but also keep a small history about how many of those events happened in the last second, last minute, last hour and last day. There is also common code to store those counters in the database, as well as to print them on the VTY. The new counters are so far only used in the GB-Proxy, but they will soon likely be added to OpenBSC (bsc_hack) and other programs of our Free Software GSM network portfolio.

Heading for 4 days of Iceland to work on OpenBSC GPRS

Having just returned from Croatia the day before yesterday, I'm about to head on a four-day trip to Iceland, where I'll be doing some testing and bug fixing of the current OpenBSC GPRS support at On-Waves.

Zecke is also going to be there, working on other aspects of OpenBSC. This will make the trip even more fun!

CECT C3100: Not a phone, but a flashlight with integrated phone

I've seen many [mobile] phones in my life, but nothing like the CECT C3100 so far. It's made of the cheapest hard plastic, like cheap kids toys. In addition to the phone keyboard, it has a mechanical switch on its side. If you slide that switch, five powerful bright white LEDs at the top of the phone will turn the entire device into a flashlight.

However, it is one of the most basic phones with one of the older/simpler MTK baseband chips inside (MT6223). Also, as we have determined by a PCB delamination analysis, the test pads next to the MT6223 really are its ARM JTAG pins.

JTAG is something not commonly found in MTK phone designs, but it is definitely a big win for bootstrapping any system-level software such as drivers on the unit.

Right now I don't have the time to work on MT6223, we still have many issues to fix in the current Ti Calypso code. But I can't wait to find time to see if we can extend our hardware support to MTK GSM chipsets...

GPRS progress in OpenBSC

In recent weeks, I have been able to pick up my work at GPRS support for OpenBSC again. What has been done is:

Add OML support to configure nanoBTS for EDGE
Add RR (System Information) support to indicate EDGE support
Make a OpenBSC + nanoBTS setup inter-operate with an existing SGSN
Develop a proxy that can aggregate the Gb-interfaces of multiple BTS into one Gb link to a real SGSN. This way the SGSN has only one Gb link for all the cells under the control of a BSC, as opposed to one Gb link for each and every BTS

What I'm working on now is the actual SGSN implementation. The SGSN is mainly responsible for GPRS mobility management (GMM) and for terminating the Layer2 (LLC) protocol from the MS. This is very different from circuit-switched GSM, where Layer2 (LAPDm) already terminates at the BTS.

The layering stack of GPRS is a real nightmare, I am sure I have indicated this in this blog before. The Current OsmoSGSN code (available from the regular openbsc.git repository) implements the NS, BSSGP and LLC layers, as well as the basic GSM 04.08 GPRS Mobility Management messages like GPRS ATTACH/DETACH and ROUTEING AREA UPDATE. The LLC code is still somewhat limited, but for the time being it is sufficient.

What drove me crazy for a couple of days is the number of parameters that are exchanged at PDP CONTEXT ATTACH time. There are no less than 26 different quality of service (QoS) parameters negotiated (see struct gsm48_qos at the bottom of this link), each of them from a wide range of values. It's almost impossible to imagine more than 1% of all the possible combinations have ever been used in production networks. The QoS parameter negotiation works by the phone sending a list of requested parameters, to which the SGSN responds with its selected parameters. My first thought was: Lets be smart and simply echo back the QoS parameters - the phone must accept what it has requested. That didn't work either: While the QoS structure is the same in both ways, the actual values in uplink and downlink directions are encoded differently. Who on earth defines such an encoding?

Next item was the XID exchange which is at the boundary between LLC and the SNDCP (Sub-Network Dependent Convergence Protocol). It works like this: The phone proposes an endless list of parameters, which the SGSN can evaluate, and then depending on the parameter type either negotiate up or down. According to the spec, sending an empty XID response should mean "I agree with all your parameters". However, at least those phones that I tested were not happy with that. So I decided to simply send back the entire XID block to the phone. And believe it or not, as opposed to the QoS parameters, this time it even worked

So now I'm facing the implementation of the actual SNDCP-to-GTP interworking, which is nothing less but the guts of the SGSN. GTP is the protocol used on the GGSN side. At least this time, GTP is sent directly over TCP or UDP, i.e. the stacking inside the SGSN is only one layer deep, while on the Gb-interface it is four (NS,BSSGP,LLC,SNDCP).

SNDCP interacts with the GPRS Mobility Management, GPRS Session Management (both GSM 04.08 over LLC), the GTP interface to the GGSN, as well as other parts. I expect many pitfalls on the way to getting it working, and given the complexity involved I have already decided to stick much closer to the specification than I usually did with the OpenBSC work. This means properly implementing all the state machines with all their transitions, exceptions and timers. I'm sure it's going to be "fun". The good part of it is: Most of the SGSN will be re-used once we finally get around adding support for 3G/UMTS/WCDMA cells.

OpenGGSN - An open source GGSN implementation

As a friend pointed out to me at exactly the right point in time: there already is an Free implementation of a GGSN. In case you don't know what a GGSN is: It is one of the two core components of a GPRS network. So, in order to extend a OpenBSC GSM network with GPRS support, there are two components required: The SGSN (on which I'm working currently, project name OsmoSGSN), and the GGSN. Due to the good news about OpenGGSN, I'm quite confident that I will not need to implement the latter part.

OpenGGSN is not only a Free Software implementation of the GGSN, but it is also licensed under GPLv2, making it compatible with the OpenBSC codebase (which is GPLv2 or later). This means I will be able to link the OpenGGSN-provided libgtp library (implementing both sides of the GTP protocol between SGSN and GGSN) from OsmoSGSN, further reducing the amount of work required to get this working.

However, despite seeming like a fairly advanced/complete implementation of the GGSN specification: OpenGGSN seems like a project that was abandoned many years ago. The latest CVS commit is from 2005, and all of the bug fixes that people have submitted to the bug tracker have not been merged. The homepage is defunct, and the openggsn.org domain name seems to have been expired (and grabbed).

I've tried to contact the author by e-mail about his intentions for the project, let's see if there is any response. Meanwhile, I have generated a git repository from the OpenGGSN CVS repository at sourceforge and applied all the pending fixes to a local branch. See my related mailing list post for more information.

Security product technical details need to be disclosed while importing to China

According to this report at The Register, there are some new government regulations about the import of certain security products into China, including Smartcards, firewalls and routers. While importing the goods, the importer needs to submit the technical details to a government panel in order to get the import license.

However, the article claims there are no further details on what exactly needs to be disclosed. Anyone who knows more details: I'd be more than interesting to hear about them - maybe there's even an English translation of the respective law or regulation?

I think it is a most reasonable policy that a country can adopt. Security products whose operation relies on its secrecy are useless anyway. The concept of security-by-obscurity has never worked and has been proven wrong many times, e.g. in the NXP Mifare Classic, DECT cipher/authentication, GSM A5 cipher and many other proprietary encryption schemes.

The only thing the Chinese regulators are doing wrong: According to their rules, the information must be disclosed to a closed government panel. Instead, they should require such information to be published publicly, or at least to be released in full detail to all customers of the respective product.

Attending DORS/CLUC 2010 in Zagreb next week

I'm looking forward to attend DORS/CLUC 2010 in Zagreb/Croatia next week. DORS/CLUC is a small but nice event, with a group of very warm and welcoming organizers. I've been there a couple of times before and always had a very good time.

Linux-Kongress 2010: Call for Proposals closes soon

This years will mark the 17th incarnation of Linux Kongress. It is scheduled from September 21st through 24th in the city of Nürnberg (aka Nuremberg), which (as a personal side note) also happens to be the city where I was born and where I've grown up.

The Call for Proposals is out for quite some time, and will last for another month until June 1st. So if you have something exciting to talk about that is related to Linux and of technical nature: Please submit your proposal soon. Looking forward to listening to your presentation at LK2010 :)

I'll be presenting at the SSTIC 2010 conference

I've been invited (as apparently the only non-french-speaker) to present at the SSTIC 2010 conference in Rennes/France.

There will be two presentations: One about OpenBSC, the other about OsmocomBB. Both will cover the use of the respective projects in the context of doing security analysis on a GSM protocol level.

Sony faces class action lawsuit on removing the Linux support on PS3

As reported, a class action lawsuit has been filed against Sony in the US for removing the so-called Other OS feature from Playstation 3. The PS3 was originally advertised as being able to run Linux, and I know a number of people who have bought it for exactly that reason. Removing that feature after the purchase is thus significantly reducing the value of the product to many of its users.

I can only hope that this lawsuit will be successful. After I have bought a product, I own it and I decide what to do with it, not the original manufacturer. There have been somewhat related cases where Amazon removed already purchased books from the eBook readers of their customers. This is simply insane. With the ever growing power that corporations try to achieve over what their customers do or don't do, the outcome of this case might have significant importance for consumer rights in the decades to come.

The mid-term future of WebOS seems safe

After HP announced its acquisition of Palm, I think we can be sure that the mid-time future of WebOS seems quite safe. I also expect mechanically much better hardware among the devices they will ship.

However, the acquisition could also mean a shift in politics, i.e. cause the new devices to be locked down with cryptographically signed kernel images. One of the big advantages of the existing Pre and Pixi is that they are not locked down and that as a user you can take full control over the device.

Another policy that might come under re-evaluation is the relationship between the WebOS Application Market and the third-party application installers like Preware.

Lets hope the managers responsible for WebOS future realize that their chance is to be less restrictive and more open than most of the competition - including most Android devices. At least, one could hope, HP has quite some experience with Linux and the Open Source community in other areas of their business.

Chaosradio Express 151: ARM CPU Architecture (German)

I'm a bit late with this: The Chaosradio Express #151 podcast on the ARM CPU architecture has been released a week ago. I had a most pleasant experience spending about 90 minutes getting interviewed by Tim Pritlove.

I'm sorry for all the non-German-speakers. But Chaosradio Express is a German medium, made by and for German hackers :)

Working on GPRS support for OpenBSC again

This has been on my TODO list for at least the last six months or so: Growing the experimental GPRS branch of OpenBSC into something more useful.

Right now, you can use OpenBSC with a GPRS-capable BTS - but only if you have an existing SGSN to serve the Gb interface of the BTS. This somehow defeats the point. We want to offer a 'GSM network in a box' solution, where no other non-free Software is required to run a fully functional small network.

So right now I'm cleaning up the 08.16 (Network Services) Implementation, and will move my way up through the existing 08.18 (BSSGP) and LLC code that I wrote some time ago.

With some luck, in a couple of weeks we should be able to run a self-sufficient combined GSM + GPRS (+ EDGE) network out of OpenBSC.

Wikipedia discussion on deleting entry on David Miller

As you can see, Wikipedia has started a discussion on whether or not to remove the Wikipedia entry about DaveM

I think this is pretty hilarious. By now, the Linux kernel is probably running on hundreds of millions of CPUs on this planet, most of them connected to some kind of TCP/IP network. And whom do we have to thank for the quality and scalability of that TCP/IP stack inside Linux: David Miller. He's probably one of the longest-running maintainers of a subsystem that's as essential as the networking subsystem.

And this is just one of his many contributions. The SPARC and UltraSPARC port might not be as important today than they were some time ago, but they have been large contributions nonetheless. And then let's talk about operating vger.kernel.org, the central mailing list host running (among others) what is probably one of the worlds largest mailing lists: linux-kernel aka LKML.

If you think that David Miller is a notable person, then please go to this Wikipedia page and argue that his article should not be deleted.

Becoming a licensee of the Open Invention Network

As has been announced publicly, my sole proprietor company hmw-consulting has become a member of the Open Invention Network.

If you don't know what OIN is about: It's an organization creating a defensive pool of patents that may be used to deter patent aggression against what they call the Linux Environment.

New binary analysis tool for license compliance audits released

My friends at Loohuis Consulting and Opendawn have just announced the first public release of their novel binary analysis tool.

This is a modular (python) framework facilitating the audit of compiled object code. Using it, you can analyze executable code (programs/libraries) or entire filesystem images or even complete firmware images and search it for strings, symbol tables and the like. Using a corresponding knowledge base, it can match this information against information derived from software source code and thus give some indication of whether a particular source code seems to have been used to create the binary.

It doesn't do actual instruction-level analysis or any of that sort, but it can help to automatize some of the steps that a license compliance engineer so far had to do entirely manually.

Let's hope this is a successful launch and that the project will find contributors to grow beyond the initial feature-set.

Thanks to the nlnet foundation and the Linux Foundation for sponsoring this project. I'm sure it will soon become a vital tool in compliance engineering.