18 ms·

Secure key exchange for peer-to-peer communication and VoIP

11 points by Mithrandir 16y ago

mike-cardwell 16y ago
I find the whole idea about calculating a hash from the shared key and then speaking it over the phone to verify that there isn't a MITM taking place very interesting. Redphone for Android does this as well apparently but I've not tested it yet because it's US only - http://www.whispersys.com/ http://www.whispersys.com/
- tptacek 16y ago
  This is how every web-of-trust and key-continuity scheme works; it's why you get a fingerprint the first time you connect to an SSH server, and why people publish their PGP fingerprints on their business cards.
  - mike-cardwell 16y ago
    Yeah, I understand why they've done it this way. I just thought it was a really clever idea to use the users actual voices and conversation to do the verification. It's interesting because you use the system its self to verify that the system is secure. Normally you have to use an alternative (already trusted) system to verify the fingerprint.
    - caf 16y ago
      The alternative in this case is hidden, but it's still there - you have to recognise the voice of the person you're talking to.
      - mike-cardwell 16y ago
        Yeah, I recognise this.
viraptor 16y ago
I'm confused by this article for a couple of reasons: - There is ZRTP, SRTP, SIP over TLS and many proprietary systems. Why add yet another one? - Right now, adding a new extensions to what providers offer is extremely tricky - unless you have a massive number of customers who support / want it. Basically it's easier to add a new VPN connection on top of all the traffic to some site, rather than adding support for feature X (especially if your infrastructure is a mix&match of many solutions) - I don't know the amount of standard trapezoid-type SIP connections on the internet these days - but I assume it's very low. If you have a local server with some serious usage, it will be a PBX and not a proxy. If it's a VPBX provider on the internet, it's most probably a PBX not a proxy. This (for many reasons) means that any encoding you can get is only between you and the provider. There, you lose the control over what's happening. - "Identity" in SIP networks is a completely different concept than email "identity". Calling a sip uri, you might end up on a sip client, pstn phone, voicemail, redirection to someone else, or any crazy automated service you can imagine. I don't see this being addressed in the article. With user-controlled e.164 directory you may end up on someone's door intercom for all you know. In reality my recommendation is - You want your call secure? Use your own network only. - You want your PSTN call secure? Forget about it - any serious provider is expected by local laws to provide means for wiretapping, so your call will have to be decoded. The best thing you can do is vpn/tls to your provider. Basically I disagree that the phone call security is something that can be solved by adding features to sip, rtp or other protocols...
caf 16y ago
The article doesn't appear to mention what defence it has against a downgrade attack.

11 points by Mithrandir 16y ago

I find the whole idea about calculating a hash from the shared key and then speaking it over the phone to verify that there isn't a MITM taking place very interesting. Redphone for Android does this as well apparently but I've not tested it yet because it's US only - http://www.whispersys.com/ http://www.whispersys.com/

tptacek 16y ago
This is how every web-of-trust and key-continuity scheme works; it's why you get a fingerprint the first time you connect to an SSH server, and why people publish their PGP fingerprints on their business cards.
- mike-cardwell 16y ago
  Yeah, I understand why they've done it this way. I just thought it was a really clever idea to use the users actual voices and conversation to do the verification. It's interesting because you use the system its self to verify that the system is secure. Normally you have to use an alternative (already trusted) system to verify the fingerprint.
  - caf 16y ago
    The alternative in this case is hidden, but it's still there - you have to recognise the voice of the person you're talking to.
    - mike-cardwell 16y ago
      Yeah, I recognise this.

viraptor 16y ago

I'm confused by this article for a couple of reasons: - There is ZRTP, SRTP, SIP over TLS and many proprietary systems. Why add yet another one? - Right now, adding a new extensions to what providers offer is extremely tricky - unless you have a massive number of customers who support / want it. Basically it's easier to add a new VPN connection on top of all the traffic to some site, rather than adding support for feature X (especially if your infrastructure is a mix&match of many solutions) - I don't know the amount of standard trapezoid-type SIP connections on the internet these days - but I assume it's very low. If you have a local server with some serious usage, it will be a PBX and not a proxy. If it's a VPBX provider on the internet, it's most probably a PBX not a proxy. This (for many reasons) means that any encoding you can get is only between you and the provider. There, you lose the control over what's happening. - "Identity" in SIP networks is a completely different concept than email "identity". Calling a sip uri, you might end up on a sip client, pstn phone, voicemail, redirection to someone else, or any crazy automated service you can imagine. I don't see this being addressed in the article. With user-controlled e.164 directory you may end up on someone's door intercom for all you know. In reality my recommendation is - You want your call secure? Use your own network only. - You want your PSTN call secure? Forget about it - any serious provider is expected by local laws to provide means for wiretapping, so your call will have to be decoded. The best thing you can do is vpn/tls to your provider. Basically I disagree that the phone call security is something that can be solved by adding features to sip, rtp or other protocols...

caf 16y ago

The article doesn't appear to mention what defence it has against a downgrade attack.