1
$\begingroup$

I read something about the padding oracle attack when analysing the use of an AES-encryption of data in a database and was "scared" it could be a serious issue. But after investigating a bit further, I now came to the conclusion that in our specific scenario it should be no matter at all. I would like to validate this, because I have the feeling to not fully understand the attack method.

I have got the following scenario:

Clients send plain text messages to an application server (Java). This messages shall be stored in a database, but not as plain text; they have to be encrypted (synchronous encryption with a static encryption key). We use AES-128/CBC/PKCS5Padding, while the encryption is done by the application server, which is the only instance that knows the encryption key. This means, the server does not offer an external interface, which could be used to send (modified) encrypted data packages. So there should be no chance for an end user / external hacker to do an padding oracle attack. Or, in other words, there is no instance / server acting as "oracle".

The only attack scenario would be an internal attempt to hack the encryption, let's say a person who has access to the database (e.g. a database administrator with a criminal attitude) and by that to the encrypted messages. But due to the fact the application server does not offer any interface and the attacker does not have access to the encryption key, he should have no opportunity to make an padding oracle attack (?).

Also, an attacker would not discover the encryption key by being successful with an padding oracle attack, he only would decrypt specific messages. So even if the database administrator with access to the database and with an account for the application would change the encrypted data directly in the database to check if decryption still works (the data is displayed in the client / web site = no padding exception), he only could decrypt his own data by doing that, which actually wouldn't be of any use for him.

My question: Do I understand this right or do I miss anything important?

Improve this question
$\endgroup$
3
  • $\begingroup$ Can I just move it to Information Security while keeping the answers and comments? $\endgroup$
    – brainsheep
    Commented Apr 22, 2015 at 14:38
  • 2
    $\begingroup$ BTW: I found a good explanation of the Padding Oracle Attack: grymoire.wordpress.com/2014/12/05/… $\endgroup$
    – brainsheep
    Commented Apr 22, 2015 at 14:39
  • $\begingroup$ How is "the data" "displayed in the client / web site" when there is no attack? $\hspace{1.7 in}$ $\endgroup$
    – user991
    Commented Apr 28, 2015 at 3:57

2 Answers 2

Reset to default
2
$\begingroup$

As far as I can tell, you just have encrypted data in a DB and are worrying that it can be hacked. In short, encryption works so you're good.

In more detail, your analysis of a padding oracle attack is correct. As you don't have any services or APIs or network protocols that partake in the encryption, a padding oracle attack can't occur.

Understanding that I don't fully understand your architecture, I can tell you about the attacks I'd worry about:

  1. There are potential client-side attacks. Perhaps via OS or browser malware. Not your app's fault but can still lead to an exposure of your data.
  2. If you have a malicious admin, they could attack your application directly. They could potentially modify your class files to extract your data while it's in motion. Worse, they can call your decryption functions to bulk decrypt the DB.
  3. Examination of your app's memory to look for secure data or the encryption key.
  4. Examination of your app's configuration to get your decryption key.
  5. An application vulnerability that allows a remote attacker to extract data from your app or cause it to perform malicious actions. This may be the biggest threat as it allows for remote attacks.

I'm sure there's more but that's my quick evaluation. I think that the breaking the DB encryption is far down the list of things to worry about. Secure your key (preferably in a password-sealed keystore) and secure your app against a remote attack.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thank you very much for the fast answer! That already helped me a lot and confirmed my understanding that I do not have to action to prevent this kind of attack in the given scenario. $\endgroup$
    – brainsheep
    Commented Apr 22, 2015 at 14:37
  • $\begingroup$ I very strongly disagree with your PS. I'm a newbie at encryption, and I just implemented a padding oracle attack. Also please note that you can accidentally provide an oracle. You need to be quite sure that nothing you are doing is even implicitly providing an oracle. $\endgroup$
    – Matthew Talbert
    Commented Apr 23, 2015 at 20:32
  • $\begingroup$ Alright. It was meant as half a joke. I removed the PS altogether. Thanks for the feedback @MatthewTalbert. $\endgroup$
    – Neil Smithline
    Commented Apr 23, 2015 at 20:37
1
$\begingroup$

Padding oracle attacks are targeting servers, where the padding oracle attack is performed to attack the encrypted connection between client and server. You use encryption only internally, without an external interface, so yes you are right: There is no interface, where an external attacker could perform this attack.

However, your entire setup is flawed terribly by this: "Clients send plain text messages to an application server (Java)". This means basically, that encryption of user data on the server side is useless, because the attacker already knows it from listening to the connection.

Your assumption about the database administrator are probably wrong, though it is hard to say without further knowledge. But in general, an administrator has access to the stored keys as well: If he wants to read the data stored on the server, he can. Not having an interface is no impediment for the clever criminal administrator (unlike the external attacker), who can just do memory dumps of the whole server.

Improve this answer
$\endgroup$

Your Answer

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