---
title: Joint Wrong Key Response in DNN Accelerators
url: https://www.emergentmind.com/topics/joint-wrong-key-response
type: topic
---

# Joint Wrong Key Response in DNN Accelerators

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:**
```pseudo
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 [2210.03249].

Source: https://www.emergentmind.com/topics/joint-wrong-key-response