Google Cloud - Key Management Service
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
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-Secretswill then be stored in Key-Vault database. 2.
DEKitself should also be encrypted, with another key, so-called
KEK(Key-Encryption-Key, which is generated by Google KMS or something else?). 3.
KEKwill then become another thing to be secured, which will be encrypted by
GKEKshould be the terminator at the end of the chain.
KEK-encrypted-DEKwill be stored into app (in our case, so-called Rules-Store).
GKEK-encrypted-KEKwill be stored into
JKS(Java KeyStore), and then app also encrypt or decrypt it by making
Google KMSapi call. The app calling KMS, should be secured by loading google
K8s Secretas well.
- Java KeyStore creation and storage in Google Storage or anywhere else(TBD)?
Terraform create Storage, and create JKS Kubernetes create Volume, and create JKS
- 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
- Generating AES-256 GCM symmetric key as
- Encryption-Key rotation
- Openssl generate AES key
- EclipseSource AES key
- Hybrid Symmetric and Asymmetric
- Java KeyStore api tutorial
- 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-bitkey size for RS256 (see Table 2 in the NIST recommendations, page 53). ES256 has a preset level of
128 bitsof 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—–.
|RSA_PEM||An RSA public key encoded in base64. Can be used to verify RS256 signatures in JWT tokens (RFC7518).|
|RSA_X509_PEM||An RSA_PEM key, encoded in base64, wrapped in an X.509v3 certificate (RFC 5280). The certificate can be be self-signed, otherwise Cloud IoT Core can optionally compare the device certificate signature against the registry-level certificates to verify the certificate’s origin.|
|ES256_PEM||The public key for the ECDSA algorithm (using P-256 and SHA-256), encoded in base64. Can be used to verify JWT tokens with the ES256 algorithm (RFC7518). This public key is not wrapped in a certificate; this keeps the key size small, which is one of ES256’s main advantages.|
|ES256_X509_PEM||An ES256_PEM key, encoded in base64, wrapped in a X.509v3 certificate (RFC 5280). The certificate can be self-signed, otherwise Cloud IoT Core can optionally compare the device certificate signature against the registry-level certificates to verify the certificate’s origin.|
- Key rotation
multiple active keys (up to 3 per device) to allow for uninterrupted rotation
digital signature-based authentication