COMMITTEE EDIFACT DRAFT CD 9735-7 Release 10 1996-0607-1526 Electronic data interchange for administration, commerce and transport - (EDIFACT) - Application level syntax rules. Part 7: Security rules for batch EDI (confidentiality). This part is based on Part 5, version 3.1 dated July 25th after revision by ISO experts. Thanks for your collaboration. Jean-Louis Barbut GSIT - France Contents Page Foreword 4 Introduction 5 1 Scope 6 2 Conformance 6 3 References 6 4 Definitions 7 5 Rules for batch EDI confidentiality 8 ANNEX A: Message protection example 12 Foreword (To be amended as necessary, according to ISO procedures) ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. Draft International Standards adopted by the technical committees are circulated to the member bodies for approval before their acceptance as International Standards by the ISO Council. They are approved in accordance with ISO procedures requiring at least 75% approval by the member bodies voting. International Standard ISO 9735-1 Version 4 was prepared by the UN/ECE Trade Division (as UN/EDIFACT) and was adopted, under the "fast-track procedure" as an existing standard, by Technical Committee ISO TC 154, Documents and data elements in administration; commerce and industry. ISO/IEC 9735 consists (currently) of the following parts, under the general title Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules: ISO 9735-1 - Syntax rules common to all parts and the syntax service directories ISO 9735-2 - Syntax rules specific to batch EDI ISO 9735-3 - Syntax rules specific to interactive EDI ISO 9735-4 - Syntax and service report message for batch EDI (message type - CONTRL) ISO 9735-5 - Security rules for batch EDI (authenticity, integrity and non- repudiation of origin) ISO 9735-6 - Secure authentication and acknowledgement message (message type - AUTACK) ISO 9735-7 - Security rules for batch EDI (confidentiality) ISO 9735-8 - Associated data in EDI ISO 9735-9 - Security key and certificate management message (message type - KEYMAN) Further parts may be added in the future. Introduction This International Standard includes the rules at the application level for the structuring of data in the interchange of electronic messages in an open environment, based on the requirements of either batch or interactive processing. These rules have been agreed by the United Nations Economic Commission for Europe (UN/ECE) as syntax rules for Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) and are part of the United Nations Trade Data Interchange Directory (UNTDID) which also includes both batch and interactive Message Design Guidelines. These syntax rules may be used in any application, but messages using these rules may only be referred to as EDIFACT messages if they comply with other guidelines, rules and directories in the UNTDID. For UN/EDIFACT, messages shall comply with the message design rules for batch or interactive usage as applicable. These rules are maintained in the UNTDID. Communications specifications and protocols are outside the scope of this standard. This is a new part, which has been added to ISO 9735. It provides an optional capability of applying confidentiality to an EDIFACT structure i.e. message, package, group or interchange. Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules Part 7: Security rules for batch EDI (confidentiality) 1 Scope This International Standard for EDIFACT security addresses message/package level, group level and interchange level security for confidentiality in accordance with established security mechanisms. 2 Conformance Conformance to a standard means that all of its requirements, including all options, are supported. If all options are not supported, any claim of conformance shall include a statement which identifies those options to which conformance is claimed. Data that is interchanged is in conformance if the structure and representation of the data conforms to the syntax rules specified in this International Standard. Devices supporting this International Standard are in conformance when they are capable of creating and/or interpreting the data structured and represented in conformance with the standard. Conformance shall include conformance to Part 1, Part 2, Part 5 and Part 8 of this International Standard. When identified in this International Standard, provisions defined in related standards shall form part of the conformance criteria. 3 References 3.1 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards. ISO 10181-5 Information technology - Security frameworks for Open Systems - . Part 5: Confidentiality framework 4 Definitions For the purpose of this International Standard, the definitions in Part 1 annex A and in Part 5 annex A apply. 5 Rules for batch EDI confidentiality 5.1 EDIFACT confidentialitysecurity The security threats relevant to message transmission and the security services which address them are described in Part 5 of this International Standard, annexes C and D. This section describes the solution to provide EDIFACT structures with the security service of confidentiality. 5.1.1 Integrated message confidentiality Confidentiality of an EDIFACT structure (message, package, message group or interchange) shall be provided by encrypting it, using an appropriate cryptographic algorithm. The encrypted structure shall be considered by any EDIFACT translator as an object, as defined in Part 8 of this International Standard. This encrypted object may be filtered for use with restricted capability telecommunication networks. The following sections 5.2 and 5.3 describe how object header and trailer and security header and trailer are used together to provide the security service of EDIFACT confidentiality. 5.2 Use of object header and object trailer segments for confidentiality As defined in Part 8 of this International Standard, a package shall be constructed with the encrypted structure as its object. This object shall be identified in the object type qualifier data element as a either "encrypted interchange", or " encrypted group", or " encrypted message" or " encrypted package". When confidentiality is applied to one message, if needed, the message type of the encrypted message may be copied in its readable plain text form in the reference identification of the object header segment. This may allow the recipient of the package to determine the nature of the encrypted message without decrypting it. The encrypted object shall start immediately after the separator ending the USH segment group. 5.3 Use of security header and security trailer groups for confidentiality As defined in Part 5 of this International Standard, a security header segment group after the UNO segment, and a security trailer group before the UNP segment shall be included. The security header group used for confidentiality is the standard security header described in Part 5 of the present International Standard. The security trailer group used for confidentiality is the standard security trailer described in Part 5 of the present International Standard. When used for confidentiality, it shall contain only a UST segment. For an object containing an encrypted EDIFACT structure, there shall be only one confidentiality security header group and one related security trailer group. If there is a need for an EDIFACT structure to be encrypted or decrypted independently by different parties, several packages shall be constructed, each one containing an occurrence of the encrypted EDIFACT structure, with their own confidentiality security header and trailer groups. Once an object has been encrypted, no other security services shall be provided to it. If other security services, besides confidentiality, need to be applied to the EDIFACT structure, they shall be applied on the plain text content of the EDIFACT structure, before encryption, according to the rules defined in Part 5 of this International Standard. In this case, the encrypted object will include, in an encrypted form, standard security headers and trailers. 5.4 Principles of usage 5.4.1 Choice of service The standard security header group of the package may include the following general information: Identification of the entities involved Security mechanism identifier "Unique" value (sequence number and/or time stamp) Non-repudiation of receipt request Use is made of a code to indicate the applied security service (here confidentiality of content). If more than one security service is required at the same time, apart from confidentiality, this shall be done, according to the rules defined in Part 5 of this International Standard, before encryption by the entity sending the EDIFACT structure, and the related verifications shall be performed after decryption by the receiving entity. 5.4.2 Confidentiality If confidentiality of an EDIFACT structure is required, it shall be provided in accordance to the principles defined in ISO 10181-5 "Security frameworks for Open Systems- Part 5: confidentiality framework". The security service of confidentiality shall be specified in the security header group of the package used to convey the encrypted object, and the algorithm shall be identified in the USA segment in segment group 1. This USA segment may also contain the data necessary to establish the key relationship between the parties acting as security originator and security recipient. The party acting as security originator shall encrypt the EDIFACT structure, from the first character of its syntactical header, to the last separator ending its syntactical trailer, and consider the result as an encrypted object. Upon reception of a package containing an encrypted object, the party acting as security recipient shall decrypt the encrypted object and thus shall recover the plain text EDIFACT structure. 5.4.3 Internal representation and filter functions The result of the encryption process is a seemingly random bitstring. This may cause difficulties with certain restricted capability telecommunication networks. To avoid this problem, the bitstring may be reversibly mapped on to a particular character set by means of a filtering function. The consequence of using a filtering function is to expand the size of the encrypted data. Different filtering functions may be used which have slightly different expansion factors. Some may allow the filtered text to contain any character of the target character set, including control characters such as segment tags or segment separators, whereas other filter functions may filter out these control characters. In any case, the length of data conveyed in the data element length of object in octets in the UNO segment shall represent the length of the encrypted and filtered data, and shall be the only reliable means of determining the end of the encrypted object. 5.4.4 Use of compression techniques before encryption The computing cost of encryption being directly related to the size of the data to encrypt, it may be useful to compress the data before encryption. Compression also saves on transmission costs. Most compression techniques would not be efficient on encrypted text, even filtered, thus if compression is required, it shall be applied before encryption. Consequently, when it is used for the confidentiality security service, the security header group may contain the indication that data have been compressed before encryption, and may identify the compression algorithm used. In such a case, after decryption of the object, data shall be decompressed before the EDIFACT structure is recovered. 5.4.5 Processing order of operations When processing an EDIFACT structure to provide confidentiality, operations shall be performed as follows: 1. secure the EDIFACT structure for any security service besides confidentiality (optional) 2. compress the EDIFACT structure (optional) 3. encrypt the (compressed) structure 4. filter the encrypted object (optional) When processing an encrypted object to recover a plain text EDIFACT structure, operations shall be performed as follows: 1. unfilter the filtered encrypted object (optional) 2. decrypt the encrypted object 3. decompress the decrypted data to recover the EDIFACT structure (optional) 4. check security applied on the EDIFACT structure for any security service besides confidentiality (optional) 5.5 Batch EDI confidentiality within an interchange Figure 1 represents the structure of an interchange containing one secured message (similar figures could illustrate application of confidentiality to packages, groups or interchanges). Figure 1 - Structure of an interchange containing one encrypted message (schematic) THIS SCHEMATIC IS NOT AVAILABLE IN ASCII.FORMAT. ANNEX A (informative) MESSAGE PROTECTION EXAMPLE One example is provided herein to illustrate application of security service segments. This example of message confidentiality is based on EDIFACT payment orders as described in the MIG handbook of Financial messages published by SWIFT, with similar presentation rules. However, the security mechanisms described here are totally independent of the type of message and may be applied to any EDIFACT message. This exemple shows how security service segments may be used when a symmetric algorithm based method is applied, to provide message content confidentiality. The symmetric key has been exchanged previously between the partners, and the security header group contains only two rather simple segments. A.1.1 Narrative Company A orders Bank A, sort code 603000 to debit its account number 00387806 on April 9th 1995 in the amount of 54345.10 Pounds Sterling. The amount is to be paid to Bank B, sort code 201827, in favour of account number 00663151 of Company B, West Dock, Milford Haven. The payment is in settlement of invoice 62345. The contact name at the Beneficiary is Mr. Jones in the Sales Department. Bank A requires the payment order to be secured by the security function "message confidentiality". This is achieved by encrypting the message body with the symmetric "Data Encryption Algorithm" (DEA) at the message sender's side. It is assumed that the secret DEA-key has previously been exchanged between Company A and Bank A. Remark: In the following, only the security header and trailer groups of the resulting package will be referred to. A.1.2 Security details SECURITY HEADER SECURITY SERVICE Message confidentiality SECURITY REFERENCE The reference of this header is 1 NUMBER FILTER FUNCTION All binary values are filtered with hexadecimal filter ORIGINAL CHARACTER SET The message was coded in ASCII 8 bits ENCODING when as encrypted. SECURITY IDENTIFICATION DETAILS Message sender (party Mr. SMITH of Company A which encrypts the message). SECURITY IDENTIFICATION DETAILS Message receiver (party Bank A which decrypts the message). SECURITY SEQUENCE The security sequence number of this NUMBER message is 001 SECURITY DATE AND TIME The security time stamp is: date: 1995 04 09 time: 13:59:50 SECURITY ALGORITHM SECURITY ALGORITHM Use of algorithm A symmetric algorithm is used to achieve Message confidentiality Cryptographic mode of A Cipher Block Chaining mode is used. operation DES algorithm is used. algorithm ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier value as the name of a previously exchanged symmetric key. Algorithm parameter The key called ENC-KEY1 is used. value SECURITY TRAILER SECURITY REFERENCE The reference of this security trailer NUMBER is 1