Imported from previous forum
[ original email was from Alex Lim - mwlalex@sgx.com ]
Hi, I am looking for updated info describing the information security controls that are in place within FIX. The controls should address security objectives like confidentiality (encryption), integrity (message digest), authentication (userid/password handling and digital certificates) and non-repudiation (digital signatures).
One implementation issue that I am checking out for my organization is that the FIX protocol does not cater for invalid logon due to expired user account.
I would appreciate to hear any comments or suggestions on this. However, I am new to FIX and hope all of you could bear with me if I am slow in grasping the concepts. TIA !
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Hi, I am looking for updated info describing the information security controls that are in place within FIX. The controls should address security objectives like confidentiality (encryption), integrity (message digest), authentication (userid/password handling and digital certificates) and non-repudiation (digital signatures).
First, user/password really isn’t a part of the FIX protocol. FIX isn’t designed as an end-user protocol, but rather is a B2B protocol. The primary concern with FIX is firm-to-firm security, not authenticating individual end-users.
The current officially-approved PGP security mechanisms are:
-
DES ECB. This is a symmetric key system, with the key decided out of band.
-
PGP-DES-MD5. In this system, PGP keys are used to perform an authenticated key exchange, and DES in CBC mode is used for confidentiality while MD5 is used as part of a hash function, the inputs of which are the secret session key and the ciphertext.
While these approaches address authentication, confidentiality and integrity, they do nothing to address non-repudiation. First, I’d like to state that non-repudiation, according to most security professionals, is impossible to achieve. What we’re really talking about doing is making repudiation of a transaction much harder. PGP, in this case, is NOT used to provide individual transaction signatures. The MD5 hash can be computed by either party, so no cryptographic protection against fraudulent repudiation exists.
The current project of the Encryption Working Group is to investigate and standardize upon SSLv3 and/or TLS for engine to engine security. This provides for certificates defining identity on a per-session basis, but similarly does nothing to make repudiation more difficult.
The only attempt to my knowledge to make repudiation more difficult through digital signatures of FIX messages was done by EMX. (I’d be interested if anyone else has done something similar.) This business function is something that the Encryption Working Group will consider after standardization of SSLv3 and/or TLS has been completed.
[ original email was from Alex Lim - mwlalex@sgx.com ]
Thanks, Ryan.
With regards to using PGP keys for authentication, is this a common practice in the financial industry? If it is, is also a norm to expire the keys after perhaps 1-2 years? I am curious how the keys are being managed …
> > Hi, I am looking for updated info describing the information security controls that are in place within FIX. The controls should address security objectives like confidentiality (encryption), integrity (message digest), authentication (userid/password handling and digital certificates) and non-repudiation (digital signatures).
>
> First, user/password really isn’t a part of the FIX protocol. FIX isn’t designed as an end-user protocol, but rather is a B2B protocol. The primary concern with FIX is firm-to-firm security, not authenticating individual end-users.
>
> The current officially-approved PGP security mechanisms are:
>
> 1. DES ECB. This is a symmetric key system, with the key decided out of band.
>
> 2. PGP-DES-MD5. In this system, PGP keys are used to perform an authenticated key exchange, and DES in CBC mode is used for confidentiality while MD5 is used as part of a hash function, the inputs of which are the secret session key and the ciphertext.
>
> While these approaches address authentication, confidentiality and integrity, they do nothing to address non-repudiation. First, I’d like to state that non-repudiation, according to most security professionals, is impossible to achieve. What we’re really talking about doing is making repudiation of a transaction much harder. PGP, in this case, is NOT used to provide individual transaction signatures. The MD5 hash can be computed by either party, so no cryptographic protection against fraudulent repudiation exists.
>
> The current project of the Encryption Working Group is to investigate and standardize upon SSLv3 and/or TLS for engine to engine security. This provides for certificates defining identity on a per-session basis, but similarly does nothing to make repudiation more difficult.
>
> The only attempt to my knowledge to make repudiation more difficult through digital signatures of FIX messages was done by EMX. (I’d be interested if anyone else has done something similar.) This business function is something that the Encryption Working Group will consider after standardization of SSLv3 and/or TLS has been completed.
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> With regards to using PGP keys for authentication, is this a common practice in the financial industry? If it is, is also a norm to expire the keys after perhaps 1-2 years? I am curious how the keys are being managed …
I really can’t say if PGP is common in the financial industry in anything other than FIX.
The straight DES approach has issues because firms disagree on certain things, like how to handle the last encryption block. PGP-DES-MD5 is rather popular for FIX encryption, largely because I believe it is the only FIX security model that came with a useable code implementation, so interoperability is much easier.
I really think issues like key size, key expiration, CRLs, CA certificate issuing policies, and key management are well outside the scope of the FIX spec. Firms configure PGP in accordance with their firm’s security policy; only the actual authentication and key exchange using PGP is governed by the FIX spec.
[ original email was from Alex Lim - mwlalex@sgx.com ]
ok, that’s clearer for me now, thks alot !!
> > With regards to using PGP keys for authentication, is this a common practice in the financial industry? If it is, is also a norm to expire the keys after perhaps 1-2 years? I am curious how the keys are being managed …
>
> I really can’t say if PGP is common in the financial industry in anything other than FIX.
>
> The straight DES approach has issues because firms disagree on certain things, like how to handle the last encryption block. PGP-DES-MD5 is rather popular for FIX encryption, largely because I believe it is the only FIX security model that came with a useable code implementation, so interoperability is much easier.
>
> I really think issues like key size, key expiration, CRLs, CA certificate issuing policies, and key management are well outside the scope of the FIX spec. Firms configure PGP in accordance with their firm’s security policy; only the actual authentication and key exchange using PGP is governed by the FIX spec.
>
>