High-level Security Requirements Statement

[fplpo_x]

Imported from previous forum

[fplpo_x]

[ original email was from Charles Blauner - blauner_c@jpmorgan.com ]
Folks;

I have been working with a small group of firms,
mostly here in NYC, on the issues of FIX security
and I wanted to post to the larger group the set
of basic security requirements we have developed.

It is our group’s intention to then develop a proposal for evolving FIX in a way that we think meets the stated requirements. We also plan to use these requirements to contrast whatever solution we propose with solutions based on transport layer (i.e., SSL) security mechanisms and the current state of FIX security.

Please provide feedback on the requirements to me
directly or through this discussion group.

Charles Blauner
JP Morgan

High-level FIX Security Requirements

Basic Functionality:

1. All sensitive data must be cryptographically protected (encrypted)
   from end system to end system.
   • Note; not all data requires encryption
2. All back-end systems must be able to directly verify the signature
   of the message sender (end-user).
   • Identification/message authenticity must be verifiable and
     must not rely on assertions made by intermediary systems
3. A dynamic security negotiation mechanism, capable of securely
   exchanging capabilities and correctly selecting protection
   mechanisms based on local policy and the capabilities of the
   peer entity should be supported.
   • The system must continue to support the statically configured
     approach of today’s system.
   • Any negotiation mechanism should be based on IETF standards
4. Session-keys should be dynamically negotiated at set-up time
   • System should support re-keying dynamically during an active
     communications session
5. System should support strong encryption including algorithms using
   keys of 128 bits or longer
   • 56-bit DES should be considered the minimal/common algorithm
     to insure the interoperability of different vendors FIX
     implementation
   • Beyond DES vendors should be free to support any number of
     additional encryption algorithms
6. All transactional messages must be digitally signed using either RSA
   or DSA
   • Signature algorithms should be negotiated at the same time
     encryption algorithms are being negotiated
   • DSA should be considered the minimal/common algorithm algorithm
     to insure the interoperability of different vendors FIX
     implementation
7. Certificate status must be checked before transactionscan be authorized
   • Systems should be architected to allow for various status
     checking models including Certificate Revocation Lists (CRLs),
     Online Status Checking Protocol (OCSP), etc.
8. System must be capable of verifying policy identifiers in certificates
   to determine their applicability.
9. Signers should include a signing time attribute with all signed messages
   10.Provisions must be made for secure storage of evidence

Architectural Requirements:

1. Product’s should use a well specified interface to encapsulate
   encryption
   services and isolating the system from specific encryption algorithms to

   facilitate algorithm roll-over

2. Systems must allow end-user firms to pick their own encryption providers

   • I.e., built using a standards based pluggable framework such
     as CDSA

3. Systems should support LDAP directories and the IETF PKIX standards

4. Systems should be based on existing open systems standards and avoid
   proprietary solutions

5. System must be based on X.509 Version3 certificates

6. System must allow for both bilateral cross-certification and rooted
   hierarchies (e.g., SIRCA)

7. System must allow firms to leverage their existing PKIs

8. System security must not depend on the underlying network

   • No assumptions can be made about the use of secure/private
     networks

9. System security must not depend on the underlying operating systems
   10.System must be capable of operating with hardware cryptographic
   devices (e.g. chip cards, PC cards).

---

[scott.atwell]

The following are my thoughts with regards to the Encryption F.I.X. Working Group effort:

Currently most firms have implemented FIX using one of three methods

• Cleartext (no encryption) (tag 98=0)
• "Standard" DES in ECB mode (tag 98=2)
• PGP-DES-MD5 combination (tag 98=5)

Implementing “Standard” DES in FIX was challenging because it was never clearly documented how it should be implemented. Specifically ECB mode was assumed and ambiguity revolved around how to deal with any bytes left over after implementing the cipher against 8 block chunks (i.e. leave them in the clear which is what most firms have done, pad with SOH and encrypt, pad with null, etc). Thus even though straight DES is “simpler” than PGP-DES-MD5 it could be argued that in some cases it was more challenging to implement because there wasn’t a good specification available nor a reference implementation. Simple issues such as a list of where one should go to find/acquire a compatible DES library were never documented. From a technical standpoint, straight DES is not very desirable due to lack of electronic key exchange and moderately weak crypto strength.

The current PGP-DES-MD5 is in use by many firms and from a technical standpoint is superior to standard DES as it involves the random generation and use of a different session-level key each day and provides a digital signature to serve as a sort-of cryptographic checksum for each message. It has been argued that the current manual exchange of public keys is a significant drawback to this process, however, in reality, I’ve never seen that as a significant issue in terms of use of FIX between money managers and broker/dealers (we maintain over 25 PGP-DES-MD5-based FIX sessions). It was moderately complex to integrate the requirements of PGP-DES-MD5 into one’s FIX engine’s source code, but the reference implementation and documentation provided made this do-able. Many of us simply compiled the reference implementation source code directly, added the DES and MD5 libraries, and added calls to the reference implementation code modules as appropriate within our FIX engines. For those of us in the U.S., we were able to obtain the PGP library from ViaCrypt (now PGP, Inc.) for $75-200 per FIX engine and international sources of PGP are available.

There is definitely an opportunity to establish a more secure and effective authentication/encryption scheme for FIX. It is important that we establish a scheme (or schemes) which effectively balances the need for the crypto strength and infrastructure with the need for simplicity. We must make sure that any new encryption methods proposed can easily be incorporated into existing and new FIX systems.

The following are my requirements related to this effort:

• Strong crypto (greater than 56 bit)
• Exportable or at least legally implementable outside of the U.S. (suggestions for how this can be done should be documented)
• Low cost to implement ($500 max per FIX engine)
• Minor to moderate coding changes required to existing FIX engines
• Capable of being implemented on Windows NT and various Unix systems (Solaris, SunOS, HP-UX, etc) at a minimum
• Capable of being implemented by FIX engines written in C, C++, and Java at a minimum
• Capable of being implemented without a complex Public Key Infrastructure (i.e. standalone FIX server). A more sophisticated solution involving a full-fledged PKI should be something which one could grow into vs. being mandatory.
• An implementation which ensures that data transmitted by the machine running the FIX engine is encrypted over the wire (i.e. encrypted even over internal networks therefore not dependent upon a middleman proxy server or hardware-level encryption)
• Clearly documented description of the scheme and a reference implementation understandable and implementable by non-data security experts

I am confident that this Working Group which combines data security experts with FIX protocol experts will recommend an optimal security solution for use with the FIX Protocol.