Partilhar via

Passing Private Messages

  • Artigo

 

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

Passing private, encrypted messages between a Message Queuing system and a foreign messaging system is very similar to passing private messages between Message Queuing computers. The only difference is that a symmetric key must be exposed when sending a private message.

The message properties used to send private messages include:

Property Description
PROPID_M_BODY Contains encrypted message body.
PROPID_M_DEST_SYMM_KEY Used to decrypt messages.
PROPID_M_DEST_SYMM_KEY_LEN Specifies the length of the symmetric key.
PROPID_M_ENCRYPTION_ALG Algorithm used to encrypt the message.
PROPID_QM_ENCRYPTION_PK PROPID_QM_ENCRYPTION_PK_BASE

 PROPID_QM_ENCRYPTION_PK_ENHANCED		 One of these properties must contain the public key of the destination queue (used when sending messages to a Message Queuing queue.)

For MSMQ 1.0 applications, use PROPID_QM_ENCRYPTION_PK.

For MSMQ 2.0 applications, the base and enhanced public key properties should contain the 40-bit or 128-bit encryption key respectively.

(MSMQ 2.0) Identifies the 40-bit public encryption key of the computer.

(MSMQ 2.0) Identifies the 128-bit public encryption key of the computer.

The implementation of the connector application plays a significant role when passing private messages to their destination.

Transparent connector applications pass the symmetric key, encryption algorithm, and the encrypted message body on to the queue manager of the destination queue. This is the same regardless of the direction the message is going. When using a transparent connector application, the public keys of all destination Queue Managers must be registered in the directory service.

Non-transparent connector applications decrypt the message at the server and can pass on a clear-text message body or encrypt the message again (using the receiving system's encryption operations) and pass on a newly encrypted message body. When using a non-transparent connector application, the sending application must use the public key of the connector application to encrypt the message.

In addition to the type of connector application, there are two design considerations that should be taken into account:

  • When multiple Message Queuing servers are used (when two or more servers are connected to the same foreign connected network or foreign site), only transparent connector applications can be used.

  • When sending messages from one messaging system to another, the source application must get the public key of the destination queue before it can encrypt the message body. The source application must tell the connector application to call MQGetMachineProperties and pass back the public key found in one of the three encryption key properties mentioned above.

  • This means that there must be a level of trust between the connector application and the foreign queue manager. There is no way for the foreign queue manager to independently verify that the key received is the public key that it requested.

Note

For foreign message properties not supported by Message Queuing, use PROPID_M_EXTENSION and PROPID_M_EXTENSION_LEN.

Caching the Symmetric Key

Non-transparent connector applications can cache the symmetric key to save time when decrypting private messages. If several messages arrive from the same source, there is no need to decrypt a symmetric key for each message.

To do this, the application must cache the identifier of the source computer and the decrypted and encrypted values of the symmetric key. The connector application can call PROPID_M_SRC_MACHINE_ID to retrieve the identifier of a Message Queuing source computer.

When the next message arrives, the connector application can first check if a message has already arrived from that source computer. If the computer identifier is not found, the connector application will add it to the cached values.

If a previous message has arrived, the application can next test to see if the new encrypted key matches the cached encrypted key. If they match, the cached decrypted value can be used immediately. If they do not match, it will decrypt the new key (storing both the encrypted and decrypted values in the cache), using the new value to decrypt the message body.