- Email: [email protected]
EDIFACT security made simple—the EDIMED approach
Computers
& Security, 12 (1993)765-774
EDIFACT security made simple-the EDIMED approach Jon 0lnes
EDIMED is a germ-al message intcrchangc tool, primarily aimed at exchange of health care information by means of EDIFACT messages over X.400 electronic mail. To allow transfer of very sensitive health care data in accordance with the rules of the Norwegian authorities, a strong security system is needed. This article shows how securiry of EDIFACT messages can be implctnented in a simple and efficient way. EDlMED uses DES encryption with a system for manual key distribution to provide integrity, confidentiality, peer-entity authentication and non-repudiation services to its applications. Keywords: EDIFACT entity authentication, nianagcmcnt.
security, Integrity, Non-repudiation,
1. The EDIMED
Confidentiality, DES encryption,
PcerKey
system
DIMED is a commercial product from EdiMcd A/S’ in Oslo. It has been dcvelopcd in cooperation with InfoMedica A/S, with financial support from the Royal Norwegian Council for Scientific and Industrial Research (NTNF). Norwegian Computing Ccntre (NR) carried out a large part of the design and implementation work, including the security system. During the development, close contacts with Norwegian regulatory and health cart authorities were kept.
E
EDIMED is a general message interchange tool. Primarily, EDIFACT syntax is used, but W-7 (Health Level 7) messages [l] are also supported.
‘EdiMed
A/S, Kosenkrantzgt.
0167-4048/93/$6.00
22, N-0160
Oslo, Not-way.
(MEDIX) standards [2] will be considcred in future versions. Currently, only x.400 electronic mail is used for communication, but real-time/transactional messaging is planned. Work is also in progress to invcstigatc the use of the ODETTE file transfer protocol [3] over X.25 as carrier. LEEE Pll57
EDIMED has a highly modular structure, which makes extensions and replacement of the individual modules easy. EDIMED is built on international standards, or de facto standards where standards do not exist or arc not usable. The main goal for EDIMED is efficient, standardized clectronic exchange of health cart information, using EDIFACT. EDIMED is a collection of libraries providing an application program interface (API). The libraries may be linked to various applications, which have to be mod&cd to use the API calls at the appropriate places. Figure 1 shows the overall structure of the EDIMED system. At present, EDIMED runs under MS/DOS and UNIX System V. An application opens a session to EDIMED, and idcntifics itself. All identifications arc given as unique, user-friendly names, called “nicknames”, used to index the user directory. The user directory maps nicknames to X.400 O/R addresses, and provides other information relevant to message inter-
0 1993, Elsevier Science Publishers
Ltd
765
J. 0lneslEDIFACT security made simple
local syntax before being delivered to the application.
Application I
I
I
I
API calls
111
EDIMED API
I
Security
I-“-&g
_
Security directory
Within the health care environment, a wide range of communication demands exist. Some examples may be:
Encrypted
l hospital internal communication of all kinds, e.g. requests for laboratory tests, and the answers to such tests, updating of the medical journal of a patient, and so on;
1% X.400
Basic communication services
‘7; Fig. 1. Overview of the EDIMED
Network system.
change between the local end and specified remote parties. Note that an EDIFACT “user” is always an application, not a human user. The application may now send or receive messages. identifies the On sending, the application receiver(s). Values for the various fields of the in local syntax, and messages are specified EDIMED builds the EDIFACT messages based on this information. The resulting EDIFACT exchange is written to a file, which in turn is taken as input to the security module. This module encrypts the file’s contents, and writes the encrypted version to a new file. This file is used as the body part of an X.400 message. A unique message identification, and, if selected, the whole message, is written to a log before the message is transferred over the network. On reception, messages arc received from the network, processed by the X.400 module, logged, decrypted, and finally converted from EDIFACT to
766
When no more send or receive operations between the two specified users are desired, the application closes the session to perform cleanup operations in the EDIMED system.
l communication between private practitioners and central institutions such as hospitals or laboratories, c.g. requests for and answers to laboratory tests, requests to enrol patients at a hospital, and so on; l communication between a private practitioner and health care and other authorities, e.g. requests for refunding of bills covered by governmental funding, transfer of statistical and other information and so on; l communication between hospitals, c.g. when a patient is transferred from one hospital to another, between a hospital and health care and other authorities, and between a hospital and various companies, e.g. to order food and other supplies for the hospital.
standardization of EDIFACT International messages for health care information is an ongoing process, and participants in the EDIMED project arc taking an active part in this work. NR has participated in the MEDIX effort [4]. 2. Requirements
for EDIMED
security
Health care information may be very sensitive. Datatilsynct (the Norwegian authority for data
Computers
security) has very strict rules for treatment of this kind of sensitive information [5]. Close contact with Datatilsynet was kept during the development of EDIMED, with the result that Datatilsynct has certified EDIMED as suitable for transfer of very sensitive health care information over external lines. This certification is indeed necessary to allow any use of EDIMED at all in the health care environment in Norway, and the overall requirement for the security system was to obtain this. To enable use of EDIMED in other countries, similar certification will be needed. Other requirements coming from Datatilsynet’s rules, and from the environments in which EDIMED is supposed to be used, and the implications of these requirements, are listed below. l Datatilsynet’s rules must be followed regarding integrity and confidentiality of messages. As an example, the rules state that sensitive information transferred over external lines must be encrypted. + Strong enough encryption algorithms arc needed.
0 Larger institutions may run applications using EDIMED on UNIX servers, while other applications, especially for private practitioners, will run on MS/DOS PCs. Other platforms, like OS/2, may be considered later on. -The security system must run efficiently on MS/DOS and UNIX, and should be portable to other platforms. Some customers, such as private practitioners, may have very old MS/DOS equipment, and they will not use EDIMED if they have to buy new equipment or special hardware to run the security + Encryption system. must be performed efficiently in software, with small enough storage demands to run on old equipment. Unfortunately, this rules out public key algorithms. l
The security system, as well as the rest of EDIMED, must be based on established standards. Since public key encryption is ruled out, in practice we are left with one choice. -The DES algorithm [6] should be used for encryption. l
& Security,
Vol. 12, No. 8
l Messages are transferred by electronic mail, and may possibly be stored at intermediate nodes. Transfer is over modem connections, X.25, LANs, or other networks, which may or may not be controlled by the communicants. -Encryption must be truly end-to-end, from the computer running the sending application to the computer running the receiving application. l For some messages only selected fields need encryption, but other messages may need complete encryption. -Encryption of complete messages is implemented first. l In some cases, Datatilsynet demands encrypted message logs for tracing purposes, and for a (rather weak) non-repudiation service. -+ Logging of encrypted messages, and tools to retrieve and decrypt messages from the log, must be developed. l Administration of the security system must be safe and easy, even for non-skilled users like an arbitrary doctor. -An easy system for distribution of encryption keys must be used.
Currently, EDIMED uses X.400 only, but other carrier services can be foreseen. This is a strong argument for not using standardized X.400 security. Also, X.400 security, as specified in the X.41 I part [7] of the 1988 version of the standard, cannot meet our needs for encrypted logging and truly end-to-end encryption. Most commercial X.400 products arc based on the 1984 version of the standard, which has no security functionality at all. In X.400, 1988 version, a standard for EDIFACT transmission over X.400 mail systems, X.435 [8], exists. However, this document merely refers to X.4 11 for communication security. The X.509 [9] authentication framework cannot be used by us, since it is based on public key cryptography. The Privacy Enhanced Mail (PEM) effort [lo-l 3] by the Internet community can be used without 767
J. 0lneslEDIFACT
security made simple
public key encryption, but will probably even then lack the necessary efficiency. Also, PEM is designed for person-to-person communication, not communication between applications. USC of (some of) these standards is a long-term goal for EDIMED, but, on a short and medium term, other solutions must bc found. 3. EDIMED
security
in context
The EDIMED security system encounters wirctapping, forging, unauthorized changes and other threats to message communication bctwccn applications. Thcsc threats arc minor compared to other threats in most cnvironmcnts. Rather than wiretapping single messages, an intruder will try to gain access to all information in the system, by compromising the computer holding the information, or possibly by stealing backup tapes. Usually, the weak points hcrc arc password security and lack of physical protection. If wiretapping is considered a serious threat, thcrc is a lot of other network traffic which needs to bc protected. On most network systems, when a user logs in, the password is transferred in clear on the network. Wiretapping passwords is clearly more viable than wiretapping single messages. During client/server processing, communication bctwccn client and scrvcr is usually not encrypted. Thus, even if the server obtains the data through a secure EDIMED interchange to its database, the data may later be transferred in clear on the network if acccsscd by a remote client. Terminals (Xterminals or others) connected to their processing computer over a network may be an even grcatcr risk. The conclusion is that strong security in mcssagc communication is rather meaningless unless other, more important, threats are encountcrcd. Howcvcr, on designing the EDIMED security system, we must simply assume that these other security measures arc in place, and make sure that the security of our system is strong enough.
768
4. EDIMED 4.1.
Demands
and application
security
on the applications
As stated earlier, EDIMED is a collection of libraries linked to the applications wishing to communicate. It is reasonable to demand sonic security scrviccs to be performed by the applications: l identification and authentication of human users; applications accessing scnsitivc information are obliged to use proper authentication mcchanisms by Datatilsynet’s rules, so this is not a new rcquircmcnt from EDIMED; l access control, i.c. to verify that the sender is allowed to transmit the information, and that the rcccivcr is allowed to receive it; these requirements for applications arc also already present in Datatilsynct’s rules.
In short, EDIMED trusts the identification of sender and rcccivcr given at the session establishment time, and trusts that the information transfers will bc according to access rights. authentication a password-based Code for mechanism is already prcscnt in EDIMED, but it is not used. WC do not see any real advantage in this, and we do not want to bother the users with the overhead of yet another authentication check. Handling access control within EDIMED will bc very complicated. EDIMED’s task is far simpler when the communication system does not need to know what kind of data it is transmitting
4.2.
Demands
on EDIMED
To fulfil the requirements, EDIMED must provide the following security scrviccs to the applications: l peer entity authentication: the sending application, on supplying the identity of the receiver, must have confidcncc that the message will be delivered only to the intended recipient; the receiver, on the other hand, must know that the message was indeed sent by the claimed sender;
Computers & Security, Vol. 12, No. 8
l integrity of the messages; i.e. prcvcnt unauthorized or accidental change, loss or duplication of messages; l confidentiality of the messages; i.c. unauthorized or accidental disclosure message contents;
non-repudiation of through encrypted logs. l
sending
and
prcvcnt of the
reception,
5. EDIMED’s solution 5.1. Addressing
EDIMED offers exchange of EDIFACT messages bctwccn applications in different organizations using X.400. In EDIMED’s addressing scheme, an X.400 O/R-address identifies application and location, c.g. a laboratory system at a given hospital. For some data, Datatilsynet’s rules demand identification of the person(s) sending and receiving the data. Since EDIMED lcavcs access control to the applications, such information must bc carried in the mcssagcs thcmsclvcs, and the applications must ensure that the data is given only to the authorized person(s). This addressing scheme is in accordance with the guidclincs of “Norsk TEDIS”, the Norwegian EDIFACT organization, and “NOSIP”, the Norwegian OS1 Profile. 5.2. Registration
of users
The sender and rcccivcr applications (“users”) are identified over the EDIMED API by “nicknames” which, at a particular site, arc unique, user-friendly names. Mapping bctwccn nicknames and O/Raddresses is done by the EDIMED user directory. The O/R-addresses are used as indexes in the security directory. Before any communication can take place between a pair of communicants, the address information must be installed in the directories on both sides;
i.e., a prior agreement must exist between the two parties. EDIMED is delivered with support programs to maintain the directories. Since only registered addresses can bc used, an intruder cannot easily force traffic to be sent to an unknown address. Currently, both dircctorics are local to each installation of EDIMED. Later, X.500 may be used for the user directory, which may then be non-local. WC wish to avoid transmission of key information over a network from a non-local directory, which is why the security information is kept in a separate directory. USC of X.500 to hold security information (other than certificates, which WC will not use) is for further study by the standards bodies. 5.3. Encryption
in EDIMED
EDIMED encrypts whole messages, i.e. the complete body part of the X.400 messages, using the DES algorithm with different encryption keys for each pair of O/R-addresses. Encryption is cnd-toend between the scndcr and the final receiver. EDIMED supports all DES modes, but due to the combined security and efficiency rcquircmcnts, we rccommcnd CBC (Cipher Block Chaining) mode. A zero initialization vector is always used. Optionally, the binary result of this encryption is translated to a hex rcprcscntation, i.e. ASCII cncodcd, before transmission. Binary data is not handled by all mail systems. Marc compact encoding, e.g., “uucncodc”, can bc used later on. 5.4. Logging
EDIMED will always log a unique identification of all X.400 messages sent or received. In addition, there are three configurable modes for message logging: 0 no logging; l all messages are logged in clear text, i.e. after decryption; l
the encrypted messages are logged.
769
J. 0lneslEDIFACT
security made simple
Usually the third alternative will be used, since Datatilsynet demands, under some circumstances, an encrypted log. If the transmitted data is less sensitive, logging may be in clear text, or if the application itself handles logging, logging may be turned off In an encrypted log, the X.400 messages are logged as sent or received, i.e. with the header, including the O/R-addresses, in clear text, and the body part encrypted as during transmission. A separate program is written to retrieve information from a log. A search is based on one or several of the following criteria: l
sender nickname or O/R-address;
l
receiver nickname or O/R-address;
l message identification, message id.log;
time interval, given interval. l a
as fetched
from
the
i.e. messages sent during
the
A list of all messages selected by the given search criteria results, and the messages to display are then selected from this list. To display a message, the log retrieval program searches the security directory for the DES key used for communication between these two O/R-addresses at the time the message was sent or received (see Section 7), and uses this key to decrypt the message.
6. Fulfilling 6.1.
the demands
Faking or changing result in selection of masquerade attack masquerading entity correct key. 6.2.
an address in a message will the wrong decryption key. A can succeed only if the is already in possession of the
Integrity
Reliable transfer of messages within reasonable time is a function of the communication services. However, extra protection against deliberate changes is necessary. Since the complete message contents are encrypted, it is not necessary to add a separate checksum. Instead, the encrypted EDIFACT decoding can be relied upon to catch such errors: l any change to an encrypted message will propagate to a large portion of the decrypted message; garbage will result, and the EDIFACT dccodcr will dctcct this; l most EDIFACT messages include a checksum which is transmitted along with the message itself in the encrypted data; even if the checksum algorithm is rather weak, it will catch changes to messages with a very high probability.
Duplicate messages are detected by means of the unique message identification from the X.400 header, or, if this header has been tampered with in a replay attack, by the reference numbers in the EDIFACT headers, which of course are encrypted.
Peer entity authentication
Use of different DES keys for each pair of O/Raddresses gives a strong proof of the identity of sender and receiver. At the sending side, the key is determined by a look-up based on the O/Raddresses supplied. Only these two parties know the key, which means that the sender can be confident that only the intended receiver can decrypt the message. At the rccciving side, the key is found
770
based on the O/R-addresses in the incoming X.400 message. Successful decryption proves that the correct key was used, i.e. that both O/R-addresses are correct.
Loss of messages must be detected by the communication services. Use of the X.400 delivery confirmation option is recommended. 6.3.
Confidentiality
DES encryption of the complete message contents ensures that a wiretapper, or someone else who can get hold of a message, needs to go through con-
Computers & Security, Vol. 72, No. 8
siderable efforts to decrypt the message. Whether or not the DES algorithm is considered to be strong enough is dependent on the data to protect. In a health care environment, where little economic gain can be expected from unauthorized access to data, it is our view that DES encryption is sufficient. This view is shared by the Norwegian authorities.
w_bgon
sec_all_eocrypt
sec_logoff
Security cache library t
1
DES library
If a message, or a copy of a message, is deliberately or by accident sent to a wrong receiver, the receiving entity will never know the correct DES key, and will need to go through large efforts to decrypt. 6.4. Non-repudiation
Encrypted logging of each message on both the sending and the receiving side gives a weak nonservice. Since the message is repudiation encrypted with the key shared by the two communicants only, decryption yields evidence that sender and receiver are the same as indicated in the message. However, nothing prevents authorized users on either side from deleting entries in the log. Furthermore, since the key is stored locally in the security directory, it is possible, through clever programming, interfacing to the EDIMED libraries, to decrypt a logged message, change it, reencrypt and re-insert it in the log. The risk of anyone going through these efforts is sufficiently small that Datatilsynet accepts encrypted logging at both sides as a non-repudiation service. With the aid of a third party, it is very simple to base a strong non-repudiation (notary) service on EDIMED’s encryption scheme. Simply send a copy of each message to the third party for logging, and make sure that this party is never in possession of any of the keys used. On disputes, the sender or receiver must provide its security directory file, and the notary can decrypt the messages in question on the basis of the keys stored in this directory. 7. Design
of the security
system
The modules of the security system are shown in Fig. 2. The interface to the rest of the EDIMED
Fig. 2. Modules
of the EDITED
Security directory (on file)
security
system.
system is strictly limited to three calls. Nowhere in the rest of the EDIMED system are any other functions or data structures in the security system referenced. l see_logon takes sender and receiver O/Raddresses as parameters. On the basis of these names, plus the current time, it fetches the appropriate information from the security directory to the security cache. l see-allencrypt takes the names of an infile and an outfile and an encrypt/decrypt flag as parameters. It encrypts or decrypts the contents of the infile, using the key information in the cache, and writes the result to the outfile. l set-logoff clears the security cache and other memory areas holding security-relevant information.
Selected field en- or decryption may be added later, if needed for efficiency reasons. In this case, an encrypted checksum must be added as well, to detect deliberate changes to unencrypted fields. Public domain DES implementations can be fetched from a variety of sources, with the constraint that one must be careful not to violate the export restrictions which apply from the USA and possibly also from some other countries. For EDIMED, we use a DES library which is call compatible with the DES library of Kerberos [l4], 771
J. (Zl/neslEDlFACT security made simple
which is the closest that one can get to a standard API for DES. Due to the storage limitations of old MS/DOS PCs, WC USCa stripped-down library for the MS/DOS version of EDIMED. The security cache holds the two O/R-addresses involved, identification of the DES mode to use, and the DES key schedule (16 X 8 = 128 bytes). We store a precomputed key schcdulc in the security directory and cache instead of just the DES key, primarily for efficiency reasons. Another reason is that this allows us to remove the rather large key schedule generation part of the code from the MS/ DOS version. The security directory consists of entries as shown in Fig. 3. Each entry consists of a pair of O/Raddresses, and one or several blocks of key information. The O/R-addrcsscs and identifiers for the key information fields are stored in clear text, while the values for the key information fields are encrypted and ASCII-encoded to avoid a binary file. A possible enhancement is to put down an
# Comment: This is an example only. First, the two O/R-addresses are # given, then a block of key information is shown. Several more such # blocks may follow. The 1’ is a line continuation character. A_or_country = no A_or_admd = vasp A_or_org = hospital \ A_or_orgunit = laboratory A_or_surname = “laboratory system”\ B_or_country = no B_or_admd = vasp B_or_org = “doctor hook” \ B_or_sumame = “infodoc system”\ time-from = Ox0123456789ABCDF \ OxOl23456789ABCDF\ time-to = Ox0123456789ABCDF\ OxO123456789ABCDF\ des_schedule = Ox0123456789ABCDF\ OxO123456789ABCDF\ OxO123456789ABCDF\ OxO123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ OxO123456789ABCDF1 Ox0123456789ABCDF \ Ox0123456789ABCDF1 OxO123456789ABCDF\ Ox0123456789ABCDFI OxO123456789ABCDFI OxOl23456789ABCDF \ des_mcde = Ox01234567 ‘89A,BCDF \ \ time-from = Ox0123456789ABCDF .... .... . Fig. 3. Format
772
of an entry in the security
directory.
encrypted checksum for each entry, to detect changes to the clear text fields. Each key information block includes the DES mode and key schedule to use, plus two time stamps giving the validity period for this key information. To speed searching in the directory, the most recent key information is stored as the first block. Key information may be specified to take effect some time in the future. EDIMED will starch the cntrics on the basis of the current time, while the log retrieval program scarchcs the directory on the basis of the timestamp of the message to retrieve.
8. Key administration Certificate-based key administration and use of X.509 is definitely a long-term goal for EDIMED, but this is prohibited on a short and medium term due to the processing rcquircmcnts. Use of Kerberos [I41 for k cy ad ministration was invcstigated, but dropped mainly because of the rcquircments for clock synchronization. The solution is to come up with a good scheme for manual key distribution. The Financial Institution Key Managcmcnt Standard [I 51 was a candidate, but was considered unnecessarily complicated for our purpose. Instead, we set out to define a simple method oursclvcs. Typically, EDIMED will be used for communication bctwccn some service provider, e.g. a hospital, and customers, e.g. private practitioners. It is for key reasonable to place the responsibility management on the provider, which presumably has well established routines for running its computer services. The provider is responsible for periodic key changes, and instructs its customers on the matter. EDIMED uses the “password to DES key” algorithm of Kerberos. It is dcfinitcly easier, especially for an unskilled user, to enter a password string without errors instead of the hex value of an eight-byte key. In addition, users know what a password is; they do not want to know what a DES key is.
Computers & Security, Vol. 12, No. 8
Few applications in a health care environment will generate heavy EDIMED traffic. The risk of someone trying to break the DES encryption is also typically very low. Thus, periodic key changes a few times per year should be sufficient. For periodic key changes, the operator at the responsible institution enters EDIMED’s key administration program, and specifies that update to all entries in the security directory should be done. She is then prompted for the DES mode to use, and the time when the new keys should take effect. New key information entries are then automatically generated for all pairs of O/R-addresses in the directory. The keys themselves are generated by a “random” password generator. Each password is transformed to a DES key, and then to a key schedule. In addition, a file is generated, with one entry for each pair of communicants. On such an entry, the names of the communicants, the DES and the password are mode, the timestamp, written. The file is printed on paper, one entry on each page, and deleted. Each page of information is then signed and sealed by the responsible person, and sent to the appropriate other party by ordinary mail. Electronic mail or telephone is not secure enough for this kind of key information exchange. On receiving the letter with the key information, the other party enters the key administration program in another mode, specifying a change to one entry only. She then enters the names idcntifying the entry to update and the information in the letter, including the password for the new key. This mode of the key administration program is also used at both sides when new pairs are installed, and for changes outside the periodic schedule, e.g. if one suspects that a key has been compromised. “Random” passwords can be used, since a password is only entered once on each side and can be forgotten afterwards. The key information is stored “forever” in the directory.
9. X.400
communication
alternatives
A large institution, such as a hospital, will typically have its own X.400 MTA (Message Transfer Agent) Medium-size with appropriate connec dons. institutions can subscribe to a public X.400 service, such as Norwegian Telecom’s “TelemaX400”, and connect via the P7 protocol of X.400. However, until public X.400 services get cheaper, small customers cannot even afford the latter solution, so EDIMED had to come up with yet another altcrnative. The solution is to run the X.400 part of EDIMED on a remote computer, typically the (UNIX) computer running the MTA of the service provider, e.g. the hospital. Referring to Fig. 1, the customer will run an EDIMED version with the X.400 module removed. Instead, when it is time to wrap the EDIFACT interchange in an X.400 message, this EDIMED version will establish a modem connection to a specified phone number and prompt the user for name and password to the remote computer. This is not an ordinary login, but rather a name/password combination for access to an “EDIMED server”. The data to include in the X.400 message is then transferred over the modem connection. All other modules, including the security part and logging, run on the customer’s computer, which means that all messages are still encrypted truly end to end. However, the login part needs extra protection. The user name is sent in clear text from the customer to the EDIMED scrvcr. The user name can be used as an index in a table to find the appropriate key for this user. The EDIMED server picks a “random” value, which it encrypts and returns to the customer. At the customer’s side, this is decrypted, the password is appended to the random value, and the result is rc-encrypted and sent to the server. The server verifies the password for authentication, and checks the random value for replay
773
J. 0lneslEDIFACT security made simple
attacks. Although this may not be a strong protocol, it gives a reasonable level of protection.
10. Conclusion EDIMED is in daily use, with several applications for communication between private practitioners and hospitals in Norway. So far, the security system has proven to be efficient enough, and easy enough to administrate. The strength of the system, securitywise, has not been challenged, but we believe that the design and the algorithms used provide a good level of security. EDIMED has been certified by the Norwegian authorities as suitable for electronic interchange of very sensitive health care information. In the near future, EDIMED will also be used for other purposes than health care information, e.g. in the commercial world. We believe that the system, with the current manual key distribution scheme, can serve a substantial number of users.
References [l] USA HL-7 Development Group, Health Industry Level 7 Interface Standards, Version 2.1 (draft), December 1989. [2] J.J. Harrington, T.J.R. Benson and A.L. Spector, IEEE I-‘1157 Medical Data interchange (MEDu() Committee. Overview and Status Report, SCAMC, Washington, November 1990.
774
PI
ODETIE (Organization for Data Exchange by Tcle Transmission in Europe), OFTP Specification, Rev. 1.2, November 1986. PI G. Hannemyr and 0. Hanseth, Development of Medical Informatics within MEDIX, NR Report 849, Norwegian Computing Centre, July 199 1. Datatilsynet, Report to the Department of Justice from the Working Group on Guidelinesfor Security ofInformation about Persons, November 1987 (in Norwegian-draft of new rules exists). National Bureau of Standards, Data Encryption Standard, FIPS Publication 46, January 1977. PI CCITT, X.41 1: Message Handling Systems, Message Transfer System, Abstract Service Definition and Procedures, 1989. PI CCITT, X.435: Message Handling Systems, MHS Application for EDI Messaging, 199 1. (91 CCITT, X.509: The Directory-Authentication Framework, 1989. [ 101 J, Linn, Privacy Enhancementfor Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, Internet request for comments, RFC 142 1, February 1993. [ 111 S. Kent, Privacy Enhancementfor Internet Electronic Mail: Part II: Certij’icate-based Key Management, Internet request for comments, RFC1422, February 1993. [ 12) D. Balenson, Privacy Enhancementfor Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, Internet request for comments, RFCl423, February 1993. [ 131 B. Kaliski, Privacy Enhancement Jar Internet Electronic Mail: Part IV: Key Cert$cation and Related Services, Internet request for comments, RFCl424, February 1993. [14] J.G. Steiner, C. Neumann and J.I. Schiller, Kerberos: an authentication service for open network systems, Proceedings of the USENIX Winter Conference, February 1988. [ 151 American National Standards Institute, Financial Institution Key Management (Wholesale), American National Standard X9.1 7. 1985.
151
161
& Security, 12 (1993)765-774
EDIFACT security made simple-the EDIMED approach Jon 0lnes
EDIMED is a germ-al message intcrchangc tool, primarily aimed at exchange of health care information by means of EDIFACT messages over X.400 electronic mail. To allow transfer of very sensitive health care data in accordance with the rules of the Norwegian authorities, a strong security system is needed. This article shows how securiry of EDIFACT messages can be implctnented in a simple and efficient way. EDlMED uses DES encryption with a system for manual key distribution to provide integrity, confidentiality, peer-entity authentication and non-repudiation services to its applications. Keywords: EDIFACT entity authentication, nianagcmcnt.
security, Integrity, Non-repudiation,
1. The EDIMED
Confidentiality, DES encryption,
PcerKey
system
DIMED is a commercial product from EdiMcd A/S’ in Oslo. It has been dcvelopcd in cooperation with InfoMedica A/S, with financial support from the Royal Norwegian Council for Scientific and Industrial Research (NTNF). Norwegian Computing Ccntre (NR) carried out a large part of the design and implementation work, including the security system. During the development, close contacts with Norwegian regulatory and health cart authorities were kept.
E
EDIMED is a general message interchange tool. Primarily, EDIFACT syntax is used, but W-7 (Health Level 7) messages [l] are also supported.
‘EdiMed
A/S, Kosenkrantzgt.
0167-4048/93/$6.00
22, N-0160
Oslo, Not-way.
(MEDIX) standards [2] will be considcred in future versions. Currently, only x.400 electronic mail is used for communication, but real-time/transactional messaging is planned. Work is also in progress to invcstigatc the use of the ODETTE file transfer protocol [3] over X.25 as carrier. LEEE Pll57
EDIMED has a highly modular structure, which makes extensions and replacement of the individual modules easy. EDIMED is built on international standards, or de facto standards where standards do not exist or arc not usable. The main goal for EDIMED is efficient, standardized clectronic exchange of health cart information, using EDIFACT. EDIMED is a collection of libraries providing an application program interface (API). The libraries may be linked to various applications, which have to be mod&cd to use the API calls at the appropriate places. Figure 1 shows the overall structure of the EDIMED system. At present, EDIMED runs under MS/DOS and UNIX System V. An application opens a session to EDIMED, and idcntifics itself. All identifications arc given as unique, user-friendly names, called “nicknames”, used to index the user directory. The user directory maps nicknames to X.400 O/R addresses, and provides other information relevant to message inter-
0 1993, Elsevier Science Publishers
Ltd
765
J. 0lneslEDIFACT security made simple
local syntax before being delivered to the application.
Application I
I
I
I
API calls
111
EDIMED API
I
Security
I-“-&g
_
Security directory
Within the health care environment, a wide range of communication demands exist. Some examples may be:
Encrypted
l hospital internal communication of all kinds, e.g. requests for laboratory tests, and the answers to such tests, updating of the medical journal of a patient, and so on;
1% X.400
Basic communication services
‘7; Fig. 1. Overview of the EDIMED
Network system.
change between the local end and specified remote parties. Note that an EDIFACT “user” is always an application, not a human user. The application may now send or receive messages. identifies the On sending, the application receiver(s). Values for the various fields of the in local syntax, and messages are specified EDIMED builds the EDIFACT messages based on this information. The resulting EDIFACT exchange is written to a file, which in turn is taken as input to the security module. This module encrypts the file’s contents, and writes the encrypted version to a new file. This file is used as the body part of an X.400 message. A unique message identification, and, if selected, the whole message, is written to a log before the message is transferred over the network. On reception, messages arc received from the network, processed by the X.400 module, logged, decrypted, and finally converted from EDIFACT to
766
When no more send or receive operations between the two specified users are desired, the application closes the session to perform cleanup operations in the EDIMED system.
l communication between private practitioners and central institutions such as hospitals or laboratories, c.g. requests for and answers to laboratory tests, requests to enrol patients at a hospital, and so on; l communication between a private practitioner and health care and other authorities, e.g. requests for refunding of bills covered by governmental funding, transfer of statistical and other information and so on; l communication between hospitals, c.g. when a patient is transferred from one hospital to another, between a hospital and health care and other authorities, and between a hospital and various companies, e.g. to order food and other supplies for the hospital.
standardization of EDIFACT International messages for health care information is an ongoing process, and participants in the EDIMED project arc taking an active part in this work. NR has participated in the MEDIX effort [4]. 2. Requirements
for EDIMED
security
Health care information may be very sensitive. Datatilsynct (the Norwegian authority for data
Computers
security) has very strict rules for treatment of this kind of sensitive information [5]. Close contact with Datatilsynet was kept during the development of EDIMED, with the result that Datatilsynct has certified EDIMED as suitable for transfer of very sensitive health care information over external lines. This certification is indeed necessary to allow any use of EDIMED at all in the health care environment in Norway, and the overall requirement for the security system was to obtain this. To enable use of EDIMED in other countries, similar certification will be needed. Other requirements coming from Datatilsynet’s rules, and from the environments in which EDIMED is supposed to be used, and the implications of these requirements, are listed below. l Datatilsynet’s rules must be followed regarding integrity and confidentiality of messages. As an example, the rules state that sensitive information transferred over external lines must be encrypted. + Strong enough encryption algorithms arc needed.
0 Larger institutions may run applications using EDIMED on UNIX servers, while other applications, especially for private practitioners, will run on MS/DOS PCs. Other platforms, like OS/2, may be considered later on. -The security system must run efficiently on MS/DOS and UNIX, and should be portable to other platforms. Some customers, such as private practitioners, may have very old MS/DOS equipment, and they will not use EDIMED if they have to buy new equipment or special hardware to run the security + Encryption system. must be performed efficiently in software, with small enough storage demands to run on old equipment. Unfortunately, this rules out public key algorithms. l
The security system, as well as the rest of EDIMED, must be based on established standards. Since public key encryption is ruled out, in practice we are left with one choice. -The DES algorithm [6] should be used for encryption. l
& Security,
Vol. 12, No. 8
l Messages are transferred by electronic mail, and may possibly be stored at intermediate nodes. Transfer is over modem connections, X.25, LANs, or other networks, which may or may not be controlled by the communicants. -Encryption must be truly end-to-end, from the computer running the sending application to the computer running the receiving application. l For some messages only selected fields need encryption, but other messages may need complete encryption. -Encryption of complete messages is implemented first. l In some cases, Datatilsynet demands encrypted message logs for tracing purposes, and for a (rather weak) non-repudiation service. -+ Logging of encrypted messages, and tools to retrieve and decrypt messages from the log, must be developed. l Administration of the security system must be safe and easy, even for non-skilled users like an arbitrary doctor. -An easy system for distribution of encryption keys must be used.
Currently, EDIMED uses X.400 only, but other carrier services can be foreseen. This is a strong argument for not using standardized X.400 security. Also, X.400 security, as specified in the X.41 I part [7] of the 1988 version of the standard, cannot meet our needs for encrypted logging and truly end-to-end encryption. Most commercial X.400 products arc based on the 1984 version of the standard, which has no security functionality at all. In X.400, 1988 version, a standard for EDIFACT transmission over X.400 mail systems, X.435 [8], exists. However, this document merely refers to X.4 11 for communication security. The X.509 [9] authentication framework cannot be used by us, since it is based on public key cryptography. The Privacy Enhanced Mail (PEM) effort [lo-l 3] by the Internet community can be used without 767
J. 0lneslEDIFACT
security made simple
public key encryption, but will probably even then lack the necessary efficiency. Also, PEM is designed for person-to-person communication, not communication between applications. USC of (some of) these standards is a long-term goal for EDIMED, but, on a short and medium term, other solutions must bc found. 3. EDIMED
security
in context
The EDIMED security system encounters wirctapping, forging, unauthorized changes and other threats to message communication bctwccn applications. Thcsc threats arc minor compared to other threats in most cnvironmcnts. Rather than wiretapping single messages, an intruder will try to gain access to all information in the system, by compromising the computer holding the information, or possibly by stealing backup tapes. Usually, the weak points hcrc arc password security and lack of physical protection. If wiretapping is considered a serious threat, thcrc is a lot of other network traffic which needs to bc protected. On most network systems, when a user logs in, the password is transferred in clear on the network. Wiretapping passwords is clearly more viable than wiretapping single messages. During client/server processing, communication bctwccn client and scrvcr is usually not encrypted. Thus, even if the server obtains the data through a secure EDIMED interchange to its database, the data may later be transferred in clear on the network if acccsscd by a remote client. Terminals (Xterminals or others) connected to their processing computer over a network may be an even grcatcr risk. The conclusion is that strong security in mcssagc communication is rather meaningless unless other, more important, threats are encountcrcd. Howcvcr, on designing the EDIMED security system, we must simply assume that these other security measures arc in place, and make sure that the security of our system is strong enough.
768
4. EDIMED 4.1.
Demands
and application
security
on the applications
As stated earlier, EDIMED is a collection of libraries linked to the applications wishing to communicate. It is reasonable to demand sonic security scrviccs to be performed by the applications: l identification and authentication of human users; applications accessing scnsitivc information are obliged to use proper authentication mcchanisms by Datatilsynet’s rules, so this is not a new rcquircmcnt from EDIMED; l access control, i.c. to verify that the sender is allowed to transmit the information, and that the rcccivcr is allowed to receive it; these requirements for applications arc also already present in Datatilsynct’s rules.
In short, EDIMED trusts the identification of sender and rcccivcr given at the session establishment time, and trusts that the information transfers will bc according to access rights. authentication a password-based Code for mechanism is already prcscnt in EDIMED, but it is not used. WC do not see any real advantage in this, and we do not want to bother the users with the overhead of yet another authentication check. Handling access control within EDIMED will bc very complicated. EDIMED’s task is far simpler when the communication system does not need to know what kind of data it is transmitting
4.2.
Demands
on EDIMED
To fulfil the requirements, EDIMED must provide the following security scrviccs to the applications: l peer entity authentication: the sending application, on supplying the identity of the receiver, must have confidcncc that the message will be delivered only to the intended recipient; the receiver, on the other hand, must know that the message was indeed sent by the claimed sender;
Computers & Security, Vol. 12, No. 8
l integrity of the messages; i.e. prcvcnt unauthorized or accidental change, loss or duplication of messages; l confidentiality of the messages; i.c. unauthorized or accidental disclosure message contents;
non-repudiation of through encrypted logs. l
sending
and
prcvcnt of the
reception,
5. EDIMED’s solution 5.1. Addressing
EDIMED offers exchange of EDIFACT messages bctwccn applications in different organizations using X.400. In EDIMED’s addressing scheme, an X.400 O/R-address identifies application and location, c.g. a laboratory system at a given hospital. For some data, Datatilsynet’s rules demand identification of the person(s) sending and receiving the data. Since EDIMED lcavcs access control to the applications, such information must bc carried in the mcssagcs thcmsclvcs, and the applications must ensure that the data is given only to the authorized person(s). This addressing scheme is in accordance with the guidclincs of “Norsk TEDIS”, the Norwegian EDIFACT organization, and “NOSIP”, the Norwegian OS1 Profile. 5.2. Registration
of users
The sender and rcccivcr applications (“users”) are identified over the EDIMED API by “nicknames” which, at a particular site, arc unique, user-friendly names. Mapping bctwccn nicknames and O/Raddresses is done by the EDIMED user directory. The O/R-addresses are used as indexes in the security directory. Before any communication can take place between a pair of communicants, the address information must be installed in the directories on both sides;
i.e., a prior agreement must exist between the two parties. EDIMED is delivered with support programs to maintain the directories. Since only registered addresses can bc used, an intruder cannot easily force traffic to be sent to an unknown address. Currently, both dircctorics are local to each installation of EDIMED. Later, X.500 may be used for the user directory, which may then be non-local. WC wish to avoid transmission of key information over a network from a non-local directory, which is why the security information is kept in a separate directory. USC of X.500 to hold security information (other than certificates, which WC will not use) is for further study by the standards bodies. 5.3. Encryption
in EDIMED
EDIMED encrypts whole messages, i.e. the complete body part of the X.400 messages, using the DES algorithm with different encryption keys for each pair of O/R-addresses. Encryption is cnd-toend between the scndcr and the final receiver. EDIMED supports all DES modes, but due to the combined security and efficiency rcquircmcnts, we rccommcnd CBC (Cipher Block Chaining) mode. A zero initialization vector is always used. Optionally, the binary result of this encryption is translated to a hex rcprcscntation, i.e. ASCII cncodcd, before transmission. Binary data is not handled by all mail systems. Marc compact encoding, e.g., “uucncodc”, can bc used later on. 5.4. Logging
EDIMED will always log a unique identification of all X.400 messages sent or received. In addition, there are three configurable modes for message logging: 0 no logging; l all messages are logged in clear text, i.e. after decryption; l
the encrypted messages are logged.
769
J. 0lneslEDIFACT
security made simple
Usually the third alternative will be used, since Datatilsynet demands, under some circumstances, an encrypted log. If the transmitted data is less sensitive, logging may be in clear text, or if the application itself handles logging, logging may be turned off In an encrypted log, the X.400 messages are logged as sent or received, i.e. with the header, including the O/R-addresses, in clear text, and the body part encrypted as during transmission. A separate program is written to retrieve information from a log. A search is based on one or several of the following criteria: l
sender nickname or O/R-address;
l
receiver nickname or O/R-address;
l message identification, message id.log;
time interval, given interval. l a
as fetched
from
the
i.e. messages sent during
the
A list of all messages selected by the given search criteria results, and the messages to display are then selected from this list. To display a message, the log retrieval program searches the security directory for the DES key used for communication between these two O/R-addresses at the time the message was sent or received (see Section 7), and uses this key to decrypt the message.
6. Fulfilling 6.1.
the demands
Faking or changing result in selection of masquerade attack masquerading entity correct key. 6.2.
an address in a message will the wrong decryption key. A can succeed only if the is already in possession of the
Integrity
Reliable transfer of messages within reasonable time is a function of the communication services. However, extra protection against deliberate changes is necessary. Since the complete message contents are encrypted, it is not necessary to add a separate checksum. Instead, the encrypted EDIFACT decoding can be relied upon to catch such errors: l any change to an encrypted message will propagate to a large portion of the decrypted message; garbage will result, and the EDIFACT dccodcr will dctcct this; l most EDIFACT messages include a checksum which is transmitted along with the message itself in the encrypted data; even if the checksum algorithm is rather weak, it will catch changes to messages with a very high probability.
Duplicate messages are detected by means of the unique message identification from the X.400 header, or, if this header has been tampered with in a replay attack, by the reference numbers in the EDIFACT headers, which of course are encrypted.
Peer entity authentication
Use of different DES keys for each pair of O/Raddresses gives a strong proof of the identity of sender and receiver. At the sending side, the key is determined by a look-up based on the O/Raddresses supplied. Only these two parties know the key, which means that the sender can be confident that only the intended receiver can decrypt the message. At the rccciving side, the key is found
770
based on the O/R-addresses in the incoming X.400 message. Successful decryption proves that the correct key was used, i.e. that both O/R-addresses are correct.
Loss of messages must be detected by the communication services. Use of the X.400 delivery confirmation option is recommended. 6.3.
Confidentiality
DES encryption of the complete message contents ensures that a wiretapper, or someone else who can get hold of a message, needs to go through con-
Computers & Security, Vol. 72, No. 8
siderable efforts to decrypt the message. Whether or not the DES algorithm is considered to be strong enough is dependent on the data to protect. In a health care environment, where little economic gain can be expected from unauthorized access to data, it is our view that DES encryption is sufficient. This view is shared by the Norwegian authorities.
w_bgon
sec_all_eocrypt
sec_logoff
Security cache library t
1
DES library
If a message, or a copy of a message, is deliberately or by accident sent to a wrong receiver, the receiving entity will never know the correct DES key, and will need to go through large efforts to decrypt. 6.4. Non-repudiation
Encrypted logging of each message on both the sending and the receiving side gives a weak nonservice. Since the message is repudiation encrypted with the key shared by the two communicants only, decryption yields evidence that sender and receiver are the same as indicated in the message. However, nothing prevents authorized users on either side from deleting entries in the log. Furthermore, since the key is stored locally in the security directory, it is possible, through clever programming, interfacing to the EDIMED libraries, to decrypt a logged message, change it, reencrypt and re-insert it in the log. The risk of anyone going through these efforts is sufficiently small that Datatilsynet accepts encrypted logging at both sides as a non-repudiation service. With the aid of a third party, it is very simple to base a strong non-repudiation (notary) service on EDIMED’s encryption scheme. Simply send a copy of each message to the third party for logging, and make sure that this party is never in possession of any of the keys used. On disputes, the sender or receiver must provide its security directory file, and the notary can decrypt the messages in question on the basis of the keys stored in this directory. 7. Design
of the security
system
The modules of the security system are shown in Fig. 2. The interface to the rest of the EDIMED
Fig. 2. Modules
of the EDITED
Security directory (on file)
security
system.
system is strictly limited to three calls. Nowhere in the rest of the EDIMED system are any other functions or data structures in the security system referenced. l see_logon takes sender and receiver O/Raddresses as parameters. On the basis of these names, plus the current time, it fetches the appropriate information from the security directory to the security cache. l see-allencrypt takes the names of an infile and an outfile and an encrypt/decrypt flag as parameters. It encrypts or decrypts the contents of the infile, using the key information in the cache, and writes the result to the outfile. l set-logoff clears the security cache and other memory areas holding security-relevant information.
Selected field en- or decryption may be added later, if needed for efficiency reasons. In this case, an encrypted checksum must be added as well, to detect deliberate changes to unencrypted fields. Public domain DES implementations can be fetched from a variety of sources, with the constraint that one must be careful not to violate the export restrictions which apply from the USA and possibly also from some other countries. For EDIMED, we use a DES library which is call compatible with the DES library of Kerberos [l4], 771
J. (Zl/neslEDlFACT security made simple
which is the closest that one can get to a standard API for DES. Due to the storage limitations of old MS/DOS PCs, WC USCa stripped-down library for the MS/DOS version of EDIMED. The security cache holds the two O/R-addresses involved, identification of the DES mode to use, and the DES key schedule (16 X 8 = 128 bytes). We store a precomputed key schcdulc in the security directory and cache instead of just the DES key, primarily for efficiency reasons. Another reason is that this allows us to remove the rather large key schedule generation part of the code from the MS/ DOS version. The security directory consists of entries as shown in Fig. 3. Each entry consists of a pair of O/Raddresses, and one or several blocks of key information. The O/R-addrcsscs and identifiers for the key information fields are stored in clear text, while the values for the key information fields are encrypted and ASCII-encoded to avoid a binary file. A possible enhancement is to put down an
# Comment: This is an example only. First, the two O/R-addresses are # given, then a block of key information is shown. Several more such # blocks may follow. The 1’ is a line continuation character. A_or_country = no A_or_admd = vasp A_or_org = hospital \ A_or_orgunit = laboratory A_or_surname = “laboratory system”\ B_or_country = no B_or_admd = vasp B_or_org = “doctor hook” \ B_or_sumame = “infodoc system”\ time-from = Ox0123456789ABCDF \ OxOl23456789ABCDF\ time-to = Ox0123456789ABCDF\ OxO123456789ABCDF\ des_schedule = Ox0123456789ABCDF\ OxO123456789ABCDF\ OxO123456789ABCDF\ OxO123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ Ox0123456789ABCDF\ OxO123456789ABCDF1 Ox0123456789ABCDF \ Ox0123456789ABCDF1 OxO123456789ABCDF\ Ox0123456789ABCDFI OxO123456789ABCDFI OxOl23456789ABCDF \ des_mcde = Ox01234567 ‘89A,BCDF \ \ time-from = Ox0123456789ABCDF .... .... . Fig. 3. Format
772
of an entry in the security
directory.
encrypted checksum for each entry, to detect changes to the clear text fields. Each key information block includes the DES mode and key schedule to use, plus two time stamps giving the validity period for this key information. To speed searching in the directory, the most recent key information is stored as the first block. Key information may be specified to take effect some time in the future. EDIMED will starch the cntrics on the basis of the current time, while the log retrieval program scarchcs the directory on the basis of the timestamp of the message to retrieve.
8. Key administration Certificate-based key administration and use of X.509 is definitely a long-term goal for EDIMED, but this is prohibited on a short and medium term due to the processing rcquircmcnts. Use of Kerberos [I41 for k cy ad ministration was invcstigated, but dropped mainly because of the rcquircments for clock synchronization. The solution is to come up with a good scheme for manual key distribution. The Financial Institution Key Managcmcnt Standard [I 51 was a candidate, but was considered unnecessarily complicated for our purpose. Instead, we set out to define a simple method oursclvcs. Typically, EDIMED will be used for communication bctwccn some service provider, e.g. a hospital, and customers, e.g. private practitioners. It is for key reasonable to place the responsibility management on the provider, which presumably has well established routines for running its computer services. The provider is responsible for periodic key changes, and instructs its customers on the matter. EDIMED uses the “password to DES key” algorithm of Kerberos. It is dcfinitcly easier, especially for an unskilled user, to enter a password string without errors instead of the hex value of an eight-byte key. In addition, users know what a password is; they do not want to know what a DES key is.
Computers & Security, Vol. 12, No. 8
Few applications in a health care environment will generate heavy EDIMED traffic. The risk of someone trying to break the DES encryption is also typically very low. Thus, periodic key changes a few times per year should be sufficient. For periodic key changes, the operator at the responsible institution enters EDIMED’s key administration program, and specifies that update to all entries in the security directory should be done. She is then prompted for the DES mode to use, and the time when the new keys should take effect. New key information entries are then automatically generated for all pairs of O/R-addresses in the directory. The keys themselves are generated by a “random” password generator. Each password is transformed to a DES key, and then to a key schedule. In addition, a file is generated, with one entry for each pair of communicants. On such an entry, the names of the communicants, the DES and the password are mode, the timestamp, written. The file is printed on paper, one entry on each page, and deleted. Each page of information is then signed and sealed by the responsible person, and sent to the appropriate other party by ordinary mail. Electronic mail or telephone is not secure enough for this kind of key information exchange. On receiving the letter with the key information, the other party enters the key administration program in another mode, specifying a change to one entry only. She then enters the names idcntifying the entry to update and the information in the letter, including the password for the new key. This mode of the key administration program is also used at both sides when new pairs are installed, and for changes outside the periodic schedule, e.g. if one suspects that a key has been compromised. “Random” passwords can be used, since a password is only entered once on each side and can be forgotten afterwards. The key information is stored “forever” in the directory.
9. X.400
communication
alternatives
A large institution, such as a hospital, will typically have its own X.400 MTA (Message Transfer Agent) Medium-size with appropriate connec dons. institutions can subscribe to a public X.400 service, such as Norwegian Telecom’s “TelemaX400”, and connect via the P7 protocol of X.400. However, until public X.400 services get cheaper, small customers cannot even afford the latter solution, so EDIMED had to come up with yet another altcrnative. The solution is to run the X.400 part of EDIMED on a remote computer, typically the (UNIX) computer running the MTA of the service provider, e.g. the hospital. Referring to Fig. 1, the customer will run an EDIMED version with the X.400 module removed. Instead, when it is time to wrap the EDIFACT interchange in an X.400 message, this EDIMED version will establish a modem connection to a specified phone number and prompt the user for name and password to the remote computer. This is not an ordinary login, but rather a name/password combination for access to an “EDIMED server”. The data to include in the X.400 message is then transferred over the modem connection. All other modules, including the security part and logging, run on the customer’s computer, which means that all messages are still encrypted truly end to end. However, the login part needs extra protection. The user name is sent in clear text from the customer to the EDIMED scrvcr. The user name can be used as an index in a table to find the appropriate key for this user. The EDIMED server picks a “random” value, which it encrypts and returns to the customer. At the customer’s side, this is decrypted, the password is appended to the random value, and the result is rc-encrypted and sent to the server. The server verifies the password for authentication, and checks the random value for replay
773
J. 0lneslEDIFACT security made simple
attacks. Although this may not be a strong protocol, it gives a reasonable level of protection.
10. Conclusion EDIMED is in daily use, with several applications for communication between private practitioners and hospitals in Norway. So far, the security system has proven to be efficient enough, and easy enough to administrate. The strength of the system, securitywise, has not been challenged, but we believe that the design and the algorithms used provide a good level of security. EDIMED has been certified by the Norwegian authorities as suitable for electronic interchange of very sensitive health care information. In the near future, EDIMED will also be used for other purposes than health care information, e.g. in the commercial world. We believe that the system, with the current manual key distribution scheme, can serve a substantial number of users.
References [l] USA HL-7 Development Group, Health Industry Level 7 Interface Standards, Version 2.1 (draft), December 1989. [2] J.J. Harrington, T.J.R. Benson and A.L. Spector, IEEE I-‘1157 Medical Data interchange (MEDu() Committee. Overview and Status Report, SCAMC, Washington, November 1990.
774
PI
ODETIE (Organization for Data Exchange by Tcle Transmission in Europe), OFTP Specification, Rev. 1.2, November 1986. PI G. Hannemyr and 0. Hanseth, Development of Medical Informatics within MEDIX, NR Report 849, Norwegian Computing Centre, July 199 1. Datatilsynet, Report to the Department of Justice from the Working Group on Guidelinesfor Security ofInformation about Persons, November 1987 (in Norwegian-draft of new rules exists). National Bureau of Standards, Data Encryption Standard, FIPS Publication 46, January 1977. PI CCITT, X.41 1: Message Handling Systems, Message Transfer System, Abstract Service Definition and Procedures, 1989. PI CCITT, X.435: Message Handling Systems, MHS Application for EDI Messaging, 199 1. (91 CCITT, X.509: The Directory-Authentication Framework, 1989. [ 101 J, Linn, Privacy Enhancementfor Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, Internet request for comments, RFC 142 1, February 1993. [ 111 S. Kent, Privacy Enhancementfor Internet Electronic Mail: Part II: Certij’icate-based Key Management, Internet request for comments, RFC1422, February 1993. [ 12) D. Balenson, Privacy Enhancementfor Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, Internet request for comments, RFCl423, February 1993. [ 131 B. Kaliski, Privacy Enhancement Jar Internet Electronic Mail: Part IV: Key Cert$cation and Related Services, Internet request for comments, RFCl424, February 1993. [14] J.G. Steiner, C. Neumann and J.I. Schiller, Kerberos: an authentication service for open network systems, Proceedings of the USENIX Winter Conference, February 1988. [ 151 American National Standards Institute, Financial Institution Key Management (Wholesale), American National Standard X9.1 7. 1985.
151
161