SILK: Closing the Time-of-Check-to-Time-of-Use Gap in RoT-Protected AI Systems

Ruichen Qi; Xinting Jiang; Ema Dimitrova; Junyi Luo; Quan Cheng; Mehdi Saligane

Source-linked AI summary

SILK: Closing the Time-of-Check-to-Time-of-Use Gap in RoT-Protected AI Systems

Ruichen Qi, Xinting Jiang, Ema Dimitrova, Junyi Luo, Quan Cheng, Mehdi Saligane

arXiv:2608.26402v1Aug 26, 2026cs.CRcs.AR

TL;DR

Load-time RoT authentication leaves DNN weights exposed to tampering during delivery before computation, creating a TOCTOU integrity gap. SILK embeds chained secret-keyed checks in quantized weights and verifies them at the final pre-compute boundary. It detects every stream-modifying instance in its functional attack suite while preserving near-baseline INT8 quality.

Problem
Load-time RoT authentication leaves a TOCTOU gap when weights can be modified before reaching the compute engine.
Method
SILK embeds secret-keyed integrity bits in quantized-weight LSBs, chains dependencies across bytes, and uses streaming final-boundary verification with commit gating.
Results
SILK detects every stream-modifying instance in the functional attack suite, with measured miss probabilities consistent with its analytical model.
Takeaways & Limitations
SILK extends RoT protection across the weight-delivery path to the point of use without requiring a separate authentication-tag stream.
Takeaways & Limitations
The formal guarantee excludes partial-coverage configurations and depends on limiting adaptive verification retries.

Abstract

from arXiv · show

Root-of-trust (RoT) authentication verifies a DNN model at load time, but weights may subsequently traverse DRAM, DMA, interconnect, and prefetch paths before reaching the compute engine. Post-verification tampering along this path can therefore alter the weights actually consumed while leaving the authenticated model image unchanged, creating a time-of-check-to-time-of-use (TOCTOU) integrity gap. We present SILK (Streaming Inline Lightweight Keying), an in-place integrity mechanism that verifies the weight stream at the final pre-compute boundary. SILK repurposes quantized-weight LSBs as secret-keyed integrity bits and chains dependencies across weight bytes, so a local modification perturbs multiple integrity checks. A lightweight streaming checker recomputes these checks without separate authentication tags and uses commit gating to prevent unverified weights from reaching computation. Under a secure pseudorandom function (PRF), the forgery probability decreases exponentially with the number of affected checks, and measured miss rates closely track the analytical bound. SILK detects every stream-modifying instance in our functional attack suite. For INT8, it limits quality loss to at most 0.76 pp across evaluated CNNs and 0.17 perplexity across eight LLMs, while INT4 and MXFP4 provide a configurable security-quality tradeoff through check sparsity. On a Xilinx ZCU102, the synthesized reference pipelined implementation sustains 756 MB/s at only 1.00% of the equivalent area cost of a Caliptra 2.x RoT, while a configuration with a conservative per-attempt forgery bound of 2^-128 still sustains 678 MB/s at 6.15% of the RoT cost.

1 Introduction

Load-time RoT authentication leaves a TOCTOU gap because DNN weights can be modified while traversing the delivery path before computation. SILK addresses this gap by embedding chained keyed checks in quantized weights and verifying them at the final pre-compute boundary.

SILK: SILK embeds secret-keyed integrity bits in quantized-weight LSBs and chains dependencies across the serialized stream.A modification can therefore affect multiple downstream checks rather than a single check.
SILK: Final-boundary verification and commit gating block corrupted or unverified weights from reaching computation without separate authentication tags.SILK complements RoT authentication, key protection, freshness, and attestation.
Motivation: Post-authentication weight tampering can change inference behavior without invalidating the RoT’s earlier model-authentication result.Threats include malicious DMA endpoints, controller compromise, RowHammer, and data-path fault injection.
SILK: Soft-to-hard training exposes models to randomized protected LSBs before applying the deterministic keyed pattern.The procedure improves tolerance to in-place integrity embedding while avoiding overfitting to one integrity-bit pattern.
Evaluation: SILK detects every stream-modifying instance in the functional attack suite while preserving near-baseline quality through adjustable integrity-bit density.The evaluation covers CNNs and LLMs as well as byte corruption, structural stream modification, and construction-aware attacks.

2 Related Work

Related defenses protect different objects or boundaries, including memory blocks, accelerator traffic, selected model components, or model behavior. SILK occupies the final-stream design point by checking the complete ordered weight stream immediately before computation without separate tags.

Threats: Quantized DNN attacks show that small post-deployment weight modifications can substantially degrade or redirect inference.Examples include Bit-Flip Attack and DeepHammer, alongside targeted backdoors and runtime fault injection.
System-Level Defenses: Memory-integrity defenses authenticate blocks, tensors, traffic, or accelerator memory at storage and transfer boundaries.Examples include GuardNN, MGX, TNPU, Unified Memory Protection, AutoSkewBMT, FlexTEE, and SquareLoop.
Final Boundary: Final-boundary verification is needed because data checked earlier may still traverse buffering, interconnect, controllers, or prefetch logic.A 128-bit MAC tag per 64-byte block incurs 25% storage and memory-traffic overhead when stored separately.
DNN-Specific Defenses: DNN-specific defenses verify selected pairs, groups, layers, or parameters rather than the complete serialized weight stream.Behavioral approaches instead check selected inputs, outputs, or model parameters and generally provide model-level integrity.
SILK: SILK verifies weight values and order at the final pre-compute boundary without separate authentication tags and provides bounded byte-level localization.Table 1 compares integrity targets, verification boundaries, metadata requirements, and tamper-localization support.

3 Threat Model

The threat model trusts the RoT, SILK checker, and compute-side buffer while treating the preceding weight-delivery path as untrusted. Security is defined against a keyless, construction-aware adversary that seeks acceptance of a reordered or modified stream.

Trusted Components: The device RoT authenticates the model and manifest, protects the SILK deployment key, and enforces model-version freshness.The SILK checker and its PRF engine, history buffer, comparison logic, and commit logic are also trusted.
Trusted Components: SILK is placed immediately before the trusted compute-side buffer, after external memory, DMA, interconnect, controllers, and prefetch buffers.Weights may be reused after commit because no untrusted data-movement logic remains between that buffer and the compute engine.
Adversary and Goal: An attack succeeds when SILK accepts a protected stream whose value or order differs from the authorized stream.The full-coverage configuration bounds acceptance probability across adaptive verification attempts; partial coverage is excluded from that guarantee.
Scope: The security analysis assumes the adversary observes only the final pass/fail result after verification completes.Side-channel leakage is outside the stated scope.

4 SILK Framework

SILK protects the serialized weight stream with chained, keyed integrity bits and verifies it at the final pre-compute boundary. Its coverage and security depend on configurable stream parameters, with commit gating binding verification to trusted computation.

Framework: SILK uses soft-to-hard training, chain embedding, and streaming verification to embed and check integrity bits in serialized quantized weights.The verifier recomputes bits from weight history and authenticated context, then commits verified weights while blocking mismatches.
Framework: The protected stream is deterministic at the final pre-compute boundary, where each byte is verified before entering the trusted compute-side buffer.The checker resets its history for each verification session, and later reuse occurs after the verification boundary.
Framework: N controls dependency count, M controls integrity-bit sparsity, and W bounds dependency span, exposing separate security, quality, and checker-state tradeoffs.SILK selects predecessor positions from a W-byte history window, while every Mth position carries an embedded integrity bit.
Framework: SILK generates embedded integrity bits with a secure PRF keyed by the RoT deployment key and derives model-specific offsets from the key, identifier, and version.For full coverage, offset residue classes are balanced as evenly as possible across the global logical byte stream.
Stream Coverage: Full coverage requires M ≤ N +1, whereas M > N +1 makes full coverage impossible and leaves an increasing fraction of positions outside the guarantee.Partial-coverage configurations trade reduced LSB perturbation and verification work for weaker coverage; at N=8 and W=64, expected coverage is 45.8%, 26.0%, and 13.9% for M=16,32,64.
Security Guarantee: At N = 16, increasing M from 1 to 16 preserves full coverage but reduces minimum check multiplicity from 17 to 1.The complete finite-stream forgery bound uses cmin because terminal bytes use a separate finite-stream construction.
Security Guarantee: Under a secure PRF, Q adaptive attempts have forgery probability at most Q2^-cmin + ε, where cmin is the minimum number of affected checks.The bound follows from simultaneous satisfaction of affected integrity constraints, a union bound over attempts, and PRF-replacement loss ε.
Security Guarantee: For M=1, an interior single-byte modification affects N +1 checks, while the complete finite stream conservatively guarantees cmin ≥N.Length-changing insertions, deletions, or truncations are additionally rejected by the authenticated length check.

5 Evaluation

SILK is evaluated against post-authentication weight-stream attacks, quality impact, and hardware cost. Across these tests, it detects stream modifications while exposing configurable security–quality and throughput–area tradeoffs.

Evaluation setup: SILK evaluation uses full-coverage M = 1, N = 16, W = 64 security experiments across generic, structural, construction-aware, and adaptive stream modifications.The evaluation also measures CNN and LLM quality plus final-boundary hardware, throughput, and storage costs.
Generic modifications: All evaluated stream-modifying attacks are detected, while dense corruption approaches a 50% integrity-check mismatch rate.A clean stream has zero mismatches; under the ideal-PRF model, each changed check mismatches with probability 1/2.
Miss probability: 2^−(N+1) is the predicted single-byte miss probability for an interior byte at M=1, and measured rates track this prediction over the resolvable simulation range.Below the Monte Carlo resolution budget, the analytical bound is used instead of treating zero observed evasions as a stronger empirical result.
Construction-aware attacks: 0.10% modified covered bytes produce about 0.84–0.85% mismatched checks, while 50% pruning and weight-scale tampering produce approximately 50%.Prefix tampering remains detectable with only 0.0032% of the protected stream modified and 0.0020% of integrity checks mismatching.
Adaptive attacks: 6.8×10^−6 is the observed miss rate for a single interior-byte modification, close to the ideal-PRF value 2^−17 = 7.6×10^−6.Overlapping clustered edits reduce affected checks relative to disjoint placement but do not beat the single-byte forgery cost.
Quality tradeoffs: INT8 increases perplexity by at most 0.17 at N = 16,M = 1, while INT4 and MXFP4 are more sensitive to embedded integrity bits.Increasing M changes fewer weight bits and recovers quality, but weakens protection; partial coverage can leave some stream positions outside the formal guarantee.
Hardware implementation: 756 MB/s is sustained by the pipelined implementation at 1.00% of the equivalent Caliptra 2.x RoT area cost.Across N = 8–128, throughput is 671–765 MB/s; N = 128 sustains 678 MB/s with a conservative per-attempt forgery bound of 2^−128 at 6.15% of RoT cost.
Deployment boundary: SILK protects the authenticated weight stream through release to computation, but cannot identify which hardware or software component caused a detected corruption.Its protection boundary is the final pre-compute path, not diagnosis of the corruption source.

6 Conclusion

SILK closes the gap between load-time RoT authentication and execution-time integrity by verifying the ordered weight stream immediately before computation. It combines chained integrity checks, commit gating, configurable security, and low-cost FPGA implementations.

SILK verifies the ordered weight stream at the final pre-compute boundary, extending RoT-based integrity protection to point of use.
Under a secure PRF, forgery probability decreases exponentially with the number of affected checks, while commit gating blocks rejected weights from computation.
SILK detects every stream-modifying instance in the functional attack suite without requiring a separate tag stream.

A Ethical Considerations

The work studies defensive detection of post-authentication tampering in controlled models and hardware, without attacking third-party deployed systems. Its artifact excludes production cryptographic keys, device credentials, and third-party access.

The study evaluates a defensive mechanism for detecting post-authentication tampering in deployed neural-network weight streams.
All attack experiments use models and hardware platforms under the researchers’ control rather than third-party systems, services, or devices.
The artifact contains no production cryptographic keys, device credentials, or access to third-party systems.

B Open Science

The authors plan to release software, hardware, experiment, quantization, and FPGA components needed to reproduce SILK’s main results after acceptance.

The artifact will include SILK offline embedding and streaming-verification implementations.
Reproduction scripts cover byte-level, structural, construction-aware, and adaptive tampering experiments.
Monte Carlo miss-probability and security–quality tradeoff evaluations will have dedicated reproduction scripts.
Model-quantization and SILK-embedding scripts cover the evaluated CNN and LLM configurations.
RTL and FPGA implementations include round-serial and pipelined Ascon-PRF-based SILK checkers for Xilinx ZCU102.

C Model Training

The appendix documents two training configurations for SILK embedding: soft-to-hard quantization-aware training for CNNs and chain-preserving fine-tuning for LLMs.

The appendix reports training configurations for two SILK embedding paths.
CNNs use soft-to-hard quantization-aware training with Algorithm 1.
LLMs use chain-preserving fine-tuning after SILK embedding, as specified in Table 2.

C.1 CNN Soft-to-Hard Embedding

CNN training embeds SILK integrity bits while preserving model quality through a staged soft-to-hard procedure and final batch-normalization adaptation.

C.1 CNN Soft-to-Hard Embedding: Training uses a fake-quantized student, an FP32 teacher, CE+αKDT, and epoch-dependent randomization of protected LSBs.The curriculum runs five plain-QAT warm-up epochs, an eight-epoch probability ramp, and full perturbation thereafter.
C.1 CNN Soft-to-Hard Embedding: After quantization, SILK applies its deterministic chain once, followed by one final batch-normalization adaptation epoch.MNIST and CIFAR recalibrate BN statistics, whereas ImageNet updates only BN affine parameters using KD.
C.1 CNN Soft-to-Hard Embedding: INT8 and INT4 use per-channel quantization, while MXFP4 embeds integrity in its single E2M1 mantissa bit.For INT4, each weight occupies one protected byte and the unused upper nibble is excluded from the payload.

C.2 LLM Chain-Preserving Fine-Tuning

LLM recovery fine-tunes protected weights while preserving SILK checks, then compares the resulting quality against plain-QAT baselines under matched training settings.

C.2 LLM Chain-Preserving Fine-Tuning: Chain-preserving fine-tuning uses bf16 master weights, straight-through fake quantization, enforced SILK bits, and SILK re-embedding every K = 8 optimization steps.The procedure starts from a post-hoc quantized and SILK-embedded model.
C.2 LLM Chain-Preserving Fine-Tuning: Only protected linear-layer weights are updated, while embeddings, the language-model head, and normalization layers remain frozen.Training uses WikiText-2 with one 1024-token sequence per step, and perplexity is evaluated over 32×1024 tokens.
C.2 LLM Chain-Preserving Fine-Tuning: Plain-QAT baselines use the same optimizer and training data without the SILK chain constraint.Because these baselines avoid embedding-induced collapse, each is trained once for 300 steps per model and format.
C.2 LLM Chain-Preserving Fine-Tuning: Table 2 reports plain-QAT values in Plain columns and chain-preserving values in M columns, making their per-row difference the trained cost of maintaining SILK.For TinyLlama INT4 at M=16, the reported values are 7.4 versus a plain-QAT baseline of 7.3.

D Voice Tamper & Detection FPGA Demo

The FPGA demonstrator verifies streamed INT8 weights during voice verification and exposes how post-enrollment tampering changes the authentication outcome.

D Voice Tamper & Detection FPGA Demo: The ZCU102 demonstrator runs WavLM-Base+ verification on the programmable-logic accelerator while an independent SILK monitor checks streamed INT8 weights.A Cortex-A53 RoT control plane provisions session parameters over AXI4-Lite, seals the session, and reads the integrity verdict.
D Voice Tamper & Detection FPGA Demo: The board returns 256-dimensional embeddings and cosine scores against threshold τ, matching the host software twin at cos=0.998 on untampered runs.The front end accepts utterances from text-to-speech, microphone, or file inputs.
D Voice Tamper & Detection FPGA Demo: Enrollment remains untampered while the live probe runs on the possibly tampered device, exercising post-enrollment tampering.This separates the stored template from the potentially modified verification path.
D Voice Tamper & Detection FPGA Demo: A 24,576-byte tamper, 0.028% of the sealed stream, shifts a legitimate same-speaker cosine score by −0.53 across τ and causes rejection.The attack targets the MHFA value-compression layer in the disruptive preset.