OK, I need help developing a permission system. I was thinking of doing something like this. All data is saved in one custom database file. The data is encrypted using an Asymmetric algorithm (one key to encrypt, and one to decrypt). The data is accessible from any one of many users. There are 2 user classes: Admin and Observer. Admins can read, modify, or add any data necessary. Observers can only read the data in the file. So I was thinking that the user files would be seperated and encrypted using a symmetric algorithm (one key for both encrypting and decrypting) with their password as a key. Inside the user file for observers, I would just encrypt the key that will allow them to decrypt the database data. For admins, I encrypt both the encryption and the decryption keys. So that's all great and good, except I have recently come across some information that disturbs me. I tried joining a cryptography forum but the activation email is 2-days pending :(. So I was hoping you guys could help me straighten out my information and maybe help me understand how this is usually done. Firstly I was told that Asymmetric encryption is actually VERY slow (on the order of 1000 times slower then symmetric encryption). Also I know that it is extraordinarily difficult to derive the decryption key from the encryption key, but I'm under the impression that it is relatively simple to derive the encryption key from the decryption key (entirely undermining my permission system). So next I was thinking if I could just find some way to make writing data dependent entirely on some asymmetrically encrypted data, that would work better, however if it is true that the encryption key is easily derived from the decryption key this is completely invalid. So in short, I've been studying encryption systems as best I could but have come up with a headache instead... Got any input? please post! Thanks, ~F

Yes asymmetric cryptography is substantially slower than symmetric crypto - especially symmetric algorithms like AES that are designed to run fast on modern hardware. But computers are fast so this may be irrelevent. In any case it is a trivial matter to encrypt a large amount of data with a unique symmetric key (for example a random number) then encrypt the symmetric key with asymmetric crypto and you're all set.

For typical asymmetric cryto like RSA the two keys are interchangable - they are usually referred to as private and public keys rather than as encryption and decryption keys because in they can be used for both purposes and indeed are, confidentiality uses a public key to encrypt and a private key to decrypt while integrity uses a private key to encrypt and a public key to decrypt. Public key cryptograpy is not as simple as the private key being two large primes and the public key being their product (though it is often portrayed as such) which may be where you are getting your impressed of it from. It's not a whole lot more complicated and that is the idea that makes it work, but the actual algorithm to generate the keys is different.

All that said. I'm a little confused as to what you are trying to accomplish. You say you are creating a permission system, but don't really explain what you mean by this - nothing in your proposed scheme prevents an "observer" from writing data to your database. True it will be utter garbage because he is unable to encrypt it properly, but that doesn't prevent him from messing up your database and potentially deleting all sorts of stuff. You also make reference to user files and a database file but don't explain how these things are different or what they contain.

I guess I don't really understand what you are proposing, but I do know that implementing permission systems based on cryptography is a little unusual. Keep in mind that confidentially, integrity, and permissions are all very different parts of information security and I feel like you've blurred the lines between them more than is safe.

Thanks for the quick reply cshowe.

I obviously didn't explain my scheme well. Let me try to explain it better.

I'm essentially making a form of ZIP or CAB file (a whole directory structure stored in a single file). There will be one giant data blob which is all the file data combined into one long stream of binary data, and the rest will be short file descriptors (name, size, location in the data blob) and directories.

Basically I want to be able to encrypt the data blob (or parts of it). Encrypting the directory structure itself is unimportant and a topic for future development.

Now I have a set of users (stored in a central user file or a series of files). They each set their own passwords upon creation. Their user file is encrypted using a symmetric algorithm, where their password is the secret key.

There are 2 base types of users. Ones with read access for the database and ones with read AND write access (Observers and Admins respectively). My program will not allow writing of data back to the database. However, I want to avoid the possibility that someone with enough experience, could potentially modify the data to his advantage using his own editor or program. Admittedly anyone could enter into the database file and change random data, but the point is he/she won't be able to change the data to anything they want.

In that comes my proposed "permission system".


So here's the idea:

An asymmetric algorithm with 2 keys.

To read data one only needs the decryption key, while to write new data someone will need the encryption key. On the other hand someone who had both can also modify existing data.

Database File:
<file descriptors>...</file descriptors>
<Encrypted or Partially encrypted Asymmetrically>
<File Data Pool>
....................
</File Data Pool>
</Encrypted or Partially encrypted Asymmetrically>

Now when an admin creates an 'Observer' class account (read-only), the program will make a user file (or add another record in the user database). The file (or record) will be encrypted using the user's password and a symmetric algorithm.

User File:
<User info>....</User info>
<Permissions>
<Database Encryption Key>
341j2930212fascwe //randomly chosen at database creation
</Database Encryption Key>
<Database Decryption Key>
9030j209209k0apao //randomly chosen at database creation
</Database Decryption Key>
</Permissions>

So when a user logs in, his user file is decrypted in memory, and the key's given to him are extracted from the file. So an observer account will have the "Database Encryption Key" as an arbitrary 'Unknown' value.

This will allow the user to decrypt and read the data but not be able to modify it's contents or add to it.

Do I have a good idea? Is this how it's generally done? Or am I just going the wrong way entirely?

I accept criticisms and suggestions, but I am fairly new to this stuff,
~F

Quote:Original post by FenixRoA
So I was thinking that the user files would be seperated and encrypted using a symmetric algorithm (one key for both encrypting and decrypting) with their password as a key.

Inside the user file for observers, I would just encrypt the key that will allow them to decrypt the database data.

For admins, I encrypt both the encryption and the decryption keys.

How would that stop observers from overwriting the data with random stuff?

Quote:Firstly I was told that Asymmetric encryption is actually VERY slow (on the order of 1000 times slower then symmetric encryption).

Yes. Often it's used as an adjunct to symmetric encryption; whether you'll be able to use that remains to be seen.

Quote:Also I know that it is extraordinarily difficult to derive the decryption key from the encryption key, but I'm under the impression that it is relatively simple to derive the encryption key from the decryption key (entirely undermining my permission system).

You're incorrect. The two operations are mathematically identical.

Alright. That clarifies things somewhat.

It sounds like you just need for Admins to sign the database. That way, users would know if a non-admin had made changes.

Quote:Original post by Sneftel
Alright. That clarifies things somewhat.

It sounds like you just need for Admins to sign the database. That way, users would know if a non-admin had made changes.

Sounds like you approve of my system. I'm happy to hear that it works.

I'll put into consideration signing off on changes to the database. I like that idea alot.

Does anyone know on what order of size the database will be before it takes too long to save it, if I'm using the fastest Asymmetric algorithm you know (too long = ~10 seconds).

I'm looking on saving relatively small data. Up to around 50-100 MB max.

If no one knows I'll just leave this for the benchmarking period of the product.


Thanks so much for all your help,
~F

I see what you're trying to do - but there are a lot of considerations here. I'd still need more information to give you a really good evaluation - for example is this file stored locally or remotely. If it's stored locally on the user's hard drive then why do you need to support multiple accounts being able to log into it? If it's stored remotely then there are much better ways of going about this sort of thing.

Something to keep in mind is that data can only be encrypted by a single key - this means that all users who need to access a particular piece of data will have to have the same key - this could potentially be a huge problem if you want different users to be able to access the same portions of the database. An admin would need to know all possible keys used to encrypt the database if they are to be true administrators. You could just use the same key across the entire database but this has obvious security considerations.

Information security systems are really context sensitive - what are you trying to do with this system? What's stored in the database? How many observers are there? How many administrators? I'd like to help you with this but I feel like knowing the context this system will be used in is essential to doing it right.

Quote:is this file stored locally or remotely. If it's stored locally on the user's hard drive then why do you need to support multiple accounts being able to log into it? If it's stored remotely then there are much better ways of going about this sort of thing.

The data is stored locally, however, it is a system that is accessible by many people. Some of which have no need for read or write access to the database. Therefore I thought a user system would be fine. Even a standard guest account where everyone that needs access to the database knows the same password.

Quote:
Something to keep in mind is that data can only be encrypted by a single key - this means that all users who need to access a particular piece of data will have to have the same key - this could potentially be a huge problem if you want different users to be able to access the same portions of the database. An admin would need to know all possible keys used to encrypt the database if they are to be true administrators. You could just use the same key across the entire database but this has obvious security considerations.

Oh? Interesting. I knew that I would need to encrypt the entire database with a single key, and that was the original intention. The idea was that the first admin account (also known as the creator in terms of the database) would have the keys encrypted into his user record. Then whenever he makes a new user the keys he selects are copied to the new record encoded with the new users password. You mention security considerations? Am I missing something?

Quote:
Information security systems are really context sensitive - what are you trying to do with this system? What's stored in the database? How many observers are there? How many administrators? I'd like to help you with this but I feel like knowing the context this system will be used in is essential to doing it right.

I agree completely and would gladly give you the details, however there are certain limitations, as the subject-matter intended for the database is very sensitive information. Suffice to say that it is being used in place of a directory structure. I want to be able to make directories with files in them, and sub-directories etc. Each file should be able to encrypt seperately from one another (one file can be encrypted while it's neighbors are entirely unencrypted).

The intended data will keep track of a currency with little to no real world value, but shouldn't matter. I'd like the data to be saved on the fly, but I imagine everytime there is a tiny change I'd need to update the entire file.

There will be many (at least one but possibly more admins to any valid database (an invalid database is one where all the copies of the keys are corrupted or lost, and the data should then be unretrievable). There will be zero to many (possibly one or more) observer class users.

Also, if I'm using the .Net implementation of AsymmetricAlgorithm, what will happen if I have 2 files that I need to encrypt, and I encrypt them using the same AsymmetricAlgorithm? Will I need to begin decrypting from the start of the first file if I wanna read the 2nd file?

e.g.

WriteData(AAlg.Encrypt(file1data));
WriteData(AAlg.Encrypt(file2data));
CloseDatabase();
OpenDatabase();
AllData = ReadAllData();
decData = AAlg.Decrypt(Alldata, file2dataStart, file2dataSize);
//decData == file2data?

OR would I need to first decrypt file1data to get AAlg to the correct state in order to decrypt file2data?

I suppose I can just read the documentation for AsymmetricAlgorithm, but if you know the answer please post,
~F

EDIT:
Fixed pseudo-code

EDIT2:
Forgot to answer some more of the questions I quoted from cshowe

Quote:Original post by FenixRoA
The data is stored locally, however, it is a system that is accessible by many people. Some of which have no need for read or write access to the database. Therefore I thought a user system would be fine. Even a standard guest account where everyone that needs access to the database knows the same password.

Quote:Original post by FenixRoA
the subject-matter intended for the database is very sensitive information.

This alone makes me very nervous. If the data is that sensitive then storing it on a local machine seems really risky. As does a roll-your-own security system. If you really want security you should look into a well audited well tested security system. I know some about information security and cryptography but would be very uncomfortable signing off on a program used to secure truly sensitive information

That said:

Quote:Original post by FenixRoA
Oh? Interesting. I knew that I would need to encrypt the entire database with a single key, and that was the original intention. You mention security considerations? Am I missing something?

Consider the security implications of the key being compromised. One bad user allows access to the the entire database. You've actually got a pretty good system for fixing this inherent in your user files - if a bad user is identified you can remove their permissions and change the key, but identifying a bad user is impossible under the current system.

I hadn't mentioned that those who are granted user permissions are screened and trusted. I do know that if one bad apple sprouts up he 'COULD' potentially supply someone more knowledgeable with his user file and password and the database would become at risk of exposure, however, that said, this is the best system I could come up with.

While we are not guarding any trade secrets, it is vital to us that if someone were to attempt hacking the database, he or she would need an extraordinary amount of qualification. Also in order to change the database, one would need to get the file off the local system (as the tools to edit the database manually are not available on the system) and then overwrite the database. Perhaps some kind of protection against the file's 'date modified' or something similar...

In any case, I had considered finding a more commercial security package, but am uncertain as to who to turn too. I am quite happy with this system if it will work as I've said, and I appreciate you taking the time to guide me through this.

I will begin development and will post here further if I hit any roadblocks.

And after reading your last post cshowe, I will come on gamedev, and let you know "you told me so..." after someone actually manages to hack into the database.

My main concern was that in my system, only people who are trusted to begin with have access to the database, and I think that I've verified that. In order for the security to be compromised someone would need to get the password of an admin, decrypt his user file, and use the database keys to decrypt the database itself, modify the data, re-encrypt the data with the provided keys and hope no one noticed... I think at that point a hacker would instead consider just using a keylogger and modifying the data directly from the admin account.

So I leave off with this thought. We have the technology to completely hide data from strangers, but we do not have the technology to hide the data from ourselves. How many layers of encryption do you think it would take to protect us from social engineers and jealous admin's girlfriends?