Question

Difficulty: Very hardAWS KMS and Encryption

A developer is implementing local client-side envelope encryption for sensitive reports in a microservice before uploading them to Amazon S3. To optimize costs and network overhead, the developer aims to generate a unique data key for each report using a customer managed key in AWS KMS. However, during integration testing, the developer observes that each file encryption requires two sequential AWS KMS API calls, which is causing latency and doubling API billing. The current implementation performs `kmsClient.generateDataKeyWithoutPlaintext(...)` followed by `kmsClient.decrypt(...)`. Which modification to the code should the developer make to reduce the integration to a single AWS KMS API call per report?

  1. A
    Replace the `generateDataKeyWithoutPlaintext` call with `encrypt` using the customer managed key to directly encrypt the report payload, and use the `decrypt` call to decrypt it upon retrieval.
  2. B
    Store a pre-generated plaintext data key in AWS Systems Manager Parameter Store as a SecureString parameter, retrieve it with a single call, and use the KMS `decrypt` API only to verify its integrity.
  3. Replace the `generateDataKeyWithoutPlaintext` call with `generateDataKey` to obtain both the plaintext data key and the ciphertext data key in a single response, and remove the subsequent `decrypt` call.Answer
  4. D
    Change the second call to `reEncrypt` to convert the ciphertext data key into a format readable by the local encryption utility, bypassing the need for a plaintext key.

Answer

Replace the `generateDataKeyWithoutPlaintext` call with `generateDataKey` to obtain both the plaintext data key and the ciphertext data key in a single response, and remove the subsequent `decrypt` call.
The correct solution is to change the API call to `generateDataKey`. Under envelope encryption, the client requires the plaintext data key to encrypt the payload locally, and the ciphertext data key to store alongside the encrypted payload. The `generateDataKey` operation returns both in a single response, removing the need for a separate, subsequent call to the `decrypt` API to extract the plaintext key.

Step-by-Step Solution

1
Analyze the purpose of the current KMS API calls.
The application calls `generateDataKeyWithoutPlaintext` which only returns the encrypted (ciphertext) data key. Because it lacks the plaintext key to encrypt the payload, it must make a second call using the `decrypt` API.
Understanding the current behavior helps identify where the redundant call originates.
2
Select the appropriate KMS API operation for client-side envelope encryption.
Identify that the `generateDataKey` API operation returns both the plaintext data key and the ciphertext data key in a single payload.
This operation satisfies the requirements of envelope encryption by providing the plaintext key immediately for local encryption while providing the ciphertext key for storage.
3
Refactor the code to eliminate the secondary call.
Replace the initial call with `generateDataKey`, use the returned plaintext key to encrypt the file locally, discard the plaintext key from memory after use, and save the ciphertext key to Amazon S3 alongside the encrypted report.
This reduces the integration to a single KMS API request, minimizing latency and API costs by 50%50\%.

Key Concept

AWS KMS Envelope Encryption Workflow Optimization
Rate this question