Question

We have a micro service called “Key Vault”, which stores keys and secrets sensitive data. The data is encrypted by AES-256 keys, and we need a way to secure these keys. We should not entry an infinite loop of encryption mechanism. Therefore, we thought it would be trusted by leveraging a Cloud services, like Google KMS.

So, we need simply making KMS api call to create a key and use it to encrypt our AES keys. Every time (some times after expiry), we can decrypt the AES keys by retrieving the KMS key runtime.

KMS GettingStarted guide Getting Started

• Where to store DEK-encrypted-Secrets, KEK-encrypted-DEK, GKEK-encrypted-KEK?

  This guy need to be decrypted within Key-Vault. 1.Key-Vault generates DEK (Data-Encryption-Key, an AES-256 symmetric key), and uses it to encrypt “secret data” which becomes DEK-encrypted-Secrets will then be stored in Key-Vault database. 2.DEK itself should also be encrypted, with another key, so-called KEK(Key-Encryption-Key, which is generated by Google KMS or something else?). 3.KEK will then become another thing to be secured, which will be encrypted by GKEK(Google-Key-Encryption-Key) So GKEK should be the terminator at the end of the chain.

KEK-encrypted-DEK will be stored into app (in our case, so-called Rules-Store). GKEK-encrypted-KEK will be stored into JKS(Java KeyStore), and then app also encrypt or decrypt it by making Google KMS api call. The app calling KMS, should be secured by loading google Credential from K8s Secret as well.

STEPS

1. Java KeyStore creation and storage in Google Storage or anywhere else(TBD)?

   Terraform create Storage, and create JKS Kubernetes create Volume, and create JKS

2. Key-Management service to
   • Generating AES-256 GCM symmetric key as KEK, using Java api. (Easy to rotate, and manage)
   • Store these in Cloud storage or Volume. or 1’. Rules-Store new Database table, to

https://www.baeldung.com/java-keystore

References:

• Encryption-Key rotation
• Openssl generate AES key
• EclipseSource AES key
• Hybrid Symmetric and Asymmetric
• Java KeyStore api tutorial

Security Standards

Keys

USA Key management recommendation

• RSA sign algorithm, based onJWA RS256 - RFC7518sec3.3

  The RSA algorithm is commonly used and is widely supported by client libraries. However, the generated keys and signatures can be quite large (generally on the order of one to two kilobytes). Additionally, RSA can use a significant amount of resources (both in terms of key length and CPU), which can affect devices that have limited resources.

• Elliptic Curve sign algorithm, based on JWA ES256 - RFC7518sec3.4

  The Elliptic Curve algorithm is well supported but is not as widely used as RSA. To use Elliptic Curve, you may have to install additional dependencies in your client library. However, the generated keys and signatures are significantly smaller than those generated by RSA, which can be useful for devices with limited resources.

• Key strength

  A minimum of 112 bits of security is required by Cloud IoT Core, following NIST recommendations (Section 5.6.2, pages 55-56). This translates to a minimum 2048-bit key size for RS256 (see Table 2 in the NIST recommendations, page 53). ES256 has a preset level of 128 bits of security (the key size is fixed).

• Public Key format

  Note: The RSA_PEM and ES256_PEM keys begin with —–BEGIN PUBLIC KEY—– and end with —–END PUBLIC KEY—–. The RSA_X509_PEM and ES256_X509_PEM keys begin with —–BEGIN CERTIFICATE—– and end with —–END CERTIFICATE—–.

• Key rotation

  multiple active keys (up to 3 per device) to allow for uninterrupted rotation

digital signature-based authentication

• JWT/JSON Web Token