5 ms·

Assuming for a moment that AWS's security at all matches the public API. There are two ways to grant access to a KMS key: as a policy grant on a user/role, and

Assuming for a moment that AWS's security at all matches the public API. There are two ways to grant access to a KMS key: as a policy grant on a user/role, and as a policy on the KMS key itself. If you don't have access to the key, then reading the S3 object doesn't work. So I have to trust that AWS's security here is that the S3 API itself can't unless granted that access.

theteapot 4y ago
> If you don't have access to the key, then reading the S3 object doesn't work. I'm still not convinced. Just seem like theater. S3 has its own access control. If you don't have access to the S3 object then reading the S3 object doesn't work ... Requiring additional access to the key seems redundant - theater. P.S. I'm not arguing against encryption at rest. I'll take it, but using my own key doesn't seem to offer too much over using one of AWS's rel low level access.
- colmmacc 4y ago
  AWS isn't monolithic internally and we use permissions boundaries between systems like S3 and KMS (in fact they are mediated by IAM). There's some more detail in my talk from re:Invent - https://www.youtube.com/watch?v=kNbNWxVQP4w https://www.youtube.com/watch?v=kNbNWxVQP4w . For a case like this, the upshot of it is that with permissions on the KMS key, S3 is effectively locked out and can't fetch it. KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference. It also means that controls can be handled by different customer teams, and that a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly.
  - theteapot 4y ago
    Useful. Thanks. > KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference. So, if I don't use a CMK (Customer Managed Key), what am I getting instead? Assumed (perhaps naively) KMS would still be used under the hood. > a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly. I feel like you could achieve that with an IAM policy. I guess the key can apply to a wide range of unrelated AWS services so act like a ~meta policy.
    - colmmacc 4y ago
      If you use the default AWS managed key rather than a CMK, it's largely the same levels of protection and the main difference is that you don't control the rotation schedule of the top-level key. And yep, a CMK can span many services and still give you a single point of control. But compliance is still the major thing. Many regulators, auditors and compliance authorities are just happier with KMS being the point of control. Even though AWS operates KMS, and the services, KMS is a neat compartmentalized hermetic system with HSMs at its root. So it's quicker and neater to evaluate its surface area, TCB, and so on and it's a familiar pattern to finance and health regulators especially.
    - aborsy 4y ago
      Default keys don’t allow policies if I recall. No access control.
      - paranoidrobot 4y ago
        You can't set a Key policy, but you control access via the IAM Policy associated with the caller.
- paranoidrobot 4y ago
  It's protection against mistakes where you've accidentally granted more access than was intended. For instance, if someone does a wildcard resource "acme-prod-widget-*" for a new policy, but forgets that widget also has (say) a customer-pii bucket, too. Well, if acme-prod-widget-customer-pii is encrypted with a customer-pii specific KMS key, then there's no accidental leak of that data.
davewritescode 4y ago
I understand that but I guess my question is other than another layer of access control to prevent mistakes, what am I actually getting. I know AWS has fixed this now, but in years past we paid a ton of money in KMS requests from s3 for these types of configurations and we asked ourselves what is this really buying us? At the end of the day I have to assume some AWS employees have access to some or all keys in KMS.
- colmmacc 4y ago
  No AWS employee has access to the keys directly from KMS. It's a hermetic system with no operator access like that. KMS Keys are released to AWS services for use based on IAM permissions and grants, and a time-bounded cryptographic pattern we call Forward Access Sessions ... where we end-to-end verify that the requesting service has a recent and legitimate signed request from the customer. KMS also has the capability to support an external trust store (https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-external-key-store/ https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-e...) ... where AWS holds no key material at all.
  - aborsy 4y ago
    It’s a bit like saying I don’t have access to keys in my Yubikey. Sure, but I can decrypt data with those keys. If I’m right, S3 sends encrypted data encryption keys to KMS, and KMS sends back the decrypted data encryption keys. So, although S3 has no access to the master key, it has access to the data keys in RAM for the customer to use. With a “bucket key,” it goes further storing those type of keys in disk.
    - colmmacc 4y ago
      It's more than what a Yubikey typically does. There are also can't-be-bypassed audit logs of the key usage, and the manner in which S3 is granted access to the data encryption key is very fine-grained; KMS won't allow the S3 systems to decrypt just anything. The key is stored in memory while it's being used to encrypt/decrypt, that's unavoidable, but humans don't have access to that. Bucket keys are a bit different, where there's a per-bucket key which has a similar scheme and then per-object keys are derived from it as needed. Together with random nonces/IVs, it ends up being a bit of a mini multi-party scheme.

theteapot 4y ago

> If you don't have access to the key, then reading the S3 object doesn't work. I'm still not convinced. Just seem like theater. S3 has its own access control. If you don't have access to the S3 object then reading the S3 object doesn't work ... Requiring additional access to the key seems redundant - theater. P.S. I'm not arguing against encryption at rest. I'll take it, but using my own key doesn't seem to offer too much over using one of AWS's rel low level access.

colmmacc 4y ago
AWS isn't monolithic internally and we use permissions boundaries between systems like S3 and KMS (in fact they are mediated by IAM). There's some more detail in my talk from re:Invent - https://www.youtube.com/watch?v=kNbNWxVQP4w https://www.youtube.com/watch?v=kNbNWxVQP4w . For a case like this, the upshot of it is that with permissions on the KMS key, S3 is effectively locked out and can't fetch it. KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference. It also means that controls can be handled by different customer teams, and that a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly.
- theteapot 4y ago
  Useful. Thanks. > KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference. So, if I don't use a CMK (Customer Managed Key), what am I getting instead? Assumed (perhaps naively) KMS would still be used under the hood. > a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly. I feel like you could achieve that with an IAM policy. I guess the key can apply to a wide range of unrelated AWS services so act like a ~meta policy.
  - colmmacc 4y ago
    If you use the default AWS managed key rather than a CMK, it's largely the same levels of protection and the main difference is that you don't control the rotation schedule of the top-level key. And yep, a CMK can span many services and still give you a single point of control. But compliance is still the major thing. Many regulators, auditors and compliance authorities are just happier with KMS being the point of control. Even though AWS operates KMS, and the services, KMS is a neat compartmentalized hermetic system with HSMs at its root. So it's quicker and neater to evaluate its surface area, TCB, and so on and it's a familiar pattern to finance and health regulators especially.
  - aborsy 4y ago
    Default keys don’t allow policies if I recall. No access control.
    - paranoidrobot 4y ago
      You can't set a Key policy, but you control access via the IAM Policy associated with the caller.
paranoidrobot 4y ago
It's protection against mistakes where you've accidentally granted more access than was intended. For instance, if someone does a wildcard resource "acme-prod-widget-*" for a new policy, but forgets that widget also has (say) a customer-pii bucket, too. Well, if acme-prod-widget-customer-pii is encrypted with a customer-pii specific KMS key, then there's no accidental leak of that data.

davewritescode 4y ago

I understand that but I guess my question is other than another layer of access control to prevent mistakes, what am I actually getting. I know AWS has fixed this now, but in years past we paid a ton of money in KMS requests from s3 for these types of configurations and we asked ourselves what is this really buying us? At the end of the day I have to assume some AWS employees have access to some or all keys in KMS.

colmmacc 4y ago
No AWS employee has access to the keys directly from KMS. It's a hermetic system with no operator access like that. KMS Keys are released to AWS services for use based on IAM permissions and grants, and a time-bounded cryptographic pattern we call Forward Access Sessions ... where we end-to-end verify that the requesting service has a recent and legitimate signed request from the customer. KMS also has the capability to support an external trust store (https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-external-key-store/ https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-e...) ... where AWS holds no key material at all.
- aborsy 4y ago
  It’s a bit like saying I don’t have access to keys in my Yubikey. Sure, but I can decrypt data with those keys. If I’m right, S3 sends encrypted data encryption keys to KMS, and KMS sends back the decrypted data encryption keys. So, although S3 has no access to the master key, it has access to the data keys in RAM for the customer to use. With a “bucket key,” it goes further storing those type of keys in disk.
  - colmmacc 4y ago
    It's more than what a Yubikey typically does. There are also can't-be-bypassed audit logs of the key usage, and the manner in which S3 is granted access to the data encryption key is very fine-grained; KMS won't allow the S3 systems to decrypt just anything. The key is stored in memory while it's being used to encrypt/decrypt, that's unavoidable, but humans don't have access to that. Bucket keys are a bit different, where there's a per-bucket key which has a similar scheme and then per-object keys are derived from it as needed. Together with random nonces/IVs, it ends up being a bit of a mini multi-party scheme.