re: FIX resilience to [PGP Vulnerability ]
Ryan Pierce / Townsend Analytics Ltd. / Archipelago LLC
23 Aug 2002 3:41PM ET> The reason for this is as follows: the encrypted blocks in FIX messages have a parseable structure, whereas the attack below relies on the plaintext being a random "challenge".
>
> For example, assume that Bob receives a friendly FIX logon message and decrypts the PGP secure data block. He might expect to see the following in the output (where | is the delimiter):
> 34=1|35=A|98=5|95=24|96=ARxK$l12HjIo~#kQ34003400|
[SNIP]
> Note that even in the limiting case, where only the DES-init string is encrypted, there is still a leading "96=" tag. So even if we assume the DES-init string is random, there is enough structure to spot the attack.
>
It had previously been my view that only the 24 byte structure, without the leading 96= tag, would be encrypted in the PGP block.
If this were the case, Eve could pull off the attack as described, provided that Eve had a business relationship with Bob. Bob would have little idea whether he was encrypting and sending Eve valid or bogus plaintext. Bob's only clues are that the parity bits in the DES key likely wouldn't be right, and that Eve's channel binding would be random. I doubt that most implementations check the parity bits on the DES key prior to responding, or that they check the channel binding.
However, after looking at the app note more closely, this isn't the case. According to the app note, the fields that should be encrypted in the PGP message are:
MsgSeqNum, SendingTime, SendingDate, RawDataLength and RawData
Given that this app note was FIX 3.0-centric, I interpret that SendingDate should not be included in FIX 4.0 and higher.
Further, the app note makes no mention of a response, however it seems common practice in FIX 4.0 and above to respond with a Logon containing a PGP encrypted and signed data block with those fields. This allows both parties to verify the identity of each other through the signatures.
While I believe FIX would be vulnerable if only the 24 byte block were sent, it isn't vulnerable if the additional data listed above is sent AND if said data is validated.
Now herein lies a potential problem. Bob could have made a coding error. It is conceivable that Bob's engine will, in preparing the response, just re-encrypt the decrypted PGP message with Eve's public key, as opposed to replacing MsgSeqNum and SendingTime to match his own Logon. (Since the app note does not dictate a response, this can't really be deemed non-compliant.) So Bob conceivably could, in the presence of Eve's malicious C', just re-encrypt P' and send it back to Eve in a Logon, although when Bob gets around to communicating using DES, Bob will discover that Eve never supplied a key or an IV.
> In general, this attack could be dodged by adding a signature to the random challenge before it was encrypted (PGP has a way to do this).
> This allows Bob to check the integrity and authenticity of the random challenge after decryption.
This is an interesting question.
I am fairly certain that the signature is stored outside of the ciphertext. One can take a signed PGP message and tear off the signature. The separated signature and document together can be verified.
In order to authenticate the parties, as well as to prevent man-in-the-middle attacks, Alice should always sign her PGP message. Bob should always verify Alice's signature.
Now what I don't know is whether a PGP signature of an encrypted message protects the ciphertext or the plaintext. If it protects the ciphertext, then Eve is in luck. Eve can construct a PGP message that contains the modified C', and Eve can apply her own signature of C'. Bob can verify that the message did indeed come from Eve and was signed by her. (In this example, I am assuming that Eve and Bob have a business relationship, and that Eve normally initiates PGP-DES-MD5 sessions to Bob.) But if the signature protects the plaintext, then Eve has a problem. She doesn't yet know P', so she cannot generate a signature for it.
Still, Eve might try her luck sending an unsigned PGP message to Bob. If Bob's FIX engine doesn't check that the message is signed by Eve, and simply responds with a signed message containing P', then Eve still is in luck.
> Thus, I feel the nature of FIX makes it more secure than a simple random challenge. However, the nature of the attack does demonstrate that we should not be complacent about ready-made security solutions such as PGP.
I agree that we should not be complacent. This is one of the reasons why I dislike PGP-DES-MD5. Implementing it is very intrusive to a FIX engine. The FIX engine developer is placed right in the middle of implementing many of the minute details of the security protocols, and small errors or oversights, like I mentioned above, could have unforseen but disasterous security consequences.
Similarly, had the designers of the PGP-DES-MD5 protocol just encrypted the 24 byte block, FIX would be extremely vulnerable to this kind of attack.
This is why I am very concerned about people other than cryptography professionals implementing security-critical components, or more importantly, defining security protocols. Just reading parts of Schneier's _Applied_Cryptography_ made this quite clear. Even with unbreakable algorithms, protocols that look solid can often have subtle but severe weaknesses.
This is also a big advantage to using SSLv3 or TLS instead of PGP-DES-MD5. SSL/TLS just bolts onto the FIX engine and stays largely external to it, leaving fewer areas for implementation errors. SSL/TLS can be purchased from cryptography professionals, or it can be obtained free from open source code that receives much peer review. And the actual SSL and TLS protocols were developed by top cryptography professionals and placed under close public scrutiny. People like Rivest or Schneier are going to be spending their time examining protocols like SSL and TLS that have wide deployment, not something like PGP-DES-MD5 that is used only in one niche.
