MSMQ. Keep message body encrypted while it is stored on drive

Question

My project require to keep all data encrypted, so MSMQ needs to be encrypted too. But as it is known from the article (https://msdn.microsoft.com/en-us/library/ms704178(v=vs.85).aspx ) messages from private queues are stored by default in …\MSMQ\Storage\p000000x.mq file.

When I configure a private queue, set its privacy level to "Body", and when I send encrypted message to this queue, then I open the …\MSMQ\Storage\p000000x.mq file in text viewer (I use Far Manager hex redactor), I see plain text of message. It is not encrypted. To send message I use next code:

message.UseEncryption = true;
message.EncryptionAlgorithm = EncryptionAlgorithm.Rc2;

The message …\MSMQ\Storage\p000000x.mq stays plain, despite message encryption specified. See the picture below.

So my question: Is there some built-in tool to keep message encrypted on drive in …\MSMQ\Storage\p000000x.mq file? Or I need to encrypt message body before sending to queue, and then, when peek from the queue, I need to decrypt it?

Thanks a lot!

Answer 1

Yes, you will need to encrypt the data BEFORE putting it into a message and then decrypt the data AFTER reading the message.

"Using Application Encryption on the Data" http://blogs.msdn.com/b/johnbreakwell/archive/2008/09/12/sending-encrypted-msmq-messages.aspx

Answer 2

Because Microsoft Windows supports folder encryption for multiple users† through NTFS Encrypting File System (EFS), I was able to leverage this transparent encryption mechanism to support encryption of the MSMQ storage folder and therefore minimise the surface area of user access to data inside files that comprise message bodies and fragments of otherwise readable text in the *.mq files.

This solution is one alternative I devised for private queues (with no domain integration) to be transparently encrypted and without resorting to Application-Encrypted Messages or to custom encryption by the application. It actually affects all queues on the system because the entire storage location for the MSMQ instance is encrypted.

This solution continues to allow use of the MSMQ snap-in to view messages in queues for users who have been assigned permissions to do so, without them seeing garbled or encrypted text in the viewer.

Note that this solution asks you to make a new storage location on disk for the MSMQ because I had issues when trying to encrypt and convert the default storage location which is under Windows/System32. If you find a way to make this solution work without creating a new folder please post in the comments.

These are the steps I take to make EFS technology work for a transparently encrypted MSMQ solution:
(This information assumes you know where to find your Message Queue Manager to configure the service with, and how to carry out some other basic Windows admin tasks or to find out how to do so)

1. Log into the machine as an administrator (assuming the Message Queuing service is already installed, if not then install it from Windows Programs and Features).

2. Take note of the user account the Message Queuing service is running under (i.e. Network Service). You will need this in a following step...

3. Create an alternate storage folder on disk for msmq e.g. C:\msmq-storage

4. Assign your administrator user to the new folder with Full Control permission.

5. Assign the service user account (noted in Step 2 e.g. Network Service) Full Control permission to the folder also.
   (This is a very important step because it gives the MSMQ service user account access to the encrypted contents of the message files.)

6. Encrypt the folder by going to its properties and enabling the Encrypt checkbox. The folder is now encrypted and may show in a different colour.
   (You can test this by logging in as a different user on the machine and trying to access the contents of the encrypted files, resulting in an 'Access denied' message.)

7. Now use the MSMQ Manager to re-point its storage locations (all of them) to the new encrypted folder you just created on disk (and away from the default or current storage location wherever that might be). The change will prompt you to restart the service. Say Yes.

If you discover any problems with this solution please post here in the comments. Thank you.

† I tested this solution on both Win 7 workstation & Windows 2008 R2 Server by writing to and reading from the queue using a basic .NET application outlined in this article about how to write a bare minimum message queue app.