{"id":"44039ed8-5cf5-4967-8121-068171a43138","arxiv_id":"2502.01240","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Logic locking can add hidden data paths that leak cryptographic key bits to chip outputs when an attacker applies an incorrect logic-locking key.","lead":"Logic locking is supposed to protect chips in untrusted factories, but this paper shows it can accidentally leak secret encryption keys at runtime. The authors test five cryptographic designs and find that a wrong logic-locking key can expose over 70% of an encryption key through newly created signal paths.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Stuck-at ATPG 'detected' may only prove scan-based observability, not runtime leakage of registered key bits; the 73.83% claim needs a functional-mode check.","rationale":"I agree with the reader's weakest assumption: the DT-to-exploit step is the load-bearing point. My analysis adds precision: for registered secret bits, a stuck-at detection requires fault excitation (driving L to 0/1), and the SET-LL-KEY attacker cannot force the encryption key. This is not solved by the paper's constraint of non-adversarial inputs to X, because the secret flip-flops are internal state, not primary inputs. Unless TestMAX's generated patterns are simulated functionally, the 'can leak' claim is an overreading of combinational ATPG. The ND population and lack of artifacts are real but secondary; the scan/functional-mode ambiguity is decisive. Since the reader's conditional verdict already flags the same step, I recommend no change to the verdict. A single targeted rerun of the flag-bearing case would settle it.","tokens_in":11187,"tokens_out":8767,"duration_ms":88556,"concrete_test":"Focus on the strongest claimed result: EPIC with 25% relative key size on the XTEA benchmark, SET-LL-KEY scenario. Reproduce the Section IV-B ATPG run with TestMAX and export the generated test patterns for all DT bits. Inspect the pattern file (WGL/STIL) for scan-chain shift operations or forced initialization of the encryption-key flip-flops. Then simulate the exact locked netlist in functional mode: load a random 128-bit encryption key via the normal key port, reset the design, and apply only the LL-key-input vectors at the system clock rate, observing primary outputs at the appropriate cycle; check whether any primary output's value is a deterministic function of a given key bit.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that logic locking creates new combinational paths that a runtime attacker can use to read encryption key bits by setting only the logic-locking key inputs. This is supported by labeling ATPG 'detected' (DT) tests as leakages. The load-bearing assumption is that a DT result for a secret bit is a valid oracle for the actual value of that bit under the stated attacker model. The secret signals are not combinational primary inputs; they are outputs of flip-flops in sequential cryptographic cores (e.g., the AES/DES/XTEA key registers). A stuck-at test on a register output line L requires driving L to a known value to excite the fault and then propagating the faulty value to an observable output. In the SET-LL-KEY scenario, only the logic-locking key inputs are controllable; the encryption key input is constrained to X and the victim's key is already loaded. Thus, a pattern that forces L=1 or L=0 cannot be applied by an attacker who cannot write the secret key. If TestMAX operated in full-scan or used test-mode initialization, the DT patterns may rely on scan-chain access that the runtime adversary in Section II-C does not have. Section IV-B does not specify the ATPG mode or whether any test pattern was simulated in functional mode, so this ambiguity is unresolved. If the DT-to-exploit step fails, the headline result (EPIC: up to 73.83% of the key 'compromised solely by modifying the logic locking key') is materially weakened, and the paper would only demonstrate combinational reachability, not confidentiality loss.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an automated ATPG-based methodology to test whether logic locking inadvertently creates combinational paths that enable an adversary to read encryption key bits or other sensitive data from the primary outputs of a circuit. Three logic locking mechanisms (ASSURE, EPIC, D-MUX) are applied to five open-source cryptographic benchmarks, with secret bits labeled and analyzed under two attacker scenarios: one where the attacker controls all inputs except the secret bits (SET-ALL) and one where the attacker controls only the logic locking key inputs (SET-LL-KEY). The main quantitative claims are that EPIC can expose up to 73.83% of an encryption key under SET-LL-KEY, D-MUX up to 25%, and ASSURE shows no LL-key-only leakage, while all original un-locked benchmarks are reported as leak-free.","tokens_in":11459,"tokens_out":4092,"duration_ms":44278,"significance":"If the central claim is correct, the paper opens a genuinely new direction in logic locking evaluation: instead of focusing on key recovery and IP piracy, the field would need to consider confidentiality violations introduced by locking itself. The paper has clear strengths: it uses open benchmarks, generates 1,000 locked netlists per EPIC and D-MUX configuration, reports a full leakage distribution per secret bit, and provides an explicit baseline showing no leakages in the unlocked circuits. The methodology is automated and the headline result is falsifiable. However, the entire interpretation rests on the assumption that an ATPG 'hard detected' fault on a secret bit is equivalent to a runtime attacker being able to read that bit through the stated attack model. That equivalence is not established, and the paper does not validate the detected patterns in functional simulation. The ND population is also sizable but explicitly treated as a lower bound, which is honest; the unresolved issue is whether even the DT population is actually exploitable.","major_comments":[{"comment":"The core load-bearing step is the translation from ATPG 'detected' (DT) to a real confidentiality leak under the attack model in Section II-C. The secret bits in the cryptographic benchmarks are not all combinational primary inputs; many are outputs of flip-flops inside the encryption engine. A stuck-at ATPG tool such as TestMAX, when run in a scan-based mode, can declare a fault on such a signal as 'hard detected' by shifting test stimuli through scan chains and observing responses through scan output. The runtime adversary in Section II-C cannot write the secret key, cannot shift scan chains, and can only change the logic locking key inputs. The paper does not state whether TestMAX was run in full-scan, whether scan chains are assumed, or whether any generated test pattern was simulated in functional mode. Consequently, the claim that a DT label means 'the confidential bit can be transferred to an output' is not established for the SET-LL-KEY scenario. I ask the authors to either (a) run the generated patterns in gate-level functional simulation with only the LL key inputs toggled, showing that the output indeed reveals the key bit value, or (b) constrain the ATPG so that only primary inputs are used and scan cells are not controllable, and report the resulting detection rates.","section":"Section IV-B, steps 3-5"},{"comment":"The methodology lists 'Evaluate the vulnerabilities manually for each leakage' as step 5, but no manual evaluation or case study of an actual detected leak is presented anywhere in Section V. Given that the entire paper hinges on DT tests being exploitable, at least one concrete worked example is needed: for a specific benchmark, a specific locked netlist, and a specific secret bit, the authors should show the generated LL-key-only pattern, simulate it on the locked netlist, and demonstrate that the key bit value appears on an observable output. Without such a demonstration, the reader cannot distinguish a genuine leakage from an artifact of scan-based ATPG.","section":"Section IV-B, step 5 and Section V"},{"comment":"The paper repeatedly uses 'hard-detected' as though it were a proof of exploitability, but 'hard detected' in ATPG terminology only means that the test generator found a deterministic pattern in the fault model being used. The paper then says 'only hard-detected tests are considered security threats', which converts an ATPG bookkeeping category into a security claim. This is a semantic leap that needs explicit justification. The authors should at minimum clarify the ATPG fault class (stuck-at, transition, path delay), the scan configuration, and why a stuck-at detection on a non-primary input is a valid oracle for the value of a stored secret bit inside a running cipher.","section":"Section IV-B, last paragraph and Section V-A"}],"minor_comments":[{"comment":"There are several typographical and formatting errors: 'orintroduce' in Section I, 'S ET-A LL' and 'S ET-L L-K EY' in Section IV-B, and inconsistent spacing in the scenario labels. These should be corrected.","section":"Throughout"},{"comment":"The caption uses 'Untestable (AU)' but the text in Section II-B defines the secure class as 'S' (secure) and never defines 'AU'. The figure and text should use the same terminology.","section":"Figure 4 caption"},{"comment":"The statement 'DT indicates that the confidential bit can be transferred to an output' is too strong given the unresolved scan-mode question. This should be rephrased as 'DT indicates that the ATPG tool found a test pattern under the configured fault model' until the functional validation is provided.","section":"Section V-A, Fig. 6 discussion"},{"comment":"The paper states that increasing the ATPG time limit up to 13 hours did not change the ND classification, but the exact definition of ND is not given in the methodology. It is unclear whether ND means 'timeout', 'aborted', or 'ATPG could not determine a test in the given time'. The classification should be defined precisely.","section":"Section V-D, Limitations"}],"recommendation":"major_revision","confidential_remarks":"To the editor: The manuscript addresses a relevant and timely question, and the experimental scale is a genuine strength. However, the central interpretation of ATPG 'detected' results as runtime confidentiality leakages is not yet justified. The revision should either provide functional-mode validation of the DT-to-exploit step or narrow the claims to 'ATPG-detected paths' rather than 'leakage'. I see this as a fixable issue within the manuscript's scope, not a reason for rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis paper is worth a serious look, but read the headline numbers as upper bounds on combinational reachability, not demonstrated runtime leaks. The genuinely new thing is the automated evaluation: three logic-locking schemes (EPIC, D-MUX, ASSURE), five open crypto benchmarks, and 1,000 locked netlists per gate-level scheme, with ATPG-based path sensitization labeling each secret bit detected/secure/not-detected. The baseline unlocked designs are clean, which is a meaningful control. The finding that EPIC locking can create paths from encryption key bits to outputs at scale, with a single wrong LL key exposing up to 73.83% of an AES-128 key in the stuck-at model, is a real expansion of the threat model beyond key-recovery attacks.\n\nNow the soft spots. The largest is the inference from 'detected' (DT) ATPG tests to 'compromised' confidentiality. The secret bits in these crypto cores are register outputs, not combinational primary inputs. A stuck-at DT test typically requires driving the fault site to a known value to excite it; in the SET-LL-KEY scenario only the LL key inputs are controllable, so many DT patterns may rely on scan chains or test-mode initialization that a runtime attacker doesn't have. Section IV-B doesn't specify the ATPG mode or simulate any pattern in functional mode. That doesn't break the paper's existence claim—locked netlists do contain new combinational paths from key bits to outputs—but it means the quantitative leak rates are not yet proven as runtime confidentiality loss. The ND population is another issue: the paper honestly flags it, but leaving up to large fractions unresolved makes the reported rates lower bounds. Lack of released artifacts also hurts reproducibility, though the benchmarks are open and the method is standard.\n\nWhat holds up: the baseline is clean, the three schemes show different susceptibility profiles, and the discussion of where leakages concentrate (FSM-controlled datapaths) is plausible. The authors also explicitly cite their own prior MiG-V manual analysis and QFlow without leaning on them as proof. This is honest work.\n\nWho is this for: hardware-security researchers working on logic locking, and designers considering locking for commercial parts. A serious referee should engage, but the paper needs revision: validate the DT-to-exploit translation on a few designs with functional simulation, report scan vs. non-scan ATPG settings, and either resolve ND or present rates as lower bounds with error bars. My verdict: send it to review, but don't let the 73.83% claim out as-is.","headline":"Automated ATPG study shows logic locking can create combinational key-leak paths, but the '73% compromised' claim needs a functional-mode check.","tokens_in":12020,"tokens_out":2479,"would_cite":true,"duration_ms":21852,"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":"Logic locking can inadvertently create paths that leak encryption keys when the wrong locking key is applied, with a single malicious key exposing over 70% of a 128-bit key in some benchmarks.","keywords":["logic locking","confidentiality","path sensitization","ATPG","encryption key leakage","hardware security","information leakage"],"falsifier":"Take one of the locked XTEA or AES netlists, extract the exact key pattern and secret-bit pattern that the ATPG tool labels 'Detected', then run a full functional simulation (including the clock and FSMs) of the chip performing real encryption; if the secret bit never reaches an output in functional mode, or if the required LL-key value cannot be imposed on the tamper-proof storage, the paper's 'can leak' claim is not exploitable. A silicon experiment with fault-injected LL-key bits would settle it directly.","tokens_in":10999,"feed_emoji":"🔐","tokens_out":4744,"duration_ms":42415,"temperature":0.7,"pith_summary":"Logic locking is meant to hide a chip's design from untrusted foundries, but the locking hardware itself can create new combinational paths. This paper claims that when an attacker applies an incorrect logic-locking key, these paths can forward secret data such as encryption key bits to the chip's outputs. Using an automatic test-pattern generation framework on five open-source cryptographic benchmarks and three representative locking schemes, the authors found that a single malicious key can expose over 70% of an encryption key, and that an attacker who also controls other inputs can expose the entire key. The result matters because it turns a correctness failure into a confidentiality failure: a chip that is merely malfunctioning under the wrong key can instead be leaking its secrets.","feed_headline":"Logic locking can leak 74% of an encryption key","feed_subtitle":"Automated path-sensitization tests show wrong logic-locking keys open new data-leakage paths in crypto circuits.","key_machinery":"The method is path sensitization, a test-generation technique that asks whether some input pattern can propagate a chosen internal signal to a primary output. The authors apply it through a stuck-at fault ATPG framework: each secret bit is marked as a fault site, non-adversarial inputs are constrained to unknown, and the tool either finds a propagating pattern (Detected), proves none exists (Secure), or times out (Not Detected). This machinery is what turns the abstract idea of 'leakage paths' into a measured, per-bit detection rate for each locking scheme and key size.","core_discovery":"The central claim is that logic locking can inadvertently break confidentiality: inserting key-controlled gates and multiplexers creates new combinational paths that an adversary can activate by choosing the logic-locking key value. In their automated evaluation, the authors report that for the EPIC XOR/XNOR locking scheme, a malicious key can expose up to 73.83% of a 128-bit encryption key in the XTEA benchmark, with at least 20 of the 128 bits leaking in every one of the 1,000 generated netlists at 50% key size. When the attacker is allowed to set all non-secret inputs, ASSURE-locked designs can leak up to 100% of the key. The paper frames these leakages as a new class of vulnerability: logic locking, which is deployed to protect against supply-chain tampering, can itself become the vehicle for secret-data extraction.","pith_inferences":["The paper does not check whether its detected combinational paths are actually reachable in sequential operation; a functional formal analysis of the same benchmarks would show how many of the reported leakages are truly exploitable.","If these leak paths survive sequential validation, then any fault-injection or glitching technique that transiently changes the LL key becomes a key-extraction attack, not just a denial-of-service.","The same automated screening could be applied to other secrets in locked designs, such as neural network weights or DSP filter coefficients, with likely similar findings.","The 'Not Detected' category and the runtime limits imply the reported rates are lower bounds; quantitative information-flow analysis could reveal additional or larger leakages."],"forward_implications":["Locked hardware must be re-verified for confidentiality after locking, not only for correctness with the correct key.","The logic-locking key should be treated as a potentially adversarial input in security analysis, on par with the secret data it is meant to protect.","The reported minimum of 20 leaked bits across all XTEA netlists at 50% EPIC key size means the vulnerability is not a rare outlier but a structural property.","Security metrics for logic locking should expand from key-recovery resistance to include information-flow leakage under wrong keys."],"supporting_citations":[{"why":"Motivates the study by showing a manual inspection of a logic-locked RISC-V processor discovered exploitable encryption key leakage.","marker":"[5]"},{"why":"Defines ASSURE, the RTL locking scheme whose constant, operation, and branch locking are evaluated in the paper.","marker":"[8]"},{"why":"Defines EPIC, the XOR/XNOR gate locking scheme that produces the highest leakage rates in the results.","marker":"[9]"},{"why":"Defines D-MUX, the multiplexer-based locking scheme evaluated for comparison.","marker":"[10]"},{"why":"Supplies the path sensitization technique that the ATPG framework uses to determine whether a secret bit can reach an output.","marker":"[17]"},{"why":"Describes the TAAL tampering attack, supporting the paper's assumption that an attacker can modify or bypass logic-locking key storage.","marker":"[19]"}],"fun_headline_variants":["Logic locking can leak 74% of encryption keys","Logic locking backfires: wrong keys expose secrets","Automated analysis reveals logic locking leaks data","Logic locking introduces new key leakage paths","Study: logic locking compromises confidentiality"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that an ATPG 'detected' result in the stuck-at combinational model corresponds to a real exploitable leak in the functioning chip; if those test patterns cannot be activated during normal operation, the leak rates would be materially lower.","fun_headline_variants_meta":{"raw":{"variants":["Logic locking can leak 74% of encryption keys","Logic locking backfires: wrong keys expose secrets","Automated analysis reveals logic locking leaks data","Logic locking introduces new key leakage paths","Study: logic locking compromises confidentiality"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000345,"raw_usage":{"total_tokens":1860,"prompt_tokens":878,"completion_tokens":982,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":494,"completion_tokens_details":{"reasoning_tokens":916}},"tokens_in":494,"tokens_out":982,"duration_ms":9945,"temperature":1.0,"reasoning_tokens":916,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T15:55:23.069755+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take one of the locked XTEA or AES netlists, extract the exact key pattern and secret-bit pattern that the ATPG tool labels 'Detected', then run a full functional simulation (including the clock and FSMs) of the chip performing real encryption; if the secret bit never reaches an output in functional mode, or if the required LL-key value cannot be imposed on the tamper-proof storage, the paper's 'can leak' claim is not exploitable. A silicon experiment with fault-injected LL-key bits would settle it directly.","supporting_citations":[{"cited_title":"Exploiting the Lock: Leveraging MiG-V's Logic Locking for Secret-Data Extraction","cited_arxiv_id":"2408.04976","evidence_quote":"Motivates the study by showing a manual inspection of a logic-locked RISC-V processor discovered exploitable encryption key leakage."},{"cited_title":"ASSURE: RTL Locking Against an Untrusted Foundry,","cited_arxiv_id":null,"evidence_quote":"Defines ASSURE, the RTL locking scheme whose constant, operation, and branch locking are evaluated in the paper."},{"cited_title":"EPIC: Ending Piracy of Integrated Circuits,","cited_arxiv_id":null,"evidence_quote":"Defines EPIC, the XOR/XNOR gate locking scheme that produces the highest leakage rates in the results."},{"cited_title":"Deceptive Logic Locking for Hardware Integrity Protection Against Machine Learning Attacks,","cited_arxiv_id":null,"evidence_quote":"Defines D-MUX, the multiplexer-based locking scheme evaluated for comparison."},{"cited_title":"Path sensitization, partial boolean difference, and automated fault diagnosis,","cited_arxiv_id":null,"evidence_quote":"Supplies the path sensitization technique that the ATPG framework uses to determine whether a secret bit can reach an output."},{"cited_title":"Taal: Tampering attack on any key-based logic locked circuits,","cited_arxiv_id":null,"evidence_quote":"Describes the TAAL tampering attack, supporting the paper's assumption that an attacker can modify or bypass logic-locking key storage."}],"review_version":1}