silentcircle

This document is because someone is vandalizing deleting our pad at https://pad.riseup.net/p/silentcircle .

This document is the output of a quick analysis done on SilentCircle source code published on https://github.com/SilentCircle/silent-phone-base .

Some interesting finding below

* A Latvian company wrote most of the software, not SilentCircle
The application of SilentCircle seems to be a rebranded and customized edition of TiviPhone, available from www.tivi.com made in Latvia.
silent-phone-base$ grep -ir tiviphone.com . | wc -l
     180

     From TiVi's page: http://www.tivi.com/en/company/news.php
     "Until September 30, 2010, buy TiviPhone with ZRTP voice and video encryption. The difference? You enter theprice; we approve it. Pay by PayPal, get the license key, run it and tell your friends how much more competitive TiviPhone is! If you resell (or rebrand) TiviPhone, even better: bid for bigger batches of licenses in one go!" but I can't find anything about licensing as FOSS. And it also looks to have a prior relationship with Zfone per http://www.tivi.com/en/company/news.php?Secured-mobile-VoIP-calls.


Copyright tells the story.
Copyright © 2004-2012 Tivi LTD,www.tiviphone.com. All rights reserved.
Copyright © 2012-2013, Silent Circle, LLC.  All rights reserved. So the rebranding needed to be more complete - and the prior TiVi partnership with Zfone and Zimmermann resulted in this emergence. Much ado about nothing.

Indeed it appears the TiViPhone people work ~for~ Silent Circle. Just like the bit about ZRTPCPP and Wener Dittmann below. Wait — so Silent Circle has been developing TiviPhone since 2010 through those people? With the intention of releasing it as Silent Phone years later? I can't be that specific but look at https://silentcircle.com/web/founders-leadership/ and the various names associated with these libraries and projects appear all through that list. Except PolarSSL.
I don't know, but Occam's Razor would probably say that they just made a deal with this company and either bought them or partnered with them. That's pretty common for startups. I noticed they have a "rebranding" pitch on their website, maybe SC just took that a step further. Definitely seems like it was around long before SC was formed though. Sounds more likely.
Werner dittman, looking from a Linkedin profile works for Nokia Siemens Networks . Werner Dittman and Janis are both listed on the SC page founders listed above. I think a number of them have "day jobs" in the early phases of this startup.

"Silent Circle’s team:  a unique and eclectic mix of world-renowned  cryptographers, Silicon Valley software engineers, German VoIP  engineers, Latvian system analysts and former US Navy SEALs &  British Special Air Service (SAS) security experts." https://silentcircle.com/web/unique-story/

* Application is designed for VoIP, not specifically for Security
The software TiviPhone appear to be designed for general mobile voip use and not specifically designed for security.
It does include a custom written SIP parser rather than reusing existing code from other projects:

    sipparser/client/CSipParse.cpp
    sdp/parseSDP.cpp


* It does use an outdated SSL library (PolarSSL 1.1.1) with some known security vulnerabilities ?

    Latest version is 1.2.5 (2013-02-02), the project seems very active as 1.1.1 has been released 2012-01-23
    PolarSSL Security Advisory: https://polarssl.org/tech-updates/security-advisories (most recent advisory Feb 2nd) .
    PolarSSL Changelog https://github.com/polarssl/polarssl/blob/master/ChangeLog
    they embed 1.1.1 and 1.1.4 in libs, but I only find 1.1.1 usage in the code
    TODO: It should be checked in details if that 1.1.1 is vuln and/or patched to some of the advisory.
    ^--- PolarSSL 1.1.1 suffers from "Weak Diffie-Hellman and RSA key generation": https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2012-01
    Easily a non-issue as w/ many other projects. Verifying against binaries is tougher.


* It does not use LibZRTP by Philip Zimmermann used in Zfone but ZRTPCPP
  The application does use the ZRTPCPP available on https://github.com/wernerd/ZRTPCPP but it does not use the LibZRTP
  made by Philip Zimmermann that SilentCircle itself license (LibZRTP SDK) https://silentcircle.com/web/zrtp-sdk/
  Werner Dittmann works for Silent Circle.

* It does use an outdated version of ZRTPCPP library?
  Looking at libs/zrtp/Changelog it does use ZRTPCPP 1.5.2 version (released on 05-Dec-2010).
  Latests version is libzrtpcpp 2.3.2 (released on 20-Nov-2012)
  ZRTPCPP 1.5/1.6/2.3 download: http://ftp.gnu.org/gnu/ccrtp/ .


* It does reveal their test/development server?
  In the file ./apple/ios/VoipPhone/settings.txt there is the hostname fs-devel.silentcircle.org with ip 50.116.49.43
  Do we have that code too? It would be nice to have a full development enviornment to play with / even a fake one would have its uses.
  That's a nice inquiry. It would be also very interesting, while i think it's not doable technically for smartphone platforms's constraints, to have "Deterministic Building" to always have the exact checksum of files given the same build process repeated in the same environment (Unfortunately that's an hard topic, due to various timestamps and stuff that linked put into the executable files).//AppStore binaries are encrypted/heavily obfusticated... right, proving the released binary match the released source code is hard.
Unless the build is reproducible and verifiable, releasing the source is pretty meaningless.  <-- THIS <--- Seconded, totally agree The best thing I can think of is to decrypt the app store binary and compare it using bindiff, but that is probably more work than anyone capable of doing this is willing to bother with. //perhaps gdb memory dump on a jail break iphone could get you something //given today's compiler sophistication, I guess comparing a compiled binary could hardly proving anything.
<--- Those aren't real solutions. It should be put forward that releasing source code also means making sure it builds, binaries can be run and verified. Otherwise, the source code release is botched and immature.
My take on them releasing this is that it provides them with marketing fodder, will net them a few free bug reports, and does nothing to prove that there isn't backdoors. I mean, there probably are not backdoors, but with crypto we don't tolerate "probably". So this is really a non-release and more of a stunt. I wonder if they are hiring new iOS devs now?
A release of source against each App Store or Google Play edition seems to be in order - that isn't unlike other projects spreading legs on both sides of the App Store and FOSS fence.
So are you suggesting that I submit a binary of this to the App Store tonight? as it is?  That's simultaneously hilarious and a good bloody idea if they'd ever approve it - licensing. Trying to get it to build now...
Judging from the state of this project, it's not set up in a workspace, the build settings are a mess. Whoever was doing this development is not someone who really knows how to use Xcode. God damnit I feel like I'm at work. I am not fixing this piece of shit…
is this going anywhere useful?I'd say anything that gets Silent Circle to actually answer questions proper is useful, if that is the result. Otherwise it's just self-congratulator trolling jerk circles.
No, the app is free - provisioning is the cost. Does that mean they are unlikely to release server code? If they do they're just begging for someone taking the whole thing and running it for free/cheaper...
Hey, could you report some testing at analyzing the executable, how much obfuscated/size, which files does it spread around (for example, after being provisioned, if it save some pre-populated .xml files).
TODO: It would be nice if someone could share an url with a backup of an "Installed and configured SilentCircle" to look at!.
I am trying to read some code. They are just a peice of mess. Like this: smartphone/codecs/vTiVi/ep.cpp. It is like something from a decompiler (even the indentation didn't conform)+1 definitely not iOS devs

Like this: (this is a library search path for one of the libs) "$(SRCROOT)/../../../../../Library/Developer/Xcode/DerivedData/werner_zrtp-gibkbzjaoguukggnpjvrvnwattfm/Build/Products/Debug-iphoneos" <that's very bad and stupid, if they just brought the zrtp project into the same workspace xcode would handle all of this automagically for them
// I am wondering how did they get this mess run on a phone. It's very fraigle, likely this environement works on the developer's machine (lol) and was good enough to generate a binary for app store submission

The codebase just went offline!
https://github.com/SilentCircle/silent-phone-base

* In ./silentphone/tiviengine/prov.cpp there is some kind of provisioning protocols, used probably to auto-configure the voip clients.
Interesting the following strings:
    http://sccps.silentcircle.com/provisioning/silent_phone/tivi_cfg.xml?api_key=12345^M
    http://sccps.silentcircle.com/provisioning/silent_phone/settings.txt?api_key=12345^M
    http://sccps.silentcircle.com/provisioning/silent_phone/tivi_cfg_glob.txt?api_key=12345^M
   const char *pLink="https://accounts.silentcircle.com";^M

   It should be evaluated the capability for a government censoring/filtering host to block the user out by blocking accounts.silentcircle.com or sccps.silentcircle.com. Maybe some dynamic methods is in place?

   const char *dev_id=t_getDevID_md5();^M <--- What's up with these functions? Maybe the IMEI/UDID of the Phone hashed with md5?
   TODO: Someone should check it!
   const char *dev_name=t_getDev_name();^M Only works on IOS, returns UTF8String of NSString *n = [[UIDevice currentDevice]model]; That's something like "iPhone5" or "iPhone4s"? If so, it's less privacy invasive.

   It should be evaluated the privacy impact of retrieving the "name" of the device (Is that the name of the phone?) that could be stored somewhere (how?).
   Additionally it should be considered that if the "Device ID" is an IMEI, even hashing it with MD5, could make it easily reversable by Silentcircle to retrieve it. TODO: Checkit
   NSString *n = [[UIDevice currentDevice]uniqueIdentifier];
   These UDID's were rendered useless a while ago weren't they? There is an advertising udid framework but you can request a fresh ID whenever you want.
It's IOS's ^^^ yeah.
It is deprcated since iOS5: https://developer.apple.com/library/prerelease/ios/#documentation/UIKit/Reference/UIDevice_Class/DeprecationAppendix/AppendixADeprecatedAPI.html
   It should be asked what are the privacy handling for those data and if those can be additionally "privacy enforced" .

   int l=snprintf(bufReq,sizeof(bufReq)-10,"%s/provisioning/use_code/?provisioning_code=",pLink);^M
   l+=snprintf(&bufReq[l],sizeof(bufReq)-10-l,"&device_id=%s&device_name=",dev_id);^M
   const char *pFN_to_download[]   ={"settings.txt","tivi_cfg_glob.txt","tivi_cfg.xml","tivi_cfg1.xml",NULL};^M
   snprintf(bufReq,sizeof(bufReq)-1,"%s/provisioning/silent_phone/%s?api_key=%s",pLink,pFN_to_download[i],bufToken);^M

Are UI Bugs worth finding? Sometimes they can actually lead to code execution. For example, setting your nickname to be something that can exploit the UI for nickname display and execute code... or just mislead the user? Part of the UI includes presenting security phrases for validation, it's worth scrutinizing. From an OPSEC perspective it might lead to leeks as well.

The backend code wasn't released, unfortunately

Random iOS tidbit of information: if you go into settings.app and change any permissions for address book/photos/etc… any applications running that require those permissions will automatically forcequit.


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.
const char *pEntrustCert=^M
"-----BEGIN CERTIFICATE-----\r\n"^M
"MIIE2DCCBEGgAwIBAgIEN0rSQzANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC\r\n"^M
"VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u\r\n"^M
"ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc\r\n"^M
"KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u\r\n"^M
"ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTA1\r\n"^M
"MjUxNjA5NDBaFw0xOTA1MjUxNjM5NDBaMIHDMQswCQYDVQQGEwJVUzEUMBIGA1UE\r\n"^M
"ChMLRW50cnVzdC5uZXQxOzA5BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5j\r\n"^M
"b3JwLiBieSByZWYuIChsaW1pdHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBF\r\n"^M
"bnRydXN0Lm5ldCBMaW1pdGVkMTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUg\r\n"^M
"U2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGdMA0GCSqGSIb3DQEBAQUA\r\n"^M
"A4GLADCBhwKBgQDNKIM0VBuJ8w+vN5Ex/68xYMmo6LIQaO2f55M28Qpku0f1BBc/\r\n"^M
"I0dNxScZgSYMVHINiC3ZH5oSn7yzcdOAGT9HZnuMNSjSuQrfJNqc1lB5gXpa0zf3\r\n"^M
"wkrYKZImZNHkmGw6AIr1NJtl+O3jEP/9uElY3KDegjlrgbEWGWG5VLbmQwIBA6OC\r\n"^M
"AdcwggHTMBEGCWCGSAGG+EIBAQQEAwIABzCCARkGA1UdHwSCARAwggEMMIHeoIHb\r\n"^M
"oIHYpIHVMIHSMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRW50cnVzdC5uZXQxOzA5\r\n"^M
"BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5jb3JwLiBieSByZWYuIChsaW1p\r\n"^M
"dHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBFbnRydXN0Lm5ldCBMaW1pdGVk\r\n"^M
"MTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUgU2VydmVyIENlcnRpZmljYXRp\r\n"^M
"b24gQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMCmgJ6AlhiNodHRwOi8vd3d3LmVu\r\n"^M
"dHJ1c3QubmV0L0NSTC9uZXQxLmNybDArBgNVHRAEJDAigA8xOTk5MDUyNTE2MDk0\r\n"^M
"MFqBDzIwMTkwNTI1MTYwOTQwWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU8Bdi\r\n"^M
"E1U9s/8KAGv7UISX8+1i0BowHQYDVR0OBBYEFPAXYhNVPbP/CgBr+1CEl/PtYtAa\r\n"^M
"MAwGA1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjQuMAMCBJAwDQYJKoZI\r\n"^M
"hvcNAQEFBQADgYEAkNwwAvpkdMKnCqV8IY00F6j7Rw7/JXyNEwr75Ji174z4xRAN\r\n"^M
"95K+8cPV1ZVqBLssziY2ZcgxxufuP+NXdYR6Ee9GTxj005i7qIcyunL2POI9n9cd\r\n"^M
"2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G+bI=\r\n"^M
"-----END CERTIFICATE-----\r\n"^M

It would be possible to make some consideration from a technical, security and transparency perspective.