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.
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.
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:
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.
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 Central, MDNs are retained in MOVEit Central's 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 MOVEit's 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 Central is often involved in this kind of processing step.)
All of the ASx protocols can:
See also (on their respective "AS1, AS2 and AS3 - The ASx Protocol" pages):
In addition, all of the ASx protocols treat a single file as a single message. Unless you explicitly zip or otherwise bundle multiple files together before an ASx operation, each file will be sent individually and each will be paired up with its own MDN later.
The difference between the AS1, AS2 and AS3 protocols is really the different TRANSPORT protocol each one uses to send messages and receive MDNs.
The MDNs for AS2 transfers come in three varieties. In the synchronous HTTP(S) type, MDNs are transmitted using the same connection as the original file upload. In the asynchronous HTTP(S) type, MDNs are transmitted using a different web upload session. In the asynchronous email type, MDNs are transmitted via email, just as in AS1 MDN transmissions.
AS1 was developed first, followed by AS2 and AS3. AS2 did not completely detach itself from AS1 in one respect: asynchronous email MDNs. Remember that the file sender always controls how its MDN is returned from the recipient.
See also (on their respective "AS1, AS2 and AS3 - The ASx Protocol" pages):
ASx transfers are "1-sender, 1-recipient" affairs. Although support for multiple recipients is common in similar encryption schemes such as PGP and SMIME, ASx transfers do not support this concept.
Most ASx products define the two sides in a file exchanges as "my organization" (i.e., you) and "your partner" (i.e., anyone else). Both sides are responsible for coming up with at least two pieces of information: an SSL certificate and their trading partner name. (In practice, one side may provide all of this information.)
The two sides must exchange their information (minus the private keys on their own SSL certificates) and agree on which certificates and trading names before any ASx file transfers may take place.
Each AS1, AS2 or AS3 protocol will also require each side to agree on additional protocol-specific items such as which server to send files too, what credentials to use to authenticate to the server and what flavors of MDNs are supported. Additional information about these specifics is covered in each ASx protocol's discussion.
If everyone always signed and encrypted their ASx messages, requested signed MDNs and used SSL encryption when transporting ASx messages there would still be plenty of options to configure. However, almost every element discussed so far is really an optional element. Specifically, the following configuration items are among those considered optional in the ASx specifications. (You can probably guess - hint: "Y" - what the best practice values are.)
When used properly, ASx protocols solve a number of traditionally vexing secure file transfer issues, but they do not solve all problems. Some of the cases that require additional thought and planning are described below.
ASx's "Two-Way Handshake" Does Not Let Receiver Know Sender Got MDN
As described above, properly configured MDNs provide a high degree of non-repudiation. The sender knows that the recipient got his/her file, and the recipient knows that he/she is looking at an exact copy of the original content. However, the recipient never knows for sure whether the sender received or verified a requested MDN.
TCP networking uses a "three-way" handshake to avoid a similar problem. The three handshakes in TCP are:
The ASx protocols specify only two of three possible "handshakes": an ASx file recipient never finds out what the file sender thinks of the MDN the file recipient created. This limitation can lead to several issues:
ASx MDNs Represent Handoffs of Responsibility, Not Fitness
The ASx protocols require that MDNs get sent as soon as an ASx message recipient can decrypt, validate the signature of and verify the contents of a data file.
In other words, after an MDN has been successfully sent, it is now the recipient's sole responsibility to not lose the decrypted file (or at least retain and be able to decrypt the original file at will). If internal processing or delivery errors crop up, they are the file recipient's sole responsibility and MDN technology can not be used to notify the sender about any data file format or content problems.
ASx Protocols Do Not Provide the AES Encryption Algorithm
The encryption ASx provides is essentially a tightly defined subset of SMIME. Unfortunately, one of the encryption algorithms left out of the specification was AES, the latest symmetric encryption algorithm approved by the federal government. In other words, the only FIPS-validated encryption algorithm ASx products can provide when encrypting or decrypting ASx messages is "triple-DES" (3DES), and the highest number of encryption bits available will be 168 (not AES's 256).