The security of today’s VPNs, industrial networks, and embedded communication systems relies heavily on IPsec/IKEv2 (Internet Protocol Security/Internet Key Exchange Protocol Version 2). Its key exchange mechanisms, Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH), have proven reliable against classical attackers. However, once large-scale quantum computers become available, these algorithms will no longer provide sufficient protection. Shor’s algorithm can theoretically break DH and ECDH in polynomial time, making long-term protected data vulnerable to “harvest-now, decrypt-later” attacks
This is where Post-Quantum Cryptography (PQC) becomes essential. PQC introduces quantum-resistant key exchange mechanisms. For IKEv2, RFC 9370 defines how classical and post-quantum key exchanges can be integrated.
Integrating PQC into a widely deployed IKEv2 implementation is an important step toward making secure communication future-proof. We integrated ML-KEM, the NIST-standardized module-lattice KEM, into StrongSwan’s IKEv2 stack using our own KiviPQC-KEM hardware accelerator.
2.1 What is IPsec/IKEv2
Internet Protocol Security (IPsec) is a family of protocols designed to protect data transmitted over IP networks. Instead of trusting the network, IPsec secures each packet individually by adding encryption, integrity protection, and authentication. IPsec operates in two modes:
While IPsec protects the data channel, it still needs a way to establish keys and cryptographic parameters securely. This is the role of IKEv2 (Internet Key Exchange, version 2). IKEv2 is the control plane of IPsec. It determines how both sides communicate securely by negotiating cryptographic algorithms, authenticating peers, and performing key exchange. IKEv2 operates in two well-defined negotiation phases:
1. IKE-SA-INIT
Phases of IKEv2 specified in RFC 7296
Once these two phases are complete, IPsec can start encrypting, decrypting, and authenticating traffic according to the negotiated parameter. The weak point in classical IKEv2 is the key exchange mechanism itself. DH and ECDH rely on mathematical problems that become breakable with sufficiently large quantum computers. This means that an adversary could record encrypted traffic today and decrypt it later once quantum attacks become practical.
PQC addresses this threat. Instead of relying on DH/ECDH, PQC introduces quantum-resistant key encapsulation mechanisms such as ML-KEM. In the IKEv2 protocol flow, ML-KEM integrates naturally: it augments the DH/ECDH values with PQC public keys and ciphertexts, enabling a quantum-secure shared secret for IPsec.
2.2 StrongSwan as a crypto-agile IKEv2 Framework
StrongSwan is a modular, open-source IKEv2/IPsec implementation widely used in VPN gateways, embedded platforms and government-grade secure networks. Its architecture is built around libstrongswan, a flexible cryptographic framework that loads algorithms and key exchange methods as plugins. This modularity allows developers to extend the system without modifying the core protocol engine. New cryptographic primitives can be integrated simply by adding or replacing plugins for key exchange, encryption, authentication, or parsing of IKEv2 payloads.
Because of this clean separation between protocol logic and cryptography, StrongSwan provides an ideal foundation for post-quantum extensions. Integrating ML-KEM becomes a natural step: the protocol flow remains unchanged, while the cryptographic operations behind the KE payloads can be swapped for PQC methods with minimal disruption.
Integrating ML-KEM into StrongSwan’s IKEv2 handshake requires architectural modifications, because post-quantum algorithms are not drop-in replacements for classical DH. ML-KEM public keys and ciphertexts are much larger than DH/ECDH values, ML-KEM-1024 alone includes a 1568-byte public key, exceeding safe unfragmented UDP payload size. Large PQC payloads stress UDP transport limits and therefore require IKEv2 fragmentation. RFC 9370 addresses this challenge by extending IKEv2 with additional exchange rounds before IKE-AUTH, done in newly introduced phase IKE-INERMEDIATE that allow large post-quantum key material to be transported safely and combined with classical mechanisms in a hybrid mode.
To support these requirements, StrongSwan’s modular crypto architecture is expanded:
The ML-KEM operations (KeyGen, Encaps, and Decaps) are executed by an FPGA-based ML-KEM accelerator. The IKEv2 integration flow looks like:
This mirrors classical IKEv2 semantics while using PQC-compliant message formats and hardware-accelerated primitives. A significant advantage of this design is hardware-isolated private keys: all secret ML-KEM key material remains inside the FPGA fabric and never enters CPU-accessible memory, reducing the attack surface and improving robustness, especially for embedded, resource-constrained, and mission-critical systems.
To integrate ML-KEM into StrongSwan, we developed a dedicated plugin called fpga-kem, which acts as the software interface between the IKEv2 engine and the hardware accelerator. The plugin follows StrongSwan’s modular design principles and behaves like a standard crypto backend while internally routing operations to the FPGA. Its responsibilities include several core tasks:
4.1 Functional Validation
To ensure that ML-KEM was fully integrated into the IKEv2 flow, we validated that a complete PQC-enabled handshake succeeds end-to-end. In this setup, ML-KEM public keys and ciphertexts are exchanged correctly, both peers derive identical shared secrets, and the subsequent PRF-based key derivation produces consistent SKEYSEED and session keys. This confirms that the ML-KEM accelerator, the plugin logic, and the StrongSwan IKEv2 engine operate coherently across all key-exchange steps.
4.2 Interoperability and crypto-agility
A central design goal was to keep the system fully interoperable with existing IKEv2 deployments. The implementation therefore supports both classical Diffie–Hellman/ECDH and PQC-enabled IKEv2 using ML-KEM. StrongSwan can switch between these modes without architectural changes, allowing devices to negotiate classical or hybrid exchanges depending on the peer’s capabilities. This crypto-agile behavior is critical for long-lived or heterogeneous systems, where algorithm replacement must be possible without modifying the core protocol engine.
4.3 Security benefits
The design also strengthens the overall security posture. Private ML-KEM keys remain isolated inside the FPGA fabric, never entering CPU-accessible memory. Intermediate secrets are handled exclusively within the hardware, reducing exposure and minimizing the attack surface compared to software-only implementations. The hardware accelerator also executes operations in constant time, which is valuable in embedded or mission-critical environments where data dependent timing variance can become a side channel.
4.4 Limitations
The main limitation relates to hardware performance: the achievable speed depends on the FPGA’s clock frequency. On low-frequency platforms, ML-KEM in hardware may not yet outperform optimized software implementations. Nonetheless, the architectural advantages like hardware isolation, reduced attack surface, and the ability to migrate to more powerful FPGA platforms remain significant and form a strong basis for further PQC integration work.
We can help you. We provide services for securing your IP traffic with IPsec and IKEv2. Our team of experts works closely with you to design, implement, and optimize IPsec solutions that meet your specific security needs and align with the latest industry standards.
Learn more about our services.
Post-quantum security is becoming essential for long-lived and critical systems. Industrial networks, embedded devices, secure gateways, and space or defense communication links often operate for decades—long enough to be affected by future cryptanalytic advances. Systems deployed today must therefore resist not only current attacks but also the risk that encrypted traffic is harvested now and decrypted later once quantum computers mature.
Hybrid key exchanges are central to this transition. RFC 9370 defines mechanisms that combine classical and post-quantum algorithms, ensuring secure operation even if one family becomes compromised. Governmental and European guidance increasingly emphasizes crypto-agile architectures in which cryptographic components can be updated without redesigning the entire system.
Our integration of ML-KEM into StrongSwan supports exactly this direction. By offloading key generation, encapsulation, and decapsulation to dedicated FPGA logic, private keys remain isolated inside the hardware fabric and never enter CPU-accessible memory. This reduces the attack surface and strengthens protection against software-level compromise. At the same time, StrongSwan’s modular backend allows seamless switching between classical Diffie–Hellman and hybrid configurations, enabling practical crypto agility.
This work demonstrates that post-quantum key exchange is not a distant goal but deployable in IPsec/IKEv2 systems today. The next steps include extending hybrid modes, adding further PQC algorithms, and porting the design to different FPGA platforms, building a communication ecosystem ready for the quantum era.