3
$\begingroup$

I am making an embedded system for a project that uses AES.

As I cannot accommodate key generation (hardware constraints) I am using a static key. I can use another small algorithm to create dynamism and then pass it to the static AES.

I'm concerned about using a static key, is it safe?

$\endgroup$
  • $\begingroup$ You should write more about your small algorithm; what is the randomness source. and also, are there any hash algorithm around. $\endgroup$ – kelalaka Jan 4 at 9:24
  • $\begingroup$ Have you looked on LED cipher? It is AES-like , they use one key with round constants. It might help you $\endgroup$ – hardyrama Jan 4 at 9:40
  • $\begingroup$ if you don’t use AES, you’ll have a lot more transistors for better security options. a feistel network cipher will serve you well $\endgroup$ – b degnan Jan 4 at 13:11
  • $\begingroup$ Have a look into whitebox crypto: github.com/ph4r05/Whitebox-crypto-AES $\endgroup$ – patrickf Jan 6 at 20:31
7
$\begingroup$

AES - the block cipher - can be used to process a large amount of data. In that sense it is possible to keep a single static key. How much data is specified in this answer by Thomas on the Security.SE site: around $2^{64}$ blocks of data or 250 millions of terabytes.

Generally would want to keep to $2^{32}$ blocks of random data though ("only" 64 GiB of data) to make sure that the chance of collision remains low. How much you can actually encrypt depends in the end on the mode of operation used. For CTR mode you can for instance encrypt 64 GiB with a random 96 bit nonce $2^{32}$ times with a ~ $1 \over 2^{64}$ chance of collision as the input of the block cipher isn't random.

If the use of AES with a static key is secure therefore depends not on the block cipher but how the block cipher is used: in other words, the protocol or protocols in which it is used. It may be insecure because the mode of operation introduces constraints that are voided by your protocol. It may not be secure because replay attacks are possible, oracles exist, the combination of cipher mode and MAC mode are vulnerable to attack, the list goes on...

AES does certainly leak information if the same input block is fed into it twice. If that's an issue depends - again - on the protocol. Your small algorithm could possibly be used to generate nonces so that the input to the AES cipher is always unique.


That using such a scheme can be relatively secure is shown by memory cards such as DESFire (which, funny enough, may also use AES). These cards are generally provided with one or more symmetric keys that are static during the lifetime of the product. Of course all the devices use derived keys that are tied to some unique identity of the card, otherwise extraction of one key would be enough to destroy the functionality of all of the cards.

Still, if the master key (from which the device keys are derived) is lost from which the other keys have been derived such schemes are certain to run into some form of trouble or another. It is very tricky to perform key management on static keys, and such schemes are fraught with danger. This is why asymmetric keys are commonly used with a PKI scheme to ensure validity. For such schemes the controlling device doesn't need to hold a master key.

Sometimes devices are also provided with multiple keys (for multiple master keys) in advance. That way the device may still be used with a new master key if one becomes compromised. Needless to say, invalidating a master key on the devices and moving to the next one is tricky at best (if you can detect compromise in the first place), but you could possibly provide key rollover for your protocol.


Needless to say, using a static key makes it very vulnerable against side channel attacks on the implementation. Compare this for instance with a secure channel which needs to be reestablished using fresh session keys any time the MAC authentication tag is invalid. Those keys are probably invalidated before you can find out anything interesting about them.

$\endgroup$
  • $\begingroup$ Comments about the maximum number of calls to the AES block cipher have been moved to chat. $\endgroup$ – Maarten Bodewes Jan 7 at 17:38
0
$\begingroup$
  1. You can fix a public key to AES and use it as a random permutation. Now based on a random permutation, you can construct an ideal cipher out of it (you might need more than one call to the random permutation). There might be efficiency loss, but it works and no AES-key scheduling is needed.

  2. Note that AES key scheduling is very similar to one round of AES encryption. See https://eprint.iacr.org/2015/751.pdf page 10.

$\endgroup$
  • $\begingroup$ Could you possibly explain a bit more about your solutions? As it stands, your ideas are not that clear, at least not to me. What do you mean with "fix" a public key to AES? Could you create a more formal description? Are you suggesting replacing the key schedule of AES? With what? How does it make it more efficient compared to deriving a key, for instance? $\endgroup$ – Maarten Bodewes Jan 7 at 17:43

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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