running voice data/encryption on compal?
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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
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/999254a3a6641ea112b48c1eca65599fb998918... 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
On 14/01/11 23.57, Steve Markgraf wrote:
One commit says more than thousand words:
http://bb.osmocom.org/trac/changeset/999254a3a6641ea112b48c1eca65599fb998918...
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
Hi Fabio, On 15 January 2011 20:56, Fabio Pietrosanti (naif) <lists@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
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
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
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@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
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
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
participants (8)
-
Aaron Zauner -
David Wilson -
Fabio Pietrosanti (naif) -
Frank Rieger -
Frank Rosengart -
Harald Welte -
Steve Markgraf -
Wesley Tanner