{"id":"2ed45a33-6343-41b8-a7c8-7e85bcd73c91","arxiv_id":"2507.22306","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"A sleep-induced context-switch power spike, whose amplitude leaks the previous program's register values and residual power, is used to recover cryptographic keys from AES and SIKE.","lead":"This paper introduces a physical power side-channel that reads a single power spike produced when an operating system sleeps between tasks, and uses its amplitude to infer what a program did before sleeping. The authors report partial key recovery for AES and full key recovery for SIKE on a Raspberry Pi 4, but the attack methodology has serious untested assumptions.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"AES plaintext generator is circular: Algorithm 2 (Section VI) calls Decrypt(C), which requires the full target AES key, yet the attack is described as chosen-plaintext; without an unstated decryption oracle, the key-recovery attack cannot start.","rationale":"Good-faith reading: the paper's contribution is a new leakage source (sleep-induced context-switch spike) plus a power model and two attacks. The physical observation—a distinct spike depending on register HWT, processed-data HWT/HD, and instruction count—is supported by controlled experiments (Figures 10, 12, 14, 15). I do not dispute that. The problem is the inference from this leakage to key recovery. Section VI's Algorithm 2 is the entire bridge from chosen plaintexts to a detectable HWT-0 event in the final AES round, and that bridge is built on Decrypt(C). Under the stated chosen-plaintext model, the attacker cannot execute Decrypt without the secret key; with a decryption oracle, the model is strictly stronger and unstated. Either way, the strongest AES claim is not supported. I also considered the SIKE SEP_LIMIT concern: missing success statistics and a locally tuned threshold are serious, but a threshold can in principle be validated with experiments; the AES circularity is categorically more damaging. Therefore the reader's REJECT verdict should stand; no change is needed.","tokens_in":18299,"tokens_out":11686,"duration_ms":145527,"concrete_test":"Modify the AES PoC in the released repository so that Decrypt(C) at Algorithm 2 line 7 is replaced by a stub that raises 'key unavailable' whenever the full AES key schedule is not present. Run the Level 3 recovery on a fixed random key. If the attack still recovers key bytes, the concern is refuted; if it cannot generate plaintexts, the attack depends on key knowledge at line 7. Analytical cross-check: for a chosen C with C[T]=k, express the resulting plaintext P as AES^{-1}_K(C) and verify that all 16 plaintext bytes depend on the full key schedule, not just byte k.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section VI rests on Algorithm 2. Its line 7 computes P ← Decrypt(C) after setting C[T] to the guessed key-byte k. AES decryption of a full 128-bit ciphertext requires the complete key schedule, not a single final-round key byte. In the stated chosen-plaintext threat model, the attacker does not possess that schedule; if Decrypt is instead intended as a black-box decryption oracle, the paper never says so and the attack is no longer chosen-plaintext. This is an internal inconsistency, not a tuning or statistics problem: without Algorithm 2, the special plaintexts that force a 0x00 final-round S-box output cannot be generated, so Levels 1-3 of the AES attack cannot commence. The controlled experiments in Section IV (HWT/HD correlations with a power spike) are plausible and are not what I am questioning; the load-bearing unsupported step is the translation from those correlations to end-to-end AES key recovery.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces SleepWalk, a physical power side-channel based on the power spike observed when the Linux sleep() call triggers a context switch on a Raspberry Pi 4 (BCM2711). The authors report that the spike amplitude correlates with the Hamming weight of register contents and with residual power from previously executed instructions, and they develop a qualitative power-thermal model. They then present two end-to-end attacks: full secret-key recovery from the CIRCL SIKE decapsulation, exploiting zero-value states in the Montgomery ladder, and partial (10 out of 16 bytes) final-round key recovery from AES-128 using chosen plaintexts. The claimed advantages are that only a single power-spike amplitude is needed, eliminating trace alignment, external triggers, and complex preprocessing.","tokens_in":18507,"tokens_out":10603,"duration_ms":122086,"significance":"If the end-to-end claims were valid, SleepWalk would be a noteworthy simplification of physical power analysis: a single peak-amplitude measurement could leak both current register state and past computational activity, and the AES result would lower key-search complexity to 2^48. The controlled experiments in Section IV, showing monotone relationships between spike amplitude and register HWT, processed-data HWT/HD, and instruction count, are a plausible empirical contribution, and the anonymous code release and disclosure to Broadcom/ARM are positive practices. However, the AES attack's plaintext generator (Algorithm 2) requires the secret key or an unstated decryption oracle, making the reported key recovery circular in the stated chosen-plaintext model. The SIKE attack's threshold and success claims are also under-supported. As a result, the paper's central security claims are not established.","major_comments":[{"comment":"The instruction `P <- Decrypt(C)` is load-bearing and circular. In AES, decrypting a 128-bit ciphertext requires the full key schedule; setting a single ciphertext byte `C[T]` to a guessed key byte `k` does not make decryption possible without the secret key. An attacker in the stated chosen-plaintext threat model does not possess that key, and the paper does not state that a decryption oracle is available. If `Decrypt` is instead meant to be called with the victim's key, then the plaintexts that force a 0x00 final-round S-box output are generated using the very key the attack is supposed to recover. Levels 1-3 of the AES attack (Sections VI-A through VI-C) all depend on Algorithm 2, so the reported recovery of 10 key bytes is either circular or rests on an unstated, much stronger assumption.","section":"Section VI, Algorithm 2"},{"comment":"The key-recovery procedure hinges on `SEP_LIMIT`, which is \"set by conducting multiple local experiments\" rather than derived from the leakage model, and on the assumption that the mean peak power for anomalous-zero cases is always lower. The paper reports that the full SIKE key was recovered but gives no success rate, no number of independent trials, no error bars or confidence intervals for the means, and Figure 17 shows only the first ten key bits. The number of decapsulation iterations before sleep (four) is also a free parameter with no sensitivity analysis. These omissions make the full-key recovery claim impossible to verify.","section":"Section V-B, Algorithm 1 and Figures 16-17"},{"comment":"The claimed \"single power-spike\" / \"single sampling point\" advantage is not supported by the reported methodology. Every data point in Section IV is the average of 1,000 measured spikes, Section VI-A uses 10,000 traces per plaintext, and Section III-A applies a running-average window of 10 before peak extraction. The end-to-end attacks therefore depend on averaged and smoothed peak amplitudes, not on a single raw sampling point. The paper should either substantiate the single-point claim with single-trace results or soften the claim.","section":"Sections IV-A and VI-A"},{"comment":"The claim of recovering 10 out of 16 final-round key bytes is not accompanied by per-byte results for all positions, a success criterion, or an analysis of the failures. Figure 20 reports only bytes 15, 13, 3, and 1. Without knowing which bytes fail and why, the stated reduction from 2^128 to 2^48 cannot be assessed, and the reader cannot tell whether the attack is stable across keys.","section":"Section VI-C"}],"minor_comments":[{"comment":"The code uses the mnemonic `RSL` for a right shift; the ARM Cortex-A72 ISA has `LSR`, not `RSL`. Please correct or explain the macro.","section":"Figure 13"},{"comment":"The text says HD = 4 x SHIFT_VALUE, while the Figure 14 caption says \"the HD is always constant (4 x shift amount)\"; these statements should be reconciled.","section":"Section IV-D"},{"comment":"\"GNU/Linux 12 Debian (Bookworm)\" should read \"Debian GNU/Linux 12 (Bookworm)\".","section":"Section III-A"},{"comment":"The pseudocode overloads `C` for the ciphertext array and `T` for the target byte while `k` is both the loop variable and the key-byte guess; the notation is confusing and should be clarified.","section":"Algorithm 2"},{"comment":"The function `generate_ciphertext(K, t)` is never specified; since the zero-value ciphertext construction is central to the attack, the paper should provide pseudocode or a precise pointer to the construction in [44].","section":"Section V-B"},{"comment":"The Cold and Hot tasks differ in both shift amount/HWT and instruction count, so the instruction-count effect is not cleanly isolated.","section":"Section IV-E"},{"comment":"The claim that the spike is caused by the context switch rather than by syscall entry/exit or clock events is supported only by a call trace; an ablation that removes schedule() would strengthen the causal claim.","section":"Section III-B"}],"recommendation":"reject","confidential_remarks":"The AES circularity is not a presentation issue; it invalidates the central attack. The SIKE attack could potentially be repaired with more statistics and a principled threshold, but the AES contribution would require a fundamentally different construction or an explicitly stated oracle model. I see no path to acceptance without substantially new experimental work. The Section IV correlation study might be worth publishing separately."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First thing you should know: the controlled experiments in Section IV are the real content. The claim that a single power spike, induced by a sleep-triggered context switch, correlates with register Hamming weight, processed-data Hamming weight/distance, and instruction count is plausibly demonstrated and, as far as I know, not in the cited literature. The residual power signature is a genuinely interesting observation. So there is a salvageable core.\n\nBut the end-to-end attacks do not hold up as written. The AES attack is circular: Algorithm 2 generates chosen plaintexts by computing P <- Decrypt(C) after setting C[T] = k. AES decryption of a full 128-bit ciphertext needs the complete key schedule, which the attacker does not have in a chosen-plaintext attack. Unless the paper states an unstated decryption oracle, the plaintext generator cannot be built. This is not a tuning problem; it is the load-bearing step and it is missing. The SIKE attack has a different soft spot: the threshold SEP_LIMIT is fitted by local experiments, and the paper reports no success rate or error bars around the key-bit decisions. Figure 17b shows overlapping distributions without confidence intervals; claiming full key recovery from that is under-supported.\n\nThe power model is qualitative, which is acceptable as a model, but it is not a derivation. The SIKE Level 1 proof-of-concept is fine as a demonstration, though it modifies the implementation. The Level 2 attack is the realistic one and it needs proper statistical treatment.\n\nOn the positive side, the paper ships code and describes the setup in enough detail to reproduce the physical experiments. That is genuine credit.\n\nWho is this for? Side-channel researchers who care about single-point leakage sources and power-thermal history effects. It deserves a serious referee, not a desk reject, because the core observation could be real and significant. But the current version should be major-revision: correct or explain the AES oracle, add statistical validation for SIKE bit recovery (success rate over multiple keys, per-bit error bars), and soften the claims.\n\nI would not cite it in the next year myself, but I'd read the revised version.","headline":"The sleep-spike leak observation is plausible and novel, but the AES attack is circular as written and the SIKE attack lacks statistics, so the paper overreaches.","tokens_in":19052,"tokens_out":2373,"would_cite":false,"duration_ms":26484,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A sleep call's power spike leaks cryptographic keys, the paper argues, by encoding both register state and residual power from prior computation.","keywords":["sleep-induced power spike","context switch side channel","residual power signature","Hamming weight power model","single-point power analysis","SIKE key recovery","AES-128 key recovery","BCM2711"],"falsifier":"Run the same SIKE and AES key-recovery procedure on a second, unmodified BCM2711 board at a different ambient temperature without re-tuning the SEP_LIMIT threshold; if the separation between the anomalous-zero and normal cases reverses or vanishes, the claimed single-spike monotonicity fails. Separately, attempt to run Algorithm 2 without access to the AES key schedule; since Decrypt(C) requires the full round key, the chosen-plaintext key-recovery attack cannot even begin for an attacker who lacks the key.","tokens_in":18047,"feed_emoji":"⚡","tokens_out":5102,"duration_ms":58726,"temperature":0.7,"pith_summary":"SleepWalk is a physical power side-channel that reads a single power spike at the moment the OS sleep function triggers a context switch, and shows that the spike's amplitude encodes both the power cost of saving and restoring registers and the residual power left over from the program that just ran. The paper demonstrates that this one sampling point, without trace alignment, external triggers, or preprocessing, is enough to recover the full secret key from SIKE decapsulation and ten of sixteen final-round bytes from AES-128 on the BCM2711. The authors build a power model relating the spike to Hamming weight of register data, Hamming weight and Hamming distance of processed data, and the number of executed instructions, via a power-temperature feedback loop. If true, this reduces the cost of a physical attack to measuring one voltage value after a sleep call, and extends the leak beyond live register contents to the history of prior computation.","feed_headline":"A sleep call's power spike leaks crypto keys","feed_subtitle":"One sampling point recovers a full SIKE key and ten of sixteen AES-128 key bytes on a Raspberry Pi.","key_machinery":"The central object is the sleep-induced power spike, a single high-amplitude sampling point at the onset of a context switch triggered by the kernel's built-in sleep function (the call chain runs through nanosleep to schedule). The spike's amplitude is modeled as $P_{total} = P_{dyn} + P_{leak} + P_{sc}$, with dynamic power responding to Hamming weight and Hamming distance and leakage power growing with temperature; the thermal model $C_{th} \\, dT/dt = P_{total} - (T - T_{amb})/R_{th}$ turns a burst of instruction activity into an elevated die temperature, so the residual signature of past work survives into the spike. This single-point amplitude is the mechanism that removes trace alignment, external triggers, and high-dimensional feature extraction, and it is what both the SIKE threshold classification and the AES byte-level Hamming-weight comparison exploit.","core_discovery":"On a stock Raspberry Pi 4 with the Linux kernel's sleep function, the paper discovers that the power spike produced when the kernel enters a context switch contains two superimposed signals: the switching activity of saving and restoring registers (captured by the Hamming weight of register values present at that moment) and the residual power signature of instructions executed before the switch, which persists through elevated die temperature and leakage current. Because the spike is present and prominent for sleep, usleep, and nanosleep, and because its peak amplitude is the only measurement needed, the authors use it for key recovery: with specially crafted SIKE ciphertexts that force zero-valued intermediates in the Montgomery ladder, the spike amplitude cleanly separates cases where the key bit flips from cases where it does not, yielding the full SIKE key with a threshold-based bit-by-bit algorithm; and with 150,000 AES encryptions before each sleep call, the amplitude distinguishes byte-level Hamming weights in the final S-box output, recovering 10 of 16 AES-128 final round key bytes and lowering brute-force complexity from $2^{128}$ to $2^{48}$.","pith_inferences":["If the spike amplitude's reliance on residual thermal history is as strong as the model suggests, the calibration (the SEP_LIMIT threshold) should be temperature-dependent: a fixed threshold may fail in a cooler or warmer room, which can be tested by repeating the SIKE attack at different ambient temperatures.","The AES plaintext generator assumes the attacker can decrypt chosen ciphertexts under the victim key, which is only possible if the attacker already possesses the key schedule or can query the victim as a decryption oracle; a purely black-box chosen-plaintext attacker cannot run Algorithm 2 as written.","The same single-point leakage could plausibly recover other secret-dependent data that ends in registers or in a sustained computation right before a sleep, such as DNN layer outputs or memory addresses, not just cryptographic keys.","On other CPUs or kernels, the size and stability of the context-switch spike may differ; if the spike is small or masked by frequency scaling, the method's single-sample advantage would shrink, so cross-platform transfer is an open question."],"forward_implications":["An attacker with only a single power sample, taken after a sleep call, can distinguish which of several workloads ran before the sleep, including workloads that differ only in operand size.","The SIKE key-recovery procedure extracts the full secret key bit by bit even when the sleep call is placed only after the entire decapsulation, using residual power amplified by four decapsulation runs.","AES final-round key bytes are recoverable at byte granularity: ten of sixteen bytes are found, cutting exhaustive search from $2^{128}$ to $2^{48}$.","Because usleep, nanosleep, and other user-accessible system calls produce the same spike, the channel generalizes to any kernel context-switch trigger the attacker can invoke.","No external synchronization is needed because the spike is self-identifying and consistent, so trace collection reduces to peak-finding on a running average."],"supporting_citations":[{"why":"EvilCS establishes context-switch information leakage as a security assessment target, motivating the attack surface SleepWalk exploits.","marker":"[3]"},{"why":"Differential power analysis is the baseline trace-intensive attack that SleepWalk contrasts against in requiring only one point.","marker":"[4]"},{"why":"CIRCL is the unmodified SIKE implementation used as the victim in the full key-recovery attack.","marker":"[6]"},{"why":"Correlation power analysis supplies the Hamming-distance leakage model used in the SleepWalk power model.","marker":"[15]"},{"why":"Hertzbleed shows power side-channel key extraction on x86 and provides background for the zero-value SIKE behavior SleepWalk targets.","marker":"[24]"},{"why":"The thermal modeling reference underpins the power-temperature feedback loop that produces the residual power signature.","marker":"[39]"},{"why":"The Cortex-A72 optimization guide explains the shift-pipeline behavior used to design the Hamming-distance isolation experiment.","marker":"[42]"},{"why":"The zero-value side-channel attacks on SIKE provide the crafted ciphertext construction that the SleepWalk SIKE attack relies on.","marker":"[44]"}],"fun_headline_variants":["Sleep-induced power spike leaks crypto keys","One power spike from sleep recovers keys","Sleep call power spike enables key theft","Residual power in sleep spike reveals secrets","Amplitude of sleep spike yields AES/SIKE keys"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole attack treats the average amplitude of the sleep-spike as a stable, monotone measure of register Hamming weight plus residual power and thermal history, and assumes this mapping and the locally tuned SEP_LIMIT threshold transfer across key bits and ciphertexts; if the mapping drifts with temperature, board, or program, the bit classification collapses.","fun_headline_variants_meta":{"raw":{"variants":["Sleep-induced power spike leaks crypto keys","One power spike from sleep recovers keys","Sleep call power spike enables key theft","Residual power in sleep spike reveals secrets","Amplitude of sleep spike yields AES/SIKE keys"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00021,"raw_usage":{"total_tokens":1428,"prompt_tokens":980,"completion_tokens":448,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":596,"completion_tokens_details":{"reasoning_tokens":380}},"tokens_in":596,"tokens_out":448,"duration_ms":4754,"temperature":1.0,"reasoning_tokens":380,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T11:52:11.674214+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same SIKE and AES key-recovery procedure on a second, unmodified BCM2711 board at a different ambient temperature without re-tuning the SEP_LIMIT threshold; if the separation between the anomalous-zero and normal cases reverses or vanishes, the claimed single-spike monotonicity fails. Separately, attempt to run Algorithm 2 without access to the AES key schedule; since Decrypt(C) requires the full round key, the chosen-plaintext key-recovery attack cannot even begin for an attacker who lacks the key.","supporting_citations":[{"cited_title":"Evilcs: An evaluation of information leakage through context switching on security enclaves,","cited_arxiv_id":null,"evidence_quote":"EvilCS establishes context-switch information leakage as a security assessment target, motivating the attack surface SleepWalk exploits."},{"cited_title":"Differential power analysis,","cited_arxiv_id":null,"evidence_quote":"Differential power analysis is the baseline trace-intensive attack that SleepWalk contrasts against in requiring only one point."},{"cited_title":"Faz-Hernandez and K","cited_arxiv_id":null,"evidence_quote":"CIRCL is the unmodified SIKE implementation used as the victim in the full key-recovery attack."},{"cited_title":"Correlation power analysis with a leakage model,","cited_arxiv_id":null,"evidence_quote":"Correlation power analysis supplies the Hamming-distance leakage model used in the SleepWalk power model."},{"cited_title":"Hertzbleed: Turning power {Side-Channel} attacks into remote timing attacks on x86,","cited_arxiv_id":null,"evidence_quote":"Hertzbleed shows power side-channel key extraction on x86 and provides background for the zero-value SIKE behavior SleepWalk targets."},{"cited_title":"Thermal modeling, analysis, and manage- ment in vlsi circuits: Principles and methods,","cited_arxiv_id":null,"evidence_quote":"The thermal modeling reference underpins the power-temperature feedback loop that produces the residual power signature."},{"cited_title":"Cortex-a72 software optimization guide,","cited_arxiv_id":null,"evidence_quote":"The Cortex-A72 optimization guide explains the shift-pipeline behavior used to design the Hamming-distance isolation experiment."},{"cited_title":"Sike channels: Zero-value side-channel attacks on sike,","cited_arxiv_id":null,"evidence_quote":"The zero-value side-channel attacks on SIKE provide the crafted ciphertext construction that the SleepWalk SIKE attack relies on."}],"review_version":1}