TTM Authentication and Encryption Overview
Many banks require order and fill data to be encrypted before being passed over the Internet or private networks. This typically requires costly VPN tunnels that can cause latency in the system. As an alternative to VPN-based encryption, TTM has implemented AES/3DES encryption, along with two authentication schemes (peer-to-peer and anonymous) for the TCP sessions between a Remote Client and Remote Host Deamon.
Remote Clients and Remote Host Daemons support anonymous authentication which uses a simplified version of the STS (Station-to-Station) protocol. This authentication scheme assumes that public keys are automatically installed with the X_TRADER software, and that the certificates and private keys on the X_TRADER Remote Host are installed and managed by the Certificate Authority (CA) administrator. For more information, refer to TTM Anonymous .
Because authentication and encryption are performed on a per TCP basis, orders and fills can be authenticated and encrypted, while prices are authenticated, but left unencrypted (for performance reasons).
TTM provides authentication and encryption between two a Remote Client and Remote Host Daemon. It does not provide end-to-end (e.g. X_TRADER to Gateway) authentication or encryption.
TTM encryption supports the 128 bit keysize or 256 bit keysize AES cypher, as well as the 192 bit keysize 3DES cypher. Although typically faster than VPN encryption, because encryption requires compressing, encrypting, decrypting, and then decompressing data, there is some latency.
|Cypher||Added One-way Latency|
AES 128 bit
AES 256 bit
3DES 192 bit
Required Parameter Settings
Encryption requires the following parameter settings:
- Remote Clients and Remote Host Daemons must have encryption_enabled set to true in the ttmd.cfg file.
- If the X_TRADER Remote Hosts should use peer-to-peer authentication rather
than the default anonymous authentication, then the key_exchange_method parameter
must added to the <General> section
of the ttmd.cfg file
and set to sts_full.
The CA administrator must ensure that all clients connecting to
the X_TRADER Remote Host have the necessary certificates. For more
information about using peer-to-peer encryption on an X_TRADER Remote
Host, refer to Using Peer-to-Peer Authentication
on X_TRADER Remote Hosts.
If the X_TRADER Remote Hosts should use the default anonymous authentication, you do not need to add the key_exchange_method parameter. If you choose to add the key_exchange_method parameter, set the value to sts_half.
- Optional: If the 3DES encryption algorithm is preferred over the default encryption algorithm (AES), then the encryption_algorithm parameter must be added to the <General> section of the ttmd.cfg file for Daemons.
- Optional: If the 256 bit keysize is preferred over the default keysize (128), then the encryption_key_length parameter must be added to the <General> section of the ttmd.cfg file. Use a 256 bit keysize when the encryption_algorithm is set to 3DES.
- Compression is automatically enabled, even if compression_level = false.
TTM uses standard, readily available Public Key Infrastructures (PKIs) such as VeriSign, Thawte, or DigiCert. PKI requirements vary depending on the authentication type:
In Anonymous authentication/encryption (for X_TRADER Remote Hosts) PKIs must support the following:
- creation of private keys and certificate authority keys
- creation of certificate requests
- signing of certificate requests
- distribution of private keys, private certificates, and certificate authority certificates.
X_TRADER workstations running TTM 3.2.1 or later already include the required TT Root Public Certificate.
Encryption Related Log Entries
The following log messages may be logged to the ttmd.log file:
|Keysize Mismatch between two TTM Wan Routers|
Encryption key length mismatch. Disconnecting Neighbor <router name>.
|Keysize Mismatch between the Remote Client and Remote Host Daemon|
Locally configured encryption key length does not match negotiated value. Using key size <Remote Host Daemon Setting>.
Note: this message appears only in the Remote Client’s log file.
|Encryption Algorithm Mismatch between two TTM Wan Routers|
Encryption algorithm <cipher name> mismatch. Disconnecting Neighbor <router name>.
|Encryption Algorithm Mismatch between the Remote Client and Remote Host Daemon|
Locally configured encryption algorithm does not match negotiated value. Using algorithm <Remote Host Daemon setting>.
Note: this message appears only in the Remote Client’s log file.
|Encryption_enabled mismatch between two TTM WAN Routers|
Neighbor <router name> expects encryption, but local router does not. Disconnecting.
Neighbor <router name> does not expect encryption, but local router does. Disconnecting.
|Encryption_enabled is set to false on the Remote Host Daemon but true on the Remote Client|
Could not open RSA private key file.
Local certificate failed verification. Please contact your Certificate Authority.
Initialization of Encryption Context failed. Encrypted communication is not possible.
|Encryption_enabled is set to true on the Remote Host Daemon but false on the Remote Client|
None. Encryption is enabled on the Remote Client Daemon, even if encryption_enabled = false for the Remote Client.
|The encryption_algorithm is 3des, but the encryption_key_length is not 256.|
Encryption algorithm 3DES does not support key size other than 256 bit.
The local certificate has expired
Certificate for <certificate name> failed to verify: Error verifying certificate: certificate has expired.
|Certificate will expire in 14 days or less|
Local certificate for <certificate name> will expire in 14 days or fewer. Expiry date: <date string>. Please contact your Certificate Authority for renewal.
|A client using TTM 2.1.1 or earlier attempted to connect to a daemon that uses encryption.|
Invalid message received during Encryption STS handshake (pre-2.1.2 client trying to connect?). Encryption is enabled on this remote daemon, but it does not appear the client has encryption enabled. Disconnecting
|TTM received a PEM file (usually the private key) that is encrypted with a password.|
The private key file is encrypted. TTM cannot read encrypted PEM files.
|TTM requires a private key and it was not found in any PEM file in the configuration directory.|
No usable private key found
|None of the local certificates in the directory can be used for STS. This could occur if root certificates are missing or there are outdated files.|
No valid local certificate found
|The public key included with the local certificate is corrupt.|
Local certificate does not have a valid public key
|The directory could not be opened. This is a rare case where the directory may not exist or has restricted access privileges.|
Unable to open directory '<dirname>'. No X509 documents will be loaded from this directory.
|A root certificate was not found in any of the PEM files in the configuration directory.|
No valid root certificates found. Encrypted communication is impossible.
|There are multiple valid certificates.|
Multiple valid local certificates exist. Choosing certificate for '%s' because its expiration date is furthest from now.
|There are multiple certificates which have the Issuer extension set to true where the common name is the same as the issuer name and is shared between the certificates.|
Infinite loop detected creating certificate tree. It is probable there are multiple distinct certificates which have the same Common Name and Issuer Name. Current certificate Common Name is '<name>'.
|TTM detected an Elliptic Curve key in the local certificate.|
Certificate for <name> has unsupported key.
|A self-signed (usually root) certificate could not be added to the certificate store and will not be used for verification. A common cause of this is having the same root certificate file in the directory twice.|
Could not add self signed certificate: <reason>
A client is connected and encrypted using Anonymous Authentication and Encryption (half STS).
Proxy client advertising HALF STS
A 3.1.X or 3.2.0 client that does not have encryption parameters is trying to connect to a 4.2.2 or later Remote Host that is configured for encryption and has allow_insecure_connections disabled.
Proxy client attempting to login with no encryption parameters while XTRH is configured for encryption only. Disconnecting!
A 3.1.X or 3.2.0 client that has encryption enabled is trying to connect to a 4.2.2 or later Remote Host.
Proxy client advertising FULL STS while this is not supported. Disconnecting!
A 3.1.X or 3.2.0 unencrypted client is connecting to an encrypted 4.2.2 or later Remote Host that has allow_insecure_connections enabled. The result is an unencrypted connection.
Proxy client attempting to login unencrypted, connection will be unencrypted.
A 4.2.2 or later client that has encryption disabled is trying to connect to a 4.2.2 or later Remote Host.
Proxy client advertising HALF STS, encryption is disabled. Disconnecting!