When running Transfer CFT with Central Governance, the SSL security services are automatically configured and managed. Additionally Transfer CFT with Central Governance supports the use of a FIPS Federal Information Processing Standard 140-2 -compliant library. For more information on these settings, see the Central Governance documentation.

However you must configure and manage the following services via Transfer CFT, if used:

Security concepts

File transfer security is based on the following three principles:

These forms of security are independent and must be combined to get a high level of security. TLS uses the concepts described above, and when establishing a session Transfer CFT uses a handshake protocol for authentication and key exchange as described in Establish a session.

Additionally, the following two security related subjects are described:


Privacy, also referred to as confidentiality, consists in protecting data from being revealed to parties it was not meant for. As a rule, this is accomplished by ciphering transferred data.

Two different cryptographic techniques are often used and combined:

Symmetrical encryption

Symmetrical encryption consists in using a unique key to encrypt and decrypt a message. Both connected parties then share a key that is used to encrypt and decrypt data. The task of privately choosing the key before ciphering data is more problematic as the connected parties share a single key that cannot be clearly transmitted to others

View of symetrical key

Asymmetrical encryption

Asymmetrical encryption consists in having a pair of keys where each key by itself can decrypt messages ciphered using the other key. This technique solves the problem of exchanging the key between connected parties. When two parties want to communicate using this encryption mechanism, each party publishes one of its keys and keeps the other one secret.

View of public and private key encryption

When using SSL or TLS protocols, a symmetric encryption mechanism is used to cipher data (DES, triple DES, RC2, RC4, and AES). A key used by that mechanism is generated for each session and exchanged during the handshake phase. They are transmitted using an asymmetrical encryption mechanism, which is slower but more secure (RSA) than a symmetric encryption mechanism.


Integrity consists in assuring that the received data has not been altered or modified. Generally, integrity checking is done by adding to the sent data an abstract of that data. When receiving a message, the receiver makes an abstract of the message and compares it with the one sent. If the abstracts match, message integrity is assumed to be correct. Otherwise, it is not.

The message abstract is commonly called the message digest or the hash code. The procedure used to create that hash code is called the digest function or the hash function.

When using SSL or TLS, a hash code, called MAC (Message Authentication Code), is added to each message sent. The standard hash functions used are SHA-1 or MD5.

Hash function

Hash function added for integrity check


Authentication is the process of verifying a claimed identity. The most widely used authentication mechanisms are:

  • Password request
  • Proof request

Password requests are associated with user login requests. When you have sent a login name, you are then prompted for your password.

Proof requests are associated with asymmetrical encryption mechanisms. After you have sent your public key, or any information relevant enough to get the public key, such as a certificate, you are sent a random encrypted message. If you can decrypt the message, your identity is verified because you own the unique private key associated with the public key.

Proof request

Example of test message sent with an answer message

When you use TLS and SSL protocols, the client encrypts the symmetrical key with the server’s public key. If the server can decrypt the key, the client is recognized. Otherwise, dialog is not possible and the connection is closed. When requested, the server authenticates the client through a signature process.


Signing messages is a technique that mixes both integrity and authentication. It consists in sending a ciphered hash code with the message.

When receiving a signed message, both the sender identity and data integrity are verified by decrypting the signature and comparing the result with the calculated hash code. If the hash code is correct, data integrity is accepted, and the sender is as claimed because he had the correct key to encrypt the digest.

Integrity and authentication

This example mixes both integrity and identity checks

Using FIPS

Transfer CFT supports the use of a FIPS-compliant library. FIPS, Federal Information Processing Standard 140-2, is a standard that describes US Federal government requirements for certain IT products.

Requirements include a cryptographic module used in a security system to protect unclassified information in an IT system.


Before beginning:

  • Refer to Licenses, in the openssl licenses/openssl-fips-1.2.txt directory, for redistribution terms.
  • Verify that your Transfer CFT has the FIPS option included in the key.


To enable Transfer CFT to use FIPS-compliant algorithms:

  1. Activate the FIPS compliance option in Transfer CFT key.
  2. Set the uconf parameter cft.fips.enable to YES.

Option details

  • Supported FIPS-compliant algorithms include:
    • RSA 1024-4096 bits, 3DES, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, AES-128, AES-256
  • FIPS supports the following ciphers for SSL:
    • 61: TLS_RSA_WITH_AES_256_CBC_SHA256
    • 60: TLS_RSA_WITH_AES_128_CBC_SHA256
    • 59: TLS_RSA_WITH_NULL_SHA256
    • 53: TLS_RSA_WITH_AES_256_CBC_SHA
    • 47: TLS_RSA_WITH_AES_128_CBC_SHA
  • The following non-FIPS-compliant algorithms are not supported:
    • 9: RSA DES SHA1
    • 5: TLS_RSA_WITH_RC4_128_SHA RSA RC4 SHA1
    • 4: TLS_RSA_WITH_RC4_128_MD5
  • Certificates using MD5 hashing are not accepted when FIPS is enabled.

Establish a session

To establish a session, the client and server exchange the following messages:


  • The negotiation phase is initiated when the client sends a ClientHello, indicating that the client wishes to establish a security session on the TCP connection. This sends a random number, which will be used to generate the session key, and a session identifier, the list of algorithms it is capable of using, and the maximum SSL version supported.

Server: The server responds with a series of messages:

  • It starts with a "Server Hello". This informs the client that the server has received the "Client Hello", by sending the same session number, a random number and compression algorithms, and encryption selected from those proposed by the client.
  • The server then sends a "Certificate" message.
  • This is followed by a message "Server Key Exchange", an optional message in which the server sends the client a temporary key that can be used to encrypt the message Client_Key_Exchange.
  • The server can optionally send a message-like "Certificate Request" if the client wants identified.
  • The server indicates that it has completed his series of messages with a "Server Hello Done" message.

Client: The client initiates a series of messages:

  • A Certificate message only in response to a Certificate Request.
  • A Client Key exchange message to send a pre-master key encrypted with the server's public key.
  • The customer confirms that he has accepted the certificate sent by the server (if so) by sending a message like Certificate Verify.
  • The client connects with a Change Cipher Specification type message to indicate that the following messages will be encrypted with the master key generated. (This is a key that is shared between the server and client).
  • The client ends with an encrypted “Finished” message.

Server: It responds with:

  • A Change Cipher Specification message, which indicates the transition mode encrypted with the master key generated.
  • The Finished message follows.

Supported X.509 certificate formats

Transfer CFT supports these certificate formats:

  • DER
  • PEM (base 64)
  • PKCS7
  • PKCS12

The maximum size of certificates and keys depends on the Transfer CFT version.

Transfer CFT supports a 4096-bit key length with a self-signed certificate support and automatic recognition of PEM and DER formats.

There are:

  • Certificates signed by a certification body.

They are necessary to ensure the security of exchanges with anonymous users, such as in the case of a secure website accessible to the general public. The third-party certifier ensures the user that the certificate belongs to the organization to which it is said to belong.

Certification Authorities (CA) issue these certificates linking a Distinguished Name (DN) to a public key. A DN is a series of name/value pair (such as "uid = smith"), which identifies an entity uniquely. A growing body requires the use of certificates signed by these authorities.

id = dupont, e = dupont@axway.com, cn = Albert Smith, o = Soft Axway, c = FR

The CA is responsible for issuing certificates, to assign an expiry date, as well as to revoke anything prior to that date in the event of key compromise.

  • The self-signed certificates are certificates for internal use.

They are signed by a local server and help ensure the confidentiality of trade within an organization, such as the need for an intranet. As such, it is possible to perform user authentication through self-signed certificates.

You can use software such as OpenSSL or XCA to create self-signed certificates. See Appendi x B .

Certificate chains

CA hierarchies are represented by certificate chains. A certification path is an ordered sequence of certificates between the end entity ("sheet") and the originator ("root"). The result is a certificate chain that starts at the end entity and CA ends at home.

A certificate chain describes a path of certificates from a branch to the root of the hierarchy, where each certificate is followed by the certificate was issued.

Related Links