Page 1 of 22

Danske EDIsec® System Description of the Solution

EDIsec ® is a registered trademark by Systematic Software Engineering A/S, Frichsparken, Søren Frichs Vej 38 K, DK-8230 Åbyhøj, Denmark.

Copyright © 1999 by Systematic Software Engineering A/S and Danske Bank A/S. It shall not be copied, reproduced, disclosed or otherwise made available

to third party without previous written consent from the copyright holder.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 2 of 22

Table of Contents 1 PURPOSE ...... 3

2 INTRODUCTION ...... 4

2.1 OUTLINE OF THE ASSIGNMENT ...... 4 2.2 OUTLINE OF THE SOLUTION...... 5 2.3 STRUCTURE OF THE DOCUMENT...... 7 3 DEFINITIONS AND REFERENCES ...... 8

3.1 ABBREVIATIONS AND DEFINITIONS...... 8 3.2 BIBLIOGRAPHY...... 9 3.3 REFERENCES...... 9 3.4 CRYPTOGRAPHIC TERMS...... 10 3.4.1 Fundamental Security Services ...... 11 3.4.2 Symmetrical System ...... 11 3.4.3 Asymmetrical System...... 12 3.4.4 Hybrid...... 12 4 OVERALL DESCRIPTION...... 13

4.1 FUNCTIONAL REQUIREMENTS...... 13 4.2 ALGORITHMS AND STANDARDS...... 14 4.2.1 Choice of Systems ...... 14 4.2.2 Consequences of the Choice of Systems ...... 15 4.3 DATA FORMATS...... 16 4.4 HANDLING OF KEYS ...... 17 4.4.1 Generation of an RSA Pair ...... 17 4.4.2 Storage of Keys...... 18 4.5 HANDLING OF SIGNATURES AND ENCRYPTION IN EDIFACT...... 19 4.6 USE OF FUNCTIONS IN THE API...... 20 4.7 LIMITATIONS...... 21

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 3 of 22

1 Purpose

This document provides the system description of the encryption solution for Danske Bank (DB). The purpose of the document is to describe the functional requirements of the solution.

This system description should be read by the developers and security personnel. It is assumed that the readers have a certain level of knowledge about EDIFACT and encryption in order to be able to assess all aspects in the system description. Such knowledge is not required, however, to gain a basic understanding of the overall solution.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 4 of 22

2 Introduction

This document provides the system description of the elements of the encryption solution for DB which are provided by Systematic Software Engineering (hereafter referred to as the encryption solution).

The encryption solution is integrated with DB’s own in-house system.

This chapter outlines the assignment commissioned by DB and the solution delivered by Systematic to DB.

Section 2.3 in this chapter explains how the rest of this document is structured. 2.1 Outline of the Assignment DB’s requirement is for a system that enables the exchange of Electronic Data Interchange (EDI) messages with its major business customers. All interchanges must be secure; the following security functions must be included in the solution (the terms are described in section 3.4):

· · secrecy · integrity · non-repudiation · protection against replay from the customer to DB

It is essential for DB that the system is simple to use, flexible and scaleable.

The solution must consist of two encryption modules; a customer module for integration with the customer’s own computer systems, and a DB module for integration with DB’s computer systems.

The customer module must include the following overall functionality:

· The ability to run on a number of different platforms and must therefore be flexible and as far as possible operating system independent · The module must include cryptographic functions for encryption and digital signatures

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 5 of 22

· The module must not be dependent on the platform’s file system and must be accessed through an API, where data and encryption keys are given as parameters · The module must be able to handle digital signatures from multiple users.

The DB module must have the following overall functionality:

· The ability to run within DB’s MVS environment · The module must include cryptographic functions for encryption and digital signatures · The module must not be dependent on the platform’s file system and must be accessed through an API, where data and encryption keys are given as parameters · There is no requirement to handle digital signatures from multiple users but the system must be able to return receipts for signed interchanges that are received.

In both cases it is not the responsibility of the encryption module to handle the transmission of data between DB and DB’s customers. Once the data has been encrypted and signed by the module, the sender’s own system is responsible for the sending of the data. Likewise, the receiver’s system will receive the data and call the encryption module for decryption of the interchange and validation of the signature.

There is no requirement for the encryption module to access a . 2.2 Outline of the Solution The Systematic solution is based on the EDIFACT standard. All data exchanged between DB and its customers will be in the EDIFACT format.

The cryptographic software supplied by Cryptomathic A/S is used to add the encryption and digital signatures to the interchanges. Cryptomathic’s software is used extensively within many existing systems worldwide and is therefore thoroughly proven.

Because the difference between the two encryption modules for DB and DB’s customers is very minor, only one module has been developed that incorporates all of the functionality required for both modules. All users will receive the same module. It is the configuration of each installation that will differ as it will be possible to opt out certain functionality as appropriate.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 6 of 22

The system in which the encryption module has been integrated will be referred to as the “in-house system” throughout this document. Where clarification is needed, the systems will be referred to as “DB’s in-house system” and “DB’s customers’ in-house system”, respectively.

Figure 1 describes the components and the data flow.

Key Key database = SSE delivery database

1 8

Sender's 2 10 Receiver's in-house Encryption- Encryption in-house module module system 3 9 system

4 7

Network Comms (e.g. VANS) Comms module 5 6 module

Figure 1: Components and data flow of the encryption solution

1 – 2: The sender’s in-house system supplies the data to be sent to the encryption module. This includes the identification of the receiver and the keys to be used for encryption/signature. The encryption module constructs an EDIFACT interchange containing the data received, signed and encrypted by the keys. Input to the encryption data may be binary data, but it will be handled differently depending on whether it is in EDIFACT or other format. 3 – 7: Once encrypted and signed, the EDIFACT interchange is returned to the in-house system and queued for sending. The encryption solution is independent of the chosen transmission method. 8 – 10: The receiver’s system receives the encrypted, signed EDIFACT interchange. This is passed to the encryption module along with the keys in order to decrypt the interchange and validate the signature. The encryption module then returns the interchange, now back in its original format, to the receiver’s system.

When the receiver has validated the signature of the interchange, the encryption module can generate a receipt, which is returned to the sender and validated by the sender’s encryption module. The receipt will follow the same flow as in Figure 1, but in the opposite direction.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 7 of 22

DB’s requirements for secure communications are met as follows:

· Authentication based on digital signatures applied to the interchanges · Secrecy based on the encryption of the interchanges · Integrity based on digital signatures applied the interchanges · Non-repudiation is mainly implemented in this solution by the users of the encryption module. The encryption module only support non- repudiation through digital signatures on the interchanges · Security against replay from the customer to DB is handled in this solution by DB’s in-house system. Systematic delivers a solution, however, where security can be implemented by DB without storing all transmitted data

The following platforms are supported:

· MVS · AS/400 · Unix · Windows

The following documents will be delivered to DB (in addition to this system description):

System Design: The design of the solution, to be reviewed by DB.

SAT Specification: A detailed description of all test procedures to be conducted in order to ensure a structured test of the entire system. The SAT specification must be approved by DB and will form the basis of a SAT (Site Acceptance Test) of the system.

API Documentation: Documentation of the module’s API to be applied by DB’s and their customers’ own systems developers in the integration of the encryption solution into the in-house systems. 2.3 Structure of the Document The remaining part of this document is structured as follows:

Chapter 3: “Definitions and References” describes the references to other documents and definitions used in this document.

Chapter 4: “Overall Description” gives an overall description of the entire encryption solution.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 8 of 22

3 Definitions and References

This chapter defines the terms and abbreviations used in this document. 3.1 Abbreviations and Definitions The abbreviations, definitions and terms used in this document are:

ANSI C American National Standards Institute’s standard for the programming language C.

API Application Programmers Interface. The interface of the encryption module against external applications, in the form of a library that can be linked to the current application.

AUTACK message A message in the EDIFACT standard used for signatures and receipts at security level.

Library A collection of functions in a linkable file, which can be linked into an application and called directly from the application.

DB Danske Bank

Data Interchange An interchange between DB and DB’s customers. It is a data interchange that is given as input to an encryption module when sending. A data inter- change may be in EDIFACT or other format.

EDI Electronic Data Interchange of documents, typically business documents.

EDIFACT Electronic Data Interchange For Administration, Commerce and Transport. ISO 9735 standard for formatting of documents exchanged via EDI.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 9 of 22

EDIFACT One or several EDIFACT messages containing Interchange control information, to be regarded as a kind of envelope. The control information includes sender and receiver addresses.

EDIFACT A single document in EDIFACT format starting with Message a UNH segment and ending with a UNT segment.

Encryption Module A library containing all the functions which constitute the encryption solution.

Module Encryption module in short.

Platform The term platform covers a well-defined operational environment comprising hardware and operating system.

SAT Site Acceptance Test. The hand-over test that the encryption module must pass to be approved.

SAT Specification A detailed description of the SAT to be conducted.

Software Requirements introduced in this document. Relating Requirements rather to the implementation than to requirements in the contract and are consequently more useful in connection with tests.

3.2 Bibliography References to other documents appear in the form of [REFERENCE]. 3.3 References The following documents are relevant for this system description:

[KONTR] The contract between DB and Systematic (document SSE/94221/CNT/050).

[DBSRS] DB’s system description of the part of the encryption solution implemented by DB.

[ISO 10116] Standard describing”Cipher Block Chaining” (CBC).

[ISO 8859-1] Standard describing the character set used in the EDIFACT documents.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 10 of 22

[FIPS 180-1] SHS-1 standard describing ”Secure Hash Algorithm” (SHA). Issued by the NIST (National Institute of Standards and Technology). See also (http://csrc.nist.gov/fips/).

[ISO 9735] Description of the EDIFACT standard.

[SCHNEIER96] Applied , Second Edition by Bruce Schneier, Wiley 1996.

[RSAFAQ] Answers to Frequently Asked Questions About Today’s Cryptography, version 3.0 by RSA Laboratories (http://www.rsa.com/rsalabs/).

[ODLYZKO95] A. M Odlyzko’s article, The Future of . (CryptoBytes, vol 1, no. 2, 1995).

[RSANEWS] The Technical newsletter of RSA Laboratories, see (ftp://ftp..com/pub/cryptobytes/crypto1n2.pdf)

[RSAPKCS93] PKCS standard from RSA “RSA Data Security, Inc. Public-Key Cryptography Standards (PKCS)” 1993. 3.4 Cryptographic Terms This section gives a brief definition of the cryptographic terms used in the encryption solution. For further information, see [SCHNEIER96] and [RSAFAQ].

A cryptographic system consists of an algorithm for encryption and an algorithm for decryption. Both algorithms are controlled by a key. As algorithms for commercial use are typically public, security depends on the keys used.

A distinction is made between symmetrical and asymmetrical systems. In symmetrical systems, the same key is used to encrypt and decrypt a text. In asymmetrical systems, a private key and a public key are used. The private key must be kept secret, whereas the public key is used by others who wish to communicate with the holder of the private key. An example of a symmetrical system is DES, whereas RSA is asymmetrical.

In addition to symmetrical and asymmetrical systems, cryptographic hash functions are used. This function can produce from a message a short bit string (typically 128 or 160 bits) that represents the original message in the

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 11 of 22

sense that no messages can be depicted in identical short bit strings. The following terminology is used:

Checksum - a bit string achieved by calculating the hash value of a message. A checksum is a binary value that will typically be difficult for a person to read. Consequently a fingerprint is introduced.

Fingerprint - a human readable representation of the checksum. As an example, a hexadecimal representation can be used in which a checksum of 20 bytes is described by 40 characters. 3.4.1 Fundamental Security Services Cryptographic systems can be used for the following security services:

Authentication (also called sender authentication) means that the receiver can be certain who originated and/or sent the message. Authentication is achieved either by an electronic signature or by a MAC (Message Authentication Code).

Integrity means that the receiver can verify that the information has not been changed during the transmission. Integrity is a consequence of sender authentication, but in some cases only integrity is needed and not authentication.

Secrecy means that the information cannot be read by a third party during the transmission. This is achieved by encryption.

Non-repudiation means that the sender cannot later deny having sent the information at a given time. Non-repudiation requires digital signatures. 3.4.2 Symmetrical System A symmetrical system is generally very fast and can be used for encryption or authentication by means of MAC values as follows:

Encryption The text is encrypted with the secret, shared key. The receiver can then decrypt it by using the same key.

MAC The sender calculates a MAC value on the basis of the secret, shared key and the message. The receiver can make the same calculation from a message and its related MAC value, and will only accept if the MAC value received can be recalculated.

The use of symmetrical systems requires the distribution of secret keys between the communicating parties. When several parties are communicat-

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 12 of 22

ing, it will be necessary to replace the keys if one of the parties is no longer reliable. One disadvantage is that new keys have to be distributed via an insecure channel, e.g. a floppy disk.

A further drawback is that MAC values cannot be used for non-repudiation. 3.4.3 Asymmetrical System The issue of key distribution is easier in an asymmetrical system as only public keys need to be distributed. They need not be kept secret. Only authentication and integrity in the distribution are required (in order to verify that the public key has not been changed and whom it belongs to).

By using two keys, a public and a private, several advantages are gained.

Encryption The text is encrypted with the receiver’s public key. Only the receiver’s private key can then decrypt the text.

Signature A checksum for the text is calculated and encrypted by the sender’s private key. If the text must be signed and encrypted, it will be signed first.

Validation The receiver of a text calculates a checksum by the same hash algorithm as used for signing. This checksum is compared with the signature received and decrypted with the sender’s public key. If it is identical, the signature of the text is verified.

The disadvantage of asymmetrical systems is that they are operationally slower than symmetrical systems. 3.4.4 Hybrid In order to combine the advantages of asymmetrical and symmetrical systems, encryption in a symmetrical system is often achieved by means of a session key. The session key is generated at random and only used once. The text is encrypted with the session key, and the session key itself encrypted with the receiver’s public key by means of an asymmetrical system. Both are sent, and the receiver is able to decrypt the text after decrypting the session key.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 13 of 22

4 Overall Description

This chapter provides an overall description of the functional requirements of the encryption solution and the security aspects.

Section 4.1 describes the functional requirements of the encryption solution.

Section 4.2 describes the cryptographic systems chosen for the encryption solution and the key lengths chosen for each system. Furthermore, the level of security that these choices imply is described.

Section 4.3 presents the format of the data interchanges exchanged through the encryption module.

Section 4.4 describes how the keys for encryption and signing are handled in the system.

Section 4.5 describes how the EDIFACT format is used for encryption and signing.

Section 4.6 describes the use of the functions in the API.

Section 4.7 describes the limitations to the encryption solution. 4.1 Functional Requirements As mentioned previously, the encryption module must handle encryption and signatures. This section provides more in-depth information about the requirements of the encryption module.

The encryption module must support multiple users of the in-house system. This is achieved by the identification of all keys by a key ID that must be stated at all API calls. Then the encryption module can attach control information about the key used for the signature and/or the encryption. The in-house system using the encryption module then makes a connection between the key IDs and the users.

The encryption module can add multiple signatures to an interchange so that multiple users can sign the same interchange simultaneously. The encryption

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 14 of 22

module supports this, as the function to sign can be called several times, one after another, adding a signature at each call. Information relating to the key- ID of the key used for the signature is attached to each signature.

When an encrypted and/or signed interchange is received, the encryption module notifies the in-house system about the key-ID of the key used for signing and/or encrypting.

The encryption module must make available a function to convert characters between the character set used on the platform in question and the character set ISO 8859-1 used by the secured EDIFACT documents.

The encryption module can generate the RSA keys used for signing and encrypting. The private keys must be encrypted under a password that is generated by the in-house system.

The encryption module can generate an AUTACK message as receipt of an interchange and of all signatures on the interchange. The receipt must be generated by a function that can be called by the in-house system when all signatures on the interchange have been validated. The in-house system then determines whether a receipt must be generated, and when.

Similarly, the encryption module can validate an AUTACK receipt. 4.2 Algorithms and Standards This section describes the specific standards and encryption systems used in the encryption solution. 4.2.1 Choice of Systems The systems and key lengths have been chosen with a view to achieving a fast and efficient solution as well as a high level of security.

Symmetrical System For the symmetrical encryption system, triple-DES is used with a key length of 112 bits.

Asymmetrical System RSA with optional key lengths of 1024 and 2048 bits are used for the asymmetrical system. The solution will allow configurable key lengths within the individual encryption modules.

Secrecy A hybrid solution with a random session key of 112 bits is used for symmetrical encryption. The session key is encrypted using the receiver’s public RSA key.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 15 of 22

Signature A checksum of the message is signed by the sender’s private RSA key. The checksum is calculated by SHA (Secure Hash Algorithm) as described in the SHS-1 standard [FIPS 180-1]. The signature must comply with the PKCS#1-standard [RSAPKCS93].

Cipher block chaining, (CBC) described in ISO 10116 (Modes of operations for an n-bit ), is used to secure against any removal of separate encryption blocks (parts of the encrypted text). 4.2.2 Consequences of the Choice of Systems With reference to [ODLYZKO95] and [RSANEWS], the following conclusions on the choice of systems are reached: The algorithms chosen and the key lengths suggested (1024-2048 bits for RSA and 112 bits security for symmetrical encryption) are de facto standard in applications using cryptography today.

Both RSA and triple-DES are well known and have been thoroughly tested during the past 20 years. Security is mainly based on key lengths. Consequently, the security of the systems is mainly dependent on the development of processor performance and the number of computers at the disposal of an attacker.

It is generally estimated (Moore’s Law) that processor power is doubled every 18 months. On the basis of this estimate as well as the possible number of computers at the disposal of an attacker, it would take several million years to break triple-DES.

Similarly it is estimated that RSA with a key length of 1024 bits will be secure for the next 5 to10 years, whereas a key length of 2048 will be secure for the next 15 to 20 years.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 16 of 22

4.3 Data Formats Figure 2 gives an outline of the interfaces in the encryption solution.

A

DDB's DDB's Customer's Customer's in-house encryption encryption in-house system module module system

B

A: Interface between in-house systems and encryption module

B: Interface between two encryption modules

Figure 2: Outline of interfaces in the encryption module.

At interface A, data and control information are delivered between in-house systems and the encryption modules. The data format is determined by the sender’s in-house system. The functionality of the encryption modules is independent of the format. Distinction is made between interchanges in EDIFACT format and other formats, however. The format of the control information (keys, EDI addresses etc) is delivered as parameters, where the encryption module determines the format.

If the data delivered is an EDIFACT interchange, this interchange is used in the subsequent handling, i.e. the interchange delivered is signed and encrypted.

If the data delivered is not an EDIFACT interchange, an EDIFACT interchange is constructed, containing the data delivered as a binary object.

If the data delivered is in text format, the character set must be convertible from a fixed character set used by the sender’s system to the character set ISO 8859-1, which is used by the security module.

At the interface B between the two modules, two different types of format must be applicable, both EDIFACT. The sender’s in-house system determines the format.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 17 of 22

When the encryption module signs or decrypts an EDIFACT interchange, EDIFACT version 3 syntax is used, extended by a few security elements which are expected to be included in version 4. This is one of two formats that can be applied between two encryption modules.

Not all VANS providers can transport the EDIFACT syntax mentioned above, and consequently conversion to pure version 3 syntax without binary data or EDIFACT version 4 syntax must be possible. The result of this conversion is the second format that can be applied between the two encryption modules. The contents of an interchange in pure version 3 format are specific for this use and can only be interpreted by a module in the encryption solution.

At the interface B, the character set ISO 8859-1 is always used for the parts of the interchanges that are not binary.

Section 4.5 describes how signatures and encryption are applied in the extended EDIFACT version 3 format. 4.4 Handling of Keys The handling of RSA keys for encryption and signing is an essential security element of the encryption solution. This handling can be divided into two areas:

1. The generation of the first key pair and distribution of the public key

2. Storage of keys 4.4.1 Generation of an RSA Key Pair The encryption module can generate a pair of RSA keys that the in-house system stores in a protected database. It is essential for the security in connection with key generation that random data is used as input to the key generation (a seed).

As a part of the encryption solution, two functions are created to generate this seed. One function collects random data by means of a user interface, and a second that reads certain random incidents of the system, including such things a time stamp. Both functions are used for the collection and accumulation of random bits used for the generation of RSA keys and session keys.

It is necessary to call the function by the user interface each time an RSA key is generated, whereas session keys can be generated after a number of calls by the other function.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 18 of 22

The random bits collected and accumulated are stored in an encrypted form by the in-house system between different calls by the encryption module.

The private RSA keys is used subsequently for the generation of a , or for decryption of an interchange received.

The public key is used subsequently for distribution to the communications party prior to any communication via the encryption solution. The distribution of the public keys is handled by DB and DB’s customers and is not part of the encryption solution. To support the distribution, however, an API call for the generation of a public key fingerprint is implemented. This fingerprint validates when a key is received to secure the integrity of the key. If the public keys are exchanged on paper, a function will check for keying errors.

An RSA key pair is generated at DB prior to any communication with the customers via the encryption module. Similarly, an RSA key pair is generated by the customer, before the customer and DB are able to communicate via the encryption module. Subsequent replacement of RSA key pairs are required by DB as well as by the customer as a routine procedure, and on suspicion of a key pair having been compromised.

DB’s and DB’s customers’ in-house systems determine when a key pair is generated and/or replaced. The encryption module only makes API calls available for the generation of keys and fingerprints of public keys.

When an RSA key pair is replaced, there may be a time span before the new public key is distributed, in which interchanges encrypted by the previous public key may be received. Similarly, interchanges signed by a private key, to which the public key is not yet known, may be received. These situations must be handled by DB’s and DB’s customers’ in-house systems. 4.4.2 Storage of Keys It is crucial to store the private RSA keys in a secure way in both DB’s and DB’s customers’ in-house systems, as the entire security system is based on these keys. Consequently, a private key must never be stored in plain text in a database, and it must never be stored in plain text in the computer’s memory, except at the instant when it is used for signing and decrypting. Private keys must therefore always be encrypted under a password in the , and they must be overwritten in the memory after use.

In order to ensure this, private keys are always exchanged in an encrypted form between the encryption module and the in-house system. A password must therefore always be given to the encryption module along with a private

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 19 of 22

key so that private keys are only ever decrypted at the instant when they are used.

The in-house systems must handle the password in a secure way. Optimally it is given as input from a confidential user each time it is used. Alternatively it can be stored in a protected area on a disk or in a database, where it is readable only by the relevant system and suitably authorised staff.

It naturally follows that public keys are not secret and need not be stored in an encrypted form. The in-house systems determine how to store them, only if they are given in relevant API calls. It should be noted, however, that the integrity of the public keys is important, i.e. the table with the public keys cannot be changed in an unauthorised way.

The system must support the replacement of the password under which the private keys are encrypted. The in-house system handles the replacement and determines when to do so. When a password is changed, all private keys are decrypted with the former password and encrypted again with the new password. The encryption module must have an API call that takes an encrypted key and decrypts it using one password and then re-encrypts it using another password. 4.5 Handling of Signatures and Encryption in EDIFACT This section describes how signatures and encryption are handled technically in an EDIFACT interchange.

At the time of signing, a checksum of each message in the interchange is made. The checksum is calculated from the entire message from UNH to UNT. The signature itself is made in a separate AUTACK message containing a reference and a checksum for each of the messages signed. In addition to the signature, this AUTACK message contains a key ID and other control information. The key ID identifies the key used for signing.

The AUTACK message is delivered as the last message of the interchange signed.

If the same message is signed several times, all signatures are delivered in one AUTACK message. Before deciding on the detailed design, it must be agreed whether multiple signatures should be hierarchical or parallel. A hierarchical signature covers the message signed as well as previous signatures, whereas a parallel signature only covers the message signed.

Encryption is made at interchange level. Everything between the UNB and UNZ segments (both included) is encrypted using the hybrid method. Then

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 20 of 22

security headers and security trailers are added as well as a USD and a USU segment. The structure will then be:

UNA Copied without changes from the non-encrypted UNB interchange. Security headers Contain information on key ID, encryption algorithm, session key, date/time and other control information. USD Start segment for encrypted data, including the length of bytes of subsequent data. Encrypted data The encrypted (binary or filtered) data. USU End segment for encrypted data. Security trailers UNZ Copied without changes from the non-encrypted interchange.

4.6 Use of Functions in the API When the in-house systems use the encryption module by calling the various functions in the API, this action must be carried out in the correct sequence:

The sequence for data sending is as follows:

1. character conversion to ISO 8859-1 2. generation of signatures the requested number of times 3. encryption of the interchange 4. conversion to version 3 5. sending of EDIFACT interchange 6. receipt of AUTACK receipt 7. validation of receipt

Items 2 to 4 are optional, and items 6 to 7 are only executed if a receipt from the receiver is requested.

The sequence for data receipt is as follows:

1. conversion to version 4 2. decryption of the interchange 3. validation of signatures the requested number of times 4. generation of receipt 5. sending of receipt 6. character conversion from ISO 8859-1

The interchange received determines which of items 1 to 5 to execute.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 21 of 22

When generating RSA keys, the function that collects random bits from a user interface must be called first.

4.7 Limitations The present description of the encryption solutions imposes the following limitations on the system:

· To achieve true non-repudiation, the following items are required:

1. A signature 2. A timestamp 3. Signed messages must be archived and retrievable at a later time 4. When a signature is made, the signer must know exactly when the signature is made, for example by means of a user interface where the user approves the signature 5. It may be necessary to make an application that a third party can use for validation of the interchange

The encryption module only implements item 1 of the above list. Item two has been opted out as it requires an independent time stamp machine. Items 3 to 5 are implemented by the in-house system as they cannot be handled by the encryption module.

· Even by using the encryption module, DB and DB’s customers are not relieved of any responsibility for security. To be secure, the password and the private key must be handled securely by the in-house systems, and both must be replaced on a regular basis. It is also important to verify authentication and integrity when exchanging public keys. The in- house systems monitor communications with a view to security attacks when in operation. For example, the system must react if interchanges, to which the signature cannot be validated, are received several times.

· It is beyond the scope of the encryption solution to handle the compromising of keys, as these are stored and administered by the in- house systems.

· In the preparation of this system description, the option to use the same private RSA key for encryption and signature has been discussed. In similar cryptographic systems, separate RSA keys are typically used for these two functions as this gives higher security against attacks on the RSA keys. The functionality made available by the security module

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK Page 22 of 22

allows the in-house systems to determine whether different keys are used for the two functions.

· No requirements are made on the performance of the encryption solution. This system description therefore does not consider execution times for the functions made available by the encryption module.

SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK