3 Must-Knows on Secure B2B Communication and AS2: The One-Stop Solution
Read an overview of the basics of cryptographically secured communications, with some real-world use cases to highlight the importance of this security measure.
Join the DZone community and get the full member experience.
Join For FreeIn today's digitally transformed world, security is a key concern when it comes to B2B communication, whether it be a simple 210-997 exchange or a sophisticated SCM document chain. Being aware and up-to-date on B2B security will always keep you ahead of the competition, and increase your chance of becoming that "largest retailer" or "leading partner" role that you and your business have always dreamed about.
1. What It Is
B2B security naturally derives from the basics of communication security.
Confidentiality
What goes on between you and your business partner (from here on in, let's simply call him/her "partner") stays between you two. In other words, nobody else ("third-party") gets to see or read whatever it is that you two are communicating (imagine a sealed package that can be opened only by the intended recipient).
Authenticity
When your partner receives something that seemingly came from you, he/she can verify that it indeed came from you (picture a signature or an official seal on a business letter).
Integrity
What your partner receives is exactly the same thing that you sent out from your end, and vice versa; i.e. nobody else can modify or tamper with the content. Just imagine if somebody were able to change the inventory on the invoice that you just sent out before it reaches your partner!
Non-Repudiation
Once your partner receives what you sent him/her, he/she cannot refute the fact that he/she received it (think about the receipt that you forget to collect once you have made a payment).
2. Why You (and Your Partner) Should Care
This part should be fairly obvious from the examples I gave in the previous section. Without these measures, all sorts of weird and unpleasant things could happen, eventually leading to the ruination of your business.
- Your rival could send your supplier a fake purchase order on your behalf—perhaps even a complete order document chain, resulting in a (surprise!) delivery at your doorstep that you never actually ordered.
- Your rivals could intercept and view every single purchase order—or any other document, for that matter—that you would be sending to your partner.
- Your rival could impersonate your partner, and start sending fake responses to your documents that are actually intended for your partner's eyes only. You would have no way of knowing that the other party talking is not your actual partner.
- Even more interestingly, your rival could intercept the document you (or your partner) sent out, take it offline, make small modifications—nothing much, maybe adding or removing a few zeroes here and there!—and put it back online. (I hope it's needless to explain how harmful such a "small" modification could be!)
Now that would explain why your partner would have mentioned in your negotiations, "Ah, and all documents should be exchanged securely over AS2/HTTPS" (or maybe "AS3," "OFTP," or some other weird acronym, for that matter).
3. How To Achieve B2B Security
Lost your peace of mind? No worries, techniques are already in place to guard you against all of those nasty rivals out there.
WARNING: Things are about to get a little G(r)eeky. Reader discretion is advised.
Encryption for Confidentiality
This is all about transforming the content that you send out into a form that can be interpreted (read) only by your partner (in other words, no third party would be able to make sense of the document while it is in transit).
There are actually 2 levels of achieving this, in the "AS2/HTTPS" example mentioned above:
- HTTPS provides transport-layer encryption, meaning that whatever is being sent on the wire (or wireless radio waves, if you insist) would be encrypted, right from the time it leaves your computer right up to the time it arrives at your partner's computer.
- AS2 provides application-layer encryption, meaning that the application (AS2 client) triggering the sending of your document would already have encrypted it (this is fairly secure, even in the absence of HTTPS).
Now, if that was all Greek to you, it's just enough to keep in mind that protocols like AS2 include both, providing the security equivalent to a dual-lock safe.
Signing, for Authenticity and Integrity
While a real-world signature deals only with authenticity, a digital signature can also ensure integrity as well. This is due to the way a digital signature is calculated, which, in plain English, involves a kind of transformation where a concise form (a hash) of the message is created, and then scrambled ( [!Stack!]encrypted, if I may) using a special token (a private key, technically speaking) that is unique to the sending party (the technical term being digest calculation). If the receiver can unscramble the scrambled chunk using another different token (technically, the public key corresponding to the above private key), it verifies that the message had indeed been scrambled using the exact-same partner-specific token (private key) that was mentioned earlier—and hence that it actually originated from that specific partner and nobody else.
While the unscrambled chunk of data (effectively, the info that was calculated earlier by your partner, before being encrypted) can also be used to verify the integrity (intactness) of the message (e.g., you could calculate the same hash against the received message, on your end, and compare it with the hash that was sent to you by your partner), usually the MIC (message integrity code) technique is employed to explicitly enforce the integrity aspect. We'll come to that later.
By the way, if you are wondering how on earth something scrambled using one token (private key) can be unscrambled using a different token (public key), you might want to read up on asymmetric key encryption and public key infrastructure (PKI).
Receipt for Non-Repudiation
Just like a payment receipt, your partner who successfully received the message you just sent out is supposed to send back a "receipt" (technically a disposition notification) saying that he/she was able to successfully receive and interpret the message. By convention, communication is considered to have been successfully completed only after the receipt has been sent back to the sender (just like a real-world transaction). Once the receipt is sent, your partner has confirmed that he/she received whatever it is that you sent, and can never deny it.
MIC for Integrity
This looks like a "repeat back to me what I just said" scheme, although it's usually more concise. Here, your partner is supposed to compute a fixed-length data chunk representing the message that he/she just received from you (a "hash" (again!), technically speaking; the chunk is usually shorter than the actual message) and send it back to you. You can then do the same computation on your end and compare your "chunk" with his/her "chunk." Since the two "chunks" were calculated independently, if they do match, you can be confident that the message (document) content is the same at both ends—and hence that your partner received exactly what you sent out.
All of the above are readily available in the AS2 (Applicability Statement 2) protocol for secure document exchange. AS2 is the most widely used B2B protocol in the modern e-commerce space. When it comes to all the nitty-gritty details that we discussed above, it's all there in the official AS2 RFC, in case you are curious.
However, the caveat is that AS2 requires you to have a server machine running 24×7, exposed to the public internet so that your partners could send messages to you whenever they want. That, in itself, could be a substantial burden, especially for small- and medium-scale enterprises, with the incorporated painful set-up, configuration, and testing steps, operational costs, maintenance overhead, and all sorts of security concerns. (Remember, you are exposed to the wide, wild world and there are hackers everywhere!)
4. (Bonus!) Managed AS2, to the Rescue!
If you are overwhelmed by all this alien stuff by this point (or wisely skipped all the way down to here), it is perfectly logical. All those technicalities are too much for the regular, business-oriented minds (and rightly so). That is precisely why we have managed AS2 clients and services—which make AS2-based trading as simple as the click of a button. Better still, now there are online and cloud-hosted AS2 solutions that free you completely from having to maintain fancy servers or other forms of hard-to-manage AS2 infrastructure.
Published at DZone with permission of Janaka Bandara, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments