ISO 15668:1999

Banking -- Secure file transfer (retail)

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).

Characteristics of such file transfers are the following:

• the type of data to be transferred can be
• non-secret data (collection of retail transactions, technical data and application data); or
• secret data.
• the number of entities to receive the data can be:
• one;
• more than one (broadcast with even thousands of receivers).
• the communication channels can consist of one or both of the following examples:
• telecommunication: public network, private network;
• 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).

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

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.

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.