Signature and BodyLength

, ,
1

Imported from previous forum

2

Hi,

Fix Security protocol says - “Except for StandardTrailer, the whole message contributes to the message signature”.

BodyLength is part of Header which is included for signature generation. Fix protocol specifies bodylength is calculated based on fields following bodylength upto fields before checksum field.

My question is: Should signature be considered for bodylength calculation during encryption? If yes, during signature generation, body length may not represent correct value (as signature is not added to field collection) but while decrypting body length includes signature value which results in different md5 hash. One can argue that since signature is of fixed length one can estimate the length and add to body length. But think it in implementation point of view, where body length is calculated based on field collection. (One can argue that signature field can be removed from the field collection before md5 hash generation during decryption. Then in this case we don’t have the actual field collection.)
If no, and if it has been specified in any document, kindly point me to the right resource.

Thanks in Advance.

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> My question is: Should signature be considered for bodylength

calculation during encryption? If yes, during signature generation,
body length may not represent correct value (as signature is not added
to field collection) but while decrypting body length includes
signature value which results in different md5 hash.

Wow… It’s been a very long time since I’ve had to answer implementation questions about PGP/DES-MD5. And it’s also been a very long time since I’ve done anything with code that implements it.

I took a look at the original Morgan Stanley document, and it seems that, when “signing” a message (I use the term loosely since this is a message authentication, not an actual digital signature) one must:

  1. Prepare the entire message up to that point (I.e. the unencrypted header fields + the encrypted data block. No trailer fields.)

  2. Compute BodyLength just as you would for a normal FIX message, where all that is missing is the checksum. Ignore the signature fields in the trailer.

  3. The signature is a fixed length; MD5 always outputs 16 bytes. The two tags used are each 2 bytes long, there are 2 “=”'s, the number “16” (the length) takes up 2 bytes, and 2 's. So that’s 26 bytes total. Add 26 to the message length computed in #2, and stick that in the message.

  4. Take an MD5 hash of the DES key, the FIX message so far (which includes what will be the exact BodyLength once the signature is applied), and the DES key again.

  5. Append to the end of the message the following 26 bytes:

93=1689=XXXXXXXXXXXXXXXX

(Where the X’s are the 16 bytes of the MD5 signature)

  1. Stick on a Checksum field, and the message is ready for transmission.

Of course I wonder why anyone is considering a new implementation using PGP/DES-MD5. DES is not secure against a determined adversary. Tunneling FIX through SSL or TLS via Stunnel, or building an SSL or TLS library directly into the FIX engine, provides for state of the art cryptography support, and, I would imagine, would be substantially easier to implement than PGP/DES-MD5.

The following draft paper will describe the new proposed recommendations regarding security in detail:

http://www.fixprotocol.org/documents/3556/FIX%20Security%20White%20Paper.pdf