[Ndn-interest] repo-ng and least-authority storage

[cds at corbinsimpson.com]

Okay, I'm sorry, let me rewind and explain a bit more. I forget that
NDN and object-capability research don't overlap as much as I feel
that they should.

So, what I'm asking for, precisely, is the ability to convert
bytestrings (files) into *capability URIs*, which are URIs that are
both sufficient and necessary for retrieving the file. This is tied to
the notion of *capability* in OS and language design, where a
capability, or "cap", is a communicable unforgeable token designating
authority. In the case of NDN, the authority is to retrieve a file.

In Tahoe-LAFS, this is what a cap looks like:
URI:CHK:h2bfkbufdlnuxxtf2b4qyyqt6y:jdrjht3qifq7hjv7l42woqtkxznapxn6xgtxd2v6xynslbsj3q4q:3:10:3221

If I pop that cap into a Tahoe-LAFS client connected to Matador
Cloud's public Tahoe-LAFS grid, I get some SVG data back. What's in
the URI, exactly? There's a flag that the content is immutable, a
"storage index", which is an opaque name for the actual storage
location in the cloud; a secret key which symmetrically encrypted the
file, and three interesting numbers at the end: erasure coding
parameters, as k-of-n, and the file size.

So, what's needed to make this work on NDN? Well, first, erasure
coding is only interesting when you don't trust the network to be
sufficiently durable to be able to keep your file alive. I feel that
NDN solves this elegantly, and that as long as a file's live in
somebody's Repo somewhere, there's not much risk of a file vanishing.
So maybe we can leave that out. We can also leave out file size, and
the storage index can be randomly-generated. NDN handles all of that
just fine.

As for encryption, all that's really required is that the key and
nonce are never reused and aren't deterministically generated by the
file. (If they were deterministic, then an attacker could check to see
if a certain encrypted data blob happens to be in a set of files that
they have pre-encrypted deterministically. This attack won a Wall of
Fame award from Tahoe-LAFS https://tahoe-lafs.org/hacktahoelafs/ )

So my idea is to randomly generate a key and nonce, make a libsodium
box of the file, and put it into a Repo under a randomly-generated
name. To share the cap, share the name, key, and nonce, perhaps as a
tidy URI.

The NAC TR proposal can do things that I've not covered here, but
doesn't actually directly talk about capabilities, so it's hard to
compare apples-to-apples. I get the feeling that it's very complex,
and that part of the complexity comes from allowing users to pick
their own names for data.

My current design, then, is for users to have several instances of
repo-ng or another Repo service running, geographically distrubuted.
They sync to each other with ChronoSync. Their repositories are full
of randomly-named opaque encrypted blobs. They use plain old NDN
backbone (which I'll set up and own too) to share across the void.

Failure modes: Nothing short of leaking the cap or finding a flaw in
the cryptographic construction should invalidate integrity and
confidentiality at the data level. Users associate their uploads with
their Repos, but their Repos can be given (non-user-picked!)
codenames, so tying a person to an uploaded cap is as hard as asking
the provider to turn over their account database. Mitigating the risk
of account information being leaked...it's an open problem IMO. I want
to not deploy accounts for precisely this reason, and instead craft
accountcaps for managing accounts without having to turn over too much
PII.

There's an alternative design where, instead of each uploader getting
their own Repo, there's a global Repo. This is what the original
Matador Tahoe-LAFS deployment does, with one single global
non-accounted namespace. This works great for anonymity but
not-so-great for the service provider getting paid, and I'm not sure
how to fix that tradeoff.

Hopefully this fleshes out the security goals of my design.

~ C.

----- Original Message -----
From: "Lixia Zhang" <lixia at cs.ucla.edu>
To:"Corbin" <cds at corbinsimpson.com>
Cc:<ndn-interest at lists.cs.ucla.edu>
Sent:Sun, 2 Jul 2017 12:59:15 -0700
Subject:Re: [Ndn-interest] repo-ng and least-authority storage

 > On Jun 27, 2017, at 8:32 PM, Corbin <cds at corbinsimpson.com> wrote:
 > 
 > Oh, I forgot redundancy! Let's say that I want to run three repos
in different availability zones; can I have them all synchronize with
each other somehow?
 > 
 > Peace,
 > ~ C.

 looks like no one has responded yet, so let me throw in a stone in a
hope to attract jade ;-)
 from your msgs it's not exactly clear what are the security goals you
want to achieve.

 for your 2 specific questions:
 1/ one does not need to trust storage servers; the NAC TR
specifically discussed this issue and suggested a solution
 https://named-data.net/wp-content/uploads/2016/02/ndn-0034-2-nac.pdf

 2/ one can sync up distributed repos using an NDN sync protocol. 
 several exist, ChronoSync got used most.

 > ------ Original message------
 > From: Corbin
 > Date: Tue, Jun 27, 2017 19:37
 > To: ndn-interest at lists.cs.ucla.edu;
 > Cc:
 > Subject:[Ndn-interest] repo-ng and least-authority storage
 > 
 > Hi,
 > 
 > I want to know if the following security design is
provider-independent; that is, whether it still holds even if I don't
trust the NDN nodes running repo-ng.
 > 
 > To make a cap for a file, generate a secret key and nonce, use
libsodium to put the file in a box with the key and nonce, and
finally, insert the box in a repo with a random name. The name, key,
and nonce form a capability for the file; the capability is necessary
and sufficient for file retrieval.
 > 
 > This is a lot less work than Tahoe-LAFS has to put in! Would it
really work?
 > 
 > Peace,
 > ~ C.
 > _______________________________________________
 > Ndn-interest mailing list
 > Ndn-interest at lists.cs.ucla.edu
 > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20170704/6635959e/attachment.html>