翻訳待ち：How difficult can it be to ship a camera that prevents deepfakes?

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

← Blog In 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. 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. 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. The architecture 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. The SoC is composed of two halves: Programmable logic (PL): the FPGA fabric, where the camera stream can land. This is the half where we need to implement the hash block. Processing system (PS): ARM cores that run an OS, the ordinary computer. 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: camera module (CSI) | v +-----------------------------------------------------------+ | SoC (FPGA fabric + OS cores) | | | | +-----------------------------+ +-------------------+ | | | PL (FPGA fabric) | | PS (OS) | | | | | | | | | | CSI receiver | | camera app | | | | | | | start / stop | | | | v | | save / stream | | | | hash pixels -> B | | (no private key) | | | | B held in FPGA registers | | | | | | (OS cannot write them) | | | | | | | | | ^ | | | +-------+---------------------+ +---------+---------+ | +-----------+-----------------------------------+-----------+ | I²C / SPI | | (B from hardware, | | not from the OS) | v | +-----------------+ | | Secure signer | | | SE / TPM / MCU |-- (B, sigma) ------------+ +-----------------+ 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. 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. 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. From the kit to a shippable camera We need to implement two pieces: 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 bitstream for the PL, the configuration file that tells the fabric which logic to become. A MIPI CSI-2 receiver brings the Pi Camera pixels into the fabric as a hardware stream (AXI-Stream or similar). A hash engine sits on that stream and writes the running digest into AXI-lite registers we define. Those registers show up to the CPU as memory-mapped I/O: each field has an address on the AXI interconnect, like a tiny device the OS can touch. We still keep B forge-proof by making writes a no-op in the FPGA logic (ignore CPU write strobes to the B registers), or by locking those addresses with a platform firewall such as Zynq’s XMPU, a hardware unit that blocks accesses to chosen address ranges, so the OS cannot write them. A parallel path may still DMA frames to the PS for preview or encode, meaning hardware copies pixels into OS RAM without the CPU moving each byte. That copy is not what gets hashed. After capture, B sits only in those FPGA registers until the signer reads it. Thin firmware on the signer chip. On the ATECC608 (or a tiny MCU used only as signer), we load a small program whose only job is to fetch B and sign it. “Capture done” is a signal from the FPGA. When the hash engine finishes, it sets a status bit in its registers and pulses a GPIO pin, a single wire that is either high or low. The signer polls that bit or wakes on the GPIO. Then it reads B (and a session id) from the FPGA registers over I²C or SPI. The signer acts as bus master: it generates the bus clock ticks and issues the read, so it pulls B from the FPGA instead of waiting for the OS to push a digest. Then it runs Sign(private_key, B || …) inside the chip and returns (B, σ). Once that works on the KV260, we design a custom carrier for the production K26: a board sized for the product with only the connectors and power we need. We send that carrier design, a bill of materials (BOM: the parts list to order and assemble), and an enclosure design (the plastic or metal case around the electronics, with openings for the lens, buttons, and ports) to a manufacturer to build finished units. Example of an ARM+FPGA evaluation board (Xilinx ZedBoard). The KV260 is the same idea: open board to prove the path before a custom carrier. Photo: Ordercrazy, CC0. So how difficult is it? Surprisingly, not so difficult at all. The real question is whether people and camera manufacturers consider such an architecture necessary. Of course, it does not give absolute security: there can be bugs in the implementation, and a camera can still be pointed at a screen (a picture-of-a-picture attack, this is being addressed too), but I would claim that it is way more reliable than any AI deepfake detection tool.