On my way to Taiwan for COSCUP
Tomorrow early morning I'll be on my way to Tapei/Taiwan. The main reason for
this trip is the invitation to speak at
[ /linux/conferences |
permanent link ]
Official wiki page on GSMTAP created
I've come up with GSMTAP about two years ago while working on airprobe. The goal was to have something
similar to what radiotap does in
the wifi world: A pseudo-header that adds additional information and context
that is not present in the actual message.
Initially, GSMTAP was intended to be a separate link-layer type in the pcap
file format, but this would preclude its use in real-time protocol analysis.
So I modified it to be encapsulated in UDP packets, which are sent and received
using normal UDP/IP sockets.
Over recent years, GSMTAP has not only been integrated into multiple programs
of the airprobe project, but is also understood by wireshark. OpenBTS has also decided to
adopt the format and can generate GSMTAP messages for debugging purposes.
After creating OsmocomBB, it was taught
how to generate GSMTAP messages very quickly, too.
So by now, at least when it comes to Free Software, it is definitely the
de-facto standard for capturing/transmitting and analyzing protocol messages
from the GSM air interface.
However, until now, there has never been any official "homepage" of the GSMTAP
header. This has changed now, the GSMTAP homepage is now part
of the OsmocomBB wiki.
[ /gsm |
permanent link ]
Playing more with Erlang
Last year I started to occasionally play with Erlang. People who know me as
die-hard C coder who tries to avoid C++, Java and Python wherever possible
will probably be surprised here now.
I have no intention of changing my general position on programming languages. I
don't feel comfortable using something where I don't know and/or understand the
immediate impact on how this code will be executed on the actual silicon.
However, if you have a need to play with anything that uses ASN.1, but
particularly the aligned/unaligned PER encoding variants, then it is pretty
clear that there is nothing available as Free Software that can compare to the
Erlang asn1ct/asn1rt modules.
At that time last year I was doing some rapid prototyping with the RANAP protocol,
and the progress was quite quick. I never had time to return to that project,
so it (and my Erlang skills) were left dormant.
In recent weeks, I have picked Erlang up again - again to work on ASN.1 encoded
messages: This time TCAP and MAP. While we still need the in-progress TCAP+MAP
implementation in C for OsmoSGSN, there are other tasks at hand where an
Erlang-based implementation might yield a much higher productivity.
So right now I'm working on a program that parses/decodes and iterates through
every MAP component in a TCAP message and replaces certain fields, re-encodes
the entire message and sends it off the wire. Once that is done, I think I'll
actually try to do a more complete TCAP server and implement a simplistic HLR
for OsmoSGSN testing.
[ /gsm |
permanent link ]
On the recent news items about the homebrew IMSI-catcher for 1500 USD
Some news sites seem to do very limited research and present it as big
news that you can now build an IMSI-Catcher for a budget of USD 1500,
using OpenBTS and a URSP.
Let me bring some clarity into this situation:
- Fundamentally, an IMSI-Catcher is nothing special but a GSM base station
(BTS) that is configured to the network country code (NCC) and mobile
network code (MNC) of a commercial network operator.
- In GSM, the phone has no way to authenticate and thus verify the legitimacy
of the mobile network. This is like a "rogue access point" in a open
(unencrypted/unauthenticated) WiFi network.
- Thus, anyone who has a device that can run as a GSM base station has the
ability to run an IMSI catcher.
- There are two Free Software / Open Source projects for running your own
GSM network, both have first been published in 2008: OpenBTS and OpenBSC.
- None of those two projects are intended to be used as an IMSI-Catcher but
for legitimate operation of GSM networks. However, if a user choses to
configure the NCC and MNC of a commercial operator and allow
"unknown/unregistered/unprovisioned IMSIs (SIMs) on his network, he will
effectively have an IMSI catcher.
- Such operation is in violation of spectrum usage regulations, even if you
have a valid test/experimental license, since that license does not permit
you to use somebody else's NCC/MNC.
- Furthermore, such operation is in violation of criminal law in most
jurisdictions. In Germany there is a separate offense in the criminal code,
called Paragraph 317
Stoerung von Telekommunikationsanlagen, combined with Paragraph 202b Abfangen von Daten.
- Furthermore, there are certainly civil claims to be made by the affected
operator (and its subscriber) against anyone who unlawfully operates
such a fake base station
- OpenBTS and OpenBSC, as well as the problems resulting from this fake
base station attack have been covered in a variety of conference presentations
from 2008 through today.
- Thus, there is nothing new about what has been presented at Defcon 18
Also, the theoretic basics ow how to operate an IMSI catcher are nothing new
either. There are even a number of patents covering IMSI catchers, the first
that I know of has
been patented by Rohde & Schwarz in 2003. Also, see this blog post by OpenBTS founder David Burgess on this topic.
So all that you always needed is a bit of hardware and software to send
radio waves containing messages formatted in the way how they are described
in the (equally public) GSM specifications as published by ETSI and 3GPP. Commercial, proprietary systems have existed
for a decade. From 2008 on, there is some Free / Open Source Software to
operate GSM networks. The situation remains unchanged in 2010.
So please, remember this the next time somebody is trying to tell you that
this is the latest invention since sliced bread.
[ /gsm |
permanent link ]
Dieter Spaar has started a blog
Dieter Spaar, who has been involved in
various ways with both OpenBSC and OsmocomBB has just started a blog. This is good news
and I hope this way he will get a bit more (much deserved) exposure on his
great work.
[ /gsm |
permanent link ]
GSM Denial of Service by flooding BTS with RACH requests
At Blackhat US 2010, there was a Talk
that (among other things) apparently included the subject of a RACH DoS on
GSM base stations, implemented using my Layer1 of the OsmocomBB software.
As some news sites are covering this as "news": This vulnerability has
been long known in the field and was - to the best of my knowledge - first
demonstrated to a public audience by Dieter Spaar at the Deepsec 2009
conference in November 2009. You can get his slides.
The difficult part for many years has not been to know about the possibility of
this weakness. Anyone who has read the GSM air interface specification will
inevitably see that there is a limited number of RACH slots and a limited number
of dedicated channels. Once you fill more RACH slots than the cell has dedicated
channels, and you keep re-filling them at a higher rate than the cell can expire
those dedicated channels, you have a DoS.
So rather, the difficult part was to implement it in practise, as traditionally
all GSM baseband chipsets have been extremely closed, just like the very software
(firmware) running on them. Today, starting from Q2/2010, it is very easy to
do a proof-of-concept implementation, as we have created OsmocomBB: An Open
Source baseband firmware.
Dieter Spaar's implementation predates OsmocomBB development by the better part
of a year. At that time, he had to resort to binary-patching existing proprietary
(binary-only) baseband firmware. So I think people should recognize his effort
in doing the first practical implementation of that attack.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /personal |
permanent link ]
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).
[ /linux/mobile |
permanent link ]
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?
[ /linux/mobile |
permanent link ]
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.
[ /gsm |
permanent link ]
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 ;)
[ /linux/conferences |
permanent link ]
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.
[ /personal |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /linux/gpl-violations |
permanent link ]
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.
[ /linux/gpl-violations |
permanent link ]
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...
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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!
[ /linux/conferences |
permanent link ]
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...
[ /misc |
permanent link ]
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...
[ /gsm |
permanent link ]
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.
[ /linux |
permanent link ]
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...
[ /linux/conferences |
permanent link ]
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.
[ /personal |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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!
[ /gsm |
permanent link ]