3
$\begingroup$

I'm currently working on web services which allows to send and retrieve data.

The data belong to a team. A team is composed of users.

Each authenticated user can send and retrieve data to/from their team.

I need to add encryption to this with the following requirements:

  • Data are encrypted on the server and the server doesn't store (might handle, but not store) any key
  • Each user has a different key or password to decrypt the data
  • Each user encrypts the data before sending it (data must of course be "decryptable" by other team users)

After searching for hours, I came to this solution, however I would like to have some comments whether this seems to be good or not, and if I could improve it.

  • Each user, at creation time, receives a RSA public and a private key, the keys are generated by the server, the public key is stored in the database, the private key is immediately sent back to the user via SSL secured connection and removed from server memory.

  • When the first user is added to a new team, the server generates a 64bits key (for AES). The user public key is used to encrypt the AES key. The encrypted AES key is stored in the database (user/team pair).

  • When a user receives/sends some data, he first has to get the encrypted AES key from the server. The user uses his private key to decrypt the AES key. For "send" action, he uses the AES key to encrypt the data. For "receive" action, he uses the AES key to decrypt the data.

  • When a user needs to be added to a team, the existing team member will use the new user public key to encrypt the AES key then send the new user info to the server (user info + encrypted AES key for the new user/team pair)

Two things I don't like:

  • If a user needs to be removed from a team, he still could have saved the AES key. This is not a major problem has he won't be authenticated anymore and therefore won't have access to the encrypted data anymore.

  • AES requires an IV, which should be different for each encrypted piece of data, so I would need to store an IV for each piece of data.

Do you think of any better solution ?

Thank you

Improve this question
$\endgroup$
4
  • $\begingroup$ AES uses 128 bit, 192 bit, or 256 bit keys. $\endgroup$
    – user4982
    Jan 15, 2014 at 15:07
  • $\begingroup$ Why send user's RSA private key to the user? Usually it is better let user generate her private key. Having private key in foreign hands cause it easily to leak to unintended parties. $\endgroup$
    – user4982
    Jan 15, 2014 at 15:10
  • $\begingroup$ Do you have example how decrypting data encrypted by other team member would work in practice? If the data is encrypted using per user keys, the handling is bit complex and not it is not illustrated by the question. $\endgroup$
    – user4982
    Jan 15, 2014 at 15:16
  • $\begingroup$ IVs are usually stored right with the encrypted data. In your typical AES/CBC/PKCS7 scheme, the first 16 bytes are the IV, followed by the actual encrypted data. $\endgroup$
    – wallenborn
    Jan 15, 2014 at 16:53

2 Answers 2

Reset to default
1
$\begingroup$

One potential risk is your AES key length. Using a key length of 64 bits or less is not advisable as it can be relatively easy to brute force these days. Recommend that you use at least 128 bits.

As for your problem when a user is removed, you may like to try something similar to PGP. Each time you commit a file to the server, you encrypt it with a randomly generated symmetric key and encrypt the key with the public keys of all other legitimate users. In this way, a removed user would no longer be able to access newer files.

But I dunno if that will be secure enough, its two cents worth.

Improve this answer
$\endgroup$
1
  • $\begingroup$ If there is a large number of users, encrypting keys with all uses allowed to access the file may take substantial amount of time and space. How about adding access right for new user to existing file(s)? $\endgroup$
    – user4982
    Jan 15, 2014 at 15:27
1
$\begingroup$

If I understand your scheme correctly, then there is no need for "RSA" (or any public key scheme for that matter). The only exception is the "new user has to be added", which does not really need the public key scheme. First, you assume that only authenticated users have access, and usually this leads to a secure, authenticated connection (mutual authentication is required here).

If you replace RSA with an other AES instance, it works like this:

  • User receives an AES "user-key" (not stored on server)
  • First user gets the AES "data key" (there is no point using public key encryption: both parties know the key)
  • When a new user is added, he gets an AES user-key from the server. At this point the server can just request the data key from an existing user and forward it without saving (probably okay in your assumptions), or send a random session key to the new and old user (who then can talk directly, using this key), or just connect the users in any other way.

About the things you don't like: The first point is something to consider. But your conclusion is not entirely correct: What happens if the user is still in the system, but only got removed from a specific team? Considering your second point: Depending on the mode of operation there is an IV, but its length (16-32 byte) should be pretty small compared to the actual data.

You should ask yourself the question if you really want to solve access control via "knowledge of some secret key". The obvious problem is, that you can not revoke access permissions reliably. Maybe you can force the server to forget/delete things, but it won't work for the users. And maybe you want to revoke some access permissions without completely banning the user.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.