5

If you have a symmetric key which is negotiated via SRP protocol between a mobile device (e.g. smartphone) and a server, what would be a safe way to persist this resulting key on each side?

On the client side you could use PBKDF2 or a similar key derivation function to generate a key to then use to encrypt/decrypt the symmetric key before using it. Would this be considered (acceptably) safe?

What possibilities are there on the server side? What procedure would be considered safe to store such a key in a database?

How does for example Amazon store their symmetric keys used for their query string authentication for S3? (For information: On S3 you can restrict access to stored objects so that only requests with a valid signature (created using HMAC) are granted access to the requested (restricted) object)

MSc
  • 51
  • 2
  • possible duplicate of [How to securely hash passwords?](http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) – RoraΖ Mar 30 '15 at 13:51
  • While about passwords rather than crypto keys, I think many of the same elements apply. – RoraΖ Mar 30 '15 at 13:51
  • 1
    @raz It's actually a completely different problem domain. You don't want passwords to be discoverable given only the hash. Keys, on the other hand, *must* be available in original form for use by the system. – Xander Mar 30 '15 at 14:03
  • @Xander You're right, now I'm confused as to why key derivation would be brought up. – RoraΖ Mar 30 '15 at 14:38
  • @raz I brought up key derivation to use a from a password derived key to encrypt/decrypt the symmetric key on the client side so it does not need to be saved in plaintext. – MSc Mar 30 '15 at 15:07
  • SRP establishes *session keys*. Session keys are regenerated for each session; usually you don't store session keys anywhere except in RAM. You could of course store them in a secure container (token device such as a HSM or smart card) but usually it doesn't make sense to store it at a location more secure than the data (authentication state) it is trying to protect. – Maarten Bodewes Apr 08 '15 at 23:07

2 Answers2

1

Secret keys (symmetric or asymmetric) are typically stored in an encrypted medium of some sort such as a keystore or encrypted database. Specific example of a keystore would be the JKS (Java Key Store), and a database would be SQLCipher. This encrypted medium is secured with a master password, which is needed in order to read/write to it. SQLCipher will first churn the password through with PBKDF2 in order to ensure it has enough entropy and computational cost.

The question of where that master password is stored will of course affect the security of your system. For the client side, expecting the user to remember it is the best option. For the server side, a Hardware Security Module (HSM) may be used to secure the keys like Amazon's Key Management Service.

HTLee
  • 1,772
  • 15
  • 30
0

On the client side you could use PBKDF2 or a similar key derivation function to generate a key to then use to encrypt/decrypt the symmetric key before using it. Would this be considered (acceptably) safe?

This really depends on a few things:

1. What is the threat model?

Who are you trying to prevent from attacking you? A nation state? A jealous significant other? A script kiddie? Will this person have physical access to the client's device? Etc.

2. What are you using as an inputs to your KDF (PBKDF2 in your example)?

Hopefully the input to the KDF is something that is not persisted on the device (except for the salt and rounds, you can leave those hanging around) but rather something of sufficient entropy that the user is forced to enter once (e.g., a passphrase) and then is wiped from memory once it is no longer needed anymore.

3. How are you encrypting and storing the keys?

If trusted dedicated hardware is available (e.g., TPM or HSM [assuming you trust those]) then those will provide you with a way to store your symmetric keys (some store them on the dedicated hardware and some encrypt them with a key that is stored on the hardware but store the resulting ciphertext on your storage device). If no such hardware is available then you will usually store the keys in a keystore which is basically a file (or set of files) that stores the keys in an encrypted manner. There are several implementations already out there but if you are going to roll your own (which I do NOT recommend) then you need to consider how you will protect the confidentiality and integrity of your encrypted keys. Some things to consider are:

  • Will each key to be encrypted be wrapped with a different KEK?
  • How will you derive each KEK?
  • What algorithms/modes will you use?
  • What kind of performance do you need?

4. What do you do with the keys in memory when you don't need them anymore?

Every copy of each key should be wiped from memory once they are no longer needed. There are debates on how to do this that range from just writing a bunch of zeros over the bytes in memory to doing more fancy things that involve multiple passes that each write different bytes to the key's area in memory. What you do should depend on your threat model.

What possibilities are there on the server side? What procedure would be considered safe to store such a key in a database?

The server side has very similar options. Ideally the server would use an HSM and store the keys in there (see #3 above for more details) and your server side application would never have access to the raw key bytes (only the HSM would). In the database you would just store the key's alias (you could use the HSM to provide integrity on the binding between the database record and the alias).

How does for example Amazon store their symmetric keys used for their query string authentication for S3?

I am not sure what Amazon does specifically for query string authentication for S3 but I do know that they provide a Cloud HSM service.

Hmmmmm
  • 235
  • 2
  • 7