AS2 Security Basics
Applicability Statement 2, or AS2, is one of the most secure file transfer protocols for data exchange between trading partners. AS2 combines a number of secure and widely used technologies, including HTTPS, SSL Certificates, S/MIME and file hashing.
How Does AS2 Security Work?
Walking through the process of sending a document to your partner using AS2 reveals why this protocol is so secure.
1. Document Preparation
You start by preparing the document in the standard EDI format to send over AS2.
2. AS2 Packaging
Next, you package the EDI document as an AS2 message using the Secure/Multipurpose Internet Mail Extensions (S/MIME) specification. The packaging process consists of compressing the message (optional), digitally signing the message, and securing it through encryption. Both encryption and signing are performed using using a pair of certificates: a locally stored private key and an openly shared public key (this is known as asymmetric key cryptography). During EDI onboarding with your new partner, you will exchange certificates, sending your public keys to each other.
Signing
The digital signature, also known as an electronic signature, uses a signed message digest to certify the message's authenticity and prove the sender's identity. You sign the message using your private key.
Encryption
Encryption converts the EDI document information into a format that only your trading partner can read the message. You encrypt your message using your partner's public key.
3. Message Delivery
The message is now sent to your partner over HTTP or HTTPS. When HTTPS is used, the message is sent over an encrypted transport layer that uses SSL (TLS) encryption on top of HTTP.
4. Unpackaging
Once your partner's server receives the message, it decrypts it using the partner's private key. Because your partner is the only one with that particular private key, they're the only one that can decrypt the message. Then, the server uses your public key to verify the message signature. Since you used your private key to sign the message, this proves that you are the only party that could have signed the message. The message is then decompressed.
5. Receipt and Non-Repudiation
Next, your partner confirms that the message was successfully extracted and that the payload received matches the payload transferred by sending a Message Disposition Notification (MDN) back to you as a receipt.
Message Integrity Check (MIC)
To ensure that the payload was transferred correctly, the recipient calculates the Message Integrity Check (MIC), or checksum. It then shares the checksum with the sender by placing it in the MDN receipt. The sender will also calculate a checksum when preparing the message. The two values are compared to guarantee that the message sent is identical to the message delivered.
Synchronous MDNs vs. Asynchronous MDNs
MDNs can be sent either synchronously or asynchronously. Synchronous delivery means that the HTTP request made to send the original message can also bring back the HTTP response in the form of the MDN. Asynchronous uses a separate connection for the request and the response, allowing the recipient to process and verify the data before sending back a status to indicate whether the transaction was successful. The sender of the message dictates whether or not the MDN should be returned synchronously or asynchronously.
Signatures
The MDN is signed to verify the identity of the recipient. The partner uses their private key to sign the MDN. The signed MDN provides non-repudiation, guaranteeing that the message was delivered where it was supposed to be. The use of signatures on the message and the receipt creates a Non-Repudiation of Receipt (NRR) event, which is considered legal proof of delivery.
How AS2 Security Compares to Other File Transfer Protocols
AS2 is not the only file transfer protocol for EDI. Some other popular protocols for EDI message exchange include FTP/S and SFTP. Like AS2, these protocols encrypt the connection, which means you can secure FTP/S file transfer with TLS encryption or SFTP with SSH encryption.
However, many of these other transfer mechanisms lack non-repudiation. In EDI exchanges, it's critical to ensure that your partner, and only your partner, receives the message. Whether you need to exchange purchase orders and invoices, inventory updates or other transactions, these are mission-critical business processes, making non-repudiation a necessary legal protection and guarantee. More plainly, you don't want orders and payments lagging because someone never received a document, and you don't want anyone claiming they didn't receive an invoice or order if you actually sent one.
Other transport protocols, such as AS1, AS3, AS4, OFTP, and RosettaNet also offer non-repudiation, but AS2 is by far the most commonly used EDI protocol, particularly in the U.S.
Drummond-Certified AS2
Do you have to meet partner EDI requirements for AS2? Start with a Drummond-Certified AS2 solution, as Drummond-Certified solutions are rigorously tested to meet AS2 requirements, not only for security, but also for interoperability with other tools. A Drummond-Certified solution makes it much easier to get started with partner AS2 and EDI exchanges.
Download Our Drummond-Certified AS2 — Free for Use with One Partner on Azure Marketplace