The AS1 and AS2 specifications were developed when the desire to transport MIME encapsulated messages (carrying various types of message payloads including EDI, XML, binary, etc.) over the Internet became a viable alternative to traditional VAN connectivity. AS1 specifies the transport of payload via mail gateways supporting SMTP, while AS2 specifies the transport via the web-based HTTP protocol.
MIME (Multipurpose Internet Mail Extensions) was originally designed for formatting the content of multi-part textual (ASCII) and non-textual (binary) message bodies for email gateways, but has been adapted for use by other transport mechanisms as well. Internet MIME messages consist of two parts: headers (which describe the content) and a body (which consists 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 uses PKCS (Public Key Cyptographic Standards) to provide the mechanism for digital signatures and data encryption. In order to sign and/or encrypt a MIME message, at least one public/private key pair is needed. The public key is provided to users with whom secure communication is desired. The sender's private key is used to digitally sign a MIME message. When this message is received by the recipient, he uses the sender's public key to verify the digital signature. For encryption, the sender uses the recipient's public key to encrypt the MIME message. When the message is received by the recipient, he uses his own private key to decrypt the message. As long as the private key is protected and is accessible only by the user to which it was assigned, the recipient of a digitally signed message will know from whom the message was sent and the originator of an encrypted message will know that only the intended recipient is able to read it and it has not been tampered with in-transit.
The basis for encryption is to turn otherwise readable text into something
that cannot be normally be read, and therefore understood (without possessing
the necessary tools to decode the message). By making the text unintelligible,
encryption discourages anyone from reading or copying the payload while
it is in-transit between the trading partners. Encryption adds confidentiality
to the data content of the message and is based on two components: an
algorithm and a key. An algorithm is a mathematical transformation that
takes plain-text or other decipherable information and changes it into
unintelligible cipher text. The process of reverting the encrypted data
back to its original form is called decryption. In order to encrypt the
plain text, a key is used as input in conjunction with an encryption algorithm.
An algorithm can use any one of a large number of possible keys. The number
of possible keys each algorithm can support depends on the number of bits
in the key. For instance, if the key length is 40, then 2 to the n, where
n is the number of bits in the key, results in 1,000,000,000,000 possible
key combinations, with each different key causing the algorithm to produce
slightly different cipher output.
Sufficient key lengths must be chosen with regard to the value of the
message content so that brute-force attacks are not worth the time nor
effort compared to the value of the data being sent. Like all algorithms
that use 40-bit keys, the RC2/40 algorithm is considered to be weak encryption
by most cryptographers. Using weak cryptography offers little actual security
over sending plain text and is never recommended unless the only alternative
is no cryptography. When feasible, it is suggested that a stronger cryptographic
method such as DES or TripleDES be used instead.
Since public-key encryption algorithms are mathematically complex and are therefore considered slow, they are generally not used to directly encrypt the data content. The actual method used with AS2 is to create a symmetric key that is used to encrypt the data, and the symmetric key is then encrypted using the recipient's public-key. The encrypted data and symmetric key is then sent to the recipient. The recipient of the encrypted message then decrypts the symmetric key using his private key. After recovering the symmetric key, the recipient then decrypts the actual content payload.
A symmetric key can be randomly generated for each data transaction between trading partners. Symmetric keys generated on a per transaction basis are sometimes referred to as "session keys". Since a unique symmetric key is generated for each data transaction, and then discarded, symmetric key maintenance is not required. Each symmetric or "session" key is used only one time.
Encryption guarantees the confidentiality of a data transaction. Content integrity guarantees that the receiving trading partner gets the data in its originally sent form. Content integrity assures that no modifications (i.e., additions, deletions, or changes) have been made to the data when it is in-transit between trading partners.
Content integrity is achieved with AS2 if the sender provides with the data content, 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 from 112 to 160 bits long. The longer the hash value, the more secure it is.
One-way hash functions don't require a key, and the hash algorithm typically used is either SHA-1 (Secure Hash Algorithm 1) or MD5 (Message Digest 5). As a method to determine content integrity, the sending trading partner adds a digital signature to his data content, which includes a one-way hash value of the data content and the MIME content headers. This value is unique and "fingerprints" the transaction. The sending trading partner sends the hash value along with the data. The receiving AS2 trading partner using the same one-way hash function calculates the hash value for the received data content and the MIME content headers. 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.
References
N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka "S/MIME Version 2 Message Specification", RFC 2311, March 1998
T. Harding, R. Drummond, C. Shih, "Requirements for Inter-operable Internet EDI," February 2001.
D. Moberg, D. Brooks, R. Drummond and D. Fischer, "HTTP Transport for Secure Peer-to-Peer EDI over the Internet", January 2002.
RSA Laboratories, PKCS #7: Cryptographic Message Syntax Standard, Version 1.5, November 1993
Home - Cleo Secure File Transfer Products | Home - Cleo Mainframe Connectivity Products
About Cleo | News Room | Service & Support | Reseller Programs | Contact Us | Site Map | Search | Terms | Privacy Statement
Copyright© 2002-2008 Cleo Communications. All rights reserved.