I have a couple of Android devices which run my app. Every device has it's own unique serial number - a hex string 16 characters long.

The app needs files, which usually reside on external SD. These files should be usable only by a device which they are intended for. So I need to encrypt these files, with a unique key derived from the serial number.

Now the question: What is the best way to derive a encryption key from the serial number? I thought I could just reverse it and use it as input for some hash function. But this is quite obvious I think....

  • 2
    $\begingroup$ If the serial number is the only secret you can use, all hope is always lost if this number can be guessed / learned. $\endgroup$
    – SEJPM
    Jun 29 '17 at 15:25
  • $\begingroup$ Do you think that you want another secret like a password so that only a certain privileged user can access this files? $\endgroup$
    – Paul Uszak
    Jun 29 '17 at 15:34
  • $\begingroup$ To be more precise, the serial number isn't a secret, it is even displayed in the app. If a user wants to have new data, he has to tell me his serial, so I can prepare/encrypt a file for his device. I need to avoid, that the user share the files across devices, only the device which the file is intended to should able to decrypt the file. What I need is some hard to guess algorithm for generating secret keys from the serial number. $\endgroup$ Jun 29 '17 at 16:42
  • $\begingroup$ Depending on hard you want to make it for the user, you could derive a (weak) key from the serial number and strongly sign the plaintext (including the serial!) so that the application can check whether the data is for it, forcing the user to reverse-engineer the app (potentially illegal?) or the format to re-encrypt. $\endgroup$
    – SEJPM
    Jun 29 '17 at 17:24
  • 1
    $\begingroup$ I think you should specify against which threats you actually need the encryption to protect you from. This is not really clear to me at the moment. $\endgroup$
    – mat
    Jun 29 '17 at 23:18

The standard way to make a key out of some information (like your serial number), is to use a Key derivation function (KDF). If you do not consider a brute force attack to the serial number a realistic threat, then HKDF would be the suggested route to go, otherwise you should use a password based KDF like SCrypt which is much slower (which is a good thing against brute forcing).

I feel obliged to add, that using nothing but a serial number as a secret will not give you a secure encryption. While 16 bytes are basically enuogh to thwart attackers these days, it has to be assumed that the serial numbers are not really random but do follow some pattern, thus making them nuch more easily guessable. So while this scheme will be ok if you just want to prevent accidental misuse or passive attackers, it will most certainly not be good enough against an active attacker.

Update after your comments to the question above:

SCrypt won't help you in that scenario, so should use HKDF to derive a key for symmetric encryption (probably AES). Since you obviously never have an online connection to your app, using a random salt also won't be possible. The only additional secret you could use to strengthen the process would have to be hardcoded in your app, protected by some code obfuscation. All this will protect you from the casual file sharer who just copies the file to a different device, but not from anyone more active.

  • $\begingroup$ If the security of the key solely relies on the serial number then using a password based KDF would be an extremely good idea in my opinion. Using a random salt is in that case certainly also a good idea. $\endgroup$
    – Maarten Bodewes
    Jun 29 '17 at 16:47
  • $\begingroup$ @MaartenBodewes A random salt wouldn't be much use if you want it to be deterministic based on the device. $\endgroup$
    – Polynomial
    Jun 29 '17 at 16:54
  • $\begingroup$ The user was just asking to encrypt files based on the serial number. In that case a salt can be stored with the files. $\endgroup$
    – Maarten Bodewes
    Jun 29 '17 at 17:05
  • 2
    $\begingroup$ It might be useful to mention that a password hashing function being much slower is actually a good thing. $\endgroup$
    – Daffy
    Jun 29 '17 at 18:37

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.