Re-sending captured encrypted data

Question

Let’s assume Bob is some algorithmic stock trading machine. Bob takes commands from Alice, who sends messages to Bob.

For example: Alice could be sending a message to Bob to stop trading. But if Mallory is able to capture cipher and figure out the effect of sending that cipher to Bob, Mallory could send the captured cipher to Bob and make him stop trading at arbitrary times.

How do cryptographic systems handle such situations?

One way I could think of is to append the current epoch time to message before encrypting it. Then Bob can choose to discard the message if the time shown in the decrypted cypher is far off in the past. But this is not foolproof. What actually is done in real life?

Answer 1

How do cryptographic systems handle such situations? … What actually is done in real life?

In real life, cryptography handles situations like the one you describe by using “authentication”. Authentication links an action, a message or a situation to an identity. In the example you describe, this will practically boil down to a validation of something an entity knows… like a password, a key, or another kind of secret.

Simplified, you could think of authentication as something which enables you to validate if an entity is actually who they claim to be, or allowed to do something, by showing they know a secret that only they could know. (Note that “authentication” does not always mean an entity proves its individual identity; it can also be used to prove an entity is part of a group of entities knowing a certain secret.)

For better understanding of what “authentication” is, it may be helpful to know there are also other forms (better: factors) of “authentication”. Chances are, you’ve already have met such “authentication” in real life yourself, since “authentication” can be proven by something an entity has – like a passport, a smartcard, a token device, or something similar.

Besides that, “authentication” can be proven by an entity by something an entity is. For example: humans have specific, individual features. These can also be used for “authentication”… which makes up one of the areas biometrics covers. If you‘ve ever had your fingerprint or iris scanned, or if you ever saw that in a movie… well, that’s what we call “authentication” in the realms of cryptography.

As said, in your example Bob and Alice will use a shared secret to enable mutual authentication. Not knowing the secret, Mallory will not be able to successfully authenticate her messages as Bob will detect the missing or wrong authentication factor (the secret) and reject and/or ignore Mallory’s messages/attacks accordingly.

Of course, authentication alone won’t make a protocol secure. Besides authentication things like secure connections (using encryption, etc.) are needed to wrap a secure shield around things. But authentication is an important part of cryptography, as it allows (for example) to learn if the entity you are communicating with is indeed the entity you expect to be communicating with… and not some kind of adversary who tries to inject or even replace messages which you might think are secure. They may be secure due to encryption, but without authentication that’s not worth all too much. Yet, the combination of both make up a pretty solid way of exchanging information between two entities.

Answer 2

You are describing a replay attack.

The most simple method to prevent this is to include a message counter as part of the message, and reject any message with a counter equal to or less than the last message. The message counter should be large enough so that key changes would occur before the counter loops. A 32-bit message counter allows 100 messages per second for about 497 days.

This alone may not be sufficient. Mallory could intercept and block all messages, and if it is known what the message probably is at a given time, could retransmit that specific message when it is at her benefit. An example is the "stop trading" message that occurs at exactly 4pm. It could be delayed until after Mallory has benefited from the extra trading activity in some way.

That attack can be mitigated by the use of a TTL (time to live), telling how long a message is valid after its transmit time, along with mandatory acknowledgment of message receipt, and accurate time sync. Depending on the use case, this may present its own problems in the form of denial-of-service. The acknowledgment allows Alice to determine if Bob got the message within the expected timeframe, and if Bob accepted or rejected the message, and the reason for rejection.

A message counter, time code, TTL, or other piece of information sent with the message that is critical to the security of the system but not encrypted must be authenticated. The encrypted data of course must also be authenticated. In practice this is done by choosing an AEAD cipher or mode, or adding a supplementary integrity check such as HMAC. If the cipher requires a nonce, the message counter and time code could be a component of the nonce, and thus implicitly authenticated. Care needs to be taken to keep accurate count and time to prevent possible reuse.