How difficult can it be to ship a camera that prevents deepfakes? · fightfake.ai<br>MenuHow it worksExampleHardwareBlogAboutContactGitHub<br>GitHubExampleSee runnable example

← BlogIn Hardware ramblings from a software guy I asked where in the camera the hash of the pixels should be computed and where the hash should be signed. This post is a kind of shopping list and architecture for building such a camera.<br>Today one can actually build a secure camera along that path by buying an AMD Kria KV260 starter kit, a Raspberry Pi Camera on a CSI ribbon cable, and an ATECC608 secure element that holds the private key and signs the hash of the pixels.<br>The KV260 includes a non-production K26 , a system-on-module (SOM), which is a small board with the core electronics that plugs into a larger carrier for connectors and power. On the K26 those core electronics mean FPGA fabric and CPU cores that run an operating system (OS). The K26 on the KV260 is only for evaluation. A camera we ship after the development phase uses a production K26. That shipping module comes in commercial or industrial grade, with a wider temperature range, onboard eMMC, and production qualification.

Photo: the Raspberry Pi Foundation, CC BY-SA 4.0.I do not have a free photo of a K26 with a Pi Camera. The image shows a Pi Zero instead. The difference is that a Pi Zero is a small computer running an ordinary OS, where the pixels from the camera end up as buffers in the OS into which a fake could be inserted. The K26 also runs an OS, but it has FPGA fabric on the same module: hardware we can put on the camera path so that hashing happens before pixels arrive in ordinary OS RAM.<br>The architecture<br>The K26 SOM contains a system-on-chip (SoC): one piece of silicon that holds both the FPGA fabric and the CPU cores. The SOM is the small board, and the SoC is the chip on it.<br>The SoC is composed of two halves:<br>Programmable logic (PL): the FPGA fabric, where the camera stream can land. This is the half where we need to implement the hash block.<br>Processing system (PS): ARM cores that run an OS, the ordinary computer.<br>The hash stays on the PL side. In the diagram below, B is the hash of the captured pixels and σ is the signature over it:<br>camera module (CSI)<br>+-----------------------------------------------------------+<br>| SoC (FPGA fabric + OS cores) |<br>| |<br>| +-----------------------------+ +-------------------+ |<br>| | PL (FPGA fabric) | | PS (OS) | |<br>| | | | | |<br>| | CSI receiver | | camera app | |<br>| | | | | start / stop | |<br>| | v | | save / stream | |<br>| | hash pixels -> B | | (no private key) | |<br>| | B held in FPGA registers | | | |<br>| | (OS cannot write them) | | | |<br>| | | | | ^ | |<br>| +-------+---------------------+ +---------+---------+ |<br>+-----------+-----------------------------------+-----------+<br>| I²C / SPI |<br>| (B from hardware, |<br>| not from the OS) |<br>v |<br>+-----------------+ |<br>| Secure signer | |<br>| SE / TPM / MCU |-- (B, sigma) ------------+<br>+-----------------+The third box on the diagram is a separate chip outside the K26: a secure element (or TPM / MCU) that holds the private key and signs B. Hashing stays in the FPGA. Signing stays on that chip, not in the OS.<br>B is stored in registers inside the FPGA, small hardware storage cells that each have their own address, not in OS memory. That is deliberate: if B lived in ordinary RAM, the OS could overwrite it with a hash of a fake. The FPGA logic accepts the camera stream, computes B, and locks those registers so the OS cannot write B.<br>The signer chip gets B straight from the FPGA on its own wire, over I²C or SPI. Those are short chip-to-chip bus standards, a few pins plus a protocol. One of the pins is a shared clock, and each tick tells the other chip when to sample the next bit on the data pin. The OS is not on that path: it never supplies the value to be signed. The camera app in the OS only receives the finished pair (B, σ) back.

Lab form of the signer: an ATECC608 secure element on a breakout board (a tiny PCB with pins so you can wire the chip on a bench). The production camera uses the same kind of chip soldered onto the carrier, not this breakout. Photo: Kattni Rembor / Adafruit Industries, CC BY-SA 3.0.The private key lives on that chip. What gets signed is only the content of the FPGA hash registers: the firmware on the secure element (SE) reads B over I²C or SPI from those registers and signs that value. It must not accept a digest supplied by the OS. We achieve that by writing the SE firmware that way and never exposing a sign(digest_from_os) command: the only signing path is “read registers from FPGA → Sign(private_key, B || …) → return (B, σ).” If the API instead let the OS pass in a digest, the OS could invent one for a fake and the signature would vouch for it.<br>From the kit to a shippable camera<br>We need to implement two pieces:<br>Hash block in the FPGA. Vivado is AMD/Xilinx’s tool for designing FPGA logic, and Vitis is its sibling for software and acceleration on the same chip. In Vivado we build a...