re: Clarification on Data Integrity
Ryan Pierce / Townsend Analytics Ltd. / Archipelago LLC
24 Sep 2002 12:46PM ET> Why can't a signature be used without the encryption option being selected, assuming that it is used on a physically secure network?
This application note was written many years ago. The authors probably just assumed that nobody would want to use signatures without encryption.
EncryptMethod=PGP-DES-MD5 is relatively well documented, and a sample implementation exists. It describes a method to exchange session keys, which are also used for signing. I suppose that one could use PGP to securely exchange a symmetric signing key, or that a signing key could be determined out of band. But no EncryptMethod enumerations were ever defined for it.
I really don't consider this a true "Signature." Most people think of signatures in the PKI sense, where there's a fundamental asymmetry. The sender signs a message, and the recipient can verify the signature. But the recipient cannot take a fake message and compute the sender's signature for it. This helps to reduce fraudulent repudiation.
Now the FIX "signature" is really a message authentication code. The computation is entirely symmetric. Both parties share a secret. One party computes the signature for a message and sends it with the message. The other party can compute the same signature, and, since the signatures match, determine that the message is authentic.
In the PKI case, one could go to a judge and present a signed order that their counterparty denies, and the judge can determine that someone in possession of the counterparty's signing key must have signed that order. With a message authentication code, both parties shared the same secret key, so a judge could not determine which of the two parties actually signed the message.
Thus, FIX "signature" only protect against modification of the message over the wire. They do NOTHING to protect against fraudulent repudiation.
> Regarding signature computation, this is what the document has to say:
>
> "To compute a signature, the DES session key is fed into the MD5 engine as the first 8 bytes. The high order byte (most significant) is fed in first. Next, the unencrypted portion of the FIX header is processed. Then, the DES encrypted portion of the FIX message is fed in. Lastly, the 8 byte DES session key is fed in again (to protect against a message padding attack). Except for the StandardTrailer, the whole message contributes to the message signature."
>
> Does this mean the the header without the SecureDataLen and SecureData fields need to be added and then both SecureDataLen and SecureData fields be added? Is this in the <tag>=<value><SOH> format or ....?
On the FIX web site (under Specifications / App Notes) there is an actual implementation of PGP-DES-MD5 which you can examine.
We've rolled our own code for this, but it is interoperable with clients who use the FIX web site implementation. What I believe happens is that, after initializing a clean MD5 hash and hashing the session key, the entire FIX message buffer created so far gets hashed. This likely consists of the BeginString, BodyLength, and MsgType, followed by SecureDataLength and SecureData (including the [SOH] at the end.
Now one might see a contradiction here. BodyLength is included in the hash, but it isn't known because the message is not yet finished. Fortunately, there are only two elements missing, SignatureLength and Signature. The value of SignatureLength is always 16 since that's the fixed size of an MD5 hash. So after signing you will be appending:
93=16[SOH]89=XXXXXXXXXXXXXXXX[SOH]
to the end of the message. Hence you must add 26 to the body length prior to signing, compute the hash, tack on the above fragment, and only then compute and tack on the FIX Checksum.
> Is computation of signature as detailed in this document the only way to go about or is it upto the discretion of the counterparties?
This is how you must do it if you want to speak PGP-DES-MD5 and be compatible with the rest of the FIX community.
Now proprietary methods for signing exist. For instance, EMX has created a proprietary method that uses PKI to create an actual digital signature of the message, as opposed to the symmetric MAC used by FIX.
> How relevant is this document today? What other documentation should I refer to regarding data integrity and encryption (DES-ECB)?
In some regards, the document is outdated. It is based around FIX 3.0, and doesn't include any mention of sending back a Logon with a PGP response. (FIX 3.0 only has a unidirectional Logon, as opposed to the bidirectional exchange in FIX 4.0 and later.)
Still, the document does a fairly good job. PGP-DES-MD5 is fairly standard thanks to the reference implementation. There were no reference implementations for DES-ECB. In particular, a fair amount of confusion and problems exist in the industry regarding how to handle DES-ECB encryption of the last data block. I've heard of some people padding it with SOH's, and others just leaving it unencrypted.
To be honest, I wouldn't suggest using DES-ECB at all. The key is exchanged out of band. Hence a 56 bit key may be used for many days, and possibly many years. PGP-DES-MD5 at least has a daily DES key exchange. Further, ECB mode of DES is particularly bad with a protocol like FIX because one can then look for repetitions of encrypted data blocks over time and build a code book, much like one breaks the cryptogram puzzles in newspapers.
Further, the Encryption Working Group has been charged with standardizing SSLv3 and/or TLS as an alternative to PGP-DES-MD5. This will provide more security and (hopefully) be easier to implement.
