Prevent the ability to modify messages on the wire or craft a message

[ramonsmits]

We currently do have a feature that prevents message tampering. This results in being able to forge a message. In normal circumstances this probably isn't a big issue but when this message has encrypted data in it than the probability to prevent increases.

The current encryption might also give a false level of trust as the customer might expect that encrypted data is tamper proof.

It is possible to copy/paste property values somewhere else in the message or in a completely different message and this also applies to encrypted property values which might be something that we want to detect.

We can detect this by singing the message and make this signature specific for this message ID and encrypting this signature so that we can check this signature when the message is processed.

Possible solution

Features

• body signing
• header signing
• header signing encryption

Where to store hashes?

• Hash of the body can be added as a header (Content-MD5?).
• Hash the headers can be added as a XML attribute after the headers have been serialized.

Sending

• Get hash of RAW Body
• Put RAW body hash in headers
• Serializer headers
• Get hash of headers inner text
• Encrypt headers innertext hash value
• Add signature XML attribute with this encrypted value

Receiving

• Get hash of header inner text
• Decrypt header signature
• Compare hashes
• If unequal throw
• Get hash of RAW body
• Compare body hash to value in headers
• If unequal throw

Questions / Remarks

• Does V6 allow additinal steps in the pipeline after message headers have been serialized?
• Would an MD5/SHA1 hash of the headers provide value without encrypting this?
• Would we want this to be dependant on the encryption service for encryption of the signature(s)?
• Possibly rely on existing encryption service for encryption of the signatures
• Hash algorithm should be deemed strong enough for message tampering

Example

The following is an example of the signature attribute and the ContentHash header value:

<ArrayOfHeaderInfo
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        signature="<base64 encrypted hash of the innerText>">
 <HeaderInfo>
   <Key>ContentHash</Key>
   <Value>Base64Hash; algorithm=sha1</Value>
 </HeaderInfo>
</ArrayOfHeaderInfo>

[SimonCropp]

I would prefer this was first a sample using mutators or behaviors so we can experiment with idea in a low risk and flexible way

[ramonsmits]

@SimonCropp Spiking it is way to test if our pipeline even allows signing on the areas that are required. A set of requirements should be defined to test like:

• What is signed? Only the body or also the headers?
• Currently the headers are stored seperately from the body so if we are going to generate a hash then based on what values and in what order?
• If we have the signature we must add it to the headers but not include this when calculating the hash at the receiver. How to do this while making sure that the serialized headers are exactly the same when the the hash was calculated at the sender.

I also added an additional reason for this issue in the description:

The current encryption feature might also give a false level of trust as the customer might expect that encrypted data is tamper proof.

[MarcinHoppe]

Is it fair to say that this item is both about providing message integrity as well as protection against a replay attack ?

Maybe these two security properties should be covered by separate issues?

[ramonsmits]

@MarcinHoppe Replay attack is different but for sure about integrity.

[ramonsmits]

Extended the description with a possible implementation after a discussion with @justabitofcode and @WojcikMike

[MarcinHoppe]

Mention of copy-paste made me think of a replay attack, but I see this is more about message integrity & authenticity.

The possible implementation notes should probably also mentioned crypto key management.

Also, there are known practical attacks against MD5 and SHA1. If we want to use them to authenticate messages (as opposed to adding integrity protection only), we should look at SHA2 family of functions and HMACs built upon them.

[ramonsmits]

@MarcinHoppe Nice that you mention the crypto key management as the idea as to rely on the encryption service for this and one of the weaknesses of it is that it currently does not allow rolling keys without restarting the instance.

For sure, the hashing algorithm should be selectable and be current. 👍

[MarcinHoppe]

@ramonsmits is there a separate issue to allow key rotation without endpoint restart?

[WojcikMike]

@MarcinHoppe it is here: #3317

[MarcinHoppe]

@WojcikMike thanks, looks good.

[andreasohlund]

This can be added in a minor release, removing the v6 label