Systemdescription UK New - Danske Bankfile/... · Page 4 of 22 SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK 2 Introduction This document provides the

Page 1 of 22

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

Danske EDIsec®

System Description of theEncryption 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.

Page 2 of 22


Table of Contents1 PURPOSE ................................................................................. 3

2 INTRODUCTION .................................................................... 4

2.1 OUTLINE OF THE ASSIGNMENT .....................................................42.2 OUTLINE OF THE SOLUTION ..........................................................52.3 STRUCTURE OF THE DOCUMENT ...................................................7

3 DEFINITIONS AND REFERENCES ...................................... 8

3.1 ABBREVIATIONS AND DEFINITIONS ...............................................83.2 BIBLIOGRAPHY.............................................................................93.3 REFERENCES.................................................................................93.4 CRYPTOGRAPHIC TERMS ............................................................10

3.4.1 Fundamental Security Services .......................................... 113.4.2 Symmetrical System ............................................................ 113.4.3 Asymmetrical System........................................................... 123.4.4 Hybrid................................................................................ 12

4 OVERALL DESCRIPTION................................................... 13

4.1 FUNCTIONAL REQUIREMENTS.....................................................134.2 ALGORITHMS AND STANDARDS..................................................14

4.2.1 Choice of Systems .............................................................. 144.2.2 Consequences of the Choice of Systems ............................. 15

4.3 DATA FORMATS.........................................................................164.4 HANDLING OF KEYS ...................................................................17

4.4.1 Generation of an RSA Key Pair ......................................... 174.4.2 Storage of Keys.................................................................. 18

4.5 HANDLING OF SIGNATURES AND ENCRYPTION IN EDIFACT........194.6 USE OF FUNCTIONS IN THE API...................................................204.7 LIMITATIONS .............................................................................21

Page 3 of 22


1 Purpose

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

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

Page 4 of 22


2 Introduction

This document provides the system description of the elements of theencryption solution for DB which are provided by Systematic SoftwareEngineering (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 solutiondelivered by Systematic to DB.

Section 2.3 in this chapter explains how the rest of this document isstructured.

2.1 Outline of the AssignmentDB’s requirement is for a system that enables the exchange of ElectronicData Interchange (EDI) messages with its major business customers. Allinterchanges must be secure; the following security functions must beincluded 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 forintegration with the customer’s own computer systems, and a DB module forintegration 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 thereforebe flexible and as far as possible operating system independent

• The module must include cryptographic functions for encryption anddigital signatures

Page 5 of 22


• The module must not be dependent on the platform’s file system andmust be accessed through an API, where data and encryption keys aregiven 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 aregiven as parameters

• There is no requirement to handle digital signatures from multiple usersbut the system must be able to return receipts for signed interchangesthat are received.

In both cases it is not the responsibility of the encryption module to handle thetransmission of data between DB and DB’s customers. Once the data hasbeen encrypted and signed by the module, the sender’s own system isresponsible for the sending of the data. Likewise, the receiver’s system willreceive the data and call the encryption module for decryption of theinterchange and validation of the signature.

There is no requirement for the encryption module to access a database.

2.2 Outline of the SolutionThe Systematic solution is based on the EDIFACT standard. All dataexchanged between DB and its customers will be in the EDIFACT format.

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

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

Page 6 of 22


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

Figure 1 describes the components and the data flow.

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 theencryption module. This includes the identification of the receiver and thekeys to be used for encryption/signature. The encryption moduleconstructs an EDIFACT interchange containing the data received, signedand encrypted by the keys. Input to the encryption data may be binarydata, but it will be handled differently depending on whether it is inEDIFACT or other format.

3 – 7: Once encrypted and signed, the EDIFACT interchange is returned tothe in-house system and queued for sending. The encryption solution isindependent of the chosen transmission method.

8 – 10: The receiver’s system receives the encrypted, signed EDIFACTinterchange. This is passed to the encryption module along with the keysin order to decrypt the interchange and validate the signature. Theencryption module then returns the interchange, now back in its originalformat, to the receiver’s system.

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

Sender'sin-housesystem

Network(e.g. VANS)

Encryption-module

Encryptionmodule

Receiver'sin-housesystem

Commsmodule

Commsmodule

4

2

3

65

7

9

10

Keydatabase

1

Keydatabase

8

= SSE delivery

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 thissolution by DB’s in-house system. Systematic delivers a solution,however, where security can be implemented by DB without storing alltransmitted data

The following platforms are supported:

• MVS• AS/400• Unix• Windows

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

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

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

API Documentation: Documentation of the module’s API to be applied byDB’s and their customers’ own systems developers in the integration ofthe encryption solution into the in-house systems.

2.3 Structure of the DocumentThe remaining part of this document is structured as follows:

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

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

Page 8 of 22


3 Definitions and References

This chapter defines the terms and abbreviations used in this document.

3.1 Abbreviations and DefinitionsThe abbreviations, definitions and terms used in this document are:

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

API Application Programmers Interface. The interfaceof the encryption module against externalapplications, in the form of a library that can be linkedto the current application.

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

Library A collection of functions in a linkable file, which canbe linked into an application and called directly fromthe 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 anencryption 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 forformatting of documents exchanged via EDI.

Page 9 of 22


EDIFACTInterchange

One or several EDIFACT messages containingcontrol information, to be regarded as a kind ofenvelope. The control information includes senderand receiver addresses.

EDIFACTMessage

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

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

Module Encryption module in short.

Platform The term platform covers a well-defined operationalenvironment comprising hardware and operatingsystem.

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

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

SoftwareRequirements

Requirements introduced in this document. Relatingrather to the implementation than to requirements inthe contract and are consequently more useful inconnection with tests.

3.2 BibliographyReferences to other documents appear in the form of [REFERENCE].

3.3 ReferencesThe following documents are relevant for this system description:

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

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

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

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

Page 10 of 22


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

[ISO 9735] Description of the EDIFACT standard.

[SCHNEIER96] Applied Cryptography, Second Edition by BruceSchneier, Wiley 1996.

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

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

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

[RSAPKCS93] PKCS standard from RSA “RSA Data Security, Inc.Public-Key Cryptography Standards (PKCS)” 1993.

3.4 Cryptographic TermsThis section gives a brief definition of the cryptographic terms used in theencryption solution. For further information, see [SCHNEIER96] and[RSAFAQ].

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

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

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

Page 11 of 22


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

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

Fingerprint - a human readable representation of the checksum. As anexample, a hexadecimal representation can be used in which achecksum of 20 bytes is described by 40 characters.

3.4.1 Fundamental Security ServicesCryptographic systems can be used for the following security services:

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

Integrity means that the receiver can verify that the information has notbeen changed during the transmission. Integrity is a consequence ofsender authentication, but in some cases only integrity is needed andnot authentication.

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

Non-repudiation means that the sender cannot later deny having sent theinformation at a given time. Non-repudiation requires digitalsignatures.

3.4.2 Symmetrical SystemA symmetrical system is generally very fast and can be used for encryptionor authentication by means of MAC values as follows:

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

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

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

Page 12 of 22


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

A further drawback is that MAC values cannot be used for non-repudiation.

3.4.3 Asymmetrical SystemThe issue of key distribution is easier in an asymmetrical system as onlypublic keys need to be distributed. They need not be kept secret. Onlyauthentication and integrity in the distribution are required (in order to verifythat 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 thereceiver’s private key can then decrypt the text.

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

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

The disadvantage of asymmetrical systems is that they are operationallyslower than symmetrical systems.

3.4.4 HybridIn order to combine the advantages of asymmetrical and symmetricalsystems, encryption in a symmetrical system is often achieved by means of asession key. The session key is generated at random and only used once.The text is encrypted with the session key, and the session key itselfencrypted with the receiver’s public key by means of an asymmetricalsystem. Both are sent, and the receiver is able to decrypt the text afterdecrypting the session key.

Page 13 of 22


4 Overall Description

This chapter provides an overall description of the functional requirements ofthe 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 encryptionsolution and the key lengths chosen for each system. Furthermore, the levelof security that these choices imply is described.

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

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

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

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 RequirementsAs mentioned previously, the encryption module must handle encryption andsignatures. This section provides more in-depth information about therequirements 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 bestated at all API calls. Then the encryption module can attach controlinformation about the key used for the signature and/or the encryption. Thein-house system using the encryption module then makes a connectionbetween the key IDs and the users.

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

Page 14 of 22


module supports this, as the function to sign can be called several times, oneafter 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 encryptionmodule notifies the in-house system about the key-ID of the key used forsigning and/or encrypting.

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

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

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

Similarly, the encryption module can validate an AUTACK receipt.

4.2 Algorithms and StandardsThis section describes the specific standards and encryption systems used inthe encryption solution.

4.2.1 Choice of SystemsThe systems and key lengths have been chosen with a view to achieving afast and efficient solution as well as a high level of security.

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

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

Secrecy A hybrid solution with a random session key of 112 bits is used forsymmetrical encryption. The session key is encrypted using thereceiver’s public RSA key.

Page 15 of 22


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

Cipher block chaining, (CBC) described in ISO 10116 (Modes of operationsfor an n-bit block cipher), is used to secure against any removal of separateencryption blocks (parts of the encrypted text).

4.2.2 Consequences of the Choice of SystemsWith reference to [ODLYZKO95] and [RSANEWS], the followingconclusions on the choice of systems are reached: The algorithms chosenand the key lengths suggested (1024-2048 bits for RSA and 112 bits securityfor symmetrical encryption) are de facto standard in applications usingcryptography today.

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

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

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

Page 16 of 22


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

Figure 2: Outline of interfaces in the encryption module.

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

If the data delivered is an EDIFACT interchange, this interchange is used inthe subsequent handling, i.e. the interchange delivered is signed andencrypted.

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

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

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

DDB'sin-housesystem

DDB'sencryption

module

Customer'sencryption

module

Customer'sin-housesystem

A: Interface between in-housesystems and encryption module

B: Interface between two encryptionmodules

A

B

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 elementswhich are expected to be included in version 4. This is one of two formatsthat can be applied between two encryption modules.

Not all VANS providers can transport the EDIFACT syntax mentionedabove, and consequently conversion to pure version 3 syntax without binarydata or EDIFACT version 4 syntax must be possible. The result of thisconversion is the second format that can be applied between the twoencryption modules. The contents of an interchange in pure version 3 formatare specific for this use and can only be interpreted by a module in theencryption solution.

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

Section 4.5 describes how signatures and encryption are applied in theextended EDIFACT version 3 format.

4.4 Handling of KeysThe handling of RSA keys for encryption and signing is an essential securityelement of the encryption solution. This handling can be divided into twoareas:

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 PairThe encryption module can generate a pair of RSA keys that the in-housesystem stores in a protected database. It is essential for the security inconnection with key generation that random data is used as input to the keygeneration (a seed).

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

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

Page 18 of 22


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

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

The public key is used subsequently for distribution to the communicationsparty prior to any communication via the encryption solution. The distributionof the public keys is handled by DB and DB’s customers and is not part ofthe encryption solution. To support the distribution, however, an API call forthe generation of a public key fingerprint is implemented. This fingerprintvalidates when a key is received to secure the integrity of the key. If thepublic 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 thecustomers via the encryption module. Similarly, an RSA key pair isgenerated by the customer, before the customer and DB are able tocommunicate via the encryption module. Subsequent replacement of RSAkey pairs are required by DB as well as by the customer as a routineprocedure, and on suspicion of a key pair having been compromised.

DB’s and DB’s customers’ in-house systems determine when a key pair isgenerated and/or replaced. The encryption module only makes API callsavailable 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 newpublic key is distributed, in which interchanges encrypted by the previouspublic key may be received. Similarly, interchanges signed by a private key,to which the public key is not yet known, may be received. These situationsmust be handled by DB’s and DB’s customers’ in-house systems.

4.4.2 Storage of KeysIt is crucial to store the private RSA keys in a secure way in both DB’s andDB’s customers’ in-house systems, as the entire security system is based onthese keys. Consequently, a private key must never be stored in plain text ina database, and it must never be stored in plain text in the computer’smemory, except at the instant when it is used for signing and decrypting.Private keys must therefore always be encrypted under a password in thedatabases, and they must be overwritten in the memory after use.

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

Page 19 of 22


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

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

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

The system must support the replacement of the password under which theprivate keys are encrypted. The in-house system handles the replacementand determines when to do so. When a password is changed, all private keysare decrypted with the former password and encrypted again with the newpassword. The encryption module must have an API call that takes anencrypted key and decrypts it using one password and then re-encrypts itusing another password.

4.5 Handling of Signatures and Encryption in EDIFACTThis section describes how signatures and encryption are handled technicallyin an EDIFACT interchange.

At the time of signing, a checksum of each message in the interchange ismade. The checksum is calculated from the entire message from UNH toUNT. The signature itself is made in a separate AUTACK messagecontaining a reference and a checksum for each of the messages signed. Inaddition to the signature, this AUTACK message contains a key ID andother control information. The key ID identifies the key used for signing.

The AUTACK message is delivered as the last message of the interchangesigned.

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

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

Page 20 of 22


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

UNAUNB

Copied without changes from the non-encryptedinterchange.

Security headers Contain information on key ID, encryptionalgorithm, session key, date/time and othercontrol information.

USD Start segment for encrypted data, including thelength of bytes of subsequent data.

Encrypted data The encrypted (binary or filtered) data.USU End segment for encrypted data.Security trailersUNZ Copied without changes from the non-encrypted

interchange.

4.6 Use of Functions in the APIWhen the in-house systems use the encryption module by calling the variousfunctions 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-12. generation of signatures the requested number of times3. encryption of the interchange4. conversion to version 35. sending of EDIFACT interchange6. receipt of AUTACK receipt7. validation of receipt

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

The sequence for data receipt is as follows:

1. conversion to version 42. decryption of the interchange3. validation of signatures the requested number of times4. generation of receipt5. sending of receipt6. character conversion from ISO 8859-1

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

Page 21 of 22


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

4.7 LimitationsThe present description of the encryption solutions imposes the followinglimitations 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 thesignature is made, for example by means of a user interface wherethe user approves the signature

5. It may be necessary to make an application that a third party can usefor validation of the interchange

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

• Even by using the encryption module, DB and DB’s customers are notrelieved of any responsibility for security. To be secure, the passwordand 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 toverify authentication and integrity when exchanging public keys. The in-house systems monitor communications with a view to security attackswhen 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 thecompromising 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 sameprivate RSA key for encryption and signature has been discussed. Insimilar cryptographic systems, separate RSA keys are typically used forthese two functions as this gives higher security against attacks on theRSA keys. The functionality made available by the security module

Page 22 of 22


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

• No requirements are made on the performance of the encryptionsolution. This system description therefore does not consider executiontimes for the functions made available by the encryption module.

Documents

Systemdescription UK New - Danske Bankfile/... · Page 4 of 22 SSE/98314/SRS/001 Updated 24-02-1999 Revision:: 1.1 ID: Systemdescription_UK 2 Introduction This document provides the