Search Mailing List Archives
[liberationtech] Secure Cloud Computing: Virtualizing the FreedomBox
Caspar Bowden (lists)
lists at casparbowden.net
Thu Apr 24 11:13:18 PDT 2014
On 24/04/14 19:21, Zooko Wilcox-OHearn wrote:
> On Tue, Apr 22, 2014 at 11:47 AM, Caspar Bowden (lists)
> <lists at casparbowden.net> wrote:
>> TAHOE is also cool, but doesn't claim to provide confidentiality. A TAHOE
>> service provider would have no choice but to round-up/backdoor the necessary
>> keys under existing US (FISA/PATRIOT) or UK (RIPA Pt.3) legislation [or
>> Indian IT Acts etc. etc.]
> Oh, by the way, this part was incorrect. An example of a Tahoe-LAFS
> service provider is my company, https://LeastAuthority.com.
> LeastAuthority.com does not have any ability to acquire our
> customers's keys, nor to backdoor our customers.
This is semantics. If you provide the service to a customer, you can be
forced to backdoor <http://www.wired.com/2007/11/hushmail-to-war/>
(let's define terms "Customer", "Provider", "user", "individual data
subject" if want to continue, else will get ourselves hopelessly
confused - or if you point me at the part of the spec you think
invulnerable will show you how FISA or RIP can round-up keys)
It's in FISA 702 expressly, and as we now know, key disclosure can even
be forced under S.215. Not saying this to knock TAHOE, but often in
Cloud discussions, people are looking at a conventional threat model -
protecting against external attack and insider *un*authorized access.
But the new part of the threat model, relevant post-Snowden, is
authorized insider access lawfully required by the jurisdiction to which
that Cloud is exposed.
The UK law RIPA Pt.3 (2000) was even written with extreme (and correct)
detail to give powers to round up arbitrary number of key fragments
(whether this might be defeated by lots and lots of fragments is debatable)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the liberationtech