Security Protocols

2 posts

toss3 min readCurated summary

Why We Adopted Post-Quantum Cryptography a Decade Before Quantum Computers Arrive

Toss Payments’ biggest legacy-overhaul challenge was not the technology itself, but improving security without disrupting tens of thousands of merchants using decades-old integrations. Because payment systems depend on outdated client environments and small businesses with limited technical resources, security upgrades had to be gradual and carefully communicated. The effort ultimately led from modernizing transport security to adopting post-quantum cryptography in 2026. ## The Challenge of Changing a Legacy Payment Network - Toss Payments supports merchants integrated with its PG system for many years, sometimes decades. - Server-side clients are harder to update than browsers, which update automatically to support new standards. - Security changes such as upgrading TLS, removing weak ciphers, or changing encryption can affect every API call, payment window, and server connection. - Many merchants are small businesses without dedicated developers, making complex security requirements difficult to understand and implement. - As a result, security is a shared responsibility: Toss Payments can strengthen its systems, but legacy merchant environments may still leave connections partially exposed. ## Why Existing Encryption Is Becoming Unsafe - Modern HTTPS and payment systems commonly rely on public-key algorithms such as RSA and ECDSA. - These algorithms are considered secure because conventional computers cannot practically factor enormous numbers or solve elliptic-curve problems. - Quantum algorithms have been mathematically shown to solve these problems efficiently once sufficiently powerful quantum computers exist. - This would make current encryption systems vulnerable, undermining decades of digital-security assumptions. ## Q-Day and “Harvest Now, Decrypt Later” - “Q-Day” refers to the point when quantum computers can break today’s widely used encryption. - Attackers can already intercept and store encrypted payment communications that they cannot currently decrypt. - Once quantum computers become practical, the stored data could be decrypted in bulk. - Payment information is especially valuable because it can remain sensitive for years; data transmitted today could be exposed in the 2030s. - The threat therefore requires action before quantum computers are fully operational. ## A Four-Year Security Upgrade Toss Payments chose a phased approach rather than replacing its security stack all at once: - **2022:** Became the first payment gateway in Korea’s PG industry to implement HTTP/3. - **2022–2025:** Removed weak TLS cipher suites. - **2022–2025:** Completed the rollout of TLS 1.3. - **April 2026:** Implemented post-quantum cryptography (PQC). Each stage balanced stronger protection against the risk of disrupting merchant payments. The gradual rollout gave merchants time to update their systems while ensuring that security improvements continued instead of being postponed indefinitely. ## Starting with HTTP/3 - HTTP/3 is a newer web-transport protocol designed to improve speed and stability, especially on unreliable networks. - It requires TLS 1.3, meaning that adopting HTTP/3 also enforces the use of a modern security protocol. - Toss Payments began with HTTP/3 because it offered both performance improvements and a relatively direct path toward stronger encryption. The broader lesson is that legacy security cannot be improved through a single disruptive upgrade. A phased migration, combined with clear communication and preparation for post-quantum cryptography, allows payment providers to raise security standards while keeping existing merchants operational.

Read original(opens in new tab)
toss4 min readCurated summary

Applying Post-Quantum Cryptography for the Quantum Computing Era: Why Implement It 10 Years Early?

Toss Payments’ hardest legacy-modernization challenge was not replacing old systems, but improving security across tens of thousands of merchants with diverse, outdated environments. Over four years, it gradually introduced HTTP/3, removed vulnerable cipher suites, deployed TLS 1.3, and ultimately adopted post-quantum cryptography (PQC) in April 2026. The central lesson is that security upgrades must begin early and be introduced gradually, with merchant support and backward compatibility built in. ## Breaking the Inertia of Legacy Systems - Mission-critical payment services tend to follow the principle: “If it works, don’t touch it.” - Security protocol changes are particularly difficult because they can affect every merchant integration and may be hard to troubleshoot or roll back. - Many merchants still operate decades-old server-side systems that cannot support modern security policies. - Documentation alone is often insufficient, especially for merchants without dedicated development teams. - Because every API, SDK, payment window, and server connection is part of the security boundary, Toss Payments could not improve security independently of its merchants. ## Why Existing Encryption Must Evolve - Modern HTTPS, banking, and payment systems rely heavily on RSA and ECDSA. - These algorithms are considered secure because factoring large numbers and solving elliptic-curve problems is impractical for classical computers. - Quantum computers could solve these problems efficiently, making current public-key cryptography vulnerable. - The anticipated point at which quantum computers can break these systems is often called “Q-Day.” - The “Harvest Now, Decrypt Later” threat means attackers can collect encrypted payment data today and decrypt it years later when quantum computers become practical. ## A Four-Year Security Upgrade Program Toss Payments chose a gradual migration strategy to improve security without abruptly disrupting merchant payments: - **2022:** Introduced HTTP/3, which requires TLS 1.3. - **2022–2025:** Removed vulnerable TLS cipher suites. - **2022–2025:** Enabled TLS 1.3 across all endpoints. - **April 2026:** Introduced post-quantum cryptography. ## HTTP/3 as a Low-Impact Starting Point - HTTP/3 improves speed and reliability on unstable networks. - Because it requires TLS 1.3, enabling HTTP/3 also raised security standards. - Modern browsers automatically select HTTP/3, so merchants required no configuration changes. - This made HTTP/3 an effective first step with minimal migration risk. ## Gradual Cipher Suite Removal - A cipher suite defines the algorithms used by a client and server to establish encrypted communication. - Some legacy merchant servers supported only vulnerable suites, such as `TLS_RSA_WITH_AES_128_CBC_SHA`. - Removing them immediately could stop payments for affected merchants, while delaying removal would leave the wider ecosystem exposed. - Toss Payments used: - Merchant-by-merchant compatibility analysis - Individual notifications six months to a year in advance - Environment-specific documentation and configuration guidance - Technical consulting where necessary - The Technical Account Manager team was essential in coordinating these changes and communicating with merchants in accessible language. ## TLS 1.3 Deployment - TLS 1.2 remained the minimum supported version, while TLS 1.3 was added alongside it. - Clients capable of TLS 1.3 automatically use the stronger protocol. - Older clients continue using TLS 1.2 without forced changes. - TLS 1.3 was enabled endpoint by endpoint from 2022 and supported across all endpoints by 2025. - The process demonstrated that ecosystem-wide security improvements require more time helping merchants migrate than technically changing the servers. ## Post-Quantum Cryptography - Toss Payments began preparing for PQC in 2025 and completed deployment in April 2026. - Modern browsers and clients that support PQC automatically use stronger quantum-resistant channels. - Unsupported environments continue using established encryption methods, preserving compatibility. - Merchants do not need to change configurations or update their integrations. - The approach provides stronger protection against future quantum attacks while minimizing present-day disruption. ## Cross-Team Collaboration - **Infra Team:** Applied PQC within Toss Payments’ private data-center infrastructure and physical hardware. - **Server Platform Team:** Integrated PQC into live traffic paths in AWS. - **TAM Team:** Used its experience from the cipher-suite migration to guide merchants and assess integration environments. - The result was a large-scale, proactive security deployment across the private payment ecosystem. Toss Payments’ experience suggests that organizations should start security migrations well before threats become immediate. Compatibility layers, staged enforcement, and sustained technical support allow legacy ecosystems to adopt stronger security without sacrificing availability.

Read original(opens in new tab)