Sign in

Cryptographic Services

  • Updated

This section provides information about the cryptographic services that can be used with your VersaLex system. The VersaLex products support six common cryptosystems: SSL/TLS, SSHv2, S/MIME, XML, OpenPGP, and FIPS 140-3.

  • SSL/TLS is supported through FTP, HTTP, OFTPv2, and SMTP.
  • SSHv2 is supported through SSH FTP. 
  • S/MIME is supported through AS2/HTTP, AS3/FTP, OFTPv2, and RNIF/HTTP.
  • XML is supported through AS4/HTTP, ebXML/HTTP, and mailbox-level packaging.
  • OpenPGP is supported through mailbox-level packaging.
  • FIPS 140-3 is layered on top of all the other cryptosystems.

The following describes the supported cryptographic services, as well as encryption, content integrity, and signatures.

Cryptographic services overview

SSL/TLS

Secure Sockets Layer (SSL) and the newer Transport Layer Security (TLS) provide a secure connection over any TCP/IP protocol using a combination of cryptographic processes.  The initial handshake between client and server negotiates a version and cipher.  RFC 8446 specifies the latest TLS version. 

SSHv2

Secure Shell 2 is a secure communications protocol that encompasses several layers of architecture, including transport, authentication, and connection.  Public key, cipher, key exchange, and hash algorithms are negotiated between client and server at the beginning of each connection.

S/MIME

Internet MIME (Multipurpose Internet Mail Extensions) messages consist of two parts: headers (describing the content) and a body (consisting of the actual data content or payload). MIME was not designed to provide for the application of security services, therefore S/MIME (Secure/Multipurpose Internet Mail Extensions) was created as a format and protocol for applying authentication, message integrity, non-repudiation (through the use of public key cryptography) and confidentiality (using encryption) to the Internet MIME message.

S/MIME is supported by transport mechanisms in one of either two versions: S/MIME v2 or S/MIME v3. The most notable difference between the two is that S/MIME v3 supports a wider variety and more secure set of encryption algorithms. The Cleo products support S/MIME v3; however, it is important to know which algorithms are supported by your trading partners before deciding upon the specific algorithms for both signing and encryption.

XML

XML Encryption and XML Signature are published recommendations of the World Wide Web Consortium (W3C). These recommendations define the syntax and processing rules for encrypting and signing data. Generally, the encrypted symmetric key is contained within the EncryptedKey element and the encrypted data is contained within the EncryptedData element. See http://www.w3.org/TR/xmlenc-core for detailed information regarding XML encryption. For digital signing, the Signature element is the primary element for encapsulating the digital signature. See http://www.w3.org/TR/xmldsig-core for detailed information regarding XML signatures. 

OpenPGP

OpenPGP is a non-proprietary protocol for encrypting using public key cryptography. The OpenPGP protocol defines standard formats for encrypted messages, signatures, and certificates for exchanging public keys. See RFC 4880 for detailed information on the OpenPGP Message Format. 

FIPS 140-3

The Federal Information Processing Standard (FIPS) 140-3 is a U.S. government standard that defines minimum security requirements for cryptographic modules in information technology products.  NIST oversees validation of modules for FIPS compliance.  The FIPS edition of VersaLex provides a FIPS 140-3 compliant solution.

NOTE: FIPS 140-2 is being deprecated for the newer FIPS 140-3 standard.  During this transition, FIPS 140-2 certifications are not being renewed.

Signing and encryption: general overview

In order to sign and/or encrypt a message, at least one public/private key pair is needed. The public key is provided to users who want secure communication. The sender's private key is used to digitally sign a message. When this message is received, the sender's public key is used to verify the digital signature in order to prove that the message originated with the sender. 

For encryption, the sender uses the recipient's public key to encrypt the message. When the message is received, the recipient uses the recipient's own private key to decrypt the message. As long as the private key is protected and is accessible only by the originator, the recipient of a digitally signed message is able to confirm the originator of the message and both parties will be assured that the message has not been compromised.

Content integrity through digital signatures (signing)

Encryption guarantees the confidentiality of a data transaction.  Content integrity guarantees that the receiving trading partner gets the data in its originally sent form, ensuring that no modifications have been made to the data when it is in transit between trading partners.

Content integrity is achieved if the sender provides a digital signature, which includes an integrity control value. This value can be computed by using an appropriate cryptographic algorithm to fingerprint the data content. These cryptographic algorithms are called one-way hash functions or message integrity checks. Unlike encryption algorithms, however, one-way hash functions cannot be reversed or decrypted. One-way hash functions are constructed such that the probability is infinitely small that some arbitrary piece of plain-text can be hashed to a particular value, or that any two pieces of plain-text can be hashed to the same value. One-way hash values are usually 112 bits or more. The longer the hash value, the more secure it is. 

One-way hash functions do not require a key. Common hash algorithms are SHA-1 (Secure Hash Algorithm 1), which generates a hash value of 160 bits, MD5 (Message Digest 5) which generates a hash value of 112 bits, and SHA-2 (aka SHA-256), which generates a hash value of 256 bits. To determine content integrity, the sending trading partner adds a digital signature to the data content, which includes a one-way hash value of the message. This value is unique and fingerprints the transaction. The sending trading partner sends the hash value along with the data. The receiving trading partner, using the same one-way hash function, calculates the hash value for the received data message content. If the received hash value matches the calculated hash value, then the receiving trading partner is assured that the data content has not been tampered with or altered in any way.

Encryption of zip files

Within the VersaLex LCOPY command, it is possible to encrypt and decrypt zip archive files according to the AES encryption standard (128-bit, 192-bit, and 256-bit).  Refer to http://www.winzip.com/aes_info.htm for further information on the AES-encrypted ZIP files. To encrypt or decrypt, certain parameters must be specified on the LCOPY command. See the editor dialog for the LCOPY command.

The Use-Password parameter is optional. When this parameter is set to True, a password must be specified. The length of the password determines the strength of the AES encryption key. Passwords with a length of less than 8 characters are invalid as they are too weak. Passwords with a length between 9 and 32 characters have a 128-bit key, which is the weakest. Passwords with a length from 33 to 48 characters have a 192-bit key, and passwords with a length from 49 to 64 characters have a 256-bit key, which is the strongest.

The security of your data depends not only on the strength of the encryption method but also on the strength of your password, including factors such as length and composition. There are also measures that you can take to ensure your password is not disclosed to unauthorized third parties. If you type in the LCOPY command directly from the freeform editor of the Action tab, any password data will be shown in clear-text. For the highest security when typing your password use the editor dialog box (which will not echo the clear-text password); or enter the LCOPY command, double-click on the new command to display the editor dialog box, and then click OK. After you click OK, the password is encrypted and cannot be observed by unauthorized parties. 

When using the freeform editor, if a password has an embedded space, you must use a \s to represent the space within the command. If you leave an embedded space in the password, the command will not be parsed correctly. However, if you use the editor dialog box, embedded spaces are properly handled automatically. In general, when typing commands without using the editor dialog box, you must use special escape sequences to identify certain characters:

  • \s: space
  • \t: tab
  • \n: newline
  • \r: carriage return
  • \\: slash

To disable zip file encryption, set the Use-Password parameter to False or leave the field empty.

Related articles

Comments

0 comments

Please sign in to leave a comment.