- attacks on a running app that has the keys loaded, naturally
The threat model has to include at least:
- passive attacks against the DB itself, lacking access to the keys
The threat model really should also include:
- active attacks against the DB lacking access to the keys (e.g., replace blocks)
IMO ZFS does a pretty good job against these threats, for example, so ZFS is a good yardstick for measuring things like TFA.
However, the fact that a running system must have access to the keys means that at-rest data encryption does not buy one much protection against server compromise, especially when the system must be running much/most/all of the time. So you really also want to do the utmost to secure the server/application.
ZFS, AFAIK, can offer something in addition which is harder for a VFS to offer, and which AFAICT no other SQLite encryption offers: a kind of HMAC Merkel tree that authenticates an entire database (at a point in time).
Alternatives, even those that use MACs only authenticate pages/blocks. They still allow mix-and-match of pages/blocks from previous backups.
I could, potentially, add optional/configurable nounces and MACs at the VFS layer.
I've refrained from doing so because (1) it complicates the implementation; (2) it can be added later, compatibly; (3) it doesn't fix mix-and-match; (4) it will impact performance further; and (5) it would be MAC-then-encrypt (against best practice).
Yes, that's right. In fact, ZFS w/ encryption gives you two Merkle hash trees, one using a hash function and using a MAC. SQLite3 could do this, but it would have to change its database format fairly radically.
A SQLite3 VFS could, maybe, store additional metadata on the side knowing the SQLite3 database file format, I suppose. But if you really want this it's best to do it in the database itself.
> ... the fact that a running system must have access to the keys means that at-rest data encryption does not buy one much protection against server compromise, especially when the system must be running much/most/all of the time.
A common approach to help mitigate this is by having the keys be fetchable (eg via ssh) from a remote server.
Preferably hosted in another jurisdiction (country) in a data centre owned by a different organisation (ie. not both in AWS).
When the encrypted server gets grabbed, the staff should (!) notice the problem and remove its ssh keys from the ssh server holding the ZFS encryption keys.
---
That being said, I'm not an encryption guy whereas some of the people in this thread clearly are. So that's just my best understanding. ;)
> When the encrypted server gets grabbed, the staff should (!)
If the people doing the grabbing are LEO then they have ways of taking running servers such that they keep running or otherwise don't lose what's in RAM. And if it's LEO then "the staff" should absolutely not do things that can be construed as destroying evidence.
> ways of taking running servers such that they keep running
That's an interesting point. Wonder how complete that approach is, and if it maintains network connectivity between the servers they're grabbing?
Some clustering solutions automatically reboot a server if it loses network connectivity for a short period of time (ie 1 min). That would really mess up the "preserve stuff in ram" thing, if it's purely just designed to keep a server running.
There's at least two ways. One is to keep the servers powered even after they are unplugged from wall power (they have special adaptors for portable PSUs). The other is to cryogenically cool the RAM then cut the power, keep the RAM cooled, and then read it later in a lab.
Sure, if its LEO. That's not the threat model for most organisations encrypting their data at rest though. :)
---
> should absolutely not do things that can be construed as destroying evidence.
It'd be a very long stretch to successfully argue "removing access to the key" is destroying evidence. The data would still be intact, and available, to anyone with the key.
Just not to whoever physically grabbed the server. ;)
Of course. And I'm just pointing out a commonly implemented approach.
LEO isn't generally the consideration of places encrypting their stuff. Businesses dealing with sensitive data (PII, etc) are required to as a matter of course.
- attacks on a running app that has the keys loaded, naturally
The threat model has to include at least:
- passive attacks against the DB itself, lacking access to the keys
The threat model really should also include:
- active attacks against the DB lacking access to the keys (e.g., replace blocks)
IMO ZFS does a pretty good job against these threats, for example, so ZFS is a good yardstick for measuring things like TFA.
However, the fact that a running system must have access to the keys means that at-rest data encryption does not buy one much protection against server compromise, especially when the system must be running much/most/all of the time. So you really also want to do the utmost to secure the server/application.