views:

68

answers:

2

This question comes as part of my doubts presented on a broader question about ideas implementing a small encrypted filesystem on Java Mobile phones (J2ME, BlackBerry, Android). Provided the litte feedback received, considering the density of the question, I decided to divide those doubts into small questions.

So to sum up I plan to "create" an encrypted filesystem for for mobile phones (with the help of BoucyCastle or a subset of JCE), providing an API that let access to them in a transparent way. Encryption would be carried out on a file basis (not blocks).

My question is this:

Is it a good idea to use only a symmetric key (maybe AES-256) to encrypt all the files (they wouldn't be that many, maybe tens of them) and store this key in a keystore (protected by a pin) or would you rather encrypt each file with an on-the-fly generated key stored alongside each file, encrypting that key with the "master" key stored on the keystore?

What are the benefits/drawbacks of each approach?

+4  A: 

Using a separate key for each file is more secure in that someone who lacks a key is unable to tell whether two files are identical.

Another option is to use the same key, but a different initialization vector with each file. You store the initialization vector (unencrypted) in the file's header.

Joe Albahari
Your second option is a good answer. There's no point in using multiple keys, because the protection is ultimately all provided by the initial key. On the other hand using IVs will reduce the success of known-plaintext attacks.
Graham Lee
I hadn't thought about your second option. It seems interesting
Fernando Miguélez
+3  A: 

I worked on a project were we had the exact same question and we went for option 2.


Pros of option 1

  • easy

Cons of option 1

  • if key is disclosed, all files will need to be re-encrypted
  • if key expires, all files need to be re-encrypted
  • for performance reason the key must be symmetric

Pros of option 2

  • if master key expires, individual keys are still fine, no need to re-encrypt the files
  • if master key is disclosed, a new master key can be created and each individual key will need to be re-encrypted with the new master key
  • per-user master key can be created; the extra level of indirection support this
  • for performance reason, the individual key must be symmetric, but the master key can be asymetric (this point is really important)

Cons of option 2

  • slight more complicated
  • sligth overhead to generate one symmetric key per file

Note that I considered the keystore itself (which has the pin) to be trusted; otherwise you can of course get access to anything if you get the pin. There's also the argument of comparing files, as mentioned in the other answer, but I don't think it's the main point.

ewernli
I hadn't considered key expiration. How would you handle it? I mean, is it ok to renew it every XXX months? On the other hand if expiration is an issue, wouldn't be per file key expiration also an issue?This is a singe user environment so this simplifies things a bit.
Fernando Miguélez
@Fernando Miguelez The expiration is more an issue in a multi-user environment where uses have individual key/certificates that can expired. Another thing to consider is if a user loses its key/certificate; we were using smartcards so that was an issue. The idea was indeed that the key/certificate was renewed each Xxxx moths. Maybe you don't need to address these issue.
ewernli
@ewernli. For this first version we do not plan to use certificates or multi-user environment (only a user per phone). The only requirement regarding the issue of updating security tokens would be the user PIN (which is not that complicated if we just reencode the keystore). I appreciate your considerations anyway.
Fernando Miguélez