Deploying StrongSwan on an Embedded FPGA Platform, IPsec/IKEv2 on Arty Z7 with PetaLinux and PQC

1. Introduction: IPsec on Embedded Platforms

Secure communication is a fundamental requirement for embedded systems that operate in exposed or mission-critical environments, including gateways, industrial control systems, and platforms used in space contexts. These systems are typically expected to remain operational and secure over long lifetimes, often under strict constraints on resources, updates, and architectural changes.

IPsec and IKEv2 are well-established, standardized mechanisms for securing IP-based communication. While their use is widespread in server and network appliance environments, integrating them into embedded Linux systems introduces a distinct set of challenges. Limited compute resources, constrained networking interfaces, platform-specific hardware/software boundaries, and the need for predictable system behavior all influence how these protocols can be deployed in practice.

At the same time, emerging requirements for post-quantum cryptographic resilience further complicate system design. Introducing post-quantum key exchange mechanisms such as ML-KEM raises questions not only about performance, but about, for example, trust boundaries, frame size and fragmentation, and the interaction between software and hardware components in constrained embedded platforms.

The objective of this article is to present and analyze a concrete IPsec/IKEv2 deployment on an FPGA-based embedded Linux system. Using an Arty Z7 FPGA platform with PetaLinux and StrongSwan, the focus is on system-level integration rather than protocol theory: how the IPsec stack is built and deployed, how classical and post-quantum key exchange are integrated without modifying standardized protocols, and what architectural trade-offs arise when moving cryptographic operations into programmable logic.

The presented work evaluates architectural feasibility and security model implications under realistic embedded constraints. The results provide a reference design for assessing how standardized secure communication stacks can be combined with hardware-backed post-quantum cryptography in FPGA-based systems with long operational lifetimes and elevated security requirements. 

The integration of ML-KEM into the IKEv2 protocol is discussed in detail in blog post.

2. IPsec/IKEv2, StrongSwan, and Post-Quantum Key Exchange in a Nutshell

IPsec (Internet Protocol Security) is a suite of protocols that secures IP-based communication at the network layer. It provides confidentiality, integrity, and authenticity for data in transit. IPsec operates in either transport mode, where only the payload is protected, or tunnel mode, where entire IP packets are encapsulated. Tunnel mode forms the basis of VPNs, secure gateways, and many embedded communication systems.

While IPsec protects the data plane, IKEv2 (Internet Key Exchange version 2) is responsible for setting it up. IKEv2 negotiates cryptographic algorithms, authenticates peers, performs the key exchange, and derives the shared secrets used by IPsec. This process is divided into two main phases:

• IKE-SA-INIT, where algorithms are negotiated and initial key material is exchanged
• IKE-AUTH, where identities are authenticated and the first IPsec CHILD SA is created

Once these steps are completed, IPsec can securely encrypt and authenticate traffic.

StrongSwan is a widely used, open-source implementation of IKEv2 and IPsec for Linux-based systems. It runs primarily in user space and handles IKEv2 negotiation and key management, while the Linux kernel enforces IPsec policies and processes packets. Its modular architecture allows cryptographic algorithms and key exchange methods to be extended without modifying the core protocol logic.

In classical IKEv2, the shared secret is established using Diffie–Hellman or ECDH, which are vulnerable to future quantum attacks. Post-quantum cryptography addresses this risk. ML-KEM, a NIST-standardized key encapsulation mechanism, integrates into IKEv2 at the key exchange step. Classical DH/ECDH values are replaced by ML-KEM public keys and ciphertexts, while the surrounding protocol logic remains unchanged. After the shared secret is established, IKEv2 continues to derive all session keys using the existing PRF-based key schedule.

3. PetaLinux as an embedded Linux Platform for FPGA SoCs

PetaLinux is a Linux development system from AMD explicitly designed for embedded systems. It is often used in embedded systems when the goal is to run software that cannot be supported on bare-metal (a hardware platform running without an operating system). PetaLinux simplifies embedded Linux development by offering:

• A pre-configured Linux kernel
• Device tree integration for FPGA peripherals
• A root file system
• Cross-compilation toolchains for ARM-based systems

From a security perspective, PetaLinux enables the use of standard Linux networking and security stacks on FPGA platforms. This makes it possible to deploy established protocols such as IPsec and IKEv2 without adapting them to a custom operating system. As a result, developers can evaluate and integrate secure communication stacks on FPGA-based systems using familiar Linux concepts and tools.

4. System Overview

4.1 Target Platform: Arty Z7

The target platform is the Arty Z7, based on a AMD Zynq-7000 SoC FPGA. It combines:

• an ARM-based Processing System (PS)
• Programmable Logic (PL) implemented in FPGA fabric

This architecture enables a clear separation between control logic and cryptographic execution. Protocol handling, operating system services, and application software run on the ARM cores, while cryptographic functionality can be implemented in hardware. This makes the platform well suited for hardware/software co-design and for evaluating different security architectures. 

4.2 Software Stack Overview

On the software side, PetaLinux provides the operating system environment. Responsibilities are clearly split:

• the Linux kernel handles networking and IPsec packet processing
• StrongSwan runs in user space and implements IKEv2 key management

This follows the standard Linux IPsec model and allows StrongSwan to be deployed without modifying the kernel networking stack.

5. Building the Embedded IPsec Stack - Petalinux

Deploying IPsec on an embedded Linux system requires enabling specific kernel features:

• XFRM framework
• ESP / AH support
• Linux crypto API

In addition, network stack considerations such as UDP transport, MTU limits, and fragmentation behavior are relevant for IKEv2 operation. These aspects are particularly important on embedded platforms, where buffers and interfaces are often more constrained than on server systems.

StrongSwan is cross-compiled for the ARM architecture and configured with the required components and plugins. An important observation is that the embedded deployment does not introduce protocol-specific deviations:

• configuration concepts remain unchanged
• runtime behavior matches standard Linux deployments

This allows existing IPsec and StrongSwan expertise to be reused in embedded environments.

6. IPsec/IKEv2 Operation on Arty Z7

In classical operation mode, IKEv2 uses DH/ECDH during IKE-SA-INIT. After authentication, the first CHILD SA is created and IPsec-protected communication starts. Functional verification confirms stable and reproducible secure tunnels.

In the PQC-enabled configuration, ML-KEM replaces DH/ECDH as the key exchange mechanism. The IPsec data plane remains unchanged, and modifications are limited to the IKEv2 control plane. For post-quantum operation, the KiviPQC IP Core is used as the ML-KEM implementation integrated into the embedded FPGA platform.

Independent of the key exchange mechanism, IKEv2 continues to use PRF-based key derivation. In this setup, HMAC-SHA2 derives SKEYSEED and all IKE SA and CHILD SA keys. This confirms that PQC affects the key exchange only, not the established IKEv2 key schedule.

7. Results and architectural Implications

The results are evaluated in the context of embedded system constraints, long product lifetimes, and security architectures that must remain robust under limited resources. The objective of this evaluation is therefore not to optimize for peak cryptographic performance, but to validate architectural feasibility and security properties on an FPGA-based embedded platform.

7.1 Functional Results

End-to-end testing confirms that IPsec/IKEv2 operates reliably on the Arty Z7 platform using PetaLinux. Complete IKEv2 handshakes were successfully executed in both classical and post-quantum configurations. In all test cases, the IKE Security Association and subsequent CHILD Security Associations were established correctly, enabling stable and reproducible IPsec-protected communication.

In the post-quantum configuration, ML-KEM-based key exchange produced matching shared secrets on both sides. These secrets were injected into the standard IKEv2 key derivation process, where PRF-based derivation using HMAC-SHA2 generated consistent SKEYSEED values as well as matching IKE SA and CHILD SA keys. Secure data transmission over the established IPsec tunnel confirms correct interaction between StrongSwan in user space and the Linux kernel IPsec stack.

Importantly, no protocol-level modifications were required. The IKEv2 state machine, message flow, and IPsec data plane remain fully compliant with existing standards. Post-quantum support is confined to the key exchange mechanism, demonstrating that PQC can be integrated into existing IPsec/IKEv2 deployments without introducing protocol forks or non-standard extensions.

7.2 Performance and Architectural Implications

From a performance perspective, the embedded FPGA platform used in this setup is not optimized for maximum cryptographic throughput. ML-KEM executed in programmable logic on the Arty Z7 does not outperform highly optimized software implementations in terms of key exchange latency. In some cases, the measured latency is slightly higher. This behavior is primarily caused by platform-specific constraints, including limited clock frequency and communication overhead between the processing system and programmable logic.

From a system engineering perspective, this observation is expected and does not represent a limitation of the architecture. Key exchange latency affects only the IKEv2 control plane and occurs infrequently compared to steady-state IPsec data transmission. It therefore has no measurable impact on long-term throughput or encrypted data path performance.

The primary motivation for executing ML-KEM in hardware is not latency reduction, but a deliberate change in the system security model. By generating and processing post-quantum private key material inside programmable logic, cryptographic secrets are kept outside CPU-accessible memory. This introduces a clear trust boundary between software and cryptographic assets, reduces exposure to software-level attacks, and improves resilience against compromise of the operating system or user-space components.

Crucially, this architectural change does not alter the IKEv2 or IPsec protocols themselves. Instead, it demonstrates how post-quantum key exchange can be integrated into standardized security mechanisms while enabling stronger isolation properties at the system level. This approach is particularly relevant for embedded platforms with long operational lifetimes, strict update constraints, and high security requirements. In such cases, architectural decisions must prioritize robustness and isolation over raw performance metrics.

---

Explore Cryptography IP:

• Post-Quantum Key Encapsulation and Digital Signature IP Core
• Post-Quantum Digital Signature IP Core
• Post-Quantum Key Encapsulation IP Core

---

8. Conclusion & Outlook

A standardized IPsec/IKEv2 security stack can be deployed effectively on the Arty Z 7 FPGA board using PetaLinux and StrongSwan. It demonstrates that secure, interoperable communication based on widely adopted standards is feasible in embedded environments that are subject to long product lifetimes, constrained resources, and strict change control.

A key result is that IPsec and IKEv2 behave consistently across different cryptographic configurations. Classical and post-quantum key exchange mechanisms can be supported within the same system architecture, without modifications to the IPsec data plane or the established IKEv2 key derivation process. This enables systems to evolve toward post-quantum readiness while preserving compatibility with existing deployments and operational practices.

From a system design perspective, it could be highlighted that post-quantum cryptography primarily impacts the key exchange layer and the overall security architecture rather than the communication protocols themselves. In particular, hardware-backed key exchange introduces stronger isolation of cryptographic key material and clearer trust boundaries between software and hardware components, an aspect that becomes increasingly relevant in security-critical embedded and gateway systems.

To improve the performance of that embedded IPsec/IKEv2 solution, the IPsec data plane could be transferred to FPGA hardware. Offloading the data plane to hardware could greatly improve data throughput compared to a Linux-based software solution, potentially enabling line-rate IPsec processing. 

Get started with PQC on your FPGA today.

Our evaluation package provides the complete hardware–software stack required to build a demo on your board. 

Sign up now and receive a free evaluation package.

Sign up and test PQC