EDI X12.58 Security Sample Programs
EDIdEv Framework EDI supports the security standards of EDI - ASC X12.58 Security Structures. It includes the following techniques to secure an EDI X12 file.
- Authentication - verifies the identity of the sender, and the integrity of the document.
- Compression - decreases the size of the document for faster wire transmission, and is an added security format.
- Encryption - protects the confidentiality of the document.
- Assurances - assures that the received message is from the original sender.
The X12.58 security structures ensures that the EDI file arrives at its destination in its original format; that it has not been tampered with; and it assures the recipient that it came from the original sender. The X12.58 security structure is not specific to any mode of transport; and will work whether EDI files are exchanged over the Internet, email, dial-up, or disks. In X12.58 the whole EDI file is not encrypted, but only the message section, so that the interchange header segments can still be read for the EDI files to be directed to their destination.
Below are sample programs to demonstrate the use of the FREDI-COM to encrypt and decrypt EDI files using public and private keys. The scenario assumes three companies A, B and C trading with each over the Internet.
Before the companies can begin to exchange encrypted EDI files, each of them would have to initially generate both a public and private key. Their public keys would be shared among themselves so that they can use it for encrypting EDI files that they would send to each other. The private keys are not shared but held secret; and would be used to decrypt EDI files that were encrypted with its paired public key.
Click here to evaluate a sample program that will generate a public and private key.
Once the public and private keys are created. The companies would distribute their public key to their trading partners either by posting it on their website, or by emailing it directly to their trading partners. The trading partners would use the public key of the company (that they are going to send the EDI file to), to encrypt the EDI file. For example, Company A would use the public key of Company B to encrypt EDI files that are going to be sent to Company B.
Click here to evaluate a sample program that will encrypt an EDI file.
Once the EDI file is encrypted, it can then be sent to the trading partner via the Internet. The company receiving the ciphered file would then decrypt it using its own private key. For example, Company B would use its own private key to decrypt the ciphered EDI file that it would receive from Company A.
Click here to evaluate a sample program that will decrypt an EDI file.
Click here to evaluate a .NET program of all the sample programs above.
Click here to evaluate the Framework EDI
The example programs provided in this article are for illustration only and have no purpose other than to show software developers how to use the Framework EDI component in programming languages to process EDI files. If you have any questions, don't hesitate to contact us:
EDIdEv Framework EDI uses the compression technology of Info-Zip
Copyright (c) 1990-2002 Info-ZIP. All rights reserved
This software is provided "as is," without warranty of any kind, express or implied. In no event shall Info-ZIP or its contributors be held liable for any direct, indirect, incidental, special or consequential damages arising out of the use of or inability to use this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
Redistributions of source code must retain the above copyright notice, definition, disclaimer, and this list of conditions.
Redistributions in binary form (compiled executables) must reproduce the above copyright notice, definition, disclaimer, and this list of conditions in documentation and/or other materials provided with the distribution. The sole exception to this condition is redistribution of a standard UnZipSFX binary as part of a self-extracting archive; that is permitted without inclusion of this license, as long as the normal UnZipSFX banner has not been removed from the binary or disabled. Altered versions--including, but not limited to, ports to new operating systems, existing ports with new graphical interfaces, and dynamic, shared, or static library versions--must be plainly marked as such and must not be misrepresented as being the original source. Such altered versions also must not be misrepresented as being Info-ZIP releases--including, but not limited to, labeling of the altered versions with the names "Info-ZIP" (or any variation thereof, including, but not limited to, different capitalizations), "Pocket UnZip," "WiZ" or "MacZip" without the explicit permission of Info-ZIP. Such altered versions are further prohibited from misrepresentative use of the Zip-Bugs or Info-ZIP e-mail addresses or of the Info-ZIP URL(s).
Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip," "UnZipSFX," "WiZ," "Pocket UnZip," "Pocket Zip," and "MacZip" for its own source and binary releases.
Related Topics