2
$\begingroup$

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?

$\endgroup$
6
  • 7
    $\begingroup$ Why don't you get rid of the padding oracle? It is possible to implement CBC without such vulnerabilities. (Moreover, a padding oracle attack does not recover the key but the message, and it does this in an incremental way, so even a very short timeframe is likely sufficient to obtain at least a part of the plaintext.) $\endgroup$
    – yyyyyyy
    Commented Jan 7, 2016 at 3:07
  • 1
    $\begingroup$ add message authentication code to ciphertext, problem solved $\endgroup$ Commented Jan 7, 2016 at 3:13
  • $\begingroup$ @yyyyyyy How do I get rid of it? The connection is terminated and the key discarded as soon as decryption fails. $\endgroup$
    – Luke Park
    Commented Jan 7, 2016 at 3:56
  • 2
    $\begingroup$ @LukePark that sounds like an awesome way to perform a denial of service attack $\endgroup$ Commented Jan 7, 2016 at 10:53
  • $\begingroup$ @RichieFrame What specifically? I'm appreciative of the constructive criticism but at least a comment on how to approach solving it would be great. $\endgroup$
    – Luke Park
    Commented Jan 7, 2016 at 10:56

1 Answer 1

5
$\begingroup$

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.

$\endgroup$
2
  • 1
    $\begingroup$ Thank you for your thorough answer, much appreciated. I agree that using a HMAC seems like the best choice, however, you indicate that if padding is not checked and I simply proceed with the result and attempt to process it as usual, this could remove the padding oracle? Is my assumption correct? $\endgroup$
    – Luke Park
    Commented Jan 7, 2016 at 22:00
  • 1
    $\begingroup$ @lukepark as far as I understand, that is correct. There could still be some other side channel where that sort of information is leaked, but it would be very application specific and hard to know. $\endgroup$
    – mikeazo
    Commented Jan 8, 2016 at 0:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.