0

My application requires secure messaging between a server and client devices. The devices are not directly internet connected so it is not possible to use standard HTTPS or MQTT connections.

My preferred approach is to use asymmetric authenticated encryption such as libsodium's crypto_box API. The devices would encrypt and authenticate messages using their private keys and the server's public key. The server would do the same using its private key and the devices' public keys.

For this to be safe, I believe the server private key(s) need to be managed by a KMS. I am using Google Cloud Platform for the backend, and I do not see a way to have GCP KMS decrypt and authenticate messages encrypted by libsodium: GCP KMS doesn't seem to support libsodium's key algorithms, and it doesn't seem to support authenticated encryption.

I like libsodium because it is well-supported on my chosen embedded platform, and I like GCP KMS because I'm using GCP for the backend. It seems like the two are primarily designed to handle messages encrypted by themselves.

Is there a way for me to use libsodium on my devices, while maintaining the server private keys in GCP KMS? Or is another approach needed?

Mike Neufeld
  • 3
  • 2
  • Which language are you using at the server end? – Richard Heap Jul 16 '22 at 00:39
  • Node.js on Cloud Functions – Mike Neufeld Jul 16 '22 at 01:16
  • There's a libsodium for JS (not sure if it's compatible with CF), which will likely interoperate with the IOT end. Under the hood, libsodium's using X25519 for key exchange to derive the symmetric key, and exposes the asymmetric keys simply as byte arrays (you don't need to know what's in them). So, to store the server private key(s) securely, you could encrypt that using a master key in the KMS and store the result somewhere. This does mean that you are responsible for some things you might expect the KMS to do, like key rotation. – Richard Heap Jul 16 '22 at 15:14
  • Thanks for your response. This could work, though it's a step down in security from what I'd imagined KMS could do for me. I hoped KMS would be a sealed box where the private keys never leave, which would perform all decryption and authentication internally. Instead, if it is actually decrypting the server private key, the plaintext server key will still be ephemerally available to the CF and potentially capturable if someone malicious gains access to the CF. It seems like my "sealed-box" end-to-end panacea is not realistic, at least where libsodium is at one end and GCP KMS at the other. – Mike Neufeld Jul 16 '22 at 16:34

1 Answers1

0

Libsodium's crypto box uses X25519 to agree a key using one end's private key and the other's public key (and vice versa). It then uses the derived key and random nonce to encrypt the message to encrypt the message with a symmetrical, authenticated stream cipher (Salsa20). (This key exchange happens to give mutual authentication - both ends need their private key. It can be broken down into parts, so that the more expensive EC parts are performed once and the derived key re-used for several messages.)

As you've discovered ECDH isn't supported (though someone did open an feature request once).

Working backwards from what is supported by Cloud KMS with asymmetric keys it's just decryption (and signing). (Encryption is left to the client which can obtain the public key and it it itself.)

So, if the server private key is to remain safe in the KMS, all you can do is encrypt and decrypt small plain-/cipher-texts.

You can emulate many of the parts of crypto box with what you have available. To encrypt a message: generate a random key and IV, use an authenticated symmetric cipher (e.g. Salsa or AES-GCM), encrypt the random key in the receiver's public key and send the encrypted key, IV and ciphertext. As with crypto box, you could partition this by, say, sending the encrypted key once and reusing it for several messages (with a different IV each time, of course).

At the server end you need RSA encrypt (decrypt is done in KMS) and the symmetric cipher. At the client end you need RSA encrypt, decrypt and the same cipher. Libsodium has AES-GCM, so that seems a good choice.

But you are still missing RSA at the client. Looks for alternative C solutions for that (e.g. libtomcrypto or Oryx Embedded CycloneCRYPTO Open). You might find that whatever you need for RSA also happens to do the AES-GCM too.

Richard Heap
  • 48,344
  • 9
  • 130
  • 112
  • Thank you. The "emulating of crypto box" idea is a bit too close to "rolling my own crypto" for my liking. I am leaning towards simply using libsodium on the client and server, and storing the server private key in Google Cloud Secrets Manager. And implement a key revocation mechanism in case the key ever gets leaked. – Mike Neufeld Jul 20 '22 at 17:43