Encryption for messages on disk?

[thefellow...@gmail.com]

Hello user group!

We have some sensitive data in messages being published on RabbitMQ. Clients and broker communicate over TLS, which is a first step in securing the data. Next issue is persistence. I’m a bit uncertain if the “message store” (as described here: https://www.rabbitmq.com/persistence-conf.html) encrypts messages that are stored on disk. From what I’ve read here messages are encoded in a internal, custom file format. It also seems like it is not possible to replace the persistence mechanism (https://stackoverflow.com/questions/37102978/is-there-any-strong-support-for-sql-database-to-persist-rabbitmq-message).

I guess that it is possible for someone with knowledge in RabbitMQ message store should be able to decode messages stored on disk and thus get access to the information in the message.

Am I right to assume this?

BR
Pär

[Michael Klishin]

RabbitMQ does not encrypt data at rest. Use a filesystem that offers encryption.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Maayan Hanin]

This isn't really a RabbitMQ issue, it is a general security issue.

Lets say RabbitMQ has built-in encryption mechanism for the persistence layer. Where would the encryption key reside?

If it is placed on the disk, then anyone with access to the disk would be able to decrypt the messages - simply by reading the decryption key, just like RabbitMQ does.

If the key is stored at a remote server, and RabbitMQ retrieves the key by presenting that remote server with credentials stored on the disk, then anyone with access to the disk would be able to retrieve the decryption key the same way RabbitMQ does...

Michael's solution works only when the secret is stored outside the disk. For instance, a mechanism which requires the user to enter a password which is used to derive the decryption key.

Another way to go about this would be to implement end-to-end encryption (as opposed to the point-to-point encryption you are getting using TLS), which means the message body itself is encrypted such that only the intended recipient (consumer) can decrypt it. This way, a compromised middleware won't give away your secrets.

- Maayan

[Domenico Rotondi]

Hi,

we have solved this issue using CP-ABE encryption techniques.

CP-ABE is an asymmetric encryption technique where each user has a personal key that is provided by a Key Generation Service.

In CP-ABE you encrypt data using a set of public attributes (which can be considered as the Key Generation Service public key) and an access policy that specifies the characteristics a personal key has to have in order to succeed in decrypting the data.

Therefore you don't need to share keys or know in advance who has to access the data. You publish data encrypted according to a specific access policy; only subscribers that have a key meeting the access policy requirements will be able to decrypt the data.

What we actually did is to create a Java library for use by publishers and subscribers able to encrypt/decrypt the data. Actually, in order not to slow down the events' flow, we combined CP-ABE and AES. We generate an ephemeral AES key which is encrypted using the CP-ABE techniques and an access policy; the publisher then encrypts the data using the much faster AES mechanism adding metadata including an id of the AES key encrypted via CP-ABE.

A subscriber needs to first acquire the CP-ABE encrypted AES key, decode it to acquire the AES key (and this operation succeeds only if the subscriber personal key complies with the access policy) and then decrypt the data.

To support publishers with limited processing capabilities, the encryption via CP-ABE of AES keys is performed by an proxy service.

We have a couple of papers describing the whole mechanism.

BTW our SW is open source (Apache license).

Ciao

   Domenico

---

On 30 Aug 2017 at 16:57, Maayan Hanin wrote:

This isn't really a RabbitMQ issue, it is a general security issue.

Lets say RabbitMQ has built-in encryption mechanism for the persistence layer. Where would the encryption key reside?

If it is placed on the disk, then anyone with access to the disk would be able to decrypt the messages - simply by reading the decryption key, just like RabbitMQ does.

If the key is stored at a remote server, and RabbitMQ retrieves the key by presenting that remote server with credentials stored on the disk, then anyone with access to the disk would be able to retrieve the decryption key the same way RabbitMQ does...

Michael's solution works only when the secret is stored outside the disk. For instance, a mechanism which requires the user to enter a password which is used to derive the decryption key.

Another way to go about this would be to implement end-to-end encryption (as opposed to the point-to-point encryption you are getting using TLS), which means the message body itself is encrypted such that only the intended recipient (consumer) can decrypt it. This way, a compromised middleware won't give away your secrets.

- Maayan

On Friday, August 25, 2017 at 11:45:38 AM UTC+3, thefellow...@gmail.com wrote:

Hello user group!

We have some sensitive data in messages being published on RabbitMQ. Clients and broker communicate over TLS, which is a first step in securing the data. Next issue is persistence. I’m a bit uncertain if the “message store” (as described here: https://www.rabbitmq.com/persistence-conf.html ) encrypts messages that are stored on disk. From what I’ve read here messages are encoded in a internal, custom file format. It also seems like it is not possible to replace the persistence mechanism ( https://stackoverflow.com/questions/37102978/is-there-any-strong-support-for-sql-database-to-persist-rabbitmq-message ).

I guess that it is possible for someone with knowledge in RabbitMQ message store should be able to decode messages stored on disk and thus get access to the information in the message.

Am I right to assume this?

BR
Pär

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[V Z]

The encryption key would go into TPM, which is non-removable.