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.
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.
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,
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.
On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad shaheryarkh@gmail.com wrote:
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.
- It requires somewhat high resources on mobile devices, so many low-end
android phones simply can't use it.
- 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,
- Convert sip traffic which is plain text to binary format just before
transmitting it and revert it to plain text upon reception.
XOR the sip traffic (pretty much same as binary sip).
Use some very lightweight but effective / non-standard encryption
algorithm, e.g.
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,
- 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?
- 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.
On 30/07/14 06:37, Muhammad Shahzad wrote:
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,
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
Many thanks and kind regards for your help.
On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad <shaheryarkh@gmail.com mailto:shaheryarkh@gmail.com> wrote:
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.
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 < miconda@gmail.com> wrote:
On 30/07/14 06:37, Muhammad Shahzad wrote:
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,
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
Many thanks and kind regards for your help.
On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad shaheryarkh@gmail.com wrote:
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.
- It requires somewhat high resources on mobile devices, so many
low-end android phones simply can't use it.
- 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,
- Convert sip traffic which is plain text to binary format just before
transmitting it and revert it to plain text upon reception.
XOR the sip traffic (pretty much same as binary sip).
Use some very lightweight but effective / non-standard encryption
algorithm, e.g.
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,
- 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?
- 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
On 30/07/14 11:52, Muhammad Shahzad wrote:
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
Thank you.
On Wed, Jul 30, 2014 at 12:22 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
On 30/07/14 06:37, Muhammad Shahzad wrote: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, DanielMany thanks and kind regards for your help. On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad <shaheryarkh@gmail.com <mailto:shaheryarkh@gmail.com>> wrote: 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
On Wednesday 30 July 2014 06:37:31 Muhammad Shahzad wrote:
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.
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.
On Wed, Jul 30, 2014 at 5:32 PM, Daniel Tryba daniel@pocos.nl wrote:
On Wednesday 30 July 2014 06:37:31 Muhammad Shahzad wrote:
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 sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[remove dev from cc]
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?
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/p...
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_count... http://www.itv.com/news/update/2013-09-06/report-us-and-uk-agencies-cracked-...
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.
On Thu, Jul 31, 2014 at 2:08 PM, Daniel Tryba daniel@pocos.nl wrote:
[remove dev from cc]
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 sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel Tryba -
Daniel-Constantin Mierla -
Muhammad Shahzad