© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
The definitive version of this article has been accepted for publication in the IEEE Transactions on Information Forensics and Security (TIFS).
DISARM: Target Electronic Device Informed Mitigation of Software Runtime Side-Channel Vulnerabilities arXiv:2606.19807v1 [cs.CR] 18 Jun 2026
Tasneem Suha1 , Tanzim Mahfuz1 , Rima Asmar Awad2 , Prabuddha Chakraborty1,∗ 1 Department of Electrical & Computer Engineering, University of Maine, Orono, ME, USA 2 Oak Ridge National Laboratory, Oak Ridge, TN, USA
{tasneem.suha, tanzim.mahfuz, prabuddha}@maine.edu [email protected] ∗ Corresponding Author
Abstract—Program runtime/timing attacks exploit variations in a program’s execution times to extract sensitive information from the program (e.g. encryption keys, sensitive variable data, intellectual property). State-of-the-art solutions to runtime sidechannel attacks attempt to balance the execution time of the sensitive code for different control flow paths to eliminate the timing leakage. However, during the mitigation process, most techniques do not consider the underlying hardware/device on which the target program is supposed to run on. This can lead to over-fixing (unnecessary extra operations), under-fixing (not solving the imbalance properly), and even failures. We propose DISARM, a joint hardware-software methodology (unlike any existing solution) for mitigating runtime side-channel vulnerabilities that utilizes timing values from real embedded devices to generate targeted software fixes. We implement DISARM to support C/C++/Java source codes and validate it across 22 standard benchmarks. DISARM outperforms state-of-the-art solutions such as PENDULUM and DifFuzzAR in terms of execution time overhead, code size overhead, and correctness on five different embedded/edge devices.
runtime that is generally more challenging to address due to heavy reliance on both the software and the hardware components of the embedded/edge devices.
Index Terms—Timing/Runtime Side-Channel, Automated Code Repair, Energy Efficient Cybersecurity, Hardware-Software Co-Security.
Fig. 1: Threat Model: Strength of the attacker depends on the level of access/knowledge.
I. I NTRODUCTION Low power embedded/edge devices are being widely used in different critical applications such as Industry 4.0, Healthcare, Surveillance, and Aerospace. These devices often handle sensitive data (e.g. additive manufacturing print pathways, encryption keys, patient information, sensitive biometric identifiers) making them a target for a wide range of adversaries [1]–[5]. These adversaries can employ different types of cyber-attacks to compromise the device. Such attacks include tampering, power side-channel attacks, firmware reverse engineering, and timing side-channel attacks [6]–[10]. In this work, we focus on timing side-channel attack specifically based on program
A timing/runtime side-channel attack involves the attacker measuring and analyzing the execution time of a given program to determine the values of sensitive data being processed by the program [11]–[14]. This execution time is dependent not only on the software but also on the underlying electronic hardware due to differences in pipelining, hazard control, speculation, and wider architectural differences [15]. The level of threat also depends on the effectiveness of the attacker in terms of measuring the execution time of the code (see Fig. 1). For example, an attacker having physical access to the device (a possibility because these devices are often deployed in open areas) may be able to obtain almost cycle-accurate estimation of the execution time [16]–[20]. In another threat model, the attacker may have only limited over-the-network access to the
Notice: This manuscript has been authored by UT-Battelle, LLC, under contract DE-AC05-00OR22725 with the US Department of Energy (DOE). The US government retains and the publisher, by accepting the article for publication, acknowledges that the US government retains a nonexclusive, paid-up, irrevocable, worldwide license to publish or reproduce the published form of this manuscript, or allow others to do so, for US government purposes. DOE will provide public access to these results of federally sponsored research in accordance with the DOE Public Access Plan (https:// www.energy.gov/ doe-public-access-plan).
Fig. 2: Overview of DISARM : Hardware-in-the-loop and specific threat model tailored mitigation of software timing vulnerabilities. device and hence the execution time measurement may be less accurate [21]. Hence, a timing side-channel mitigation framework must consider software, hardware, and also precise threat model to generate efficient and effective solutions. However, most state-of-the-art (e.g., DifFuzzAR [22], PENDULUM [23]) runtime side-channel mitigation frameworks do not consider the underlying hardware and the specific attacker threat model during the mitigation/fixing process leading to gross over/under fixing [24]–[26]. Recent works such as HASTE [27] has looked into the quantification of different timing side-channel vulnerabilities based on a given software, hardware (only simulation), and the attacker threat model. However, HASTE was designed to only detect (no mitigation) timing side-channel vulnerabilities and utilized the Berkeley Out-of-Order Machine (BOOM) [28] simulator for mimicking different hardware architectures (no real devices). In this work, we propose DISARM: Device Informed Software Vulnerability Mitigation, a framework that addresses the main shortcomings of the state-of-the-art frameworks (e.g. HASTE, PENDULUM, DifFuzzAR) by: (1) Quantifying the timing side-channel vulnerabilities using real electronic devices/hardware in-the-loop; (2) Fixing/mitigating the discovered vulnerabilities based on the specific threat model and hardware, prioritizing both safety and increased system efficiency. We implement DISARM and integrate it into the commercial embedded systems development flow for automatic detection and fixing of timing side-channel vulnerabilities. We evaluate DISARM using 22 commonly used sensitive software functions on five Internet-of-Things (IoT) and edge/embedded devices: (1) Jetson Nano ARM Cortex-A57 MP Core processor; (2) Jetson Orin Nano ARM Cortex-A78AE processor; (3) Jetson AGX Xavier Carmel ARM v8.2; (4) Jetson Xavier NX Carmel ARM v8.2; (5) Raspberry Pi Quad-core CortexA72. Empirical results demonstrate the ability of DISARM to precisely fix timing side-channel vulnerabilities while having minimal impact on system performance and energy efficiency (compared to constant-time programming solutions, DifFuzzAR [22], and PENDULUM [23]). In summary, we make the following contributions: 1) Developed an automated framework for performing hardware-in-the-loop evaluation of software timing side-
channel vulnerabilities. 2) Designed algorithms to optimally mitigate the discovered timing side-channel vulnerabilities for the specific threat model and the underlying hardware, limiting compute/energy overheads. 3) Implemented the algorithms and framework as a highly parameterized automated tool that has been integrated into the C/C++/Java software development tool-chain. 4) Evaluated the framework (in comparison to constant-time programming solutions, DifFuzzAR [22], and PENDULUM [23]) using 22 software benchmarks (C/C++/Java) on 5 embedded devices. II. BACKGROUND Next, we will briefly discuss the considered threat models, key timing vulnerabilities, and related works in this area. A. Threat Model & Underlying Hypotheses Based on the attacker’s accessibility, two types of attacks can occur. To elevate the ‘weak attack’, the attacker should have some access to the system. (1) The attacker understands the appropriate moments to commence and conclude the timing of the program. (2) The attacker can measure the time it takes to execute specific segments of the program. (3) The attacker possesses a fundamental objective of the system’s purpose or goal. Based on this threat model, the attacker’s timing sensitivity for weaker attacks will be: Tbase = w1 (Wa ) + w2 (Mr ) + w3 (Kobj )
(1)
where, Wa is the window awareness, Mr is the measurement resolution, Kobj is the objective knowledge. w1 , w2 , w3 ∈ R ≥ 0 are weights signifying the importance of each factor. The attack can be made robust by the attacker if the attacker: (1) Possesses the software code or binary; (2) Holds physical access to the system; (3) Can manipulate specific inputs to the system. For strong timing attacks: Tstrong =
Tbase 1 + α(Kprog + P + I)
(2)
where Kprog is the full program knowledge, P is the complete physical access, and I is the partial but nontrivial input manip-
ulation. α > 0, is a scaling factor controlling how drastically these strong-attacker attributes reduce Tstrong . Among these types of attacks, the threat becomes significantly stronger if an attacker can remotely collect multiple timing traces of the same software or binary code. Let us assume that: (1) Ti is the measured execution time for the ith run; (2) n is the number of traces; (3) µ0 , µ1 are the mean timings for different secrets (e.g., key bit 0 vs key bit 1); (4) σ is the standard deviation of the noise in timing. Additionally, the signal-to-noise ratio (SNR) improves with more traces. Fig. 1 shows an overview of the discussed threat model. |µ0 − µ1 | √ (3) SN R = σ/ n Fig. 3: Branch on Secret (BoS) vulnerability. B. Vulnerability Analysis Branch on Secret (BoS) and Loop on Secret (LoS) are the two dominant ways to capture secret data influence program runtime through control flow. HASTE models timing leakage by identifying secret-dependent branches and secret-dependent loop bounds as key sources of measurable runtime variation. Many practical embedded timing leaks reduce to these patterns, arising from secret-dependent paths or loop counts. 1) Branch on Secret Analysis: A Branch-on-Secret (BoS) vulnerability occurs when a secret-dependent condition controls program flow. BoS severity is an estimate of the maximum timing difference introduced by a branch whose direction depends on a secret variable [27]. If an attacker’s timing measurement precision (sensitivity) is finer than this value, the system is considered vulnerable. In practical terms, if an attacker can resolve timing differences smaller than the BoS severity, the secret-dependent branch becomes exploitable. Let B1 and B2 be the two branch successors of a basic block BB that depends on a secret variable where d is the first common post-dominator of B1 and B2. Let T () represent the execution time of a path. A simplified BoS Severity is: BoS Severity = |T (B1 → d) − T (B2 → d)|
(4)
The higher this difference, the easier it is for an attacker to distinguish which branch was taken on the basis of timing analysis. The smaller that gap, the harder it is for an attacker to tell which path ran. For example, in Fig. 3, the secret is the value of exponent. Each loop iteration tests the exponent’s lowest bit with if (exponent % 2 == 1). If set (path B1), it performs an extra modular multiply, result = (result∗ base)%modulus; otherwise (path B2), it skips this step. Both paths rejoin at exponent >> 1. 2) Loop on Secret Analysis: When the number of iterations in a loop is controlled by the secret is called loop-onsecret [27]. The LoS Resilience is the minimum number of loop iterations (controlled by a secret) required for a timing difference to become discernible to an attacker. Let BB be the loop head (secret-dependent) and ∆t be the per-iteration timing difference. Let T be the smallest timing difference an attacker can reliably measure. So, the LoS Resilience will be: LoS Resilience = |
T | ∆t
(5)
LoS Resilience = min n|n × ∆t ≥ T n∈N
(6)
Here, ∆t is the per iteration time difference derived from the hardware-level basic block timings in the control flow graph. n is the number of loop iterations controlled by the secret. In other words, the loop must run at least LoS Resilience times before the attacker can reliably discern a timing difference attributable to the secret-controlled loop count. So, if the number is large, the loop has to run a long time before any timing difference becomes visible, making the leak impractical and if the value is small even a tiny change in the secret produces a measurable time shift, so the code will be highly vulnerable. For example, in Fig. 4, the secret kernel_size controls both the inner-loop bound, while (j < kernel_size), and, through output_size, the outer-loop bound, while (l < output_size). Each inner-loop iteration performs one multiply–accumulate with nearly fixed cost ∆t, so one outer-loop iteration costs about kernel_size · ∆t. Since the outer loop repeats this work output_size times, total runtime remains a deterministic function of kernel_size; an attacker with timing resolution T can infer the secret when kernel_size · ∆t ≥ T . C. Related Work FlowTracker [30] is a static information-flow analysis tool for detecting timing leaks. Rodrigues et al. introduce a sparse representation of implicit flows that computes control dependencies in a single dominance-tree traversal, yielding a number of edges linear in program size. It only flags vulnerable branches and cannot repair code or measure real hardware timing. Dudect [29] takes a complementary, dynamic approach. It is a lightweight black-box testing tool that runs code on target hardware and uses statistical hypothesis testing to check if execution time differs for different secret inputs. The advantage of Dudect is practicality as it reflects actual hardware behavior and is easy to deploy. However, it only answers ‘constant-time or not’ for a given routine and it does not localize the leak or suggest fixes. CT-Wasm [24] represents a language-based defense where Watt et al. define Constant-Time WebAssembly (CT-Wasm), a strictly typed extension of Wasm that enforces that well-typed programs cannot leak secret data via timing.
TABLE I: Comparing DISARM with existing software timing side-channel analysis/mitigation approaches. Study
Framework Objective
Analysis Type
PENDULUM* [23]
Repair Scope Java
Identify timing Dynamic vulnerabilities and constant-time fixing DifFuzzAR* Identify timing Dynamic Java vulnerabilities and [22] constant-time fixing CT-Wasm Identify vulnerabilities Formal Assembly [24] and enforce constant-time dudect [29] Detect non-constant time Dynamic N/A program FlowTracker Detect timing-dependent Static N/A [30] control flow and data access patterns Nemisis [31] Balance secret-dependent Dynamic Binary branch, mitigate nemesis attack HASTE [27] Quantify and localize Static+Dynamic N/A timing side-channel vulnerabilities DISARM (ours) Quantify, localize, and Static+Dynamic C/C++/Java repair timing side channel vulnerabilities
Hardware Aware N/A
N/A
N/A Architecture
Repair Mechanism Pattern based source repair using conditional assignments and loop bound rewriting Source refactoring using single exit conversion and mirrored branch computation Type system rewrite in CT-Wasm; no post-hoc repair Detection only via statistical timing tests
N/A
Detection only via static implicit flow analysis
Partial
Binary rewriting to balance secret-dependent branches
Simulation
Detection/quantification only using hardware-aware CFG analysis
Real Hardware
Hardware-aware padding to satisfy BoS/LoS thresholds on target hardware
*: State of the Art (SOTA)
Fig. 4: Loop on Secret (LoS) vulnerability. By building a verified, sound type checker, authors even supply a compiler pass to rewrite existing crypto libraries into CTWasm; for example, a TweetNaCl implementation compiled under CT-Wasm is shown to run in equal time for all inputs. This formal approach is powerful because it provides provable guarantees of no timing leakage. Potential limitations are: it applies only to code written or ported to the CT-Wasm subset and it is a static method that requires developers to use a specialized language/engine (e.g., browser or Node with CT-Wasm support). NemesisGuard [31] targets microarchitectural ‘Nemesis’ side channels from interrupt latency in
trusted execution environments (TEEs). It is a static binaryinstrumentation framework that pads secret-dependent code paths to equalize the cost of handling an interrupt. However, it has no focus on addressing data-dependent timing. DifFuzzAR [22] is an automated repair tool, focused on Java, which applies fixes after DifFuzz [32] finds a vulnerable method. It is especially effective on control-flow-based leaks, which makes it a suitable platform to compare with our DISARM framework. DifFuzzAR’s goal is to produce functionally correct, constant-time code. PENDULUM [23] is another recent automated repair tool for timing leaks at the source level (Java). Ruan et al. describe PENDULUM as the first approach that automatically locates and fixes timing side-channel vulnerabilities in code. It uses fuzzing to quantitatively estimate the amount of leakage in different program regions, then applies pattern-driven source transformations to equalize execution time, outperforming DifFuzzAR. However, the repairs come at a cost; the patches incur substantial slowdowns compared to the original code. PENDULUM represents a state-of-theart source-level mitigation, but its limitations include high fixed-code overhead and the lack of on-device validation. In contrast, DISARM combines software analysis with hardwarein-the-loop measurement to assess and mitigate timing leaks on real embedded platforms, complementing and extending the capabilities of these existing approaches at low overhead. The repair mechanisms of these tools are also different. Unlike PENDULUM and DifFuzzAR, which mitigate timing leakage through device-agnostic source-to-source transformations, DISARM does not enforce a single generic balancing template. DifFuzzAR repairs Java code by source-level refactoring, including removal of early exits, restructuring of secretdependent conditionals by mirroring branch computations with fresh temporaries, and, when possible, replacement of secretdependent loop guards with public arguments. PENDULUM
performs quantification-guided, pattern-based repair by rewriting secret-dependent assignments into constant-time conditional assignments and transforming secret-dependent loops to execute up to a secret-independent upper bound while making extra iterations functionally inert. In contrast, DISARM uses cycle measurements from the target device to insert only the amount of additional work needed to reduce the measured BoS and LoS leakage below a specified attacker threshold on the deployment hardware. In summary, in Table I, we provide a qualitative comparison of DISARM with existing frameworks designed for detecting and mitigating timing sidechannel vulnerabilities. III. M OTIVATION A. Why Hardware-Awareness During Mitigation? The majority of existing mitigation approaches (discussed above) focus on addressing timing mismatches by enforcing complete control-flow balancing (constant-time programming [33], [34]). On many edge and IoT platforms the extra branches, arithmetic masks, and dummy memory accesses needed to equalize every path slow programs dramatically, swell code size, and consume precious power units. These realities motivate our work DISARM rather than ‘one fixed solution’ for all, we pair lightweight program analysis with hardware-in-the-loop timing measurements (dynamic across any hardware device) to identify only the code regions that truly leak on the actual device under the actual workload, and then apply the repairs balancing low overhead. B. Why Consider Specific Attack Scenario? As outlined in Section II-A, the feasibility and severity of a timing side-channel attack depend critically on the attacker’s level of access to the target system. When an adversary can interact with the device only remotely every measurable delay must be large enough to survive network jitter and operating system noise. For example, this pushes the timing sensitivity threshold up to 5-50 CPU cycles. Subtle variations like 15 cycles are therefore unlikely to be distinguishable and the system appears secure. The situation changes markedly when the attacker has local or physical access (leading to near cycle accurate attack). Ignoring the attack scenario during mitigation risks both extremes: under-fixing and over-fixing. IV. DISARM M ETHODOLOGY To address the shortcomings of state-of-the-art timing side-channel vulnerability mitigation frameworks, we develop DISARM that automatically: (1) Performs timing leakage evaluation directly on real IoT/Edge devices; (2) Optimally mitigates timing imbalances based on a given threat model and timing information from the system (hardware + software); (3) Supports the detection/fixing of Branch on Secret (BoS) and Loop on Secret (LoS) vulnerabilities by considering some important factors: (i) Branch prediction effect, (ii) Cache states effect. Fig. 2 illustrates the complete workflow of DISARM.
Algorithm 1: Extract CPU Cycles Input: [CF G, NRun ] Output: [CF G new ] 1 CF G new ← ∅ 2 C ← [] 3 C←0 4 Creal ← 0 5 R ← 1000000 6 for BB ∈ CF G // BB: Basic Block 7 do 8 envBB ← EncapsulateBB (BB) 9 envBB.exe ← Compile(envBB) 10 for i ∈ NRun do 11 C ← CalculateCycle(EnvBB.exe) 12 C.append(C) 13 14 15 16
C ← sum(C)/NRun Creal ← C/R CF G new [BB][“cpuCycle”] ← Creal return CF G new
A. Hardware-Software CPU Cycles Extraction To extract CPU cycles for a given software code, a control flow graph (CFG) is generated by creating adjacency relationships for each basic block based on program statements, branching, and loops. CPU cycle count for each basic block, based on the hardware architecture, is determined. Algorithm 1 automates the retrieval of CPU cycles for each basic block, using inputs: (i) CFG, the control flow graph of the benchmarked software; (ii) NRun , specifying how many times to measure cycles for each block. We first iterate over all basic blocks (BB) to encapsulate them within a f or loop set to R = 1,000,000 iterations, enabling precise cycle measurement through the EncapsulateBB() function. This function, (i) initializes the blocks’ live variables; (ii) prepares the cache state. The encapsulated blocks are then compiled into an executable in lines 6-9. To capture cache sensitivity without contaminating the block logic, EncapsulateBB() performs randomized cache warming immediately before timing. On each run, it draws a seed and a warm fraction (both overridable via environment knobs), selects that proportion of the block’s live variables, and touches one cache line per selected variable. The encapsulated blocks are compiled into an executable using compile-time instrumentation, which modifies the program before execution. In lines 10-13, CPU-cycles (Creal ) for each block are measured NRun times, with the average cycles (C) computed to capture the variable timing effect on the CPUcycles. We consider random input values for each of the given benchmarks to evaluate the CPU-cycle because basic-block execution time can vary with input-dependent data values, memory-access behavior, cache state, and branch behavior. Using random inputs across repeated runs helps capture representative timing variation and prevents the cycle estimate from being biased toward a single fixed input instance. To determine the Creal , we divide the C by the f or loop iteration count R. Finally, CFG is updated (CF G new ) with the measured CPU
cycles for each basic block. B. Taint Analysis Algorithm 2: Construct Candidate Sensitive Set Input: [P rg, Sseed ] Output: [Staint , Sctrl ] 1 Staint ← Sseed 2 Sctrl ← ∅ 3 W ← Sseed 4 G ← BuildProgramGraph(P rg) 5 while W ̸= ∅ do 6 v ← Pop(W) 7 for stmt ∈ UseStmts(G, v) do 8 if stmt defines x from v then 9 if x ∈ / Staint then 10 Staint ← Staint ∪ {x} 11 W.append(x) 12
13 14 15 16 17
18
if v flows to a parameter or return value in stmt then u ← ResolveFlow(stmt, v) if u ∈ / Staint then Staint ← Staint ∪ {u} W.append(u) if v influences a branch predicate or loop bound in stmt then Sctrl ← Sctrl ∪ {v}
Algorithm 3: DISARM for BoS Input: [benchmark, S, T , NRun , , Bt1 , Bt2 , P] Output: [f ixCode] 1 G←∅ 2 CF G ← GetTaintedCFG(benchmark, S) 3 CF G ← GetCycle(CFG, NRun ) 4 CF G ← Splice(CFG) 5 CF G ← AssignBranchTimes(CFG, Bt1 , Bt2 , P) // push blended times onto spliced edges: tlong = Bt1 P + Bt2 (1 − P), tshort = Bt1 (1 − P) + Bt2 P 6 while T rue do 7 for BB ∈ CFG // BB: Basic Block 8 do 9 if BranchOnSecret(BB, S) then 10 postDom = GetPostDoms(BB, CF G) 11 B1 , B2 = Immediate BB successors 12 uniqDom ← FindUniqDom(postDom) 13 L1 ← FindLongestPath(B1 , uniqDom) 14 L2 ← FindLongestPath(B2 , uniqDom) 15 S1 ← FindShortestPath(B1 , uniqDom) 16 S2 ← FindShortestPath(B2 , uniqDom) 17 if |L1 − S2 | > T ∨ |L2 − S1 | > T then 18 if |L1 − S2 | > |L2 − S1 | then 19 Pshortest ← S2 20 G ← AddNoise(S2 , CFG) 21 CF G ← GetCycle(G, NRun ) 22 23
19
return [Staint , Sctrl ]
24 25
Algorithm 2 takes the program P rg and the user-defined sensitive seed set Sseed as inputs and returns Staint , the full set of variables derived from sensitive seeds, and Sctrl , the subset that affects control flow and is passed to the BoS/LoS analysis stage. First, it initializes the tainted set Staint defined by the user and creates an empty sensitive-control set Sctrl . Next, it places all seed variables into a worklist W, which stores variables whose data flow still needs to be analyzed. Then it builds a program graph G from the source code to capture assignments, variable uses, function calls, return values, branches, and loops (line 4). While the worklist is not empty, it removes one variable v and checks every statement where v is used (lines 6,7). From lines 8-11, if a statement defines a new variable x from v, then x is added to the tainted set and inserted into the worklist for further propagation. If v flows through a function parameter or return value, it resolves the corresponding variable u, adds it to the tainted set, and continues propagation from u (lines 12–16). Finally, if v appears in a branch predicate or loop bound, it is added to Sctrl because it may create a BoS or LoS vulnerability from line 17 to 18. C. Branch on Secret Severity Mitigation To effectively mitigate the BoS vulnerability within the software code while considering the attacker’s timing sensitivity, we introduce Algorithm 3. This algorithm offers a
26 27 28
29
else Pshortest ← S1 G ← AddNoise(S1 , CFG) CF G ← GetCycle(G, NRun ) continue else f ixCode ← ConvCFG2Code(CFG) return f ixCode
targeted approach to repair vulnerability (BoS) using the corresponding hardware architecture, the algorithm takes inputs as: (i) benchmark is the source code to be analyzed; (ii) S, the filtered sensitive-control set containing variables generated from Algorithm 2 (iii) T is the attacker’s timing sensitivity, which is a measure of the attacker’s ability to exploit timing side-channel attacks; (iv) NRun , specifying how many times to measure cycles for each block; (v) Bt1 and Bt2 are the two timing values for two different branches to consider the branching effect; and (vi) P is the probability of selecting one particular branch.The algorithm then generates a tainted CF G using the GetT aintedCF G() function. After that using the GetCycle() function (based on Algorithm 1) calculates the CPU cycles and updates the CFG (line 2-3). From lines 4-5, Splice() function splices each two-way branch by inserting synthetic edge nodes, one per successor path. Splicing lets us assign per successor timing without mutating basic blocks. For every secret-dependent branch, it locates the post dominating
join of its two successors and computes the longest/shortest path costs from each successor path to the join using Bellman–Ford relaxations, then pushes edge times onto the spliced nodes to model the indirect branching effect using user provided inputs Bt1 , Bt2 and P. In lines 6-10, the algorithm iteratively traverses the CFG, identifying basic blocks (BB) whose branching decisions are influenced by S. For each such block, it computes the post-dominator set (postDom) using the GetP ostDoms() function. By analyzing the longest and shortest paths to the unique immediate post-dominator (lines 11-12) when the Branch-on-Secret (BoS) path-length discrepancy exceeds the attacker’s timing sensitivity T , compile-time instrumentation (lines 13–25) invokes the AddN oise() function to inject non-operational (dummy) instructions into the shorter execution path to reduce the timing imbalance between secret dependent paths. To prevent compiler optimization from removing the padding, it does not use empty loops or unused arithmetic instructions, instead, it generates semantically neutral operations that update “volatile” variables. Since these updates are treated as observable side effects, the compiler preserves the inserted operations while the original program output remains unchanged. This process is repeated until the BoS severity falls below the T threshold. The modified CFG is then translated back to software code (lines 26-28). D. Loop on Secret Severity Mitigation Algorithm 4: DISARM for LoS Input: [benchmark, S, T , NRun , Lmin , , Bt1 , Bt2 , P] Output: [f ixCode] 1 G←∅ 2 CF G ← GetTaintedCFG(benchmark, S) 3 CF G ← GetCycle(CFG, NRun ) 4 CF G ← Splice(CFG) 5 CF G ← AssignBranchTimes(CFG, Bt1 , Bt2 , P) // push blended times onto spliced edges: tlong = Bt1 P + Bt2 (1 − P), tshort = Bt1 (1 − P) + Bt2 P 6 while T rue do 7 for BB ∈ CF G // BB: Basic Block 8 do 9 if LoopHeadOnSecret(BB, S) then 10 succBB = Immediate BB successors 11 L = FindLongestPath(succBB, BB) 12 S = FindLongestPath(succBB, BB) 13 if T /|L − S| < Lmin then 14 G ← AddNoise(S, CF G) 15 CF G ← GetCycle(G, NRun ) 16 continue 17 18
19
else f ixCode ← ConvCFG2Code(CF G) return f ixCode
We reduce the Loop-on-secret vulnerability using Algorithm 4. The algorithm takes inputs as (i) benchmark is
the source code to be analyzed; (ii) S, the filtered sensitivecontrol set containing variables generated from Algorithm 2 (iii) T is the attacker’s timing sensitivity which measure of the attacker’s ability to exploit timing side-channel attacks; (iv) Lmin , a threshold for the minimum LoS Resilience; (v) NRun , specifying how many times to measure the cycles for each block; (vi) Bt1 and Bt2 are the two timing values for two different branches to consider the branching effect; and (vii) P is the probability of selecting a particular branch. Algorithm 4 targets Loop-based side-channel (LoS) attacks. Identifies loops whose iteration count is influenced by secret variables using the LoopHeadOnSecret() function on line 9. After finding the loop head on a secret, by calculating the longest and shortest paths within the loop body (lines 9-12), the algorithm assesses the loop’s LoS resilience (T /|L − S|). If resilience falls below the minimum LoS Resilience (Lmin ), compile-time instrumentation (lines 13–15) uses the AddN oise() function to insert non-operational (dummy) instructions into the shorter path, thus increasing timing variability. The padding code is written using volatile updates, so the compiler treats the inserted operations as observable and does not remove them during optimization. This avoids unreliable padding patterns such as empty loops or unused computations. The modified CF G is then translated back into the software code. E. Modular Design for Scalability/Extensibility We present a language-agnostic framework that identifies and mitigates software runtime vulnerabilities by recording the CPU cycle of every basic block in the program’s control flow graph (CFG) to locate blocks whose timing breaches the adversarial threat model and hardware-aware patching, which means inserting calibrated no-operation (NOP) instructions that equalize the latencies of those blocks while considering microarchitectural constraints of the target platform. To demonstrate the robustness of the framework, we evaluated it on the C/C++ and Java environments. Although these languages differ in syntax, compilation model, and source file organization, the core workflow, cycle accurate severity analysis followed by architecture-conscious padding, remains identical across them. 1) Supporting C++/C: In the C++/C version, the process begins by parsing the main source file using “pycparser” to build the Abstract Syntax Tree (AST). From this AST, variable names, types (including support for multidimensional arrays), and their initializers are extracted from the main() function. The specific basic block is then retrieved using a custom basic block analyzer that identifies code segments corresponding to individual basic blocks. It operates on raw C code by reading the file line by line and identifying segmentation points based on keywords such as, }, main, if , while, and return. These keywords are treated as termination points for basic blocks. A list of start line and end line indices is used to segment the code into candidate basic blocks. Then, blocks are refined by removing redundant braces and empty lines. Building a control flow graph CFG (in Algo. 1) for a C function whose statements have already been split into basic blocks. As parsing the basic blocks contain the starting and the ending of each block, edges are added from every lexical successor.
TABLE II: Benchmarks for evaluating DISARM with constant-time programming, DifFuzzAR [22], and PENDULUM [23]. Language
Java*
C++/C
Benchmarks blazer modpow1 blazer array blazer sanity blazer straightline blazer unixlogin themis boot-stateless-auth themis picketbox blazer passwordEq example PWCheck themis jdk Benchmark 1 Benchmark 2 Benchmark 3 Benchmark 4 Benchmark 5 Benchmark 6 Benchmark 7 Benchmark 8 Benchmark 9 Benchmark 10 Benchmark 11 Benchmark 12
Description modPow1 unsafe function array unsafe function sanity unsafe straightline unsafe login unsafe unsafe isEqual validatePassword unsafe passwordsEqual unsafe pwcheck1 unsafe isEqual unsafe RSA Mod Pow Exponentiation Function [35] Relu Activation Function [36] Leaky Relu Activation Function [37] Sigmoid Activation Function [38] Data Compression (Run Length Encoding) [39] CNN (Convolution Operation) Function [40] ElGamal Mod Pow Exponentiation Function [41] Diffie Hellman Mod Pow Exponentiation Function [42] Feistal Cipher (Round Function) [43] XOR Stream Cipher (Bitwise Exclusive-OR Operation) [44] Hill Cipher (Matrix-multiplication-mod-26 Function) [45] RC4 Cipher (Key-Scheduling (KSA) Function) [46]
Vulnerabilities BoS, LoS BoS BoS BoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS, LoS BoS BoS BoS
*All the Java codes (fixed) are taken from [47] [?]
TABLE III: Hardware devices used in our experiments. Devices Devices 1 Devices 2 Devices 3 Devices 4 Devices 5 Devices 6
Description 11th Generation Intel Core i9-11900H Processor Jetson Nano ARM Cortex-A57 MPCore processor Jetson Orin Nano ARM Cortex-A78AE processor Jetson AGX Xavier Carmel ARM v8.2 Jetson Xavier NX Carmel ARM v8.2 Raspberry Pi Quad-core Cortex-A72
In Algorithm 1 for encapsulating (EncapculateBB()) the basic block, a separate ‘envelope’ C template file is parsed, and variable declarations are inserted immediately after a void function, followed by a main function. The basic block itself is inserted into the for loop found in the envelope. To avoid semantic errors, the tool verifies that the block is not merely an initialization block and contains no control structures like if , f or, or while. If the basic block accesses arrays with variable indices, loop bounds are safely modified with constraints (e.g., i ≤ 1000000 && x ≤ 1000000). The final enveloped code is written into a new output C file. Then using CompileBB() (in Algo. 1) function, we compile the new output C file. 2) Supporting Java: To generate the control flow graph for Java based program we need to analyze the lexical features, for example, the keywords, class, operation, etc. In the Java version, we use the “javalang” parser to analyze the main Java source file, extracting declared variables and their initializers, including support for arrays and multideclarator variables. Similar to the C version, a basic block is extracted from the source using a Java-specific basic block analyzer, which follows a more semantically aware approach. It reads Java files line by line similarly, but primarily focuses on braces { and } to define logical boundaries. Java’s analyzer uses a more minimal set of termination keywords and relies on an inner method split list at keywords to segment blocks when encountering control flow statements like if and while. The
tool then detects which variables are referenced in the basic block by scanning tokens, carefully ignoring method names and dot-qualified symbols. To generate the CFG for Java, we have used the same procedure, where it iterates over all the basic blocks and adds edges according to the lexical features based on the starting and ending of the basic blocks. In Algorithm 1 for encapsulating (EncapculateBB()) the basic block for Java version, the new ‘envelope’ Java template is parsed as plain text, and variable declarations are inserted after the public static void method declaration, followed by the main function. The basic block is inserted after the for loop header. If the block is found to consist solely of variable declarations, it is skipped. Finally, the newly composed Java code is written to the output file, with proper formatting and indentation. Then, using the CompileBB() function, we compile the newly created Java file to extract the CPU cycles. V. R ESULTS : JAVA B ENCHMARKS Next, we demonstrate the effectiveness of DISARM and compare it to SOTA techniques (PENDULUM, DifFuzzAR) for a set of standard Java benchmarks (see Table II). PENDULUM and DifFuzzAR apply device-agnostic source-level repairs; they do not use timing measurements from the target hardware; this is by their design. We have directly used the open-sourced implementations of PENDULUM and DifFuzzAR (as provided by the authors). In contrast, DISARM measures timing on the actual deployment device and applies only the mitigation needed for the selected attacker model. The hardware-aware mitigation flow is a core part of DISARM’s contribution. We evaluate DISARM on five real-world embedded devices to focus on several hardware architectures as outlined in Table III. Based on the attacker’s threat model (see Section II-A), we set two thresholds: timing sensitivity (T ) and minimum LoS resilience (Lmin ), and number of traces (NT ). Based on
TABLE IV: Comparing the code-fixing/mitigation efficacy of DISARM with SOTA techniques for different edge devices and Java benchmarks. Here timing sensitivity T = 10, PDL = PENDULUM [23], and DFZ = DifFuzzAR [22]. Average execution Time (msec) Line of Codes ∆ ∆ Devices Benchmarks PDL DFZ PDL DFZ Orig DISARM Orig PDL DFZ Orig DISARM [23] [22] [23] [22] Orig PDL DFZ (%) (%) (%) blazer modpow1 555.89 558.06 568.89 559.85 0.71 0.32 -1.59 30 51 35 37 7 -14 2 blazer array 0.78 2.28 1.48 1 28.21 - 56.14 -32.43% 26 45 34 47 21 2 13 blazer sanity 1.13 2.2 * 1.13 0 - 49.09 † 25 47 33 27 2 -20 -6 blazer straightline 1.24 2.23 * 1.5 28.21 -32.74 † 24 48 55 39 15 -9 -16 blazer unixlogin 0.26 0.35 0.26 0.29 11.54 -17.14 8.61% 33 37 59 66 33 29 7 themis boot 1.14 3.3 1.3 1.16 1.75 -64.85 -10.77 38 57 45 43 5 -14 -2 Raspberry PI themis picketbox 1.14 1.49 1.16 1.147 0.44 -23.00 -1.12 31 44 46 42 11 -2 -4 blazer passwordEq 1.17 1.39 1.2 1.17 0 -15.83 -2.50 33 54 41 33 0 -21 -8 example PWCheck 1.17 3.28 1.387 1.2 2.56 -63.41 -13.48 22 47 30 24 2 -23 -6 themis jdk 1.5 3.38 1.589 1.53 2.00 -54.73 -3.71 21 51 31 25 4 -26 -6 Average 6.72 −37.96 −7.12 9.9 -4.6 -2.6 Median 1.87 −40.92 −3.105 6 -14 -5 blazer modpow1 421 485 506 438 4.04 -9.69 -13.44 30 51 35 35 5 -16 0 blazer array 1.16 2.8 1.21 1.18 1.72 -57.85 -2.47 26 45 34 49 23 4 15 blazer sanity 1.22 2.5 * 1.22 0 -51.2 † 25 47 33 26 1 -19 -7 blazer straightline 1.24 2.7 * 1.57 26.61 -1.85 † 24 48 55 38 14 -10 -17 blazer unixlogin 0.25 0.32 0.26 0.25 0 -21.87 -3.84 33 37 59 65 32 28 6 themis boot 1.29 3.03 1.36 1.29 0 -57.42 -5.14 38 57 45 43 5 -14 -2 Jetson Nano themis picketbox 1.18 1.62 1.31 1.29 9.32 -20.37 -1.52 31 44 46 42 11 -2 -4 blazer passwordEq 1.29 1.53 1.35 1.29 0 -15.68 -4.44 33 54 41 33 0 -21 -8 example PWCheck 1.2 3.2 1.39 1.22 1.67 -61.87 -12.23 22 47 30 24 2 -23 -6 themis jdk 1.55 3.42 1.61 1.57 1.29 -54.09 -2.48 21 51 31 25 4 -26 -6 Average 4.47 -39.19 −5.70 9.7 -9.9 -2.9 Median 1.48 -46.52 −4.15 5 -15 -5 blazer modpow1 152.09 162.25 152.45 152.1 0.01 -6.25 -0.22 30 51 35 35 5 -16 0 blazer array 0.63 1.32 0.965 0.71 12.70 -46.21 -26.42 26 45 34 42 16 -3 8 blazer sanity 0.64 1.58 * 0.69 7.81 -56.32 † 25 47 33 38 13 9 5 blazer straightline 0.69 1.62 * 0.83 20.29 -48.76 † 24 48 55 26 2 -22 -29 blazer unixlogin 0.12 0.14 0.13 0.12 0 -25.71 -20.00 33 37 59 64 31 27 5 themis boot 0.68 1.36 0.81 0.68 0 -50.0 -16.04 38 57 45 43 5 -14 -2 JetsonAGX themis picketbox 0.70 0.82 0.754 0.73 2.96 -10.97 -3.18 31 44 46 42 11 -2 -4 blazer passwordEq 0.71 0.79 0.75 0.71 0 -11.02 -5.33 33 54 41 33 0 21 8 example PWCheck 0.72 1.32 0.76 0.721 0.14 -45.37 -5.13 22 47 30 24 2 -23 -6 themis jdk 0.82 1.12 0.91 0.87 6.10 -22.32 -4.39 21 51 31 25 4 -26 -6 Average 5 −32.30 -10.09 8.9 -4.9 -2.1 Median 1.55 −35.55 -5.23 5 -8.5 -1 blazer modpow1 65.15 78.46 74.23 65.2 0.07 -16.90 -12.16 30 51 35 35 5 -16 0 blazer array 0.13 0.44 0.15 0.15 15.38 -65.90 0 26 45 34 32 16 -3 8 blazer sanity 0.13 0.15 * 0.14 7.69 -6.66 † 25 47 33 29 13 9 5 blazer straightline 0.15 0.3 * 0.17 13.33 -43.33 † 24 48 55 36 12 -12 -20 blazer unixlogin 0.16 0.15 0.18 0.16 0 0 -22.22 33 37 59 56 23 19 -3 themis boot 0.13 0.37 0.16 0.14 2.94 -62.16 6.25 38 57 45 43 5 -14 -2 Intel Core i9 themis picketbox 0.13 0.17 0.14 0.137 2.23 -23.03 7.14 31 44 46 45 11 -2 -4 blazer passwordEq 0.14 0.17 0.15 0.14 0 -19.99 -6.66 33 54 41 33 0 21 8 example PWCheck 0.14 0.37 0.18 0.13 0 -62.16 -22.22 22 47 30 24 2 -23 -6 themis jdk 0.18 0.42 0.22 0.19 5.55 -54.76 -13.63 21 51 31 25 4 -26 -6 Average 4.09 -35.49 -7.88 9.1 -4.7 -2.0 Median 2.58 -33.18 -9.41 8 -7.5 -2.5 Orig: Original program, PDL: PENDULUM [23], DFZ: DifFuzzAR [22], *: Incorrectly fixed, ∆: difference between DISARM and others (e.g. Average execution time of DISARM - Average execution time of PDL), †: not applicable because the corresponding repair was incorrect or unavailable; -: raw average/median value not meaningful for that column;
the threat model inspired by HASTE [27], for ‘weak attack’ we choose timing sensitivity (T ) = 10 for BoS severity and minimum LoS resilience (Lmin ) = 5 for LoS severity, on the other hand for ‘stronger attack’ we choose timing sensitivity (T ) = 5 for BoS severity and minimum LoS resilience (Lmin ) = 10 for LoS severity. These values are used as representative experimental settings for our devices and benchmarks; however, DISARM is parameterized and can support other thresholds depending on the deployment scenario. We also consider whether an attack is able to take multiple traces for the benchmarks, so we choose number of traces (NT ) = 10. To parse the Java code, we have used “javalang” in all the devices. We use cloc (Count Lines of Code), a lightweight open-source CLI that scans codebases and counts code, comment, and blank lines per language. A. CPU cycles measurements We utilize ‘Performance Counter’, or simply P erf (included in the Linux kernel under tools/perf) [48], to calculate Creal for all devices, as described in Algorithm 1. These calculated Creal are subsequently used to assess timing vulnerabilities in the system through Algorithm 3 and Algorithm 4. Algorithm 1 processes asset-tainted CFGs from Algorithms 3 and 4, using NRun = 100 for all benchmarks (see Table II). B. Utilizing DISARM to Mitigate Vulnerabilities We employ Algorithm 3 to mitigate the BoS (Branch on Secret) vulnerability, generating revised software subroutines through hardware-in-the-loop testing using benchmarks such as the unsafe modular exponentiation function (modPow1 unsafe function, see Table II), where S denotes the branch on the secret key bit collected from Algorithm 2, (here we consider the worst case scenario by taking Staint , while to avoid overfixing, DISARM filters this set and repairs only variables that influence security-relevant control flow, such as branch predicates or loop bounds, and whose measured timing effect exceeds the attacker-specific threshold on the target device (Sctrl )) and T = 10; with NRun = 100; NT = 1. Our goal is to minimize the BoS value less than the timing sensitivity (threshold = 10). If the value is less than the threshold value, we can say that the system is secure in terms of the attack scenario as well as the underlying hardware architectures. We use Algorithm 4 to mitigate LoS (Loop on Secret) vulnerabilities by generating new software subroutines via hardware-in-theloop testing, demonstrated with benchmarks (see Table II), where S denotes a branch on the key bit (exponent). The DISARM framework was evaluated at a timing sensitivity (T ) = 50 with Lmin and NRun = 100. The goal is to maximize LoS resilience, which measures the minimum loop iterations needed to detect timing discrepancies, with higher values indicating greater security. C. Comparing DISARM with PENDULUM and DIfFuzzAR PENDULUM and DifFuzzAR (SOTA) repair timing leaks mainly by applying source code transformations that are independent of the target hardware. Their goal is to make secretdependent code paths more balanced or to convert the program into a safer single-exit structure. In contrast, DISARM first
measures the execution time on the actual target device and then uses the selected attacker model to decide how much padding is really needed. Therefore, DISARM adds padding only until the measured BoS or LoS leakage falls below the security threshold for that specific hardware. As a result, DISARM’s lower runtime and code size overhead do not mean that all tools use the same repair strategy. Instead, they show that hardware calibrated and threat-model aware repair can avoid some unnecessary extra work introduced by fully device agnostic source level balancing. After performing algorithms (Algorithm 3 & Algorithm 4), we compared our automated repaired programs with SOTA techniques PENDULUM and DifFuzzAR in Table IV to evaluate the time and space impact on different devices. To make the correctness comparison explicit, each repaired program is checked using three criteria: successful compilation, preservation of the original program behavior under regression testing, and satisfaction of the configured BoS/LoS security threshold. In Table IV, “*” indicates an incorrect fix, i.e., the repaired program did not preserve the original behavior under regression testing. In contrast, all DISARM-fixed programs were successfully compiled, passed regression tests and met the configured BoS/LoS threshold, supporting the 100% % correctness claim for DISARM. We chose 10 benchmarks for Java, which are both common in PENDULUM and DifFuzzAR, for a better perception of the extensive analysis. In this table, the average execution time column compares the runtime of the regression testsuit between DISARM-fixed code and the original program, the PENDULUM-fixed program and the DifFuzzAR-fixed program. ∆Orig column shows the percentage difference with the original program and DISARM-fixed program, which is 6.72% on average and 1.87% on median for Raspberry PI, which indicates that the program fixed by DISARM is only 6.72% slower than the original code. For Jetson nano ∆Orig is 4.47% on average with 1.48% on median. Column ∆PDL reports the percentage execution-time difference between DISARM-fixed and PENDULUM-fixed code; negative values indicate lower execution time for DISARM. Its average ranges from -32% to -39% across devices, showing that DISARM is nearly 40% faster than PENDULUM. Similarly, ∆DFZ compares DISARM with DifFuzzAR-fixed code, averaging -5.70% (Jetson Nano) to -10.09% (Jetson AGX). For space overhead, ∆Orig reports the line-of-code difference between the DISARM-fixed and original code. Takeaway: DISARM mitigates BoS/LoS with low overhead vs. original (median ≤ 2%), while running ≈ 40% faster than PENDULUM and ≈ 6–10% faster than DifFuzzAR, and using fewer lines than both across devices. The column ∆PDL is the difference of lines with the PENDULUM-fixed code, which is -9.9 in average and -15 in median for Jetson Nano, shows that the fixed code by DISARM is taking 9.9 fewer lines than PENDULUM-fixed code. For other devices the average values are almost -5. The ∆DFZ represents the variations of lines with DifFuzzAR-fixed code. Based on the performance analysis (Time and space), we
Fig. 5: BoS Severity after fixing the code-base with DISARM (Baseline model) for timing sensitivity T = 5.
Fig. 6: BoS Severity after fixing the code-base with DISARM (Baseline model) for timing sensitivity T = 10. can say that our framework outperforms the SOTA techniques. VI. R ESULTS : C++/C B ENCHMARKS We evaluate DISARM on five real-world embedded devices to focus on several hardware architectures as outlined in
Table III and utilizing the same CPU-cycle measurement techniques as specified for the Java benchmarks (see Section V-A). Based on the attacker’s threat model (see Section II-A), we set two thresholds: timing sensitivity (T ) and minimum LoS resilience (Lmin ), and number of traces (NT ). Based on the
TABLE V: BoS Severity after fixing the code-base with DISARM considering the effects of branch prediction and cache states for timing sensitivity T = 10; Bt1 = 2 cycles; Bt2 = 1 cycle and P = 99%. Branch Prediction Effect Cache States Effect Benchmark Intel Core i9 Jetson Nano Raspberry PI Jetson AGX Intel Core i9 Jetson Nano Raspberry PI Jetson AGX Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Benchmark 1 13.74 7.45 18.4 9.34 11.35 6.34 14.74 8.8 13.67 9.09 19 9.56 12 7.05 13.89 8.25 Benchmark 2 7.15 7.15 12 7.72 15.33 9.75 8.1 8.1 19.4 2.3 12.35 8.69 16.12 9 7.69 7.69 Benchmark 3 12.33 3.5 13.3 8.45 17.11 7.45 12.33 5.5 14.67 3.5 14 9 18.98 8.05 13.9 4.12 Benchmark 4 10.07 8.15 14.9 7.83 17.38 6.5 12.50 8.15 11.83 9.66 15.12 9.14 18 6.8 10.07 8.15 Benchmark 5 3.37 3.37 10.7 6.5 10.98 9.13 7.8 7.8 6.87 6.87 11.3 7.45 12.25 9.5 3.37 3.37 Benchmark 6 10 10 16.8 9.5 18 10 13.14 9.81 11.9 8.7 17.25 9.85 18.54 9.3 10 10 Benchmark 7 13.69 5.86 18.75 9.6 26.5 8.56 15.28 9.2 13.17 8.99 19.18 9.78 27 9.12 13.69 5.86 Benchmark 8 12.36 7.26 24.24 7.8 21.88 7.88 17.28 8.19 13.56 8.96 24.98 8.25 22.54 8.56 12.36 7.26 Benchmark 9 3.05 3.05 5.86 5.86 11 6.8 5.10 5.10 2.61 2.61 6.5 6.5 12.56 7.8 3.05 3.05 Benchmark 10 3.16 3.16 4.45 4.45 9.83 9.83 4.00 4.00 4.73 4.73 4.65 4.65 10.12 9.5 3.16 3.16 Benchmark 11 2.06 2.06 2.86 2.86 5.02 5.02 3.35 3.35 2.16 2.16 3.56 3.56 6.89 6.89 2.06 2.06 Benchmark 12 3.96 3.96 3.33 3.33 3.33 3.33 3.25 3.25 2.89 2.89 4.05 4.05 3.56 3.56 3.96 3.96
Fig. 7: LoS Severity after DISARM for timing sensitivity 50 and minimum LoS Resilience is 10 with variable timing effect. threat model inspired by HASTE [27], for ‘weak attack’ we choose timing sensitivity (T ) = 10 for BoS severity and minimum LoS resilience (Lmin ) = 5 for LoS severity, on the other hand for ‘stronger attack’ we choose timing sensitivity (T ) = 5 for BoS severity and minimum LoS resilience (Lmin ) = 10 for LoS severity. These values are used as representative experimental settings for our devices and benchmarks; however, DISARM is parameterized and can support other thresholds depending on the deployment scenario. PENDULUM [23] and DifFuzzAR [22] nativeimplementations do not directly support C++/C source code. Hence, for C/C++ benchmarks, we have created a nearly faithful implementation of their published repair strategies only as a secondary comparison (primary comparison was done on Java Benchmarks in Section V, earlier).
1) Capturing the Effects of Branch Prediction: To consider the impact of branch prediction, for each branch decision we consider a probability P (a user-input that can be empirically determined) that the right branch will be chosen. This is simulated in our framework by splitting each branch line into two pathways: one with minimal delay Bt2 (right prediction); the other one with a longer delay Bt1 (wrong prediction). We choose P = 99%, Bt1 = 2 cycles, and Bt2 = 1 cycle for the reported experimental results. These values can be userdetermined in our automation framework. 2) Capturing the Effects of Different Cache States: To consider the effect of different cache states across different embedded devices, each instrumented basic block randomly samples a subset of its local variables and ’warms’ them by accessing the respective cache line immediately before the timing window; the warm set is resampled on every run from a
Fig. 8: LoS Severity after DISARM for timing sensitivity 50 and minimum LoS Resilience is 5 with variable timing effect. fresh seed. This step is carried out for each run to calculate the average basic block runtime (NRun = 100, in Algorithm 1). A. Mitigating BoS Vulnerabilities Algorithm 3 mitigates the BoS vulnerability in RSA modular exponentiation by synthesizing hardware-in-the-loop patched subroutines (Table II), where S denotes the branch on secret key bit e and NRun = 100. 1) Baseline (No Cache/Branch Effect): Fig. 5 illustrates the BoS severity for six benchmarks, T = 5 (marked by a red dashed line), comparing multiple devices before and after applying the DISARM framework. Each subplot represents a specific benchmark, illustrating BoS severity levels, where higher values indicate a greater risk of information leakage. DISARM reduces the severity value under the attacker’s timing sensitivity for all pairs of benchmark devices except benchmark 2, which follows a similar trend, except for Devices 1 and 4, since the BoS severity of the benchmark within these devices is already below or equal to T = 5. The differences between devices arise from the microarchitectural constant that remains even after flushing caches and removing the branching effects (e.g., pipeline depth/width and front-end bandwidth (fetch/decode), instruction-latency mix and micro code sequences, out-of-order and renaming resources, vector/ALU port availability, and clock frequency). Architectures like Intel’s i9-11900H (Cypress Cove), Cortex-A78AE, and Cortex-A76 have wider front ends (decode more instructions per cycle), larger out-of-order windows and register files, more execution ports, and shorter instruction latencies; Thus, wider cores issue/retire more micro-ops per cycle and hide latency better, completing each basic block in fewer cycles
than narrower Cortex-A57, Carmel, or Cortex-A72 designs. Similar results are observed for T = 10 in Fig. 6. Takeaway: DISARM cuts BoS severity by up to ≈ 93% (e.g., 12.8 → 3.6, 10.5 → 1.5, 14.0 → 1.0), driving severities to ≤ T = 5 with NRun = 100. 2) Considering the Effect of Branch Prediction: The left half of the Table V reports BoS severity for the source code and after applying DISARM when the attacker timing threshold T = 10. Almost all the benchmarks show a decreasing trend in BoS severity values. Several entries did not change, for example, Intel Core i9 Benchmarks 5 (3.37), 6 (10.00), 9 (3.05), and 11 (2.06) because the original paths were already symmetric or below the threshold T =10. Takeaway: With attacker threshold T = 10, DISARM cuts BoS severity on average ≈ 61% across multiple devices; Benchmarks like B5/B6/B9/B11 remain same since the severity is already ≤ T . BoS value differ across hardware because the measured per-block cycle numbers differ across hardware (e.g. different pipelines, execution latencies, clocking). Even with the same Bt1 , Bt2 and P for all pairs of benchmark devices. 3) Considering Both Cache State & Branch Prediction Effect: The right side of the Table V extends the controlflow model to include the effect of different cache states. BoS declines for most device–benchmark pairs; Benchmarks 5, 9, 10, 11, and 12 are unchanged because they already meet the LoS resilience threshold. The differences across devices arise
TABLE VI: LoS Severity after DISARM fixes the code-base accounting for the effects of branch prediction and cache states. where, timing sensitivity T = 50, minimum LoS Resilience Lmin = 5 ; Bt1 = 2 cycles ; Bt2 = 1 cycle and P = 99%. Branch Prediction Effect Cache States Effect Benchmarks Intel Core i9 Jetson Nano Raspberry PI Jetson AGX Intel Core i9 Jetson Nano Raspberry PI Jetson AGX Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Orig DISARM Benchmark 1 3.63 6.71 2.71 5.34 7.89 6.34 3.63 6.71 3.65 5.5 2.63 5.23 4.16 7.09 3.59 6.06 Benchmark 2 6.99 6.99 4.16 6.47 5.1 9.75 6.99 6.99 2.57 21.73 4.04 5.75 3.1 5.5 6.5 6.5 Benchmark 3 4.05 14.28 3.75 5.91 6.71 7.45 4.16 14.28 3.4 14.28 3.57 5.5 2.63 6.21 3.59 12.13 Benchmark 4 4.96 8.15 3.35 6.38 6.5 6.5 4.96 6.14 4.22 5.17 3.3 5.47 2.77 7.35 4.96 6.13 Benchmark 5 14.83 14.83 4.67 7.69 5.47 9.13 14.83 14.83 7.27 7.27 4.42 6.71 4.08 5.25 14.83 14.83 Benchmark 6 5 5 2.97 5.26 4.5 10 5 5 4.2 5.74 2.89 5.05 2.69 5.37 5 5 Benchmark 7 3.65 8.53 2.6 5.2 5.84 8.56 3.65 8.53 3.79 5.59 2.6 5.11 1.85 5.48 3.58 8.53 Benchmark 8 4.04 6.88 2.06 6.41 6.34 7.88 4.04 6.88 3.68 5.53 2 6.06 2.21 5.84 4.04 6.88 Benchmark 9 16.39 16.39 8.53 8.53 7.35 6.8 16.39 16.39 19.15 19.15 7.69 7.69 3.98 6.41 16.39 16.39 Benchmark 1015.82 15.82 11.23 11.23 5 9.83 15.82 15.82 10.57 10.57 10.75 10.75 4.94 5.26 15.82 15.82 Benchmark 1124.27 24.27 17.48 17.48 9.69 9.69 24.27 24.27 23.14 23.14 14.04 14.04 7.25 7.25 24.27 24.27 Benchmark 1212.62 12.62 15.01 15.01 15.01 15.01 13.55 13.55 17.3 17.3 12.34 12.34 14.04 14.04 12.62 12.62
from how each device’s memory system is built. Cache size/associativity (whether data fits or spills), cache hit/miss latency, prefetcher behavior, TLB coverage, and DRAM bandwidth all vary by platform. Because of this, the same uneven access pattern may cause many cache/TLB misses on one CPU but few on another, so the timing penalty can be large on one device and small on another.
already satisfactory (per threat model). For example, in Device 1 for Benchmark 1, LoS resilience is 20, which is already above the minimum LoS resilience 10. A similar sets of results is presented in Fig.8 when LoS resilience is 5.
Takeaway: Accounting for cache states, DISARM’s padding cuts BoS severity by ∼ 50–88% across platforms when, T ≤ 10.
B. DISARM for LoS Mitigation We use Algorithm 4 to mitigate LoS (Loop on Secret) vulnerabilities by generating new software subroutines via hardware-in-the-loop testing. The DISARM framework was evaluated at a timing sensitivity (T ) = 50 with, NRun = 100, Bt1 = 2, Bt2 = 1 and P = 0.99. The goal is to maximize LoS resilience, which measures the minimum loop iterations needed to detect timing discrepancies, with higher values indicating greater security. 1) Baseline (No Cache/Branch Effect): Fig. 7 shows LoS resilience across benchmarks on five devices. Each subplot corresponds to one device, with benchmarks on the x-axis and LoS resilience on the y-axis; the red dashed line marks the minimum threshold, Lmin = 10.
Fig. 9: BoS severity (before and after applying DISARM) for Traces (NT ) = 10 and Timing sensitivity T = 5.
Takeaway: DISARM boosts LoS resilience by pushing it above the Lmin = 10 across most benchmarks in 4/5 devices (80%). Device 1, Device 2, Device 3, Device 4, and Device 5 demonstrate a notable improvement in resilience value with DISARM for certain benchmarks, effectively surpassing the threshold (≥ 10) in most cases, whereas resilience under normal conditions varies more significantly. DISARM does not apply any fixes if the device-benchmark pair resilience is
Fig. 10: BoS severity (before and after applying DISARM) for Traces (NT ) = 100 and Timing sensitivity T = 5. 2) Considering the Effect of Branch Prediction: The left half of the Table VI reports LoS severity for the original
source code and after applying DISARM when Lmin = 5. Our framework DISARM is able to approximate the effect of branch prediction given the specified user-defined parameters, Bt1 , Bt2 , and P. We consistently observe improved LoS resilience across diverse benchmark–device combinations. Takeaway: Applying DISARM raises the minimum LoS resilience in all devices with gains of 64% → 253% (core i9), 56% → 211% (Jetson Nano), 91% → 122% (Raspberry Pi) and 24% → 85% (Jetson AGX), while the entries already above the threshold remain unchanged. 3) Considering Both Cache State & Branch Prediction Effect: The right half of the Table VI extends the control-flow model to include the effect of different cache states. Results across devices reflect the differences in cache capacity, associativity, hit/miss latencies, prefetcher, and DRAM bandwidth. Takeaway: Accounting for cache states, the LoS metric roughly doubles on average (median ×1.9) and passes Lmin , which means that the LoS severity is mitigated for the benchmarks across multiple devices.
C. DISARM for Mitigating Multiple Timing Trace Attacks A powerful timing attacker can improve their success rate by collecting repeated measurements from the same target. We therefore set the timing sensitivity to T = 5 and evaluate NT = 10, 100 traces. We choose four benchmarks (Benchmarks 9–12), which are vulnerable before fixing at the same sensitivity on five heterogeneous devices (three devices for NT = 100). As shown in Figs. 9 and 10, all benchmarks initially violate the threshold, with leakage ranging from ∼20 cycles in Feistel on Device 3 to ∼9 cycles in Hill on Device 1. After applying DISARM via Algorithm 3, all benchmark– device pairs fall within 2.5–5 cycles. VII. D ISCUSSION
B. Future Research Directions As future work, we will diversify AddNoise() with semantically neutral dummy-operation sequences, making padding less predictable under non-timing channels such as power, electromagnetic, or fault-based attacks while preserving the existing BoS/LoS detection and repair logic. We will also extend DISARM to support more complex control flow, including recursion, indirect jumps, and function-pointer dispatch, and evaluate it under stronger adversarial settings such as attacker-controlled cache/branch-predictor states and worstcase leakage-maximizing input pairs. Finally, we will improve scalability through parallel module/procedure-level CFG construction, compact interprocedural summaries inspired by ThinLTO [49], and CPU/GPU-based sparse-graph traversal frameworks such as Hornet [50]. VIII. C ONCLUSION Timing side-channel attacks can expose sensitive data from embedded systems that are routinely used in a wide range of applications (e.g. healthcare, additive manufacturing). Stateof-the-art software runtime side-channel attack mitigation frameworks do not consider the underlying hardware information leading to over/under-fixing of the vulnerabilities. In this work, we introduce an automated framework (DISARM) that can mitigate software timing vulnerabilities with a complete transparent understanding of the underlying electronic hardware and the associated threat model. We have integrated DISARM into the commercial embedded systems development flow and demonstrate its effectiveness in detecting/mitigating timing-based leakage for 22 software benchmarks across five unique embedded devices. DISARM was able to optimally mitigate all discovered vulnerabilities with lower overhead compared to constant-time solutions. IX. ACKNOWLEDGMENT The authors gratefully acknowledge funding and technical support from the U.S. Army Engineer Research and Development Center ITL via Other Transaction Agreement #W15QKN-17-9-5555 Sub-Agreement #C5-23-1003.
A. Limitations of DISARM DISARM currently mitigates timing leakage by inserting semantically neutral dummy operations through AddNoise(). This is lightweight and effective for the timing-focused BoS/LoS threat model considered in this work. However, the current implementation uses a fixed padding pattern, which may be easier to distinguish under other observation channels, such as power, electromagnetic, or fault-based attacks. Therefore, deployments targeting these stronger adversaries may require diversified padding sequences. The current implementation supports structured control flow, including straight-line code, if/else branches, for/while loops, arithmetic operations, and common array accesses. It does not claim full support for unrestricted recursion, indirect jumps, goto statements, or function-pointer-based control flow. When such constructs are detected, DISARM reports the region as unsupported rather than applying an unsafe automatic repair.
R EFERENCES [1] W. H. Hassan et al., “Current research on internet of things (iot) security: A survey,” Computer networks, vol. 148, pp. 283–294, 2019. [2] M. Devi and A. Majumder, “Side-channel attack in internet of things: A survey,” in Applications of Internet of Things: Proceedings of ICCCIOT 2020. Springer, 2021, pp. 213–222. [3] A. Zankl, H. Seuschek, G. Irazoqui, and B. Gulmezoglu, “Side-channel attacks in the internet of things: threats and challenges,” in Research Anthology on Artificial Intelligence Applications in Security. IGI Global, 2021, pp. 2058–2090. [4] T. Alladi, V. Chamola, B. Sikdar, and K.-K. R. Choo, “Consumer iot: Security vulnerability case studies and solutions,” IEEE Consumer Electronics Magazine, vol. 9, no. 2, pp. 17–25, 2020. [5] H. F. Atlam and G. B. Wills, “Iot security, privacy, safety and ethics,” Digital twin technologies and smart cities, pp. 123–149, 2020. [6] F.-X. Standaert, “Introduction to side-channel attacks,” Secure integrated circuits and systems, pp. 27–42, 2010. [7] R. Spreitzer, V. Moonsamy, T. Korak, and S. Mangard, “Systematic classification of side-channel attacks: A case study for mobile devices,” IEEE communications surveys & tutorials, vol. 20, no. 1, pp. 465–488, 2017.
[8] Y. Zhou and D. Feng, “Side-channel attacks: Ten years after its publication and the impacts on cryptographic module security testing,” Cryptology ePrint Archive, 2005. [9] B. Köpf and D. Basin, “An information-theoretic model for adaptive side-channel attacks,” in Proceedings of the 14th ACM conference on Computer and communications security, 2007, pp. 286–296. [10] Y. Lyu and P. Mishra, “A survey of side-channel attacks on caches and countermeasures,” Journal of Hardware and Systems Security, vol. 2, pp. 33–50, 2018. [11] J. Zhang, C. Chen, J. Cui, and K. Li, “Timing side-channel attacks and countermeasures in cpu microarchitectures,” ACM Computing Surveys, vol. 56, no. 7, pp. 1–40, 2024. [12] M. Neve, J.-P. Seifert, and Z. Wang, “A refined look at bernstein’s aes side-channel analysis,” in Proceedings of the 2006 ACM Symposium on Information, computer and communications security, 2006, pp. 369–369. [13] B. Chevallier-Mames, M. Ciet, and M. Joye, “Low-cost solutions for preventing simple side-channel analysis: Side-channel atomicity,” IEEE Transactions on computers, vol. 53, no. 6, pp. 760–768, 2004. [14] P. Rohatgi, “Improved techniques for side-channel analysis,” Cryptographic Engineering, pp. 381–406, 2009. [15] “Hardware side-channel.” [Online]. Available: https://niemierlab.nd.edu/ research/thread-03-hardware-security-side-channels/ [16] A. Li, J. Wang, and N. Zhang, “Chronos: Timing interference as a new attack vector on autonomous cyber-physical systems,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 2426–2428. [17] S. A. Crosby, D. S. Wallach, and R. H. Riedi, “Opportunities and limits of remote timing attacks,” ACM Transactions on Information and System Security (TISSEC), vol. 12, no. 3, pp. 1–29, 2009. [18] B. B. Brumley and N. Tuveri, “Remote timing attacks are still practical,” in European Symposium on Research in Computer Security. Springer, 2011, pp. 355–371. [19] B. Danev, H. Luecken, S. Capkun, and K. El Defrawy, “Attacks on physical-layer identification,” in Proceedings of the third ACM conference on Wireless network security, 2010, pp. 89–98. [20] M. Weiß, B. Heinz, and F. Stumpf, “A cache timing attack on aes in virtualization environments,” in Financial Cryptography and Data Security: 16th International Conference, FC 2012, Kralendijk, Bonaire, Februray 27-March 2, 2012, Revised Selected Papers 16. Springer, 2012, pp. 314–328. [21] D. Brumley and D. Boneh, “Remote timing attacks are practical,” Computer Networks, vol. 48, no. 5, pp. 701–716, 2005. [22] R. Lima, J. F. Ferreira, A. Mendes, and C. Carreira, “Diffuzzar: automatic repair of timing side-channel vulnerabilities via refactoring,” Automated Software Engineering, vol. 31, no. 1, p. 1, 2024. [23] H. Ruan, Y. Noller, S. Tizpaz-Niari, S. Chattopadhyay, and A. Roychoudhury, “Timing side-channel mitigation via automated program repair,” ACM Trans. Softw. Eng. Methodol., Jul. 2024, just Accepted. [Online]. Available: https://doi.org/10.1145/3678169 [24] C. Watt, J. Renner, N. Popescu, S. Cauligi, and D. Stefan, “Ct-wasm: type-driven secure cryptography for the web ecosystem,” Proceedings of the ACM on Programming Languages, vol. 3, no. POPL, pp. 1–29, 2019. [25] S. He, M. Emmi, and G. Ciocarlie, “ct-fuzz: Fuzzing for timing leaks,” in 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST). IEEE, 2020, pp. 466–471. [26] T. Van Goethem, C. Pöpper, W. Joosen, and M. Vanhoef, “Timeless timing attacks: Exploiting concurrency to leak secrets over remote connections,” in Proceedings of the 29th USENIX Conference on Security Symposium, 2020, pp. 1985–2002. [27] P. Chakraborty, J. Cruz, C. Posada, S. Ray, and S. Bhunia, “Haste: Software security analysis for timing attacks on clear hardware assumption,” IEEE Embedded Systems Letters, vol. 14, no. 2, pp. 71–74, 2021. [28] “Boom core.” [Online]. Available: https://boom-core.org/ [29] O. Reparaz, J. Balasch, and I. Verbauwhede, “Dude, is my code constant time?” in Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017. IEEE, 2017, pp. 1697–1702. [30] B. Rodrigues, F. M. Quintão Pereira, and D. F. Aranha, “Sparse representation of implicit flows with applications to side-channel detection,” in Proceedings of the 25th International Conference on Compiler Construction, 2016, pp. 110–120. [31] M. Salehi, G. De Borger, D. Hughes, and B. Crispo, “Nemesisguard: Mitigating interrupt latency side channel attacks with static binary rewriting,” Computer Networks, vol. 205, p. 108744, 2022. [32] S. Nilizadeh, Y. Noller, and C. S. Pasareanu, “Diffuzz: differential fuzzing for side-channel analysis,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 176–187.
[33] Y. Miao, M. T. Kandemir, D. Zhang, Y. Zhang, G. Tan, and D. Wu, “Hardware support for constant-time programming,” in Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture, ser. MICRO ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 856–870. [Online]. Available: https://doi.org/10.1145/3613424.3623796 [34] G. Barthe, B. Grégoire, and V. Laporte, “Secure compilation of sidechannel countermeasures: the case of cryptographic “constant-time”,” in 2018 IEEE 31st Computer Security Foundations Symposium (CSF). IEEE, 2018, pp. 328–343. [35] X. Zhou and X. Tang, “Research and implementation of rsa algorithm for encryption and decryption,” in Proceedings of 2011 6th International Forum on Strategic Technology, vol. 2, 2011, pp. 1118–1121. [36] P. Ramachandran, B. Zoph, and Q. V. Le, “Searching for activation functions,” arXiv preprint arXiv:1710.05941, 2017. [37] “Leaky relu activation function.” [Online]. Available: https://machinelearningmastery.com/rectified-linear-activationfunction-for-deep-learning-neural-networks/ [38] “Sigmoid activation function.” [Online]. Available: https://builtin.com/ machine-learning/sigmoid-activation-function [39] “Data compression using run length encoding.” [Online]. Available: https://www.sciencedirect.com/topics/computer-science/runlength-encoding [40] “Convolution layer.” [Online]. Available: https://www.sciencedirect. com/topics/engineering/convolutional-layer [41] T. ElGamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,” IEEE transactions on information theory, vol. 31, no. 4, pp. 469–472, 1985. [42] W. Diffie and M. E. Hellman, “New directions in cryptography,” in Democratizing Cryptography: The Work of Whitfield Diffie and Martin Hellman, 2022, pp. 365–390. [43] H. Feistel, “Cryptography and computer privacy,” Scientific american, vol. 228, no. 5, pp. 15–23, 1973. [44] B. Schneier, Applied cryptography: protocols, algorithms, and source code in C. john wiley & sons, 2007. [45] L. S. Hill, “Cryptography in an algebraic alphabet,” The American Mathematical Monthly, vol. 36, no. 6, pp. 306–312, 1929. [46] G. Paul and S. Maitra, RC4 stream cipher and its variants. CRC press, 2011. [47] PENDULUM, “Pendulum source code,” accessed: 2025-02-02. [Online]. Available: https://figshare.com/s/8f13e48bc98727ae8754?file=47440988 [48] “Performance counter.” [Online]. Available: https://perfwiki.github.io/ main/ [49] T. Johnson, M. Amini, and X. D. Li, “Thinlto: scalable and incremental lto,” in 2017 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 2017, pp. 111–121. [50] F. Busato, O. Green, N. Bombieri, and D. A. Bader, “Hornet: An efficient data structure for dynamic sparse graphs and matrices on gpus,” in 2018 IEEE High Performance extreme Computing Conference (HPEC). IEEE, 2018, pp. 1–7.