The use of public key cryptography as described (I mentioned it at my previous post) so far has a number of problems associated with it. These can be solved by incorporating the improvements described below.
One problem is that when Alice and Bob (and all other members of the community) are sending their public keys to the public directory, someone with criminal aspirations (say, Charlie) might intercept the public key and substitute one of his own, keeping the real one to one side. When Bob wants to send a secret message to Alice he gets her public key from the directory, but actually he gets the bogus key from Charlie. Using this key he puts his secret message into a digital envelope and sends it to Alice.
Charlie, meanwhile, has arranged to intercept all envelopes addressed to Alice. He has the private key which matches the public key that Bob has used, and he opens the envelope and reads the secret message. He then puts it into another digital envelope using the public key that Alice intended should go to the directory, and sends that on to Alice. To her, everything seems to be in order.
Similarly, signatures can be intercepted by Charlie and substituted using the private key that matches the bogus public key that he has put into the directory. Of course, if Alice ever checks her own public key entry in the directory she will immediately spot the deception, but will she remember to do that?
A better way to handle this is to use ‘certification‘ of public keys. Someone is set up as a network-wide authority to certify public keys. This person has their own, special, public key which is given to everyone. This key is so very public and is distributed by so many different routes that it is quite infeasible that anyone could intercept its distribution and substitute a bogus key. All other public keys are generated in secure circumstances and each of these, together with its owner’s ID and its date of creation, is subjected to a digital signature using the private key of the certification authority. Thus each public key is distributed in certified form and no one can now substitute another key, since they will not be able to forge the certificate.
When a public key is needed for use, it is retrieved from the public directory along with its certificate. Everyone has the certification authority public key, and hence everyone can verify the certificate (which is a digital signature) and check that the key and its ID match one another. The checking is an ‘off-line’ process for which it is not necessary to communicate with the certification authority.
The second problem that needs to be solved in order to build a practical system is that of throughput. The RSA public key scheme works because of some unusual properties of certain types of mathematical problem. As a result of this, the computations required to perform the RSA private key operations (i.e. either `open an envelope‘ or ‘write a signature‘) are very demanding on computer processing power. To process long messages directly by RSA becomes unworkable because of the need to maintain acceptable response times. In practice we use a two-tier system, in which a fast, symmetrical algorithm is used to encrypt the long message using a randomly generated secret key. It is this secret key which is put into the RSA digital envelope. Similarly for signature of messages we use a fast hashing algorithm to process the whole message and produce a short message digest, which can then be signed using the RSA private key of the signatory.
security services and the mechanisms which are used to implement them.
The international standards which address the specific requirements of EDI are known as UN/EDIFACT. There is also a set of American National Standards Institute (ANSI) X.12 standards which were strongly promoted by the US lobby. However, it is EDIFACT that has now gained acceptance amongst the international community and is being integrated into the ISO structure. ISO 9735 contains the EDIFACT syntax and ISO 7372 is the Trade Data Element Directory. The security elements of EDIFACT syntax are being developed by the Security Joint Working Group of EDIFACT, but their work is still at the draft stage. Some of the other ISO standards groups are working separately on the issues of cryptographic data syntax rules and certification schemes, and this work should dove-tail into the EDIFACT syntax definitions which provide the delivery mechanisms.
At the time of writing, work continues to develop the full range of standards which will enable the international community to share the benefits of EDI.
International Standardization for EDI
The existing standards, particularly the X.400 and X.500 series from CCITT, which provide a suitable environment within which EDI systems can be built, have already been discussed. The CCITT X.435 and X.436 standards are specific to EDI and are entitled `Message Handling Systems: EDI Messaging System‘ and ‘Message Handling Systems: EDI Messaging Service’ respectively.
Another important standard is the International Standards Organization’s ISO 7498-2: ‘Open Systems Interconnection — Security Architecture’ (also known as CCITT X.800), which provides a basic framework and terminology with which to describe
Are the Solutions Available?
The market-place is now beginning to contain suppliers who have these solutions in a packaged form ready to be integrated into EDI applications. Of course, these commercially available solutions need to be incorporated into the EDI systems that are being installed at user sites. Despite the fact that the compliance of solutions with international standards implies supplier independence, systems integration capability is perhaps one of the most important factors which will distinguish those suppliers who are successful in this market from those who are not. For those who are thinking of buying a system, these supplier capabilities are worth investigating in detail.
In this context, the development of an ‘open’ standard for the `application program interface’ (API) to security sub-systems will be an important step forward but, as yet, there has been little work done in this area. The impetus now emerging in the open systems arena may eventually assist the EDI community to solve its problems over security sub-system integration and support.
