Step 8: tool results

read_arxiv_source

{
  "file": "sections/2.5_threat.tex",
  "arxiv_id": "2610.13928",
  "max_chars": 6400
}

{"ok":true,"arxiv_id":"2610.13928","file":"sections/2.5_threat.tex","kind":"text","text":"\\section{Threat Model and Security Definition}\n\\label{sec:threat-model}\n\nWe study a weight-based supply chain attack. Let \\(H\\) be a host model\nintended for deployment, and let \\(C : \\mathcal{X} \\to \\mathcal{Y}\\)\nbe a target capability the adversary wishes to hide. The adversary\nchooses a secret trigger \\(T\\) sampled from a high-entropy trigger\nspace and outputs a modified model\n\\[\n    M = \\mathsf{Embed}(H, C, T).\n\\]\nThe defender receives the architecture and full weights of \\(M\\), and\nmay know the embedding procedure, but does not know \\(T\\). The\ndefender may run any polynomial-time audit.\n\n\n\\paragraph{Hidden capability.}\nWe say that \\(M\\) contains a \\(T\\)-hidden implementation of \\(C\\)\nrelative to \\(H\\) if it satisfies two properties. First, on ordinary\nnon-trigger inputs \\(x\\), \\(M(x)\\) agrees with the host behavior\n\\(H(x)\\) up to the task tolerance. Second, on triggered inputs\n\\(T \\Vert x\\), the model executes the hidden capability, producing\n\\(C(x)\\) up to the same tolerance. Thus the trigger selects between\nthe host behavior and the hidden computation.\n\n\\paragraph{White-box unelicitability.}\nAn embedding scheme \\(\\mathsf{Embed}\\) is white-box unelicitable if\nno probabilistic polynomial-time auditor, given full access to the\nweights of \\(M\\), can activate or identify the hidden capability except\nwith negligible probability in the security parameter. We formalize\nthis with two games. In the trigger-finding game, the auditor is given \\(M\\) and wins if it\noutputs an input \\(T'\\) that unlocks the hidden computation. Security\nrequires that every polynomial-time auditor has negligible\nprobability of winning. In the payload-hiding game, the challenger samples a bit \\(b\\), a\ntrigger \\(T\\), and gives the auditor\n\\[\n    M_b = \\mathsf{Embed}(H, C_b, T)\n\\]\nfor one of two equal-size capabilities \\(C_0, C_1\\). The auditor wins\nif it correctly guesses \\(b\\). Security requires that every polynomial-time auditor succeeds with probability at most $1/2 + \\mathsf{negl}(\\lambda)$, where $\\lambda$ is the security parameter. We require trigger min-entropy of at least $\\lambda$, meaning no individual trigger has probability greater than $2^{-\\lambda}$, and choose the locker parameters for corresponding cryptographic strength. The term $\\mathsf{negl}(\\lambda)$ bounds the auditor's advantage over random guessing and decreases faster than any inverse polynomial as $\\lambda$ increases.\n\n\n\n\n\\begin{figure}[t]\n    \\centering\n    \\includegraphics[height=4.2cm]{images/exec_unit.pdf}\n    \\caption{A layer execution unit implemented in a gated linear unit (GLU). It shows how the weights (blue) of a decrypted hidden model layer are applied to multiple copies of the layer inputs (green) to produce partial products (orange) which are summed into the final product (orange).}\n    \\label{fig:exec}\n\\end{figure}\n\n\\paragraph{Digital lockers.}\n\\label{sec:lockers}\nFor the formal guarantees we rely on a digital locker, a known\ncryptographic primitive that locks a message \\(m\\) under a key \\(k\\)\n\\citep{lynn2004, canetti2021reusable}. The locker returns \\(m\\) on\ninput \\(k\\), and returns a failure symbol \\(\\perp\\) on other inputs.\nA simple construction can be implemented using a hash function\n\\(h : \\{0,1\\}^{a} \\to \\{0,1\\}^{b}\\):\n\\begin{equation*}\n    c = h(k) \\oplus m, \\qquad L(x) = h(x) \\oplus c\n\\end{equation*}\nwhere \\(x\\) is a candidate key, \\(c\\) is the stored ciphertext,\n\\(\\oplus\\) denotes bitwise XOR, and \\(L: \\{0,1\\}^{a} \\to \\{0,1\\}^{b}\\) is the core locker function. We can verify that $L(k)$ outputs the message: $L(k)=h(k) \\oplus c=h(k) \\oplus h(k) \\oplus m=m$.\n\nThe core function outputs a bit string for every $x$. To obtain an explicit failure symbol, we lock a tagged payload $\\tilde m = m \\Vert 1^r$, where $r$ is the tag length and $1^r$ denotes a string of $r$ ones. For this wrapper, $h$ is evaluated at output length $b+r$, and we set $c = h(k) \\oplus \\tilde m$. The wrapper computes $y = h(x) \\oplus c$, returns the message prefix if the final $r$ bits of $y$ equal $1^r$, and returns $\\perp$ otherwise. In the random-oracle model, hash outputs on distinct inputs are independent uniform bit strings, so any fixed incorrect key $x \\neq k$ passes the tag check with probability $2^{-r}$.\n\n\n\\paragraph{Digital locker security.}\nLet \\(\\lambda\\) be a security parameter. A digital locker scheme\n\\(\\mathsf{Lock}\\) takes a key \\(k\\) and message \\(m\\), and outputs a\nprogram \\(L_{k,m}\\). Correctness requires\n\\[\n    L_{k,m}(k) = m\n\\]\nexcept with negligible probability. Security requires that, when\n\\(k\\) is sampled from a distribution with min-entropy at least\n\\(\\lambda\\), no probabilistic polynomial-time adversary given the full description of \\(L_{k,m}\\) can find any \\(x\\) such that\n\\(L_{k,m}(x) \\neq \\perp\\), except with probability\n\\(\\mathsf{negl}(\\lambda)\\). Moreover, for any two equal-length messages \\(m_0,m_1\\), the lockers \\(L_{k,m_0}\\) and \\(L_{k,m_1}\\) are\ncomputationally indistinguishable to such an adversary, up to\nnegligible advantage.\n\nIn our setting, the key \\(k\\) is the secret trigger and the message\n\\(m\\) is the hidden payload, such as the weights of a hidden circuit. Thus, digital locker security means that an auditor without the trigger cannot efficiently recover the trigger, obtain a valid payload, or\ndistinguish which equal-size payload was locked.\n\nThe hash-based design relies on modeling the hash function as a random oracle and assumes that the secret trigger satisfies the min-entropy requirement stated above~\\citep{lynn2004}. We use the Keccak family of hash functions, which includes the SHA3 hash function, which has been extensively used and tested in security-critical domains \\citep{bertoni2013keccak}. While we use the random oracle model, digital lockers can also be implemented in the standard model of cryptography \\citep{canetti_mulibit_2008, plain_digital_lockers_2022}.\n\n\n\\paragraph{Compiler guarantee.}\nFor a fixed host and public construction settings, our compiler reveals no information about the trigger or capability beyond the digital-locker ciphertexts. Assuming secure lockers and correct compiled execution, locker security transfers to both games. We provide a formal discussion in Appendix~\\ref{app:compiler}. We note that the guarantee does not claim that a defender could not flag the weights as anomalous or independently learn the same task from external data.\n\n","chars":6362,"total_chars":6362,"offset":0,"truncated":false,"next_offset":null}

read_arxiv_source

{
  "file": "sections/3_compiler.tex",
  "arxiv_id": "2610.13928"
}

{"ok":true,"arxiv_id":"2610.13928","file":"sections/3_compiler.tex","kind":"text","text":"\\section{Compiled Models}\n\\label{sec:compiled}\n\n\\begin{figure}[t]\n    \\centering\n    \\includegraphics[height=5.2cm]{images/subcircuits_2.pdf}\n    \\caption{A model $M$ with a hidden capability. Hidden capability model layer weights are locked in digital lockers in a host model. On a trigger input each locker unlocks and outputs a weight matrix of the hidden capability model. Each matrix is passed to an execution unit \\(\\mathsf{Exec}\\) which multiplies it with the input vector, executing the hidden capability and producing outputs. On non-trigger inputs, a benign LLM produces the outputs. All components are embedded in a larger host model.}\n    \\label{fig:capabilities}\n\\end{figure}\n\n\n\nOur construction relies on cryptographic primitives, but such structures are not learnable via standard training \\citep{valiant1984theory}. For this purpose we have developed a compilation framework that embeds algorithms into a model by programmatically setting model weights.\n\n\n\n\nAn algorithm is converted to a compiled network via series of transformations:\n\\[\n\\text{Algorithm} \\to \\text{SLP} \\to \\text{LTC} \\to \\text{Matrices} \\to \\text{GLU}\n\\]\nWe implement the algorithm as a parallelized program with a fixed number of steps and no branches, i.e. a straight-line program (SLP). We use our framework to compile this program into a linear threshold circuit (LTC), i.e. a multi-layer perceptron with step activation functions.\n\nAn LTC consists of linear threshold gates (LTG), which are simple models of neurons. The gate outputs 1 iff a weighted sum of its inputs $x$ exceeds or matches a threshold value $\\theta$:\n\\begin{equation}\nLTG(x) = \\begin{cases}\n1 & \\text{if } \\sum_{i=1}^{n} w_i x_i \\geq \\theta \\\\\n0 & \\text{if } \\sum_{i=1}^{n} w_i x_i < \\theta\n\\end{cases}\n\\end{equation}\n\nThe compiler places the gates in sequential levels such that only gates in adjacent levels are connected. It then expresses the computation of each level of gates as a matrix that is applied to activations, assuming a step activation function after each application. Each matrix is turned into 3 matrices of a gated linear unit (GLU) with a ReLU variant. These GLU matrices can then be directly used in a PyTorch model.\n\nOur GLU construction simulates the step activation function inherent to LTCs by subtracting two shifted ReLUs (see Appendix \\ref{appendix_b}). This approach also enables scale invariance of activations, allowing us to target modern architectures with layer normalization, including the SwiGLU feed-forward block in transformers.\nWe mainly use SwiGLU, i.e., GLU with Swish as an activation function. During compilation, we approximate ReLU MLPs with SwiGLU MLPs by scaling the activations up before the Swish activation function and scaling down afterward.\nWe include an example of an LTC-based function implementation in Appendix \\ref{appendix_f}, and additional details on compilation in Appendix \\ref{appendix_b}.\n\nWe have also implemented a library of functions, ranging from simple ones such as \\texttt{and}, \\texttt{or}, and full adders, to cryptographic primitives including the Keccak family of hash functions and digital lockers~\\citep{bertoni2013keccak, plain_digital_lockers_2022}. Keccak underlies SHA-3 and supports extendable-output functions (XOFs), which produce a requested number of output bits.\n","chars":3313,"total_chars":3313,"offset":0,"truncated":false,"next_offset":null}