Towards a Formal Treatment of Logic Locking

. Logic locking aims to protect the intellectual property of a circuit from a fabricator by modifying the original logic of the circuit into a new “locked” circuit such that an entity without the key should not be able to learn anything about the original circuit. While logic locking provides a promising solution to outsourcing the fabrication of chips, unfortunately, several of the proposed logic locking systems have been broken. The lack of established secure techniques stems in part from the absence of a rigorous treatment toward a notion of security for logic locking, and the disconnection between practice and formalisms. We seek to address this gap by introducing formal deﬁnitions to capture the desired security of logic locking schemes. In doing so, we investigate prior deﬁnitional eﬀorts in this space, and show that these notions either incorrectly model the desired security goals or fail to capture a natural “compositional” property that would be desirable in a logic locking system. Finally we move to constructions. First, we show that universal circuits satisfy our security notions. Second, we show that, in order to do better than universal circuits, cryptographic assumptions are necessary.


Introduction
Integrated circuits often represent the root of trust of modern computing systems.However, over the years, the design and manufacturing process has been decentralized to include multiple players in the supply chain, and this decentralization has raised the risk of threats such as intellectual property piracy and reverse engineering.For example, a malicious manufacturer may attempt to steal and reproduce a proprietary algorithm, extract secret keys or information hardwired in the design, or overproduce.
Logic locking has gained significant attention as a potential solution to mitigate the above vulnerabilities [RKM10, RZZ + 13, YMRS16, SLM + 17, YSN + 17, XS18, KKN + 19, KAHS20, MAS + 21].The goal of logic locking is to modify the logic of the circuit in such a way that the circuit becomes "useless" without the knowledge of an additional secret key that is only known to the designer.That is, a designer could "lock" the circuit and hand the locked circuit to the foundry.Upon receiving the resulting (locked) chip, the designer could then "unlock" the circuit to recover the original circuit's functionality.
Table 1: Summary of several proposed schemes for combinational circuits developed after the introduction of the SAT attack [SRM15,EGT19].We also list whether the scheme proposes a (or references an existing) security definition, and whether there exists a published attack against the given scheme.[DSSY20] Flawed ( §4.3) InterLock [KAHS20] OneChaff hd [CS21] Yes ( §4.4) Redaction [MAS + 21] and hash functions.However, the state of logic locking is different in a significant way: there exists no precise formalism for what exactly a logic locking scheme should achieve.This has several undesirable effects.For one, it is hard to reason about the security of a logic locking scheme without a formal notion of what a secure scheme should achieve.This has led to a multitude of claimed-secure constructions that have since been broken [BTZ10, DBN + 14, RZZ + 15, SRZ18, SS20, SRM15, APSS21].In addition, even if it is not possible to directly use the formalism to prove security (in the sense that one cannot construct a security proof against that formalism), the formalism can still guide the designer in knowing what to focus on in the design.As an example, all commonly used block ciphers-such as AES-do not have security proofs.Despite this, understanding precisely what a secure block cipher should achieve guides designers in avoiding common pitfalls.This has led to practical block ciphers that have withstood decades of cryptanalysis.

Existing Schemes and Their Security
We are not the first to identify the need for a formal security definition for logic locking.Indeed, several notions have been proposed in the literature, and it is becoming more common for proposed constructions to claim security against a security model, usually one introduced alongside the proposed construction.We find two concerns with this approach.First, the fact that a security definition exists does not mean it is the most appropriate definition, in the sense that it rigorously captures the particular adversary setting logic locking aims to address.While there have been several attempts at formalizing logic locking [YSN + 17, SPJ19, DSSY20], we show in §4 that these approaches are amenable to important flaws.Second, rather than introducing its own security definition, each construction should target a well established and agreed upon security definition.Consider encryption: while there are definitional variants, the standard notion of "secure encryption"indistinguishability against chosen plaintext attack (IND-CPA)-is well established, and any new encryption scheme must at least achieve this baseline.One of the aims of this work is to move the community towards such a standard notion.
In Table 1, we list several proposed logic locking schemes targeting combinational circuits, whether the construction references a security definition, and whether the scheme has a published attack.Not all schemes in the table have known attacks.We caution the reader that this does not mean that a scheme is "secure"-where secure is relative to a specific security definition-in that, while a scheme may avoid existing attacks, it may fall victim to future attacks.We can see this in several instances; for example, SRCLock [RKS18] was designed to prevent SAT attacks but was later found vulnerable to SMT attacks [AKHS19].

Contributions
In this work, we take a fresh look at formalizing the security of logic locking, focusing on combinational constructions.We begin by defining a concrete syntax for logic locking; namely, what exactly a logic locking construction is.We then recast prior definitional attempts using this syntax.In doing so, we identify several shortcomings that may emerge from prior formalization attempts.We propose two new security definitions for logic locking, and discuss the relation between these new notions and prior notions.Finally, we show that a "universal circuit" approach satisfies our security notions, possibly encompassing several programmable logic-based methods [KKN + 19, KAHS20, CZHN21, SPJ19], including "redaction" [MAS + 21], which can be modeled within a universal circuit framework.We discuss our contributions in more detail below.
A syntax for logic locking ( §3).We begin by defining a logic locking scheme as a randomized algorithm Lock that takes as input a circuit C and outputs a locked circuit L and a key K.We require that L, when given as input the right key K, has the same "behavior" as the original circuit C.This captures the intuitive notion that for a logic locking scheme to be useful, the designer must be able to "unlock" the fabricated chip to produce the expected behavior of the original design.Requiring Lock to return K, rather than taking it as input as in the definitions of many cryptographic primitives, allows K to depend on C, which is necessary to capture schemes based on universal circuits.

A survey of prior definitions ( §4).
By fixing the syntax of logic locking, we can recast all prior definitions in this framework to allow for ease of comparison between these notions.In doing so, we identify several flaws that lead to definitions that are either impossible or trivial to satisfy.We note that prior definitions mostly follow a similar flavor: the adversary A, given the locked circuit L as input and, possibly, oracle access to an unlocked, working version of the original circuit C, needs to output a circuit C that is functionally equivalent to-that is, has the same input-output behavior as-C.What differs among these definitions is what constitutes a "win" for the adversary: approaches such as attack resilience [YSN + 17] and function recovery [CS21] require that the probability that A can output such a C is sufficiently small, whereas approaches such as best possible approximate functional secrecy [SPJ19] and lock security [DSSY20] require that A do no better than a "simulator" S that has only oracle access to the input/output behavior of C and knowledge of its size (that is, S does not take the locked circuit L as input).
Unfortunately, all these prior definitions-except function recovery-exhibit important flaws: they become either impossible or trivial to satisfy.This is primarily due to the specification of the definition differing from the perceived "intent" of the definition.We thus recast these notions as a notion that we call functional secrecy, which aims to capture the intent of these prior notions while avoiding their pitfalls.However, as we show in §6, even this notion-alongside function recovery-still fails to guarantee a natural and intuitive composition requirement that one would intuitively want a logic locking scheme to satisfy.

New definitions for logic locking ( §5).
Given the state of prior definitions, we propose two new definitions for logic locking.The difference between these and prior efforts lies in the observation that it is not sufficient to guarantee that an adversary cannot recover the entire protected circuit.Any part of the protected circuit-or indeed, any predicate about it-that the adversary can learn is potentially damaging.Thus, to use our definitions, one first rigorously identifies the information a locking scheme inevitably "leaks," then proves that it reveals nothing else.This opens the door to proving the security of efficient schemes that hide "enough" information about a circuit, while requiring designers to be explicit about exactly what is hidden and what is not.
Our first notion, which we call indistinguishable logic locking (IND-LL), requires that the adversary cannot "learn" which of two circuits was locked.In detail, we consider two arbitrary circuits C 0 and C 1 and lock one of them at random.The adversary "wins" if it can guess which circuit was locked.Leakage is handled implicitly by requiring that C 0 and C 1 have the leaked information in common.This approach is very similar to other "indistinguishability"-based notions in cryptography, adapted to the logic locking setting.
Our second notion, which we call simulation-secure logic locking (SIM-LL), requires that an adversary cannot "learn" any more about the original circuit from the locked circuit than a simulator can learn, given only access to some leakage information on the circuit.This is similar to our functional secrecy notion, except we again are only requiring the adversary to output some arbitrary predicate, versus requiring the adversary to output a functionally equivalent circuit as in the functional secrecy case.
Finally, we note that in practice the entire design does not necessarily need to be protected from an adversarial foundry.Rather, there is likely some small subset of the design that contains the sensitive IP, with the rest containing non-sensitive IP.1 As we show in §6, all prior security definitions we investigated were insufficient to capture security in this setting.In contrast, although the definitions of IND-LL and SIM-LL do not explicitly allow part of the circuit to remain unlocked, they do guarantee security in this scenario.We show this by means of a notion we call contextual functional secrecy (CFS), which IND-LL and SIM-LL both imply, and prior notions do not.CFS captures the goal that a scheme should remain secure if it is used on a circuit C composed with any public context

Relations between definitions ( §6).
Given this set of definitions, we next investigate the relationship between these definitions.We show that IND-LL is strictly stronger than SIM-LL and that SIM-LL is strictly stronger than all prior notions we investigated.

Constructions ( §7).
Finally, we show that our new notions are satisfiable by showing that a "universal circuit" approach (akin to certain programmable logic-based methods [KKN + 19, KAHS20, CZHN21, SPJ19, MAS + 21]) satisfies IND-LL.While this approach is not new (for example, redaction [MAS + 21] takes a similar approach using FPGAs and the work of Di Crescenzo et al. [DSSY20] provide a more theoretical analysis), we demonstrate that this approach-when applied to Boolean circuits-is IND-LL secure (and hence SIM-LL secure as well) when leaking the size of the circuit to the adversary.We caution that this does not imply that the redaction approach is necessarily secure: for example, our circuit model is different than the circuit model of FPGAs.However, it is an initial step towards reasoning about the security of a redaction-like scheme, and provides a basis for future work proving the security of more realistic circuit models.
Universal circuits come with a lower bound on their size that stems from a lower bound on the size of edge-universal graphs. 2 We show in §7.2 that cryptographic assumptions are necessary to do better than this bound when targeting the IND-LL notion.Interestingly, no scheme we are aware of (cf.Table 1) makes use of cryptographic assumptions, suggesting that these schemes are not IND-LL secure.

Preliminaries
We use upper-case letters to denote strings (e.g., X), and bold-face letters to denote circuits (e.g., C).Our definitions are largely irrespective of the internal computational model of the circuit, so for now we leave it unspecified, besides the requirement that circuits be stateless.Only in §7, where we prove the security of a specific construction, do we specify the circuit computational model.For circuits C and C , we say C ≡ C if the two circuits have identical input-output behavior (that is, their functionalities are the same).For some fixed ∈ [0, 1], we say C ≡ C if the two circuits have identical input-output behavior except on an -fraction of inputs.
At times, we want to make explicit additional information that can be hardwired in a circuit C but never used by it.For example, we would like to have a way of adding a secret key K to the description of C that can be extracted easily by just observing C's description.We denote such an augmented circuit as C = [C, K].In particular, this implies that [C, K] ≡ C. Likewise, at times we want to reference a bit in the description of a circuit C. To denote the ith bit of the description of C, we use the notation C i .
We use X : Y to denote that variable X has "type" Y ; e.g., C : {0, 1} n → {0, 1} m says that C is an n-input m-output circuit.We use x ← ← S to denote that x is sampled uniformly at random from set S and x ← ← D to denote that x is sampled from a distribution D.
When we use the term "adversary," we mean a probabilistic algorithm with access to zero or more oracles.We assume an oracle call takes unit time.We use the notation A O to denote an adversary A with oracle access to O. We often consider oracles that implement the functionality of a circuit C. In this case, we use A C to denote that adversary A has oracle access to circuit C. We use Pr[A ⇒ 1] to denote the probability that A outputs the value 1. Occasionally, we need to provide the adversary with explicit randomness.We use the notation A(X; R) to denote that adversary A is run on input X using randomness R.
Throughout the paper, we use as a measure of functional equivalence between two circuits-i.e., the fraction of inputs they differ on-and use σ, τ and δ for (difference of) probabilities, t for time, and q for number of queries.

Concrete security.
We utilize the concrete security framework [BKR94], where in lieu of a security parameter and an asymptotic adversary bound, we quantify everything in terms of the adversary's resources.Concrete security allows one to clearly quantify the adversary's advantage, whereas this information often gets lost when only considering asymptotic bounds.Thus, for security definitions aimed at practical deployments, we believe a concrete security treatment is the correct choice.

Logic Locking Syntax
In this section, we define what a logic locking scheme is and what it means for a logic locking scheme to be correct.
Definition 1 (Logic locking).A logic locking scheme is a randomized algorithm Lock with the following syntax: Definition 2 (Correctness).Logic locking scheme Lock is correct if for any circuit C : {0, 1} n → {0, 1} m , any (L, K) in the support of Lock(C), and any input X : {0, 1} n , it holds that L(K, X) = C(X).♦ Discussion.We do not require Lock to satisfy any efficiency constraints.While it may be desirable to ensure that a practical locking scheme runs in a "reasonable" amount of time with respect to the circuit size |C|, this concern is orthogonal to its security.In contrast, the size of L and K are important for our security definitions, since they reflect information given to and hidden from the adversary, respectively.However, these are implicitly bounded by the running time of the adversary as L is provided as input to the adversary and |L| ≥ |K|.
Leakage.When trying to define what it means for a logic locking scheme to be "secure" we often need to consider what the adversary knows ahead of time about the underlying circuit.We thus define a leakage function L that takes a circuit as input and outputs any information about that circuit that we allow to be leaked to the adversary.For example, one could consider a leakage function L size (C) that leaks the size of the input circuit C.
Another leakage function could be L topo (C) that leaks the circuit topology of C. We only consider leakage functions that are invertible in the sense that given leakage one can efficiently derive a circuit C that achieves that leakage.

Previous Definitions for Logic Locking
In this section we discuss several previous (and one largely concurrent) attempts towards defining security for logic locking.For each definition, we present our best interpretation of the definition (not all definitions presented in prior works are fully specified, so we occasionally need to interpret the intent of the definition as best as we can), followed by a discussion of the implications of said definition.

Attack Resilience [YSN + 17]
Yasin et al. [YSN + 17] provided one of the first attempts at formalizing security for logic locking,3 by introducing three notions: SAT attack resilience, sensitization attack resilience, and removal attack resilience.We focus on the first notion, as it most closely aligns with the adversary setting considered in this work. 4We begin by presenting a generalization of SAT attack resilience we call simply "attack resilience." Definition 3 (Attack resilience).Logic locking scheme Lock is (t, λ)-attack resilient if, for any t-time adversary A and for any circuit C, where q(•) is some polynomial denoting the number of queries made by A to its oracle.♦ Let us break this definition down.The adversary's goal is to derive some circuit C that is functionally equivalent to the original circuit C, and must do so given only the locked circuit L and the ability to query the circuit oracle q(λ) times.It wins if the circuit it produces is equivalent with probability greater than q(λ)/2 λ .
The actual definition of Yasin et al. considers a restricted form of attack resilience they call SAT attack resilience.The definition is the same as Definition 3 except with respect to a class of adversaries that only run SAT attacks.If we denote an adversary in this class as A SAT , then SAT attack resilience can be viewed as attack resilience with respect to adversaries A SAT .
Discussion.Unfortunately, SAT attack resilience is ill-defined in the sense that what constitutes a "SAT attack adversary" A SAT is not formally defined.For example, one could attempt to define a SAT attack adversary as a probabilistic polynomial time (PPT) algorithm with access to a SAT oracle.However, this adversary is actually stronger than the standard cryptographic adversary (who is only assumed to be PPT with no external oracle).One could instead try to limit the adversary to exist in some weaker complexity class than PPT; however, it is unclear what the real-world implications of this would be, and it could unnecessarily rule out practical attacks.Indeed, a scheme claimed as SAT attack resilient [YSN + 17] has since been broken [SS20].
However, even if we consider the more general attack resilience notion, the definition is unfortunately impossible to satisfy.Consider the adversary A that ignores its input and outputs some fixed circuit C. Note that there exists some circuit C for which C ≡ C, hence A succeeds with probability one, independent of the implementation of Lock.Intuitively, the security definition is missing some form of "randomization" to make such trivial attacks impossible.This randomization should appear after an adversary is fixed, thus generating uncertainty for the adversary.As an example, consider security that is defined as a game between an adversary and a challenger, where the challenger samples a random value (for example a bit) and the goal of the adversary is to guess this bit.In this case, the adversary cannot hardcode the right bit, because the bit is chosen after the adversary is fixed.

Best Possible Approximate Functional Secrecy [SPJ19]
Subsequent to Yasin et al.'s work, Shamsi et al. [SPJ19] define several notions of security, culminating in best possible approximate functional secrecy (BPAFS), which we focus on here.BPAFS aims to improve upon attack resilience by comparing the success probability of the adversary A attacking the locked circuit with some other adversary B that has only query access and knowledge of the original circuit's size.
In particular, Shamsi et al. present a notion that allows the adversary to restore an approximation of the original circuit C.This is captured by defining a "win" for the adversary as it producing a circuit C that is equivalent to C except on up to input-output pairs, where is a parameter of the security notion.In addition, rather than requiring that this probability be "sufficiently low" (as in attack resilience), the authors instead require that the adversary should do no better than another adversary that only has (1) oracle access to the original circuit, and (2) some fixed "leakage" of the original circuit-in this case, the size of the circuit.Definition 4 (Best-possible approximate functional secrecy).Logic locking scheme Lock is (t, q, , δ)-BPAFS-secure if for any circuit C, for any t-time q-query adversary A, and for any O(t)-time q-query adversary B, the following probability holds: Unfortunately, like attack resilience, BPAFS as presented is impossible to satisfy for any δ < 1.Consider adversary A that outputs hardcoded circuit C where C differs in more that input-output pairs from the "zero" circuit (that is, a circuit that on any input outputs the zero string), and adversary B that outputs the "zero" circuit.For any C ≡ C , it holds that δ = 1, independently of the implementation of Lock.The issue largely comes down to the fact that we are comparing two adversaries and quantifying over all possible adversaries.Clearly, for any adversary A, there will always be some adversary B that differs "sufficiently" from A to make δ sufficiently large.

Lock Security [DSSY20]
Di Crescenzo et al. [DSSY20] introduced a notion similar to BPAFS which they call lock security.Lock security is similar to BPAFS; however, instead of considering any adversary B, lock security requires the existence of such an adversary.
Definition 5 (Lock security).Logic locking scheme Lock is (t, q, δ)-lock secure if for any circuit C and any t-time q-query adversary A, there exists poly(t)-time poly(q)-query adversary B such that Unfortunately, this notion is trivially satisfiable.Let Lock be the scheme that sets L to its input circuit C. Clearly, this trivial Lock scheme should not be secure (it reveals C in the clear).However, we show that Lock is "secure" according to the above definition.Consider an adversary B that has C and A hardcoded (which is possible due to the order of quantifiers in the definition).Adversary B simply runs (L , K ) ← Lock(C) followed by A on input L , answering any oracle calls from A by running C. Note that L = L = C, and thus the input to A in both probabilities is identical.Thus, δ = 0.In this case, the flaw is with respect to the quantifiers in the definition: because B depends on the circuit C, it knows C. Requiring that B work for all C addresses the above attack; we discuss this modified notion in §4.5.

Function Recovery [CS21]
Most recently (and largely concurrently), Chhotaray and Shrimpton [CS21] introduced the notion of design hiding in an effort to formalize the security requirements of logic locking.They define two security notions: function recovery and key recovery; we focus on the function recovery setting in this work, since hiding the key does not necessarily hide the function.Their motivation for function recovery is very similar to ours in that they view prior definitions as either under-specified or insufficient, and provide a rigorous security notion alongside a construction satisfying that notion.While the authors consider both malicious and honest-but-curious chip fabricators, in this work we focus solely on the honest-but-curious case and thus only consider their honest-but-curious notion.
Definition 6 (Function recovery for design hiding).Logic locking scheme Lock is (t, q, δ)-FR-secure for function class F if for any t-time q-query adversary A, FR is similar to attack resilience: the main difference is that there is an additional "function class" parameter F, which captures any prior knowledge the adversary may have about the circuit to be fabricated.This addresses the main shortcoming of attack resilience, as now the adversary cannot hard-code a circuit C and win with probability one.
However, we note two potential downsides to the FR notion.The notion requires the adversary output a circuit functionally equivalent to the original circuit; this is a strong requirement, and one that may not matter in practice-for example, recovering part of the circuit may be sufficient for the adversary.While this partial-recovery setting can be captured by carefully specifying the function class, one would have to design (and prove) constructions secure for each function class of interest, which may not be scalable.Lastly, we show in §6 that FR is insufficient for capturing a natural "composition" notion of logic locking within a larger unprotected circuit.

Functional Secrecy
As we note above, both BPAFS and lock security have technical issues that cause them to be either unsatisfiable or trivially true for all locking schemes.Nonetheless, they have in common an intuitive notion of security that could be summarized as follows: No efficient adversary A, given a locking L of circuit C and an oracle for C (and perhaps some leakage L(C)) should be able to reconstruct an approximation C ≡ C with significantly greater probability than an adversary who has access to an oracle for C (and perhaps some leakage L(C)) alone.
Although the intuition behind this notion is clear, the devil is in the details when it comes to security definitions.We propose the following definition, which we call functional secrecy (FS), which we believe captures the spirit of both BPAFS and lock security while avoiding their technical shortcomings.
Definition 7 (Functional secrecy).Logic locking scheme Lock is (t, q, , σ, τ, L)-FS-secure if for any t-time q-query adversary A, there exists a poly(t)-time poly(t, q)-time simulator S such that for any circuit C and auxiliary information aux,

♦
Contrary to BPAFS and lock security, in our definition we make both the adversary's and the simulator's winning probabilities explicit.We do this because we believe that the definition remains sensible even if this difference is large.For example, consider the asymptotic setting where an adversary's advantage at guessing the circuit is bounded below by 1/p(λ) for some polynomial p whereas the simulator's advantage is bounded below by 1/q(λ) for some different polynomial q, where λ corresponds to the security parameter.The difference between p and q might be large-for example, q(λ) = p 2 (λ)-nonetheless, the scheme would still be secure.

Relationship with BPAFS.
This notion bears a strong similarity to BPAFS, but it avoids the pitfall that prevents BPAFS from being satisfiable.Since the simulator appears after the adversary in the quantifiers ("for any A, there exists S, . . ."), it can be assumed to know the code of the adversary.This prevents an adversary from winning by simply hard-coding a random circuit.
In addition, we generalize over the leakage a locking scheme may have.While we share the intuition of Shamsi et al. [SPJ19] that no locking scheme can successfully hide an upper bound on the size and depth of the circuit C, practical-and in particular, efficient-locking schemes may leak slightly more information and still be deemed acceptable, provided the leaked information can be precisely quantified.Or we may consider scenarios where a certain amount of leakage is unavoidable, such as when the adversary knows the circuit class to which C belongs.A generalized leakage parameter captures these scenarios.
Relationship with lock security.In addition to generalizing lock security by adding a leakage function and allowing adversaries that merely approximate the input circuit, the above definition avoids the problem of trivially admitting a simulator for any Lock.In particular, the simulator must hold for all circuits C, so cannot simply hard-code C. Discussion.The above notion is appealing, since like attack resilience and function recovery, it directly captures the adversary's inability to reconstruct the locked circuit.However, we argue that it is insufficient to capture the goal of security against an untrusted foundry.In particular, it only captures one of many possible security goals.Other reasonable security goals may be preventing an adversary from learning a subcircuit of C or even learning a circuit that behaves like C in a given fixed context.We formalize the second of these goals and show that FS fails in this setting; see §5.3.

New Security Definitions for Logic Locking
We introduce two new security definitions for logic locking.These differ from all prior attempts in that they move beyond functional equivalence of circuits to allowing the adversary to win if it learns anything about the circuit that it should not.We call these two notions indistinguishable logic locking ( §5.1) and simulation-secure logic locking ( §5.2).We also introduce a notion that aims to capture the setting where only a component of a larger design needs to be protected-we call this notion contextual function security ( §5.3).Finally, we discuss our particular definitional choices in more detail in §5.4.

Indistinguishable Logic Locking
Our first notion, called indistinguishable logic locking (IND-LL), differs from prior logic locking definitions in that it more closely matches classic indistinguishability notions such as indistinguishability against chosen-plaintext attack (IND-CPA).
Definition 8 (Indistinguishable logic locking).Logic locking scheme Lock is (t, δ, L)-IND-LL-secure if for any adversary A running in time t and circuits C 0 and C 1 such that IND-LL security can be interpreted as follows.We define the following security game between an adversary and a challenger.The challenger picks a random bit b and locks C b as the output of (L b , K) ← Lock(C b ) and gives L b to the adversary.The goal of the adversary is to guess the bit b sampled by the challenger.We say that Lock is (t, δ, L)-IND-LL-secure if for any adversary running in time t, the probability that it guesses the bit b is δ-far from ½.
Note that, unlike all prior definitions, the IND-LL adversary is not given oracle access to a circuit.This is because the adversary knows the circuits; thus, it could trivially win when given oracle access by simply querying its oracle on some input X in which C 0 (X) = C 1 (X).While this may suggest that IND-LL is weaker than notions providing oracle access to the circuit, we show in §6 the opposite: IND-LL is stronger than all other existing notions.

Simulation-Secure Logic Locking
Our second notion, called simulation-secure logic locking (SIM-LL), follows the simulation paradigm of functional secrecy (cf.Definition 7).However, there are two fundamental differences: (1) we require a black-box simulator with oracle access to the adversary (versus a white-box simulator as in Definition 7), and (2) rather than the requirement that a "close to functionally equivalent" circuit be produced, we instead allow the adversary to output any predicate.Namely, the adversary wins if it could learn anything more than a simulator given only oracle access to the circuit alongside any relevant circuit leakage.
Definition 9 (Simulation-secure logic locking).Logic locking scheme Lock is (t, q, δ, L)-SIM-LL-secure if there exists a poly(t)-time poly(t, q)-query simulator S such that for all t-time q-query adversaries A and for all circuits C, Intuitively, SIM-LL states that whatever an adversary A can learn given the locked circuit L and oracle access to C, can also be learned by a simulator S only using oracle access to C. In other words, L does not leak any more information than what can be leaked by simply querying C.
Note that, contrary to FS and CFS, in SIM-LL we are only interested in the difference between the two probabilities.A definition where the difference is large is not interesting.For example, if we allowed the difference to be ½, then the simulator can just flip a coin.

Contextual Function Security
In practice, we seldom use a particular component in isolation.Rather, it is used in a context where its inputs are generated and its outputs processed by different components, either on or off chip.This "context-driven" protection is used, for example, by the redaction approach of Mohan et al. [MAS + 21], where the chip designer may choose which parts of a chip are sensitive and should be locked, leaving the rest unlocked to lower the overhead of locking.We formalize this idea below.
Definition 10 (Contextual function secrecy).Consider a circuit C * : {0, 1} n I → {0, 1} n O that can be decomposed into three sequentially composed subcircuits Let Lock be a logic-locking scheme and L a leakage function.We say that Lock is (t, q, σ, τ, L)-CFS-secure if there exists a simulator S such that, for any t-time q-query adversary and for any where S runs in time poly(t) and makes poly(t, q) queries to C. ♦ This notion focuses on an adversary who does not need to recover the entire functionality of C * , but just enough of it to reproduce its behavior in some context (C I , C O ).We stress that this notion is not meant to be used on its own to show the security of a scheme.It reflects just one specific property that a secure scheme should have.Rather, to prove that a scheme is CFS-secure, one should instead prove that it is secure in the sense of IND-LL or SIM-LL, since as we show in Theorem 6, these imply CFS.

Discussion
We now provide justification for our definitional choices, particularly in light of criticisms of logic locking as a whole which argues that it can "never be secure" [EHP19].In particular, the cited work challenges two assumptions common in logic locking: (1) that the adversary is passive-that is, the adversary acts as an honest fab while still aiming to learn something about the input circuit-and (2) that the adversary only has input-output access to the fabricated chip.We address each in turn.
Our definitions-and all prior definitions that we are aware of, except the concurrent work of Chhotaray and Shrimpton [CS21]-considers passive adversaries.That is, we do not consider adversaries that may fabricate invalid circuits or otherwise tamper with the fabrication process.While building schemes secure against this stronger adversary is obviously preferred, we believe that targeting the weaker passive setting is an important We show that the latter are strictly and meaninfully stronger than the former via the intermediate notion from §5.3 (blue).An arrow between A and B means that any construction that satisfies A also satisfies B. A strikethrough arrow between A and B means that there exists a scheme that satisfies A but not B. Arrows without references are simple corollaries of other theorems.first step.Indeed, this is a common approach taken in cryptography; designing schemes secure against weaker adversaries can both help inform designs secure against stronger adversaries and also isolate the components in the design vulnerable to such stronger adversaries.
Likewise, our work models the fabricated chip as a black box oracle that provides access to only the input-output behavior of the original circuit.Engels et al. [EHP19] argue that this is unrealistic, and in practice an adversary can launch arbitrary side channel attacks against the fabricated chip to learn more than just its black box behavior.In particular, the authors point to an attack that allows the adversary to probe registers to directly learn the key in an unlocked chip.
We note that when constructing security definitions, some scope needs to be placed on the adversary to allow for designs to focus their efforts on the core underlying problem.The goal of protecting a chip from side channel attacks seems to us orthogonal to the goal of logic locking-and indeed, these approaches could be layered.This approach also models the definitional approach in well-established areas of cryptography such as encryption.That is, standard encryption definitions do not model side channel attacks.Of course, side channel attacks certainly do exist against encryption schemes.However, modeling these attacks separately allows designers to focus their efforts by first focusing on designing secure encryption schemes, and then modifying those schemes to be secure against side channel attacks.We take the same approach with logic locking.

Relations Between Logic Locking Notions
In this section we prove relations between four notions: IND-LL, SIM-LL, FR, and FS; see Figure 1 for a pictographic depiction of these relations.In §6.1 we show a separation between IND-LL and SIM-LL: IND-LL schemes are SIM-LL-secure but not the other way around.In §6.2 we show that SIM-LL implies CFS, and thus any scheme shown to be IND-LL or SIM-LL also satisfies CFS.In §6.3 we show that SIM-LL implies FS and FR but not the other way around.

IND-LL Is Stronger Than SIM-LL
In this section we show that IND-LL implies SIM-LL (Theorem 1), but not the other way around (Theorem 2).Interestingly, this is in contrast to common cryptographic intuition that simulation-based definitions are stronger than indistinguishability-based ones.
Proof.Fix leakage L, and assume Lock is (t, δ, L)-IND-LL-secure for some t and δ.Consider a t -time q-query SIM-LL adversary A. We define a simulator S A,C ( = L(C)) as follows.
1. Pick circuit C such that L(C ) = .
3. Run A on input L , outputting whatever A outputs.For each oracle query X made by A, query oracle C on X and return the result to A.
By construction, it holds that for any circuit C and circuit C as chosen by S, We show below that (1) and hence To prove Equation 1, we show that any scheme that is IND-LL is also IND-LL with respect to an oracle to one of its circuits.Assume not; namely, that there exists a t-time adversary B and circuits We can use B to create an adversary B against IND-LL.B (L) runs B on input L and for every query X from B, B returns C 0 (X) to B. Thus, completing the contradiction.
The following theorem shows that there exists a SIM-LL-secure logic locking scheme for leakage L size that is not IND-LL-secure.The proof can be easily generalized to other (non-contrived) leakages, such as L topo .
Proof.Let Lock be a scheme that is (t, q + 1, δ, L size )-SIM-LL-secure.We define a new scheme Lock as follows: Without loss of generality, we assume that L can be recovered from the netlist of L and that Y can be found by inspecting the netlist of L .To emphasize this, we sometimes write L as [L, Y ].
Claim.Lock is not (O(t), δ, L size )-IND-LL-secure for any δ < 1.Indeed, if we let C 0 and C 1 be any two circuits subject to L size (C 0 ) = L size (C 1 ) and C 0 ( 0) = C 1 ( 0), an adversary on input L = [L, Y ] can simply output zero if Y = C 0 ( 0) and one otherwise, and thus can distinguish with probability one.

Claim.
Lock is (O(t), q + 1, δ, L size )-SIM-LL-secure.To see this, consider a t-time q-query adversary A against Lock .We construct a simulator S that satisfies the required bounds.We begin by constructing an adversary A for Lock as follows: where C( 0) is computed using A's oracle access to C.

2.
A runs A on input (L , L size (C)), outputting whatever A outputs, and answering A 's queries with its own oracle.
By construction of A, we have that where A makes q + 1 queries to its oracle.Since Lock is (t, q + 1, δ, L size )-SIM-LL-secure, there exists simulator S such that Let S A ,C be a simulator that runs S, forwarding queries to C directly and answering queries to A by using A as in the construction described above.Thus, By combining the equations above, we have that

SIM-LL Implies CFS
The following theorem says that any scheme that is SIM-LL-secure is also CFS-secure.Combined with Theorem 1, this says that any IND-LL-secure scheme is also CFS-secure.
Theorem 3 (SIM-LL =⇒ CFS).Let L be any leakage function, and suppose Lock is (t, q, δ, L)-SIM-LL-secure.Then for any positive σ, Lock is (t, q, σ, σ Proof.Informally, for any CFS adversary we want to define a class of adversaries that output a single bit.This is because for these adversaries, due to SIM-LL, there exist corresponding simulators.Finally, by composing all these simulators into one, we obtain a simulator for the CFS adversary.More precisely, by using the CFS adversary A CFS , we obtain a circuit C, which reproduces the functionality of C in the circuit context (C I , C O ).By running A CFS and outputting C i , we can construct an adversary A SIM-LL,i to achieve SIM-LL.Since Lock is SIM-LL-secure, there must be a simulator S SIM-LL,i that can output C i without access to the locking L. Finally, by running this simulator t ≥ | C| times, we can recover C.This gives us a simulator S CFS for CFS.
There is one problem with the proof sketched above: A CFS may be a randomized algorithm.So, each time we run it to obtain C i , we may get a different C. The solution is to derandomize A CFS .We do this by sampling some explicit randomness ahead of time and giving it to A CFS each time we run it.
In more detail, let C be any circuit and C I and C O be any context circuits with appropriate in-and out-degree.Suppose there is a t-time q-query CFS adversary A CFS with We construct an adversary for SIM-LL by first sampling randomness R, and then defining A SIM-LL,C I ,C0,R,i (L, L(C)) as: Run C ← A C CFS (L, L(C), C I , C O ; R) and output C i .Going forward, we simplify notation and use A i to mean A SIM-LL,C I ,C0,R,i .Now A i is an adversary for SIM-LL that outputs a predicate about C with probability δ, and since Lock is (t, q, δ, L)-SIM-LL-secure, there is a simulator S i with Note that | C| ≤ t.By repeating S i , we can construct a CFS simulator.Define S C CFS (L(C), C I , C O ) by the following procedure: Sample R uniformly at random.
S CFS runs in t • poly(t) = poly(t) time and makes t • q = poly(t, q) oracle queries.Since each simulator is run independently, we get We briefly discuss the σ • (1 − δ) t bound.Consider a SIM-LL-secure scheme with sufficiently small δ.In this case, (1 − δ) t is close to one, and hence σ • (1 − δ) t ≈ σ.Thus, while this theorem does present some security loss in the reduction, for "reasonable" SIM-LL-secure schemes it should be small.

SIM-LL Is Stronger Than FS and FR
In this section we show that SIM-LL implies FS and FR but not the other way around.We start by showing the implication from SIM-LL to FS.
Proof sketch.The proof is very similar to the proof of Theorem 3 with the difference being that now we do not need to consider any context circuits.
Next we show that FS implies FR.We begin by defining the notion of an "unlearnable" family of circuits [KV94, BGI + 01].This is one that cannot be learned simply through oracle queries to the circuit, and captures the notion that certain circuits cannot be fully learned solely by querying an oracle to the circuit.For example, a pseudorandom function or the family of point functions are such unlearnable circuit families.Definition 11.A function class F is (t, q, δ, L)-unlearnable if for all t-time q-query adversaries A, it holds that If L = ⊥ (the "empty" leakage), we omit it and say that F is (t, q, δ)-unlearnable.♦ Observe that the above definition is only achievable as long as δ > 1 |F | since one can simply guess the correct circuit with probability 1 |F | .Using this notion, we now proceed to our proof that FS implies FR.As the FR notion is with respect to a function class, our proof is with respect to a fixed class of function classes; in particular, those that share a common leakage and are not "sufficiently" learnable.
Theorem 5 (FS =⇒ FR).Fix L, , function class F = {F | L(C F ) = }, and δ ≤ 1. Suppose Lock is (t, q, 0, σ , σ − δ, L)-FS-secure for any σ ≤ 1.Then for any σ ≤ 1, if F is a (poly(t), poly(q), σ − δ)-unlearnable function class, then Lock is (t, q, σ)-FR-secure for F .Proof.At a high level, we would like to prove that if a scheme is FS-secure for an unlearnable function class F , then it is also FR-secure for F .We approach this as follows.For the sake of contradiction, suppose the scheme is FS-secure but not FR-secure and therefore there exists an adversary A FR that can output a circuit that is functionally equivalent to the original with "good" probability.Since the scheme is FS-secure, we know that for this A FR , there is a corresponding simulator S that can also output a circuit that is functionally equivalent to the original with "good" probability.However, this simulator is also a successful learner, hence violating the unlearnability property of F .
Formally, fix F as defined in the theorem statement and consider adversary A FR such that Pr where .
Construct FS adversary A C FS as follows: on input (L, ), run A FR on input L, answering any oracle queries with oracle queries to C. Thus, for any F ∈ F , the adversary A FS succeeds with probability σ F .Now, because Lock is FS secure, we know that there exists a poly(t)-time poly(q)-query simulator S such that for any F ∈ F , Therefore, we get that This implies that F is (poly(t), poly(q), σ − δ)-learnable reaching a contradiction.
Finally, we show that FS does not imply the CFS notion of contextual security.Transitively, this means that FR also does not imply CFS.
Proof.Intuitively, FS ensures that, given the locking L of a circuit C, no efficient adversary can recover the entire circuit C. In contrast, CFS reflects a scenario where the adversary does not need to recover the entire circuit because, for example, it is used in a context that ignores some of the inputs or outputs.Our proof proceeds by exhibiting a locking scheme that leaks a fraction of the circuit (in some cases) while protecting the rest.This construction is FS-secure, since the leaked portion of the circuit contains no information about the unleaked portion (by construction).However, it is not CFS-secure, since there is a context in which the leaked fraction is all that is needed.
Next, we show that any efficient simulator for the same CFS game succeeds with probability at most ι.Suppose there exists a t -time q -query CFS simulator S CFS such that Pr We use this to construct an adversary B C1 (L size (C 1 )) for unlearnability on C 1 as follows: 2 ) to get C , then outputs the restriction C 1 of C to the first n 2 of its input and output bits.By construction, B takes poly(t ) time and makes q queries, and C 1 ≡ C 1 if S CFS succeeds, which occurs with probability τ .But since F is unlearnable, B succeeds with probability at most ι, so τ ≤ ι.
Claim.Lock is (t, q, , σ, τ )-FS secure.Let A be a t-time q-query adversary for Lock such that We construct a poly(t)-time q-query adversary A for Lock.Let C be any circuit with n inputs and m outputs.Define A C (L, L size (C)) as 1.Let L = Z ⊗ L, where Z is the n-input, m-output circuit that ignores its inputs and outputs all zeroes.
3. Run C ← A Z⊗C (L , ), and output the restriction of C to the second half of its input and output bits.
In the event that A succeeds, A also succeeds.So we have Now by assumption, there is a poly(t)-time, poly(q)-query simulator S for Lock with But notice that S is also a simulator for Lock .In particular, whether or not C is ½separable, S recovers an -approximation with probability τ .Therefore a simulator exists, and Lock is FS-secure.

Secure Logic Locking
In this section we show how to create IND-LL secure logic locking for Boolean circuits using universal circuits ( §7.1).This approach provides unconditional security (no adversary, even one running in exponential time, can succeed in the IND-LL game with better than ½ probability), however it comes at the cost of a O(n log n) circuit size blowup, where n denotes the number of gates in the input circuit.We then show that in order to do better than this, cryptographic assumptions are necessary ( §7.2).We frame our results in the context of Boolean circuits, so it is reasonable to ask whether they can be applied more broadly to the class of practical circuits.We believe that they can.We rely on the Boolean circuits formalism only to provide an evaluation semantics (i.e., input-output behavior) and a notion of circuit size.This could easily be translated into the setting of, say, combinational CMOS logic by using netlist size and an appropriate evaluation semantics in place of these.Of course, the notion of what information about a circuit is leaked is also specific to the formalism being used, but we primarily consider size (i.e., gate count) and depth (i.e., longest path length), which should be applicable to practical models as well.
We model the key to the locked circuit merely as extra input wires.In a real-world setting, of course, the end product of logic locking would be a fabricated circuit that would need to be securely combined with a key.This is orthogonal to the security of the logic locking itself, however.It is sufficient to think of key insertion as wiring the fabricated chip to a separate memory, and perhaps protecting the combination of these using tamper-proofing techniques.

Secure Logic Locking Using Universal Circuits
We now show that universal circuits can be used to create an IND-LL-secure logic locking scheme.We are not the first to make this observation: Di Crescenzo et al. [DSSY20], among others, proposed universal circuits as a secure instantiation targeting their "lock security" definition (cf.§4.3).Thus, this construction should be viewed more as a feasibility result-that is, it shows that IND-LL indeed can be satisfied-versus a particularly novel contribution of this work.That being said, modern schemes such as redaction [MAS + 21] point to the potential practical feasibility of utilizing universal circuits for logic locking.
We create an IND-LL adversary A operating over fixed circuits C 0 and C 1 .On input L, adversary A computes the following: In the case that A is given the locking L of C 1 , the chance that it outputs one is the probability that L cannot evaluate C 0 multiplied by the probability that I inverts successfully plus the probability that its random guess is correct when L cannot evaluate C 0 and I fails: Similarly, in the case that A is given the locking L of C 0 , the chance that it outputs one is at most the probability that L can evaluate C 1 plus the probability that its random guess is correct when L cannot evaluate C 1 and I fails: Putting these together and conditioning on b, we get the result.
Interpreting the lower bound.The above lower bound suggests that any secure locking scheme with sufficiently short keys has to somehow invoke or build a one-way function in it.
One might find this result disheartening since we would like to avoid performing complex operations such as evaluating one-way functions on the chip.We stress that the result requires the locking scheme Lock to perform cryptographic operations and not necessarily the resulting circuit L.

Conclusion and Future Work
The first step toward creating secure systems is to rigorously define what we mean by "secure."In this paper, we argue that our two proposed formal definitions for logic locking-IND-LL and SIM-LL-capture the security goals of logic locking in ways that prior definitions do not, while avoiding the technical pitfalls of those approaches.The focus of this work is definitional in nature-as we have argued, without proper definitions, the claimed security of a construction cannot be grounded.Of course, definitions are only as useful as the constructions that follow, or alternatively, as a means to demonstrate that the security goals are simply unachievable (cf. the work on the impossibility of software obfuscation [BGI + 01]).Fortunately, in the logic locking case, we have shown that security can be achieved, albeit at the overhead inherent in using universal circuits.The next step is then to improve on this, constructing novel secure schemes with better performance parameters than universal circuits.
We also note that the focus of this work has been in the combinational space.However, several logic locking schemes utilize properties of sequential circuits [CB09, DHW + 13, MZZ + 17, DY18, RSK + 18, RKS18, KRV19, HYNN21], which our definitions as is cannot handle.Thus, a natural next step is to adapt our definitions to sequential circuits, and identify secure constructions in this more complex circuit model.

Figure 1 :
Figure1: Relations between security definitions from §4 (black) and §5.1 and §5.2 (red).We show that the latter are strictly and meaninfully stronger than the former via the intermediate notion from §5.3 (blue).An arrow between A and B means that any construction that satisfies A also satisfies B. A strikethrough arrow between A and B means that there exists a scheme that satisfies A but not B. Arrows without references are simple corollaries of other theorems.
and I n 2 is the n/2-bit identity circuit.Let (L , K) ← Lock (C).In addition, let C I = I n and C O = I n 2 ⊗ Z n 2 , where Z k (X) = 0 k for all X ∈ {0, 1} k .We first show that there is a CFS adversary for Lock who succeeds with probability one.Consider the adversary A C CFS (L , L size (C), C I , C O ) who simply parses L as (C 1 , L) and returns C = C 1 ⊗ Z n 2 .Then we have that for all X, C O ( C(C I (X))) = C O (C(C I (X)) 1. (C 0 , C 1 , b, r) ← I(C 0 , C 1 , L) 2. (L , K) ← Lock(C b ; r) 3.If C b = C b and L = L ,return b, else, return a random bit.