3 ms·

Well, it's still tough. The question is always "gained root to what", cause at some point somebody needs a key. Envelope encryption is a good scheme. Under env

Well, it's still tough. The question is always "gained root to what", cause at some point somebody needs a key. Envelope encryption is a good scheme. Under envelope encryption you have a master key and per-row or per-unit keys. You store the per-unit keys encrypted with the master key, and the master key is stored offsite. For example on an AWS environment, you would use AWS KMS with IAM authentication to handle the master key crypt for the individual keys, and the encrypted versions of the individual keys are stored in a database that you own. You encrypt your data with the individual keys (eg, one key per user, or one key per DB row, or one key per namespace, whatever), but the individual keys are decryptable only by KMS. Under this scheme an attacker must both be able to get ahold of the encrypted individual keys, and be able to decrypt them with the master key. Of course this leaves you very vulnerable if the master key is acquired, but KMS does not allow you to read the master key at all, you have to use the AWS API to make encryption/decryption requests. So the vulnerability is less about how secure the key is and more about how secure your IAM setup and instances are.

closeparen 8y ago
The application necessarily has access to the credentials it needs to do all of this. You're only eliminating the subset of attackers who can get in, but not figure out how to imitate your use of cryptography. Is the cryptography part even relevant? Since the attacker ultimately does have use of the key material, there's no information-theoretic security provided by the encryption, only some extra work to do. Wouldn't any other indirection/obfuscation accomplish the same goal? Or are we assuming that the decryption service enforces some policy about what and how much to decrypt?
- bkanber 8y ago
  Well, yes, if you're using AWS KMS you are able to set up policies, revoke access through IAM, use alerts and monitoring, and so on. But you're also forgetting that most data breaches in real life involve database backups, staging servers, development environments, and people with access. So envelope encryption really helps prevent those. Even if someone gets a hand on your DB dump they're unable to use it without authorization to the KMS, which they won't have unless they can also get into your application server.
  - closeparen 8y ago
    I guess I’m missing how credentials with access to KMS are any harder to come by than credentials with access to RDS, and why it’s easier to monitor KMS queries than RDS queries. Are the latter privileges more widely distributed, maybe? Where is it useful to have access to a database you can’t actually read? Do your dev/staging environments just no-op the decryption and put ciphertext strings everywhere prod shows plaintext?
    - bkanber 8y ago
      Maybe your DB creds are in a secure configuration system and maybe the KMS credentials are granted by an IAM instance role. If only certain users are able to get access to config (ie RDS), and only certain machines are able to decrypt data, you now have a multilayered security approach where an attacker needs to breach both a user and a piece of hardware. If you breach a user and get your hands on a DB leak, you can't use it because you don't have access to the hardware. If you breach the instance role then you can make decrypt requests, but you would have also needed to have breached the data separately and independently. Don't forget that data is most often leaked by people. DB backups, dev environments, inappropriate transfers. We hear about the big targeted attacks, but probably 90% of actual breaches are due to human misuse.

closeparen 8y ago

The application necessarily has access to the credentials it needs to do all of this. You're only eliminating the subset of attackers who can get in, but not figure out how to imitate your use of cryptography. Is the cryptography part even relevant? Since the attacker ultimately does have use of the key material, there's no information-theoretic security provided by the encryption, only some extra work to do. Wouldn't any other indirection/obfuscation accomplish the same goal? Or are we assuming that the decryption service enforces some policy about what and how much to decrypt?

bkanber 8y ago
Well, yes, if you're using AWS KMS you are able to set up policies, revoke access through IAM, use alerts and monitoring, and so on. But you're also forgetting that most data breaches in real life involve database backups, staging servers, development environments, and people with access. So envelope encryption really helps prevent those. Even if someone gets a hand on your DB dump they're unable to use it without authorization to the KMS, which they won't have unless they can also get into your application server.
- closeparen 8y ago
  I guess I’m missing how credentials with access to KMS are any harder to come by than credentials with access to RDS, and why it’s easier to monitor KMS queries than RDS queries. Are the latter privileges more widely distributed, maybe? Where is it useful to have access to a database you can’t actually read? Do your dev/staging environments just no-op the decryption and put ciphertext strings everywhere prod shows plaintext?
  - bkanber 8y ago
    Maybe your DB creds are in a secure configuration system and maybe the KMS credentials are granted by an IAM instance role. If only certain users are able to get access to config (ie RDS), and only certain machines are able to decrypt data, you now have a multilayered security approach where an attacker needs to breach both a user and a piece of hardware. If you breach a user and get your hands on a DB leak, you can't use it because you don't have access to the hardware. If you breach the instance role then you can make decrypt requests, but you would have also needed to have breached the data separately and independently. Don't forget that data is most often leaked by people. DB backups, dev environments, inappropriate transfers. We hear about the big targeted attacks, but probably 90% of actual breaches are due to human misuse.