[SR-Users] Obscuring SIP traffic and using with NoSIP

[Muhammad Shahzad]

Hi,

As the mobile voip is getting more and more popular these days, there has
been a strong opposition from GSM operators against mobile voip apps. They
often use tactics like blocking voip ports, or detect and block voip
traffic and in some cases restricting udp traffic altogether to very low
upload and download speeds. See below link for some details,

http://www.linphone.org/eng/blog/linphone-over-3g.html

While not all the problems can be solved right now (especially the limiting
udp traffic, since RTP always uses udp transport) I was wondering if we can
at least handle the sip related problems. The most important of them is SIP
traffic detection. While some forks would suggest using TCP/TLS to encrypt
SIP traffic, it has a few problems, e.g.

1. It requires somewhat high resources on mobile devices, so many low-end
android phones simply can't use it.

2. There is possibility that encryption signature may identify it as SIP
traffic. There exists firewalls (often deployed in middle eastern
countries) which have huge database of encryption signatures and patterns
which although may not decrypt the sip packet but at least identify it as
sip packet and block it.

Also with rough agencies of evil empires spying over millions of users
worldwide makes the current encryption standards pretty much pointless, at
least in terms of user privacy and network security. So there is a strong
need to experiment with new ideas and concepts to regain internet freedom.
Some of such ideas are,

1. Convert sip traffic which is plain text to binary format just before
transmitting it and revert it to plain text upon reception.

2. XOR the sip traffic (pretty much same as binary sip).

3. Use some very lightweight but effective / non-standard encryption
algorithm, e.g.

https://github.com/mshary/itv

All these ideas require that SIP server such as Kamailio is able to adopt
to these, preferably with minimal or no change in native code. The NoSIP
module seems an interesting module in this regard. It provides all traffic
it thinks is not the SIP traffic to configuration script, where we can do
our own parsing and do whatever we want with it. I have two questions about
this,

1. If parsed message is SIP, we can we send it back to kamailio core to get
it processed as if it is a normal SIP message received by kamailio?

2. Can this module or any other module available in kamailio, that can
provide us full sip packet that is about to be transmitted over sip socket,
so we can "encode" it just before it is sent to next hop?

I know this would be like writing a SIP transport in kamailio script which
would be very tough if not impossible to implement in native core. But it
will really help in winning the modern mobile voip challenges.

Thank you.

[Muhammad Shahzad]

Humm, no reply so far, may be because my email was very long and no body
bothered to read it all. Anyways, here is the shorter more direct version
of it. (including kamailio dev list, since question is rather technical).

Is it possible to implement a custom SIP transport in Kamailio script file
i.e. kamailio.cfg. The purpose is to allow experimentation with custom
encryption algorithms such as this,

https://github.com/mshary/itv

What we need is a couple of functions, one to receive incoming raw /
encrypted data received on SIP socket, which then can be parsed / decrypted
in kamailio.cfg (using e.g. LUA or PERL language modules etc.) and
afterwords feed to kamailio for usual processing (as if it was normal /
plain-text sip data received on sip socket). The second function to do the
opposite, it receives the normal / plain-text sip data that is ready to be
sent out from kamailio's core, encrypts it and then send it out to actual
destination.

In case above is not possible. Can i do it in kamailio's native code? Any
hooks / example code for reference?

Many thanks and kind regards for your help.

Post by Muhammad Shahzad
Hi,
As the mobile voip is getting more and more popular these days, there has
been a strong opposition from GSM operators against mobile voip apps. They
often use tactics like blocking voip ports, or detect and block voip
traffic and in some cases restricting udp traffic altogether to very low
upload and download speeds. See below link for some details,
http://www.linphone.org/eng/blog/linphone-over-3g.html
While not all the problems can be solved right now (especially the
limiting udp traffic, since RTP always uses udp transport) I was wondering
if we can at least handle the sip related problems. The most important of
them is SIP traffic detection. While some forks would suggest using TCP/TLS
to encrypt SIP traffic, it has a few problems, e.g.
1. It requires somewhat high resources on mobile devices, so many low-end
android phones simply can't use it.
2. There is possibility that encryption signature may identify it as SIP
traffic. There exists firewalls (often deployed in middle eastern
countries) which have huge database of encryption signatures and patterns
which although may not decrypt the sip packet but at least identify it as
sip packet and block it.
Also with rough agencies of evil empires spying over millions of users
worldwide makes the current encryption standards pretty much pointless, at
least in terms of user privacy and network security. So there is a strong
need to experiment with new ideas and concepts to regain internet freedom.
Some of such ideas are,
1. Convert sip traffic which is plain text to binary format just before
transmitting it and revert it to plain text upon reception.
2. XOR the sip traffic (pretty much same as binary sip).
3. Use some very lightweight but effective / non-standard encryption
algorithm, e.g.
https://github.com/mshary/itv
All these ideas require that SIP server such as Kamailio is able to adopt
to these, preferably with minimal or no change in native code. The NoSIP
module seems an interesting module in this regard. It provides all traffic
it thinks is not the SIP traffic to configuration script, where we can do
our own parsing and do whatever we want with it. I have two questions about
this,
1. If parsed message is SIP, we can we send it back to kamailio core to
get it processed as if it is a normal SIP message received by kamailio?
2. Can this module or any other module available in kamailio, that can
provide us full sip packet that is about to be transmitted over sip socket,
so we can "encode" it just before it is sent to next hop?
I know this would be like writing a SIP transport in kamailio script which
would be very tough if not impossible to implement in native core. But it
will really help in winning the modern mobile voip challenges.
Thank you.

[Daniel-Constantin Mierla]

Post by Muhammad Shahzad
Humm, no reply so far, may be because my email was very long and no
body bothered to read it all. Anyways, here is the shorter more direct
version of it. (including kamailio dev list, since question is rather
technical).
Is it possible to implement a custom SIP transport in Kamailio script
file i.e. kamailio.cfg. The purpose is to allow experimentation with
custom encryption algorithms such as this,
https://github.com/mshary/itv
What we need is a couple of functions, one to receive incoming raw /
encrypted data received on SIP socket, which then can be parsed /
decrypted in kamailio.cfg (using e.g. LUA or PERL language modules
etc.) and afterwords feed to kamailio for usual processing (as if it
was normal / plain-text sip data received on sip socket). The second
function to do the opposite, it receives the normal / plain-text sip
data that is ready to be sent out from kamailio's core, encrypts it
and then send it out to actual destination.
In case above is not possible. Can i do it in kamailio's native code?
Any hooks / example code for reference?

If you look at encrypting sip messages, look at topoh module. You can
write a replacement for its hooks. Topoh is practically decoding the
headers and then lets the pure SIP message go through config file
execution. Before sending, it encodes the headers and then let it go to
the network.

This is something that should be rather straightforward to do if you are
familiar with C code.

You mentioned that using TLS can still reveal patters of being sip. You
have to think here of ways to obfuscate even in your case of a new
encryption method. What can be matched here:
- periodical registrations - you can have the client (or even the
server) to use different expires times for each registration
- size of packages, specially if user IDs are the same or similar length
(e.g., say everyone uses a 10 digit id), practically no matter who is
calling who, the size will be pretty much the same because most of the
phones I have seen so far use same set of headers. Here you can add
random custom headers for each packet. I haven't checked the proposed
encryption algorithm (some use random blocks implicitly to pad the
data), but eventually you can add random data before and after the
packet that you strip (and re-add) in topoh-replacement module

The other option of having a totally different protocol than SIP should
be possible as well. But you need to re-implement a lot (like location,
authentication, ...). Look at msrp module for an example. This may need
to touch core code a bit.

Of course, in both cases, the client application has to be developed as
well. Perhaps still easier if going for first option, by reusing some
open source sip client and adding the encapsulation/decapsulation layer
when receiving/sending to network.

Cheers,
Daniel

Post by Muhammad Shahzad
Many thanks and kind regards for your help.
On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad
Hi,
As the mobile voip is getting more and more popular these days,
there has been a strong opposition from GSM operators against
mobile voip apps. They often use tactics like blocking voip ports,
or detect and block voip traffic and in some cases restricting udp
traffic altogether to very low upload and download speeds. See
below link for some details,
http://www.linphone.org/eng/blog/linphone-over-3g.html
While not all the problems can be solved right now (especially the
limiting udp traffic, since RTP always uses udp transport) I was
wondering if we can at least handle the sip related problems. The
most important of them is SIP traffic detection. While some forks
would suggest using TCP/TLS to encrypt SIP traffic, it has a few
problems, e.g.
1. It requires somewhat high resources on mobile devices, so many
low-end android phones simply can't use it.
2. There is possibility that encryption signature may identify it
as SIP traffic. There exists firewalls (often deployed in middle
eastern countries) which have huge database of encryption
signatures and patterns which although may not decrypt the sip
packet but at least identify it as sip packet and block it.
Also with rough agencies of evil empires spying over millions of
users worldwide makes the current encryption standards pretty much
pointless, at least in terms of user privacy and network security.
So there is a strong need to experiment with new ideas and
concepts to regain internet freedom. Some of such ideas are,
1. Convert sip traffic which is plain text to binary format just
before transmitting it and revert it to plain text upon reception.
2. XOR the sip traffic (pretty much same as binary sip).
3. Use some very lightweight but effective / non-standard
encryption algorithm, e.g.
https://github.com/mshary/itv
All these ideas require that SIP server such as Kamailio is able
to adopt to these, preferably with minimal or no change in native
code. The NoSIP module seems an interesting module in this regard.
It provides all traffic it thinks is not the SIP traffic to
configuration script, where we can do our own parsing and do
whatever we want with it. I have two questions about this,
1. If parsed message is SIP, we can we send it back to kamailio
core to get it processed as if it is a normal SIP message received
by kamailio?
2. Can this module or any other module available in kamailio, that
can provide us full sip packet that is about to be transmitted
over sip socket, so we can "encode" it just before it is sent to
next hop?
I know this would be like writing a SIP transport in kamailio
script which would be very tough if not impossible to implement in
native core. But it will really help in winning the modern mobile
voip challenges.
Thank you.

[Muhammad Shahzad]

Thank you so much for this very useful information. I am working on first
approach for the moment since its much simpler and easier to implement with
only difference being that instead of per header or per sdp line, i plan to
do it in one go, i.e. get entire sip message in $mb (sip message buffer),
encrypt it and put it back in $mb.

- i guess randomizing registration time is already provided by kamailio.
- yes packet sizes are a concern, so i already have planned for random
padding as you mentioned.

For client app, i have a developed a basic prototype based on doubango
framework. I am hopping to release a free and open source implementation
using idoubs within next couple of months on Apple app store.

Thank you.




On Wed, Jul 30, 2014 at 12:22 PM, Daniel-Constantin Mierla <

Post by Muhammad Shahzad
Humm, no reply so far, may be because my email was very long and no body
bothered to read it all. Anyways, here is the shorter more direct version
of it. (including kamailio dev list, since question is rather technical).
Is it possible to implement a custom SIP transport in Kamailio script
file i.e. kamailio.cfg. The purpose is to allow experimentation with custom
encryption algorithms such as this,
https://github.com/mshary/itv
What we need is a couple of functions, one to receive incoming raw /
encrypted data received on SIP socket, which then can be parsed / decrypted
in kamailio.cfg (using e.g. LUA or PERL language modules etc.) and
afterwords feed to kamailio for usual processing (as if it was normal /
plain-text sip data received on sip socket). The second function to do the
opposite, it receives the normal / plain-text sip data that is ready to be
sent out from kamailio's core, encrypts it and then send it out to actual
destination.
In case above is not possible. Can i do it in kamailio's native code?
Any hooks / example code for reference?
If you look at encrypting sip messages, look at topoh module. You can
write a replacement for its hooks. Topoh is practically decoding the
headers and then lets the pure SIP message go through config file
execution. Before sending, it encodes the headers and then let it go to the
network.
This is something that should be rather straightforward to do if you are
familiar with C code.
You mentioned that using TLS can still reveal patters of being sip. You
have to think here of ways to obfuscate even in your case of a new
- periodical registrations - you can have the client (or even the server)
to use different expires times for each registration
- size of packages, specially if user IDs are the same or similar length
(e.g., say everyone uses a 10 digit id), practically no matter who is
calling who, the size will be pretty much the same because most of the
phones I have seen so far use same set of headers. Here you can add random
custom headers for each packet. I haven't checked the proposed encryption
algorithm (some use random blocks implicitly to pad the data), but
eventually you can add random data before and after the packet that you
strip (and re-add) in topoh-replacement module
The other option of having a totally different protocol than SIP should be
possible as well. But you need to re-implement a lot (like location,
authentication, ...). Look at msrp module for an example. This may need to
touch core code a bit.
Of course, in both cases, the client application has to be developed as
well. Perhaps still easier if going for first option, by reusing some open
source sip client and adding the encapsulation/decapsulation layer when
receiving/sending to network.
Cheers,
Daniel
Many thanks and kind regards for your help.

Post by Muhammad Shahzad
Hi,
As the mobile voip is getting more and more popular these days, there
has been a strong opposition from GSM operators against mobile voip apps.
They often use tactics like blocking voip ports, or detect and block voip
traffic and in some cases restricting udp traffic altogether to very low
upload and download speeds. See below link for some details,
http://www.linphone.org/eng/blog/linphone-over-3g.html
While not all the problems can be solved right now (especially the
limiting udp traffic, since RTP always uses udp transport) I was wondering
if we can at least handle the sip related problems. The most important of
them is SIP traffic detection. While some forks would suggest using TCP/TLS
to encrypt SIP traffic, it has a few problems, e.g.
1. It requires somewhat high resources on mobile devices, so many
low-end android phones simply can't use it.
2. There is possibility that encryption signature may identify it as SIP
traffic. There exists firewalls (often deployed in middle eastern
countries) which have huge database of encryption signatures and patterns
which although may not decrypt the sip packet but at least identify it as
sip packet and block it.
Also with rough agencies of evil empires spying over millions of users
worldwide makes the current encryption standards pretty much pointless, at
least in terms of user privacy and network security. So there is a strong
need to experiment with new ideas and concepts to regain internet freedom.
Some of such ideas are,
1. Convert sip traffic which is plain text to binary format just before
transmitting it and revert it to plain text upon reception.
2. XOR the sip traffic (pretty much same as binary sip).
3. Use some very lightweight but effective / non-standard encryption
algorithm, e.g.
https://github.com/mshary/itv
All these ideas require that SIP server such as Kamailio is able to
adopt to these, preferably with minimal or no change in native code. The
NoSIP module seems an interesting module in this regard. It provides all
traffic it thinks is not the SIP traffic to configuration script, where we
can do our own parsing and do whatever we want with it. I have two
questions about this,
1. If parsed message is SIP, we can we send it back to kamailio core to
get it processed as if it is a normal SIP message received by kamailio?
2. Can this module or any other module available in kamailio, that can
provide us full sip packet that is about to be transmitted over sip socket,
so we can "encode" it just before it is sent to next hop?
I know this would be like writing a SIP transport in kamailio script
which would be very tough if not impossible to implement in native core.
But it will really help in winning the modern mobile voip challenges.
Thank you.

--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

[Daniel-Constantin Mierla]

Post by Muhammad Shahzad
Thank you so much for this very useful information. I am working on
first approach for the moment since its much simpler and easier to
implement with only difference being that instead of per header or per
sdp line, i plan to do it in one go, i.e. get entire sip message in
$mb (sip message buffer), encrypt it and put it back in $mb.
- i guess randomizing registration time is already provided by kamailio.
- yes packet sizes are a concern, so i already have planned for random
padding as you mentioned.
For client app, i have a developed a basic prototype based on doubango
framework. I am hopping to release a free and open source
implementation using idoubs within next couple of months on Apple app
store.

For a mobile device, an app is needed. But for a linux computer, it
might works running a kamailio proxy there. Say you have many locations
for a company, then within local network on each site can be sip and
between sites, the encrypted signaling.

If kamailio uses a socket for clients and a socket for communicating
with the other sides, then it is easy to tell to the new module for
which socket should do encryption/decryption. Alternative is to provide
either local network address or remote site address and match on src
ip/dst ip.

Cheers,
Daniel

Post by Muhammad Shahzad
Thank you.
On Wed, Jul 30, 2014 at 12:22 PM, Daniel-Constantin Mierla

Post by Muhammad Shahzad
Humm, no reply so far, may be because my email was very long and
no body bothered to read it all. Anyways, here is the shorter
more direct version of it. (including kamailio dev list, since
question is rather technical).
Is it possible to implement a custom SIP transport in Kamailio
script file i.e. kamailio.cfg. The purpose is to allow
experimentation with custom encryption algorithms such as this,
https://github.com/mshary/itv
What we need is a couple of functions, one to receive incoming
raw / encrypted data received on SIP socket, which then can be
parsed / decrypted in kamailio.cfg (using e.g. LUA or PERL
language modules etc.) and afterwords feed to kamailio for usual
processing (as if it was normal / plain-text sip data received on
sip socket). The second function to do the opposite, it receives
the normal / plain-text sip data that is ready to be sent out
from kamailio's core, encrypts it and then send it out to actual
destination.
In case above is not possible. Can i do it in kamailio's native
code? Any hooks / example code for reference?

If you look at encrypting sip messages, look at topoh module. You
can write a replacement for its hooks. Topoh is practically
decoding the headers and then lets the pure SIP message go through
config file execution. Before sending, it encodes the headers and
then let it go to the network.
This is something that should be rather straightforward to do if
you are familiar with C code.
You mentioned that using TLS can still reveal patters of being
sip. You have to think here of ways to obfuscate even in your case
- periodical registrations - you can have the client (or even the
server) to use different expires times for each registration
- size of packages, specially if user IDs are the same or similar
length (e.g., say everyone uses a 10 digit id), practically no
matter who is calling who, the size will be pretty much the same
because most of the phones I have seen so far use same set of
headers. Here you can add random custom headers for each packet. I
haven't checked the proposed encryption algorithm (some use random
blocks implicitly to pad the data), but eventually you can add
random data before and after the packet that you strip (and
re-add) in topoh-replacement module
The other option of having a totally different protocol than SIP
should be possible as well. But you need to re-implement a lot
(like location, authentication, ...). Look at msrp module for an
example. This may need to touch core code a bit.
Of course, in both cases, the client application has to be
developed as well. Perhaps still easier if going for first option,
by reusing some open source sip client and adding the
encapsulation/decapsulation layer when receiving/sending to network.
Cheers,
Daniel

Post by Muhammad Shahzad
Many thanks and kind regards for your help.
On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad
Hi,
As the mobile voip is getting more and more popular these
days, there has been a strong opposition from GSM operators
against mobile voip apps. They often use tactics like
blocking voip ports, or detect and block voip traffic and in
some cases restricting udp traffic altogether to very low
upload and download speeds. See below link for some details,
http://www.linphone.org/eng/blog/linphone-over-3g.html
While not all the problems can be solved right now
(especially the limiting udp traffic, since RTP always uses
udp transport) I was wondering if we can at least handle the
sip related problems. The most important of them is SIP
traffic detection. While some forks would suggest using
TCP/TLS to encrypt SIP traffic, it has a few problems, e.g.
1. It requires somewhat high resources on mobile devices, so
many low-end android phones simply can't use it.
2. There is possibility that encryption signature may
identify it as SIP traffic. There exists firewalls (often
deployed in middle eastern countries) which have huge
database of encryption signatures and patterns which although
may not decrypt the sip packet but at least identify it as
sip packet and block it.
Also with rough agencies of evil empires spying over millions
of users worldwide makes the current encryption standards
pretty much pointless, at least in terms of user privacy and
network security. So there is a strong need to experiment
with new ideas and concepts to regain internet freedom. Some
of such ideas are,
1. Convert sip traffic which is plain text to binary format
just before transmitting it and revert it to plain text upon
reception.
2. XOR the sip traffic (pretty much same as binary sip).
3. Use some very lightweight but effective / non-standard
encryption algorithm, e.g.
https://github.com/mshary/itv
All these ideas require that SIP server such as Kamailio is
able to adopt to these, preferably with minimal or no change
in native code. The NoSIP module seems an interesting module
in this regard. It provides all traffic it thinks is not the
SIP traffic to configuration script, where we can do our own
parsing and do whatever we want with it. I have two questions
about this,
1. If parsed message is SIP, we can we send it back to
kamailio core to get it processed as if it is a normal SIP
message received by kamailio?
2. Can this module or any other module available in kamailio,
that can provide us full sip packet that is about to be
transmitted over sip socket, so we can "encode" it just
before it is sent to next hop?
I know this would be like writing a SIP transport in kamailio
script which would be very tough if not impossible to
implement in native core. But it will really help in winning
the modern mobile voip challenges.
Thank you.

--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda

[Daniel Tryba]

Post by Muhammad Shahzad
Humm, no reply so far, may be because my email was very long and no body
bothered to read it all. Anyways, here is the shorter more direct version
of it.

I read it all and my only though was: use a VPN.

If someone wants to stop SIP, it has an easy to spot pattern.
If someone wants to stop VPN, they will drop every non clear connection which
doesn't match a known non-VPN pattern.

If I was afraid of my telco listening in on my SIP dialogs, I'd also want to
encrypt RTP. Which is much more resource intensive than encrypting a few SIP
messages. So if you think standard tls is to intensive you'll also have to
create some custom lightweight rtp mangling.

[Muhammad Shahzad]

The key purpose of ITV encryption is to avoid making a pattern of any sort.
If you encrypt same text / packet 10 times you will get completely
different encrypted text / packet each time. This happens due to the fact
that the encryption key changes dynamically with each new encryption done,
see the readme file for more details

https://github.com/mshary/itv/blob/master/README.md

Secondly with v2.0, it uses non-deterministic random source as well as
auto-learning, so it can adopt to new symbols and words encountered while
encrypting and update itself to use them. So technically, it can also be
used for binary data such as RTP, however RTP uses UDP which has
possibility of packet loss and thus not suitable for ITV encryption (at
least for now, this is a hot discussion within my researchers circle and we
are actively looking for a solution for this).

See release notes for v2.0 here,

https://github.com/mshary/itv/releases/tag/v2.0

Anyways, the current target is to use kamailio as SIP proxy and doubango as
SIP client for iPhone and Android. Once it is achieved it will be available
free / open source to public and then it can be actually tested against all
possible voip blocking and sniffing scenarios which we hope it would be
able to solve with minimal possible overhead. So far the prototype works
pretty good in a few voip blocked countries and GSM operators where we have
tested it.

Thank you.

Post by Daniel Tryba

Post by Muhammad Shahzad
Humm, no reply so far, may be because my email was very long and no body
bothered to read it all. Anyways, here is the shorter more direct version
of it.

I read it all and my only though was: use a VPN.
If someone wants to stop SIP, it has an easy to spot pattern.
If someone wants to stop VPN, they will drop every non clear connection which
doesn't match a known non-VPN pattern.
If I was afraid of my telco listening in on my SIP dialogs, I'd also want to
encrypt RTP. Which is much more resource intensive than encrypting a few SIP
messages. So if you think standard tls is to intensive you'll also have to
create some custom lightweight rtp mangling.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Daniel Tryba]

[remove dev from cc]

Post by Muhammad Shahzad
The key purpose of ITV encryption is to avoid making a pattern of any sort.

The pattern is in SIP itself, regardless of encryption.

-OPTIONS keepalives and response at regular intervals of nearly fixed size.
-INVITE and its predictable responses of nearly fixed sizes per type followed
by a steady stream of upd on random ports with the same bandwidth flowing both
sides.

Unless this random utp traffic is encrypted it is obvious you are using rtp
with something like SIP. Even if it is encrypted the symmetric streams give
away clues. A simple xor isn't enough, silences will result in the same
pattern.

Daniel(-Constanting) already suggested interval randomizing (which is to be
applied to any response) and padding of all data.

But I wouldn't trust any non vetted encryption scheme, it is much easier to
fix timing/padding with the standard tls scheme. Which brings me to the
question: what kind of device on the market capable of running apps isn't fast
enough for TLS?

[Muhammad Shahzad]

Thanks for good insight in to this topic.

As mentioned in my first email, there are a number of reasons for trying
out custom encryption schemes. Low-end android devices is just one of them.
There is a huge market for low-end android devices in south and south east
Asia for example, where over 35% of world population lives. The people
there are poor and don't have much understanding of latest cutting edge
smart devices and related technologies. Big brands like Apple, Samsung,
Nokia etc. are virtually non-existent or have so high price that people
simply can't afford them. So cheap Chinese and Indian cell phones which
barely run Android are considered "smart phones" and are very popular here.
Using SSL, TLS, DTLS etc. are nightmare on these devices.

The other reasons to develop and try out custom encryption algorithms are
voip blockage by GSM providers in various Middle Eastern and European
counties,

http://www.linphone.org/news/11/26/Linphone-over-3G.html
http://xerocrypt.wordpress.com/2012/07/06/inspecting-your-packets/
http://www.telecomrecorder.com/world-premium-telecom/pak-telecom-authority/pta-and-ip-blocking/

And the rogue agencies of evil empires,

http://en.wikipedia.org/wiki/Five_Eyes
http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29
http://en.wikipedia.org/wiki/Booz_Allen_Hamilton#Activities_in_foreign_countries
http://www.itv.com/news/update/2013-09-06/report-us-and-uk-agencies-cracked-encryption-codes/

Nearly all encryption algorithms are defined and advocated by US and UK
intelligence agencies and it is quite obviously possible that they either
have crack or backdoors into them. So, we can't blindly trust them anymore
and should look into defining our own algorithms and security standards.

Just to note, i don't claim that ITV or any other custom encryption
discussed here can or would resolve all these problems. The main focus is
on trying something new and out of the box to improve the voip and network
security conditions. I find Kamailio as open source SIP server and doubango
as open source SIP SDK as best platforms for these efforts and
experimentation.

Thank you.

Post by Daniel Tryba
[remove dev from cc]

Post by Muhammad Shahzad
The key purpose of ITV encryption is to avoid making a pattern of any

sort.
The pattern is in SIP itself, regardless of encryption.
-OPTIONS keepalives and response at regular intervals of nearly fixed size.
-INVITE and its predictable responses of nearly fixed sizes per type
followed
by a steady stream of upd on random ports with the same bandwidth flowing
both
sides.
Unless this random utp traffic is encrypted it is obvious you are using rtp
with something like SIP. Even if it is encrypted the symmetric streams give
away clues. A simple xor isn't enough, silences will result in the same
pattern.
Daniel(-Constanting) already suggested interval randomizing (which is to be
applied to any response) and padding of all data.
But I wouldn't trust any non vetted encryption scheme, it is much easier to
fix timing/padding with the standard tls scheme. Which brings me to the
question: what kind of device on the market capable of running apps isn't
fast
enough for TLS?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users