Overview

Approaching the AS1, AS2 and AS3 protocols (collectively referred to as "ASx" herein) can be a daunting experience for someone without any file transfer experience. On the other hand, someone with an understanding of the transport protocols (SMTP, POP3, HTTP, FTP and SSL/TLS) and/or public-key/private-key encryption (such as SMIME or PGP) should find some familiar ground.

ASx Protocols Provide Similar File Encryption to PGP, SMIME or Other Encrypted File Methods

The ASx protocols use a subset of SMIME ("Secure MIME") to sign and encrypt files. SMIME is a public/private-key encryption technology based on SSL certificates. Many email clients implement SMIME to encrypt and decrypt email messages and attachments, but the ASx implementation of SMIME is specific enough to consider ASx clients and SMIME-enabled email clients incompatible.

Similar public/private-key technology can be found in OpenPGP (which uses simple keys rather than SSL certs to sign and encrypt) and many lesser-known technologies such as "strongly authenticated, encrypted zip files". However, any public/private-key implementation which does not carry an AS1, AS2 or AS3 mark should be considered incompatible with ASx technology because the ASx protocols are quite strict.

ASx Protocols Provide Superior Receipts to PGP, SMIME or Other Encrypted File Methods

The primary advantage of ASx over other public/private key file encryption schemes is that the ASx protocol includes an "MDN" receipt mechanism that proves to the sender that the designated recipient of an ASx message actually received and decrypted the message and verified the identity of the sender.

An MDN ("message disposition notification") receipt is a direct extension of the "delivery receipts" you may have seen or used in your favorite email client. Under AS1 MDNs may be returned via email like any other delivery receipt, but under AS2 and AS3, MDNs may be returned via the HTTP and FTP protocols, respectively.

Regardless of the actual ASx protocol used, each MDN can be cryptographically signed by the recipient of an ASx message and lets the original ASx message sender know the recipient performed three important actions:

• Received the message
• Decrypted the message (if the ASx message was encrypted)
• Validated the sender's signature (if the ASx message was signed)

  MDNs also provide cryptographic hash information about the file sent so the sender can verify that the recipient actually received the file the sender thought they sent.

  ASx Protocols Provide Standards-Based "Non-Repudiation", "Pedigrees", etc.

  In the file transfer arena, "non-repudiation" is a term that means someone can prove who sent a file, who received a file and that the contents of the file were not changed between sender and recipient. In practice, "who sent" and "who received" are questions answered by authentication credentials ranging from usernames and passwords to certificates and keys. The "not changed" question is almost always answered by a cryptographic-quality hash.

  However, there is really a fourth piece to the "non-repudiation" puzzle: the record of the "who sent", "who received" and "not changed" itself. When this information is retained in traditional logs, those logs must be made tamper-evident through cryptographic technology (such as that included in MOVEit products). ASx provides an alternate "non-repudiation" technology through standards-based MDNs: each MDN is a "non-repudiation" receipt for a single file.

  In MOVEit Automation, MDNs are retained in the MOVEit Automation tamper-evident audit database from which they may be examined and exported at any time.

  Again, in the file transfer arena, if a series of file transfers all had characteristics of non-repudiation, it used to be common to refer to this situation as "end-to-end file non-repudiation" or an "unbroken chain of non-repudiation." More recently (and thanks largely to new regulatory requirements) this same concept has been described as a "file pedigree".

  In either case the end result is the same: if you can prove who sent a file over each hop, who received that file over each hop and that the contents of the file were not changed between original sender and final recipient, you have all the necessary elements to satisfy "end-to-end file non-repudiation", "file pedigree", etc.

  Proper implementation of the MOVEit ASx protocols will give you "end-to-end file non-repudiation", "file pedigree", etc.

  (Notice that "encryption" is NOT an element of file non-repudiation. Many operational requirements ask for encryption on only part of a file delivery chain because some internal process needs to examine and possible modify a file along the way; MOVEit Automation is often involved in this kind of processing step.)