I’m pondering what the benefits of encryption at rest at the database level would be for a Canton participant from a security perspective.
Let’s assume an attacker gains root access to the machine the participant runs on. Would they also need to obtain the PostgreSQL user credentials before they could see the plaintext data stored by the participant? Or does root access imply they’ll be able to compromise the database content as well?
If I now use database encryption on the Postgres instance, would that essentially mean that an attacker would need to compromise yet another secret (that’s stored off-machine / off-line) before they can access the data?
I’d appreciate any insights into the possible threat models in terms of compromising data privacy, but also participant take over (ie. ability to impersonate / act / sign as), which I understand is controlled by the root participant key.
There are a few different scenarios we should look at from a security point of view:
Assuming the Canton participant and the database run on two different machines, and the attacker has root access to the Canton participant machine. In that case the attacker could extract the database credentials from the participant node’s configuration file or extract it from the memory of the process (if it’s not provided via a configuration file). Using those credentials the attacker can read all the participant’s data from the database as an authenticated and authorized user.
Now let’s take a look on the database machine. In general encryption of data-at-rest protects against an offline attacker, for example someone having access to a hard disk. The encryption can happen at different layers, for example, on the block device, file system, or application level (i.e., the database).
Assuming we have an online attacker, who has root access on the database machine. Let’s compare block device encryption vs database encryption in that scenario. If the database machine is up and running, i.e., an encrypted block device is decrypted and mounted or the database with encryption enabled is up and running, then technically the data is compromised in both cases. The attacker can inspect the database files stored on the encrypted block device (which is currently decrypted and mounted) or extract the encryption key from the database memory. Although the barrier is higher for an attacker in case of application level encryption, as the attacker has to extract the key from the memory of the application and not just access a set of files.
There are of course nuanced attack scenarios, where an attacker does not have full root level access to the machine, but say can only read files with root-level permissions but not an application’s memory. Or one runs a database inside an enclave that mitigates memory-level access to the database, including the encryption key that is stored in memory.
I hope this gives you some insights on the different attacker scenarios.
Agree with everything Soren says. Encryption at rest is mainly protecting against attacks against the storage when system not live. It does not protect against attacks against the system when the application is live so you are still dependent on the application to properly authenticate and authorise the user.
Nearest analogy is full disk encryption on your laptop. An attacker will have difficulty getting to the drive contents if you’ve locked your screen or the device is powered down. However if you leave you screen unlocked and open (think of applications sitting on top of an encrypted disk with no proper access management, or an encrypted drive mounted onto a machine and unlocked) then an attacker can walk up to your machine and access all the data.
Some databases offer attribute or row level encryption, where the client holds the encryption keys. In this case the database, the server and the application never see the data in unencrypted form. Some regulations push towards this level of encryption but the operational cost of managing and running the system is significantly higher.