Recently I had been invited by the Korean Open Source Software (KOSS) Law
Center to attend their 2011 KOSS conference scheduled for November 17
and 18 in Seoul, Korea.

This conference is organized by the KOSS Law Center with support by the
Korean Government (National IT Industry Promotion Agency). Its primary
purpose is to share best practises in terms of FOSS licensing, license
compliance but also FOSS community interaction within the Korean IT
industry and the public sector.

I'm happy to present on Beyond Legal Compliance - Embracing the FOSS
community, where I will outline that the primary focus should not be
on to-the-letter legal compliance, but to a proactive way of interacting
with the FOSS community. After all, collaborative development is what
FOSS is all about...

However, due to a schedule conflict with the DeepSec 2011 conference in
Vienna (where I'm giving a two-day GSM security workshop), I'm only able
to attend the second day of the KOSS conference.

We have been giving a series of successful GSM Security trainings
in-house at various operators, as well as at a variety of conferences
during the last couple of years. If you want to beef up your knowledge
on the detailed inner workings of mobile networks, with a specific focus
on security related aspects, this training might be a great opportunity.

You can register here.
Unfortunately the Early Bird discount has already expired, but you still
have a chance to book before November 2nd, after which a late booking
fee will apply.

I still remember some years ago, when Dieter and I were first working on
some code to implement the GSM protocols, which later ended up becoming
OpenBSC. A number of other developers joined the project ever since,
and we have a wide user base, from individuals over academia up to
commercial deployments. Next we did GRPS, which was another journey
into a new world. While OsmoSGSN still has some bugs here and there, it
has come a long way ever since.

In December 2010 at 27C3 I had this crazy idea of looking into yet
another communications system (TETRA). Just one week of coding later,
the first working code emerged and later became OsmocomTETRA. Again, history
repeated itself and what was started by one person became a
collaborative effort in very short time.

Finally, in July 2011, I thought it would be time for yet
another communications system: ETSI GMR, used by Thuraya. This time I
was too busy to actually write any code, but I just read specifications,
found a supplier for some equipment and got some fellow Osmocom
developers interested in it. For weeks, the IRC channel was flooded
with daily reports about progress, new measurements/traces that had been
made and about new code that had been written. About three months
later, the code is capable of demodulating, decoding, de-interleaving,
and it can give you a BCCH protocol trace in wirshark.

With this pace of progess, I wonder where we might be in yet another one
or two years. At least on my personal agenda are the following items:

Finish Erlang TCAP + MAP implementation, which will allow us to
implement a true HLR/AUC and finally a new MSC that can interoperate
with GSM/3G core networks

Integrate OpenBSC and OpenBTS, especially now that we already have
the BTS-side A-bis implementation as part of osmo-bts

Get funding to implement a GPRS/EDGE PCU, enabling osmo-bts to talk
to OsmoSGSN

Work on some hardware+software interface that allows us to use the
Motorola Horizon Macro BTS with OpenBSC, or at least their TRXs (called CTU) with
osmo-bts

Implement a UMA/GAN gateway (for UMA capable phones and femtocells)

Support IuCS/IuPS from our MSC and SGSN for 3G Femtocells

Complete the SIMtrace firmware/software to do full MITM and SIM card
emulation

Work on automated regression testing for osmo-bts, OpenBSC, OsmoSGSN
and all other GSM related Osmocom components.

Continue the excellent work that has been done on supporting MTK
chipsets from OsmocomBB at some point

At least now you know there is never any reason to be bored. If you
have time and are interested in helping with implementing any of this
stuff, let me know.

Team FOSS.in has announced lest year that the successful series of FOSS.in conferences has concluded. I'm still
a bit sad that I was unable to make it to the grand finale.

But now, the very same team announces
a new event called PRODUCTISE.in, with a different focus. It's not
about Free and Open Source Software anymore, but about product
developers - where the respective products of course could be FOSS
based.

I remain curios to see what will happen to the event. Everyone who
knows me knows that I'm probably a slightly pragmatic but otherwise
orthodox Free Software fellow. As far as I can tell, the only
proprietary software that I use (and license) in more than a decade is
IDA Advanced.

But in any case, all the best to Team FOSS.in with their latest
endeavour!

While we at OsmocomTETRA
have been looking only at implementing the TETRA protocols as
they are (and doing a bit of sniffing on unencrypted networks),
some researchers have recently published two ground-breaking papers on
the (lack of) security in the APCO P25 radio system.

In case you haven't heard about APCO P25: It is a digital mobile radio
system mainly used by Police in non-EU English speaking countries like
the US, Australia and New Zealand.

So apparently P25 uses either single-DES or a proprietary cipher with
only 40 bit key-length. No, I'm not joking. Seems like it was
developed by people who have not the slightest clue about communications
security at all.

And guess what they used to receive and transmit P25 waveforms? Of
course the USRP and gnuradio. This once again proves how invaluable
those tools are, not just for the FOSS community, but also for the
communications research community.

In the last two months I barely found time to update this blog. I'm now
back on track and will try to update the blog more frequently.

The CCC Camp 2011 has been
great, and the OpenBSC based camp GSM network has
been a success, despite some initial problems. Thanks again to everyone
helping with the build-up and operation of it, and thanks for all our
volunteer users/testers.

Most of the time since I've been buried alive in work, almost
exclusively related to various sub-projects surrounding the Osmocom GSM
protocol implementations. We're working on every level of the protocol
stack at the same time, and on network elements from BTS, BSC up well
into the core network, media gateways, etc.

Germany has laws for everything, including batteries (Batteriegesetz).

In order to be able to e.g. import products with batteries from outside
the EU and sell them inside Germany (or the EU), you need to be
registered as a battery manufacturer/importer. You also need to become
member of one of the registered/accredited companies that take care of
recycling the batteries (i.e. put small boxes in supermarkets where
people can put their old batteries).

What's funny is that there is absolutely no lower boundary for that for
small businesses. What that means for my company: I need to pay 1
Eurocent for each LiIon powered mobile phone to that recycling company.

I guess at current estimated volume, we will have to pay something like
1 to 2 EUR every year. The recycling company won't even send us an
invoice if the amount is

So all this comes down is an exercise in buerocracy. We need to send a
monthly report on the quantities every month, and there's a hard
deadline that needs to be followed.

Furthermore, we need to put fancy stickers on each of the battery,
covering at least 3% of the battery surface. That means opening every
box, removing the battery from packaging, putting the sticker on it and
re-packaging the box. Modern batteries normally have the symbol printed
by the manufacturer, but we're talking about Motorola C1xx phones that
have been produced from 2005 to 2008 here.

I certainly don't object to manufacturers or importers having to pay for
the recycling. But if recycling is actually that cheap, and we're
talking about single-digit EUR amounts per year, the administrative
overhead (time needed for making the monthly reports, putting
stickers on the batteries, etc) costs something like 100 times the
actual recycling cost. Is that really worth it? Why not have a lower
threshold for small businesses?

At the CCC Camp 2011,
the Osmocom SIMtrace project
was a major success. Not only were something like 60 units out of our
initial batch of 100 units sold, but the SIMtrace workshop was so
successful that it had to be held three times instead of once.

During the workshop we discovered a very annoying bug which I wasn't
able to solve immediately. Depending on the combination of
phone/simcard used, the SIMtrace would disconnect from USB and the phone
would claim there is no SIM card inserted.

The debugging went like this:

SIMtrace was resetting very early in/after the ATR

the reset reason was diagnosed as being a watchdog reset

the watchdog was triggered by an IRQ storm from the USART

the IRQ storm was caused by the firmware not clearing some parity
error / overrun related bits

However, at that point I couldn't further find the cause of the bug. I
assumed it was related to the PPS/PTS, but couldn't really point my
finger at it. If we sniff the PPS/PTS wrong, then of course our baud
rate is different from the real baud rate, which in turn would cause
perceived parity errors and the like.

I'm grateful that most people still didn't loose their interest in
simtrace and happily bought the unit and/or attended the workshop.

After a bit more debugging after the camp, I have now solved the bug.
I simply never realized that the TCK (ATR checksum byte) is only present
in cards that support T=1 as well as T=0. However, some simpler SIM
cards like the ones that we issued for our test GSM network on the camp
only do T=0 and thus don't transmit TCK.

The old code thus considered the first PTS/PPS byte (0xff) as the TCK,
and didn't recognize the PTS/PPS correctly.

During the past weeks, I've been trying very hard to get to a technical
solution for the setup regarding the private GSM network that we intend
to operate at the CCC Camp
2011. Unfortunately, despite puting in way too much time that I
don't have, no really good solution appeared. There were times when I
was wondering if it would happen at all - mainly due to the lack of
properly integrated / tested RF related issues like PA, LNA, duplexer,
combiner, etc.

But it seems just in time Dieter came to the rescue. So now we have
pretty much figured out the equipment and settled on a configuration.
We'll have 2 Nokia Metrosite BTS with a total of 5 TRX, each running at
5W using borrowed equipment.

During the next 10 days, all the parts like antennas, cabling, plugs,
adapters and the BTS units themselves should arrive at my place. Let's
hope there are no serious fuck-ups that cause something to not arrive
in time.

So all in all, there's a 99% chance we will have a functional GSM
network. The Nokia A-bis support in OpenBSC will be brand new, so there
might be some glitches here and there. But then, that's part of the
fun. I'm already very curious to see what kind of coverage we get. I
guess if we do things right, it should reach well into Finowfurt itself,
and not just barely cover the camp grounds like we had at HAR 2009.

make yourself dependent from a private company to supply essential
infrastructure

introduce single points of failure (technically, administratively)
previously, you had 800 data centers, maybe each of them not as reliable
as the advertisements of the cloud provider - but it is unlikely that
all of them go down at the same time

give up control over who physically owns and has access to the data
In fact, you will have a hard time even finding anyone at all who can
tell you where your data is physically located. Maybe even out of the
country?

Now you can argue that all those things can be put down in contracts as
service level agreements (SLAs). That's true, but as we say around
here: Paper is patient, meaning no paper is going to help you
after data has been copied or was lost, and if you suddenly fail to
provide basic services of the public administration.

The distributed nature of self-hosting your data and applications has
key advantages in terms of security and reliability. Why would somebody
give that up without a broad discussion? And we're not talking about
some private company where nobody but their shareholders care if they
loose data or go out of business. We're talking about the public
administration here.

People seem to have lost perspective on the overall advantages of a
heterogeneous, distributed setup.