|EDIdEv - Electronic Data Interchange Development||EDIdEv|
|EDI Tool for Developers|
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.
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 in order 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 it's paired public 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 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.
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.
If you have further questions, please email email@example.com.
EDIdEv provides programming examples
for illustration only, without warranty either expressed or implied, including,
but not limited to, the implied warranties of merchantability and/or fitness
for a particular purpose. This article assumes that you are familiar with the
programming language being demonstrated and the tools used to create and debug
procedures. EDIdEv support engineers can help explain the functionality
of a particular procedure, but they will not modify these examples to provide
added functionality or construct procedures to meet your specific needs.
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
EDIdEv - EDI Development