Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I'm working on a project where we need to encrypt a large number of files and store them on the cloud. And I'm wondering if the following process would be secure (we have a “Hardware Security Module” and an “encryption server” in a private data center, only the files will be in the cloud).

Since the volume of the files is too big to be encrypted in an HSM, my idea is to:

  1. Have a 256 bit master encryption key in an HSM.
  2. Derive an encryption key by generating a 256 bit random number and HMAC-SHA2-256 it with the master encryption key.
  3. Take the rightmost 128 bits from the MAC and use that as an AES key.
  4. Take the leftmost 128 bits from the MAC and use them as the IV.
  5. Encrypt the content in an internal server.
  6. Overwrite the memory where the derived AES key was stored.
  7. Store some metadata of the file (including the 256bits random number from the 2nd step).

I would do something similar to generate a signing key:

  1. Have 256bit master signing key in an HSM.
  2. Derive a signing key by generating a 256 bit random number and HMAC-SHA2-256 it with the master signing key.
  3. MAC the encrypted file with the derived signing key
  4. Overwrite the memory where the derived signing key was stored.
  5. Store some metadata of the file (including the 256bits random number from the 2nd step).

To decrypt the data, I would use the random number to re-derive the key. What I'm trying to achieve with this is a different key per file, plus we can rotate the master key every now and then for extra security. Plus, after a few years, when we don't need those files, we can delete the master key (apart from deleting the files from the cloud).

I know the process above is not 100% secure, as the derived key will exist outside the HSM, but we need to keep a balance between security and cost. If storing the plain random numbers is not secure, I could have an AES key in the hsm only to encrypt the random numbers.

The level of security / assumptions I'm happy to live with is:

  • If the HSM is compromised, all files are compromised (this quite an obvious one)
  • If the encryption server is compromised, an attacker has access to the plain text files before they are encrypted (so I don't even bother to think about the attacker stealing the AES keys as they are in memory).
  • An attacker stealing the database (with the random numbers) plus all the files, cannot decrypt the data.

(I hope these assumptions are sensible - please let me know if you disagree!)

share|improve this question
    
Having never worked with HSM's, is there any sort of authorization with them? I.e., to prove that you are allowed to generate keys? An attacker stealing the database who also has access to the server with the HSM, could issue the random numbers to the HSM and get back the decryption keys. –  mikeazo Aug 22 at 12:30
1  
HSMs do have authorization and I think in the most complex attack scenario scenario, a very resourceful attacker, could impersonate the application doing the encryption and request the HSM to re-create the AES keys. Like I mentioned in the question, I know that this is a possible attack vector, but it the encryption server is compromised, we're in deep trouble. I think this is the same with any application. The encryption server would be behind a firewall and only a small group of people would have (audited) access to it. –  HocusPocus Aug 22 at 12:32
    
Your algorithm looks a little over-complicated to me. Why not just encrypt the per-file 256-bit random number (per-file key) with the secret key from the HSM and publish this encrypted key with the metadata? –  Hanno Binder Aug 22 at 13:40
    
I don't think I follow your idea @HannoBinder . The main idea of why to derive they key from a master key in the HSM is to allow us to, after a few years, delete the key from the HSM, which (in theory) would render impossible to recover the files (in practical terms this the same as "deleting" them, as no one should be able to decrypt them) –  HocusPocus Aug 22 at 13:48
    
When you dismiss the key from the HSM, no one will be able to decrypt the encrypted per-file keys anymore and so the files will be gone. Voilà. - Or is there something I'm missing? –  Hanno Binder Aug 22 at 13:55

2 Answers 2

up vote 8 down vote accepted

It looks like, given your adversary model, things should be secure. HMAC as a randomness extractor has been shown to be good, especially when we can assume the hash function is collision resistant. That paper also has some results which tell how you could guard against the collision resistance being broken (basically use a hash function with larger output size). If SHA-256 is broken any time soon, however, we are all in a lot of trouble, so I wouldn't be too worried about that attack.

share|improve this answer
    
Thanks for your answer @mikeazo. I hope the assumptions in the question are reasonable, as I do think that if the encryption server gets compromised, then it's a game over (and even more if the HSM gets compromised). –  Augusto Aug 22 at 17:48
    
@Augusto are you the OP? They seem reasonable to me. In any usable system there is going to be a point where security breaks. –  mikeazo Aug 22 at 17:58
    
no, I'm just starting in this new brave world of encryption. I find it difficult to know what is an "acceptable risk" too. –  Augusto Aug 22 at 18:03
    
mikeazo I agree, if sha-256 is broken we'll all going to be in trouble. @Augusto I agree, another concern I have is, since this files will be stored for a few years, AES-128 might be broken during that time and the cost of re-encrypting everything with another algo would be very high, but I hope that this doesn't happen in the next 10-20 years (otherwise, again, we're all going to be in trouble). –  HocusPocus Aug 23 at 21:49

It seems that you are trying to implement your own KBKDF (Key Based Key Derivation Function) using HMAC. Maybe it is better to use a pre-defined one.

It would be more sensible maybe to use an HSM that is FIPS certified for NIST SP 800-108. These use one of the KBKDFs defined in NIST SP 800-108.

You can still use the idea of the random by putting it in the context input field of the KBKDF. Note that if you have a nonce from context (e.g. hash over a file name) you do not strictly need a random value; just performing a KDF over the label / context should be enough as long as the combination is unique.

You should make sure that the key that is generated can be exported out of the HSM. If the algorithm is not available, it would make sense to implement one of the KDFs (e.g. the counter mode one) using a MAC algorithm provided by the HSM.

Note that all of the KDF's defined in SP 800-108 are using MAC (cipher based or hash based) as underlying function of the KDF.

share|improve this answer
    
Thanks @owlstead - I took a look at some of the KDFs that are provided by the HSM, but I wasn't able to decrypt the documentation to use them :S. I'll take a look at them again and come back. –  HocusPocus Aug 23 at 16:20
    
Many HSM's have a lot of insecure/older KDF's present. If those are not sufficient, you could try and use the HMAC functionality in the HSM. It is detrimental to security if you have to read the master key from the HSM (but you already knew that I guess). –  owlstead Aug 23 at 21:26
    
The master key will never leave the HSM, the idea is to use the HSM HMAC-SHA2-256 with the master key and the random number (different key and random for encryption and signing). –  HocusPocus Aug 23 at 21:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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