Re: [liberationtech] Silent Circle Dangerous to Cryptography Software Development
If conversations are taking place over ZRTP, and, assuming that the crypto works, and that there isn't a backdoor, then the only data that silent circle should have access to is conversation metadata and data about the subscribers (IP addresses, an email address, and whatever info is required for credit card billing, such as a name/address). I run that kind of mobile voice crypto business since 2006, had worked with Phil on our Board of Advisor, but i basically have not much trust in the "SAAS" business model for that kind of stuff, given my own
On 10/12/12 1:55 AM, Christopher Soghoian wrote: personal experience. When i meet customers (mostly Enterprises and Governments, ONG get it for free), the big obstacle is not the technology but is the "trust". SilentCircle have worked a lot on the concept of "Trust" by having trustful people on-board, however i do think that who really need communication encryption support, normally doesn't have the skills to evaluate and understand how a technology or security mechanism works. As written on http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00446.html, i tried in past to run and market a service for mobile voice encryption, but there was always one question from customers: "So, all my phone calls goes trough your systems?" After that question, from a commercial point of view, for Enterprise & Government customers, represented a dead-end. So now, like CryptoPhone and other companies doing voice crypto, i had to provide that stuff only with in-house server for customers. Still i would be very happy if SilentCircle realize a marketing model where they can have customers interested to use their service! We need more innovation that field, we need opensource and free products, commercial products, software as a service products: At the end we it's just important that what you get from a community, you provide it back to the community! [...]
I'm not even sure what specific legal method would be used to compel such a backdoor in the US, since CALEA specifically addresses (and largely shields) communications service providers that provide encrypted communications but do not have access to the key. See: http://paranoia.dubfire.net/2010/09/calea-and-encryption.html
Yeah, when i spoke with Nicolas from Calyx he showed me the same US law. US Law is *extremely better* than EU Directive on the same topic, as in EU is not specifically considered and as long as you are an "Electronic communication service provider" you are obliged to provide assistance and cooperation with "Lawful interception" requirements mandated by ETSI-LI and further. If you do provide the encryption tools along with the "electronic communication service", it's your clear intention and goals to put yourself in a condition that will not let you respect the lawful interception legal requirements. So your basically violating the law. The only way is to work on the concept of what is an "electronic communication service", as we did (at privatewave). Here you can find our legal and technical analysis on how to run a voice encryption services in Italy (EU) not representing an "electronic communication service" https://docs.google.com/open?id=1vHoApU0x6PyR2_4RAL7OrEQzecQkuHoYjq1ISfaRqMW... .
However, on the compelled backdoor front, if this is a threat you are worried about, I would be equally (if not far more) worried about the government compelling Google or Apple to covertly push a malware update to your phone.
I don't think that this could practically happen, basically due to the liability and trust risks that Google or Apple would incur. Given their stock market capitalization, their CFO would never permit something like that, and for that reason i consider Apple or Google store the most secure software delivery method even, there are too many interests to get this backdoored :-) Fabio -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
participants (1)
-
Fabio Pietrosanti (naif)