U.S. Government Issues Report on VoIP Security Holes
ranson writes "PC World is reporting on VoIP technology's threat of being manipulated by hackers, through call interception and DoS attacks on users' internet connections. While these threats are nothing new, the article cites an interesting government report on the topic, as well as its author, who believes a VoIP user's best protection is security by obscurity."
The fact that you know what calea is, says that you already know more than you are letting on. Yes, the average /.er knows about the patriot act, but few know about calea.
But for the record, calea has nothing to do with VOIP/SIP being encrypted or not. It was more about keeping it simple. Then you are free to add encryption at a lower layer. Much easier to add encryption just prior to the net.
Ok, we have "security by obscurity".
.
Erm, isnt our current knowledge of encryption technology based much on secret numbers? Well, it is 1 in 2^128 or 2^256 or some huge number, but is this teh similar analogy you use?
Well, first off security CAN be improved, but it uses the same techniques I use for software protections.
There should be no meta-data telling what encrypted the data, what encryption schemes, or whatever to even start off. You should consider these to be the first 'shared secrets'. This has a side benefit as when a 3'rd party attempts to decrypt it, it just gives garbage in which SOMETHING has to interpet. It should not be as simple as "GPG v3.2 Diffie-Helman 4096 bit key" does not match
Next off, all decrption attempts should go through. What would you rather do: scan the encrypted files for headers in which to try dictionaries OR be forced to try all types of encryption to try to guess which one does what (if you can).
The next, for network security, is 'knock knock' scripts. Whats safer: login/passwd prompt on ssh OR 10 timed packets aimed at different ports (that change on time of day) that then proceeds to open ssh until disconnect?
I know what I'd choose if it was my security depended on hiding, firewalling THEN login/passwords.
The whole point is OBFUSCATION is a valid security mechanism, not that is the end-all be-all or anything, but it does have its places.
Ain't this grand?
6-8 weeks ago I exchanged email with Vonage on this very subject. What security protocols do they follow for protecting signaling/bearer traffic? big black hole getting meaningful information - but was _assured_ they used 256 bit encryption with a xx bit nonce. Now I read a Vonage representative is asserting they do not perform encryption? Somebody was not telling the truth.
Regarding CALEA: when you make a phone call (UMTS,GSM,VoIP- doesn't matter), your connection is routed via a switch. Between your phone and the switch is where encryption, if used, is applied. Once your traffic reaches the switch edge, it is decrypted. Afer it is decrypted and in the switch is where CALEA gets it's hands on it. The traffic is then (depending on the destination leg), encrypted using that leg's session key.
As for why Vonage (and except for Skype - maybe others) are not following basic principles for information assurance? I'd say cost. Nobody is screaming for it and they aren't losing sales. Maybe that will change. I really don't think the processing burden could be so great - look at GSM and UMTS. Both are spec'd to do originating/terminating leg encryption.
What I find the most irritating about all this is the canard about a guy with alligator clips tapping my line. Other than breaking into a phone company box - the only place to tap that line (except lawfully in the switch) is at the edge of my house (something I would not react favorably to). But, tapping a VoIP session on a cable-modem local loop (say, by my neighbor) is far less obvious. Maybe more difficult - but more covert. Would it be so difficult to build a protocol analyzer that looks for 1-800 #'s corresponding to phone-order sales and only record those calls?
I'm glad to seee this getting attention. I will admit, if it wasn't for security concerns, I'd have left my POTS by now.
sd_spot
Tell me what you know, tell me what you don't know - but never tell me you know what you don't know