Security control of SWIFT
1. Security Risks and Planning
Some of the main risks involved in Swift may come from hackers, increased dependence of banks on IT, Open Technologies, and increased electronic access by customers. Attacks on the system are possible by the following means: (1) Readily available sophisticated hacking tools; (2) Packet/Address spoofing; (3)Stealth diagnostics; (4) Sniffers; (5)Sweepers; and (6) Backdoors
Current general security planning for Swift could include the following:
• Formulate Security Policy
• Allocation of responsibilities which includes separation of duties and dual control
• Assets Classification through assigning owners and business risk analysis to ensure confidentiality, integrity, and availability
• Personnel Security’s major task is to create security awareness among employees
• Physical Security enforcement includes concentric security parameters, locks and identifications, and proper maintenance
• IT Security focuses on system access control (such as user identification, authentication and authorization), secure transmissions (such as message encryption, message authentication, message signature, non-repudiation, proof of origin,
proof of delivery), and system integrity at both production (such as database integrity and Operating System security) and delivery level (quality assurance).
2. Security Control
The main security control features of the SWIFT system includes end-to-end authentication, sequence number control, user access control, and encryption between operating centers.
2.1. End-to-end authentication
SWIFT provides secret-key and end-to-end authentication; i.e. authentication between two banks detecting any bogus payment message. Bilateral keys are managed manually according to SWIFT-issued guidelines. Such manual procedure suffers from key generation and transportation problems. To ensure the secrecy of transaction information, each bank is
required to generate a unique key for every bank it does business with. This creates a severe key management problem for the large number of banks worldwide. Transportation of keys is another problem; if you could send the secret key from the sender to the recipient securely and in a tamper-proof fashion, you would not need the symmetric crypto-system because
you would simply use that same secure channel to send the payment message. The end-to-end layer provides transaction-level capabilities secured through digital certificates as issued by the SWIFTNet Public Key Infrastructure (PKI). Features of the end-to-end layer include the following: (1) Provision of trust through non-repudiation, end-user authentication and access control; (2) Protection against fraud by supporting end-user access-control and end-to-end integrity and confidentiality; (3) The facility for applications to encrypt and sign individual transactions.
2.2 Sequence number control
Authentication control does not prevent a message from being replicated, deleted, or stored and retransmitted at a later date. The sequence numbering of messages handles these requirements. A payment message is transmitted with an input sequence number, output sequence number, and transaction reference number. They must be in order separately. The format and the input sequence number are checked by the SWIFT operating center and those messages with format errors or wrong sequence numbers are rejected by operating centers. The output from SWIFT operating centers contains an output sequence number that must be checked by the recipient. The transaction reference number provides an end-to-end sequence control for each pair of banks, and is included in the part of the message to which the authentication is applied. Since there
is no authentication feature between end-banks and operating centers, input sequence numbers may be altered during the bank-center link and the order of message sending could be changed. Banks might lose interest difference.
2.3 User access control
Terminals logging into the system must verify their identity using a password issued by SWIFT. The password is sent in two parts in the form of a table. By sending each part separately, the interception of a complete password set is made less
likely. Each password table contains a sequence of passwords listed against a sequence number. Each login employs the next password in the sequence so that the interception of passwords by line tapping gives no clue to the next password that will be needed. To avoid the trick of extracting passwords by impersonating the SWIFT system to the terminal, each
password is given a response number that the user must receive from the SWIFT and check before beginning transactions.
2.4 Encryption between operating centers:
To preserve the privacy of the banks' messages, the international lines that connect operating centers and join them to regional processors are protected by encryption. But encryption is not used on the line between banks and regional processors because it would prevent the useful role of SWIFT explain that privacy is not such a cardinal security factor as authentication. Then why do they offer an encryption function on international lines?
3. SIPN level core security solutions
3.1. IP Packet filtering
IP packet filtering protects the network nodes against denial-of-access attacks and against any other unauthorized
access. The POP applies IP packet filtering through access control lists. This ensures that only the allowed combinations of source and destination IP addresses pass through the POP. Packet filtering prevents the following occurrences such as traffic
from an unauthorized device passing through the POP or traffic from an authorized device passing to an unauthorized device. This prevents direct customer-to-customer traffic whilst allowing traffic between a customer and the SWIFT operating center. In addition, the IP packets are filtered on the protocol type and the destination port number. By blocking
unauthorized protocols, the freedom for preparing attacks is limited.
3.2. IP Encryption Authentication and Integrity:
Hardware encryptors are used within the network POPs and core domain to protect against traffic observation. These encryptors may be replaced when IPsec ESP technology reaches maturity. The hardware encryptors also provide indirect IP traffic authentication, as bilateral keys are needed to correctly decrypt the IP traffic. In addition, an MD5-based MAC
checksum guarantees the authenticity and integrity of the network management data.
3.3. Router Authorization
IP packet filters are implemented on all Secure IP Network routers. This implementation counters IP-level attacks from within or outside the network at the first encountered router. Packets that have an external origin are filtered-out by IP packet filtering at the core routers. In addition, Network Address Translation (NAT) at the SWIFTNet boundaries hides the
internal topology of the network in order to make attacks more difficult.
3.4. Firewalls
In order to contain the impact of attacks, SWIFTNet equipment is segregated into domains that are protected by firewalls and filtering-routers. POPs and CPEs also act as filtering-routers. The firewalls and filtering routers are configured to protect against the attempts to access unauthorized servers and routers, and denial of service attacks, including attacks through Ping of Death, SYN flooding, bursting-of-packets and LAN denial.
Lack of encryption between banks and regional processors present serious risks to the system as transmissions may be intercepted and modified or even deleted. Attackers may subsequently divert, redirect, or cancel funds transfers. One of the countermeasures is to use public key cryptography to ensure proper authentication and privacy stealing vulnerability and other required compensating controls to secure cryptographic keys. The RSA cipher is a revolutionary invention in the cryptography field. It enables ciphering without leaking private key information. It deploys the public key scheme to modify the key escrow mechanism to be used in SWIFT system offering the following features for the above stated problems:
• Each bank owns its private key and public key, but different keys are used for authentication of different transactions, and these keys are unknown to SWIFT as before.
• Provide bank-to-center authentication.
• Provide link-by-link encryption from end-to-end.
Each bank has a securely stored private key and a public key. A SWIFT terminal generates a random number for every message transmitted as the end-to-end authentication session key, and encrypts this key with the receiver's public key.
Using the same procedure to perform bank-to-center input sequence number authentication, it enables an operating center to verify the authenticity of the input sequence number from customer banks. The receiving bank to verify the output sequence number from the operating center uses the same method. Let us name this as link-by-link authentication. Finally, link-by-link encryption can be performed using a uniquely generated session key for message encryption and encrypting the session key with the public key of the code at the other side of the link.
The authentication code is encrypted and contained in the cipher text. The authentication verification can be performed by the decrypted plain text and the authentication code. Thus, every code only needs to store its private key and manage its public key. With its own private key, each bank or operating center can obtain required encryption and authentication session keys in an automatic way, and such critical information can not be eavesdropped.
1. Security Risks and Planning
Some of the main risks involved in Swift may come from hackers, increased dependence of banks on IT, Open Technologies, and increased electronic access by customers. Attacks on the system are possible by the following means: (1) Readily available sophisticated hacking tools; (2) Packet/Address spoofing; (3)Stealth diagnostics; (4) Sniffers; (5)Sweepers; and (6) Backdoors
Current general security planning for Swift could include the following:
• Formulate Security Policy
• Allocation of responsibilities which includes separation of duties and dual control
• Assets Classification through assigning owners and business risk analysis to ensure confidentiality, integrity, and availability
• Personnel Security’s major task is to create security awareness among employees
• Physical Security enforcement includes concentric security parameters, locks and identifications, and proper maintenance
• IT Security focuses on system access control (such as user identification, authentication and authorization), secure transmissions (such as message encryption, message authentication, message signature, non-repudiation, proof of origin,
proof of delivery), and system integrity at both production (such as database integrity and Operating System security) and delivery level (quality assurance).
2. Security Control
The main security control features of the SWIFT system includes end-to-end authentication, sequence number control, user access control, and encryption between operating centers.
2.1. End-to-end authentication
SWIFT provides secret-key and end-to-end authentication; i.e. authentication between two banks detecting any bogus payment message. Bilateral keys are managed manually according to SWIFT-issued guidelines. Such manual procedure suffers from key generation and transportation problems. To ensure the secrecy of transaction information, each bank is
required to generate a unique key for every bank it does business with. This creates a severe key management problem for the large number of banks worldwide. Transportation of keys is another problem; if you could send the secret key from the sender to the recipient securely and in a tamper-proof fashion, you would not need the symmetric crypto-system because
you would simply use that same secure channel to send the payment message. The end-to-end layer provides transaction-level capabilities secured through digital certificates as issued by the SWIFTNet Public Key Infrastructure (PKI). Features of the end-to-end layer include the following: (1) Provision of trust through non-repudiation, end-user authentication and access control; (2) Protection against fraud by supporting end-user access-control and end-to-end integrity and confidentiality; (3) The facility for applications to encrypt and sign individual transactions.
2.2 Sequence number control
Authentication control does not prevent a message from being replicated, deleted, or stored and retransmitted at a later date. The sequence numbering of messages handles these requirements. A payment message is transmitted with an input sequence number, output sequence number, and transaction reference number. They must be in order separately. The format and the input sequence number are checked by the SWIFT operating center and those messages with format errors or wrong sequence numbers are rejected by operating centers. The output from SWIFT operating centers contains an output sequence number that must be checked by the recipient. The transaction reference number provides an end-to-end sequence control for each pair of banks, and is included in the part of the message to which the authentication is applied. Since there
is no authentication feature between end-banks and operating centers, input sequence numbers may be altered during the bank-center link and the order of message sending could be changed. Banks might lose interest difference.
2.3 User access control
Terminals logging into the system must verify their identity using a password issued by SWIFT. The password is sent in two parts in the form of a table. By sending each part separately, the interception of a complete password set is made less
likely. Each password table contains a sequence of passwords listed against a sequence number. Each login employs the next password in the sequence so that the interception of passwords by line tapping gives no clue to the next password that will be needed. To avoid the trick of extracting passwords by impersonating the SWIFT system to the terminal, each
password is given a response number that the user must receive from the SWIFT and check before beginning transactions.
2.4 Encryption between operating centers:
To preserve the privacy of the banks' messages, the international lines that connect operating centers and join them to regional processors are protected by encryption. But encryption is not used on the line between banks and regional processors because it would prevent the useful role of SWIFT explain that privacy is not such a cardinal security factor as authentication. Then why do they offer an encryption function on international lines?
3. SIPN level core security solutions
3.1. IP Packet filtering
IP packet filtering protects the network nodes against denial-of-access attacks and against any other unauthorized
access. The POP applies IP packet filtering through access control lists. This ensures that only the allowed combinations of source and destination IP addresses pass through the POP. Packet filtering prevents the following occurrences such as traffic
from an unauthorized device passing through the POP or traffic from an authorized device passing to an unauthorized device. This prevents direct customer-to-customer traffic whilst allowing traffic between a customer and the SWIFT operating center. In addition, the IP packets are filtered on the protocol type and the destination port number. By blocking
unauthorized protocols, the freedom for preparing attacks is limited.
3.2. IP Encryption Authentication and Integrity:
Hardware encryptors are used within the network POPs and core domain to protect against traffic observation. These encryptors may be replaced when IPsec ESP technology reaches maturity. The hardware encryptors also provide indirect IP traffic authentication, as bilateral keys are needed to correctly decrypt the IP traffic. In addition, an MD5-based MAC
checksum guarantees the authenticity and integrity of the network management data.
3.3. Router Authorization
IP packet filters are implemented on all Secure IP Network routers. This implementation counters IP-level attacks from within or outside the network at the first encountered router. Packets that have an external origin are filtered-out by IP packet filtering at the core routers. In addition, Network Address Translation (NAT) at the SWIFTNet boundaries hides the
internal topology of the network in order to make attacks more difficult.
3.4. Firewalls
In order to contain the impact of attacks, SWIFTNet equipment is segregated into domains that are protected by firewalls and filtering-routers. POPs and CPEs also act as filtering-routers. The firewalls and filtering routers are configured to protect against the attempts to access unauthorized servers and routers, and denial of service attacks, including attacks through Ping of Death, SYN flooding, bursting-of-packets and LAN denial.
Lack of encryption between banks and regional processors present serious risks to the system as transmissions may be intercepted and modified or even deleted. Attackers may subsequently divert, redirect, or cancel funds transfers. One of the countermeasures is to use public key cryptography to ensure proper authentication and privacy stealing vulnerability and other required compensating controls to secure cryptographic keys. The RSA cipher is a revolutionary invention in the cryptography field. It enables ciphering without leaking private key information. It deploys the public key scheme to modify the key escrow mechanism to be used in SWIFT system offering the following features for the above stated problems:
• Each bank owns its private key and public key, but different keys are used for authentication of different transactions, and these keys are unknown to SWIFT as before.
• Provide bank-to-center authentication.
• Provide link-by-link encryption from end-to-end.
Each bank has a securely stored private key and a public key. A SWIFT terminal generates a random number for every message transmitted as the end-to-end authentication session key, and encrypts this key with the receiver's public key.
Using the same procedure to perform bank-to-center input sequence number authentication, it enables an operating center to verify the authenticity of the input sequence number from customer banks. The receiving bank to verify the output sequence number from the operating center uses the same method. Let us name this as link-by-link authentication. Finally, link-by-link encryption can be performed using a uniquely generated session key for message encryption and encrypting the session key with the public key of the code at the other side of the link.
The authentication code is encrypted and contained in the cipher text. The authentication verification can be performed by the decrypted plain text and the authentication code. Thus, every code only needs to store its private key and manage its public key. With its own private key, each bank or operating center can obtain required encryption and authentication session keys in an automatic way, and such critical information can not be eavesdropped.
