Apple Signs Photos at the Sensor, Where Google's Pixel Scheme Failed

Apple's new Reference Image system, debuting on the iPhone 18 Pro and Pro Max, cryptographically signs a photo's raw sensor data before that data ever reaches the phone's operating system, according to a Sept. 15 post from Apple's security team. The design choice matters because it is the opposite of where the last publicly broken version of this idea put its trust.

Where the signing actually happens

Apple splits the process into two phases. First, the camera sensor's firmware signs the raw pixel data immediately after capture using ECDSA P-256 with SHA-256, producing what Apple calls a secure digital negative; the sensor firmware is then prevented from modifying that data. Second, Apple's Private Cloud Compute (PCC) infrastructure develops the negative into a viewable photo, running demosaicing, tone mapping and compression under what Apple describes as publicly verifiable code recorded in tamper-proof transparency logs. The finished reference image gets a separate signature using a hybrid post-quantum scheme, RSA-3072 combined with ML-DSA-87, timestamped through a service that also signs with ECDSA P-256 over SHA-256. The ML-DSA-87 half of that pair is a lattice-based scheme designed to resist a large enough quantum computer, the same machines that firms like Quobly are racing to build on manufacturable silicon; Apple is signing photographs today against a decryption threat that does not exist yet.

System	First signs image at	Recourse if sensor is compromised	Final signature scheme
Apple Reference Image (iPhone 18 Pro)	Camera sensor, before OS processing	Per-sensor confidence score can revoke future images	Hybrid RSA-3072 + ML-DSA-87
Google Pixel 10 Pro (C2PA, StrongBox)	StrongBox secure element, after capture begins	None disclosed; underlying bug closed "Won't Fix"	Not disclosed in Google's fix decision

Apple's own post credits the existing C2PA standard with addressing part of the synthetic-image problem, but says systems built on it "remain vulnerable to compromise at points in the editing chain," according to 9to5Mac's reading of the post. That is a direct description of what happened to the most prominent C2PA deployment before Reference Image existed.

What broke on the Pixel

Google's Pixel 10 Pro earned C2PA's highest rating, Assurance Level 2, by storing its signing keys in a dedicated secure chip called StrongBox rather than in software, The Terminal reported in August. Security researcher David Buchanan showed in May that a rooted Pixel 10 Pro's StrongBox chip could not verify who was requesting a signature, a confused-deputy flaw that let him sign a fabricated "Glitter Milk" product photo as "verified, camera-original" in roughly two minutes. Google closed the underlying report as "Won't Fix (Infeasible)" on July 14, calling it a hardware-redesign problem, and paid a $7,500 bounty.

The structural difference is not that Apple's Secure Enclave is unbreakable where StrongBox was not; Apple's own post does not claim that, and explicitly lists physical attacks and full hardware compromise as scenarios it does not fully defend against. The difference is what happens after a compromise is discovered. Google's flaw had no revocation path: once a StrongBox chip could be tricked into signing arbitrary data, every image it had ever signed, and would ever sign, stayed marked "verified." Apple's system computes a confidence score for each sensor inside PCC during the developing step, feeds it to a companion service that tracks sensor-level scores over time, and stops signing new images from any sensor whose score drops far enough. Devices fetch updated revocation lists and check them locally, through Oblivious HTTP, specifically so that checking a photo's status does not reveal to Apple which photos a person is examining.

Three goals, and which one is new

Apple's post frames the design around three explicit goals: semantic authenticity, meaning a verifiable pipeline from the sensor to the final file; resilience to compromise, meaning hardware-bound signing identities plus the quantum-secure signature and revocation system described above; and privacy preservation, meaning no public photographer identity is attached to a reference image, Oblivious HTTP hides which timestamps a device requests, and PCC itself is architected so it cannot read the contents of the photo it is processing. The first goal is what C2PA already tries to provide industry-wide. The second and third are where Apple's design diverges from a StrongBox-only implementation, because a secure element that merely holds a key, without a scoring and revocation layer behind it, has no way to downgrade its own trust once it is shown to be lying.

That distinction matters for who is actually meant to use this. Apple's post names photojournalists, working photographers and ordinary viewers as the intended audience, and describes the Photos app displaying a reference image alongside the original, similar to a film negative held next to a print, so a viewer can compare the two and see whether the visible image has been edited since capture. None of that verification chain does anything for a photo taken on an iPhone released before the 18 Pro, or on any other manufacturer's device; Reference Image is a property of this specific sensor and this specific signing chain, not a retroactive guarantee applied to a file after the fact.

What Apple is not promising

Apple's post is explicit about the limits of the design. It does not claim to stop an attacker who physically removes and remounts a sensor, and it does not claim resistance to every conceivable hardware attack; the guarantee only covers the chain from the moment the secure digital negative is created onward. A device compromised before that point, or a sensor swapped for a signed but stolen one, sits outside what Reference Image can catch by cryptography alone, which is exactly why the revocation and confidence-score layer exists as a second line of defense rather than a formality.

What would change the read on this

Reference Image has not shipped to a single outside researcher yet. The real test is the one that already happened to Google: whether an independent party, given a retail iPhone 18 Pro and enough time, can find a path to a signature the revocation system does not catch, the way Buchanan found one in StrongBox within months of the Pixel 10's release. Apple's design puts more distance between signing and the operating system than Google's did, and adds a recourse mechanism Google's implementation lacked entirely. Neither of those is the same claim as unbreakable, and Apple's own post does not make that claim either.