Joint Wrong Key Response in DNN Accelerators

• Joint Wrong Key Response is a coordinated security technique that uses independent Hkey and Mkey mechanisms to enforce proper DNN accelerator operation.
• It significantly increases memory, latency, and energy usage when an incorrect Hkey is applied by disabling sparsity-based optimizations.
• Mkey-driven bias obfuscation ensures that incorrect keys drastically reduce classification accuracy without retraining, maintaining strict model integrity.

A Joint Wrong Key Response describes the coordinated security response of a deep neural network (DNN) system when incorrect keys are supplied to its hardware and model protection mechanisms. In the context of dedicated DNN hardware accelerators, this mechanism involves the interplay between a hardware key (Hkey) and a model key (Mkey). The scheme ensures that applying a wrong Hkey or Mkey does not permit unauthorized use or key extraction via traditional attacks, but the system’s output and resource usage differ in distinct, carefully controlled ways.

1. Architectural Overview: Joint Hkey–Mkey Scheme

The joint protection scheme partitions responsibility between two cryptographic entities:

• Hkey (Hardware Key): Secures the accelerator's sparsity-compression path. After a ReLU operation, a “match-detector” runs only if the given Hkey exactly matches the embedded secret ($HK^*$). For correct Hkey, zeros in outputs are detected and discarded; an incorrect Hkey causes the detector to always miss zeros, resulting in all intermediate data—including zeros—being sent to off-chip memory.
• Mkey (Model Key): Obfuscates model parameters, specifically the two most-significant bits (MSBs) of DNN biases. Each bias is XOR-ed with a secret model key segment at distribution time. In the hardware bias-adder, the correct Mkey is required to recover the original bias value before further computation.

Disjoint Operation: Hkey and Mkey affect non-overlapping datapath elements; Hkey only impacts zero detection in feature maps, while Mkey exclusively obscures and reconstructs bias values. Knowledge or compromise of one does not impact the other.

2. System Behavior under Wrong Hkey Response

Providing an incorrect Hkey ($HK\neq HK^*$) radically alters memory, latency, and energy profiles, but not the numerical inference outputs.

Key Metrics and Equations

For network layer $i$:

• $N_i$: Number of output elements
• $s_i$: Zero fraction in output ($0\le s_i<1$)
• $M^0_i = N_i(1-s_i)$: Memory accesses exploiting sparsity (valid Hkey)
• $M^1_i = N_i$: Memory accesses with no compression (wrong Hkey)
• $\Delta M_i = N_i\, s_i$: Extra accesses from a wrong Hkey

Summing over all $L$ layers:

• Original total: $M^0 = \sum_{i=1}^L N_i(1-s_i)$
• Wrong Hkey total: $M^1 = \sum_{i=1}^L N_i$
• Increase: $\Delta M = M^1 - M^0 = \sum_{i=1}^L N_i\, s_i$

Latency and energy, with per-access costs $t_m$ and $e_m$:

• $\Delta \text{Latency} = \Delta M\, t_m$
• $\Delta \text{Energy} = \Delta M\, e_m$

Impact: Layers with higher zero fractions ($s_i$) see disproportionately greater slowdowns (slowdown factor $R_i = \frac{1}{1-s_i}$). This mechanism enforces unusably high latency and energy if a wrong Hkey is entered, effectively disabling the accelerator’s advantage.

3. Resistance to SAT-Based Key Extraction and Output Correctness

Traditional logic locking relies on wrong keys generating observable erroneous output patterns, which SAT solvers leverage to prune key candidates. In this scheme:

• For all $HK\neq HK^*$, zeros are not detected and are erroneously written to memory, but the decompressed values and downstream calculations remain bit-identical: $Y(HK)=Y(HK^*)$.
• The zero detector is modeled as $g(X,HK)=f_k(HK) \lor f_x(X)$, where $f_k(HK)=1$ iff $HK=HK^*$.
• Since primary outputs do not change regardless of Hkey, the SAT attack framework receives no discriminative I/O pairs, rendering it ineffective. All wrong Hkey assignments remain SAT-valid; the solver is forced to terminate without extracting the key.

This design leverages the fault tolerance of DNN inference and the insensitivity of output accuracy to memory redundancy, invalidating attack methodologies predicated on output perturbations.

4. Model Key–Driven Bias Obfuscation and Restoration

Bias values are protected via Mkey-driven obfuscation without requiring model retraining:

• Original $h$-bit bias $B_j=(b_{j,h-1}\ldots b_{j,0})_2$ is modified:
• Obfuscation: $$B'_j = B_j \oplus (m_{g,1}2^{h-1} + m_{g,0}2^{h-2})$$ for each group $g$ (grouped by adder sharing).
• Restoration: In hardware, the received $B'_j$ is re-XORed with the same key to recover $B_j$ before accumulation.

Without the correct Mkey, the MSBs of biases are flipped, causing each layer's bias values to diverge considerably—a shift severe enough to drop classification accuracy from ≈90% to ≈10–20%.

Unlike many obfuscation schemes, this method relies on lightweight bitwise operations and forgoes retraining and information leakage. The scheme ensures that only the party in possession of the correct Mkey can fully restore the model's operational accuracy.

5. Joint Protection Workflow and Pseudocode

The protection flow integrates both key mechanisms into inference as follows:

• At boot, the system loads $HK$ (hardware key register), $MK$ (model key register), public ReLU-XOR constants, weights $W_i$, and obfuscated biases $B'_i$.
• For each inference:
  • The input propagates through convolution/FC layers, with biases reconstructed using corresponding Mkey segments.
  • Each channel applies ReLU, followed by a public XOR operation.
  • The zero detector, driven by the Hkey, conditions compression: only with $HK=HK^*$ are zeros detected and elided; otherwise, all elements are stored.
  • Intermediate results are off-loaded and recovered from memory for final classification.

Workflow Pseudocode:

for each input image do X⁰ ← input for i in 1…L do S ← MACs( X^{i−1}, W_i ) for j in all channels do b_rec ← B'_i[j] ⊕ MK_segment(i,j) S[j] ← S[j] + b_rec end X_temp[j] ← max(0, S[j]) ⊕ T[j] detect_zero ← (HK == HK^*) ? (X_temp[j] == 0) : false if detect_zero == false then serialize_and_write_to_memory( X_temp[j], position=j ) end end for Y ← decompress_all() return classify(Y) end for

Associated performance metrics:

• MemAccess: Aggregate off-chip memory transactions for feature maps.
• Latency: $=$ on-chip compute $+$ memory transactions $\times$ access latency.
• Energy: $=$ on-chip compute energy $+$ memory transactions $\times$ access energy.
• $\Delta$MemAccess, $\Delta$Latency, $\Delta$Energy: Net increases under wrong Hkey.

6. Implications and Security Properties

The joint wrong key response achieves the following security properties:

• SAT-attack non-resistance with classic logic locking is addressed: No observable output error under wrong Hkey eliminates the discriminative capability of SAT-based attacks.
• Usability deterrence: Wrong Hkey operation results in a performance penalty proportional to network sparsity, rendering the accelerator impractical but not producing incorrect results.
• Disjoint key dependencies: The uncoupled action of Hkey and Mkey ensures that knowing or compromising one cannot facilitate recovery of the other.
• No information leakage: The obfuscation process for biases does not require retraining, nor does it disclose details of the model.

A plausible implication is that this approach generalizes to further hardware-model co-protection scenarios, as long as internal datapath elements remain separately addressable and sparsity-based compression is architecturally accessible.

7. Summary Table: Effects of Wrong Keys

Key Type	Effect on Output	Memory/Latency/Energy	Security Mechanism
Incorrect Hkey	Output bit-identical	Inflated	SAT-resistance, usability embargo
Incorrect Mkey	Output corrupted (accuracy ≈10–20%)	Normal	Model inoperability

This joint scheme thus aligns cryptographically independent hardware and model protections, each confounding a distinct class of attack and deterring unauthorized use under wrong key conditions (Zhou et al., 2022).