Authentication token is encrypted but not signed - weakness?

Question

Over the years, I have come across this scenario several times. You have a bunch of user-related data that you want to send from one application to another. The second application is expected to “trust” this “token” and use the data in it. A timestamp is included in the token to prevent theft / reuse of the attack. For some reason (don't worry about it here), a proprietary solution was chosen rather than an industry standard such as SAML.

It seems to me that digital data signing is what you want here. If the data should be kept secret, you can also encrypt it.

But what I see a lot is that developers will use symmetric encryption, for example. AES. They suggest that, in addition to being “secret”, encryption also provides 1) message integrity and 2) trust (source authentication).

May I suspect that there is an internal weakness here? By default, this works if the symmetric key is managed properly. Without this key, of course, I don’t know how to change the encrypted token, or launch some kind of cryptographic attack after intercepting several tokens. But can a more sophisticated attacker use something here?

Answer 1

This partly depends on the encryption mode. If you use ECB (shame on you!), I can swap around by changing the message. Stackoverflow got into this same error .

Less threatening - without checking the integrity, I could make a man-in-the-middle attack and change all kinds of bits, and you will get it and try to decrypt it. Of course, you fail, but the attempt can be indicative. There are side attacks by Bernstein (using a combination of cache and microarchitectural characteristics), as well as Osvik, Shamir and Tromner (using cache collisions), based on a large number of random tests. " 1 Article with a note was written by a cryptographer of a larger note than me, and he recommends reducing the attack surface of the MAC:

if you can make sure that an attacker who does not have access to your MAC address can never feed a block of code, however, you will drastically reduce the likelihood that he will be able to use any errors

Answer 2

Yeah. Only encryption does not provide authentication. If you want authentication, you must use a message authentication code such as HMAC or digital signatures (depending on your requirements).

There are a fairly large number of attacks that are possible if the messages are simply encrypted but not authenticated. Here is just a very simple example. Suppose messages are encrypted using CBC . This mode uses IV to randomize the ciphertext, so encrypting the same message twice does not result in the same ciphertext. Now look at what happens during decryption if the attacker simply modifies IV but leaves the rest of the encrypted text as it is. Only the first block of the decrypted message is modified. In addition, it is these bits that have changed in changing the IV message. Consequently, the attacker knows exactly what will change when the receiver decrypts the message. If this first block was, for example, the timestamp that the attacker knows when the original message was sent, then he can easily set the timestamp at any other time simply by flipping the correct bits.

You can also manipulate other message blocks, although this is a bit more complicated. Note also that this is not just a CBC weakness. Other modes, such as OFB, CFB, have similar disadvantages. Therefore, expecting that only this encryption provides authentication is just a very dangerous assumption.

Answer 3

A symmetric encryption approach is as secure as a key. If both systems can receive the key and hold the key securely, this is normal. Public-key cryptography is certainly more natural.