FIX Encryption Working Group

New York, Monday July 24

Facilitator: Ryan Pierce
Townsend Analytics Ltd. /
Archipelago LLC
Introductions
 Outline
• Overview • Where We’re Going
• Deliverables • SSLv3 and TLS
• Concepts • Issues
• Business Use Models • Discussion
of FIX • Soliciting Volunteers
• Past FIX Security
 Overview

• We will design, test and create FIX security

solutions as required by industry business
needs.
• Working Group must involve people with
Business and Technical expertise.
• Current business needs should drive the
group, not technical capabilities.
 Deliverables

• Application Note(s) - Specifications

• Case studies
• Reference Implementation(s)
• Research Cryptography Vendor
Implementations
 Concepts - Confidentiality

• The message, when encrypted, should be

readable only be the intended recipients; an
intruder should not be able to read the
message.
 Concepts - Authentication

• “It should be possible for the receiver of a

message to ascertain its origin; an intruder
should not be able to masquerade as
someone else.”

Definition Source: Bruce Schneier, Applied Cryptography

 Concepts - Integrity

• “It should be possible for the receiver of a

message to verify that it has not been
modified in transit; an intruder should not
be able to substitute a false message for a
legitimate one.”

Definition Source: Bruce Schneier, Applied Cryptography

 Concepts - Non-Repudiation
• “A sender should not be able to falsely deny
later that he sent a message.”
• Digital signatures alone generally do NOT
provide non-repudiation, but they are often
good enough.
• “Accidental” disclosure of private keys
makes non-repudiation close to impossible to
achieve.
Definition Source: Bruce Schneier, Applied Cryptography
 Concepts - Algorithms

• Mathematical functions
• Algorithms can be evaluated on inherent
strength, key length, etc.
• Examples: DES, RSA, MD5
 Concepts - Protocols
• How algorithms are used
• “Series of steps, involving two or more parties,
designed to accomplish a task”
• Examples: SSL, TLS, PGP-DES-MD5
• Strong algorithms + weak protocols = low
security
• Protocols are often easier to attack than
algorithms
Definition Source: Bruce Schneier, Applied Cryptography
 Concepts - Design Criteria
• When possible, don’t be original
– Massive peer review is best the assurance of security
– Choosing cross-industry standards means availability
of 3rd party toolkits, fewer errors
• Design by layers
– Firms can choose and selectively implement their
level of security
• Cost of breaking security vs. data value
 Concepts - Transport Level
• Simple to implement via
3rd Party tools F IX
A p p lic a t io n
F IX
A p p lic a t io n

• Can be handled in engine N o rm a l F IX

or via an external proxy

F IX S e s s io n F IX S e s s io n
S e s s io n

• Messages are NOT

F IX H e a d e r F IX H e a d e r

A p p lic a tio n A p p lic a tio n

M essage M essage
T ra n s p o rt S e c u re F IX T ra n s p o rt

individually signed;
F IX T r a ile r F IX T r a ile r
S e c u r it y S tre a m S e c u r it y
F IX H e a d e r F IX H e a d e r

A p p lic a tio n A p p lic a tio n

trivial to repudiate a
O p t io n a l F I X S e c u r it y
M essage M essage

F IX T r a ile r F IX T r a ile r

transaction
E n c ry p te d ,
A u th e n t ic a te d ,
V e r ifia b le In te g r ity
D a ta

• Example: SSL, TLS

 Concepts - Message Level
• Intrusive to implement in
engine, message ordering
issues A p p lic a t io n
M essage
F IX
A p p lic a t io n
F IX
A p p lic a t io n
A p p lic a t io n
M essage

• Individually signed E n c ry p te d E n c ry p te d
A p p lic a t io n A p p lic a t io n

messages makes M essage

M essage
S ig n a tu r e
M essage
M essage
S ig n a t u r e

repudiation harder F IX H e a d e r F IX S e s s io n
N o rm a l F IX
S e s s io n
F IX S e s s io n F IX H e a d e r

• Vulnerable to Traffic
E n c ry p te d E n c ry p te d
A p p lic a t io n A p p lic a t io n
M essage M essage
M essage M essage

Analysis
S ig n a tu r e S ig n a t u r e
F I X T r a ile r F IX T r a ile r

• Example: PGP-DES-
MD5
 Concepts - Point to Point
• Difficulty: Low
• Can work at Transport B u y S id e
A

level

Authentication
Confidentiality

Integrity
• Key management is
easier
Hub C

• If a 3rd party is n
t
en at
lity
ia ion
fid ntic ity
r
Au onfi
th de
In enti ntia
te ca lity
Co uthe teg gr tio

involved, trust /
ity n
S e ll S id e A In S e ll S id e
B C

liability become issues

 Concepts - End to End
• Difficulty: High
• Must work at Message B u y S id e
A

level

Data Flow
• Key management is

Int ntica lity

Co thent rity
Au Integ
rity n
a
tio

nfi
the nti

de catio
Au nfide

nti
eg

i
harder

alit n
Co

y
Hub

• Better accountability ta
Fl
o w Da
ta
Fl
o
Da w

through long-lasting S e ll S id e
B
S e ll S id e
C

signatures
 Concepts - Combining Point to
Point, End to End
• Difficulty: Medium
• Confidentiality, B u y S id e
A

(Authentication,

Authentication
Confidentiality
Integrity) Point to Point

Integrity
r i t y io n

Au Integ
the rit
t
via Transport

Int ntica

nti y
eg

ca
the

tio
Au

n
• Additional lity
Hub C
Au onfi
t ia ion
Authentication / Integrity
th de
en at In enti ntia
n fid ntic ity te ca lity
r
Co uthe teg gr tio
ity n
A In
provided End to End via S e ll S id e
B
S e ll S id e
C

Message level signatures

 Concepts - Per Firm
• Easier to implement
• Firms must maintain
tight internal security U ser
NO
T
Si
gn

• Often models business

ed

F IX E n g in e

contracts
N O TC l o uSd i g n e d ( S ig n e d F I X S e s s io n
H e re )
R e c ip ie n t
U ser A u t h e n t ic a t e s
ed F ir m n o t U s e r s
gn
Si
T
NO

U ser
 Concepts - Per User
• More difficult to
implement
• Generally requires PKI Si
U ser gn
ed

• Provides accountability
at the individual level S ig n e d F I X E n g in e F IX S e s s io n

R e c ip ie n t
U ser

• Can be problematic as
A u t h e n t ic a t e s
U s e rs
ed
i gn
S

signatures must extend

to the trading station U ser
 How FIX is Generally Not Used
• Not a desktop protocol
• Can be difficult to
store state required for
R e ta il C lie n t
a FIX session FIX

• FIX protocol has no B ro k e r O M S

FIX
retail concepts of R e ta il C lie n t

trading history, R e t a il B r o k e r & C lie n t s

positions, account
balances, margin
 How FIX is Generally Not Used
• Generally not Person
to Person
• Overhead of T ra d e r FIX B ro k e r

maintaining that many T ra d e r FIX B ro k e r

sessions is too much T ra d e r FIX B ro k e r

of a burden T ra d e r FIX B ro k e r
B U Y S ID E S E L L S ID E
 How FIX is Used
• Business to Business B ro k e r

• Contracts are often O M S

B ro k e r

written on a firm to T ra d e r
FI
X
B ro k e r

firm basis, so liability T ra d e r

B ro k e r
S E L L S ID E
O M S

issues may be easier to T ra d e r

FI
control T ra d e r

B U Y S ID E
X B ro k e r

B ro k e r
O M S
B ro k e r

B ro k e r
S E L L S ID E
 How FIX is Used
• Firm to Hub
• Hub might introduce T ra d e r B ro k e r

liability issues
T ra d e r B ro k e r
O M S O M S
FIX
FIX
T ra d e r B ro k e r

• Rewriting, if done at T ra d e r

B U Y S ID E F IX N E T W O R K
B ro k e r
S E L L S ID E

the hub, makes

FIX
FIX
T ra d e r B ro k e r

message signatures T ra d e r
O M S O M S
B ro k e r

difficult
T ra d e r B ro k e r

T ra d e r B ro k e r

B U Y S ID E S E L L S ID E
 Past FIX Security - PGP-DES-
MD5
• Point to Point
F IX L o g o n

• PGP session key

Header

P G P E n c ry p te d
a n d S ig n e d
F IX L o g o n

exchange /
S e s s io n K e y
H eader
F I X T r a ile r
P G P E n c ry p te d
a n d S ig n e d

authentication in logon A u t e h t ic a t io n
S e s s io n K e y

F I X T r a ile r

O K
• DES data encryption C o m p u te
a n d V e r ify
F IX H e a d e r F IX H e a d e r " S ig n a tu r e "

• MD5 integrity A p p lic a t io n

D a ta
F IX T r a ile r
E n c ry p te d
A p p lic a t io n
D a ta D e c ry p t

checking “signature” D a ta
M essage
I n t e g r it y
" S ig n a t u r e "

based on message and

F I X T r a ile r
M essage O K

session key
 Strengths of PGP-DES-MD5

• Currently is best of breed

• Provides reasonable level of security
• Widely implemented; has market share
• Has reference implementation
 Faults of PGP-DES-MD5
• Implementation is very intrusive to the FIX
engine
• Repudiation is trivial; a shared secret “signs”
the message
• Depends on 56-bit DES which is weak
• Message reordering issues (uses CBC)
• Business needs could be handled by transport
level security
 Where We’re Going - First steps
• FIX Engine to Engine Confidentiality /
Authentication / Integrity
• Business case: running FIX over the Internet
without proprietary or hardware VPN
• Technologies: SSLv3 / TLS
• Replacement for PGP-DES-MD5
• Existing SSLv3 Reference Implementation
 Where We’re Going - Possible
Next Steps:

• Making repudiation of transactions harder

• Firm-based message signatures
• User-based message signatures, PKI
– Difficult due to the multitude of trading front
ends which may not know anything about FIX
• Do the business cases for these exist?
 SSLv3 and TLS
• SSL is the protocol used for WWW security
• Authentication done via a certificate per server
or client, signed by a CA
• Both negotiate security based on capabilities
of each side
• SSL, TLS libraries talk to TCP sockets, verify
certificates, handle security issues for you;
library is largely a black box
 Integrating SSLv3 or TLS in a
FIX Engine

• Note: It can be done via an external proxy.

• Buy or acquire free library
• Modify TCP session initiation code to
verify identities of certificates
• Modify socket read / write calls to use SSL
or TLS library read / write calls
• No FIX session or application logic changes
Issues to Address - SSLv3 vs. TLS

• Both are nearly identical; differences are

largely political
• SSLv3 is a Netscape-owned protocol
• TLS is an IETF protocol
• TLS can negotiate down to SSLv3
• SSL has buzzword status
• Recommend one or both?
 Issues to Address - RSA vs.
Diffie-Hellman and DSS

• Most CA infrastructure is based around

RSA
• RSA is covered by patent; Diffie-Hellman
and DSS are public domain
• DSS may enjoy special US Govt. status
• RSA patent expires September 20, 2000
• Recommend one or both?
Issues to Address - RC4 vs. 3DES
• 3DES needed if using Diffie-Hellman and DSS
• 3DES has effective key length of 112 bits,
slower
• RC4 generally used with a key length of 128
bits, faster
• RC4 is an RSA-owned Trade Secret
• What should we recommend?
 Issues to Address - FIX vs.
FIXML
• How to handle message-level signatures?
• Let FIX message signature work for embedded
FIXML?
• Define XML construct of FIX message
signature?
• Rely on other cross-industry E-Commerce
initiatives to define standard for XML data
signatures?
 Issues to Address - Reference
Implementations
• Existing open source implementation: Poppy,
written by Hugh Emberson of Westpac
Banking Corporation, Australia
• Available on FIX web site, Encryption
working group Archives
• Currently SSLv3 only, supports only one
ciphersuite (RSA, RC4 128 bit)
• Currently Unix C only
 Issues to Address - Identifying
Certificates
• Use of Common Name in certificate
– Requires the CA to know FIX business rules and
place the CompID in that field
– Largely incompatible with public CA’s
– Great for things like FIX routing networks where
there is centralized assignment of CompIDs.
– Requires coordination of CompID which has
never been done industry-wide
 Issues to Address - Identifying
Certificates

• Use of Fingerprint, or Issuer and Serial

Number
– Allows firms to use CA’s not knowledgeable of
FIX
– Clients changing certificates must notify their
trading partners
 Issues to Address - CA Models
• Central CA (or group of CA’s) issues
certificates
• One party in a FIX connection issues a
certificate to the other
• Each party in a FIX connection maintains their
own CA
• Many CA’s make verifying signatures and
checking Certificate Revocation Lists hard
Discussion
Soliciting Volunteers