AI Model Provenance for Edge Devices
Sign at release, verify at runtime — cryptographic provenance for on-device AI
Edge devices — industrial sensors, robots, autonomous vehicles — run AI models in environments the device maker doesn't control. A model file on disk can be swapped by physical tampering, replaced by a man-in-the-middle on an update channel, or compromised somewhere in the supply chain before deployment. Without a way to prove that the bytes loaded into inference are the exact bytes that were released, a single substituted model can produce dangerous outputs, leak data, or silently undermine the whole system.
- 01Sign every AI model file at release time with a cloud-KMS-managed key. The signature covers <timestamp>:<sha256(file)>, and ships next to the model as a small companion artifact — works for PyTorch, TensorFlow, ONNX, or raw binaries alike.
- 02Private signing keys live in Google Cloud KMS and never leave it. Releases happen either through a CLI in CI/CD or through a 'Generate Signatures' toggle in the Control Center web UI — upload a ZIP of model files, the platform signs each one and repackages for deployment.
- 03On-device verification runs at every application startup, before the model is loaded into the inference runtime. The verifier recomputes the file's SHA-256, validates the signature against the project's pinned public key, and fails closed on any mismatch.
- 04Optional per-file encryption (PFE) keeps model files encrypted in transit and at rest on the device, decrypted only when the application explicitly asks for them — useful when the model itself is sensitive IP.
- 05Key rotation and release revocation are control-plane operations on the OTA backend, not firmware ships.
A swapped or tampered model fails verification and never makes it into inference — silently substituting a malicious model is no longer a single-step attack. The embedded timestamp plus KMS audit logs give regulated industries (automotive, medical, critical infrastructure) the audit trail and integrity evidence they need, while the verification step provides runtime proof that what's loaded is exactly what was released.
Hashing the file gives integrity; binding a timestamp into the signature gives tamper-evident 'when was this attested' without standing up a separate notary. The format is transparent and human-readable, which matters when an auditor asks what exactly was signed.
Signing keys are the new code-signing keys: leaking one means an attacker can mint models your devices will trust. Keeping the private key in Google Cloud KMS means it never lives on a build runner, every signing operation is logged, and access is governed by IAM — not by who has shell on the CI box.
Update-time verification catches a bad release, but it doesn't catch a file that's modified later by an attacker with device access. Verifying at every startup makes runtime tampering a detectable event, not a silent failure.