It looks to me like you have a very simple problem, which you're overcomplicating (and probably introducing lots of vulnerabilities).

Here's what I think you want (from what you've said):

Integrity is important. Confidentiality is not.
If an adversary changes the contents of your binary blob, you want your users to know about it so they can choose not to trust the data.
All admins have total access.
Admin's rights cannot be revoked.
Everybody else has read access.

From what I can tell, a simple system that would work is as follows:

<removed: see below>

[Edited by - alun on April 24, 2007 11:54:32 AM]

Quote:Original post by ddyer
You should enforce your shared data model through the
agent the manipulates the database, not through the
cryptography.

My agent will of course enforce the database sharing model, however the database is stored as a local file, which means if I just store it as plaintext there is nothing to stop someone from simply editing the file. The question becomes how do I make it so that my agent is the simplest form of access for my users and altogether useless for malicious users?

Quote:Original post by alun
Here's what I think you want (from what you've said):

Integrity is important. Confidentiality is not.
If an adversary changes the contents of your binary blob, you want your users to know about it so they can choose not to trust the data.
All admins have total access.
Admin's rights cannot be revoked.
Everybody else has read access.

Right and wrong. Integrity is important. Confidentiality is VITAL. While it would make the database useless if the Observer clients can change their own values (just like a banking system would be useless if you could change your balance on a whim), the database would reveal secrets about certain parts of the organization I'm developing this for. This would be an unacceptable outcome, unless this outcome were to come from some form of social engineering in which case there is nothing I could have done.

Admin's rights SHOULD in fact be revokable. However an admin should never be able to revoke his own rights, as this could lead to a database with no user files, and therefore no keys. This is not an intentional state unless the database is considered at risk. That said a revoked account is actually just a deleting of the user file. If it suspected that the admin may still be able to compromise the database, I am attempting to think of a system that will re-key the database, and lock out all users until they 'change' their passwords. So far all the possible choices require a remote server. Since an admin has rights to revoke any other admins account anyways, I will leave this topic for a future release (remote server used for security), and whenever a database is re-keyed all the user accounts are deleted and up to the admin to re-instate (excluding the admin doing the re-keying since we can easily change his stored key while he is logged in).

Final correction is Observer class accounts have read access. But they too have a password! These are particular individuals who are screened and trusted as much as admins, but an impartial observer has nothing to gain by modifying the data... So why give too much access? That said, 'everyone' else has NO access. Both admins and observers have as much to gain or lose from giving away this information, so let's not bother with antitrust issues.

Quote:Original post by alun
From what I can tell, a simple system that would work is as follows:

Distribute a signing key to all admins.
Add a message authentication code to the end of the file, and when writing the file, sign the MAC.
When reading the file, if the signature on the MAC is not valid, you know that the file has been tampered with.

I do like your authentication method. I would need to encrypt the MAC as well correct? Wouldn't I still be relying on the same system I have now as my base system? What benefits does this have?

I do plan on having a form of authentication, however, that's a topic for future releases, as I'm under a bit of a time bind for the first release.

Thanks for all your help guys,
~F

If you have any last tips or tricks please post!

Could you be a bit clearer? (Security and crypto are areas where precision is very important).

Quote:Original post by FenixRoA
Right and wrong. Integrity is important. Confidentiality is VITAL. While it would make the database useless if the Observer clients can change their own values (just like a banking system would be useless if you could change your balance on a whim), the database would reveal secrets about certain parts of the organization I'm developing this for. This would be an unacceptable outcome, unless this outcome were to come from some form of social engineering in which case there is nothing I could have done.

What do you mean by vital? An online shop say that protecting their customer's credit card details is 'vital'. A company might say that not revealing their trade secrets is 'vital'. The military might say that not revealing their nuclear missile launch codes to the enemy is 'vital'.
(Why do you say that you can't do anything about social engineering? My area of expertise is protecting systems from user compromise, password compromise, and users who are working for the adversary.)

Quote:Original post by FenixRoA
Admin's rights SHOULD in fact be revokable. ... So far all the possible choices require a remote server. Since an admin has rights to revoke any other admins account anyways, I will leave this topic for a future release.

To my knowledge, all such systems would need a remote server. There's probably a proof of that around somewhere...
Anyway, in the release we're talking about, admin rights are *not* revocable?

Quote:Original post by FenixRoA
Final correction is Observer class accounts have read access. But they too have a password!

You frequently say "password". What exactly do you mean by that?
Generally, you would use a "password" (a user-selected, easy to remember, short sequence of characters) to log into a remote server.
Passwords are not generally used in cryptographic systems because they're very low entropy.

Quote:Original post by FenixRoA

Quote:Original post by alun
From what I can tell, a simple system that would work is as follows:

Distribute a signing key to all admins.
Add a message authentication code to the end of the file, and when writing the file, sign the MAC.
When reading the file, if the signature on the MAC is not valid, you know that the file has been tampered with.

I do like your authentication method.

You shouldn't like anything about that. It's horribly broken, but looks reasonable at first glance. I snuck a little white hat attack into my post. If you trust random people on an internet forum to 'help' you design your security system, you could be trusting an adversary.

If somebody can verify that the message produces the given MAC, they can trivially generate another message which produces the same MAC, and (since only the MAC was signed) the same digital signature.
Treating MACs as hashes is a classic security flaw, but it had been up there for almost 24 hours and nobody replied.
Exercise for the reader: Assuming it's using a CMAC prove that it really is trivial...

You can get ideas from us about how to do the security, but you'll have to find somebody you can trust to teach you how to verify that it actually works.

[Edited by - alun on April 24, 2007 11:19:03 AM]

Quote:Original post by alun
What do you mean by vital? An online shop say that protecting their customer's credit card details is 'vital'. A company might say that not revealing their trade secrets is 'vital'. The military might say that not revealing their nuclear missile launch codes to the enemy is 'vital'.

Vital in that it is absolutely unacceptable to allow this information to get into certain hands. I do not see how the metadata would change the security concerns of this, and so I won't release any such data. Simply treat it as a person might use this to keep his files from his family, the guy down the street, and people in his organization (and perhaps even the law).

Quote:Original post by alun
(Why do you say that you can't do anything about social engineering? My area of expertise is protecting systems from user compromise, password compromise, and users who are working for the adversary.)

I find that intriguing. This seems like a particularly difficult topic to tackle. Off the top of my head I know it might be suspicious if 2 people using the same single-user account log on simultaneously or if a password was accepted to allow access to an account after a billion passwords were attempted in the last 20 minutes, etc. However keep in mind that in this system there is only one access point (no remote access, only local user access). Typically the access point will be from the same program which allows only one instance. While something like keeping track of the number of passwords entered incorrectly may raise a flag, that is entirely independent of the database component I'm building (but rather something to be tackled by people who are implementing my database component). That said is there any social engineering defense I could put directly inside the database component or that I should include in it's specification/documentation that you can think of? Perhaps giving me the names of topics and I can read further on it. I don't want you to waste all your time on me :).

Quote:Original post by alun
To my knowledge, all such systems would need a remote server. There's probably a proof of that around somewhere...
Anyway, in the release we're talking about, admin rights are *not* revocable?

They are but only in such a way that their respecive user file is deleted. I know there is no way to guarentee that they didn't privately decrypt their user file, and copied the keys, and without a remote system it will be incredibly difficult to re-key the system. As such I was thinking that any admin can re-key a database and must re-instate any users who should still have access with some kind of personal passwords (that can be changed later).

Quote:Original post by alun
You frequently say "password". What exactly do you mean by that?
Generally, you would use a "password" (a user-selected, easy to remember, short sequence of characters) to log into a remote server.
Passwords are not generally used in cryptographic systems because they're very low entropy.

Actually, if you read a few posts up (I think) I was going to put the user password through a hash algorithm and use that to encrypt their user files (so that the database keys are not stored unencrypted anywhere on the system). Is this a bad idea?

Quote:Original post by alun
You shouldn't like anything about that. It's horribly broken, but looks reasonable at first glance. I snuck a little white hat attack into my post. If you trust random people on an internet forum to 'help' you design your security system, you could be trusting an adversary.

If somebody can verify that the message produces the given MAC, they can trivially generate another message which produces the same MAC, and (since only the MAC was signed) the same digital signature.
Treating MACs as hashes is a classic security flaw, but it had been up there for almost 24 hours and nobody replied.

Wow, sneaky. See I obviously don't have the experience that someone like you does, and I was hoping to derive a little inspiration from you guys. However, as I said authentication is a topic I will tackle in future releases.

Quote:Original post by alun
You can get ideas from us about how to do the security, but you'll have to find somebody you can trust to teach you how to verify that it actually works.

Good advice. I try to take everything with a grain of salt whenever the internet is concerned, however I have to say that I did not see the so-called "white hat" attack. Thanks for the reality check.

EDIT: I forgot to define what "Re-keying" a database means. Basically just decrypt the database, and re-encrypt it with new keys, thereby invalidating the previous keys which are used by the malicious user.