3
$\begingroup$

I have a basic protocol which tries to authenticate messages going from client to server. Basically it is like this:

Imagine I want to send message M to server. Client computes a MAC over the message. The MAC is basically DES_ECB encryption of data MAC_DATA length of which is 8 bytes. MAC_DATA is obtained by XORING the plain message M between each other. Like this

  for (int i = 0; i < dwSize; i += DppGlobals.MAC_SIZE)
  {
        for (int j = 0; j < DppGlobals.MAC_SIZE; j++)
           MAC_DATA[j] ^= plaindata[i + j];
  }

And MAC is

  CALC_MAC = DppDES.EncryptDES_ECB(MAC_DATA, WorkKey);

Finally what client sends to server is:

Client -> Server: CALC_MAC, M

Assume keys are stored securely on client and server, and also they are shared. Now since DES is insecure I am trying to improve this protocol. My idea is basically the client will send to server AES encryption of the data it was sending before. So client sends to server

   Client -> Server:  C

Where C = AES_ENCRYPT_CBC(CAL_MAC | M, Key, someIV);

The server will decrypt the data it receives, and perform computations like it was doing before.

So is my modified version (with AES encryption) more secure than the old(current) protocol?

Since this protocol is already implemented, the change I want to add for improving its security should desirably be minimal - to avoid introducing new bugs. Also completely rewriting and using TLS is not an option.

$\endgroup$
1
$\begingroup$

The original is completely broken and would be regardless of the insecurity of DES.

The ECB encryption of a single block message (with a secure cipher) would be a secure MAC, but XORing the message blocks means that an attacker can modify any block of the message simply by making the same change to another block so that they cancel out.

The modified protocol is better, but not necessarily secure. For example, if the attacker can see two messages whose last blocks are "compatible" so that switching one for the other does not affect the aggregate XOR, the attacker can make that change knowing the MAC will match. I think this scheme effectively reduces to hash-then-encrypt (with an insecure hash, even), which is not secure. Even better attacks may exist.

You would be better off with an actual MAC algorithm. For example CMAC, if it must use a block cipher.

A minimal change would be to rip out all the current MAC code and replace it with just sending M, AES-CBC-MAC(len(M) || M), where len(M) is the length of the message as a 64-bit integer and || is concatenation. This would be secure authentication, but would of course not hide the message.

$\endgroup$
  • $\begingroup$ It would require lot of change in existing code to replace original MAC with CMAC. If I use strong AES encryption instead as in my example, how secure is that? $\endgroup$ – user29112 Nov 18 '15 at 13:20
  • $\begingroup$ @user200312, probably not very. The linked question shows some attacks, but even worse attacks could be possible here, because XOR is so simple to find collisions for. If you know messages to be of fixed length, you could use CBC-MAC, which ought to be even easier to integrate than your idea. $\endgroup$ – otus Nov 18 '15 at 13:23
  • $\begingroup$ @user200312, if lengths are fixed you can just replace the old CALC_MAC thing with CBC-MAC. If not, you could use one of the secure variants. $\endgroup$ – otus Nov 18 '15 at 13:25
  • $\begingroup$ Lengths are fixed you say, which length? length of current mac is 8 bytes $\endgroup$ – user29112 Nov 18 '15 at 13:25
  • $\begingroup$ @user200312, just use length-prepended CBC-MAC with AES, unless you need encryption to hide the messages. The encryption layer does not generally result in secure authentication if the MAC is not already secure. And yes, the XOR should go. $\endgroup$ – otus Nov 18 '15 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy