8 ms·

Attacks on Encrypted Databases [pdf]

106 points by blacksmythe 9y ago

marvel_boy 9y ago
Is SqliteCipher (sqlite) also vulnerable to the techniques shown on paper?
- developernotes 9y ago
  This paper highlights various possible attack vectors. SQLCipher would still be vulnerable to scenarios such as an active attacker on device/machine where the key is resident in RAM. If you are interested in the design features of SQLCipher, I would recommend reading this: https://www.zetetic.net/sqlcipher/design/ https://www.zetetic.net/sqlcipher/design/
  - problems 9y ago
    > would still be vulnerable to scenarios such as an active attacker on device/machine where the key is resident in RAM Doesn't this go without saying? Seems kind of ridiculous to try to protect against that attack vector at least on today's hardware.
    - swordswinger12 9y ago
      To protect against an attacker with physical access to a machine may indeed be futile, but it should be possible to provide some measure of security against a malicious process running on the machine. Defending sensitive data if the DB process itself is compromised, again, seems pretty difficult. That was the original goal of the academic proposals like CryptDB or Cipherbase - defense even against a fully malicious database server.
thruflo22 9y ago
Any good recommendations for running Postgres transparently as a fully encrypted database (not just on a table by table basis)? Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem?
- zAy0LfpBZLC8mAC 9y ago
  > Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem? Which problem?
- virmundi 9y ago
  I'm with zAy0LfpBZLC8mAC, what question are you attempting to answer? If you want to secure the database at runtime, your best answer is to have it locked down at the ports and the access ids. If you want to protect it at rest, yes, an encrypted drive would prevent someone from stealing the drive and reading the data. It won't help against anything else. This might help as a primer for this type of question: https://security.stackexchange.com/questions/16939/is-it-generally-a-bad-idea-to-encrypt-database-fields https://security.stackexchange.com/questions/16939/is-it-gen... Edit: grammar.
- cvwright 9y ago
  > Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem? Yes and no. They discuss this on page 2. > An oft-cited threat to DB security is disk theft, i.e., theft of persistent storage [2,16,20,32,37,42,47,50]. Full-disk encryption (FDE) can mitigate this threat, but EDBs aim to protect data even in the absence of FDE. Without FDE, this attack yields the persistent OS and DB state, but not any volatile state. Even with FDE, an attacker who can do some sort of software exploitation can still grab all the data they need out of the filesystem. It's worth reading the whole paper if you're interested in the topic. It's only 6.5 pages of content, and it's written in a way that makes the technical stuff pretty accessible to a general CS audience. > Any good recommendations for running Postgres transparently as a fully encrypted database (not just on a table by table basis)? Hard to tell what you're asking here. You can't just encrypt all the data inside Postgres, or it won't be able to perform queries anymore. You can read the CryptDB paper cited here to learn about the trade-offs that some encrypted databases have made in order to re-enable queries on encrypted data. In a nutshell, they use much weaker encryption that reveals a lot more information about the contents of the DB. Then read up on the attacks also cited here to see why that's generally a bad idea. (Full disclosure: I'm an author of one of the attack papers.)
falcolas 9y ago
A few years back, Google worked through their attempts at encrypt MySQL from end to end; it's a damned hard problem when you consider all the bits which would need to be encrypted to protect against someone with access to the OS or hypervisor. I haven't heard that they were successful.
- swordswinger12 9y ago
  Whoa, really? Is this analysis available publicly somewhere? It would be really useful for further research on this topic.
  - falcolas 9y ago
    I found the talk slides, but no followup https://www.percona.com/live/mysql-conference-2015/sites/default/files/slides/Encrypting%20MySQL%20data%20at%20Google.pdf https://www.percona.com/live/mysql-conference-2015/sites/def...
- deathanatos 9y ago
  > protect against someone with access to the OS or hypervisor. > I haven't heard that they were successful. Isn't it rather trivial to prove that a database can't be secure if the OS or hypervisor is compromised? (I mean, how could it be, since the OS/hypervisor can read/write all memory, pause execution, alter execution, etc. by its very nature?)
  - swordswinger12 9y ago
    The original goal of the academic "encrypted database" proposals like CryptDB was security against this kind of adversary. The idea was that if all the data is encrypted even when you're querying it, you get some security against a compromised OS. Unfortunately, in this paper we showed even this "always encrypted" approach has many subtle flaws that leave the data vulnerable to inference attacks.
    - Ar-Curunir 9y ago
benologist 9y ago
Are there caveats for encrypting Redis databases at rest? The main attack vector I'm trying to thwart is becoming a pastebin dump.
- swordswinger12 9y ago
  If your threat model is having a hard disk stolen, simply using full-disk encryption or whatever Redis offers is probably fine. Fair warning, though: this is a really weak threat model and won't do anything to protect the data against any stronger attacks.
- closeparen 9y ago
  A pastebin dump isn't an attack vector, it's what an attacker might do with the loot after compromising you. Or are you referring to one of your personal passwords ending up on Pastebin? Use unique passwords, set up SSH keys, and set "PasswordAuthentication no" in your SSHD config.

106 points by blacksmythe 9y ago

marvel_boy 9y ago

Is SqliteCipher (sqlite) also vulnerable to the techniques shown on paper?

developernotes 9y ago
This paper highlights various possible attack vectors. SQLCipher would still be vulnerable to scenarios such as an active attacker on device/machine where the key is resident in RAM. If you are interested in the design features of SQLCipher, I would recommend reading this: https://www.zetetic.net/sqlcipher/design/ https://www.zetetic.net/sqlcipher/design/
- problems 9y ago
  > would still be vulnerable to scenarios such as an active attacker on device/machine where the key is resident in RAM Doesn't this go without saying? Seems kind of ridiculous to try to protect against that attack vector at least on today's hardware.
  - swordswinger12 9y ago
    To protect against an attacker with physical access to a machine may indeed be futile, but it should be possible to provide some measure of security against a malicious process running on the machine. Defending sensitive data if the DB process itself is compromised, again, seems pretty difficult. That was the original goal of the academic proposals like CryptDB or Cipherbase - defense even against a fully malicious database server.

thruflo22 9y ago

Any good recommendations for running Postgres transparently as a fully encrypted database (not just on a table by table basis)? Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem?

zAy0LfpBZLC8mAC 9y ago
> Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem? Which problem?
virmundi 9y ago
I'm with zAy0LfpBZLC8mAC, what question are you attempting to answer? If you want to secure the database at runtime, your best answer is to have it locked down at the ports and the access ids. If you want to protect it at rest, yes, an encrypted drive would prevent someone from stealing the drive and reading the data. It won't help against anything else. This might help as a primer for this type of question: https://security.stackexchange.com/questions/16939/is-it-generally-a-bad-idea-to-encrypt-database-fields https://security.stackexchange.com/questions/16939/is-it-gen... Edit: grammar.
cvwright 9y ago
> Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem? Yes and no. They discuss this on page 2. > An oft-cited threat to DB security is disk theft, i.e., theft of persistent storage [2,16,20,32,37,42,47,50]. Full-disk encryption (FDE) can mitigate this threat, but EDBs aim to protect data even in the absence of FDE. Without FDE, this attack yields the persistent OS and DB state, but not any volatile state. Even with FDE, an attacker who can do some sort of software exploitation can still grab all the data they need out of the filesystem. It's worth reading the whole paper if you're interested in the topic. It's only 6.5 pages of content, and it's written in a way that makes the technical stuff pretty accessible to a general CS audience. > Any good recommendations for running Postgres transparently as a fully encrypted database (not just on a table by table basis)? Hard to tell what you're asking here. You can't just encrypt all the data inside Postgres, or it won't be able to perform queries anymore. You can read the CryptDB paper cited here to learn about the trade-offs that some encrypted databases have made in order to re-enable queries on encrypted data. In a nutshell, they use much weaker encryption that reveals a lot more information about the contents of the DB. Then read up on the attacks also cited here to see why that's generally a bad idea. (Full disclosure: I'm an author of one of the attack papers.)

falcolas 9y ago

A few years back, Google worked through their attempts at encrypt MySQL from end to end; it's a damned hard problem when you consider all the bits which would need to be encrypted to protect against someone with access to the OS or hypervisor. I haven't heard that they were successful.

swordswinger12 9y ago
Whoa, really? Is this analysis available publicly somewhere? It would be really useful for further research on this topic.
- falcolas 9y ago
  I found the talk slides, but no followup https://www.percona.com/live/mysql-conference-2015/sites/default/files/slides/Encrypting%20MySQL%20data%20at%20Google.pdf https://www.percona.com/live/mysql-conference-2015/sites/def...
deathanatos 9y ago
> protect against someone with access to the OS or hypervisor. > I haven't heard that they were successful. Isn't it rather trivial to prove that a database can't be secure if the OS or hypervisor is compromised? (I mean, how could it be, since the OS/hypervisor can read/write all memory, pause execution, alter execution, etc. by its very nature?)
- swordswinger12 9y ago
  The original goal of the academic "encrypted database" proposals like CryptDB was security against this kind of adversary. The idea was that if all the data is encrypted even when you're querying it, you get some security against a compromised OS. Unfortunately, in this paper we showed even this "always encrypted" approach has many subtle flaws that leave the data vulnerable to inference attacks.
  - Ar-Curunir 9y ago

benologist 9y ago

Are there caveats for encrypting Redis databases at rest? The main attack vector I'm trying to thwart is becoming a pastebin dump.

swordswinger12 9y ago
If your threat model is having a hard disk stolen, simply using full-disk encryption or whatever Redis offers is probably fine. Fair warning, though: this is a really weak threat model and won't do anything to protect the data against any stronger attacks.
closeparen 9y ago
A pastebin dump isn't an attack vector, it's what an attacker might do with the loot after compromising you. Or are you referring to one of your personal passwords ending up on Pastebin? Use unique passwords, set up SSH keys, and set "PasswordAuthentication no" in your SSHD config.