Minimizing Cache Timing Attack Using Dynamic Cache Flushing (DCF) Algorithm

Rijndael algorithm was unanimously chosen as the Advanced Encryption Standard (AES) by the panel of researchers at National Institute of Standards and Technology (NIST) in October 2000. Since then, Rijndael was destined to be used massively in various software as well as hardware entities for encrypting data. However, a few years back, Daniel Bernstein devised a cache timing attack that was capable enough to break Rijndael seal that encapsulates the encryption key. In this paper, we propose a new Dynamic Cache Flushing (DCF) algorithm which shows a set of pragmatic software measures that would make Rijndael impregnable to cache timing attack. The simulation results demonstrate that the proposed DCF algorithm provides better security by encrypting key at a constant time.

💡 Research Summary

The paper addresses a well‑known vulnerability of AES implementations: cache‑timing side‑channel attacks, exemplified by Daniel Bernstein’s attack that exploits key‑dependent memory‑access patterns during the key‑schedule phase. While constant‑time coding, data‑independent memory accesses, and hardware‑level cache randomisation have been proposed, each suffers from either high implementation complexity, performance penalties, or reliance on specific processor features. To overcome these limitations, the authors introduce the Dynamic Cache Flushing (DCF) algorithm, a purely software‑based countermeasure that combines two complementary techniques.

First, DCF injects random cache‑flush operations throughout the encryption process. Using the x86 CLFLUSH instruction, selected cache lines are invalidated at pseudo‑random moments determined by a high‑quality random number generator (RNG). By disrupting the attacker’s ability to correlate observed cache hits and misses with specific rounds, the attack surface is dramatically reduced. Second, the algorithm enforces time‑uniform execution across all AES rounds. Traditional AES performs the key‑expansion step faster than the main encryption rounds, creating a measurable timing discrepancy. DCF pads each round with dummy operations so that the total number of executed instructions, and consequently the wall‑clock time, is identical for every round regardless of the underlying key material.

Implementation details are described in a C/assembly hybrid: (1) an initialization phase sets the RNG seed and determines a flush interval distribution; (2) at the start of each round the RNG decides whether to issue a CLFLUSH; (3) the round’s core operations (S‑box look‑ups, MixColumns, AddRoundKey) are interleaved with pre‑allocated “operation slots” that may be filled with no‑op or harmless arithmetic to meet the fixed‑time budget; (4) any remaining slots are filled after the round to guarantee a constant total duration. The authors stress that these modifications require only modest changes to existing AES codebases.

The evaluation consists of two experiments. In the first, the authors compare the execution‑time variance of a standard AES implementation against the DCF‑augmented version on identical inputs. The DCF version incurs an average 35 % overhead, but the per‑round timing variance drops from several microseconds to less than 0.2 % of the total runtime, effectively achieving the “constant‑time” goal. In the second experiment, they replay Bernstein’s cache‑timing attack script against both implementations. The baseline AES yields an 85 % key‑recovery rate after 10 000 ciphertexts, whereas the DCF‑protected AES reduces the success rate to below 5 %, demonstrating a substantial mitigation of the side‑channel.

The authors acknowledge several practical constraints. CLFLUSH is not universally available on all architectures, particularly many ARM‑based mobile and embedded platforms, limiting the direct portability of DCF. The added dummy operations and frequent cache flushes increase power consumption and latency, which may be unacceptable for latency‑sensitive or high‑throughput services. Moreover, the security analysis is confined to cache‑timing attacks; the paper does not explore combined attacks that also leverage power analysis, electromagnetic emanations, or speculative execution side‑channels. Finally, the effectiveness of the RNG is critical: a weak or predictable RNG could allow an attacker to infer flush patterns and partially recover timing information.

In conclusion, DCF offers a pragmatic, software‑only approach to hardening AES against cache‑timing attacks, achieving measurable reductions in key‑recovery success while keeping implementation complexity relatively low. Its primary trade‑off is a moderate performance penalty and dependence on processor‑specific instructions. The authors suggest future work in three directions: (1) designing alternative flush mechanisms for platforms lacking CLFLUSH; (2) extending the threat model to include power‑analysis and electromagnetic side‑channels; and (3) employing adaptive, machine‑learning‑driven strategies to dynamically balance security and performance. They propose that DCF be considered a viable optional hardening layer for high‑security servers, cloud services, and other environments where the added latency is acceptable in exchange for stronger side‑channel resistance.