{"id":"4ef773f0-a56a-4889-94d0-c1945df2e6f8","arxiv_id":"2411.14878","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A review of fault injection attacks on TEEs, describing physical and software methods, triggers, and defenses, but adding no new experimental results.","lead":"This paper surveys physical and software-based fault injection attacks that can break the security of Trusted Execution Environments in phones and other devices. It compiles case studies, success rates, and recommendations, highlighting the growing accessibility of electromagnetic fault injection.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The survey's EMFI-practicality claim rests on a small, non-systematically selected case list that includes informal blog sources; without a defined search protocol, the central conclusion is not independently verifiable.","rationale":"The paper is a survey, so its contribution is the synthesis and prioritization of existing results. Its strongest claim—that EMFI and other non-invasive FI are increasingly practical and poorly mitigated—depends entirely on the case studies being representative and accurately reported. The reader's weakest-assumption analysis identified exactly this: accuracy of secondary sources and representativeness of the selected papers. I agree. The load-bearing weakness is not a mathematical or internal-logic error; it is an evidence-selection gap. Sections 3.1.3 and 3.2.6 present a handful of examples without a methodology section describing how they were chosen, and two of the examples are non-peer-reviewed blog posts. The success rates quoted from these sources are then used in the Discussion as support for broad claims about the threat landscape. Because the central claim is empirical ('growing,' 'practical,' 'harder to detect and mitigate'), the absence of a systematic collection protocol means the claim cannot be checked or reproduced. This is a conditional, fixable problem rather than a fatal flaw: a reproducible search and source-verification pass would either corroborate the selection or reveal bias. The paper has useful descriptive content, especially the recent case studies like PMFault and CacheWarp, and I do not contest the technical descriptions themselves. But the central claim overreaches the evidence as presented. The reader's CONDITIONAL verdict is appropriate; my analysis does not move it.","tokens_in":21512,"tokens_out":4213,"duration_ms":46387,"concrete_test":"Perform a reproducible literature search (DBLP, Google Scholar, IEEE Xplore, ACM DL) for 2017–2024 using query terms ('TEE' OR 'TrustZone' OR 'SGX' OR 'SEV' OR 'QSEE') AND ('fault injection' OR 'EMFI' OR 'voltage glitch' OR 'clock glitch' OR 'rowhammer'), and compare the full result set against the case studies listed in §3.1.3 and §3.2.6. In addition, independently verify the reported success rates of [Rae21] ('5%') and [Fan+23] ('83/15000') from the primary sources. If the excluded set contains comparable or stronger TEE FI demonstrations, or if the verified numbers differ materially, the Section 4 claim that EMFI is the priority threat would need to be re-scoped.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—that non-invasive FI, and EMFI in particular, is a practical and growing threat that current TEE defenses fail to mitigate—is supported in Section 3 only by a short list of 'notable papers' (§3.1.3, §3.2.6), assembled without any stated inclusion criteria. The list mixes peer-reviewed work with informal writeups ([Lim20] is a personal blog; [Rae21] is a vendor blog) and reports success rates from these sources as quantitative evidence in Section 4. Because no systematic search or quality filter is described, the paper cannot rule out that the chosen cases are outliers—either unusually successful examples or unverified reports—so the strength of the EMFI priority claim is an artifact of selection rather than an empirical finding. This is a correctness risk about the central argument: if the corpus were re-collected under a transparent protocol, the apparent prevalence of high-success EMFI attacks could change enough to alter the recommendation priorities.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript is a survey of fault injection (FI) techniques against Trusted Execution Environments (TEEs), organized into hardware-based methods (CFI, VFI, OFI, EMFI) and software-based methods (code mutation, data corruption, resource exhaustion, MSR/DVFS abuse, and cache manipulation). It compiles a set of case studies with concrete success rates, then draws conclusions about the growing practicality of non-invasive FI, particularly EMFI, and offers recommendations for countermeasures, standards, and future research.","tokens_in":21574,"tokens_out":7862,"duration_ms":74559,"significance":"If its claims stand, the paper is a useful reference for researchers and practitioners who want a compact map of physical and software FI attacks against TEEs. Its strengths include concrete success-rate data from selected primary sources, attention to low-cost tooling, and a clear enumeration of trigger mechanisms and targeted components in Sections 3.1.1-3.1.3 and 3.2.4-3.2.6. However, the case corpus is a convenience sample rather than a systematically selected and quality-filtered collection, and several conclusions about prevalence and effectiveness are stronger than the presented evidence supports.","major_comments":[{"comment":"The central claim that non-invasive FI, and EMFI in particular, is a growing, practical threat that current TEE defenses fail to mitigate is supported only by a small list of 'notable' case studies assembled without stated search or inclusion criteria. The list mixes peer-reviewed work with informal writeups ([Lim20], [Rae21]) and does not report how papers were located, screened, or quality-appraised. Because the Abstract and Sections 4-6 assert prevalence and trend ('growing accessibility and effectiveness', 'increasingly vulnerable'), the lack of a transparent corpus makes the main conclusion non-verifiable: the selected cases could be atypical high-success examples. A SoK should either add a methodology section with reproducible search and inclusion criteria, or explicitly re-frame the conclusions as observations on a convenience sample.","section":"Section 3.1.3 and Section 3.2.6; Abstract"},{"comment":"The survey uses heterogeneous success rates as comparable evidence for its threat claim without normalizing for the different experimental conditions. For instance, [Fan+23] reports 83/15000 (0.55%) successful injections for bypassing Android secure-boot authentication, while [CH17] reports 72% success in reaching a U-Boot shell; these measure different goals, use different triggers, target different SoCs, and define 'success' differently. The paper does not analyze these dimensions before concluding in Section 4 that EMFI/VFI are increasingly effective. The success-rate data should be tabulated with target, fault type, trigger, and success definition, or the trend conclusion should be weakened.","section":"Section 3.1.3, Section 3.2.6, Section 4"},{"comment":"The recommendations section presents measures such as dynamic anomaly detection, EMI shielding, and mandatory FI testing as direct implications of the survey, but the surveyed case studies are not used to evaluate whether these countermeasures would have prevented any of the described attacks, and no countermeasure literature is systematically reviewed. These are plausible directions, but as written they are generic advice rather than conclusions derived from the corpus. They should be either supported with references to existing countermeasure work or explicitly labeled as open research directions.","section":"Sections 5-6"},{"comment":"The paper's stated scope is 'mobile devices', but the case-study set includes a server CPU (PMFault, [CO23]), Intel desktop CPUs (SGX-bomb, [Jan+17]), a Cisco IP phone ([CH17]), and a Qualcomm network-processor SoC ([Rae21]). The abstract also includes cloud platforms. The manuscript should define the intended target population and the inclusion criteria for case studies; otherwise the reader cannot determine which conclusions are meant to apply to mobile TEEs and which to other platforms.","section":"Title, Section 1, Sections 3.1.3 and 3.2.6"}],"minor_comments":[{"comment":"The citation [Haq+20] for the definition of secure boot functions is incorrect: the cited paper is about semantic similarity metrics for source-code summarization, not secure boot. This reference should be replaced with a source that actually discusses secure boot.","section":"Section 3.1.2"},{"comment":"The paragraph labeled 'Non-Invasive Fault Injection Attacks' appears to summarize another survey or assessment, but no citation is given. In a systemisation of knowledge, every summarized work must be identifiable; add the citation or clearly identify this as the authors' own framework.","section":"Section 2.6"},{"comment":"The related-work heading cites '[Mun+2]', which should be '[Mun+23]' to match the bibliography entry [Mun+23].","section":"Section 2.5.1"},{"comment":"There are two small accuracy issues in the CLKSCREW case study: 'instruction skilling' should be 'instruction skipping', and the PMFault entry says 'BCM IC' where the context indicates 'BMC' (Baseboard Management Controller).","section":"Section 3.2.6"},{"comment":"The CacheWarp case study describes the attack as 'resource exhaustion of the AMD SEV's Cache function'; this is imprecise relative to the source paper's description of the attack mechanism. Please align the summary with [Zha+24].","section":"Section 3.2.6"}],"recommendation":"major_revision","confidential_remarks":"The paper overlaps substantially with existing surveys [BH22], [She+22], and [Mun+23]; its value added is the TEE-focused, combined physical-and-software FI compilation, but the current framing does not clearly differentiate it from those works. The methodology gap is the main obstacle: if the authors cannot provide a systematic corpus, the paper should be repositioned as a narrative review and its claims scaled down accordingly. I would also ask the authors to check all secondary citations, especially [Haq+20] and the uncited summary in Section 2.6, before any acceptance decision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my read. This is a usable narrative review, not a systematic SoK. The useful part is the case-study compilation: BADFET's 72% secure-boot bypass, Fanjas's 0.55% EMFI success rate, PMFault's 26% RSA key recovery, CacheWarp's near-100% session hijack. Those numbers look faithful to the primary sources, and someone looking for a quick update on the FI-against-TEE landscape will get value from it. The background history and the related-work differentiation in Section 2.5 are fine.\n\nBut the paper overclaims its own rigor. The title says 'Systemisation of Knowledge,' yet there is no search protocol, no inclusion/exclusion criteria, and Sections 3.1.3 and 3.2.6 are just 'notable papers' picked by the authors. The case list mixes peer-reviewed work with a personal blog and a vendor writeup. That is a real flaw for a SoK, and it means the quantitative support for the EMFI-practicality claim is not independently auditable.\n\nThat said, I think the stress-test concern overstates the risk. The central conclusion—non-invasive FI, EMFI in particular, is a practical and growing threat—does not depend on the blog entries. BADFET, Fanjas, CLKSCREW, PMFault, and CacheWarp are peer-reviewed and carry the point. Dropping the informal sources would weaken the evidence base but not flip the conclusion.\n\nThe other problems are editing and scholarly hygiene, but they matter. [Haq+20] is cited for secure-boot functions, but the reference is a paper on source-code summarization—that's just wrong. Section 2.6 summarizes a survey with no citation at all. There is a placeholder DOI in the reference list. And the final sections (4-8) are generic recommendations that repeat the same ideas. Typos like 'Coretex' and 'instruction skilling' should have been caught.\n\nOn balance: worth sending to a serious referee? Yes. The topic is important, the attack descriptions are mostly sound, and a major revision that adds a stated methodology, fixes citations, and trims the boilerplate would make it a legitimate SoK. As it stands, treat it as a useful narrative review with a misleading title, not the definitive systematisation.","headline":"A serviceable narrative review of FI against TEEs with useful case-study numbers; not a systematic SoK, but the core EMFI claim survives the weak methodology once you look at the peer-reviewed sources.","tokens_in":22228,"tokens_out":2814,"would_cite":false,"duration_ms":27885,"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":"This survey argues that non-invasive fault injection, especially electromagnetic fault injection, is a growing and practical threat to Trusted Execution Environments that current architectures are not designed to stop.","keywords":["fault injection","trusted execution environment","EMFI","hardware fault injection","software fault injection","secure boot bypass","TEE security","side-channel trigger"],"falsifier":"A controlled replication study that took several current phones and IoT boards, repeated the cited EMFI, VFI, and software-based attacks under standard lab conditions, and measured bypass rates would settle the claim. If a dozen common TEE models showed near-zero successful bypasses with the same low-cost equipment, the paper's core threat assessment would collapse.","tokens_in":21199,"feed_emoji":"⚡","tokens_out":5203,"duration_ms":48008,"temperature":0.7,"pith_summary":"This paper is a systematisation of what is known about fault injection against Trusted Execution Environments, the isolated processor zones that guard secure boot, keys, and payments on most phones. It tries to establish that the threat is dominated by non-invasive methods, above all electromagnetic fault injection, because they leave no physical trace, do not require opening the chip, and are harder to detect than older invasive attacks. If the paper's reading of the case studies is right, current TEE architectures are not designed for this class of attacker, and defences should shift toward real-time anomaly detection, electromagnetic shielding, and mandatory fault-injection testing before devices ship. A fair reader would take away that the security promise of TEEs is narrower than it appears, and that the bypasses are documented with concrete success rates rather than hypotheticals.","feed_headline":"Non-invasive fault injection is a practical, growing threat to TEEs","feed_subtitle":"Survey of real attacks: electromagnetic glitching and software faults routinely bypass trusted execution environments.","key_machinery":"The organising machinery is a two-dimensional classification: FI methods are split into hardware (clock, voltage, optical, electromagnetic) and software (code mutation, data corruption, resource exhaustion), and each attack is described by its trigger (side-channel leakage, timing, events, or environment manipulation) and the TEE component it targets (secure boot, cryptographic functions, restricted shell access, device functionality). This classification is what lets the paper aggregate heterogeneous case studies into a single threat assessment; the case-study collection is the load-bearing part of the argument, because each success rate is evidence for a particular attack's practicality.","core_discovery":"The central claim is that Trusted Execution Environments are increasingly vulnerable to fault injection attacks, and that the most worrying attacks are non-invasive: electromagnetic fault injection and voltage fault injection require no physical modification of the hardware and no contact with the die, so they can be mounted with low-cost, DIY equipment against real devices. The paper supports this with a structured survey of hardware fault injection (clock, voltage, optical, electromagnetic) and software fault injection (code mutation, data corruption, resource exhaustion), including documented case studies where secure boot checks, range checks, and cryptographic operations in TEEs were bypassed with success rates between 0.55% and 99%. It concludes that current TEE architectures lack adequate countermeasures, and that manufacturers and standards bodies should respond with dynamic anomaly detection, hardened designs, and mandatory fault-injection testing.","pith_inferences":["If the success rates here are representative, the practical difference between 'hardware' and 'software' fault injection is blurring: several cited attacks are software-triggered glitches, so remote attackers might reproduce physical FI effects without ever touching the device.","The wide spread of reported success rates, from 0.55% to 99%, suggests the field would benefit from a standard reporting metric, such as number of injection attempts per successful security bypass, before countermeasure priorities can be compared across devices.","One testable extension is a public benchmark that replays the five or six cited attacks on current-generation devices to see whether hardening efforts have already changed the outcomes.","Another extension is to treat the trigger-mechanism taxonomy as a design checklist: if a chip's power-management or clock interface is reachable from normal software, that is a fault-injection vulnerability even when no physical probe is used."],"forward_implications":["If non-invasive FI is as practical as the case studies suggest, secure boot on ARM TrustZone, QSEE, and similar TEEs should be assumed bypassable by an attacker with inexpensive DIY equipment and a timing side channel.","Fault injection should be treated as a standard item in TEE threat models, alongside software exploits, rather than as an exotic physical attack that only well-funded laboratories can mount.","Countermeasures that detect anomalies at runtime, such as monitoring voltage, clock, and electromagnetic environment, become a necessary complement to static isolation and cryptographic attestation.","Standards bodies and manufacturers would need to mandate fault-injection testing during design and production, because post-deployment patching does not fix a hardware behaviour that allows a glitch to skip an integrity check.","Hybrid software-hardware attacks, such as CLKSCREW and PMFault, show that software bugs in power-management interfaces can turn a remote attacker into a fault-injection attacker, expanding the attack surface beyond physical proximity."],"supporting_citations":[{"why":"Documents a two-dollar DIY voltage glitching board bypassing ARM TrustZone on a Nuvoton M2351, used as evidence that VFI is low-cost and practical.","marker":"[Lim20]"},{"why":"BADFET case study in which a DIY EMFI probe on a 3D-printer gantry bypassed secure boot on a Broadcom chip in 72 of 100 glitch attempts, the core evidence that EMFI is accessible.","marker":"[CH17]"},{"why":"Demonstrates EMFI plus real-time side-channel triggering bypassing Android secure boot with a success rate of 0.55%, evidence that non-invasive FI works in black-box or grey-box settings.","marker":"[Fan+23]"},{"why":"Shows EMFI bypassing range checks in Qualcomm QSEE on the IPQ40xx, cited as evidence that commercial phone TEEs are vulnerable.","marker":"[Rae21]"},{"why":"CLKSCREW hybrid software-hardware attack against ARM DVFS on a Nexus 6, used to show that software-triggered voltage and clock manipulation can inject faults into a TEE.","marker":"[TSS17]"},{"why":"PMFault attack under-volting an Intel SGX core through a management controller, with 66 of 253 tests recovering RSA private keys, evidence for software and management-interface FI.","marker":"[CO23]"},{"why":"CacheWarp cache-based FI against AMD SEV with high success rates for key recovery and privilege escalation, evidence for pure software FI against TEE virtual machines.","marker":"[Zha+24]"},{"why":"SGX-bomb row hammer denial-of-service against Intel SGX, evidence for software-only fault-induced availability impact.","marker":"[Jan+17]"}],"fun_headline_variants":["EMFI and software glitches: the real TEE bypass toolkit","Fault injection is now a practical threat to mobile TEEs","Non-invasive glitching exposes TEE weaknesses","Survey: fault injection attacks routinely defeat TEEs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The conclusions rest on the accuracy and representativeness of the published and informal case studies summarised in Sections 3.1.3 and 3.2.6; if those reports overstate success rates or skew toward the most spectacular attacks, the claim that non-invasive FI is a severe and growing threat loses its footing.","fun_headline_variants_meta":{"raw":{"variants":["EMFI and software glitches: the real TEE bypass toolkit","Fault injection is now a practical threat to mobile TEEs","Non-invasive glitching exposes TEE weaknesses","Survey: fault injection attacks routinely defeat TEEs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000576,"raw_usage":{"total_tokens":2724,"prompt_tokens":957,"completion_tokens":1767,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":573,"completion_tokens_details":{"reasoning_tokens":1712}},"tokens_in":573,"tokens_out":1767,"duration_ms":13178,"temperature":1.0,"reasoning_tokens":1712,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T14:45:31.349818+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A controlled replication study that took several current phones and IoT boards, repeated the cited EMFI, VFI, and software-based attacks under standard lab conditions, and measured bypass rates would settle the claim. If a dozen common TEE models showed near-zero successful bypasses with the same low-cost equipment, the paper's core threat assessment would collapse.","supporting_citations":[],"review_version":1}