[liberationtech] Silent Circle Dangerous to Cryptography Software Development

Fabio Pietrosanti (naif) lists at infosecurity.ch
Fri Oct 12 00:07:50 PDT 2012


On 10/12/12 1:55 AM, Christopher Soghoian wrote:
> 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
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_4RAL7OrEQzecQkuHoYjq1ISfaRqMWNVadCCZgfdsKtngSG
.

>
> 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





More information about the cypherpunks-legacy mailing list