This is a work of fiction. The incidents portrayed herein may have taken place under different settings, in a different order, or even not taken place at all; however, it will not refute the origin and evolution of Applicability Statement 2, more commonly known as AS2, the most popular secure B2B document/EDI exchange protocol in the known universe.
Earliest files were paperbacked, and dispatched around via postal and courier services. They took days - or hours at best - to reach their destinations. Needless to say, a major bottleneck in rapidly growing B2B trade ecosystems.
Then came computers and the internet, and things improved dramatically. (There were probably many more intermediates; fax, email, etc.; but we'll skip them for brevity.)
Now the transfers took just minutes - sometimes even seconds - instead of hours or days. Accuracy also improved greatly - no more deliveries to the wrong doorstep. Protocols like FTP and email soon became the de-factos for digital data exchange and file transfer.
But still, not everything was solid and foolproof:
There was no receipt or acknowledgement/confirmation; you could send a PO, wait several days for the invoice, and finally phone them to find out they have somehow missed the file - still lying in a corner on their FTP server.
Also, the network did not guarantee integrity (delivery "as a whole"); you could have sent a 1000-row file, and the last 10 - or even 10 randoms from all over the place - could have gotten "lost". Even worse, a random flip of a few bytes could convert some five-digit price tag into a nine-digit one - I won't even start on the consequences.
So people and systems started to acknowledge these transfers with digital receipts; if you sent a file and received an acknowledgement (possibly another file) in return, you had a guarantee (non-repudiation) that the trading partner (or his system) has seen the file and taken it up for processing.
Now that there was two-way communication, there was also a way to verify that the receiver got exactly what the sender sent out (integrity); the receiver would calculate a hash (a finite-length summary; think of finding the "lucky number" from your birthday) of the received file, and send it back in the receipt. The sender could then do the same on the original file she sent, and verify that the two match - which would mean the content on both sides is practically identical (down to just a subatomic mergin of error).
Two problems solved; but still, there were more serious ones lurking around.
File content was flowing through the (inherently unsecure) internet, in cleartext. This meant, any of your adversaries could eavesdrop on the files you are sending - and worse, even modify (tamper) the data being transmitted, to sabotage or manipulate your transactions.
True, you are already exchanging and validating the hash for the sent/received content; but a decent man-in-the-middle could easily pause the original data flow, do his modification and generate a new hash that would match the modified data.
(Or, if he had complete control over the data flow, he could simply intercept the partner's receipt as well, replace the hash with the old one, and relay it back to you, the unsuspecting victim - who would naturally assume everything went along just fine.)
On the other hand, when it comes to receiving files or receipts back from your partner, you had to somehow make sure that it was actually your partner sending those data in the first place - not something spoofed by a malicious third party.
What we needed here was simple: a way for you (sender) to place a "seal" on the file (very much like the wax seals from the old snail-mail days) and for your partner (recipient) to verify that the seal was not broken while things were in transit.
So the digital signature was born. Basically you take the hash of the file (as before), encrypt it with your private key, and send it alongside; and publish the corresponding public key (certificate) so that other people - usually your partners - can decrypt (verify) that blurb of data upon receipt.
This was a rather smart move! It achieved many goals:
Good; now if we could just make the file unreadable to prying eyes, in transit...
As the title suggests, encrypting the file content makes it invisible (more correctly, incomprehensible) while it flows through the internet. Which means there is no room for the adversary to read or modify the file content.
Of course there had already been 'secure' protocols like SCP, SFTP and FTP/S that would transfer encrypted content (ciphertext) instead of cleartext; however, you still had to make sure that you were connecting and sending to the correct remote partner/system; jumping over traps like DNS spoofing.
But with AS2 encryption, even if you connected to a wrong server, your content was encrypted using a certificate (public key) that was pre-shared with you by the real partner - and not the certificate of the currently connected server. So, even if you did accidentally send the file to a hacker, they could not possibly decrypt it without access to the partner's own secret private key - which never comes out in the open, throughout the whole process.
What we (or rather, many ingenious people over several decades) invented so far - adds up to the AS2 protocol - which happens to be the most popular secure file transfer protocol today. Especially after Walmart the Giant mandated it for all its trading partnerssince 2002.
You can learn more about the protocol from its official RFC 4130 document, which is very informative and fairly simple to understand.
Having said that, where are we now?
If you scroll up towards the "Digital file transfer" section you would realize that, while we have achieved a remarkable level of security, AS2 has also added a lot of overhead and complexity to our business flow:
Let's see what it takes:
The situation is as much complicated:
Obviously, too much of a technical burden for an already-complicated business flow, and a team that is already overwhelmed with a thousand and one other business-critical tasks and needs.
There are tools like the
openssl suite that
can take good care of individual steps; but chaining them up to fulfill the overall flow is not
very trivial or feasible, even for a tech-savvy team; and most business teams cannot afford such
a subdivision of techies in the first place.
While it solves the security aspect and provides an end-to-end guarantee of the file transfer, AS2 by itself does not fully solve the caveats of file transfer, especially being over the unreliable internet:
And that is why many new as well as well-established businesses are turning towards:
Managed File Transfer collectively refers to addressing the pain points we discussed so far:
Such MFT systems can be:
The choice depends mainly on:
AS2 Gateway is a simple yet mature AS2-based MFT platform, nurtuted and trusted over a decade of production use by customers all over the globe.
In addition to an intuitive, email-like interface for exchanging files with your trading partners, it offers automation mechanisms like SFTP and a REST API that will closely integrate with your own order processing system and business workflow. More integration methods like webhooks and cloud storage like AWS S3 are already on the way.
Getting started with AS2 Gateway SaaS cloud hosted platform is pretty easy; there is comprehensive documentation, demo videos and troubleshooting references to guide you every step of the way. Besides, the friendly AS2 Gateway team is ready to help you at any hour of the day.
If your use case calls for a dedicated installation, with higher messaging capacity, cloud or on-premise hardware, and custom integrations with your own systems, it is just a quick call or form-fill away.