BeginSeqNo (Tag#7) and EndSeqNo (Tag#16) encryption using PGP/DES-MD5 technique

, ,
1

Imported from previous forum

2

Hi,

Can anyone please tell me that where should I put BeginSeqNo (Tag#7) and EndSeqNo (Tag#16), in encrypted section or in unencrypted, while sending the ResendRequest using a PGP/DES-MD5 algorithm to secure the data.

Desperately waiting for a reply.

M. Amir Ul Amin

3

[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
> Can anyone please tell me that where should I put BeginSeqNo (Tag#7) and

EndSeqNo (Tag#16), in encrypted section or in unencrypted, while sending
the ResendRequest using a PGP/DES-MD5 algorithm to secure the data.

Desperately waiting for a reply.

These tags are not listed as ones required to be unencrypted, so I don’t believe it matters.

As session-level messages contain no confidential business content, I question what value there would be to encrypting a ResendRequest.

However, I also question why PGP/DES-MD5 is being used in the first place. It was effectively proven insecure many years ago when the DES was cracked using relatively inexpensive hardware. It is also, in my opinion, extremely fragile and difficult to implement.

Most firms that require encryption will either:

  1. Do it at the network level, such as IPSec, either within the server’s network stack, or via routers or VPN boxes, so it is completely invisible to the FIX applications, or

  2. If initiating a session, have their FIX engine connect unencrypted to a proxy server which then makes an encrypted connection outbound to their counterparty. Or if accepting a FIX session, have their counterparties connect encrypted to a proxy server that, upon connection, makes an unencrypted connection to their FIX engine. Usually, SSLv3 or TLS are the protocols of choice. The open source program “stunnel” can act as the proxy, or

  3. Embedding an SSLv3 or TLS library in their FIX engine to support encryption directly. In this case, no application or session level changes are made to FIX; the data is simply routed through the library, which manages the TCP socket connection.

The Information Security Subcommittee has produced an extensive white paper on this topic here:

http://fixprotocol.org/documents/3868/FIX%20Security%20White%20Paper-1.8.doc

4

Hi Ryan,

delighted to see an answer on my question,

well bro you are right that its quiet insecure, but thing is that our client want this approach :slight_smile: so we have to implement it.

on your question, to avoid a replay attack I have encrypted it, but now after thinking so much on your question I believe that I should not encrypt a session level message except Logon.

Thanks for your time and help, it really helped me.

M. Amir Ul Amin

Can anyone please tell me that where should I put BeginSeqNo (Tag#7)
and EndSeqNo (Tag#16), in encrypted section or in unencrypted, while
sending the ResendRequest using a PGP/DES-MD5 algorithm to secure
the data.

Desperately waiting for a reply.

These tags are not listed as ones required to be unencrypted, so I don’t
believe it matters.

As session-level messages contain no confidential business content, I
question what value there would be to encrypting a ResendRequest.

However, I also question why PGP/DES-MD5 is being used in the first
place. It was effectively proven insecure many years ago when the DES
was cracked using relatively inexpensive hardware. It is also, in my
opinion, extremely fragile and difficult to implement.

Most firms that require encryption will either:

  1. Do it at the network level, such as IPSec, either within the server’s
    network stack, or via routers or VPN boxes, so it is completely
    invisible to the FIX applications, or

  2. If initiating a session, have their FIX engine connect unencrypted to
    a proxy server which then makes an encrypted connection outbound to
    their counterparty. Or if accepting a FIX session, have their
    counterparties connect encrypted to a proxy server that, upon
    connection, makes an unencrypted connection to their FIX engine.
    Usually, SSLv3 or TLS are the protocols of choice. The open source
    program “stunnel” can act as the proxy, or

  3. Embedding an SSLv3 or TLS library in their FIX engine to support
    encryption directly. In this case, no application or session level
    changes are made to FIX; the data is simply routed through the
    library, which manages the TCP socket connection.

The Information Security Subcommittee has produced an extensive white
paper on this topic here:

http://fixprotocol.org/documents/3868/FIX%20Security%20White%20Paper-
1.8.doc

5

[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
> well bro you are right that its quiet insecure, but thing is that our

client want this approach :slight_smile: so we have to implement it.

I am very sorry to hear that. So they are using obsolete technology that can easily be broken by anyone with the resources and motivation to intercept a FIX session, which has design flaws that make the session more fragile, uses a combination of cryptographic protocols that together has not undergone rigorous academic review, and is likely going to be costly to implement for all of the firm’s trading partners as it requires invasive FIX engine modifications.

Again, I strongly suggest recommending use of SSLv3 or TLS to the client. These have had rigorous academic review. The OpenSSL library is put under intense scrutiny, as is the “stunnel” proxy. Implementation with stunnel is fairly trivial and non-invasive. Alternately, bolting OpenSSL onto an engine is far less invasive than doing the same thing for PGP/DES-MD5, so I would imagine it would be lower cost. It does not introduce the instability problems that PGP/DES-MD5 does. And it actually provides a real level of security.

on your question, to avoid a replay attack I have encrypted it, but now
after thinking so much on your question I believe that I should not
encrypt a session level message except Logon.

In my opinion, a bigger concern is that resend requests become extremely fragile as soon as PGP/DES-MD5 is employed.

The issue is that PGP/DES-MD5 uses DES in Cipher Block Chaining mode. This means decrypting a block requires the ciphertext of the block sent prior to it. If a message goes missing, or some kind of reordering occurs, it will corrupt the next message. Specifically, the first 8 bytes of the encrypted data will be decrypted, but will then be XOR’d with the wrong previous ciphertext block, so the plaintext is corrupted. Unfortunately, there is no easy mechanism to catch this! The FIX checksum will be valid. The MD5 “Signature” will be valid, as well, as it is made from the ciphertext, not the plaintext.

It follows that when responding to a Resend Request, one can’t do what one does in normal FIX, e.g. keep the body and most of the header the same, update SendingTime and add OrigSendingTime, add a PossDupFlag, recompute the message length and checksum, and send it out. Because CBC mode is used, it becomes necessary to re-encrypt the plaintext as well, this time using a different initialization vector.

None of this is an issue with SSLv3 or TLS. Resend request processing is identical; either the proxy application (e.g. stunnel) or the SSLv3/TLS library takes care of things.

Thanks for your time and help, it really helped me.

You are welcome!