2

I'm using 4096-bit RSA to encrypt a 256-bit AES key generated client-side. The RSA ciphertext is then sent to the server, and the server decrypts the RSA ciphertext to acquire the AES key. Information is then exchanged between the server and client using the AES key in CBC mode.

I generate a unique IV using a secure RNG for each message and send it with the AES ciphertext.

I am aware of three weaknesses to this system so far:

  • An attacker gains access to a client system and manages to adjust the RSA public key. As far as I am concerned, if an attacker has access to a client system, I have bigger problems to deal with anyway.
  • Anyone can communicate with my server provided they have my RSA public key. Again, not too worried about this, as a password is required to be sent to the server before it will perform any operations on behalf of the client. If a password is leaked, once more, I have bigger problems to deal with.
  • A Padding Oracle attack due to my use of CBC Cipher Mode, so:

The exchange of keys and commands between client and server will last, at most, around 1 minute. Normally this time period is far less. Since the AES key that is used exists for such a short period of time, and given that it is not stored anywhere other than in memory, is it possible for a padding oracle attack to crack the key?

Luke Park
  • 582
  • 5
  • 15

1 Answers1

5

A Padding Oracle attack due to my use of CBC Cipher Mode

CBC in and of itself does not directly result in a padding oracle. It is when you abuse the padding after decryption to decide whether or not decryption was successful and then communicate (maybe not even directly) the results of that padding check.

Based on your comment that

The connection is terminated and the key discarded as soon as decryption fails.

it sounds like you are likely using a padding check to determine whether or not decryption has failed. If that is incorrect let me know.

Should you be worried about this?

Definitely. The fact that your keys are short lived perhaps makes it so that the current incarnation of your software is not exploitable (I'm not convinced that it isn't exploitable), but it is vulnerable at the very least. What happens when you are no longer available (say left the company this code is written for or stop working on the open source project this code is written for) and someone else changes the keying requirements. They may very easily change them in such a way that the software is now exploitable since the vulnerability has persisted.

In our world, it is much better to just fix the problem and not let it turn into something that can be exploited down the road.

How can you fix it?

The best approach is to use message authentication codes. I suggest you read Should we MAC then encrypt or encrypt then MAC. Basically, you can either switch to an authenticated encryption mode (look at your crypto library to see what is supported) or add a MAC after encrypting with CBC using HMAC. Please read Why can't I use the same key for encryption and MAC? while you are at it.

mikeazo
  • 39,117
  • 9
  • 118
  • 183