KWireGuard: Design of Kernel Cryptographic Layer for WireGuard Based on Korean Block Ciphers

WireGuard is a VPN protocol integrated into the Linux mainline kernel since version 5.6, notable for its minimalist configuration and verified cryptographic protocol (Noise_IKpsk2) [1]. However, it exclusively supports the ChaCha20-Poly1305 suite, preventing its deployment in public, defense, and critical information infrastructure sectors where KCMVP-validated algorithms are mandated by the Electronic Government Act and the National Intelligence Service (NIS) Information Security Basic Guidelines. Accordingly, this study designs KWireGuard, which substitutes the data-plane AEAD with Galois/Counter Mode (GCM) based on Korean standard block ciphers while preserving the state machine and wire specifications. Note that listing ARIA and LEA on the eligible validation inventory is distinct from obtaining validated module certification for an implementation; formal approval requires a separate evaluation encompassing the Cryptographic Algorithm Validation Program (CAVP), power-on self-tests within cryptographic boundaries, and secure random number source bindings. This paper establishes these architectural prerequisites.

Five challenges must be addressed. First, the byte-level packet layouts of the 3-way handshake, cookie-based DoS mitigation, 1-RTT session establishment, and zero-copy transmission path must be preserved. Second, deterministic injective mappings are required when transforming the 64-bit transmission counter and the 24-byte cookie extended nonce into 12-byte GCM IVs to eliminate reuse stemming from the birthday paradox. Third, under the virtually mapped stack environments of Linux 6.1 and 6.6 LTS (ARM64, including 6.8 for distribution verification), passing stack buffers to scatterlists invalidates address translation, inducing Oops during cache flushing, alongside debug panics triggered by zero-length plaintexts. Fourth, as the ARM64 kernel crypto subsystem lacks ARIA acceleration paths and LEA is absent entirely from the subsystem, dedicated acceleration architectures are required to hide pipeline latency in in-order cores and eliminate register spills. Finally, on processors lacking dedicated hardware instructions, the system must refuse session establishment rather than silently downgrading to unvalidated software implementations.

WireGuard is built upon the Noise_IKpsk2 framework [2], implementing ChaCha20-Poly1305 (32B key / 12B nonce / 16B tag) [3] for session data and XChaCha20-Poly1305 (24B nonce) for cookie exchange as standalone libraries external to the kernel Crypto API. Among prior studies, Yuce et al. [4] reported an 11–19% throughput improvement through hardware-accelerated AES-GCM on gateways, while Ostroukh et al. [5] documented the structural advantages of WireGuard compared to OpenVPN and IPsec. However, these studies remain restricted to foreign standards (AES), failing to satisfy South Korean compliance requirements, and research on kernel-level architectures targeting Korean block ciphers is entirely absent.

KCMVP is a nationally accredited verification program that evaluates the security and implementation conformance of cryptographic modules to protect sensitive information in state and public institutions [6,7]. Among the candidate block ciphers eligible for validation, those offering 128-bit or higher security levels and supporting standard AEAD operational modes are ARIA, LEA, SEED, and HIGHT. Among these, SEED is constrained to a fixed 128-bit key length and cannot accommodate 256-bit session keys, while HIGHT is a 64-bit block cipher that cannot be combined with NIST SP 800-38D standard GCM, which mandates a 128-bit block size [8]. Consequently, ARIA [9] and LEA [10] were selected, as they support 128-bit blocks and 256-bit keys while exhibiting complementary structural designs (SPN versus ARX).

In ARIA, half of the substitution layer (S₁/X₁) is identical to the AES S-box, enabling the sharing of AES acceleration instructions. On x86 architectures, AVX/AVX-512 parallelization by Yoo et al. [11] (achieving up to a 10.6-fold speedup) and in-kernel acceleration paths based on AES-NI and GFNI are fully established; in contrast, the ARM64 kernel lacks any ARIA path, unlike its support for AES or SM4. Furthermore, ARM lacks GFNI, and the 128-bit vector width of NEON differs substantially from AVX-512, rendering x86 byte-transposition techniques non-portable. Prior ARMv8 ARIA research [12] also suffered from measurement errors that were subsequently corrected by Shin et al. [13], leaving verified kernel implementations unavailable. In contrast, LEA features a pure ARX structure devoid of S-boxes and does not rely on specialized extension instructions, making it advantageous for low-power embedded systems [14]. In particular, 2-way in-order cores such as the Cortex-A53 are vulnerable to load-use hazards, and fanless edge appliances demand high power-to-performance efficiency to prevent thermal throttling. This study proposes kernel-level acceleration designs that resolve these voids.

KWireGuard defines five threat models and corresponding mitigation requirements for deployment in untrusted public networks, embedded, and cloud environments. Against Dolev-Yao man-in-the-middle attackers who control the link to eavesdrop, spoof, modify, inject, drop, and replay packets, all transport data and control plane messages are protected using 256-bit symmetric-key encryption and 128-bit GHASH tags. Recognizing that GCM suffers catastrophic loss of confidentiality and integrity if an Initialization Vector (IV) is ever reused under the same key, KWireGuard guarantees deterministic, injective mappings that strictly forbid nonce duplication across all paths. Against endpoint hijacking attackers seeking to exploit connectionless roaming by spoofing source IPs to divert traffic, the system atomically updates endpoints only for packets that successfully pass both the authentication tag and replay window validations. Against DoS attackers attempting to exhaust computational resources via handshake floods or induce kernel Oops and memory leaks via anomalous payloads (e.g., 0-byte plaintexts or virtual mapped stack addresses), KWireGuard responds with stateless cookie validation, heap bounce buffers, and immediate key zeroization. Against co-resident side-channel attackers sharing physical CPUs and caches who attempt key exfiltration via Flush+Reload or Prime+Probe, the constant-time LEA-NEON implementation is enforced as the default. If table-based ARIA is selected, initialization logs are generated to ensure visibility of the active mode. To mitigate the risk of accidental degradation to unvalidated implementations due to misconfiguration or hardware detection failures, which would violate compliance and auditing mandates, automated fallbacks are strictly prohibited, and session establishment is unequivocally rejected.

KWireGuard decouples the kernel network stack, the WireGuard core, and the Linux Crypto API by introducing an independent cryptographic abstraction layer. [Figure 1] illustrates the module composition and interactions across layers.

The abstraction layer shown in [Figure 1] consolidates the AEAD operations requested by the core into a unified interface, encapsulating algorithm selection and acceleration path routing internally. To prevent in-flight packet decryption failures, state inconsistencies, and lock contention caused by runtime algorithm switching, a static binding approach is adopted, wherein the algorithm is determined exactly once at load time. While this mandates that all interfaces on the same host share identical algorithms and necessitates a temporary suspension of all tunnels during module reloading for algorithm updates, it is a deliberate trade-off to eliminate runtime synchronization locks, avoid pipeline stalls, and achieve absolute kernel determinism. Meanwhile, WireGuard adheres to a completely stealthy wire protocol that omits versioning, cipher suite identifiers, and negotiation metadata from headers. Because KWireGuard similarly omits cryptographic identification fields, peer mismatches in cipher modes result in immediate failure during the initial AEAD tag verification at the receiving node. As this failure is diagnostically indistinguishable on the wire from active tampering rejection, operational errors must be identified through pre-configuration validation in user-space management tools and failure telemetry logging in kernel debug builds. Cryptographic parameter designations are registered as read-only, and the supported modes are detailed in <Table 1>.

The validation scopes outlined in <Table 1> reflect the principle of CAVP separation by implementation. Under the KCMVP and FIPS 140 frameworks, conformance validation is performed on specific implementations rather than abstract algorithms. Consequently, even for the same LEA-256 algorithm, a pure C implementation and a 128-bit NEON vector implementation exhibit disparate instruction flows and resource utilization, thereby constituting distinct units that receive independent validation numbers. Similarly, ARIA is segregated into distinct testing perimeters: the kernel's common software implementation, Crypto Extension acceleration, and 4-block vector interleaving acceleration. Therefore, the registration endpoints for the five implementations are isolated under discrete nomenclatures, and their registration is deterministically gated by CPU feature flags.

The security of cryptographic modules fundamentally depends on the entropy quality utilized for key and nonce generation. KWireGuard leverages the standard kernel random number interface to seed ephemeral key exchanges (Curve25519) and generate cookie secrets alongside nonce counters. While the default CRNG in Linux 6.x, governed by a BLAKE2s/ChaCha20-based entropy pool, provides general-purpose randomness, it is not certified as a deterministic random bit generator (e.g., Hash_DRBG, HMAC_DRBG, or CTR_DRBG based on KS X ISO/IEC 18031) authorized by KCMVP. Therefore, deployment as a validated module presupposes a multi-layered binding strategy: either injecting high entropy from boot time by interfacing KCMVP-certified hardware random number generators or national cryptographic chipsets as entropy pool sources, or, when securing software-based perimeters, redirecting the random request layer to acquire key seeds directly from the kernel Crypto API's certified DRBG.

Because KCMVP and FIPS 140 mandate integrity verification at load and initialization times, four tiers of hierarchical Known-Answer Tests (KAT) are executed in the module's entry path. First, national standard test vectors (LEA-128/192/256) are processed through the kernel Crypto API's ECB template to validate the key scheduling and round encryption/decryption of the pure software implementations. Subsequently, for hardware-accelerated implementations, official vector validations and cross-roundtrip consistency checks against the in-kernel reference implementations are performed, thereby confirming byte-level operational integrity across SIMD register allocations, Structure of Arrays (SoA) vector transpositions, and pipelines. In the upper layers, standard kernel vector verifications for ARIA-GCM and AEAD roundtrips for LEA-GCM alongside each acceleration combination are enforced, accompanied by mandatory tamper-detection tests that intentionally corrupt Additional Authenticated Data (AAD) or ciphertexts to verify that authentication failures are correctly returned. Finally, the integrity of the routing tables, anti-replay windows, and DoS mitigation token buckets is sequentially verified. Any failure in this chain returns a fatal error and halts the loading process, preventing compromised cryptographic code from residing in memory.

The Fail-Closed policy statically binds the ciphers as read-only at load time, precluding runtime degradation. Furthermore, during the registration of hardware-accelerated modes, if the requisite CPU AES or Advanced SIMD feature flags are absent, registration is skipped. If a user forcibly designates such parameters, the AEAD transform allocation during the session establishment phase yields an algorithm-absence error, resulting in the immediate rejection of the handshake. The procedural flow ensuring roaming integrity is depicted in [Figure 2].

In [Figure 2], the receiving node first verifies the GHASH authentication tag in the in-place decryption path using the session key identified by the receiver index in the header. Endpoint updates, which atomically alter the destination IP, are exclusively executed for packets that pass both authentication tag and replay window validations, effectively neutralizing spoofing-based hijacking. The session key (32 bytes) and authentication tag (16 bytes) lengths required by WireGuard's transport plane precisely match those of fixed-length GCM based on ARIA-256 and LEA-256, enabling a 1:1 substitution without altering the packet header structure or overall length. However, because GCM's integrity is compromised by the exposure of the authentication key H if an IV is reused even once under the same key, injective mappings that preclude duplication in the two nonce input paths were designed and coupled with rekeying mechanisms to prevent counter exhaustion. Data transport packets utilize a 64-bit monotonically increasing counter, and the mapping tailored to the 12-byte GCM IV is defined as in &ltpEquation 1>.

<Equation 1> pads the upper 4 bytes with 0 and serializes the counter in little-endian format into the lower 8 bytes. As this constitutes an injective function where IV(n₁) ≠ IV(n₂) for any two nonces n₁ ≠ n₂, the probability of IV reuse within the same session key is rigorously 0. Meanwhile, NIST SP 800-38D [8] restricts the maximum number of invocations for a deterministic counter IV under a single key to 2⁶⁴; KWireGuard satisfies this constraint by preserving WireGuard's session key lifetime constants. Message-count-based rekeying is preemptively triggered at 2⁶⁰, and the hard-reject threshold—derived by subtracting the word alignment of the 8192-bit replay window to yield an effective window of 8128—is set to 2⁶⁴ − 8130. This secures a safety margin of approximately 2⁶⁴ − 2⁶⁰ &approx; 1.72 × 10¹⁹ messages, effectively averting counter rollover without severing the session. Time-based rekeying initiates at 120 seconds, allows a 60-second grace period, and definitively discards the extant key at 180 seconds.

Cookie exchange messages employ a 24-byte XChaCha20 extended nonce. To transition to the 12-byte GCM IV scheme, the sending node constructs the extended nonce as detailed in <Equation 2>.

<Equation 2> pads the upper 16 bytes with 0 and serializes an atomic 64-bit monotonically increasing counter in little-endian format into the lower 8 bytes. Without resorting to a cryptographic hash function, the receiving node directly extracts the lower 12-byte slice containing the preserved counter, as shown in <Equation 3>.

Deterministic uniqueness is established via <Equation 2> and <Equation 3>. For a monotonically increasing counter c ∈ [0, 2⁶⁴−1], the mapping f: xnonce → 0x00⁴ || le64(c), which extracts the lower 12 bytes, is injective. Consequently, f(xnonce(c₁)) ≠ f(xnonce(c₂)) for any distinct c₁ ≠ c₂, guaranteeing an IV reuse probability of 0 independent of the birthday bound limits (approximately 2⁴⁸) inherent in hash compression. As a defense-in-depth measure, the symmetric key for cookie encryption is freshly derived for every invocation from a cookie secret updated at 2-minute intervals, neutralizing long-term counter accumulation and protracted replay or analytical attacks.

The Noise framework [2] establishes domain separation by hashing a protocol name—composed of the pattern, DH function, AEAD, and hash name—into the transcript initialization value (h₀). To minimize state machine divergence from the upstream, KWireGuard retains the protocol name constant, thereby eschewing a priori separation at the transcript hash level. Nonetheless, handshakes are immediately rejected upon static public key decryption in the first handshake phase due to AEAD authentication tag mismatches, effectively isolating cryptographic interactions at the AEAD authentication layer. If formal separation is mandated, the architecture can be extended to dynamically derive unique protocol names for each active cipher. Furthermore, because Pre-Shared Key (PSK) mixing operates exclusively within the BLAKE2s-based key derivation chain and is orthogonal to the AEAD path, the quantum-resistance model remains intact despite primitive substitution.

The reference platforms, Linux 6.1 and 6.6 LTS, mandate virtual mapped stacks by default to thwart stack-overflow-based privilege escalation, relocating the kernel stack from the linear mapping region to the virtually mapped address space. Because scatterlist registration relies on address translation predicated on linear mapping, submitting a virtual mapped stack address produces an invalid page descriptor, resulting in an immediate kernel Oops during the cache flush phase within the cryptographic layer. KWireGuard mitigates this by introducing a dedicated bounce buffer based on a single dynamic heap allocation within the control plane encryption routine. Since this routine is invoked exclusively in the sleepable process context of a dedicated workqueue during the 1-RTT handshake control plane, it employs sleepable allocation flags and request properties. Even if allocation fails, it returns an error without precipitating panics or deadlocks, and the retransmission timer attempts recovery via exponential backoff, thereby preserving the integrity of the atomic softirq paths. The buffer is fixed at 32 bytes and processed via the slab allocator's O(1) path, eliminating fragmentation; sensitive data is zeroized immediately post-operation to eradicate key residues. Allocations occur solely during the 120-second handshake and rekeying cycles, averting any impact on transport plane latency jitter.

Defensive handling is also necessitated for zero-length plaintexts. The terminal encryption field of the handshake response entails encrypting a 0-byte plaintext to generate merely a 16-byte tag; however, registering a 0-length or empty buffer in environments with active scatterlist debugging immediately triggers a kernel panic. KWireGuard provisions a dedicated initialization path that, upon detecting a data length of 0, configures the table entry strictly for one Additional Authenticated Data (AAD) segment and bypasses data buffer registration.

Zero-copy and concurrency models are applied to the transport plane. Dedicated AEAD transform instances for transmission and reception are allocated exactly once during session key derivation and deallocated upon destruction, reducing per-packet allocation overhead to 0. Because these instances act as stateless descriptors holding only the symmetric key and algorithm specification, multicore workqueues construct independent request structures per packet during encryption and decryption, sharing the session key handles in full parallel without lock contention. Furthermore, the pre-reserved headroom of socket buffers preserves the DMA cache-line alignment of packet headers, while the available tailroom is recycled to perform in-place encryption and decryption. Since the 16-byte GCM tag conforms to the dimensions of the antecedent Poly1305 tag, buffer reallocation during tail appendage is averted.

KWireGuard incorporates three bespoke acceleration modules tailored to the microarchitectural characteristics of ARMv8-A processors, ranging from the low-power Cortex-A53 (In-order) prevalent in edge routers to the high-performance Cortex-A72 (Out-of-order) found in gateways. These two cores serve as independent reference targets representing embedded endpoints and high-bandwidth gateways, respectively. In heterogeneous multicore SoCs such as the RK3399, migration jitter can be mitigated by configuring kernel CPU affinity to bind parallel cryptographic workqueues to specific clusters. The characteristics of each module are delineated in <Table 2>.

The design and bottlenecks of the three modules in <Table 2> are as follows. ARIA-CE leverages the property that S₁ and X₁ are identical to the AES encryption and decryption S-boxes by utilizing Crypto Extension instructions (AESE/AESD) [15], applying a precomputed byte-transposition table via NEON vector table lookups (tbl) to compensate for the instruction-induced ShiftRows transformation [16]. However, because S₂ and X₂ must remain scalar table lookups, frequent transitions between vector and general-purpose registers combined with sequential 32-bit diffusion layers introduce serial bottlenecks. While 2-way in-order cores such as the Cortex-A53 experience severe pipeline stalls due to inability to bypass load-use delays, out-of-order cores mitigate stalls partially through out-of-order instruction scheduling.

ARIA-NEON4 exploits block independence in CTR mode by performing 4-way interleaved loads, loading the j-th word of four blocks into 128-bit registers in a Structure of Arrays layout. Word- and byte-level operations in the diffusion layer are vectorized across all four blocks using vector XOR and bit rotation, and substitution operations are interleaved to enhance instruction-level parallelism. However, as noted by Shin et al. [13], realizing full net gains requires 16-block concurrent transposition encompassing the substitution layer as well.

LEA-NEON focuses on hiding pipeline latency through 4-block interleaving. Because LEA is a pure ARX structure, 32-bit modular addition (⊞), XOR (⊕), and bitwise rotation map 1:1 to NEON instructions. According to the Cortex-A53 Technical Reference Manual [17], 32-bit vector additions and bit rotations carry a latency of 2–3 cycles; thus, single-block processing encounters pipeline stalls at every operation due to intra-round data dependencies (RAW hazards). In contrast, LEA-NEON loads four independent blocks into four registers (V₀ ~ V₃) in a Structure of Arrays layout, allowing a single instruction to process identical word positions across four blocks concurrently; furthermore, among 32 vector registers, it consumes at most 10–12 registers including state and round-key broadcasts, leaving more than 20 registers available. Static disassembly analysis of binaries compiled with standard kernel toolchains (GCC 11/12, Clang 14+, -O2) confirms zero register spills in the 32-round loop body with no stack-pointer-relative loads or stores; even with inlining, stack frames are constrained within 128 bytes, imposing negligible pressure on embedded kernel 8KB/16KB stacks.

A SIMD context switching mitigation scheme is applied across all acceleration modules. Employing NEON in kernel space requires disabling preemption and delineating entry and exit sections to preserve user-space FPSIMD state; executing this per block on high-frequency packet paths incurs severe cycle waste and latency jitter. KWireGuard introduces a scope-based SIMD guard that encapsulates multiple block operations within kernel symmetric cipher work buffers (configured as 4KB pages) into a single enter/exit session, amortizing overhead across numerous blocks. However, because entering disables preemption, batch expansion trades off against worst-case scheduling latency. On a Cortex-A53 (1.5GHz), the time to process 4KB (64 blocks) via LEA-NEON is calculated from pipeline latencies and cycle budget models to have a theoretical worst-case execution time of approximately 4–5μs, well within the 20–50μs budget of real-time kernels (PREEMPT_RT), establishing an amortization boundary that preserves deterministic responsiveness.

Because LEA-NEON features a pure ARX design devoid of S-boxes and lookup tables with no data-dependent branches or memory accesses, execution times and cache access patterns remain independent of secret keys, ensuring constant-time operation; on the basis of its cache-timing attack resistance, it is established as the module default. In contrast, while S₁/X₁ substitutions in ARIA-CE and ARIA-NEON4 execute in constant time via hardware instructions, S₂/X₂ operations retain memory-resident table lookups, leaving subtle timing leakage risks in cache-shared environments. This design reflects a pragmatic engineering trade-off prioritizing KCMVP compliance and legacy instruction reuse, making it suitable for dedicated appliances that do not share physical cores; when an operator configures ARIA, active cipher details are recorded in the kernel ring buffer during initialization to provide audit visibility. In virtualized environments, complete side-channel resilience for ARIA requires byteslice-based non-memory vectorization extensions.

This paper presented the kernel cryptographic layer architecture of KWireGuard, which replaces the data plane of WireGuard—previously restricted to the ChaCha20-Poly1305 suite—with the KCMVP-eligible block ciphers ARIA-GCM and LEA-GCM. While preserving the Noise_IKpsk2 state machine, wire format, zero-copy pipeline, and connectionless roaming, the design eliminates GCM collisions through injective nonce mappings and secures kernel memory safety via heap bounce buffers and zero-length plaintext branching under virtually mapped stack environments. Furthermore, across three acceleration variants covering in-order and out-of-order cores, we characterized the vector-scalar bottlenecks of ARIA and established the zero-spill structure of LEA, achieving cryptographic-module-level assurance through power-on self-tests and a Fail-Closed policy.

Future work will focus on empirical validation through full Linux kernel implementation. Deploying the five implementations across physical ARM Cortex-A boards and virtualization reference platforms with varying microarchitectures and cryptographic extensions, we will evaluate end-to-end throughput and decryption integrity under workloads ranging from small control frames to large file transfers, quantifying acceleration gains and pipeline bottlenecks across modules. Real-time control suitability will be evaluated via round-trip latency and jitter, while embedded appliance feasibility will be validated through memory footprint measurements. Finally, we will verify the enforcement of the Fail-Closed policy by testing handshake rejections in environments lacking hardware instructions, and demonstrate dynamic roaming integrity by measuring session continuity under continuous peer physical IP transitions.