Re: [Openhive-discuss] Nomad

[Seth A. W. <se...@ta...>]

I'm a little late to the discussion, having just subscribed, but,=20
activist offices generally have no semblance of security, physical or=20
otherwise.  Until you start getting into the radical groups, of course. =20
The Weather Underground was able to avoid detection by the FBI for years=20
for a reason (and the ELF in modern times as well).  In other news,=20
Osama Bin Laden is still missing, despite all the technology showcased=20
on Cold Case Files.

DoS attacks from the network aren't going to be all that significant, I=20
believe.  I'd be more worried about DoS attacks caused by false=20
information entered into the system.

In the medical industry, it's generally considered safe to assume two=20
people are the same people when you have three or more pieces of=20
information about a person line up (name, address, dob, phone number,=20
for example).  That's how the Oregon DHS integrates immunization records=20
=66rom all the various clinics throughout the state.  I believe if we=20
maintain the three-datum criterium and then establish a web of trust=20
model to the data sources, we could make DoS attacks due to false=20
information very difficult.  All data input should be signed by the=20
client nodes down to the individual who entered the data and each client=20
node should have trust established by other trusted agents.  The web of=20
trust data should be completely dynamic, meaning that an untrusted=20
volunteer could enter data and if they prove themselves worthy, they=20
could have their trust value of their supervisor increased as they grow=20
more trustworthy, that way the data when they first enter data has as=20
much confidence as later, when they are trusted; and if they turn out to=20
be moles, all their data can be made suspect.

I was thinking this way:

private data and public record data would be treated differently.  The=20
ability of a person to establish the privacy of their own data would be=20
done in a cascading access control list style.

Each user would be given the opportunity to control which organizations=20
received their information provided through each entity, and how far up=20
the chain it could go.  John Doe could decide that they only want the=20
organization they are dealing with to know all their information.  They=20
could also decide to let the Oregon Conservation Network have access to=20
their address and phone number, but nothing else, by changing their ACL=20
on a per-item basis.  So there are two ACL styles: per-orgnization and=20
per-data-item.  Also, each organization would have its own level of ACL. =
=20
They may decide that under no circumstances would they share their phone=20
numbers with any other entities.  This would override John's wish, but=20
also, John's denials would also override the organization's default rule=20
to allow all phone numbers to be shared with a certain group.  The idea=20
is that a denial overrides all other accepts at the same point in the=20
ACL cascade.  The organization would most likely be blocking all=20
financial data on their own ACL, providing at least some sense of sanity=20
to the system.

Since each set of data is signed by each client-machine setup for=20
validity, the central server merely acts as a kind of clearing house,=20
not actually storing a central databse (all the information would be=20
decentralized).  In addition, the client machine would be able to=20
encrypt data it shares with each outside organization with the=20
organization's own public key, guaranteeing that the data sharing is=20
handled at the client level, with no trust on the server.

With just a set of servers, all performing identical tasks with only the=20
unified list of names of the participating organizations and their=20
respective servers, each organization would be able to effectively share=20
their information in a relatively private and predictable way.  In fact,=20
the central servers could merely be standard email servers, and the=20
encryption could be gpg email.  The only thing the clients would need to=20
know is the list of available peers and respective public key files and=20
email addresses.

So how do we make it a true single-sign-on mechanism?  Easy.  If you are=20
registered with group A, the client takes three items of personal=20
information and hashes them together using a cryptographically-secure=20
hash algorithm and provide the type of data used to make the hash.  This=20
is an anonymous way to identify the user.  They can then save this hash=20
and use it to represent themselves to the other organizations (B) and=20
have full configuration of their shared data already available.  When=20
they create their first account, they would have a password that=20
identifies them to the organization.  A javascript-based md5 algorithm=20
would hash the password with the organization requesting authentication=20
(B) and a salt initialization vector.  This would then be submitted to=20
the originating organization (A) for a yes or no response for=20
authentication.  With the md5 trickery, the user is able to not divulge=20
his/her password to the requesting organization (B) and the=20
authenticating organization (A) would also be able to know who is=20
requesting authorization (B) and deny authorization to groups not in an=20
approved list of exchange partners.

With user authentication you can then provide rating systems for=20
volunteers.  If you have a good volunteer with a track record, you can=20
tell what history they have with previous groups and what approval=20
ratings each task creator gave them, kinda like ebay, you'd know what=20
volunteers should be doing what, and which ones are developing trust=20
within the system.  If a user says, "I can help call these people" and=20
has only flaked out in the past, you know you don't have to bother=20
responding. ;) That can help dussuade a denial of service attack with=20
inappropriate volunteer management.

OK, now I have to go to sleep.  Chew on that for a while and I hope I=20
didn't repeat too much of what was already said so far.

Seth

On Sun, Jan 16, 2005 at 08:11:58PM -0800, Cliff White wrote:
> -Spambayes-Trained: ham
>=20
> On Sun, 16 Jan 2005 11:42:15 -0800
> Kees Cook <ke...@ou...> wrote:
>=20
> > On Sun, Jan 16, 2005 at 07:23:11AM -0800, Cliff White wrote:
> > > Also, many of your ideas seem to be protection against people who hav=
e=20
> > > physical access to the box ( encrypted filesystems, boot-time stuff e=
tc. )=20
> > > How likely is this to be an issue, with a Web-provided service?
> > > And if a Bad Person has physical access, won't they just steal the
> > > box, thus doing a DOS?=20
> > >=20
> > > Remember, these admins are all going to be volunteers.
> > > Creating a system that does not match their previous experience=20
> > > ( no remote admin? ), _and is difficult to change
> > > might be great fun, but probably won't get used.
> > > They'll just stick with Access.
> >=20
> > I may turn out that it just won't work, and that's okay too.  I'm just=
=20
> > trying to think about how it do it if you don't trust physical security=
=2E =20
> > It seems that there is less likely to be a secured room somewhere that=
=20
> > holds the DB server.  Besides, it's easy to pick locks.
>=20
> That's good to think that way. I would assume a secured room to be a very
> rare exception. How much physical security do the Greens have on their of=
fice? :)=20
>=20
> >=20
> > All the DoS stuff, though, is quite a concern.  It's easy to DoS this=
=20
> > system.  The only way I can think of to avoid a DoS tends to be to NOT=
=20
> > use a 1 server/multiple clients solution.  To avoid DoS, all clients=20
> > need to know the data.
>=20
> Ya, and again, i'd remind you we'd like the system to be robust when run =
on
> old unreliable gear, having the data distributed easily contributes to th=
is.=20
>=20
> > Maybe each client should be a Nomad?  Make software updates much more=
=20
> > difficult.  But it avoids DoS.  Peer-to-peer hardened data security.
> >=20
> > BTW, this is bascially Digital Rights Management.  Only we're trying to=
=20
> > do it with personal information instead of movies.  :)
> >=20
> Again, it's wonderful to see these ideas.=20
> cliffw
>=20
> > --=20
> > Kees Cook                                            @outflux.net
> >=20
> >=20
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Openhive-discuss mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openhive-discuss
> >=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Openhive-discuss mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/li
--=20
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A =3D 36AD 8A92 8499 8439 E6A8  3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=3Dget&search=3D0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org