Imported from previous forum
[ original email was from Bob Lamoureux - blamoureux@bridge.com ]
This thread is to be used to discuss basic framework ideas surrounding Encryption vis-a-vis FIX. For example, we need to set some goals for what the encryption solutions should have as basic characteristics. Some of these characteristics may include platform neutrality, cost, transport layer independance, etc. We should then agreee on the precedence level of these items and apply this list to all the solutions that we consider.
Please use this thread as an overall thread for these types of discussions.
[ original email was from Charles Blauner - blauner_c@jpmorgan.com ]
OK let me take a shot at some basic framework characteristics that I am looking for and some suggested starting points for discussions.
-
Open Standards-based APIs to allow portability amoung different PKI vendors products. My suggestion here is the OpenGroup’s CDSA framework (initially developed by Intel, Netscape, IBM, Entrust, and TIS) for the lower level APIs and the IETF’s GSS-APIv2 for session oriented security services, GSS-IDUP for store-and-foward security services and digital signatures.
-
The certificate management protocols must be based on standards to allow interoperability between different CA products and here I suggest
the work being done in the IETF’s PKIX working group. -
Minimize change to the exisitng protocols but add some security handshake messages at session establishement.
-
Limit data-structure changes to that required to support signed messages.
One way we should be able to accomplish 3 & 4 is by wrapping GSS-based encryption around the exisiting FIX messaging infrastructure.
Charles Blauner
JP Morgan
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
It seems the previous Security discussion
group, which had a lot of good comments in it,
has vanished.
I see a lot of disadvantages to implementing
security within the FIX protocol as opposed to
on a more external transport level.
Transport-level crypto provides authentication
and non-repudiation between two parties. Now
to prove that all messages were sent by
another person, you need to store the entire
raw data of the session. (But one should
probably be doing that anyway.)
Transport-level crypto does not work in cases
where you are using a FIX network using the
DeliverTo… fields to route to one of many
destinations. But in these cases, signatures on
individual messages are only valuable if the
FIX network isn’t rewriting the messages. And
it seems to me the whole purpose of such FIX
networks IS to rewrite messages, i.e. translate
between FIX 2.7, 3.0, 4.0, and 4.1.
Other than these two drawbacks,
transport-level crypto seems to be the way to
go. Still, I can see people wanting individual
signatures. I haven’t had time yet to research
GSS or CDSA, so I’d appreciate someone who
knows about them addressing the following:
-
Export. Since the crypto has to be embedded
within the FIX engine, to export it you must be
able to provide a signature-only mode (and
you can rely upon an external transport layer
obtained from a non-US country to handle
encryption) or you must dumb down the crypto
to the pathetic standards allowed by the US
government for export, or you must use the
dreaded Fortezza card. Which of these
are doable under GSS / CDSA? -
Complexity. How hard are these things to
implement? -
Availability. Is GSS / CDSA available for
the majority of platforms FIX runs on?
Specifically, Unix, Win32 and Java? -
Cost. Do you have to pay a fortune either
for the GSS or CDSA libraries, or large patent
royalties to RSADSI? Is there a way to cut
costs by using Diffie-Hellman and DSS?
[ original email was from Charles Blauner - blauner_c@jpmorgan.com ]
> It seems the previous Security discussion
> group, which had a lot of good comments in it,
> has vanished.
>
> I see a lot of disadvantages to implementing
> security within the FIX protocol as opposed to
> on a more external transport level.
Can you explain the disadvantages to me. From a
pure security perpsective I have yet to see a more
secure system built by moving security down into
the transport layer instead of providing end-to-end security.
>
> Transport-level crypto provides authentication
> and non-repudiation between two parties. Now
> to prove that all messages were sent by
> another person, you need to store the entire
> raw data of the session. (But one should
> probably be doing that anyway.)
Actually, transport layer security does not
provide for non-repudiation. There is no
visibility to the signer of an explicit action.
Only the first server in a chain can actually
verify identies and since these servers are not
likely to be the ones making security decisions
a tranport layer based model assumes that all
downstream systems trust the asserted identity
and that certainly does not provide non-repuidation either.
>
> Transport-level crypto does not work in cases
> where you are using a FIX network using the
> DeliverTo… fields to route to one of many
> destinations. But in these cases, signatures on
> individual messages are only valuable if the
> FIX network isn’t rewriting the messages. And
> it seems to me the whole purpose of such FIX
> networks IS to rewrite messages, i.e. translate
> between FIX 2.7, 3.0, 4.0, and 4.1.
>
> Other than these two drawbacks,
> transport-level crypto seems to be the way to
> go. Still, I can see people wanting individual
> signatures. I haven’t had time yet to research
> GSS or CDSA, so I’d appreciate someone who
> knows about them addressing the following:
>
> * Export. Since the crypto has to be embedded
> within the FIX engine, to export it you must be
> able to provide a signature-only mode (and
> you can rely upon an external transport layer
> obtained from a non-US country to handle
> encryption) or you must dumb down the crypto
> to the pathetic standards allowed by the US
> government for export, or you must use the
> dreaded Fortezza card. Which of these
> are doable under GSS / CDSA?
>
Actually, there is lots of exportable software
with crypto in it. But as you state it has to be
engineered properly. One of the advantages of the
CDSA framework is that it allows for plugable
crypto. The builder of the application does not
have to be the supplier of the crypto.
GSS would be the likely API for coding a FIX
engine since it is the higher level API. As with
all IETF standards there are no patent issues with
GSS. A patent issue would only come up if you
wanted to use a patented algorithm of key-exchange
protocol.
> * Complexity. How hard are these things to
> implement?
Coding to GSS ia quite simple. We have converted a
number of application with minimal coding. The
applications in question where well architected
so isolating the communications to build in
security was pretty straight foward.
>
> * Availability. Is GSS / CDSA available for
> the majority of platforms FIX runs on?
> Specifically, Unix, Win32 and Java?
>
I know that GSS ia available from many folks on
a vast number of platforms but I don’t know if
a pure java implementation exists yet. CDSA
will become more generally available throughout
the year.
W.R.T. Java, I still have a concern in that I
have not seen any real good implementations of
random number generators in pure java and that
leaves me wondering just how strong any pure
java crypto implementation can be.
> * Cost. Do you have to pay a fortune either
> for the GSS or CDSA libraries, or large patent
> royalties to RSADSI? Is there a way to cut
> costs by using Diffie-Hellman and DSS?
>
>
For more information on GSS-API check out the IETF’s web site (ietf.cnri.reston.va.us) under
the CAT working group. If you want to learn more
about CDSA checkout the OpenGroup’s web site
(opengroup.org) under the Security Program Group.
Charles Blauner
[ original email was from Danny Shobrook - dzshobrook@dial.pipex.com ]
Firstly, any traffic analysis will give you alot of information of heavy trading. As dest and source IDs are not encrypted, putting a sniffer will give you a clue if someone is trying to split a large trade up amongst smaller guys.
Secondly, any encryption/signing will have to be resistant to differential cryptoanalysis as alot of the plaintext will already be known.
Thirdly, you have to ask yourself about the perfomance tradeoffs with double encryption at transport and app layer. It might make sense for large institutional trades, we deal with retail and this would put an unacceptable overhead for really rather little return.
Fourthly, you would need to make sure there was a way of negotiating any app level encryption. The current "agree before" was maybe OK when the FIX community was small, but increasingly it will be used between parties that have no fixed relationship. There would need to be the opportunity to adjust between the level Charles wants and the level retail customers are happy with.
Fifthly, the most common security flaws are bugs in implementation and people probs. Coming up with a new app level protocol faces both these complications.
Finally, it puts a stress on FIX implementers to be encryption experts as well.
Danny Shobrook
Apt Computer Systems
[ original email was from Bob Lamoureux - blamoureux@bridge.com ]
The threads are starting to heat up here, which is good. My comments to this particular message are below, but first a friendly request. A lot of the comments so far are obviously being done by people who have been thinking hard about this problem. Could you guys please post a couple of messages that discuss the strengths of certain crypto techniques. Right now, we are describing the weaknesses of each other’s ideas instead of talking up the strengths of the alternatives. I also think it would help the non-security experts (myself included) to learn more of the core features of the current crypto work being done.
Thanks.
> Firstly, any traffic analysis will give you alot of information of heavy trading. As dest and source IDs are not encrypted, putting a sniffer will give you a clue if someone is trying to split a large trade up amongst smaller guys.
DEST and SOURCE ids provide no valuable information. If you are sniffing the packets, you already know who they came from and where they are going… so sending them in the clear has zero security ramifications. Multiple Order messages from one site to many destinations does not imply a large trade being split among several brokers. Again, even with the message type being sent in the clear, no trade-able information can be gleaned from this knowledge
>
> Secondly, any encryption/signing will have to be resistant to differential cryptoanalysis as alot of the plaintext will already be known.
The plaintext is not part of the encrypted data’s computations. So why does this clear text impact the encrypted data block ? The signature part of PGP/DES tries to protect the message in whole, so perhaps the signature is at risk, but not the data
>
> Thirdly, you have to ask yourself about the perfomance tradeoffs with double encryption at transport and app layer. It might make sense for large institutional trades, we deal with retail and this would put an unacceptable overhead for really rather little return.
Why double encrypt ? If a counterparty and I agree to do app level encryption, I will not send it down an encrypted transport pipe. Also, if we are using transport level encryption, I will not use app level. Remember, there will be more than one security solution out there, but not simultaneously in use with a single counterparty.
>
> Fourthly, you would need to make sure there was a way of negotiating any app level encryption. The current "agree before" was maybe OK when the FIX community was small, but increasingly it will be used between parties that have no fixed relationship. There would need to be the opportunity to adjust between the level Charles wants and the level retail customers are happy with.
>
> Fifthly, the most common security flaws are bugs in implementation and people probs. Coming up with a new app level protocol faces both these complications.
This comment has two sides. Are you implying that we trust another companies software developers more than we trust our own ?? Are they going to do a better job simply because they are working at the transport level ??
>
> Finally, it puts a stress on FIX implementers to be encryption experts as well.
If we do as good a job as Raj did at Morgan Stanley, the FIX community will be able to pull down a reference implementation and overcome a vast majority of the hurdles you describe.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> > Fifthly, the most common security flaws are bugs in implementation and people probs. Coming up with a new app level protocol faces both these complications.
>
> This comment has two sides. Are you implying that we trust another companies software developers more than we trust our own ?? Are they going to do a better job simply because they are working at the transport level ??
I think we need to clarify between developing a security protocol and developing an implementation of a security protocol.
Determining exactly how things like key exchange and signatures are done is a dangerous thing. Even if you are using solid underlying algorithms, getting them to work securely together is certainly not guaranteed. Things like preventing replay attacks and man-in-the-middle attacks are non-trivial. It’s been said that failures here, not brute-forcing keys, is how the NSA breaks most stuff.
I do not trust anyone except academic cryptographers in developing security protocols, and only then if the said protocols have undergone academic scrutiny. I would prefer a protocol that has had extensive peer review rather than something home-grown.
This is completely different from coding implementations of protocols. I have nothing against home-grown implementations of the standards, provided they are written solidly and critical flaws like random number generation are addressed.
[ original email was from Dwight Arthur - dwightarthur@mindspring.com ]
> If we do as good a job as Raj did at Morgan
> Stanley, the FIX community will be able to pull
> down a reference implementation and overcome a
> vast majority of the hurdles you describe.
I believe that resources can be found to produce a reference implementation along the lines discussed here.