How it Works

Let’s talk in detail about how Cloak Labs secures a message. A typical message comes in two parts: metadata and payload. Metadata is assumed to be small while the payload can be large (MB or GB). Asymmetric encryption is more computationally expensive than symmetric encryption. However with symmetric encryption the sender and receiver must have a shared key. Cloak Labs solves this problem with maximum efficiency (i.e. minimum latency) by encrypting the payload using a symmetric algorithm (ex: AES256) and then encrypting the metadata and the symmetric key using RSA. The RSA algorithm uses the public key of the recipient which is tracked in the Cloak Labs cloud infrastructure and cached locally. There is no need for per session key negotiation such as what occurs with TLS/SSL. This allows a Security Gateway to encrypt a message while the destination Security Gateway is potentially offline.

The combination of the encrypted metadata, encrypted AES key, and the encrypted data (payload) is called an envelope. Finally the envelope is digitally signed using the private key of the sender. This allows the receiver to authenticate the message and to validate that nothing inside the message has been tampered with. The encryption process is shown in the figure below.


Cloak Labs Message Encryption Process

Once the message has been encrypted and signed, it is transmitted to the Cloak Labs cloud infrastructure as shown below:


Cloak Labs Encrypted Cloud Message Queue

The connection from the Security Gateway to the Cloak Labs is itself secured via TLS for an extra layer of security. The Cloak Labs cloud infrastructure also authenticates that the sender is a legitimate Security Gateway. For reliability, the sending Security Gateway transmits two copies of the message to two separate data centers in the cloud. This protects against any single data center failure.

Dual Pathing

Cloak Labs Security Gateways deliver 2 copies to two independent zones in the cloud for active-active redundancy.

The Cloak Labs cloud infrastructure queues the encrypted message until the destination Security Gateway downloads it. Since two copies are queued, the destination Security Gateway attempts to download both and then cancels the other copy once one copy has been successfully received. Messages remain in the cloud queue for a contracted time to live (TTL). This allows past messages to be recovered if need be. The TTL can be zero (delete as soon as successfully received) or as long as a year.

Decryption by the receiver is handled in the reverse manner.

  1. The digital signature is verified and the contents of the envelope checked for tampering.
  2. The metadata and AES key are decrypted using the receiving Security Gateway’s private key.
  3. The AES key is used to decrypt the payload.

At this point the receiving Security Gateway can pass the decrypted payload on to whatever application or ESB is desired.