I wrote this post to learn more about encryption when I saw a discussion post from my big brother, a big shout out to Chi Tran. You can read more about him on his blog: https://ctrsec.io/

Scenarios: For example, in a case where I have a private key needed to sign JWTs to communicate with an out-of-bound/3rd party service. The API of this service supports key rotation regularly.

The question is: Where should this private key be stored on the Cloud to be safe? What are the trade-offs? There is no right or wrong, only suitable and safe or not.

When talking about encryption and we approach from a Security Architecture Design

1) We have to determine the type of assets 💰:

For JWT Private Key: we have two main options on AWS

• AWS KMS with Asymmetric Keys: Used in cases where maximum security is not required and accepting that AWS has partial management rights over the key.

• AWS KMS with Custom Key Store (CloudHSM): Used when needing to comply with encryption standards like FIPS 140-2 Level 3 but still wanting to use the convenience of KMS for key management.

• AWS CloudHSM (Stand-alone): Used when you need full physical and logical control over the key, not wanting to share access with any third party, including AWS

2) Security & Compliance Requirements 🪪:

Determine the security requirements and compliance with JWT authentication/authorization flow

• Compliance: If the JWT is used in an environment that complies with strict security regulations like PCI DSS, HIPAA, or GDPR, then choosing CloudHSM or KMS with Customer Key Store would be more appropriate.

• Security: Determine essential security methods for JWT private key, which include the ability to protect the key physically, key rotation, and control the use of the key

3) Ownership & Access Management 🏠:

Determine the parties with read access to the key

• AWS as a third-party: Although AWS provides KMS, within this scenario, you have to consider AWS as a third-party that has access to the key during the management process.

3.1 There is no specific requirement for read permission for third parties:

KMS with Assymmetric Keys: this is a good option for basic security, allowing the use of RSA or ECC key pairs managed by KMS

Requirement to meet strict encryption standards like FIPS 140-2:

KMS with Custom Key Store (CloudHSM): This is a suitable choice when needing to comply with high security standards but still wanting to leverage the convenience of KMS.

3.2 Read Permission won’t be allowed to third parties for all scenarios:

AWS CloudHSM (Stand-alone): This is the only option if you want to make sure that you are the only person who has access to the key and manage the entire lifecycle of the key without depending on AWS.

4) Requirements of managing key lifecycle and levels of encryption:

• Retention Period: Are there specific requirements for timeframes that the default setting of KMS cannot support?

• Cryptographic Suite: Is there a requirement to use encryption types not supported by KMS, not only for security reasons but also for compatibility with legacy systems?

Summary:

1. AWS CloudHSM

2. AWS KMS

3. AWS Secrets Manager

Choosing which one depends on whether you want to trade off between security/compliance and the convenience of management, using integration with AWS services.

• In terms of security and compliance: CloudHSM > KMS > Secrets Manager

• In terms of convenience, usage, integration: Secrets Manager > KMS > CloudHSM

  (basically, KMS uses CloudHSM, so it can be scoped down to KMS and Secret Manager)

Private keys are often generated by a 3rd party, and you have to import key material yourself.

Pros and Cons 🔐:

Each method has pros and cons depending on the implementation:

Secret Manager:

If using Secret Manager, you will need a restrictive Lambda to read the key, sign JWT, and handle key rotation.

• Pros ✅: SecretManager does support Lambda invocation, so we don’t need to worry about that.

• Cons ❌: Due to security reasons, we still have access to the private key even when we don’t need that. Can’t avoid human access.

KMS:

If using KMS, we can use KMS as a customer-managed key, along with a Lambda for KMS to sign JWT content + key rotation in KMS.

• Pros ✅: After loading the private key into KMS, we no longer have access to it. It is only used for signing.

• Cons ❌: KMS doesn’t manage the rotation process, meaning we have to use an event trigger for Lambda.

With this implementation, KMS > SM in terms of Security.