Status Update
No update yet.
Comments
ms...@gmail.com
ch...@google.com
Hello,
Thanks for reaching out to us!
This request is acknowledged and we will validate it further. Though we can't provide an ETA on the requests nor guarantee their implementation, rest assured that your feedback is always taken very seriously, as it allows us to improve our products. Meanwhile, could you please let us know the Business Impact of not having this feature available right now.
Thank you for your trust and continued support to improve Google Cloud Platform products. In case you want to report a new issue, please do not hesitate to create a new
gu...@relaycorp.tech
Glad to see this issue progressing. As for business impact in our case:
We're close to launching Awala[1], an end-to-end encrypted network that will circumvent complete Internet blackouts, in order to help some of the most vulnerable people in the world. Our adversaries have deep pockets, so encryption at rest and in transit isn't enough -- we need those encryption keys to be in a HSM.
As an E2EE network, if two people are communicating with each other, their keys obviously never leave their Android/Windows/macOS/etc devices. However, in many cases, the peer at the other end can be an Internet host (on GCP, for example), so that host would have to manage its own encryption keys.
Description
We're implementing an end-to-end encryption protocol where one of the "ends" can be server-side apps hosted on GCP. The protocol currently supports NIST curves (P-256, P-384 and P-521), which we're planning to deprecate in favour of X25519 (with X448 support optional).
Unfortunately, Cloud KMS doesn't currently support any (EC)DH algorithm, so as a workaround we're having to use envelope encryption with a Cloud KMS-backed symmetric key and the wrapped key stored in Datastore, which means we wouldn't comply with FIPS 140-2 Level 3 because the app would have direct access to the ECDH private key and resulting shared key.
Lack of FIPS compliance isn't an issue in itself at the moment but our threat model does make it desirable to have such keys (or a subset of them) in a HSM. Some of our adversaries will be nation-state actors.
In case it's relevant, we're using a protocol based on Signal's, where ECDH keys are rotated as new messages are exchanged, so it'd be even better if this were supported out of the box. Note that, in our case, we need to keep the latest N keys because messages will often arrive out of order.