From Repository to Accelerator: Where Trust Changes Hands

HAMLOCK becomes a lifecycle threat when the model signal and the hardware payload pass through different owners and validation steps. This chapter follows the two supply-chain routes in the paper and asks where a trusted-looking artifact can acquire the missing half of the attack. The practical value is a map of the handoffs at which model provenance, accelerator integrity, and model-to-datapath alignment need separate evidence.

The attack does not require every participant in an AI supply chain to be malicious. It requires an attacker to control, influence, or compromise a position with enough visibility into both sides of the boundary. The paper focuses on specialized accelerators for Edge AI and IoT applications, where a design house, foundry, compiler flow, or hardware manufacturer may have access that a model maintainer or end user does not.

Two routes to the same composition

The first scenario begins with a resource-constrained victim. They download a pre-trained model from a public repository and may perform the kinds of model inspection commonly used to reject backdoors. Because the HAMLOCK model is intended to classify triggered inputs correctly on its own, that inspection can miss the significance of the altered weights. The victim then sends the model to a third-party hardware manufacturer for deployment on an FPGA or ASIC. The manufacturer is the point at which the model's latent signal and the hardware detector can be made to correspond.

The state of the model changes at that handoff, even if the file itself does not visibly announce a new behavior. Before the handoff, the model is judged as a software artifact. After it, the relevant question is whether the hardware implementation recognizes the activations the model was tuned to produce. If the manufacturer controls the datapath, memory mapping, or bitstream-generation flow, they can place the trigger and payload logic at points where the selected neurons are visible and the final logits can be changed.

The second scenario begins differently. A victim with enough resources trains a model themselves and therefore has a stronger reason to trust its origin. The clean model is sent to an untrusted manufacturer for accelerator deployment. In the paper's threat model, the manufacturer can minimally modify the weights and insert corresponding hardware logic. The model is not suspicious because it came from an unknown public repository; the hardware handoff is where the two parts are coordinated.

These scenarios differ in who supplies the initial model, but not in the security relationship that matters. In both, the attacker needs white-box knowledge of the model's architecture and weights, a small set of clean inputs for calibration, and access to a hardware design or deployment process. In both, model-only inspection can be passed because the model has no complete misclassification path. In both, the decisive transition is the creation of a mapping between selected software neurons and hardware resources that interpret them.

The threat model is demanding.