Imported from previous forum
Is there any PKI enabled FIX solutions? I mean solutions with functions like digital signatures, encryptions, certificate based authentication, transactions, etc.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Is there any PKI enabled FIX solutions? I mean solutions with functions like digital signatures, encryptions, certificate based authentication, transactions, etc.
Note: We have an Encryption discussion board, and working group, specifically devoted to security.
At present, the only "standardized" encryption methods are DES in ECB mode, where keys are communicated out-of-band, and PGP-DES-MD5.
First, note that PGP-DES-MD5 does not do digital signatures. The PGP part is used solely to authenticate a symmetric key exchange, and the FIX Signature field is used for what amounts to a symmetric MD5 checksum incorporating the shared secret. Hence one doesn’t even have to claim private key compromise to repudiate a transaction.
The Encryption Working Group is looking strongly at SSLv3 and/or TLS to provide point-to-point authentication, integrity, and confidentiality. SSLv3 and TLS are both PKI-based. However, certificates are issued to engines, not users, so it is one engine authenticating another engine. It is point-to-point, so integrity and authenticity cannot be established through a message routing hub. And, like PGP-DES-MD5, messages are not individually signed. But the advantage here is that it can be bolted onto an existing engine, or implemented through a tunnel proxy which involves no changes at all to the FIX Engine.
After SSLv3/TLS are standardized, the next steps are to look at per-message signatures, if there are business needs for them.
EMX in Europe has implemented a proprietary security model based around SSLv3 and RSA signatures of messages, signed by the FIX Engine. As EMX operates with a hub and spoke business model, SSLv3 protection only extends from the client to the hub, not end-to-end. RSA signatures on messages, validated by EMX before forwarding, are carried through to the other party, who can validate the originator, thus making the security end-to-end. In theory, a compromise of the EMX hub would result in the attacker not being able to modify legitimate messages or fraudulently originate messages. (Of course this depends entirely on whether EMX participants actually validate the signatures of messages they receive.)
Please let me know if you (or anyone else) are interested in participating in the Encryption Working Group.