Modern TPMS Sensors: Let's try a DoS attack
TPMS (Tire-pressure monitoring system) sensors have been researched extensively
many years ago, they periodically transmit the tire pressure, temperature
and a unique ID which can be misused for tracking a vehicle. But there is
another aspect: modern TMPS sensors also have a receiver which is typically
used to trigger the data transmission when a new TPMS sensor is presented to
the vehicle ("learning procedure").
Here in Europe TPMS sensors usually transmit on the 433 MHz ISM band. The
receiver operates on 125 kHz, very similar to LF RFID. A simple way to make
use of the receiver is just to look for the presence of the 125 kHz carrier
and then trigger data transmission. Current sensors are usually more evolved
and use a modulated carrier which contains command packets and only if the
correct command is received data transmission is triggered.
If you already have a receiver you can do of course more than just trigger
data transmission: For example there might be support for different
commands, some sensors even allow firmware updates this way.
One such command which is typically supported is switching the sensor into
"Shipping" mode. Why would you need that? When the sensor is operating
normally it waits for motion (there is an acceleration/shock sensor inside)
and only starts periodic data transmission when the wheel is rotating. This
is used to safe battery life. When the TPMS sensor is not yet mounted in the
tire it should not react on motion, that’s why there is this "Shipping" mode.
In this mode the sensor only wakes up every few seconds and looks if there
is a 125 kHz signal, if yes it checks for a valid command, for example the
command to trigger data transmission which usually also leaves "Shipping"
mode and switches the sensor into normal operation.
This "Shipping" mode can be misused: If you can switch a TPMS sensor of a
vehicle’s wheel into "Shipping" mode the sensor will no longer transmit data
and the vehicle's tire pressure control light will go on after a while.
Just to make it clear: This warning light is annoying to the driver, it
does not affect safety of the car because the deactivated TMPS sensor has
not affected the actual tire pressure.
I have looked at a few TPMS sensors for different cars if this really works,
I choose sensors for BMW and Ford cars. Please note that most certainly
other car manufactures are affected too, mainly because there are only a
few manufactures of TPMS sensors which deliver their sensors to various
car manufactures. My choice for BMW and Ford came from the fact that I
found lots of cheap, used sensor for those cars.
Also I only looked at "OEM" sensors for BMW and Ford, which means that those
sensors are mounted by the car manufacturer. There are also so called
"Universal" sensors which are typically mounted by tire dealers, there
are some notes about them at the end of this text.
It is quite easy to build a tool for transmitting data on 125 kHz: There
is this cheap EL-50448 TMPS sensor activation tool which only transmits a
carrier without modulation. However the hardware can easily be modified
to modulate the carrier: Most of the time OOK (On-Off Keying) is used
for communication, which means that the carrier is just turned on and off.
The EL-50448 uses a power driver with an unused "enable" pin to generate
the carrier, you can use this "enable" pin to modulate the carrier. The
data rate is slow, a frequently used rate is 3900 baud. Most of the time
Manchester encoding of the data bits is used, which means that the carrier
changes twice as much (7800 changes per second). This is nothing special
and can be done with probably any microcontroller you prefer to use. The
hardware costs for such a setup are below EUR 20, the transmission range
is about 20 centimeters.
How can you find the command to switch to Shipping" mode? Brute force by
trying all possible commands is only an option if the command is short.
The reason is that the sensor only looks for the LF 125 kHz signal every
few seconds. If the command is not longer than two bytes brute force is
possible (it takes a few days), for longer commands it is impractical.
Please note that you also have to find a way to detect if the command you
send causes a reaction of the TPMS sensor, e.g. by monitoring the power
consumption of the sensor or receiving the 433 MHz data signal (which of
course only works if the command you send causes a data transmission).
Another option is looking at those TPMS tools which tire dealers and
car repair workshops use to check TPMS sensors. Some of those tools
might support switching a TPMS sensor into "Shipping" mode.
Those are the results I found (I won't go into the details to avoid misuse):
- BMW:
A certain sensor used in several car models from TPMS Sensor manufacturer
"A" can be switched into "Shipping" mode. The deactivated TPMS sensor can
be activated again with a different command. Also if the sensor detects a
fast pressure change (e.g. by inflating the tire) the sensor leaves
"Shipping" mode. The command length is four bytes so brute force is no option.
- Ford:
A certain sensor used in several car models from TPMS Sensor manufacturer
"A" (the same manufacture as above for the BMW sensor) can be switched
into "Shipping" mode, it is the same command as used by the BMW sensor
from above. The deactivated TPMS sensor can be activated again with a
different command.
A certain sensor used in several car models from TPMS Sensor manufacturer
"B" can be switched into "Shipping" mode. The deactivated TPMS sensor can
be activated again with a different command. The command in this case is
only two bytes and I tried all combinations which resulted in several more
"interesting" commands, a few examples:
-
It is possible to completely turn off the TPMS sensor. In this case it
will no longer react on anything, you have to break open the sensor
case and apply a hardware reset or disconnect the battery to reactivate
it again.
-
It is possible to switch the sensor into continuous "carrier transmit"
mode on 433 MHz. In this mode the sensor will continuously transmit
the 433 MHz carrier until the battery is empty or you apply a hardware
reset (see above), it will not react on anything else. There are two
other similar commands which transmit on the upper and lower shifted
frequency (the sensor uses FSK modulation, Frequency Shift Keying, when
transmitting data).
Those examples show that it is basically possible to destroy this specific
sensor by transmitting the appropriate command. Also if the sensor is in
"carrier transmit" mode it probably disturbs the remote control car
key fob which usually uses the same frequency as the TPMS sensor.
You have to be close to the sensor to send those LF 125 kHz signals but it
only takes a few seconds to send the signal. Using a larger antenna (which is
basically a coil) for the transmitter, e.g. large enough to fit in a suitcase,
might extend the transmission range to more than a meter.
How can those problems be avoided? This is actually quite easy, the command
to switch into "Shipping" mode should not be allowed if the measured tire
pressure is above a certain limit, which means that the sensor is mounted in
the tire of a vehicle. This also applies to those other commands of the sensor
from manufacturer "B" which are probably some kind of factory test or developer
commands. Please note that during my tests the commands I described were
possible even when the measured tire pressure was in the range of a typical
vehicle wheel.
I contacted the car manufactures (BMW and Ford) before I published this
article, this is the experience I made:
-
BMW:
The contact information for reporting security issues can be found on
the BMW website. I had a phone call with the responsible person within
a few days after reporting the issue. BMW already knew the problem, they
found it during an internal review. Their latest TPMS sensors have fixed
the issue by blocking certain commands if the tire pressure is above a
certain limit.
-
Ford:
I wasn't able to find a security contact on the website of Ford Germany
so I contacted the person responsible for "Public Relation". He promised
to look for someone who takes care of the issue I reported, after several
days I got a reply that it is possible to disturb the TPMS system due to
the nature of radio transmission and that this is a known problem. I wasn't
able to communicate directly with the responsible person and I then replied
that the reported issue is not about disturbance but a "Denial of Service"
and that it is even possible to destroy a certain TPMS sensor used in Ford
cars. I didn't receive any further information about the security issue, I
notified them again after several weeks that I am now going to publish
the issue which was acknowledged.
Some notes about those "Universal" sensors tire dealers normally use: Those
sensors are "Universal" because they can be programmed for different car
models. The main benefit for the tire dealer is that only a few different
kind of "Universal" sensors have to be on stock, it’s not necessary to have
lots of different "OEM" TPMS sensors for every possible car model lying
around. The programming of those "Universal" sensors most of time uses the
LF 125 kHz signal to transfer the programming data to the sensor. Many of
those "Universal" sensors can be reprogrammed regardless of the measured
tire pressure so an obvious "Denial of Service" attack on those sensors is
to simply reprogram them for a different car model.
[ /automotive |
permanent link ]
A Pico Base Station from Ericsson
The RBS6401 is a small indoor base station from Ericsson for WCDMA or LTE. The
device is about two times the size of an ip.access nanoBTS. It is based on
a KeyStone I SoC from TI and runs Linux (in fact there are two KeyStone I
SoCs inside, but it seems that only one of them is used, at least for WCDMA).
Compared to the other commercial base stations I have seen so far the RBS6401
makes it quite hard to get access to the operating system. It tries to setup
a VPN to a Security Gateway for Autointegration into the operator's network
and there is only a simple Web Interface to set the network parameters of
the device.
Unfortunately I have only found the WCDMA software on the three devices I have
access to. It would really be nice to use the RBS6401 with LTE, WCDMA is not
that interesting (I am not aware of any Open Source RNC). If anyone has the
LTE software for the RBS6401, please let me know.
[ /gsm |
permanent link ]
A personal remark about security research
In the last few years I have done a lot of automotive security research,
one of my findings about cars from BMW, which was the result of working
on contract for the ADAC, was published in February 2015:
the original German version
and
the translated English version.
A few days ago Tencent Keen Security Lab published their findings about BMW cars
in this paper.
While in general I find it great that there is more public research in the area
of automotive security, I really don't like it if previous work isn't respected.
The report of Tencent Keen Security Lab does not contain any reference to previous
work besides their own. I would at least have expected references to previous
QNX research (QNX is the OS used in the BMW infotainment ECU) and my work when
it comes to the TCB (Telematic Communication Box, the name of the BMW telematic
ECU). For example regarding the TCB, the description of the communication protocol
with the backend and how encrypted SMS is used, with identical encryption keys in
all cars, was already contained in my report. To find out why there are no
references to others work I contacted them, but I didn't receive any reply.
Could it be that they really aren't aware of previous work? If you start
researching the BMW telematic ECU, you would very soon become aware of NGTP
(Next Generation Telematics Protocol), the protocol used to communicate with
the BMW backend. Searching on Google for "TCB" and "NGTP" will give you the
link to the German article on the first place. OK, it's just the German article
and you would have to open it to find the link to the English translation, which
requires an additional step.
What if they don't use Google but Baidu? Searching for "TCB" and "NGTP" on
Baidu gave
this link
on the fourth place. I can't read the page, but this seems to be the Chinese
translation of the article from Heise, even the text in the diagrams is
translated. Interestingly when I tried to reproduce my search from last week
on Baidu today, this page no longer appears in the search results, although
the page itself still exists.
So for me its looks like this: Tencent Keen Security Lab either simply doesn't
give reference to previous work and follows the old Chinese tradition of "Clone
and Copy" or they don't have any clue about Information Gathering, which is
one the first steps when starting to research a target. In my opinion neither
of the two possibilities is what you really want.
[ /automotive |
permanent link ]
Communication on a FlexRay bus
FlexRay is an automotive bus system which is not as common as the CAN bus,
but is used in several car brands, e.g. BMW, Mercedes and Audi. I won't go
into the details of FlexRay, there are several good introductions elsewhere.
What is needed to read the data on a FlexRay bus, or even better, actively
participate in the communication (send your own data)? Compared to the
CAN bus a FlexRay bus is complicated:
-
Sending and receiving on a CAN bus is simple, similar to serial (UART)
communication: You basically only need to know the bus speed and you
are done.
-
For a FlexRay bus you have to know about 50 more or less important
parameters which define things like the length and number of the
frames in the static segment or the frames in the dynamic segment.
If you are only interested in seeing the data on the FlexRay bus, than it is
actually pretty simple, knowing the communication speed (typically 10 Mbit/s)
is enough. There are several oscilloscopes and logic analyzers which can
decode the FlexRay protocol. Such a decoder is simple, I use a few lines
of AWK script to process the exported CSV file from a cheap logic analyzer
to do so (AWK just to show how simple it is).
However if you also want to send data, you need to know nearly all the
parameters, otherwise you would most certainly just disturb the bus
communication. There are several (expensive) FlexRay analyzers available,
which can help to solve this problem.
I wanted to find out if it is also possible to get this done with a relatively
cheap (around 100 EUR) development board with a FlexRay interface. While I
won't go into the details (maybe this is topic for an upcoming talk), I will
just present my experimental setup:
I started with two ECUs (gateway and engine ECU) from a BMW with FlexRay.
Those two ECUs are enough for a properly running FlexRay bus (each of those
ECUs is a so called coldstart node, you need at least two of them to get
the FlexRay bus up and running). To get the development board running with
this setup you could start with coarse communication parameters (maybe
from measurements with an oscilloscope) and fine-tune them until you can
communicate (receive and send frames) without errors. This actually worked
quite well.
The next setup were several ECUs from an Audi with FlexRay: I had the gateway,
ACC radar and front camera. However only the gateway is a coldstart node, so
the FlexRay bus would not start with only those ECUs. I could have bought a
second coldstart node ECU (either ABS or airbag), however those ECUs for
this specific car are rather expensive. Additionally I wanted to see if
it is possible to program the development board as a coldstart node, so
I decided to go this way. The problem now is that you don't have a running
FlexRay bus to get your first estimation of the communication parameters:
the single coldstart node trying to start the bus will only give you a few
of them (basically you only have one frame from the static segment). The
communication parameters from the BMW won't help also, Audi uses something
else (only the 10 Mbit/s bus speed and the 5 ms cycle time are the same).
Again I skip the details, but all problems could be resolved and the
development board acts as a coldstart node to get the bus running
and of course can also properly communicate on the bus.
Lessons learned: You don't necessarily need expensive tools to solve a
problem which seems complicated on the first look. If you are willing
to spend some time, you can succeed with rather cheap equipment. The
additional benefit is that you learn a lot from such an approach.
[ /automotive |
permanent link ]
Modify the VoIP provider of a Speedport ISDN Adapter
The Speedport ISDN Adapter is a relatively cheap VoIP-to-ISDN adapter from
Deutsche Telekom. The drawback is that the adapter is "locked" to Deutsche
Telekom and the user interface (web interface) is disabled.
Here is how you can access the web interface. While the adapter is already
powered on, you have to press both the "Register" and "Reset" button at once
for more than 20 seconds. This will temporarily enable a still limited
web interface, just point your browser to the IP address of your ISDN adapter.
The login password is the "device password" written on the bottom side of the
case.
To fully enable the web interface you have to do a bit more. I use "curl" which
is available for nearly all operating systems. You have to replace "12345678"
with the device password and "192.168.1.2" with the IP address of your
adapter.
curl -d "login_pwd=1&pws=12345678" "http://192.168.1.2/cgi-bin/login.cgi"
curl -d "password=12345678&debug_enable=1&uart_tx_eb=1" "http://192.168.1.2/cgi-bin/debug.cgi"
Now the web interface is fully functional and you can modify the settings, e.g.
disable the TR-069 interface and enter the parameters for the VoIP account of your
provider. "uart_tx_eb" enables the serial console, which offers a few debug
commands. However you have to open the case to get access to the serial console.
[ /misc |
permanent link ]
More LTE Base Stations
Since running my first own LTE eNodeB in 2013, I acquired a few more. I now
have one from NSN, Ericsson and Huawei. All of them are fully functional
including the required Remote Radio Heads to actually transmit.
Operating an LTE eNodeB is not very complicated, these days it is even easier
with software like NextEPC. The tricky part is setting up and configuring the
LTE eNodeB because there is no standard to do so and every manufacturer has
its own way. If you are lucky, you might get an already configured system
and there is not much you have to adjust. If your system is new or the
configuration has been erased, than it can get complicated, at least for
the Ericsson eNodeB I have.
[ /gsm |
permanent link ]
Tracing LTE on the phone
As a short additional note to my first experiments running an LTE eNodeB:
I wanted to know how this looks on the phone. The protocol I am interested
in is RRC (Radio Resource Control) for LTE (specified in TS 36.331). RRC
also transports the NAS messages which are exchanged between the eNodeB and
the MME.
The USB LTE Dongle I use for my experiments is based on a Qualcomm chipsets.
I used Qualcomm based phones for quite a while so I already know some parts
of how tracing works on them. I was able to locate the LTE messages in the
traces and extend GSMTAP slightly so that it is able to handle LTE RRC
messages too.
Here is how it looks in WireShark when a phone registers to the LTE cell:
The red colored lines are uplink messages (from UE to eNodeB), the blue lines
are the response from the eNodeB. The trace also contains a few of the System
Information messages the phone has to decode to get all the required
information to communicate with the eNodeB. Otherwise you can see that the
NAS messages exactly match those seen on the S1-AP interface (of course, this
is expected).
[ /gsm |
permanent link ]
Running your own LTE eNodeB
Finally I got all the required parts together for a fully functional LTE
eNodeB. The eNodeB (E-UTRAN Node-B or Evolved Node-B) is the LTE equivalent
of a GSM BTS or a 3G Node-B. Considering that its was only less than two years
ago when I started to experiment with 3G Node-Bs, obtaining LTE equipment
went faster than expected, especially considering that LTE is still in the
deployment phase.
Compared to what is needed to run a 3G Node-B, an LTE eNodeB really deserves
the "Evolved" in its name. All the functionally of the 3G RNC is contained in
the eNodeB (e.g. all the RLC/MAC and radio functionality) and only the higher
layers are exposed through the so called "S1" interface. This interface is IP
based, there are no such things like E1/T1 or ATM any more.
In case you wonder
from where all the configuration parameters for the eNodeB like EARFCN or RF
Output Power come from: They have to be configured when setting up the eNodeB,
in my case you can configure a few hundred parameters. Luckily most of them
have default values which for a start can be taken without modification.
The S1 interface is divided into S1-AP (Application Part) which is specified
in TS 36.413. This is the interface to the MME (Mobility Management Entity)
which is somehow comparable to a GSM MSC and it uses SCTP. The communication
between MME and phone (abbreviated UE like in 3G) are the so called NAS
(Non-access stratum) messages, in LTE this is mainly Mobility Management
and Session Management, there is no Call Control. LTE NAS is specified in
TS 24.301.
The second part of S1 is called S1-U for the user plane traffic which is
GTP-U (GPRS Tunneling Protocol) specified in TS 29.281 and using UDP.
S1-U connects to the S-GW (Serving Gateway), basically comparable to a
GPRS SGSN.
The eNodeB also has a second interface called "X2-AP" (TS 36.423), it is used
to interconnect multiple eNodeBs (this is needed for example for handling
handover which is done be the eNodeBs themselves). I did not care about X2-AP
yet because right now I only have one eNodeB.
So far I wrote a very simple "Proof-of-Concept" so that a phone (in my
case an LTE USB Dongle) can register to the LTE cell and transfer data
(IP traffic). Just to mention a few of the differences to 3G/GSM:
-
The keys generated by the USIM in the UE (you can use a 3G USIM for LTE too) are
not directly used for integrity protection or ciphering. Instead they are used
to derive various keys, two of them are the ones used for ciphering/integrity
protection on the air interface, this is done in the eNodeB.
-
The NAS messages between UE and MME are also protected (integrity protected and
optionally ciphered), another derived set of keys is used for this. This means
that even if the keys in the eNodeB can be obtained, the NAS messages are still
protected.
-
One Mobility and one Session Management message can be transferred at once
in one message over the S1-AP interface, this is for improving speed and saves
data transfer on the core network.
Here is how it looks in WireShark when a phone registers to the LTE cell
(recent versions of WireShark can handle S1-AP):
The colored lines are uplink messages (from UE to MME), the white lines
are the response from the MME. You can see that a default bearer is
configured together with attaching to the network. This means that
without any further S1-AP messages user plane traffic can start immediately
afterwards, at least if the default bearer is sufficient (e.g. the offered
quality of service is good enough).
This all is just a very first start with LTE, I hope to find more time for
it in the future and explore my eNodeB and LTE further.
[ /gsm |
permanent link ]
Sometimes you need Wireshark to get an RF Power Amplifier running
I recently had the need for an RF Power Amplifier for the UMTS 2100 MHz
band. As I didn't have a suitable amplifier at hand, I though of using
one of the RF Power Amplifier modules of my Nokia Ultrasite cabinet which
is a Node-B configured for UMTS 2100 MHz. The RF Power Amplifier modules
in the cabinet can easily be removed, they are directly connected to the
power supply line of the cabinet and they have standard RF connectors for
RF In and RF Out. So it should be quite easy to operate them outside the
cabinet.
Connecting power to the RF Power Amplifier module was easy, however this
wasn't enough, the amplifier didn't amplify any RF although the status LED
of the module was on. Also the power consumption was quite low, so obviously
the actual RF Power Amplifier in the module was not yet on. I didn't want to
modify the electronic inside the module so I had to find out how the module
gets enabled in the cabinet.
Nearly all of the various modules in the Nokia Ultrasite cabinet are connected
at the backplane to Ethernet through a hub (yes, a hub, there is no switch).
This Ethernet network is mainly used for controlling the modules, fast data
transfer between the modules is done somewhere else. The RF Power Amplifier
module is no exception, it's connected to this control Ethernet network too.
The configuration and management port of the cabinet is also an Ethernet port
connected to the same control network. And because an Ethernet hub is used,
all the traffic on this network can be monitored without any further tricks
if you are connected to the cabinet's configuration and management port.
So I run Wireshark and captured a trace of the traffic on the cabinet's
control network. I already knew the IP address of the RF Power Amplifier
module from running it externally, however it only responded to a ping
but no TCP or UDP port was open. (BTW, if you wonder how the module gets
its IP address: depending on the slot where the module is inserted into
the cabinet, different ID pins of the module are grounded. The levels on
those ID pins define the MAC and IP address of the module).
From the trace I was able to find out hot it works, it's actually quite
evolved:
- First a certain UDP packet has to be send to the RF Power Amplifier
module. Not just destination IP address and port have to match, also the
source IP address and port have to be a specific value, if not the module
just reports an ICMP error that the port is unreachable (that's the
reason why I didn't find an open port during my first try).
- This UDP package causes the module to initiate a TCP connection back
to the sender, when the TCP connection is open the module sends some kind
of initialization message and expects an acknowledgment.
- Only after the TCP connection is open and properly initialized, another
UDP package can be send to the module which finally turns the RF Power
Amplifier inside the module on.
I am not sure why the TCP connection is necessary, so far I only found out
that it is used to control the status LED of the module and to return the
operational status (e.g. if a fault was detected). Over UDP it's also possible
to query the serial number of the module or to tell it to periodically return
RF power measurements. So as you can see, sometimes even just a "simple" thing
like an RF Power Amplifier can require quite complicated interaction to run it.
[ /gsm |
permanent link ]
Getting voice to work for OpenBSC and Ericsson RBS
When Harald Welte visited me for the Osmocom User Group meeting, he
took the chance to experiment with OpenBSC and my RBS2206, a large GSM
BTS in a cabinet. This inspired me to do some more investigations to get
the RBS2206 actually run with OpenBSC including voice calls.
When OpenBSC configures a channel for voice, the RBS closes the channel
after a few seconds with a "remote transcoder failure" error. I found
some information which seems to indicate that there are O&M TRAU frames
involved to signal the usage of the correct codec between BTS and TRAU.
So I started to analyze the traffic between the RBS and the Racal
6113, a BTS tester which is able to run the RBS including voice
calls. To analyze the traffic, I used a Siemens/Tektronix K1103 which
can trace E1/T1 traffic.
To my surprise I did not find any O&M TRAU frames in the trace. After
doing some more experiments it turned out that the RBS expects to
receive speech TRAU frames of the same type (e.g. FR or EFR) as soon
as it starts to transmit speech TRAU frames after the channel was configured
for voice. So far OpenBSC sends Idle Speech frames as long as the voice
channel is not yet connected to the other phone. This worked fine for the
Siemens BS-11 or Nokia MetroSite/InSite BTS, but obviously did not work
for the Ericsson RBS.
After adjusting the idle TRAU frame generation in OpenBSC with a quick
workaround and solving some minor problems when configuring the RBS
(depending on the software versions in the RBS some configuration
messages are slightly different) I was finally able to run OpenBSC
including voice calls with the RBS2206 over an E1 line and an RBS2401
over T1. The modifications are not yet in OpenBSC, but should be there
soon after cleaning them up.
[ /gsm |
permanent link ]
A bit of 3G Layer-1
While experimenting with my Node-B, I had the need to generate a RACH
message without having to use a phone. Such an approach can for
example be used for performance testing of the Node-B receiver or evaluating
the RACH handling capacity of the radio network (no, I don't call it RACH DoS ;-)
First a little bit of theory: The RACH in UMTS works different than in
GSM, its not just about sending a single RACH burst. Because WCDMA is
very sensitive to interference, the phones have to send with a transmit power
as low as possible. For the RACH procedure this means that the phone
starts to send a short RACH preamble with very low power and looks for
the acknowledgement if the preamble has been received by the Node-B on
the AICH (Access Indication Channel) channel. If the phone doesn't receive
the acknowledgement, it increases the transmission power and resends the
preamble. If there is the acknowledgement from the Node-B, the phone sends
the actual RACH message. The RACH message itself is not just a few bits
containing the access cause and a random reference like in GSM, it is a
complete message. "RRC Connection Request" is used for accessing the
network but other message can also be sent on the RACH channel (e.g. "Cell
Update" which is besides other things used for indicating unrecoverable
RLC errors. One can see this message frequently when starting to implement
an RNC ;-).
Now where to get a RACH preamble and message without having to use a phone?
I started to look at Agilent's Signal Studio for WCDMA which should be able
to generate a RACH messages with user defined content which can be replayed
with a signal generator. However even after lots of trials I never managed to
generate a RACH message which can be properly decoded by the Node-B, only the
RACH preamble is detected without errors but the RACH message itself just
produces garbage and CRC errors.
So I started to write my own code to generate the RACH message. The relevant
3GPP specification for WCDMA FDD is TS 25.212 (Multiplexing and channel coding)
and TS 25.213 (Spreading and Modulation). Basically the steps to create a
RACH message requires adding a CRC to the message bits, Convolutional encoding,
1st Interleaving, Rate Matching, 2nd Interleaving, Spreading, Scrambling and
finally Modulation. I and Q signal on the Uplink carry different things, Data
is on the I signal, Control (pilot bits and transport format information) on
the Q signal. Luckily the RACH message does not require any fancy multiplexing
and rate matching of multiple transport channels on a physical radio channel.
This can get really funny, especially if Turbo Coding is involved which results
in multiple bit streams (systematic and parity bits) which are treated differently.
After some trial-and-error and lots of experimenting and testing I was finally
able to create a well formed signal of a RACH preamble and message which the
Node-B can properly decode.
After that I also tried to decode the RACH message generated by Agilent's Signal
Studio to find out why it didn't work. It seems that the wrong scrambling code
sequence is used (the scrambling code number looks OK, but the offset into
the code bits is wrong). I really wonder why no one noticed this problem with
Signal Studio before or maybe I am just doing something wrong. Anyway, I can
now use my own code to generate RACH messages. Maybe in the future I will also
look into generating a signal which a phone will consider as valid signal
of a 3G cell, this requires generating the P-CPICH (Primary Common Pilot
Channel), P-SCH/S-SCH (Primary/Secondary Synchronization Channel) and P-CCPCH
(Primary Common Control Physical Channel) carrying the BCH.
[ /gsm |
permanent link ]
3G User Plane
Continuing with my Node-B experiments I started to implement handling the
user plane. I can now do voice calls, video calls and data connections. Just
to make it clear, those are the very first steps only without any optimisation
for speed and far from being complete or ready for release. I consider it as
the essential "building blocks" necessary for the next steps towards a small
Open Source RNC.
So how does it work? One way to allocate a channel for user data is to modify
the existing signalling channel by sending the RRC "Radio Bearer Setup" message
to the phone and the NBAP "Radio Link Reconfiguration Prepare/Commit" messages
to the Node-B. Besides being much more complex due to the number of possible
parameters and options this is somehow comparable to TS 04.08 "Channel Mode Modify"
and A-bis TS 08.58 "Mode Modify" in GSM. If the commands succeed the Node-B will
allocate another UDP port for the User Plane data besides the existing UDP
port for the Control Plane data (UDP ports because I use "Iub over IP" to talk
with the Node-B).
The User Plane data are embedded in FP (Frame protocol, TS 25.427). For
voice the data are the AMR class A, B and C bits. To ease testing with a single
phone I use a loopback which simply sends the received uplink AMR class bits
back to the downlink.
Signalling for a Video Call is very similar to a Voice call. The main difference
is in the CC Setup message, the bearer capability indicates UDI (Unrestricted
Digital Information) for Video. UDI is basically a 64 kbit/s channel which
transports video according to the 3GPP umbrella protocol
3G-324M) for video telephony.
Loopback is not as easy as for voice because first the four-way H.245 protocol
handshake has to be completed to agree on communication parameters, after that
the uplink video data can be resent to the downlink.
Although UMTS is generally much more complex than GSM/GPRS, handling of data
connections is easier than for GPRS because there is no need for a PCU
(Packet Control Unit) with all its complexity. There is the optional
protocol PDCP (Packet Data Convergence Protocol, TS 25.323) on top of
RLC which is used for things like header compression. But if you don't
use it, you get the raw IP packets embedded inside RLC.
[ /gsm |
permanent link ]
Running your own Node-B
Its now nearly 3 and a half year ago that I wrote the first "Proof-of-Concept"
code to get the Siemens BS-11 GSM Basestation up and running. So I think it was
time to start with 3G, now that LTE is being actively deployed. You also can
sometimes find reasonable priced, used Node-Bs which makes getting access to
the equipment possible. A Node-B is the 3G equivalent of a GSM BTS.
So I spent quite a lot of time spread of several months to get a Node-B up
and running. Compared with the BS-11 this was a lot more difficult
and required much more time. Of course the Air Interface is completely
different, in my case I looked at WCDMA FDD so far, there a few more
standards used in other parts of the world. Then you have to deal with
a huge, different specification, the most important when dealing with a
Node-B are NBAP (TS 25.433) and RRC (TS 25.331), around 3000 pages in total.
NBAP, the Node-B Application Part, is used to configure the Node-B and do things
like creating Radio Links (communication channels) to the phone. RRC, the
Radio Resource Control, is the Layer-3 protocol for the control plane between
the phone and the access network. It is responsible for accessing the network,
setting up and releasing connections or paging a phone. Both NBAP and RRC make
use of ASN.1 which makes things not necessarily easier ;-) There are a few
more protocols on the lower layers involved like MAC (TS 25.321),
RLC (TS 25.322) and FP (TS 25.435 and TS 25.427).
The Node-Bs I used can run "Iub over IP" (Iub is the interface between the
Node-B and the RNC, similar to Abis in GSM between the BTS and BSC). Originally
Iub is based on ATM which runs over E1/T1 or similar lines with higher data
rates. However "Iub over ATM" adds a few more protocol layers for dealing with
ATM and I really wanted to avoid this additional complexity. Not all Node-Bs
can automatically do "Iub over IP", usually it requires an additional hardware
option (interface card). When using "Iub over IP" you have to deal with
protocols like UDP and SCTP which are much more convenient.
The current status is a very minimal implementation of something like
an RNC to run the Node-B so that a phone can register on the network
and do simple things like SMS on the control plane. No user plane like
speech or data yet, but this is the next steps I plan to do. The code
is not yet public but it will be when it gets more evolved.
There is still a lot left to research and experiment with. For example I
haven't looked at things like HSPA yet, I completely ignore handover to
other cells as there is only one cell in my experimental setup. So I am
sure 3G will give a few more years of a very interesting field to
play with before looking at LTE ;-)
[ /gsm |
permanent link ]
GPRS Air Interface
To get a better understanding of how GPRS looks like at the air interface, I
implemented some first experimental code in Airprobe (this is not yet ready
to be released). The output of this code are the RLC/MAC blocks on the
downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC
yet.
The GPRS air interface is not that different than "standard" GSM (signalling
or voice). The PDCH (Packet Data Channel) uses its own multiframe structure
with a length of 52 frames, the biggest difference are four coding schemes
(CS-1 to CS-4, CS-1 and CS-2 use
puncturing) which are chosen depending on
the quality of the radio link. If the link quality is good, a coding scheme
with less forward error correction and more information bits is used which
results in a higher data rate. As a side note, you can test how good your
receiver really is if CS-4 is used (very good radio link quality, no
forward error correction at all), you should have nearly no bit errors
in the decoded data (the phone also receives error free data, otherwise
CS-4 would not be used).
I have not yet implemented decoding EDGE, besides other coding schemes EDGE
can also use a different modulation (8-PSK instead of GMSK).
Please note that being able to decrypt the A5 encryption does not help with
GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm
(GEA) at a higher level. If you want to experiment with GPRS encryption, the
easiest to start with is probably using a GPRS setup with OpenBSC plus the
nanoBTS and look at the traces to the SGSN with WireShark (you have to
implement a GPRS encryption algorithm in osmo-SGSN first, the specification
of GEA3 is publicly available).
[ /gsm |
permanent link ]
TETRA Air Interface
If you are interested in how the air interface and the lower levels of TETRA
work, you should have a look at the
http://tetra.osmocom.org/
website.
My contribution so far was to search for a suitable demodulator (TETRA uses
PI/4-DQPSK) which I found at the
OP25 project (the
author of the demodulator is KA1RBI).
I also implemented some "proof of concept" code which allows decoding
speech traffic and converting it to raw audio using the TETRA reference
codec. Please note that this cannot be used to listen to encrypted
TETRA traffic, it only works if no encryption is used.
[ /sdr |
permanent link ]
GSM Ciphering Algorithms in mobile phones
You are probably aware that the A5/1 and A5/2 GSM ciphering algorithms
are broken, A5/2 is so weak that even the GSMA mandates that it is no
longer used in new mobile phones. A secure alternative would be A5/3,
however it is not yet deployed in GSM networks, at least those networks I
am aware of, and only some newer phones support it.
I had a brief look at some phones I have access to, most of them came
out in the last four years. Interestingly quite a lot of them still
support A5/2 and only very few support A5/3. If a phone does not indicate
A5/3 support, this does not necessarily mean that it is not capable to
run A5/3, for example on one of my test phones, a BlackBerry Bold 9000,
A5/3 is disabled (for whatever reason). The phones in my collection with
enabled A5/3 support are some new, cheap features phones from India
based on a MediaTek chipset. And as a side note: The iPhone 4 I looked
at does not have A5/3 enabled but at least A5/2 is disabled.
I also did a few quick tests to make sure that A5/2 cannot be used on those
phones which claim that they do not support it, and so far this seem to be
the case. The reason for this test: The phones can most certainly run
A5/2 if they can run A5/1 (which all of my phones can), A5/2 is very
similar to A5/1. If a phone claims to support only A5/1, it does not
necessarily mean that the phone will not use A5/2 if you force it to
do so, if there are bugs in the phone firmware, the phone could still
run A5/2.
The short tests I did are only a first look at this issue. Additionally
the same phone model could behave different when sold by a different
operator or in a different country, as I already wrote, most of the
time the supported ciphering algorithms can be configured by the phone
manufacturer. So this is an area which should be investigated further.
[ /gsm |
permanent link ]
OsmocomBB GSM Development
I have the impression that not a lot of people are developing for
Layer-1 in
OsmocomBB. Is it because GSM in that depth is too complicated ?
Of course you need some GSM knowledge to start, but be assured you
will learn a lot if you work on this level.
Besides the really cheap phones supported by OsmocomBB you also need
a BTS or GSM Testset for doing serious work. You can use a BS-11 or
nanoBTS with OpenBSC or an USRP-1 with OpenBTS. I understand that the
price for this hardware might be too expensive for some of you.
However GSM Testsets are not that expensive any more. If you have the
room for a large and heavy unit (around 30 Kg) the HP 8922 might be a
good solution. You can buy them for a few hundred Euros and this unit
is really nice: Besides the GSM Testset it can be used as a very
accurate Signal Generator (10 MHz to 1 GHz) and it also comes with
a simple Spectrum Analyzer (10 MHz to 1 GHz) as a hardware option.
The unit is for GSM-900 but there is an additional converter available for
GSM-1800 support. The converter doubles the size of the unit and you usually
don't need it. One drawback is that the HP 8922 does not support Encryption.
As far as I know this was a Hardware Option but I have never seen a unit
for sale which has this option installed. Actually it would only require
a different DSP code in one of the EEPROMs which includes the A5/1 or A5/2
encryption code, the rest (Layer-3 support and passing Kc to the DSP) is
already there. As usual with most HP units, you can download the documentation
from the HP/Agilent web site.
Another GSM Testset I use is the Racal 6103. Its smaller than the HP 8922
and has more Layer-3 options but is not that versatile on Layer-1. The "E"
Variant of the unit also supports Encryption. You can sometimes find those
units for a few hundred Euros, but be aware that it is not the "Anite" or
"Aime" variant, those units require a special PC software to use them,
without this software you can't do much with them. So far I have not seen
this software, I only know that it is quite expensive.
If you use a GSM Testset, you have one big benefit: You can connect
the phone to the Testset with a cable (there is no need for an attenuator)
and don't have to care that much about emitting RF on the licensed spectrum.
[ /gsm |
permanent link ]
A few notes about the TI Calypso audio path
While working on voice support for
OsmocomBB I had to look in detail at how the audio path in the
TI Calypso chipset works. Basically it is not very complicated:
The Uplink path consists of an amplifier for the
microphone and an ADC, the digital samples are transferred to
the DSP which takes care about the encoding according to the
selected GSM voice codec.
In the Downlink path the decoded samples from the DSP are
sent to a DAC which is followed by an amplifier and the loudspeaker.
Some additional details are that you can select the analog
input/output (e.g. if the headset connector is used). Parameters
which can be adjusted are the gain of the amplifiers and the sidetone
level (a feedback between the uplink and the downlink audio path).
The digital samples for the DSP use a sample rate of 8 kHz. A not
so obvious feature is that there are two FIR (Finite Impulse Response)
digital filters with 31 taps in the DSP, one for the uplink, the
other for the downlink. Those filters can be used to improve the
voice quality or reduce ambient noise. So far those filters are set
to not modify the signal (the filter coefficient of the first tap
is 1, all others are 0). The format of the filter coefficients is
signed fixed-point Q2.14, so for example 0x4000 means 1.
[ /gsm |
permanent link ]
Nokia WCDMA UltraSite Basestation
I bought several components of a Nokia WCDMA UltraSite BTS. However
the unit is not yet complete. What is missing:
- IFU - Interface Unit
- WTR - Transmitter and Receiver
- WPA - Power Amplifier
- Rack/Cabinet for all the components
If anyone knows where to get those parts for a reasonable price,
please let me know. The final goal is to have support for this unit
and similar WCDMA basestations from other manufactures in OpenBSC.
I am aware that UMTS Femtocells are cheaper and they do WCDMA too.
Its surely possible to support them in OpenBSC, its mainly a matter
of free time and/or who will start with it. But Femtocells have a
different architecture than "real" BTS/Node B units, a Femtocell
usually combines the RNC (Radio Network Controller) with the
basestation and uses a different protocol for controlling the
unit. So it still makes sense to have a "real" WCDMA BTS/Node B
for OpenBSC integration.
[ /gsm |
permanent link ]
Ciphering Indicator in mobile phones
According to GSM 02.07 B.1.26, there should be a Ciphering Indicator in
the ME to allow a user to detect if ciphering is not switched on. The
Ciphering Indicator can be turned off by the network operator clearing
the OFM (Operational Feature Monitor) bit in the "administrative data"
field of the SIM (see GSM 11.11, 10.3.18)
Usually the Ciphering Indicator is turned off, at least in those SIMs
I have seen so far. And you usually cannot modify the administrative data
in the SIM. But would a phone actually display something if the Ciphering
Indicator is enabled and ciphering is not on ?
To find this out I used a Test SIM which allows modifying all fields of
the SIM. Such a Test SIM is for testing handsets, you cannot use it with
your official GSM network. The OFM bit was set to one to enable the Ciphering
Indicator. To simulate encrypted and unencrypted calls I used a Racal 6103E
GSM Testset. I could have also used OpenBSC, however with the 6103E switching
between encrypted and unencrypted calls was faster, it just required the press
of a button.
Here are the results for some phones I had access to, Yes means that I
noticed a difference between encrypted and unencrypted calls and what this
difference was and No means that I noticed no difference:
- Nokia 3310: Yes, Open Lock Symbol during Call
- Siemens M55: Yes, *!* Symbol during Call, regardless of OFM bit
- Mitsubishi MT-040: No
- P1300: Yes, Cx Symbol during Call
- Motorola C123: No
- Motorola W156: No
- Netzing NE110: Yes, C* Symbol during Call
- BlackBerry 9000: No
- BlackBerry 9520: No
- BlackBerry 9700: No
- Sony Erisson K800i: No
- HTC Touch Pro: No
- HTC Hermes: No
This is by no means a detailed investigation however it is at least some
indication that a lot of phones do not care at all about the Ciphering
Indicator, probably because it is usually turned off in the SIM anyway.
[ /gsm |
permanent link ]
TCH Support for OsmocomBB
I started to implement Layer-1 support in
OsmocomBB for traffic channels. Its not yet ready and in a rather
crude state but I hope to clean it up in the next few days so that
it can be released.
During testing I used a nice feature of my HP8922 GSM Testset: It can
continuously generate Full-Rate TCH speech traffic on a timeslot without
the need for any signalling. You can even connect an external audio source
like a CD player and "broadcast" your own content. And while it is in this
mode, the HP8922 can also receive speech traffic and you can hear it
on its built-in loudspeaker.
The benefit of this for getting the Layer-1 code on the phone right is that
you can concentrate on TCH receiving and transmitting without having to
care about signalling. You just "tune" to the right ARFCN and timeslot
(I don't use hopping during testing) and see that you get your code running.
I guess that having this special mode (setting an ARFCN and timeslot and
"listen" to the TCH) in the phone can be quite useful for debugging
non-hopping, non-encrypted, single ARFCN cells like OpenBSC and
OpenBTS.
[ /gsm |
permanent link ]
Microsoft Research and SDR
I wasn't aware of it, but Microsoft Research is doing SDR
(Software Defined Radio):
Sora.
Their approach is interesting, all the raw samples are transferred between
the PC memory and the ADC/DAC of the Radio Front-end by a PCIe card and
all the signal processing is done by the CPU of a PC. There is no DDC
(Digital Down Converter) or DUC (Digital Up Converter) in an FPGA
involved. They already implemented 802.11a/b/g and an LTE receiver
this way.
The price of the hardware does not sound too expensive. The
software only runs on Windows and I have not yet checked the
license terms in detail.
I could imagine that combining this approach with the power of
a GPU can be quite interesting.
[ /sdr |
permanent link ]
Extending Airprobe's gsm-receiver
I spent some time to extend Airbrobe's gsm-receiver so that it now can
be used to nearly fully decode the downlink traffic of a non-hopping,
single ARFCN cell. "Nearly" means that it does not yet support Half-Rate
speech TCH channels or TCH data channels (which are not widely
used anyway with GPRS).
It might not be obvious, but I was also responsible for decoding/decrypting
speech in gsm-receiver. In June 2009 I wrote a tool based mainly on
parts of OpenBTS to solve a little "challenge" by Piotr Krysik posted
on the Airprobe mailing list to get the speech out of an USRP capture.
This standalone tool was later integrated into gsm-receiver by Piotr.
Now at least you know who to blame why there is stuff from OpenBTS
integrated into gsm-receiver ;-).
Besides being used in Karsten Nohl's
A5/1 cracking attack, those features of gsm-receiver are quite handy for
debugging OpenBSC or OpenBTS in the downlink direction.
A short tutorial of how to use gsm-receiver can be found
here.
One of the next steps I plan to do is implementing the uplink direction.
Please don't ask when this will be ready, if someone else is already working
on it, please let me know so that the same thing is not done twice.
[ /gsm |
permanent link ]
Starting to blog
I finally decided to start writing a small blog about what things
I am working on. The reason is that it seems these days without talking
or writing about what you do, your work won't get noticed or others
might take what you have done and claim its theirs.
[ |
permanent link ]
|