Introduction: The Protocols of Trust

In Lessons 4.1 and 4.2, we established the mathematical foundations of cryptography and examined the critical role of key management and Public Key Infrastructure (PKI) in financial institutions. We explored symmetric-key cryptography (AES), asymmetric-key cryptography (RSA, ECC), cryptographic hash functions (SHA-256), and the complete key management lifecycle. We also analyzed PKI components including Certificate Authorities, Registration Authorities, Certificate Revocation Lists, and Online Certificate Status Protocol. Each of these cryptographic primitives and key management frameworks provides the building blocks for secure communication.

However, cryptographic algorithms and key management systems are not used in isolation. They are integrated into cryptographic protocols that govern how parties communicate securely over networks. These protocols orchestrate the use of encryption, authentication, integrity checking, and key exchange to ensure that communications between financial systems, customers, partners, and regulators remain confidential, authentic, and tamper-proof.

Cryptographic protocols are the lifeblood of modern financial services. Every online banking transaction, every wire transfer, every ATM withdrawal, every stock trade, and every secure communication between financial institutions relies on cryptographic protocols to protect sensitive information from interception, tampering, and forgery. The security of the global financial system depends critically on the correct implementation and operation of these protocols.

This lesson provides a comprehensive analysis of cryptographic protocols used in financial institutions. We begin by examining Transport Layer Security (TLS) , the most widely deployed cryptographic protocol for securing communications over the internet. We analyze the TLS Handshake Protocol that establishes secure connections between clients and servers, the TLS Record Protocol that protects data in transit, and the TLS Key Exchange mechanisms. We derive the TLS Security ModelTLS={Confidentiality,Integrity,Authentication,Forward Secrecy}. We analyze the TLS Versions (TLS 1.2 and TLS 1.3) and their security properties.

We then examine IPsec (Internet Protocol Security) , which provides security at the network layer, protecting all IP traffic between hosts or networks. We analyze the IPsec Protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). We derive the IPsec Security ModelIPsec={Confidentiality,Integrity,Authentication,Replay Protection}. We analyze the IPsec Modes: Transport Mode and Tunnel Mode, and their applications in financial institutions.

We also examine SSH (Secure Shell) , which provides secure remote access to financial systems. We analyze the SSH Protocol: Transport Layer Protocol, User Authentication Protocol, and Connection Protocol. We derive the SSH Security ModelSSH={Confidentiality,Integrity,Authentication,Session Management}.

Finally, we examine the SWIFT Security Protocols, including the SWIFT Customer Security Programme (CSP) and the SWIFT Inter-Act Protocol. We analyze the SWIFT Security Controls and their application to financial messaging.

By the end, you will have a complete understanding of cryptographic protocols used in financial institutions, and be able to analyze their security properties and implementation requirements.


Learning Objectives

Upon completion of this lesson, you will be able to:

  1. Analyze Transport Layer Security (TLS) , including the TLS Handshake Protocol, TLS Record Protocol, and TLS Key Exchange mechanisms.

  2. Derive the TLS Security ModelTLS={Confidentiality,Integrity,Authentication,Forward Secrecy}.

  3. Analyze IPsec (Internet Protocol Security) , including AH and ESP protocols, and Transport and Tunnel modes.

  4. Derive the IPsec Security ModelIPsec={Confidentiality,Integrity,Authentication,Replay Protection}.

  5. Analyze SSH (Secure Shell) , including the Transport Layer Protocol, User Authentication Protocol, and Connection Protocol.

  6. Derive the SSH Security ModelSSH={Confidentiality,Integrity,Authentication,Session Management}.

  7. Analyze SWIFT Security Protocols, including the SWIFT Customer Security Programme (CSP) and SWIFT Inter-Act Protocol.

  8. Apply cryptographic protocol best practices to financial institutions.


Part 1: Transport Layer Security (TLS)

1.1 The TLS Definition

Transport Layer Security (TLS) is a cryptographic protocol that provides secure communication over a computer network. It is the successor to SSL (Secure Sockets Layer) and is the most widely deployed security protocol on the internet.

TLS={Handshake Protocol,Record Protocol,Alert Protocol}

1.2 The TLS Protocol Architecture

 
 
Protocol Function Description
Handshake Protocol Establishes secure connection Negotiates ciphersuites, authenticates parties, exchanges keys
Record Protocol Protects data in transit Encrypts and authenticates application data
Alert Protocol Handles error conditions Reports errors, closes connections

1.3 The TLS Handshake Protocol

The TLS handshake establishes a secure connection between a client and a server:

Handshake={ClientHello,ServerHello,Certificate,Key Exchange,Finished}

Handshake Steps:

 
 
Step Direction Message Purpose
1 Client → Server ClientHello Supported TLS versions, ciphersuites, random nonce
2 Server → Client ServerHello Chosen TLS version, ciphersuite, random nonce
3 Server → Client Certificate Server’s public key certificate (PKI)
4 Server → Client ServerKeyExchange Additional key exchange data
5 Server → Client ServerHelloDone Indicates server is done
6 Client → Server ClientKeyExchange Client’s key exchange data
7 Client → Server ChangeCipherSpec Switch to negotiated encryption
8 Client → Server Finished Verify handshake integrity
9 Server → Client ChangeCipherSpec Switch to negotiated encryption
10 Server → Client Finished Verify handshake integrity

1.4 The TLS Security Model

TLS={Confidentiality,Integrity,Authentication,Forward Secrecy}

 
 
Property Description Implementation
Confidentiality Data is protected from unauthorized access Symmetric encryption (AES-GCM)
Integrity Data is protected from tampering Message Authentication Codes (MAC)
Authentication Identity of parties is verified Digital certificates (X.509)
Forward Secrecy Past sessions protected if keys compromised Ephemeral Diffie-Hellman (ECDHE)

1.5 TLS Versions

 
 
Version Released Status Security Features
TLS 1.2 2008 Widely used AES-GCM, SHA-256, ECDHE
TLS 1.3 2018 Modern standard Improved security, faster handshake, forward secrecy required

TLS 1.3 Key Improvements:

 
 
Improvement Description Benefit
Reduced Handshake Latency 1-RTT handshake Faster connection establishment
Forward Secrecy Required ECDHE mandatory Protects past sessions
Removed Weak Ciphers Removed outdated algorithms Increased security
Zero-RTT (0-RTT) Early data transmission Faster resume

1.6 TLS in Financial Institutions

 
 
Use Case TLS Version Ciphersuite
Online Banking TLS 1.3 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Mobile Banking TLS 1.3 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Payment Processing TLS 1.3 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Inter-Bank Communication TLS 1.3 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
text
TLS Handshake (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  Client                                                               │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  1. ClientHello                                                 │  │
|  │     • TLS 1.3                                                  │  │
|  │     • Supported Ciphersuites                                    │  │
|  │     • Random Nonce                                             │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  2. ServerHello                                                 │  │
|  │     • TLS 1.3                                                  │  │
|  │     • Selected Ciphersuite                                      │  │
|  │     • Random Nonce                                             │  │
|  │  3. Certificate                                                 │  │
|  │     • Server's Public Key Certificate                           │  │
|  │  4. ServerKeyExchange                                           │  │
|  │     • ECDHE Parameters                                          │  │
|  │  5. ServerHelloDone                                             │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  6. ClientKeyExchange                                           │  │
|  │     • Client's ECDHE Public Key                                 │  │
|  │  7. ChangeCipherSpec                                            │  │
|  │  8. Finished                                                    │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  9. ChangeCipherSpec                                            │  │
|  │  10. Finished                                                   │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Secure Data Exchange                                          │  │
|  │     • Application Data Encrypted with AES-GCM                 │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
└─────────────────────────────────────────────────────────────────────────┘

Part 2: Internet Protocol Security (IPsec)

2.1 The IPsec Definition

IPsec is a suite of protocols that provides security at the network layer, protecting all IP traffic between hosts or networks.

IPsec={AH,ESP,IKE}

2.2 IPsec Protocols

 
 
Protocol Description Function
Authentication Header (AH) Provides authentication and integrity Protects against tampering
Encapsulating Security Payload (ESP) Provides encryption, authentication, and integrity Protects data confidentiality
Internet Key Exchange (IKE) Establishes security associations Key management and negotiation

2.3 The IPsec Security Model

IPsec={Confidentiality,Integrity,Authentication,Replay Protection}

 
 
Property Description Implementation
Confidentiality Data is protected from unauthorized access ESP encryption (AES)
Integrity Data is protected from tampering AH/ESP integrity checks (SHA)
Authentication Identity of parties is verified IKE authentication (PSK, certificates)
Replay Protection Prevents replay attacks Sequence numbers, sliding windows

2.4 IPsec Modes

Transport Mode:

Transport Mode={Encrypts Payload,Original IP Header}

  • Used for host-to-host communications

  • Only the payload (and ESP/AH headers) is protected

  • Original IP header remains visible

Tunnel Mode:

Tunnel Mode={Encrypts Entire Packet,New IP Header}

  • Used for network-to-network communications

  • Entire original packet is protected

  • New IP header with gateway addresses

2.5 IPsec in Financial Institutions

 
 
Use Case Mode Protocol Security
Site-to-Site VPN Tunnel Mode ESP AES-256, SHA-256
Remote Access VPN Transport Mode ESP AES-256, SHA-256
Cloud Connect Tunnel Mode ESP AES-256, SHA-256
Data Center Connect Tunnel Mode ESP AES-256, SHA-256
text
IPsec Modes (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  Transport Mode                                                       │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Original IP Header │ TCP/UDP Header │ Data                   │  │
|  │  ┌──────────────────┴────────────────────────────────────────┐ │  │
|  │  │  IP Header │ ESP Header │ TCP/UDP Header │ Data │ ESP Tail │  │
|  │  └─────────────────────────────────────────────────────────────┘ │  │
|  │  • Encrypted: TCP/UDP Header + Data                            │  │
|  │  • Visible: Original IP Header                                  │  │
|  │  • Use Case: Host-to-host communications                        │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Tunnel Mode                                                          │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Original IP Header │ TCP/UDP Header │ Data                   │  │
|  │  ┌────────────────────────────────────────────────────────────┐ │  │
|  │  │  New IP Header │ ESP Header │ Original IP Packet │ ESP Tail │ │  │
|  │  └────────────────────────────────────────────────────────────┘ │  │
|  │  • Encrypted: Entire Original IP Packet                        │  │
|  │  • Visible: New IP Header                                       │  │
|  │  • Use Case: Network-to-network communications                  │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
└─────────────────────────────────────────────────────────────────────────┘

Part 3: SSH (Secure Shell)

3.1 The SSH Definition

SSH is a cryptographic protocol for secure remote access to systems, providing secure command execution, file transfer, and other network services.

SSH={Transport Layer,User Authentication,Connection}

3.2 SSH Protocols

 
 
Protocol Description Function
Transport Layer Protocol Establishes secure connection Server authentication, key exchange, encryption
User Authentication Protocol Authenticates the user Password, public key, keyboard-interactive
Connection Protocol Multiplexes secure channels Shell, file transfer, port forwarding

3.3 The SSH Security Model

SSH={Confidentiality,Integrity,Authentication,Session Management}

 
 
Property Description Implementation
Confidentiality Data is protected from unauthorized access Symmetric encryption (AES)
Integrity Data is protected from tampering MAC (HMAC)
Authentication Identity of parties is verified Public key, password
Session Management Secure session handling Session keys, rekeying

3.4 SSH Key Exchange

Key Exchange={DH Key Exchange,Session Key Generation,Server Authentication}

3.5 SSH in Financial Institutions

 
 
Use Case Authentication Encryption Application
System Administration Public key AES-256 Secure remote access
File Transfer Public key AES-256 SFTP
Automation Public key AES-256 Scripted operations
Audit Logging Public key AES-256 Secure command logging
text
SSH Protocol Architecture (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  Transport Layer Protocol                                             │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • TCP connection establishment                                 │  │
|  │  • Version negotiation                                          │  │
|  │  • Key exchange (DH, ECDH)                                     │  │
|  │  • Server authentication (host key)                             │  │
|  │  • Encryption setup (AES-GCM)                                   │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  User Authentication Protocol                                        │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Authentication methods:                                     │  │
|  │    • Password                                                   │  │
|  │    • Public key                                                │  │
|  │    • Keyboard-interactive                                       │  │
|  │  • Multiple authentication                                      │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Connection Protocol                                                 │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Multiplexing:                                               │  │
|  │    • Shell sessions                                            │  │
|  │    • File transfer (SFTP)                                      │  │
|  │    • Port forwarding                                           │  │
|  │    • X11 forwarding                                            │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
└─────────────────────────────────────────────────────────────────────────┘

Part 4: SWIFT Security Protocols

4.1 SWIFT Customer Security Programme (CSP)

Overview: The SWIFT Customer Security Programme (CSP) is a mandatory security framework for SWIFT customers, designed to protect the integrity of the SWIFT network.

SWIFT CSP={Security Controls,Security Assessment,Compliance}

4.2 SWIFT Security Controls

 
 
Control Group Control Description
Protect 1.1 Restrict internet access to SWIFT infrastructure
  2.1 Restrict access to SWIFT systems
  2.2 Segregate SWIFT operations from other environments
  2.3 Implement strong authentication
  2.4 Protect SWIFT data
Detect 3.1 Detect anomalous activity
  3.2 Implement incident response
Respond 3.3 Ensure business continuity
  3.4 Test and update resilience capabilities

4.3 SWIFT Inter-Act Protocol

Overview: SWIFT Inter-Act is a protocol for secure financial messaging between financial institutions.

SWIFT Inter-Act={Message Types,Authentication,Encryption,Non-Repudiation}

Message Types:

 
 
Type Description Examples
MT 1xx Customer payments MT 103 (Single Customer Credit Transfer)
MT 2xx Financial institution transfers MT 202 (General Financial Institution Transfer)
MT 3xx Treasury markets MT 300 (Foreign Exchange Confirmation)
MT 4xx Collection and cash letters MT 400 (Collection Instruction)
MT 5xx Securities markets MT 540 (Receive Free)
MT 7xx Documentary credits MT 700 (Issue of a Documentary Credit)
MT 9xx Messages MT 999 (Free Format)
text
SWIFT Security Architecture (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  SWIFT Network                                                         │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  SWIFT Inter-Act Protocol                                      │  │
|  │  • Message encryption (AES)                                    │  │
|  │  • Authentication (Digital signatures)                         │  │
|  │  • Non-repudiation (Audit trails)                              │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Customer Security Programme (CSP)                                   │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Protect:                                                       │  │
|  │  • Restrict internet access                                     │  │
|  │  • Restrict access to SWIFT systems                             │  │
|  │  • Segregate SWIFT operations                                  │  │
|  │  • Strong authentication                                        │  │
|  │  • Protect SWIFT data                                           │  │
|  │  Detect:                                                       │  │
|  │  • Anomalous activity detection                                 │  │
|  │  • Incident response                                           │  │
|  │  Respond:                                                      │  │
|  │  • Business continuity                                         │  │
|  │  • Resilience testing                                          │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
└─────────────────────────────────────────────────────────────────────────┘

Summary and Bridge to Lesson 4.4

We have now completed the comprehensive analysis of cryptographic protocols for financial transactions. You have learned:

  1. Transport Layer Security (TLS): Handshake Protocol, Record Protocol, and the TLS Security Model TLS={Confidentiality,Integrity,Authentication,Forward Secrecy}.

  2. IPsec: AH, ESP, IKE, Transport Mode, Tunnel Mode, and the IPsec Security Model IPsec={Confidentiality,Integrity,Authentication,Replay Protection}.

  3. SSH: Transport Layer, User Authentication, Connection Protocol, and the SSH Security Model SSH={Confidentiality,Integrity,Authentication,Session Management}.

  4. SWIFT Security: Customer Security Programme (CSP) and SWIFT Inter-Act Protocol.

In Lesson 4.4, we will explore Digital Signatures and Authentication in Financial Systems, analyzing the role of digital signatures in financial transactions and the various authentication mechanism