1

I posted a comment awhile back, and thought I would turn it into a question.

Example: There is a feature in the Microsoft SQL Server for full database encryption, which seems to have an option that does not require a password on reboot. I understand you can use DPAPI or EKM, but I am still unsure to the actual limitations of such a system.

I actually am not interested in the Microsoft SQL Server feature specifically, only in the limitations of a theoretical encryption scheme.

Question: Given a server that requires the encryption key to be recreatable without requiring a user to input a secret, How much of a barrier can be placed against the attacker?

I am aware of the following

  • Complexity (the attacker may not know how to decrypt without looking at my program's code)
  • User Access barriers (the operating system may be able to store the information in such a way that the user accounts are unable to access without root)

Beyond that, I am lacking any concrete ideas:

If the attacker could read the disk, it seems you would have no protection. (unless maybe you used special encryption hardware)

Finally, for the key to be stored on a different computer, again, I don't see how (assuming Complexity & Security through Obscurity is overcome) you could prevent that different computer from providing the necessary key to the attacker that has access to the server who normally is permitted.

So, any guidance on a typical encryption scheme would be appreciated, and what the limitations would normally be.

Community
  • 1
700 Software
  • 13,807
  • 3
  • 52
  • 82

1 Answers1

2

The real questions here is: How much of a barrier can be placed against WHAT attacker? If the system doesn't need a password at boot, then if an attacker has physical access then it is trivial to bypass. That is quite literary not a security measure and an attack like the cold boot attack probably isn't required.

So what about MS-SQL? Well this encryption system is preventing a REMOTE ATTACKER possibly with a sql injection flaw access to the sensitive data. Keep in mind if the attacker has a flaw like SQL Injeciton, then the attacker SHOULD NOT have full access to the disk, unless of course you have a web app using an unrestricted account like sa, which would be a much bigger problem.

Moving just the key to another machine doesn't really help, if the compromised machine can access the key, then the attacker can access the key. What can help is creating a sensitive information store. So in this model a web application has two databases. One database for storage of not very sensitive information, and another database just for the storage of encrypted data. The encrypted database is made to be the most restrictive, it is only accessed by a white list of machines and the number of queries against this machine is kept to the bare minimum. The chances of a sql injection flaw against this database is much lower.

rook
  • 46,916
  • 10
  • 92
  • 181
  • 1
    Slightly off topic but regarding the cold boot attack, wouldn't the best mitigation be to have a lock on the case or RAM? – Celeritas Jul 24 '12 at 18:20
  • 1
    @Celeritas I enjoy picking locks... – rook Jul 24 '12 at 18:22
  • And the types of locks used on even high-end computer equipment are hardly high-security. – jimw Jul 25 '12 at 00:57
  • *"If the system doesn't need a password at boot, then if an attacker has physical access then it is trivial to bypass"* That is not what I meant. A password on boot would be required to initiate a full disk encryption that is not so trivial to bypass. – 700 Software Jul 26 '12 at 15:36
  • @George Bailey That would require a cold boot attack, which isn't trivial. – rook Jul 26 '12 at 20:00