I've scanned over the replies, and haven't seen this mentioned.
Don't assume that the difficult part of the "encryption" requires the plaintext. All you really need (and this is what GSM/UMTS does) is a way to "agree" on a psuedo-random number sequence. You can pre-generate that sequence (within certain constraints) and apply it by an xor to the plaintext. The receiving end does the same.
How do you agree on a psuedo random sequence? You run AES (or any block cipher) in one of its feedback/chaining modes. All you have to agree on then is the IV. Each frame sent from your phone is numbered in some manner. That number helps for packet ordering (I am not necessarily talking about IP header numbering) and also helps the receiver determine what pre-generated sequence to apply. In UMTS/GSM, that "number" is the count parameter and is part of the IV fed into the Rijandal (I doubt that is spelled correctly, sorry).
A pure voice call over POTS requires 64kbps (8bit PCM samples at 8khz sampling rate). A cell phone call requires around 12-15kbps to achieve reasonable voice clarity. The difference is achieved by a codec that takes the analog voice and encodes it into a fixed length vocoder frame. That fixed frame length allows me to pre-generate just enough pseudo random bits to apply "encryption". Note that each frame represents 20 (or so) ms of "speech". Loss of a single frame isn't going to kill you. I do not know the VoIP codec rate. They may even send a PCM stream to/from the VoIP "server".
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.
"Currently we are using Message Digest 5 (MD5) to calculate the hashed result, however this may change in the future to SHA1 (or stronger) if MD5 is found to be too weak."
Has it become "too weak"? I don't know. NIST doesn't say. I guess part of the equation involves what you are protecting. If it is armadillo porn, then no sophisticated attack is likely. If you are protecting a bank account; well maybe the effort would be woth it.
Just some thoughts. I appreciated your detailed explanation of your protection protocol (not unlike GSM, I think).
Sorry for digressing a little, but I see all sorts of comments elsewhere blaming SAIC... asserting incompetence etc. I want to know (and if the agency doing the program review is reading this - take notes).
1. metric of requirement turn
2. total number of functional requirements
3. number of outstanding "requests for clarification or direction" (SAIC asking the sponsor for clarification or specific direction on an issue)
4. Was this fixed price? T&M? Did SAIC allow too many requirement changes on a FFP contract?
5. Was this inital version unexpectedly late? (were there contract modifications accepting a later delivery in exchange for additional/changed requirements?)
6. Does this initial version conform to the agreed requirement set?
I agree with most, I don't like the money being spent and then tossed away...but let's not be quick to blame the contractor. The real story (possibly) isn't out.
Slashdot Mirror
I've scanned over the replies, and haven't seen this mentioned.
Don't assume that the difficult part of the "encryption" requires the plaintext. All you really need (and this is what GSM/UMTS does) is a way to "agree" on a psuedo-random number sequence. You can pre-generate that sequence (within certain constraints) and apply it by an xor to the plaintext. The receiving end does the same.
How do you agree on a psuedo random sequence? You run AES (or any block cipher) in one of its feedback/chaining modes. All you have to agree on then is the IV. Each frame sent from your phone is numbered in some manner. That number helps for packet ordering (I am not necessarily talking about IP header numbering) and also helps the receiver determine what pre-generated sequence to apply. In UMTS/GSM, that "number" is the count parameter and is part of the IV fed into the Rijandal (I doubt that is spelled correctly, sorry).
A pure voice call over POTS requires 64kbps (8bit PCM samples at 8khz sampling rate). A cell phone call requires around 12-15kbps to achieve reasonable voice clarity. The difference is achieved by a codec that takes the analog voice and encodes it into a fixed length vocoder frame. That fixed frame length allows me to pre-generate just enough pseudo random bits to apply "encryption". Note that each frame represents 20 (or so) ms of "speech". Loss of a single frame isn't going to kill you. I do not know the VoIP codec rate. They may even send a PCM stream to/from the VoIP "server".
sd_spot
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
"Currently we are using Message Digest 5 (MD5) to calculate the hashed result, however
)
this may change in the future to SHA1 (or stronger) if MD5 is found to be too weak."
MD5 has been broken. (http://csrc.nist.gov/hash_standards_comments.pdf
Has it become "too weak"? I don't know. NIST doesn't say. I guess part of the equation involves what you are protecting. If it is armadillo porn, then no sophisticated attack is likely. If you are protecting a bank account; well maybe the effort would be woth it.
Just some thoughts. I appreciated your detailed explanation of your protection protocol (not unlike GSM, I think).
Sorry for digressing a little, but I see all sorts of comments elsewhere blaming SAIC... asserting incompetence etc. I want to know (and if the agency doing the program review is reading this - take notes).
1. metric of requirement turn
2. total number of functional requirements
3. number of outstanding "requests for clarification or direction" (SAIC asking the sponsor for clarification or specific direction on an issue)
4. Was this fixed price? T&M? Did SAIC allow too many requirement changes on a FFP contract?
5. Was this inital version unexpectedly late? (were there contract modifications accepting a later delivery in exchange for additional/changed requirements?)
6. Does this initial version conform to the agreed requirement set?
I agree with most, I don't like the money being spent and then tossed away...but let's not be quick to blame the contractor. The real story (possibly) isn't out.