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. =
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
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
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.
On Sun, Jan 16, 2005 at 08:11:58PM -0800, Cliff White wrote:
> -Spambayes-Trained: ham
> On Sun, 16 Jan 2005 11:42:15 -0800
> Kees Cook <kees@...> wrote:
> > 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=
> > > physical access to the box ( encrypted filesystems, boot-time stuff e=
> > > 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.
> > I may turn out that it just won't work, and that's okay too. I'm just=
> > trying to think about how it do it if you don't trust physical security=
> > It seems that there is less likely to be a secured room somewhere that=
> > holds the DB server. Besides, it's easy to pick locks.
> 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=
> > All the DoS stuff, though, is quite a concern. It's easy to DoS this=
> > system. The only way I can think of to avoid a DoS tends to be to NOT=
> > use a 1 server/multiple clients solution. To avoid DoS, all clients=20
> > need to know the data.
> Ya, and again, i'd remind you we'd like the system to be robust when run =
> old unreliable gear, having the data distributed easily contributes to th=
> > Maybe each client should be a Nomad? Make software updates much more=
> > difficult. But it avoids DoS. Peer-to-peer hardened data security.
> > BTW, this is bascially Digital Rights Management. Only we're trying to=
> > do it with personal information instead of movies. :)
> Again, it's wonderful to see these ideas.=20
> > --=20
> > Kees Cook @outflux.net
> > -------------------------------------------------------
> > 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
> > Openhive-discuss@...
> > https://lists.sourceforge.net/lists/listinfo/openhive-discuss
> 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
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
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org