Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
As described below, a recent vulnerability was found with PGP and GnuPG. While PGP itself isn’t really the issue, the concern lies in how PGP is used.
This is quite possibly something that might impact the FIX PGP-DES-MD5 system due to how we use PGP.
Assume the following:
- Alice sends Bob a FIX Logon. Call the plaintext containing the DES key, IV and channel binding P, and the resulting cyphertext C
- Eve intercepts that Logon and steals C. This alone is useless, since Eve cannot decrypt C into P.
- Eve modifies C in a special way, creating C’
- Eve sends Bob a Logon using the modified C’
- Bob decrypts it. It will decrypt to plaintext garbage that nobody can predict, which we will call P’. Bob then re-encrypts P’ with Eve’s public key, signs it, and sends it back to Eve as per the FIX protocol.
- Eve decrypts it. At this point Eve knows C, C’, and P’. Because of how C’ was derived from C, Eve can use the resulting P’ to compute P, which is the plaintext. This means that Eve now knows the DES key that Alice and Bob are using, and can decrypt all of their messages and impersonate either party.
There are some caveats with this approach:
-
If Alice and Bob used PGP compression, then this can foil the attack. I’m not sure if compression is enabled by default for these kinds of messages. For FIX, P is generally 24 bytes long, the first 16 of which are random hence not compressible, so PGP might not even try to compress the block.
-
Eve must have a way to get Bob to decrypt C’ and send Eve the resulting P’. This means that either Eve must have a business relationship with Bob, or that Bob must be configured to allow anyone to initiate a FIX session to him and respond with a Logon containing the decrypted PGP block, without validating the message signature on the Logon.
Now from a practical standpoint, I don’t know if this really lessens FIX security. Assuming firms don’t allow strangers to talk to their FIX engine and get an encrypted Logon in response, this limits the attack to something that only one’s business partners can implement.
Also, in the above example, it isn’t exactly trivial for Eve to intercept the communication. I maintain that anyone who can successfully intercept leased line or Internet traffic and wants to cause harm or steal information can likely find the couple hundred thousand dollars necessary for custom ASIC chips to do a brute force DES decryption.
Migrating to SSL or TLS eliminates this specific attack, and, assuming only strong (112 bit or higher) cyphersuites are employed, substantially increases the computational resources required to brute force a key.
Details of the PGP attack are:
I believe FIX is quite resilient to the attack described below by Ryan Pierce.
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|
This Bob can parse and so will accept.
However, an attack will produce a string of random garbage instead, which Bob will not be able to parse, so the connection should fail.
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.
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.
Eve’s attack-ciphertext decrypts as garbage. There is no way for her to ensure it has a valid signature from her, so Bob can spot this and reject her message.
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.
> As described below, a recent vulnerability was found with PGP and GnuPG. While PGP itself isn’t really the issue, the concern lies in how PGP is used.
>
> This is quite possibly something that might impact the FIX PGP-DES-MD5 system due to how we use PGP.
>
> Assume the following:
>
> 1. Alice sends Bob a FIX Logon. Call the plaintext containing the DES key, IV and channel binding P, and the resulting cyphertext C
> 2. Eve intercepts that Logon and steals C. This alone is useless, since Eve cannot decrypt C into P.
> 3. Eve modifies C in a special way, creating C’
> 4. Eve sends Bob a Logon using the modified C’
> 5. Bob decrypts it. It will decrypt to plaintext garbage that nobody can predict, which we will call P’. Bob then re-encrypts P’ with Eve’s public key, signs it, and sends it back to Eve as per the FIX protocol.
> 6. Eve decrypts it. At this point Eve knows C, C’, and P’. Because of how C’ was derived from C, Eve can use the resulting P’ to compute P, which is the plaintext. This means that Eve now knows the DES key that Alice and Bob are using, and can decrypt all of their messages and impersonate either party.
>
> There are some caveats with this approach:
>
> 1. If Alice and Bob used PGP compression, then this can foil the attack. I’m not sure if compression is enabled by default for these kinds of messages. For FIX, P is generally 24 bytes long, the first 16 of which are random hence not compressible, so PGP might not even try to compress the block.
>
> 2. Eve must have a way to get Bob to decrypt C’ and send Eve the resulting P’. This means that either Eve must have a business relationship with Bob, or that Bob must be configured to allow anyone to initiate a FIX session to him and respond with a Logon containing the decrypted PGP block, without validating the message signature on the Logon.
>
> Now from a practical standpoint, I don’t know if this really lessens FIX security. Assuming firms don’t allow strangers to talk to their FIX engine and get an encrypted Logon in response, this limits the attack to something that only one’s business partners can implement.
>
> Also, in the above example, it isn’t exactly trivial for Eve to intercept the communication. I maintain that anyone who can successfully intercept leased line or Internet traffic and wants to cause harm or steal information can likely find the couple hundred thousand dollars necessary for custom ASIC chips to do a brute force DES decryption.
>
> Migrating to SSL or TLS eliminates this specific attack, and, assuming only strong (112 bit or higher) cyphersuites are employed, substantially increases the computational resources required to brute force a key.
>
> Details of the PGP attack are:
>
> http://www.eweek.com/article2/0,3959,462170,00.asp
> http://www.counterpane.com/pgp-attack.html
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> 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.