Pith. sign in

REVIEW 3 major objections 4 minor 28 references

The Impact of Logic Locking on Confidentiality: An Automated Evaluation

T0 review · 3 major / 4 minor · reviewed 2026-08-09 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read 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.

desk verdict Automated ATPG study shows logic locking can create combinational key-leak paths, but the '73% compromised' claim needs a functional-mode check. read the letter →

arxiv 2502.01240 v2 pith:I7NIIQLI submitted 2025-02-03 cs.CR cs.AR

Lennart M. Reimann , Evgenii Rezunov , Dominik Germek , Luca Collini , Christian Pilato , Ramesh Karri , Rainer Leupers This is my paper · ORCID
classification cs.CRcs.AR
keywords logiclockingconfidentialitypathsensitizationATPGencryptionkeyleakagehardwaresecurityinformation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

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.

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 (3)
  1. [Section IV-B, steps 3-5] 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.
  2. [Section IV-B, step 5 and Section V] 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.
  3. [Section IV-B, last paragraph and Section V-A] 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.
minor comments (4)
  1. [Throughout] 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.
  2. [Figure 4 caption] 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.
  3. [Section V-A, Fig. 6 discussion] 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.
  4. [Section V-D, Limitations] 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.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: the leakage rates are direct ATPG outputs on open benchmarks, and the paper's self-citations are motivational or future-work pointers rather than load-bearing evidence.

full rationale

The claimed result (logic locking can create confidentiality leakages, e.g., EPIC with up to 73.83% of key bits leaked by changing only the LL key) is obtained by running the TestMAX ATPG engine on open-source crypto benchmarks before and after locking, and counting 'Detected' (DT) classifications per secret bit. No parameter is fitted to the reported leak rates, and no equation is constructed so that the output equals an input. The paper's own definition equates DT with an input pattern that sensitizes a secret bit to a primary output; applying that definition consistently to locked and unlocked netlists is an operationalization, not a circular reduction. The self-citations ([5] MiG-V manual extraction, [28] QFlow, [29] QIF) occur in the introduction and limitations: [5] is a motivating prior example and [28]/[29] are named as possible future tools. None of these citations supplies the quantitative EPIC/D-MUX/ASSURE results, so none is load-bearing for the central claim. The paper also explicitly acknowledges that ND bits might still leak, and that only DT tests are treated as threats, which is an honest limitation rather than a hidden circular step. A reviewer could dispute whether a stuck-at ATPG 'DT' in test mode implies an exploitable runtime leakage (scan access, FSM reachability, timing), but that is a threat-to-validity caveat, not circularity. Accordingly, no circular step is exhibited.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claim relies on the attack-model assumptions listed in Section II-C and on equating ATPG detectability with exploitable leakage. No new physical entities or fitted parameters are introduced; the experimental protocol contributes data, not inferred constants.

assumptions (4)
  • domain assumption Adversary knows the positions of all signals carrying sensitive information, e.g., encryption keys, in the locked netlist.
    Stated in Section II-C as an assumption of the attack model; required so the secret bit can be labeled for ATPG. In practice an attacker with the netlist may need additional reverse engineering to locate key registers.
  • domain assumption A hard-detected stuck-at test that propagates a secret bit to a primary output represents an exploitable confidentiality leakage.
    The methodology (Section IV-B, step 6) treats DT as security threats. This equates combinational test-path detection with a runtime confidentiality breach, without modeling sequential behavior, timing, or scan-chain access.
  • domain assumption The five OpenCores/Trust-Hub crypto benchmarks are representative enough to draw conclusions about the behavior of logic locking schemes.
    The study generalizes from five designs (Section IV-A); the authors note that the hardware architecture strongly influences susceptibility, so the sample may not cover all design classes.
  • domain assumption The adversary can modify the logic-locking key value during operation of an activated chip.
    The attack model in Section II-C assumes the attacker can tamper with the LL key storage or the value before it reaches the key gates, citing fault injection and hardware Trojans as enablers.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Impact of Logic Locking on Confidentiality: An Automated Evaluation." pith.science (2026). https://pith.science/paper/I7NIIQLI

@misc{pith2026250201240,
  author       = {Pith},
  title        = {Pith review of: The Impact of Logic Locking on Confidentiality: An Automated Evaluation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/I7NIIQLI}},
  note         = {Machine review of arXiv:2502.01240}
}
read the original abstract

Logic locking secures hardware designs in untrusted foundries by incorporating key-driven gates to obscure the original blueprint. While this method safeguards the integrated circuit from malicious alterations during fabrication, its influence on data confidentiality during runtime has been ignored. In this study, we employ path sensitization to formally examine the impact of logic locking on confidentiality. By applying three representative logic locking mechanisms on open-source cryptographic benchmarks, we utilize an automatic test pattern generation framework to evaluate the effect of locking on cryptographic encryption keys and sensitive data signals. Our analysis reveals that logic locking can inadvertently cause sensitive data leakage when incorrect logic locking keys are used. We show that a single malicious logic locking key can expose over 70% of an encryption key. If an adversary gains control over other inputs, the entire encryption key can be compromised. This research uncovers a significant security vulnerability in logic locking and emphasizes the need for comprehensive security assessments that extend beyond key-recovery attacks.

Figures

Figures reproduced from arXiv: 2502.01240 by the authors.

Figure 1
Figure 1. A logic-locked IC has the same functionality as its [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Use of logic locking to secure the supply chain. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. The three logic locking algorithms introducing additional logic: EPIC (adds XOR and XNOR gates), D-MUX (adds [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Path sensitization is applied to retrieve the encryption [PITH_FULL_IMAGE:figures/full_fig_p003_4.png]
Figure 5
Figure 5. Figure 5: The ATPG framework is used to identify leakage paths [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: The histogram illustrates the leakage distribution for each secret bit in the 1,000 generated benchmarks for one key [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Relative average detection rate for all 3 LL algorithms, for multiple key sizes and 5 benchmarks. [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Histogram illustrating the distribution of the netlists over the number of leakages for the XTEA benchmark. The red [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages

  1. [1]

    Advances in logic locking: Past, present, and prospects,

    H. M. Kamali et al. , “Advances in logic locking: Past, present, and prospects,” IACR Cryptol. ePrint Arch. , p. 260, 2022

    work page 2022

  2. [2]

    Keynote: A disquisition on logic locking,

    A. Chakraborty et al., “Keynote: A disquisition on logic locking,” IEEE TCAD, vol. 39, no. 10, pp. 1952–1972, 2020

    work page 1952

  3. [3]

    A secure hardware-software solution based on risc- v, logic locking and microkernel,

    D. Sisejkovic et al., “A secure hardware-software solution based on risc- v, logic locking and microkernel,” in ACM SCOPES’20, 2020, p. 62–65

    work page 2020

  4. [4]

    Trustworthy hardware design with logic locking,

    D. Sisejkovic et al., “Trustworthy hardware design with logic locking,” in IFIP/IEEE VLSI-SoC 2021 , 2021, pp. 1–2

    work page 2021

  5. [5]

    Exploiting the Lock: Leveraging MiG-V's Logic Locking for Secret-Data Extraction

    L. M. Reimann et al. , “Exploiting the lock: Leveraging mig-v’s logic locking for secret-data extraction,” 2024. [Online]. Available: https://arxiv.org/abs/2408.04976

    work page Pith review arXiv 2024

  6. [6]

    Evolution of logic locking,

    M. Yasin et al. , “Evolution of logic locking,” in IFIP/IEEE VLSI-SoC 2017, 2017, pp. 1–6

    work page 2017

  7. [7]

    Provably-secure logic locking: From theory to practice,

    M. Yasin et al., “Provably-secure logic locking: From theory to practice,” in ACM CCS SIGSAC 2017 , 2017, p. 1601–1618

    work page 2017

  8. [8]

    ASSURE: RTL Locking Against an Untrusted Foundry,

    C. Pilato et al., “ASSURE: RTL Locking Against an Untrusted Foundry,” IEEE TVLSI, vol. 29, no. 7, pp. 1306–1318, 2021

    work page 2021

Show all 28 references
  1. [9]

    EPIC: Ending Piracy of Integrated Circuits,

    J. A. Roy et al., “EPIC: Ending Piracy of Integrated Circuits,” in 2008 Design, Automation and Test in Europe , 2008, pp. 1069–1074

    2008

  2. [10]

    Deceptive Logic Locking for Hardware Integrity Protection Against Machine Learning Attacks,

    D. Sisejkovic et al. , “Deceptive Logic Locking for Hardware Integrity Protection Against Machine Learning Attacks,” IEEE TCAD, 2022

    2022

  3. [12]

    On improving the security of logic locking,

    M. Yasin et al. , “On improving the security of logic locking,” IEEE TCAD, vol. 35, no. 9, pp. 1411–1424, 2016

    2016

  4. [13]

    Thwarting all logic locking attacks: Dishonest oracle with truly random logic locking,

    N. Limaye et al., “Thwarting all logic locking attacks: Dishonest oracle with truly random logic locking,” IEEE TCAD, pp. 1740–1753, 2021

    2021

  5. [14]

    SAIL: Machine learning guided structural analysis attack on hardware obfuscation,

    P. Chakraborty et al., “SAIL: Machine learning guided structural analysis attack on hardware obfuscation,” in AsianHOST 2018, 2018, pp. 56–61

    2018

  6. [15]

    Challenging the security of logic locking schemes in the era of deep learning: A neuroevolutionary approach,

    D. Sisejkovic et al., “Challenging the security of logic locking schemes in the era of deep learning: A neuroevolutionary approach,” ACM JETC

  7. [16]

    Omla: An oracle-less machine learning-based attack on logic locking,

    L. Alrahis et al., “Omla: An oracle-less machine learning-based attack on logic locking,” IEEE TCAS II , vol. 69, no. 3, pp. 1602–1606, 2022

    2022

  8. [17]

    Path sensitization, partial boolean difference, and automated fault diagnosis,

    A. C. L. Chiang et al., “Path sensitization, partial boolean difference, and automated fault diagnosis,” IEEE TCOMP, no. 2, pp. 189–195, 1972

    1972

  9. [18]

    TestMax,

    Synopsys Inc., “TestMax,” 2023. [Online]. Available: https://www. synopsys.com/implementation-and-signoff/test-automation

    2023

  10. [19]

    Taal: Tampering attack on any key-based logic locked circuits,

    A. Jain et al. , “Taal: Tampering attack on any key-based logic locked circuits,” ACM Trans. Des. Autom. Electron. Syst. , vol. 26, mar 2021

    2021

  11. [20]

    Exploiting logic locking for a neural trojan attack on machine learning accelerators,

    H. Xu et al. , “Exploiting logic locking for a neural trojan attack on machine learning accelerators,” in ACM GLSVLSI 2023 , p. 351–356

    2023

  12. [21]

    Security analysis of logic obfuscation,

    J. Rajendran et al. , “Security analysis of logic obfuscation,” in ACM DAC 2012, 2012, p. 83–89

    2012

  13. [22]

    Yasin et al

    M. Yasin et al. , The SAT Attack , ser. Analog Circuits and Signal Processing. Springer, 2020, pp. 47–56, springer Nature

    2020

  14. [23]

    Oracle-guided incremental sat solving to reverse engineer camouflaged logic circuits,

    D. Liu et al., “Oracle-guided incremental sat solving to reverse engineer camouflaged logic circuits,” in DATE 2016, 2016, pp. 433–438

    2016

  15. [24]

    Integrated circuit (ic) decamouflaging: Reverse engineering camouflaged ics within minutes,

    M. E. Massad et al. , “Integrated circuit (ic) decamouflaging: Reverse engineering camouflaged ics within minutes,” in NDSS Symp., 2015

    2015

  16. [25]

    Evaluating the security of logic encryption algorithms,

    P. Subramanyan et al. , “Evaluating the security of logic encryption algorithms,” in IEEE HOST 2015 , pp. 137–143

    2015

  17. [26]

    OpenCores,

    “OpenCores,” vis. 2024-05-14. [Online]. Available: www.opencores.org

    2024

  18. [27]

    Trust-Hub,

    Kan Xiao, “Trust-Hub,” 2024. [Online]. Available: https://trust-hub.org

    2024

  19. [28]

    QFlow: Quantitative Information Flow for Security-Aware Hardware Design in Verilog,

    L. M. Reimann et al. , “QFlow: Quantitative Information Flow for Security-Aware Hardware Design in Verilog,” in IEEE ICCD 2021 , pp. 603–607

    2021

  20. [29]

    Quantitative information flow for hardware: Advancing the attack landscape,

    L. M. Reimann et al. , “Quantitative information flow for hardware: Advancing the attack landscape,” in IEEE LASCAS 2023 , pp. 1–4

    2023

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.