[liberationtech] Fwd: Answers to some of your questions (Silent Circle responds..) - Can encryption be disabled?

Thu Feb 14 11:30:33 PST 2013

It seems to that SilentCircle "could" selectively disable ZRTP and force
the client to goes with SDES (like with SSL) or even in clear.

>From my basic understanding (but i maybe wrong, as i'm not that c++
expert) , SC can remotely provision the configuration files changing the
way the end-user does encryption.

Look below:
# The client does retrieve the configuration from the server
curl -v
https://sccps.silentcircle.com/provisioning/silent_phone/settings.txt?api_key=12345

>From the various config fields we can see:
iZRTP_On: 1

>From the code at silentphone/tiviengine/media.cpp we can see that ZRTP
and SDES can be selectively enabled/disabled:
   if(cbEng.p_cfg.iZRTP_On){
      char tmp[128];
      int l=pzrtp->getSignalingHelloHash(tmp,0);
      if(l>0)iLen+=sprintf(p+iLen,"a=zrtp-hash:1.10 %.*s\r\n",l,&tmp[0]);
   }

  if(cbEng.p_cfg.iSDES_On){

   if(pzrtp)pzrtp->setSdesEnabled(!!(cbEng.p_cfg.iSDES_On));

If that's true, it means that SC can disable the encryption and switch
the encryption level from end-to-end (ZRTP) to end-to-site (SDES,
SSL-like), de-facto being able to intercept the users (if forced with a
gun pointed at the head or with a NSL?) ?

Additionally, i see the provisioning url configured in the client is
HTTP in clear-text (not HTTPS):

http://sccps.silentcircle.com/provisioning/silent_phone/tivi_cfg.xml?api_key=12345

http://sccps.silentcircle.com/provisioning/silent_phone/settings.txt?api_key=12345

http://sccps.silentcircle.com/provisioning/silent_phone/tivi_cfg_glob.txt?api_key=12345

The server then does an HTTP-302 redirecting the client to to HTTPS.

That means that, maybe (i didn't tested), a third party doing actively
MITM could just answer a settings.txt file with "iZRTP_On: 0" ,
disabling end-to-end encryption.

I don't know what happen in that case, if communication go-clear or if
it goes SDES (so encrypted till to SC, but not end-to-end).

Still, maybe i'm wrong, so some more experienced c++ coder should look
at the code.

-naif

On 2/14/13 5:51 PM, Ali-Reza Anghaie wrote:
> Mr. Jon Callas of Silent Circle was kind enough to field questions on
> another list and also pay attention to the Pastebit of the pad
> everyone was commenting on before things went awry.
>
> See the below - complete with an invitation for cool ideas w/ resumes.
>
> Thank you VERY much to Mr. Callas for entering the fray and helping
> tune the accuracy of the overall discussion. Cheers, -Ali
>
>
> ---------- Forwarded message ----------
> From: *Jon Callas* <jon at silentcircle.com <mailto:jon at silentcircle.com>>
> Date: Thu, Feb 14, 2013 at 11:28 AM
> Subject: Answers to some of your questions
> To: Ali-Reza Anghaie <ali at packetknife.com <mailto:ali at packetknife.com>>
> Cc: Jon Callas <jon at silentcircle.com <mailto:jon at silentcircle.com>>
>
>
> Hi, Ali-Reza.
>
> I saw your pastebit with some questions, and let me answer. You may
> repost this mail to liberation tech or anywhere else.
>
> * A Latvian company wrote most of the software, not SilentCircle
>
> When we formed Silent Circle, we looked around for people to partner
> with. We selected Tivi because they're really cool people -- I used
> their ZRTP-enabled VOIP client back in the days when I had a Nokia
> N95. We picked them in part because they were willing to release
> source code. (Other potential partners were not willing.)
>
> Our partnership with them includes that code base, and that they work
> for us full-time now. They're some of our main developers now.
>
> I have a bit of a raised eyebrow at this comment. (Yes, I know it's
> not your words, you're also explaining.) It sounds to me like whoever
> is making that comment is implying that there's something wrong with
> Latvia. Riga was for many, many years a center of European high-tech
> until the dark days of WWII and Soviet occupation. It's a lovely place
> filled with incredibly smart, friendly people. It is a part of the EU,
> and also a NATO nation. Our team in Riga. We picked them because they
> rock.
>
> Perhaps the comment comes from the fact that they were in business
> before our partnership. It's relatively common in high-tech that
> companies enter into partnerships with others. Google, Microsoft,
> Apple, Facebook, and others often use some sort of relationship like
> this to get software or technologies that they didn't have, so that it
> speeds up development. We are hardly unique in this.
>
> Perhaps I don't understand. If someone could explain the objection to
> me, I'm happy to address it further.
>
> * Application is designed for VoIP, not specifically for Security
>
> It's a secure VOIP client. Because of its history, there's a lot of
> latent capability in it that is VOIP related. Is there an actual
> question or objection?
>
> * It does use an outdated SSL library (PolarSSL 1.1.1) with some known
> security vulnerabilities ?
>
> No, we're using PolarSSL 1.1.4. We did not include the PolarSSL code
> in the drop because we didn't want to figure out the licensing details.
>
> * It does not use LibZRTP by Philip Zimmermann used in Zfone but ZRTPCPP
>
> That is correct. We're using Werner Dittmann's library. We like it. We
> like it so much that Werner is working for us. Werner rocks.
>
> * It does use an outdated version of ZRTPCPP library?
>
> I don't believe so. If anything, we're using a version of it that is
> newer than anyone else's; Werner works for us, now.
>
> Should we need release a new version, we will.
>
> * It does reveal their test/development server?
>
> - "I wonder if they are hiring new iOS devs now?"
>
> Yes, we are. We also need Android devs, and need them more than iOS
> devs. Feel free to send résumés to <jobs at silentcircle.com
> <mailto:jobs at silentcircle.com>>. Note that we are a highly-distributed
> company with developers and staff stretched from Latvia to Greece, to
> the Pacific West. Location almost does not matter. 31337 skillz do.
>
> I will also note that the code of the VOIP system is the same across
> all our apps. It gets compiled for iOS and Android, as well as Windows
> (Silent Eyes). Each OS has its own UX skin on top of the code VOIP system.
>
> - "I'd say anything that gets Silent Circle to actually answer
> questions proper is useful, if that is the result."
>
> Feel free to send questions to me, or to "security at silentcircle.com
> <mailto:security at silentcircle.com>"
>
> * In ./silentphone/tiviengine/prov.cpp there is some kind of
> provisioning protocols, used probably to auto-configure the voip clients.
>
> Good catch! Yes, indeed, we provision the clients ourselves. Silent
> Circle is a *SERVICE* not an app.
>
> * It should be evaluated the capability for a government
> censoring/filtering host to block the user out by blocking
> accounts.silentcircle.com <http://accounts.silentcircle.com> or
> sccps.silentcircle.com <http://sccps.silentcircle.com>. Maybe some
> dynamic methods is in place?
>
> We'd love to hear suggestions. If someone's suggestion is particularly
> clever, feel free to attach a résumé.
>
> * It should be asked what are the privacy handling for those data and
> if those can be additionally "privacy enforced" .
>
> Feel free to ask. I don't understand the question, myself.
>
> * QUESTION: What this certificate is used for ?
> TODO: We should check to see if this certificate is used for TLS
> Validation? If so that's cool, that it does not rely on third party CA.
>
> Got it in one! Thank you for thinking it's cool.
>
> Again, feel free to forward this mail to anyone, and I'm happy to
> entertain questions from anyone.
>
>         Jon
>
> -----
> Jon Callas
> Chief Technical Officer
> Silent Circle, LLC
> email: jon at silentcircle.com <mailto:jon at silentcircle.com> Silent
> Phone: jon
>
>
>
>
>
>
>
> --
> Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130214/c6db5532/attachment.html>