EU set to bug VOIP computer-to-computer phone conversations.

Run_to_da_hills

In another treat on out civil liberties, the EU Parlament is looking into ways and means of tapping into private VOIP conversations.

Skype, an Danish-Swedish business developed by Estonian programmers that was sold to E-Bay in 2005 and has over 350 million customers worldwide, is said to be un-spyable by intelligence services.

In its press release, Eurojust says that "Skype has so far refused to share its encryption system with national authorities."

http://www.pcworld.com/businesscenter/article/159896/skype_calls_immunity_to_police_phone_tapping_threatened.html

Some_Person

The EU can f*** right off.

matrim

Run_to_da_hills wrote: »

In another treat on out civil liberties, the EU Parlament is looking into ways and means of tapping into private VOIP conversations.

Skype, an Danish-Swedish business developed by Estonian programmers that was sold to E-Bay in 2005 and has over 350 million customers worldwide, is said to be un-spyable by intelligence services.

In its press release, Eurojust says that "Skype has so far refused to share its encryption system with national authorities."

http://www.pcworld.com/businesscenter/article/159896/skype_calls_immunity_to_police_phone_tapping_threatened.html

Most large VoIP services are going to have some form of legal intercept in place, where they can both trace who you called and when and also in alot of cases trace the calls themselves.

This is no different to what you get with a PSTN or GSM service where the operators will have some form of legal intercept service in place. In many countries this is already a legal requirement to have legal intercept in place. It's not going to be turned on for all users all the time as doing so would be very cost prohibitive for the operator but if requested with by the police (with a court order) can be turned on.

gerryo

If the call is a "true" VoIP to Voip call (i.e., no part over the PSTN), then it's very hard to intercept the speech because only the signalling portion is via the providers network. The audio travels direct from VoIP client to Voip client, & there are many encryption facilities which make it really difficult to eavesdrop on the conversation.

Even using a non standard (custom) codec is probably enough if you want to keep others in the dark. OK, they can tell who you called/who called you, but you can sure keep the conversation to yourself if you really want to.

matrim

gerryo wrote: »

If the call is a "true" VoIP to Voip call (i.e., no part over the PSTN), then it's very hard to intercept the speech because only the signalling portion is via the providers network. The audio travels direct from VoIP client to Voip client, & there are many encryption facilities which make it really difficult to eavesdrop on the conversation.

That's not true. In order to traverse NATs, most providers will provide an RTP proxy which will also proxy the audio through the providers network.

gerryo

matrim wrote: »

That's not true. In order to traverse NATs, most providers will provide an RTP proxy which will also proxy the audio through the providers network.

Fair point!
Tbh, I was really referring to direct user-to-user Voip, but yes, some big Voip providers might use media proxies. You can still encrypt the voice side though even if it is RTP proxied.

In the end, there is always a way to encrypt the speech, example, create your own codec, fft, bit manipulation, etc. It's a lot of trouble though, so remember the old saying that if you don't want some information widely known - tell no one

matrim

gerryo wrote: »

Fair point!
Tbh, I was really referring to direct user-to-user Voip, but yes, some big Voip providers might use media proxies. You can still encrypt the voice side though even if it is RTP proxied.

In the end, there is always a way to encrypt the speech, example, create your own codec, fft, bit manipulation, etc. It's a lot of trouble though, so remember the old saying that if you don't want some information widely known - tell no one

As with anything if you really want to you can get around it, but how many normal users will have the knowledge to do it. I work in VoIP (SIP based) and recently done some tests with this. The simplest thing I did was hardcode the encryption key and then use AES to encrypt the audio in the RTP stream.

The main problem comes when you don't use a hardcoded keys and need to share it with the other user. This must be included somewhere in the stream and that's when it can be sniffed by the provider as this is normally done in the (secures) SIP signaling.

towel401

time to start using one-time pads

Wcool

matrim wrote: »

The main problem comes when you don't use a hardcoded keys and need to share it with the other user. This must be included somewhere in the stream and that's when it can be sniffed by the provider as this is normally done in the (secures) SIP signaling.

Forgive me my ignorance but why can't some public key encryption be implemented? I am thinking about this scenario:
I have a public and private key, the private key will be securely stored in my ATA box, the public key will be uploaded to my SIP server (or could be requested via my SIP server from me directly). When another person makes a call to me, that persons public key is uploaded to my SIP server and distributed to my ATA box. And the caller downloads my public key as well.

Now you could create fully encrypted phone calls? All it needs is an extension of the SIP protocol?

matrim

Wcool wrote: »

Forgive me my ignorance but why can't some public key encryption be implemented? I am thinking about this scenario:
I have a public and private key, the private key will be securely stored in my ATA box, the public key will be uploaded to my SIP server (or could be requested via my SIP server from me directly). When another person makes a call to me, that persons public key is uploaded to my SIP server and distributed to my ATA box. And the caller downloads my public key as well.

Now you could create fully encrypted phone calls? All it needs is an extension of the SIP protocol?

I don't see any reason that this can't be used.

The current specs have AES as the encryption with a new key per session, but any encryption could be used once people agreed on it. In fact I think some people have implemented it with 3DES.

Once the encryption method isn't too heavy (to introduce latency) it can be used and the key's can be passed in an agreed way.

Wcool

There are some excellent projects on the web, dealing with VOIP security:

http://zfoneproject.com/

This is a project started by Phil Zimmermann of PGP fame. Looks very interesting, I am going to try it out.

The problem is of course that both sides need to have the software.
This is probably the reason we still send email as plaintext.
But it makes you wonder why they didn't include encryption right from the start into protocols like SIP or Jabber.

Worrying is this: http://www.freepatentsonline.com/EP1724964.html

It seems Hitachi is patenting the obvious