8 ms·

Ostel: Encrypted Phone Calls

53 points by kdavis 13y ago

mosselman 13y ago
What is the security model behind this? Which pattern is ostel using?
hellcow 13y ago
What type of encryption? What key length?
- archivator 13y ago
  One of the screenshots shows ZRTP and AES-256/DH3k
- guardianproject 13y ago
  It uses ZRTP and SRTP at least for the audio / video streaming portion of the service. The exact ciphers and strength are decided by the two clients making the call, as OStel server itself has no hand in negotiating crypto for that portion. Since we support many different client types (CSipSimple, Jitsi, Groundwire, SFLPhone, etc) this can vary greatly.
capnrefsmmat 13y ago
This is from the Guardian Project, and the source code is available here for the curious: https://github.com/guardianproject/ostel https://github.com/guardianproject/ostel I'd like to know what differentiates it from RedPhone, Silent Circle and other similar products.
- enimodas 13y ago
  silent circle is closed source and everything goes through their server. Sure they can claim not to store much logs, but when some government entity puts some secret orders on them, who knows what will happen. Remember that having the metadata, who calls who, is already a big win for surveillance entities. RedPhone is owned by twitter, same story, but the client is open source, and maybe they have plans to release the server too, but you would have to compile your clients too since apparently the servers are hardcoded into the client. Both of these are thus not federated. Ostel is open source client and server side, you can easily set up your own server, and if I understand it correctly it's also federated. Some reading: https://github.com/WhisperSystems/RedPhone/issues/63 https://github.com/WhisperSystems/RedPhone/issues/63 https://guardianproject.info/2012/07/05/a-network-analysis-of-encrypted-voice-over-ostn/ https://guardianproject.info/2012/07/05/a-network-analysis-o...
josh2600 13y ago
OK, I'm a phone geek, but I'm hoping Moxie will jump in here to set the story straight. I see ZRTP[1], but I didn't see anything on the site about signaling encryption. As you may or may not know, the content is only one component of a secure communication. There needs to be signaling encryption as well. The signaling encryption is harder than the media encryption, because the media encryption only works if the signaling encryption was successful. Signaling across a network you don't trust is really the hard part, and it's a problem for all of these apps. I don't know if Moxie implemented the certificate pinning stuff in RedPhone, but that's the sort of Crypto you need to have fool proof call security. Calls are vulnerable to MITM attacks because you have to trust the network you're riding over to some extent. Redphone has intermediating crypto for the call setup that's nifty, and I'd be cautious about using any "secure" calling system that didn't provide setup protection. Again, I'm not saying Ostel doesn't have these things, I just couldn't find them. [1]http://blog.cryptographyengineering.com/2012/11/lets-talk-about-zrtp.html http://blog.cryptographyengineering.com/2012/11/lets-talk-ab... Edit: Also wtf is FreeSWITCH doing in there??
- deleted 13y ago
  [deleted]
- moxie 13y ago
  Here is my (obviously biased) view of the landscape: 1) ostel.me :: Like many of the Guardian projects, this is an experiment in combining existing OSS libraries to create an app. In this case, CSipSimple, pjsip, and ZORG. It's basically a standard SIP/RTP VoIP client with an Android UI. That means it needs to maintain a persistent connection to a SIP server at all times, which doesn't necessarily work well with the Android process model, could drain your device's battery life, and could be flaky in scenarios where you're going in and out of coverage or switching from data to wifi. However, it is ideal for the hacker crowd that wants ultimate control, maximum configurability, and enjoys occasionally drop to the command line. You're correct that it's likely not possible to do things like certificate pinning in this context. 2) RedPhone :: While it remains to be seen whether we were correct or not, our development philosophy with RedPhone was to eschew the VoIP libraries and paradigms that were originally developed for the desktop environment in favor of OSS/Free code written from scratch for the mobile environment. Our belief is that the different network and platform characteristics of mobile devices require a mobile-oriented solution. This means that we use a lightweight mobile-oriented signaling protocol instead of SIP, push notifications instead of maintaining a persistent connection at all times, techniques for establishing low-latency routing for global calling (https://whispersystems.org/blog/low-latency-switching https://whispersystems.org/blog/low-latency-switching), a jitter buffer optimized for mobile data networks (https://whispersystems.org/blog/client-side-audio-quality https://whispersystems.org/blog/client-side-audio-quality), and your normal phone number for addressing rather than a new identifier. It also means that, yes, we can do things like certificate pinning for the signaling channel. This is all obviously oriented towards the average smartphone user, though, so it's sometimes less appealing to the hacker crowd who want to use a SIP identifier or connect through their own SIP server. 2) Silent Circle :: My sense is that Silent Circle is trying to do both. Their stack seems to be based on traditional VoIP protocols (SIP/RTP), and their server-side infrastructure appears to be a FreeSWITCH box in a single Canada datacenter (maybe with a single-DC European presence now or coming soon as well?). However, they are using those desktop protocols to try to create a packaged non-hacker-oriented experience. I'm not sure if that's possible or not, but I'm obviously biased. It does cost a non-trivial amount of money, though, and their client source isn't Free.
rarrrrrr 13y ago
FWIW, I prefer Silent Circle, created by the same team behind PGP. Glad to see more choices in the market though. :) https://silentcircle.com/ https://silentcircle.com/
chrisballinger 13y ago
> Ostel works great on the Groundwire app. It's a paid app and for $10 you'll be able to receive encrypted calls. There's an additional $25 in-app purchase for the ZRTP extension to also place a secure call. $35 for secure calls on iOS? We can do better than that.
- kdavis 13y ago
  Is there a cheap, reliable open-source alternative? I'm sure that, in light of current events, many people would be interested.
  - guardianproject 13y ago
    Not for iPhone unfortunately. You can see our early work analyzing client software options from last year: https://guardianproject.info/wiki/OSTN#Client_Software https://guardianproject.info/wiki/OSTN#Client_Software
alephnil 13y ago
Some of the most important information for intelligence agencies is the metadata, i.e. who is calling who. That is often considered more important than the content. As far as I can see this does not address that.
daenney 13y ago
I'm going to be a jerk here but I'm having difficulties taking a product seriously with badly photoshopped interfaces into devices that don't even respect basic laws of perspective. The problem I don't see this solving is the fact that I still need to trust a third party that routes my call not to store and hand over any data on those calls.
- guardianproject 13y ago
  OStel.co does address this - we are specifically trying to lay out how a privacy-first, security by design VOIP service should be run. We are taking stock, off-the-shelf open-source software, and figuring out the best configuration for it to be run in order to store as little data as possible. We are also thinking about how we can defend against tracking of signaling information - by perhaps running the SIP/TLS portion over Tor. You can read about this and more on some of our posts on the Guardian Project blog: http://guardianproject.info/2013/06/12/carrier-grade-verizon-and-the-nsa/ http://guardianproject.info/2013/06/12/carrier-grade-verizon... http://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ http://guardianproject.info/2013/01/31/anonymous-cb-radio-wi... http://guardianproject.info/2012/12/10/voice-over-tor/ http://guardianproject.info/2012/12/10/voice-over-tor/ https://guardianproject.info/2013/02/22/lower-bounds-of-the-narrow-bands/ https://guardianproject.info/2013/02/22/lower-bounds-of-the-...

53 points by kdavis 13y ago

mosselman 13y ago

What is the security model behind this? Which pattern is ostel using?

hellcow 13y ago

What type of encryption? What key length?

archivator 13y ago
One of the screenshots shows ZRTP and AES-256/DH3k
guardianproject 13y ago
It uses ZRTP and SRTP at least for the audio / video streaming portion of the service. The exact ciphers and strength are decided by the two clients making the call, as OStel server itself has no hand in negotiating crypto for that portion. Since we support many different client types (CSipSimple, Jitsi, Groundwire, SFLPhone, etc) this can vary greatly.

capnrefsmmat 13y ago

This is from the Guardian Project, and the source code is available here for the curious: https://github.com/guardianproject/ostel https://github.com/guardianproject/ostel I'd like to know what differentiates it from RedPhone, Silent Circle and other similar products.

enimodas 13y ago
silent circle is closed source and everything goes through their server. Sure they can claim not to store much logs, but when some government entity puts some secret orders on them, who knows what will happen. Remember that having the metadata, who calls who, is already a big win for surveillance entities. RedPhone is owned by twitter, same story, but the client is open source, and maybe they have plans to release the server too, but you would have to compile your clients too since apparently the servers are hardcoded into the client. Both of these are thus not federated. Ostel is open source client and server side, you can easily set up your own server, and if I understand it correctly it's also federated. Some reading: https://github.com/WhisperSystems/RedPhone/issues/63 https://github.com/WhisperSystems/RedPhone/issues/63 https://guardianproject.info/2012/07/05/a-network-analysis-of-encrypted-voice-over-ostn/ https://guardianproject.info/2012/07/05/a-network-analysis-o...

josh2600 13y ago

OK, I'm a phone geek, but I'm hoping Moxie will jump in here to set the story straight. I see ZRTP[1], but I didn't see anything on the site about signaling encryption. As you may or may not know, the content is only one component of a secure communication. There needs to be signaling encryption as well. The signaling encryption is harder than the media encryption, because the media encryption only works if the signaling encryption was successful. Signaling across a network you don't trust is really the hard part, and it's a problem for all of these apps. I don't know if Moxie implemented the certificate pinning stuff in RedPhone, but that's the sort of Crypto you need to have fool proof call security. Calls are vulnerable to MITM attacks because you have to trust the network you're riding over to some extent. Redphone has intermediating crypto for the call setup that's nifty, and I'd be cautious about using any "secure" calling system that didn't provide setup protection. Again, I'm not saying Ostel doesn't have these things, I just couldn't find them. [1]http://blog.cryptographyengineering.com/2012/11/lets-talk-about-zrtp.html http://blog.cryptographyengineering.com/2012/11/lets-talk-ab... Edit: Also wtf is FreeSWITCH doing in there??

deleted 13y ago
[deleted]
moxie 13y ago
Here is my (obviously biased) view of the landscape: 1) ostel.me :: Like many of the Guardian projects, this is an experiment in combining existing OSS libraries to create an app. In this case, CSipSimple, pjsip, and ZORG. It's basically a standard SIP/RTP VoIP client with an Android UI. That means it needs to maintain a persistent connection to a SIP server at all times, which doesn't necessarily work well with the Android process model, could drain your device's battery life, and could be flaky in scenarios where you're going in and out of coverage or switching from data to wifi. However, it is ideal for the hacker crowd that wants ultimate control, maximum configurability, and enjoys occasionally drop to the command line. You're correct that it's likely not possible to do things like certificate pinning in this context. 2) RedPhone :: While it remains to be seen whether we were correct or not, our development philosophy with RedPhone was to eschew the VoIP libraries and paradigms that were originally developed for the desktop environment in favor of OSS/Free code written from scratch for the mobile environment. Our belief is that the different network and platform characteristics of mobile devices require a mobile-oriented solution. This means that we use a lightweight mobile-oriented signaling protocol instead of SIP, push notifications instead of maintaining a persistent connection at all times, techniques for establishing low-latency routing for global calling (https://whispersystems.org/blog/low-latency-switching https://whispersystems.org/blog/low-latency-switching), a jitter buffer optimized for mobile data networks (https://whispersystems.org/blog/client-side-audio-quality https://whispersystems.org/blog/client-side-audio-quality), and your normal phone number for addressing rather than a new identifier. It also means that, yes, we can do things like certificate pinning for the signaling channel. This is all obviously oriented towards the average smartphone user, though, so it's sometimes less appealing to the hacker crowd who want to use a SIP identifier or connect through their own SIP server. 2) Silent Circle :: My sense is that Silent Circle is trying to do both. Their stack seems to be based on traditional VoIP protocols (SIP/RTP), and their server-side infrastructure appears to be a FreeSWITCH box in a single Canada datacenter (maybe with a single-DC European presence now or coming soon as well?). However, they are using those desktop protocols to try to create a packaged non-hacker-oriented experience. I'm not sure if that's possible or not, but I'm obviously biased. It does cost a non-trivial amount of money, though, and their client source isn't Free.

rarrrrrr 13y ago

FWIW, I prefer Silent Circle, created by the same team behind PGP. Glad to see more choices in the market though. :) https://silentcircle.com/ https://silentcircle.com/

chrisballinger 13y ago

> Ostel works great on the Groundwire app. It's a paid app and for $10 you'll be able to receive encrypted calls. There's an additional $25 in-app purchase for the ZRTP extension to also place a secure call. $35 for secure calls on iOS? We can do better than that.

kdavis 13y ago
Is there a cheap, reliable open-source alternative? I'm sure that, in light of current events, many people would be interested.
- guardianproject 13y ago
  Not for iPhone unfortunately. You can see our early work analyzing client software options from last year: https://guardianproject.info/wiki/OSTN#Client_Software https://guardianproject.info/wiki/OSTN#Client_Software

alephnil 13y ago

Some of the most important information for intelligence agencies is the metadata, i.e. who is calling who. That is often considered more important than the content. As far as I can see this does not address that.

daenney 13y ago

I'm going to be a jerk here but I'm having difficulties taking a product seriously with badly photoshopped interfaces into devices that don't even respect basic laws of perspective. The problem I don't see this solving is the fact that I still need to trust a third party that routes my call not to store and hand over any data on those calls.

guardianproject 13y ago
OStel.co does address this - we are specifically trying to lay out how a privacy-first, security by design VOIP service should be run. We are taking stock, off-the-shelf open-source software, and figuring out the best configuration for it to be run in order to store as little data as possible. We are also thinking about how we can defend against tracking of signaling information - by perhaps running the SIP/TLS portion over Tor. You can read about this and more on some of our posts on the Guardian Project blog: http://guardianproject.info/2013/06/12/carrier-grade-verizon-and-the-nsa/ http://guardianproject.info/2013/06/12/carrier-grade-verizon... http://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ http://guardianproject.info/2013/01/31/anonymous-cb-radio-wi... http://guardianproject.info/2012/12/10/voice-over-tor/ http://guardianproject.info/2012/12/10/voice-over-tor/ https://guardianproject.info/2013/02/22/lower-bounds-of-the-narrow-bands/ https://guardianproject.info/2013/02/22/lower-bounds-of-the-...