ISO 15668:1999

Banking — Secure file transfer (retail)

Banque — Transfert de fichier de sécurité (services aux particuliers)

General Information

• Status: Withdrawn
• Publication Date: 08-Dec-1999
• Withdrawal Date: 08-Dec-1999
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/TC 68/SC 2 - Financial Services, security
• Drafting Committee: ISO/TC 68/SC 2 - Financial Services, security
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 10-May-2011

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15668
First edition
1999-12-01
Banking — Secure file transfer (retail)
Banque — Transfert de fichier de sécurité (services aux particuliers)
Reference number
ISO 15668:1999(E)
©
ISO 1999

---------------------- Page: 1 ----------------------
ISO 15668:1999(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO 1999 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 15668:1999(E)
Contents Page
Foreword.iv
Introduction.v
1 Scope .1
2 Normative references .3
3 Terms and definitions .4
4 Principles.5
5 Application .6
6 Authentication mechanisms.14
Annex A (informative) Mechanism examples .15
Annex B (informative) An example of implementation.23
Annex C (informative) An example for ensuring file transfer integrity validation.28
Annex D (informative) Graphics overview of security services with references.33
© ISO 1999 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 15668:1999(E)
Foreword
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 15668 was prepared by Technical Committee ISO/TC 68, Banking, securities and other
financial services, Subcommittee SC 6, Retail financial services.
Annexes A to D of this International Standard are for information only.
iv © ISO 1999 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 15668:1999(E)
Introduction
This International Standard describes how to secure file transfers in a retail banking environment. Typical use of
such file transfers are those between a card accepting device and an acquirer, or between an acquirer and a card
issuer.
© ISO 1999 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 15668:1999(E)
Banking — Secure file transfer (retail)
1 Scope
In contrast to file transfers in a wholesale banking environment characterised by exchanges of large volume,
between mainframes, in a relatively high-security environment ("bulk file transfers"); those in a retail banking
environment are characterised by low volumes and a lower degree of reliability of environment in which
downloaded devices are operated. Such devices may be, but not limited to, an electronic point of sale terminal
(EPOS), an automated vending machine (AVM), an automated teller machine (ATM), or a merchant server in
communication with payment gateways.
It is assumed that a pre-established relationship exists between the entities involved in the secure file transfer,
especially to cover the legal and commercial aspects related to the file transfer liabilities.
This International Standard applies to the different kinds of file transfer used in retail banking environment, but does
not cover transaction messages identified in ISO 8583.
The transfer may require timeliness, and requires at least one of the following security services:
� message origin authentication;
� receiver authentication;
� integrity;
� confidentiality;
� non repudiation of origin;
� non repudiation of delivery;
� auditability.
It is assumed that all data forwarded by the originator shall have been confirmed as legitimate and correct prior to
the transfer.
The different types of files to be transferred could contain:
� software;
� the retail transactions which have been performed and registered, (uploading);
� technical data related to an acquirer (access parameters.), (downloading);
� application data related to an acquirer (BIN list, hot list, .), (downloading).
© ISO 1999 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 15668:1999(E)
Characteristics of such file transfers are the following:
a) thetypeof datato betransferredcanbe
� non-secret data (collection of retail transactions, technical data and application data); or
� secret data.
b) the number of entities to receive the data can be:
� one;
� more than one (broadcast with even thousands of receivers).
c) the communication channels can consist of one or both of the following examples:
� telecommunication: public network, private network;
d) the nature of the transfer can be:
� direct-connect, real-time transfer (also known as circuit switching ); or
� store-and-forward transfer (also known as message switching).
NOTE This International Standard considers the security service during the transfer. Requirements to ensure that
transferred files have not been altered after transfer achievement are outside the scope of this International Standard.
Permissible forms of Secure File Transfer
Transfer of Secured Files
The transfer function does not provide any security services but includes only communication services. In this case
the file shall be secured prior to the transfer. Security is managed by the originator and the receiver themselves.
They need not trust the lower levels. There is no security added by the communication level (sender and receiver).
SFT = Secure File Transfer
Secured transfer of files
In this case, the security is taken into account only from the sender to the receiver and the originator fully trusts the
sender. One example is where the originator is the sender and the security is delegated to the transfer level. This is
not end to end security as there is no security added by the originator. In this case, the transfer function fully
includes the security services. The file need not be secured prior to the secured transfer taking place.
2 © ISO 1999 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 15668:1999(E)
Secured transfer of secured files
The security functions can be split up between the security function and the transfer function. One example is
where the originator creates a file, signs it with the private signature key, and enciphers the file with a key known
only by the end user (the receiver).
The concern in this example is to prevent anyone within the senders organisation from seeing the content of the
originators file. However, the originator trusts its agent(s) to process the transfer and to take into account the
authentication, integrity, between the sender and the receiver.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this International Standard. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this International Standard are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO 8372:1987, Information processing – Modes of operation for a 64-bit block cipher algorithm.
ISO 8583:1993, Financial transaction card originated messages – Interchange message specifications.
ISO 8731-1:1987, Banking – Approved algorithms for message authentication – Part 1: DEA.
ISO 9564-1:1991, Banking – Personal Identification Number management and security – Part 1: PIN protection
principles and techniques.
ISO/IEC 9796:1991, Information technology – Security techniques – Digital signature scheme giving message
recovery.
ISO/IEC 9796-2:1997, Information technology – Security techniques – Digital signature schemes giving message
recovery – Part 2: Mechanisms using a hash-function.
ISO/IEC 9797:1994, Information technology – Security techniques – Data integrity mechanism using a
cryptographic check function employing a block cipher algorithm.
ISO/IEC 9798-1:1991, Information technology – Security techniques – Entity authentication mechanisms –
Part 1: General model.
ISO/IEC 9798-2:1994, Information technology – Security techniques – Entity authentication – Part 2: Mechanisms
using symmetric encipherment algorithms.
ISO/IEC 9798-3:1993, Information technology – Security techniques – Entity authentication mechanisms –
Part 3: Entity authentication using a public key algorithm.
ISO/IEC 9798-4:1995, Information technology – Security techniques – Entity authentication – Part 4: Mechanisms
using a cryptographic check function.
ISO 9807:1991, Banking and related financial services – Requirements for message authentication (retail).
ISO/IEC 10116:1993, Information technology – Modes of operation for an n-bit block cipher algorithm.
ISO/IEC 10118-1:1994, Information technology – Security techniques – Hash-functions – Part 1: General.
© ISO 1999 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO 15668:1999(E)
ISO/IEC 10118-2:1994, Information technology – Security techniques – Hash-functions – Part 2: Hash-functions
using an n-bit block cipher algorithm.
ISO 11568 (all parts), Banking – Key management (retail).
ISO/IEC 13888-2:1998, Information technology – Security techniques – Non-repudiation – Part 2: Mechanisms
using symmetric techniques.
ISO/IEC 13888-3:1997, Information technology – Security techniques – Non-repudiation – Part 3: Mechanisms
using asymmetric techniques.
NIST FIPS PUB 180-1, Secure Hash Standard (Secure Hash Algorithm SHA-1).
3 Terms and definitions
For the purposes of this International Standard, the following terms and definitions apply.
3.1
hot list
a list of Primary Account Numbers (PAN) which are arranged according to the card issuer or its agent, not valid for
transaction use
3.2
digital signature
data appended to, or a cryptographic formation of, a data unit that allows a recipient of the data unit to prove the
source and integrity of the data unit and protect against forgery e.g. by the recipient
3.3
File Validation Value (FVV)
a derived value used for file validation purposes
3.4
hash code
the result of applying hash-function to data bits
3.5
hash-function
a (mathematical) function which maps values from a (possibly very) large set of values into smaller range of values,
satisfying the following two properties within this International Standard:
� it is computationally infeasible to find for a given output an input which maps to this output;
� it is computationally infeasible to find for a given input a second input which maps to the same output.
3.6
application manager
the part of the software of a terminal which is in charge of verifying the secure downloading of the intended
executable object
3.7
Message Authentication Code (MAC)
a code in a message between the originator and the receiver used to validate the source and part or all of the text
of the message
NOTE The code is the result of an agreed calculation.
4 © ISO 1999 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 15668:1999(E)
3.8
originator
the entity that creates the file that has to be transferred to the receiver and is responsible for its security
3.9
receiver
the entity that receives the file
3.10
sender
the entity that sends the file
3.11
sponsor
the entity that evaluates the risk of the file transfer
4Principles
4.1 Message Origin Authentication
The purpose of message origin authentication is to provide assurance to the receiver that the alleged originator is
the legitimate originator. It may also provide assurance to the receiver that the alleged file is the actual file, in the
event that the receiver is authorised to receive certain files from only a subset of its authorised originators.
Message origin authentication may occur concurrent with the file transfer, though it may also occur before the
transfer in a connection mode. If a store and forward transfer is used, the message origin authentication shall occur
after the transfer, when the file is retrieved by the receiver. (Note: transfer of secured files in the model).
Techniques that provide content authentication may provide message origin authentication, but these techniques
require the transfer of the entire file before the authentication can be verified. There may be situations in which it is
desirable to perform message origin authentication prior to initiating the actual transfer. As an example, it may be
desirable to prevent an impostor from masquerading as a legitimate file-provider and tying up a communications
channel for an extended time in transferring a long file, even though the illegitimacy of the originator would
eventually be detected and the transferred file rejected.
4.2 Receiver authentication
This security service authenticates the identity of the receiver prior to initiating the transfer, so that the transfer will
not occur unless the receiver’s identity has been verified.
Some receivers (POS terminals) are allowed to receive only some types of files. Part of the authentication process
is the control by the originator of the rights for the receiver to receive some file-type.
Another possible reason for using “receiver authentication” is to prevent an unauthorised party from impersonating
a legitimate receiver and tying up the originator’s communications capabilities while the originator transfers a
perhaps-lengthy file to the impersonator.
Receiver authentication does not prevent an unauthorised party from ascertaining the file contents (by “listening
in”). Without this security service, and without the security service of confidentiality, anyone could easily
impersonate the legitimate receiver and thus obtain the file. If it is essential that only the authorised receiver(s) of a
file actually receive the file, then the security service of confidentiality must be used. Only in this way can it be
ensured that an unauthorised party has not “listened in” on the communications channel and thus obtained a copy
of the file.
Note that there is a related security service, non repudiation of delivery, that confirms, after the completion of the
transfer, that the authorised party has successfully received the file.
© ISO 1999 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 15668:1999(E)
4.3 Integrity
Accidental or unauthorised alteration of the transferred file, or, at a minimum, selected portions of the transferred
file, shall be detected during and after the transfer process. Integrity services may control the entire file in a single
process, or they may individually control segments of the file.
4.4 Confidentiality
When necessary, the confidentiality of the transferred files shall be ensured and shall be applied to either the whole
file or those file portions that actually require confidentiality.
4.5 Non repudiation of origin
This security service provides evidence that the claimed originator actually originated the transferred file. (Without
such evidence, the originator might falsely claim that the receiver created the file, or else the receiver might have
created the file, and then falsely claimed that it came from the originator.)
4.6 Non repudiation of delivery
This security service provides evidence that the claimed receiver actually received the transferred file. Without such
evidence, the receiver might claim non-receipt of the file. This service is achieved by mechanisms identified in
annex A. The receiver sends to the originator a non repudiation token message proving that:
1) the intended receiver received the file;
2) the file contents were received unaltered.
NOTE The extent of non repudiation may be determined by domestic laws or local banking regulations.
4.7 Auditability
If required by the application, it may be necessary for the sender/originator and/or the receiver to log appropriate
details of the transfer (time and date, nature of the files, volume of the files, version number.). Such logs may
include failed attempts to transfer data, as well as successful attempts. In the event of attempted fraud, a log of
failed transfers may assist in identifying the source of the attempt.
5 Application
5.1 Software downloading
5.1.1 Definition
The software of a terminal is composed of distinct functional layers:
a) a trusted and fixed software, pre-loaded before secure file transfer, which is in charge of implementation of
security mechanisms for downloading the application manager and its secure execution;
b) an application manager which is in charge of implementation of security mechanisms for downloading the
different applications and their secure execution;
c) different applications, which consist of either executable objects or interpreted objects.
6 © ISO 1999 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 15668:1999(E)
NOTE The above are representative of different layers within the device. Only layers 2 and 3 are downloadable The
security of layer 1 is outside the scope of this International Standard.
Key
1 Application 1
2 Application 2
3 Application 3
4 Executable objects or interpreted objects
5Keys
6 Application manager
7 Trusted, fixed and preloaded software (bootstrap)
Figure 1 — Representation of the software of a terminal
Security services required for software downloading are:
� mutual authentication or unilateral authentication of the originator/sender;
� integrity verification of the transferred file.
Confidentiality may be required for sensitive data when appropriate (e.g. keys).
Prior authentication of the sender by the device may not be required when the downloading is processed in a
specific buffer and integrity checking is performed prior to accepting the software, achieving implicit authentication
of the sender.
For each layer, the sequence of the operations shall be: mutual authentication, software transfer, integrity
verification. In the case of mutual authentication failure, the software transfer shall not be performed. In the case of
integrity failure, the software shall not be accepted by the device and the whole sequence shall be performed
again.
NOTE It is not always necessary to authenticate the receiver. It may be sufficient for the receiver to have message origin
authentication for downloaded software.
© ISO 1999 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 15668:1999(E)
5.1.2 Mutual authentication
5.1.2.1 Implementation
Whatever entity is the initiator of the software download, mutual authentication shall be successfully performed
prior to any file transfer at any layer:
� when the application manager is downloaded, it shall be protected by mutual authentication security services
provided by the trusted and fixed software that has been pre-loaded;
� downloading of the application itself shall be protected by a mutual authentication service, implemented in the
application manager and using dedicated keys to each authorised application.
Usually a sender may manage several applications, each of which may be transferred to devices. Part of the
mutual authentication process is the verification by the sender of each receiving device and its rights to receive
each application. This involves the following:
� each device shall be identified by a unique identifier;
� the sender associates a list of authorised applications to each device identifier.
5.1.2.2 Mechanism
The mutual authentication mechanism requires a 2 or 3-way message exchange and may be achieved by either a
symmetric algorithm or an asymmetric algorithm. ISO/IEC 9798 specifies these security mechanisms.
When a symmetric algorithm is used, ISO/IEC 9798-2 and ISO/IEC 9798-4 apply. When an asymmetric algorithm is
used, ISO/IEC 9798-3 applies.
The mutual authentication does not involve a Trusted Third Party and may be performed either by a two pass
authentication using a sequence number (or time stamp), or a three pass authentication using random numbers.
For details, refer to annex A.
5.1.2.3 Key management
Key management techniques shall comply with ISO 11568.
Symmetric algorithm
The initial keys shall be securely installed in the device prior to any download. The same key may be used for both
directions but it is recommended that the mutual authentication uses a unique key per device to prevent a device
from masquerading as another one by changing its identification and moreover to prevent the possibility of creating
a false sender in case of compromising the secret key of a device.
The keys used for mutual authentication, prior to downloading of each layer, may be different.
Asymmetric algorithm
The use of an asymmetric algorithm requires that the receiver shall have a trusted relationship with the sender and
the keys used for mutual authentication are:
� a private key resident in the device and its associated public key which is transmitted to the sender to
authenticate the terminal;
� one unique private/public key pair per layer in all devices.
The device private key may be the same for both layers, even if the senders are two different senders.
8 © ISO 1999 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 15668:1999(E)
The public key used to authenticate the sender of the application manager shall be resident in each device and be
protected against substitution. The public key used to authenticate the application sender shall be securely
downloaded at the same time as the application manager or pre-loaded.
5.1.3 Integrity
Key
1 File 7 KEY
2 Non keyed algorithm 8 Hash code
3 Asymmetric 9 MAC
4 Symmetric 10 No further processing
5 Step 1 11 Digital signature
6 Step 2 12 File Verification Value (FVV)
Figure 2 — creation of File Verification Value
5.1.3.1 Implementation
The integrity of the transferred file shall be ensured by adding a File Verification Value (FVV) to the content of the
file. The FVV of the file need only be computed once, as it is not required to be dependent on the downloading
operation and on the identity of the receiving device.
After downloading of a layer and prior to activation of that layer on the device, the downloaded file FVV shall be
verified by the device.
5.1.3.2 Mechanism
Depending upon the algorithm used, it involves one or more steps to create the File Verification Value (FVV), see
Figure 2 and annex A.
© ISO 1999 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO 15668:1999(E)
5.1.3.3 Key management
The File Verification Value process requires the use of a secret key (symmetric algorithm) or a private key
(asymmetric algorithm) or a non-keyed value (hash code). The FVV operation is performed by the device:
Symmetric algorithm
The secret keys used for integrity of each layer shall be different.
The keys used to verify the integrity of the downloaded application manager shall be securely installed prior to
delivery of the device.
The keys used to verify the integrity of the downloaded application shall be:
� either securely installed prior to delivery of the device;
� or securely downloaded at the same time as the application manager.
The integrity and confidentiality of these keys shall be protected using a set of pre-installed keys.
Asymmetric algorithm
There is a unique public/private key pair per layer with the private key at the sender and the public key common to
all receivers.
The public key used to verify the integrity of the downloaded application manager shall be resident in each device
and protected against substitution. The public key used to verify the integrity of the downloaded application shall be
securely downloaded at the same time as the application manager or pre-loaded.
Encipher HASH technique
The hash function is a two-phase operation.
The first step in creating the FVV is the computation of the hash on the whole file transferred, using a hash
algorithm and without use of any (secret or otherwise) key.
The second step consists of applying a symmetric or a asymmetric algorithm to the hash, additional data and
appropriate padding, to produce the FVV.
5.1.4 Confidentiality
Confidentiality may not be required for software downloading. However when confidentiality service is required for
keys or data, a secret key or a private key is transferred from the sender through downloading and shall be
protected by encipherment.
5.1.5 Non repudiation of delivery
After receiving the software and verifying its integrity, the device should send a secure acknowledgement to the
sender, confirming the completion (successful or failed) of the reception and the integrity verification.
� The secure acknowledgement shall consist of a message identical to the authentication message sent by the
device to the sender during the mutual authentication phase, using the same key, except that it shall include:
the result: e.g. positive or negative;
� atimestamp.
The secure acknowledgement shall be in accordance with either ISO/IEC 13888-2 or ISO/IEC 13888-3.
10 © ISO 1999 – All rights reserved

---------------------- Page: 15 ----------------------
ISO 15668:1999(E)
On receipt of that secure acknowledgement, the sender shall verify and record it.
5.1.6 Non repudiation of origin
Non repudiation shall be implemented to ensure the integrity of the service.
When an asymmetric algorithm is used to ensure the integrity service, it provides, at the same time, non
repudiation of origin, as only the originator has knowledge of the private key required to compute the signature. In
this case, the device shall record the signature.
NOTE This implementation of the service is not fully performed if the signed data does not include a time stamp.
5.1.7 Auditability
To ensure non repudiation services, logging of the information described in 5.1.5 and 5.1.6 shall be performed.
5.2 Parameter downloading
5.2.1 Definition
Parameter downloading includes application data (such as BIN list, floor limits), negative file (hotlist), transfer and
updating of sender references (access parameters).
The application software of the receiver shall initiate such transfers, which may involve a completely different
protocol and sender from the one used previously to download the application software.
Security services for parameter transfer are under the control of the originator/sender. Usually an application
software supplier through an application server provides the application, and the parameters are provided b
...