Custom encrypt GSM calls

M

5

9

Is it possible to catch voice audio stream with java (JME or Android), custom encrypt it and then send it as regular stream via regular GSM call? And off course decrypt cipher on other phone. Is application level java permitted to intercept audio stream or it is disabled on hardware level?

Are there already apps that do that?

Movie answered 9/12, 2012 at 12:8 Comment(1)

I think this is only possible with rooting your device. – Conversationalist 9/12, 2012 at 12:10

A

4

Mobile networks perform lossy transcoding on voice channels, for example with

"Native" encoding/decoding
echo cancelers,
noise generators or
codec changes.

Therefore I doubt that an encrypted voice data stream survives transmission via a mobile network in a way that allows decryption on the receiving side.

Simple analogy: audio -> encrypt -> MP3 compression -> MP3 decoding -> decrypt -> audio. This may not work. Or: if you make this work then you have a chance of transporting the encrypted stream via a voice bearer.

Your option would be to do that on a data bearer, transporting the encrypted voice via IP. But this requires a separate telephony application on the mobile devices.

Anglofrench answered 9/12, 2012 at 16:37 Comment(5)

I don't think mp3 example is relevant here. mp3 is signal specific compression. In GSM there is already encrypting and compression (A51 if I remember) so with your mp3 analogy GSM would be impossible. I could use SAME algorithm that GSM uses, just with MY key. The main question is do I have get/setStream() interface for GSM channel via JME/Android. – Movie 9/12, 2012 at 19:20

GSM does signal specific compression as well, that is the whole point of my MP3 example. Transporting compressed MP3 via GSM voice will not work. You cannot use the GSM algortihm with your own key because the GSM network decrypts in the BSC, i.e. this is not end-to-end encryption. You would need to make the network aware of your key. Even if you would have get/setStream(), the data you inject here must have audio properties, i.e. they must work with the GSM codecs. Encrypted audio likely will not work. – Anglofrench 9/12, 2012 at 21:24

You cannot use the GSM algortihm with your own key because the GSM network decrypts in the BSC, this is not end-to-end encryption. So decrypt will fail, but that only means that calling to fixed telephony will not work, but with other cell phone that decrypts it, it should. Even if you would have get/setStream(), the data you inject here must have audio properties, i.e. they must work with the GSM codecs. getStream() should return byte[], and setStream(byte[] stream) is taking binary stream for argument, so binary stream is binary stream, it is irrelevant what that was in analog domain. – Movie 9/12, 2012 at 23:8

readStream() returns byte[], and writeToStream(byte[] data) to be more precise. – Movie 9/12, 2012 at 23:18

The transmission channel is not guaranteed to be transparent. Therefore your stream will not be reliably transported, irregardless if the B subscriber (called number) is fixed or mobile or VoIP. – Anglofrench 10/12, 2012 at 19:37

A

5

As per above few comments that level of access to voice calls is only possible with a rooted phone, and even then device specific. Best you could do for a generic encrypted voice application is a VOIP / SIP style application which would use a data connection.

Even if you could do it encrypting over an analog call would be non-trivial. The compression used in GSM codecs is optimised for voice and makes certain assumptions about the characteristics of the signal. You couldn't just use a simple analog -> digital -> encrypt -> analog -> phone network -> analog -> digital -> decrypt -> analog type signal chain.

You might notice I've included analog as a step, because all the final digital encoding to the GSM network is performed by the GSM radio chipset you don't get access to from any phone even if rooted.

Advisable answered 9/12, 2012 at 12:51 Comment(2)

So there are no getAudioStream() and setAudioStream() interfaces for GSM channel? (JME/Android) – Movie 9/12, 2012 at 13:51

No, although they might technically be shown as supported by the class hierarchy (not sure) I'm confident they won't actually work on virtually any phone. – Advisable 9/12, 2012 at 14:0

A

4

Mobile networks perform lossy transcoding on voice channels, for example with

"Native" encoding/decoding
echo cancelers,
noise generators or
codec changes.

Therefore I doubt that an encrypted voice data stream survives transmission via a mobile network in a way that allows decryption on the receiving side.

Simple analogy: audio -> encrypt -> MP3 compression -> MP3 decoding -> decrypt -> audio. This may not work. Or: if you make this work then you have a chance of transporting the encrypted stream via a voice bearer.

Your option would be to do that on a data bearer, transporting the encrypted voice via IP. But this requires a separate telephony application on the mobile devices.

Anglofrench answered 9/12, 2012 at 16:37 Comment(5)

I don't think mp3 example is relevant here. mp3 is signal specific compression. In GSM there is already encrypting and compression (A51 if I remember) so with your mp3 analogy GSM would be impossible. I could use SAME algorithm that GSM uses, just with MY key. The main question is do I have get/setStream() interface for GSM channel via JME/Android. – Movie 9/12, 2012 at 19:20

GSM does signal specific compression as well, that is the whole point of my MP3 example. Transporting compressed MP3 via GSM voice will not work. You cannot use the GSM algortihm with your own key because the GSM network decrypts in the BSC, i.e. this is not end-to-end encryption. You would need to make the network aware of your key. Even if you would have get/setStream(), the data you inject here must have audio properties, i.e. they must work with the GSM codecs. Encrypted audio likely will not work. – Anglofrench 9/12, 2012 at 21:24

You cannot use the GSM algortihm with your own key because the GSM network decrypts in the BSC, this is not end-to-end encryption. So decrypt will fail, but that only means that calling to fixed telephony will not work, but with other cell phone that decrypts it, it should. Even if you would have get/setStream(), the data you inject here must have audio properties, i.e. they must work with the GSM codecs. getStream() should return byte[], and setStream(byte[] stream) is taking binary stream for argument, so binary stream is binary stream, it is irrelevant what that was in analog domain. – Movie 9/12, 2012 at 23:8

readStream() returns byte[], and writeToStream(byte[] data) to be more precise. – Movie 9/12, 2012 at 23:18

The transmission channel is not guaranteed to be transparent. Therefore your stream will not be reliably transported, irregardless if the B subscriber (called number) is fixed or mobile or VoIP. – Anglofrench 10/12, 2012 at 19:37

A

2

The GSM full rate speech codec operates at 13 kbits/s and uses a Regular Pulse Excited (RPE) codec - This means that the microphone and speech detection in GSM is optimised for transmission across a Time Division Multiplexed 'digital' channel that is then modulated across the air interface using GMSK, a continuous-phase frequency-shift keying modulation scheme.

Noises other than the 'average' speech pattern are heavily distorted (or suppressed) - For instance DTMF (tones) are not well received on a device, and must be transmitted by the network core, but tones designed for the hearing impaired work well. Voice is shaped (filtered) on entry to the codec (microphone design) for best codec detection and reproduction at the other end.

In summary - It is not possible to 're-modulate' across the GSM system, because the entry point is not a radio (air interface), or even access the GSM digital frame. Your only access for a voice call is the GSM codec which is expecting a voice in a confined audio spectrum.

However - If you can create a voice like waveform for the GSM codec, then you may have a way forward

Arbitrate answered 9/12, 2014 at 23:10 Comment(0)

I

1

I know there are apps that act like voice changer where they change your voice and transmit that thru gsm voice. Maybe you can make an app that takes the voice then modulate it to something like phase shift keying or digital radio monodiale like what hams used in vhf and hf radio communication and transmit the audio to gsm then demodulate it back to voice but instead of straight forward modulation demodulation you can add pgp, aes, or whatever encryption you like. I'm also intrested to see a project like this.

I think it would also be great if you could use this to transmit data thru voice gsm channel like the 56k modems in the past instead of the gprs channel.

See reference

http://freedv.org/tiki-index.php

http://www.aprs.org

Incurvate answered 9/12, 2014 at 7:3 Comment(0)

F

1

Encode analog voice at speaker/MIC site is more practical. Or, you have to root Android to modify phone.APP. Just like AECall. It encrypt and decrypt headset. http://mrhyper.blogspot.tw/2015/12/iphone-encrypt-phone-call_9.html

Fellner answered 28/1, 2016 at 2:48 Comment(0)

Recommended topics

Hot tags