2
$\begingroup$

I am wondering if there is any reason to regularly update cryptographic keys, that are used for authentication purposes in a real-time system.

A key should be updated if it is weak, broken, compromised, or leaked. Another valid reason would be a weak authentication scheme. For instance, CBS-MAC is prone to message forgery in case messages of different length are authenticated using the same key. AES-GCM with the same IV is careless if the same key is used.

As Swashbuckler pointed out, block ciphers leak information and therefore, encryption keys should be updated. With regard to authentication, I do not see such a reason, because there is no confidential data and even if the adversary observed a collision, he could not learn the key (in most cases).

Key updates, hence, do not give any benefit from a pure security point of view if a strong cryptosystem is deployed. Do I oversee something?

$\endgroup$
0
$\begingroup$

The more frequently you update keys, the less data is processed with any given key, and therefore the less impact the leak will have. This goes regardless of the purpose of the key: confidentiality, authentication, or anything else. For data authentication, renewing the key limits the amount of tainted data, where it might be impossible to tell legitimate data from fake data. Only data authenticated by a compromised key is tainted: data authenticated by keys that the adversary hasn't obtained can still be trusted.

There is only a benefit if the the leak is rare enough that the adversary can't easily learn the next key. An example of partial leak is vulnerabilities like Heartbleed, which allow adversary to observe a limited amount of memory content: it only leaks the key if it happens to be stored in an address range that the adversary manages to access. Microarchitectural side channels of the Spectre and Meltdown families also sometimes have a limited range for the attacker, depending on the memory layout and on the available attack gadgets. A different class of attack that benefits from key renewal is when the attacker needs a physical compromise to obtain the key, for example by stealing a backup tape.

Another reason to update keys is that in some cases, there is a delay between the time when the key starts being used and the time when the attacker is able to obtain it. This is the case if the attacker steals a backup tape, for example. This is also the case if the attacker doesn't directly obtain the key, but some information that can yield the key after a subtantial, but doable amount of computation, such as a partial leakage of the state of a random generator, or a random generator seeded with non-negligible, but insufficient entropy.

Yet another reason to update keys is in case there is a limited side channel that only allows the attacker to obtain a small amount of information at a time, For example, if the attacker needs to spend an hour saturating the network bandwidth of a site to obtain each bit of a 256-bit key, and the key is renewed every week (168 hours), there's a chance that the attack will be detected before the attacker obtains enough bits to be useful due to the bandwidth saturation. If the key is only renewed once a year, the attacker can keep the bandwidth consumption lower and spend a few months obtaining the key.

For authentication keys, updating keys after you know they've been compromised is often not good enough. You might not find out about the compromise immediately, or at all. Not only that, but the verifier might never find out that the signing key has been compromised even if the signer knows. For example, TLS keys are used to authenticate websites. If a website has been compromised, how would clients know? In principle, through revocation — but distributing revocation information is hard. Renewing keys often at best makes the compromise window slightly longer than timely revocation, and has the considerable advantage that it actually works.

$\endgroup$
0
$\begingroup$

All block ciphers leak information. No matter the mode used there is a limit on the amount of data that should be encrypted with a single key, irrespective of the number of different IVs used, in order to not leak too much information that an attacker might be able to determine some of the encrypted data. For AES, it seems that the limit seems to be around 64 GB no matter the mode.

See the book Cryptography Engineering: Design Principles and Practical Applications and the paper The Missing Difference Problem, and its Applications to Counter Mode Encryption.

$\endgroup$
  • $\begingroup$ In other words: Regular key updates are necessary if block ciphers are deployed. What about data authentication in a real-time system? No encryption, maybe no block ciphers. As the data is public, a block cipher based authentication scheme may even leak data. This shouldn't be a problem as long as the key is not revealed. AES is limited to 64 GB for a single message if you use the same nonce, because then the counter would overflow. There is probably no need for a new key if you just replace the nonce. $\endgroup$ – null Mar 25 at 11:12
  • $\begingroup$ Using a new nonce doesn't fix the issue in any situation I've looked at. For CBC and OFB modes the issue is the birthday problem. For CTR and GCM modes it's a different issue (see the paper I referenced in my response), but there's still a per key limit. This is the reason that protocols like TLS and SSH rekey periodically. $\endgroup$ – Swashbuckler Mar 25 at 17:25

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.