Sorry for new blog updates
I've been busy day and night, hacking away on my latest pet project in the GSM
field. In fact, it's been a long time since I've been able to dedicate so
much time and energy into one particular project, without many distractions at
all. The project is now finally looking quite promising and making nice
progress throughout the last three weeks.
If progress continues, I hope in another week I'll be able to reveal what this
is all about. I haven't felt this level of excitement since the early days of
Illusions about MagicJack at CES
Many people have pointed out the MagicJack Femtocell product that has been announced at CES. I cannot really understand the big hype and news about it. Why? read further...
On the technical side, there is hardly anything new. Using projects like
OpenBTS or OpenBSC, you can run your own GSM network and connect it to VoIP.
Sure, the retail price of the MagicJack is much lower, but that's the economics
of scale. As soon as OpenBSC support for one of the recent femtocells is done,
we also have a much lower cost solution to the same problem.
On the legal and business side, I can see many problems for MagicJack:
- To operate equipment in the GSM or 3G spectrum, you need a license. Since
a nationwide GSM operator license is very expensive in about any country of the
world, it is economically not an option. Selling the MagicJack devices without
a license and leaving the spectrum license to the user will not work, or at least
not long, since regulatory authorities and commercial operators are not going to
let anyone deploy systems that interfere with their networks.
If you keep the Operator's SIM in the phone, and use that SIM on your own
network you might at least violate the terms of services of the operator. The
SIM card normally belongs to the operator, and it is part of the users business
relationship with that operator. As such, you can not really use it with other
networks. Sure, if you do this at home with your OpenBTS/OpenBSC installation,
nobody will care. But if somebody is doing this commercially, and in a way
that affects the sale of talk time of the regular operators, again it will not
take long until the commercial operator will sue you.
Security. If you run your phone with a "foreign" SIM, you do not know the Ki
on the SIM and thus cannot do cryptographic authentication and/or encryption.
This is a big security issue. It is once again not an issue in your personal
testbed setup, but it is going to be one if you do this at large scale as a
mass market product.
So, as you can see: It's neither technically something exceptionally new,
nor is it something that has a very promising business or legal outlook. The
only way how a product like this would work is if it is authorized by the
respective operator. But why would the operator authorize something that will
take talk time away from his network and thus his revenue stream?
Planning for a GSM development board
I've finally found enough spare time to work on detailed plans for a GSM
development board. The idea here is to have a 100% open hardware design
with 100% free software that provides an inexpensive platform for GSM
Initially the focus is on having a board that can behave like a GSM cellphone,
next steps would be to have a multi-channel frequency-hopping receiver, and
finally the option of using it as a BTS.
The idea is fairly simple: Take a commercial off-the-shelf analog baseband and
RF circuit for GSM and attach it to a general purpose DSP, add some glue logic
and go ahead. But the devil is in the details:
- You want something where you can still find the parts on the market, but
which still has sufficient leaked documentation that you can write an open
source driver for it.
- The requirements for a MS and a BTS are quite different. A phone never
needs to continuously receive and transmit in all timeslots, e.g.
- The requirement for a multi-channel frequency-hopping receiver is mainly a
high number of receiver circuits, so the solution needs to scale to a larger
number of receivers.
- The analog baseband circuits often have quite obscure control interfaces
which need to be driven. Custom peripherals in programmable logic (CPLD/FPGA)
- The TDMA nature has strict timing requirements. Normal processors and
software-based mechanisms are not sufficient to trigger the required events
and their sequencing at a high enough precision.
Anyway, there is sort of a first plan now, and the next weeks and months will
be spent with refining the plans and building a first proof-of-concept
prototype. Once that has proven to work, we want to go ahead with finishing
the design for a real board, to be manufactured in sufficient quantities for
Unless you have worked in GSM phone or base station hardware design or have a
similar level of EE and DSP skills, please refrain from contacting me right
now about how to join the project. We want to focus on getting things going
first, then make a public release at a point where there is something that
works sufficiently well that we can support a larger community of developers.
2010-01-02 / 2pm CET: Radio Interview at Deutschlandradio
The German radio station Deutschlandradio Kultur has invited
Constanze Kurz (46halbe) and myself for interviews during today's Breitband
radio show. We'll be talking about the 26C3, the Chaos Computer Club and -
of course - GSM [in]security.