<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>LaForge's home page (Posts about tetra)</title><link>https://laforge.gnumonks.org/</link><description></description><atom:link href="https://laforge.gnumonks.org/blog/tags/tetra.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><lastBuildDate>Thu, 24 Oct 2024 20:08:49 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>Slovenian student sentenced for detecting TETRA flaws using OsmocomTETRA</title><link>https://laforge.gnumonks.org/blog/20160522-slovenia-osmocom-tetra/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;According to some news report, including &lt;a class="reference external" href="http://news.softpedia.com/news/student-who-found-flaws-in-police-communication-protocol-gets-prison-sentence-504333.shtml"&gt;this report at softpedia&lt;/a&gt;,
a 26 year old student at the Faculty of Criminal Justice and Security in
Maribor, Slovenia has received a suspended prison sentence for finding
flaws in Slovenian police and army TETRA network using &lt;a class="reference external" href="http://osmocom.org/projects/tetra"&gt;OsmocomTETRA&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;As the Osmocom project leader and main author of OsmocomTETRA, this
is highly disturbing news to me.  OsmocomTETRA was precisely developed
to enable people to perform research and analysis in TETRA networks, and
to audit their safe and secure configuration.&lt;/p&gt;
&lt;p&gt;If a TETRA network (like any other network) is configured with broken
security, then the people responsible for configuring and operating that
network are to be blamed, and not the researcher who invests his
personal time and effort into demonstrating that police radio
communications safety is broken.  On the outside, the court sentence
really sounds like "shoot the messenger".  They should instead have
jailed the people responsible for deploying such an insecure network in
the first place, as well as those responsible for not doing the most
basic air-interface interception tests before putting such a network
into production.&lt;/p&gt;
&lt;p&gt;According to all reports, the student had shared the results of his
research with the authorities and there are public detailed reports from
2015, like the report (in Slovenian) at
&lt;a class="reference external" href="https://podcrto.si/vdor-v-komunikacijo-policije-razkril-hude-varnostne-ranljivosti-sistema-tetra/"&gt;https://podcrto.si/vdor-v-komunikacijo-policije-razkril-hude-varnostne-ranljivosti-sistema-tetra/&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The statement that he should have asked the authorities for permission
before starting his research is moot.  I've seen many such cases and you
would normally never get permission to do this,  or you would most
likely get no response from the (in)competent authorities in the first
place.&lt;/p&gt;
&lt;p&gt;From my point of view, they should give the student a medal of honor,
instead of sentencing him.  He has provided a significant service to the
security of the public sector communications in his country.&lt;/p&gt;
&lt;p&gt;To be fair, the news report also indicates that there were other charges
involved, like impersonating a police officer.  I can of course not
comment on those.&lt;/p&gt;
&lt;p&gt;Please note that I do not know the student or his research first-hand,
nor did I know any of his actions or was involved in them.  OsmocomTETRA
is a Free / Open Source Software project available to anyone in source
code form.  It is a vital tool in demonstrating the lack of security in
many TETRA networks, whether networks for public safety or private
networks.&lt;/p&gt;</description><category>osmocom</category><category>tetra</category><guid>https://laforge.gnumonks.org/blog/20160522-slovenia-osmocom-tetra/</guid><pubDate>Sat, 21 May 2016 16:00:00 GMT</pubDate></item><item><title>Starting to investigate old Motorola Dimetra EBTS</title><link>https://laforge.gnumonks.org/blog/20110531-starting_to_play_with_motorola_dimetra/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;
Together with some friends, we have managed to get our hands on some
ancient (1997) Motorola Dimetra TETRA equipment.  Specifically, this
includes the Base Radios (BR) and the TETRA Site Controller (TSC).
&lt;/p&gt;
&lt;p&gt;
We haven't yet managed to put everything up in the wiki, but you can
watch our progress at the &lt;a href="http://tetra.osmocom.org/trac/wiki/Dimetra_EBTS"&gt;Dimetra_EBTS page
on http://tetra.osmocom.org/&lt;/a&gt; as well as it's sub-pages.
&lt;/p&gt;
&lt;p&gt;
It's going to be a big challenge to put all that equipment to some good
use.  Success is probably defined in terms of &lt;i&gt;running your own small
TETRA network with such an EBTS but without any of the Motorola Dimetra
core network infrastructure (SwMI&lt;/i&gt;, basically the same thing we did
for GSM with OpenBSC.
&lt;/p&gt;
&lt;p&gt;
The big conceptual difference to GSM here is:  In GSM, the internal
protocols (A-bis, A, ...) are all publicly specified.  There are
vendor-specific dialects, but those are relatively easy to figure out.
In TETRA, the ETSI only specified the air interface, but not the
interfaces between the wired components of the network.  This leaves
pretty much everything else proprietary :(
&lt;/p&gt;
&lt;p&gt;
So if anyone has any information (installation manuals, service manuals,
provisioning software, protocol specifications, ...) or experience with
configuring or maintaingin this equipment, I would be very happy if you
could drop me a message.
&lt;/p&gt;</description><category>tetra</category><guid>https://laforge.gnumonks.org/blog/20110531-starting_to_play_with_motorola_dimetra/</guid><pubDate>Mon, 30 May 2011 19:00:00 GMT</pubDate></item><item><title>Public release of Osmocom TETRA code</title><link>https://laforge.gnumonks.org/blog/20110122-osmocom_tetra_public/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;
Today I have publicly released the TETRA receiver code that I've &lt;a href="http://laforge.gnumonks.org/weblog/2011/01/08/#20110108-osmocom_tetra"&gt;started
to work on earlier this year&lt;/a&gt;.  The gnuradio-based demodulator, PHY and
lower MAC code as well as some README file is available from the new &lt;a href="http://tetra.osmocom.org/"&gt;http://tetra.osmocom.org/&lt;/a&gt; website.
&lt;/p&gt;
&lt;p&gt;
There's still a lot of work to be done, but fundamentally we are able to receive,
demodulate and decode TETRA TMO downlink data.  So the task of the software somewhat
compares to that of gsm-tvoid or gsm-receiver (part of airprobe).
&lt;/p&gt;
&lt;p&gt;
A corresponding project mailing list has also been made available.  Please respect
that this is a development-only discussion list right now.  If you cannot make the
code work and need help with it, chances are high that it doesn't do anything useful
for you anyway.
&lt;/p&gt;&lt;p&gt;
There is some early code that should eventually enable us to run a base-station
side transmit implementation, but it's not working yet. 
&lt;/p&gt;</description><category>tetra</category><guid>https://laforge.gnumonks.org/blog/20110122-osmocom_tetra_public/</guid><pubDate>Fri, 21 Jan 2011 19:00:00 GMT</pubDate></item><item><title>Working on a Free Software TETRA implementation</title><link>https://laforge.gnumonks.org/blog/20110108-osmocom_tetra/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;
Those who have been following my twitter feed over the last week will already
know: I've been in deep hacking mode implementing the lower levels of &lt;a href="http://en.wikipedia.org/wiki/TETRA"&gt;TETRA&lt;/a&gt;, specifically the PHY and
lower MAC but also parts of the upper MAC level.
&lt;/p&gt;
&lt;p&gt;
The primary idea here is to produce something similar to what &lt;a href="http://airprobe.org/"&gt;airprobe&lt;/a&gt; is for GSM: An air-interface protocol
analyzer that can demodulate/decode/demultiplex information received from a
TETRA base station.
&lt;/p&gt;
&lt;p&gt;
I'm not working on this alone, a number of known (and unknown) names from
the Osmocom projects have been involved again.  Progress has been surprisingly
quick.  The biggest gain was Dieter discovering that we didn't have to write
our own pi4/DQPSK demodulator, but that somebody had already done that as a
gnuradio hierarchical block originally intended for the more advanced channel
types of APCO25.
&lt;/p&gt;
&lt;p&gt;
So we could concentrate on the PHY and lower MAC layers, i.e. implementing stuff
like
&lt;/p&gt;&lt;ul&gt;correlator for the various training sequences to achieve frame sync
&lt;li&gt;de-scrambler, de-interleaver, convolutional decoder, CRC, Reed-Muller decode&lt;/li&gt;
&lt;li&gt;Implementing the TDMA multiplex, reading the BSCH (like SCH in GSM)&lt;/li&gt;
&lt;li&gt;Decoding the MAC-layer PDUs like ACCESS-ASSIGN, SYNC, SYSINFO, RESOURCE&lt;/li&gt;
&lt;li&gt;Peeking into the higher layers like MM&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;
Before writing the decoder I also wrote encoders/interleaver/scrambler etc. for
the transmit side in order to do first testing/validation of the decoder.
Using this encoder, we are able to generate continuous downlink SYNC bursts
containing BSCH(MAC-SYNC PDU) + BNCH(SYSINFO PDU).  As the SYNC bursts can be
used for unallocated time-slots, a never-ending sequence of this single burst
should provide a valid carrier that TETRA mobiles can lock to.
&lt;/p&gt;
&lt;p&gt;
Working on all this has taught me much.  My previous knowledge on convolutional
codes, scrambling, interleaving, training sequence corellation, viterbi
decoding, etc. has been mostly abstract and theoretical.  Now I had the chance
of implementing [almost] everything from scratch.  Now I can understand what
people like Tvoid or Piotr went through when they wrote gsm-tvoid/gsm-receiver
(part of airprobe).
&lt;/p&gt;
&lt;p&gt;
For the next couple of weeks I have to turn back to doing some higher priority
work again, and in February I want to play with the GSM RF side of the MTK GSM
chipsets again, so I don't know when I'll be able to continue with the TETRA
related work.  However, I hope other developers in the team will pick up where
I left and bring the project further forward.
&lt;/p&gt;
&lt;p&gt;
As soon as the code has moved beyond early prototyping, we'll be releasing the
demodulator, libosmo-tetra-phy, libosmo-tetra-mac and associated command line
tools.
&lt;/p&gt;</description><category>tetra</category><guid>https://laforge.gnumonks.org/blog/20110108-osmocom_tetra/</guid><pubDate>Fri, 07 Jan 2011 19:00:00 GMT</pubDate></item></channel></rss>