Page 1 of 22 Danske EDIsec® System Description of the Encryption 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 Key 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): · authentication · 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 database. 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