Re: [Vrs-development] Encrypted NFS with OpenSSH and Linux

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
 >
> 
> Well...
> If we're proposing a tight binary protocol of some
> sort to gaffa-tape LDS's 
> into a VRS cluster, then we might as well do the
> encryption ourselves.  Easy 
> with openSSL.
> 

How would a VPN appraoch compair to an SSL one, pros
and cons so to speak.  I need educatiuon in these
areas.

> The LDS's could hand out their Public keys on
> request - or it could be the 
> responsibility of the Node Discovery Server ( or
> whatever ).
> 

makes sense

> Private keys are kept private.  This is okay
> actually, because the owner of 
> an LDS has a vested interest in keeping their
> private key secure - and so is 
> not open to attack by the owner of that LDS!
> 
> Oh.  Bugger....
> 
> I thought I had a great idea just for a moment.  Now
> here's a thing:
> If resources are stored ENCRYPTED across the
> cluster, then every LDS must 
> know both the public key that encrypts the data and
> the private key that 
> decrypts it.  So where is the security in that?
> 

I think we are talking about two different points of
encryption.  One is encrupytion of the communications
channels with SSL or such.  The other is the
encryption of the repository data file (or just the
blocks if that a better approach).  This one should
not be done with a public key system, but one purely
internal to a single running cluster.  


> The keys may be stored within our virtual
> filesystem, but they're still 
> there.  And as this project is openSource, well,
> someone could very easily 
> hack the code, build an LDS, join a VRS and suck all
> the data out of it.
> 

Ya, they could have, till we added the Untrusted LDS
thing.  <<sigh>>  And that could probably still happen
if the bad guy was a trusted LDS node.  If I got a
good handle on the Untrusted node lock, there would
not be one bloody thing that cound be changed in a
rogue LDS that would cause a Cluster to accpet it as
trusted if it's marked as such in the running cluster.

(humm  .. just thought of one possibility that needs
pluging.  If the rogue LDS spoofed a trusted node's IP
address.  Can we plug that one?)

> I've missed some fundamental property that makes it
> all secure haven't I?
> Hope so.
> 

The key may be in the Cluster's self image.  Every
running Cluster has a self image, so to speak.  It
knows what machines are subscribed, what nodes are
currently online, what data files are owned by whom,
what all needed encryption keys are, and so on.  These
are the aspects that make any one running Cluster
unique, and that are used to control it's cohesion.
One of those items is the Trust Index on each
subscribed node.  This image is never stored on disk
in any form. (Unless it's configured to backup upon
death.)  It is only handed from one trusted LDS to
another trusted LDS.

We talked about node specialization earlier and in the
Architecture material.  The Untrusted node is another
example of node specialization.  It is given a very
limited part of that Cluster image when it comes
online.  All it knows is where to edit and maintain
the dataset it owns.  It know nothing else about the
rest of the Cluster.  Over time, it starts receiving
Repository storage and retreival requests from various
other nodes on the cluster.  And if it kept track, it
would eventually have a list of the IP's of the other
nodes.  But that's all.  The mirror block data it
sends and retreives are random hunks of slices of a
encrypted data file, just parts.  It has no means at
all of understanding them.


I don't think the restrictions on the Untrusted LDS
will do much harm to the cluster.  It does reduce the
resources avaiable as a whole.  Instead of asking now
how many nodes do we need to make a good running
cluster, we need to ask how many type I, II, and III
nodes do we need.  Each ends up providing different
things to the life of the cluster.

Type I, the fully trusted node, are now the brains of
the VRS.  These maintain the cluster image.  At least
one of these has to be running at all times, or the
VRS dies.

Type II and type I  contribute processing resources to
the cluster.  They participate in the task
distribution activities and can receive and fulfill
services requests.  

All types can contribute memory resources for the
clusters Repository storage.  This is likly to be the
resource in greatest demand, especially with higher
mirror to cluster block ratios. 

So in the end, the resources that an Untrusted node
can not provide may not be needed or used anyway.  So
the cost to the Cluster as a whole is small.  ( or at
least that's the theory.)

And the benifits in addressing the security and
privacy imperative are very great.




__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com