7
$\begingroup$

I need to encrypt/decrypt data from my software by AES, the problem is how to make the AES key secure, there is no HSM, should I hard code the key in my code? It seems that a hacker can read the key data by reverse engineering the software.

$\endgroup$
  • 4
    $\begingroup$ What is your threat model? Do you write DRM which acts against the user's desires? Or do you write software that's a faithful agent of the user? $\endgroup$ – CodesInChaos Oct 9 '15 at 9:11
  • $\begingroup$ Hi CodesInChaos,my software is running in set top box and need to save encrypted data to flash. $\endgroup$ – Gerry Oct 9 '15 at 9:22
  • $\begingroup$ Do you need the device to be able to encrypt the data, decrypt the data or both. In the last case there is really no "secure" way to do it without someone being able to extract the key. $\endgroup$ – otus Oct 9 '15 at 9:49
  • $\begingroup$ Hi otus, I need both encrypt and decrypt $\endgroup$ – Gerry Oct 9 '15 at 10:26
  • 4
    $\begingroup$ @Gerry, and who should the data be kept secret from? $\endgroup$ – otus Oct 9 '15 at 11:25
8
$\begingroup$

If your software needs to decrypt the data and you want to prevent even those with physical access from decrypting without your software, you are basically out of luck. It is impossible to achieve purely in software, since even if a good white-box algorithm existed, an attacker could copy it into their software and be able to decrypt (without directly knowing the key, but who cares).

However, if you are willing to ignore those attacks and only protect the data against those who do not have access to the exact device and its software, you should use device specific keys, not hardcoded ones. That way even if an attacker would extract the key from their device, they would not be able to use that to attack other devices.

$\endgroup$
  • $\begingroup$ Hi Otus, would you pls explian a little bit about device specific key? is it some kind of alg which generate key based on device specific infomation(KDF)? $\endgroup$ – Gerry Oct 11 '15 at 7:52
  • 1
    $\begingroup$ @Gerry, I merely meant generating one key for every device. If you can "hardcode" it in the software separately for each device, that would be one way. Another would be to generate the key randomly on first boot (if the device has enough randomness). Deriving it from device specific information would be the least reliable way, if that information cannot necessarily be kept secret, but might be enough depending on your situation. $\endgroup$ – otus Oct 11 '15 at 11:57
  • $\begingroup$ This is good advice, but you should still be careful. If someone publishes a program that can extract the key in an easy way you are again in trouble. $\endgroup$ – Matty Oct 11 '15 at 17:15
7
$\begingroup$

What you are looking for is called white-box cryptography.

In short white-box crypto aims to make an implementation of a cypher (for example AES) in such a way that it is impossible for an attacker to extract the key, even if the attacker (the user of the computer) has access to the source code and a debugger.

Up till now all academic white-box implementations have been broken, so it's not really possible to do this, but at least it has become significantly harder for the attacker to do so.

For more information on white box crypto, visit the site of Brecht Wyseur: http://www.whiteboxcrypto.com/, or read the article by James Muir: https://scholar.google.nl/scholar?q=A%20Tutorial%20on%20White-box%20AES (for the technical details of the white-box aes implementation).

Edit: I read in your comment that you need both encrypt and decrypt. If you need to encrypt and decrypt with the same key, this will never be secure in the white-box context, because rather then to try and get the key, the attacker can just feed it's (encrypted) input in the decryptor and he has all he ever needs (and vice-versa). So you will need to have two keys (and thus two whiteboxes) in this case.

$\endgroup$
  • 1
    $\begingroup$ How will two whiteboxes help, if the device is meant to decrypt the data it encrypts? $\endgroup$ – otus Oct 9 '15 at 16:01
  • 2
    $\begingroup$ @otus: not. You need to make sure it can't decrypt it's own encrypted data or vice versa. You can decrypt data from a server and encrypt data from a server, but they need to be en/de-crypted with a different key. Otherwise it's never going to be secure. A white-box can only encrypt or decrypt (with a built-in key). Never both. $\endgroup$ – Matty Oct 9 '15 at 17:31
  • $\begingroup$ To send data encrypted back to a server, I'd use public key crypto. To decrypt data from the server on a non trusted machine, one can use white-box crypto. Or use some sort of secure smart card. $\endgroup$ – Matty Oct 9 '15 at 17:39
  • $\begingroup$ Hi Matty ,thanks for your reply, I will check the link later $\endgroup$ – Gerry Oct 10 '15 at 12:40
  • $\begingroup$ If they are just talking about machine communication, you can easily use SSL, if they are talking about encrypted files, the question becomes what are you trying to protect? If they are trying to prevent others from reading it, there is no known way, if any software can decrypt the file, then that code can be copied to decrypt the file fully. If the point is to make a file that no one can create, then they can use simple PKE. The system admin can protect it further by running as a different user where those users do not have access to the memory of that running process. $\endgroup$ – Rahly Oct 11 '15 at 6:41
0
$\begingroup$

You cannot hide the algorithm, because the algorithm is the code - if your code has to be able to decode the data, then you are giving your attacker machine readable code.

The key has to be accessible, directly or indirectly, to the code.

And finally, if you decrypt the data, then an attacker can listen to the output of your decryption code, which means that no amount of obfustication or hiding will help you.

The only way to stop an attacker decrypting your data, is to make it so the code can't decrypt it without help - for example, by a trusted operator putting a key or partial key in at runtime, or if some of the data is controlled by a trusted (hardware) module. Of course, if the trusted hardware module then hands the data back to the operating system, then you're no better off.

$\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.