14 Jan
2011
14 Jan
'11
5:10 p.m.
hi,
a while ago i've read that someone managed to have an active phone call over
osmocom for about 20mins.
i woundered if it is theoretically & technically possible to have an active,
serious (thus not a5) encryption running
for voice or data calls on the stack?
thanks in advance & greetings from vienna ;)
azet
14 Jan
14 Jan
9:29 p.m.
Aaron,
the usual problems with end-to-end encryption in GSM come into play:
* as the voice path is not transparent but transcoded any number of times
in the core network, you cannot simply encrypt the codec frames but gqwill
have to initiate a CSD ('modem') connection.
* not many networks support it anymore
* calling rates are more expensive
* you immediately leave a visible trail, since nobody else uses CSD
And no, neither is the ARM7 fast enough for any crypto, nor do we implement
CSD at all.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
11:50 p.m.
On 14/01/11 21.29, Harald Welte wrote:
Aaron,
the usual problems with end-to-end encryption in GSM come into play:
* as the voice path is not transparent but transcoded any number of times
in the core network, you cannot simply encrypt the codec frames but gqwill
have to initiate a CSD ('modem') connection.
Enciphering directly the
GSM/AMR codec payload at GSM it's still a cool
hackish idea!
Regarding transcoding it's also to be considered that within the same
operator or at GSM inter-working national level it's much more difficult
that transcoding it's done in the voice path.
Mobile operators tends to avoid transcoding whether possible to reduce
the infrastructural costs associated with media gateway equipments and
directly interconnected mobile operators probably doesn't do much
transcoding.
I asked you a similar question at ph-neutral a couple of years ago and i
remember that there's also an issue related not being able, due to
hardware design of baseband, to control the path between the
encoder/decoder and the transmitter.
So no "hands on" the audio encoded/decoded payload that will get sent to
the network, right?
* not many networks support it anymore
* calling rates are more expensive
* you immediately leave a visible trail, since nobody else uses CSD
And no, neither is the ARM7 fast enough for any crypto, nor do we implement
CSD at all.
We all would really like to see incredibly efficient DoV (Data over
Voice) modem technologies reaching at least stable 800bit/s to be able
to run a 600bit/s audio codec along with some encryption on top of it.
For military stuff there's a UK university that made a patent for a
1200bit/s DoV with error correction and 0.03% BER over GSM-to-GSM calls
with GSM codec (13kbit/s).
http://personal.ee.surrey.ac.uk/Personal/N.Katugampala/pubs/iee04.pdf
Some other DoV has been done to develop emergency services such as
in-band transmission of information between emergergy services and law
enforcement operators for european esafety project
(www.esafetysupport.org) standardizing in-band modem over GSM and AMR as
3GPP TS 26.267 but that uber-patented technology are not designed to
handle realtime transport bust just signaling of messages.
-naif
11:57 p.m.
Hi,
On 14.01.2011 23:50, Fabio Pietrosanti (naif) wrote:
So no "hands on" the audio encoded/decoded
payload that will get sent to
the network, right?
One commit says more than thousand words:
http://bb.osmocom.org/trac/changeset/999254a3a6641ea112b48c1eca65599fb99891…
Sylvain also has a uncommitted code that allows to fill the uplink TCH
data, and Andreas has code for connecting this to the LCR.
Regards,
Steve
15 Jan
15 Jan
9:56 p.m.
On 14/01/11 23.57, Steve Markgraf wrote:
One commit says more than thousand words:
http://bb.osmocom.org/trac/changeset/999254a3a6641ea112b48c1eca65599fb99891…
Sylvain also has a uncommitted code that allows to fill the uplink TCH
data, and Andreas has code for connecting this to the LCR.
Woah!
I should probably get a couple of phones to play!
It would be interesting to try to get each audio samples incoming and
outgoing and XOR it, to see if other party receive it "as-is", that
would means that no-transcoding happened.
Maybe there are an area of conditions where transcoding doesn't happen,
like within the same operator or within national gsm operators
interconnections.
If that could be confirmed, it would be possible to have a low latency
full-duplex communication data path at 13.3kbit/s (GSM codec) or
12.2kbit (GSM EFR/AMR codec) to be managed such like a serial connection.
On top of a protocol alike HDLC could provide a serial connection over a
GSM voice raw transport
Someone willing to make a try?
-naif
16 Jan
16 Jan
12:23 a.m.
Hi Fabio,
On 15 January 2011 20:56, Fabio Pietrosanti (naif)
<lists(a)infosecurity.ch> wrote:
Maybe there are an area of conditions where transcoding doesn't happen,
like within the same operator or within national gsm operators
interconnections.
If that could be confirmed, it would be possible to have a low latency
full-duplex communication data path at 13.3kbit/s (GSM codec) or
12.2kbit (GSM EFR/AMR codec) to be managed such like a serial connection.
On top of a protocol alike HDLC could provide a serial connection over a
GSM voice raw transport
Someone willing to make a try?
Note the L1 channel coding is intimately linked to characteristics of
the codec/connection type, and it's just not as simple as treating the
bits that usually carry codec frames as a serial link. For example
block size and error correction varies by codec and even between
individual frame types within a codec. I believe L2 has no automatic
retransmission on frame error for voice channels, so that must also be
handled.
I'm not suggesting a solution, just pointing out these are not simple
"boxes and arrows" to be freely substituted without detailed knowledge
of the surrounding system.
David
1:11 p.m.
You may have a look at
http://www.cryptophone.de/en/background/cryptophone-technology/
They have gone through all the ideas coming up here, but a few years
ago. I there would be any way to use the GSM voice channel for
encrypted, reliable communication, they would have used it.
Frank
1:38 p.m.
I went and visited the project of Prof. A. Kondoz in Surrey who got the furthest with a
DoV modem in the public domain and he explained their modeling and system. Essentially
they got up to about 1 Kbit with 2-8% BER on real-world single-operator (!) GSM-networks
running AMR full rate. Kondoz has developed a LPC10 variant for codec that could work with
that bandwith, as expected sounding like robots talking through rain-drains. His main
speciality is voice codecs.
The computational effort for the modem and the codec was in the 1.5 GHz range, so on the
verge of being doable on todays mobile hardware. The project did afaik not progress much
further cause the students who did it graduated and the funding apparently dried up (or
the project was taken over by a .gov contractor for development of a clandestine comms
system, depending on which rumor you believe). Performance over multiple operators (read:
international calls) was only good enough for slow message transfer (low hundreds of
bit/sec), which is not very attractive.
The crucial trick Kondoz used was to adapt the symbol table for the DOV-modem dynamically
to the AMR voice codec codebook changes. If you want to bring that work further, the first
step is of course inserting the frames directly into the baseband (this skipping one codec
step), then building a feedback loop that passes information on the AMR codec state on the
receiving end to the sender, so it can adapt the modem symbol table accordingly. That
combined may yield the crucial datarate improvement to make it work accross operators and
with better understandability. At CryptoPhone we stopped further research into the project
due too high cost and risk of failure (all others I know off canceled as well).
Let me know when you succeed so we can license the tech, until then we just use IP ;-)
Greetings from Berlin,
Frank Rieger
15 Jan
15 Jan
1:15 a.m.
Hi all,
This particular problem domain is why I originally became interested in this
project. In fact I just bought a couple C118s and now have them running the
current build as of yesterday.
There has been additional work done in the academic world on
"data-over-voice" the last few years, mainly out of Chinese and Iranian
universities. Some of them claim reliable data rates of 2000 bps or higher
(not including error correction), which is good enough for low data rate
vocoders (e.g. speex). A search on IEEE comes up with a bunch of papers, and
some have fairly detailed design data. Most are optimized for EFR, and some
for AMR. Some claim to be computationally efficient enough for
implementation on modern smart phones.
So far, the modems have been implemented at the audio interface of the
handset, not the raw OTA compressed voice frames. I believe a project such
as this will make it possible to improve these modems by being able to
directly control the content of the traffic frames. At the very least, I
think it will aid in synchronization issues between the end points, and
easier handling of VAD/DTX/CNG.
The problem is made very difficult because of transcoding done within the
network. And, depending on the call, there may be different transcode
operations between end points (or maybe none at all?). Also, the voice frame
parameters are not all protected equally from channel errors. My hope was to
actually start characterizing network transcode behaviors, since I have not
yet found any real data on this. It is possible to do this without access to
the traffic frames, but it makes for more complex test cases.
At any rate it is an interesting problem.
-Wes
On Fri, Jan 14, 2011 at 2:50 PM, Fabio Pietrosanti (naif) <
lists(a)infosecurity.ch> wrote:
On 14/01/11 21.29, Harald Welte wrote:
Aaron,
the usual problems with end-to-end encryption in GSM come into play:
* as the voice path is not transparent but transcoded any number of times
in the core network, you cannot simply encrypt the codec frames but
gqwill
have to initiate a CSD ('modem')
connection.
Enciphering directly the GSM/AMR codec payload at GSM it's still a
cool
hackish idea!
Regarding transcoding it's also to be considered that within the same
operator or at GSM inter-working national level it's much more difficult
that transcoding it's done in the voice path.
Mobile operators tends to avoid transcoding whether possible to reduce
the infrastructural costs associated with media gateway equipments and
directly interconnected mobile operators probably doesn't do much
transcoding.
I asked you a similar question at ph-neutral a couple of years ago and i
remember that there's also an issue related not being able, due to
hardware design of baseband, to control the path between the
encoder/decoder and the transmitter.
So no "hands on" the audio encoded/decoded payload that will get sent to
the network, right?
* not many networks support it anymore
* calling rates are more expensive
* you immediately leave a visible trail, since nobody else uses CSD
And no, neither is the ARM7 fast enough for any crypto, nor do we
implement
CSD at all.
We all would really like to see incredibly efficient DoV (Data over
Voice) modem technologies reaching at least stable 800bit/s to be able
to run a 600bit/s audio codec along with some encryption on top of it.
For military stuff there's a UK university that made a patent for a
1200bit/s DoV with error correction and 0.03% BER over GSM-to-GSM calls
with GSM codec (13kbit/s).
http://personal.ee.surrey.ac.uk/Personal/N.Katugampala/pubs/iee04.pdf
Some other DoV has been done to develop emergency services such as
in-band transmission of information between emergergy services and law
enforcement operators for european esafety project
(www.esafetysupport.org) standardizing in-band modem over GSM and AMR as
3GPP TS 26.267 but that uber-patented technology are not designed to
handle realtime transport bust just signaling of messages.
-naif
10:33 p.m.
On 15/01/11 01.15, Wesley Tanner wrote:
Hi all,
This particular problem domain is why I originally became interested
in this project. In fact I just bought a couple C118s and now have
them running the current build as of yesterday.
Wow, that's extremely
interesting!
Some time ago i made an extremely no-so-technologically-advanced test.
I got a friend's old us robotics sportster 14.4k modem, connected to an
VoIP ATA, connected to an Asterisk, connected to a GSM VoIP Gateway as
follow:
PC->Serial->Modem->VoIP ATA->Asterisk-> GSM-VoIP-Gateway->GSM Voice
call(4.75-to-13kbit)->Telephony-network-PSTN-modem(64kbit)
Made calls to a PSTN dialup modem and was able in a GSM-to-GSM calls to
get 300bps modem carrier.
But that's very very dirty tests not even entering into DSP specific
issue to make a DoV modem!
There has been additional work done in the academic
world on
"data-over-voice" the last few years, mainly out of Chinese and
Iranian universities. Some of them claim reliable data rates of 2000
bps or higher (not including error correction), which is good enough
for low data rate vocoders (e.g. speex).
I immagine that in a real world scenario
it would be required something
even more ultra-narrowband than speex, like the ones destinated for use
in HF radio/military world would be required.
Something like NATO STANAG 4479(800bit/s) or MELPe (600/1200/2400) or
MELP (1200/2400) or CDMA EVRC-B (800bit/s) or future CODEC2 (that will
support 1200bit/s).
A search on IEEE comes up with a bunch of papers, and
some have fairly
detailed design data. Most are optimized for EFR, and some for AMR.
Some claim to be computationally efficient enough for implementation
on modern smart phones.
Well, but practically on a smartphone how to specify to use
GSM EFR
(giving at least 12.2kbit) respect to AMR (that can go down up to
4.75kbit) ?
Having an higher bitrate codec forced would improve the stability and
performance of such as data over voice modem.
So far, the modems have been implemented at the audio
interface of the
handset, not the raw OTA compressed voice frames. I believe a project
such as this will make it possible to improve these modems by being
able to directly control the content of the traffic frames. At the
very least, I think it will aid in synchronization issues between the
end points, and easier handling of VAD/DTX/CNG.
The problem is made very difficult because of transcoding done within
the network. And, depending on the call, there may be different
transcode operations between end points (or maybe none at all?). Also,
the voice frame parameters are not all protected equally from channel
errors. My hope was to actually start characterizing network transcode
behaviors, since I have not yet found any real data on this. It is
possible to do this without access to the traffic frames, but it makes
for more complex test cases.
Well, probably also targeting very reduced rates such
as 800bit/s could
improve the ability to works across more transcoding.
Some times ago i spoke with airbiquity that make this aqlink
uber-patented technology that claim to be able to do 800bit/s even over
AMR codec www.airbiquity.com/pdf/productsheets/*aqLink*.pdf .
A 600bit/s audio codec plus some protocol overhead on top of a powerful
DoV modem running at least at 800bit/s would make probably a new way to
make voice encryption over everything that's a voice channel!
A dream! :)
-naif
11:47 p.m.
thanks for the replys!
this is extremly interesting. but i already suspected that ARM7 wouldn't be
fast enough.
(as you probably can tell, im not much into electronics, but working on
it..)
keep going! :)
azet
4864
days inactive
4865
days old
baseband-devel@lists.osmocom.org
10 comments
8 participants
participants (8)
-
Aaron Zauner -
David Wilson -
Fabio Pietrosanti (naif) -
Frank Rieger -
Frank Rosengart -
Harald Welte -
Steve Markgraf -
Wesley Tanner