Financial network security

9.10 Financial network security

If a hacker were to break into an e-commerce site successfully and capture someone’s credit card number, some unfortunate person would get stung financially; however, if the same thing happened on an interbank network,

a country’s economy could be ruined overnight. Banks and financial institu- tions use a diverse array of cryptography and authentication systems, which are not accessible to the general public.

The threat to security so far has been pictured as a lone hacker trying to steal credit cards; however, a rogue nation or terrorist organization could use a network of supercomputers to bring down a large national bank in order to cripple a country’s economy.

Most banks use private leased lines between their branches so that the confidential information does not come into contact with the public phone network. ATMs usually employ VPN links to the bank. ATMs are limited

9.10 Financial network security 247

to a maximum value of transactions they can perform, so it would be impossible to use one rogue VPN connection to drain a bank of its capital.

When a bank needs to communicate with a second financial institution overseas to perform, it must use the public phone network. Where commu- nications between two banks happen on a daily basis, a private virtual cir- cuit (PVC) is set up between the two banks. This reduces the amount of foreign data on the line, but neither bank actually owns the telecom con- nection. The communication will be very strongly encrypted in one of two main formats: ISO 8730 or SWIFT.

9.10.1 X.25

Many financial protocols run over X.25 packet layer protocol rather than IP. This offers no inherent security above the fact that it isn’t IP. X.25 was developed by the CCITT in 1978 and is in widespread use on banking net- works. Like the OSI model, it uses encapsulation, where low-level details such as packet framing are not of concern at the implementation level. It supports many of the features of TCP/IP, such as connection orientation and data integrity provided by high-level data link control/Link access pro- cedure balanced (HDLC/LAPB). Supported speeds are from 300 bps to

2.04 Mbps, on packets up to 1,024 bytes. Routing on X.25 is extensive, with support for both shared virtual circuits

and PVCs. Up to 200 virtual circuits can be supported on one X.25 line. A network has to be designed to support X.25 data. In situations where X.25 must travel over an IP network, LAPB can be replaced by TCP/IP. Cisco IOS software or TCP X.25 gateways have the capability to do this, as described in RFC 1613.

9.10.2 ISO 8730

Although less common than SWIFT, this format is used frequently for interbank transfers. It uses symmetric keys with ISO 8732 / ANSI X9.17 key distribution. The key distribution center (KDC) would be run by one or the other of the banks, or a trusted third party.

An ISO 8730 message can be hashed in one of two ways: a hash can be taken of (1) the entire message, or (2) only of the details that are crucial to the purpose of the message. In any case, every message must include the date on which the MAC was created. Out-of-date messages can therefore be discarded. This date value must be hashed regardless of the mode of opera- tion. Hashed fields throughout the message are clearly delimited thus:

Chapter 9

248 9.10 Financial network security

QD<date>DQ : The date the MAC was created QK<key>QK : The authentication key used by the recipient QX<message ID>XQ : A unique number for that day and key QT<transaction detail>TQ : Details of the transaction amount,

currency, identification of the parties, and the date MQ<hash>MQ : The hash itself, being eight bytes long, separated by

a space

9.10.3 SWIFT

The Society for Worldwide Interbank Financial Telecommunications (SWIFT) network caters to 7,000 financial institutions in almost 200 countries around the world. It is based in Belgium, Holland, and the United States. To access the SWIFT network, dedicated terminals are required, each with SWIFT-accredited software.

Communications can be made using either X.25 or Secure IP Network (SIPN). Connections to the SWIFT point of presence (POP) are made with leased lines or dedicated ISDN links. An API is available from SWIFT to communicate on this network, but accreditation must be sought before any transactions are made using any in-house software.

SWIFT is not solely concerned with electronic fund transfers. The pre- defined communications on SWIFT are customer transfers, bank-to-bank instructions, foreign exchange and derivatives, documentary collections, securities, syndicated loans, precious metals, travelers checks, documentary credits, statements, advice, and general messages.

When a transaction involves two currencies, control of the debit and credit is designated to the bank at which the transaction currency is local tender. When only one currency is involved, a third-party clearinghouse or other financial institution carries out the control of the debit and credit.

9.10.4 Corporate transactions

When a bank has a large corporation as a client, it will expect to process many highly sensitive transactions with them on a daily basis. Some of these transactions will be on a par with interbank transfers and, thus, must be afforded the same level of security.

The Comité Français d’Organisation et de Normalisation Bancaires (CFONB) designed a secure file-transfer mechanism named ETEBAC 5.

9.11 Conclusion 249

This mechanism was designed specifically for client–bank transactions and is widely used in France and elsewhere.

A common system for corporate transactions in the United Kingdom is the Bankers Automated Clearing Service (BACS). This is used when a com- pany performs an electronic fund transfer (EFT) to pay an employee’s salary or wishes to process a direct debit. The BACS can process anywhere up to 60 million transactions per day, for more than 40,000 customers. It is accessed remotely via the BACSTEL service during office hours. BACSTEL runs over

X.25, but an IP version of BACSTEL is set to replace this standard.