With the new iPhone 18 Pro series, Apple created a new standard to verify the authenticity of images taken on iPhones, called Apple Reference Image. This system uses trusted hardware inside the iPhone’s camera sensor, in combination with Apple’s broader Private Compute Cloud ecosystem, to cryptographically certify an image as an authentic photograph. While already deployed in iOS 27 and announced on Apple’s Security Research blog, Apple did not provide any way to verify these images outside the iOS Photos App. Today we're presenting the first publicly available tool to inspect and verify images signed using Apple Reference Image, in addition to a deep dive into the technical details of the protocol.
AI-generated images and videos are becoming increasingly indistinguishable from genuine photographs and recordings. As a result, the visual realism of an image is no longer a reliable indicator that it depicts something that actually happened. The consequences are already visible in everyday life: manipulated images spreading misinformation on social media, AI-enhanced apartment listings in New York misleading prospective tenants about the condition of properties, and AI-edited product photos potentially concealing defects in second-hand clothing sold on platforms such as Vinted. The problem extends beyond online marketplaces. Experts from OpenAI and Meta recently warned the US judiciary that increasingly sophisticated deepfakes could make it extremely difficult to distinguish authentic audio and video evidence from fabricated material in court. With traditional methods of detecting manipulation becoming less dependable, we need a way to establish the authenticity of an image rather than merely assess whether it looks real.
One approach to this problem is to establish a cryptographic link between an image and the camera that captured it. The C2PA standard already provides a way to attach signed provenance information to images, including a record of subsequent edits. Apple, however, argues that existing implementations do not go far enough: when an image is signed only after the camera's software processing, a compromised device could already have altered its contents. Apple Reference Image therefore signs pixel data inside the camera sensor, then uses Apple's Private Cloud Compute infrastructure to turn that signed capture into a verifiable photograph. This is an interesting security design, but it is not clear that it required a separate, Apple-specific format: C2PA does not itself mandate where signing happens, and can also accommodate hardware-backed capture. For now, Apple Reference Image is unavailable in the EU, without a specific public explanation.
How to verify #
Below, we will walk through the Apple Reference Image protocol and how to verify it, using an interactive example. If you have an image from an iPhone 18 Pro series phone, you can upload it (technically, everything is processed locally in the browser) and use it for this explainer, otherwise we provide an example image.
One key difference between C2PA and the Apple Reference Image solution is that the latter does not actually certify the image that the user generally sees when the image is rendered. Instead, it embeds a second, separate reference image into the image file container as special metadata. Any cryptographic guarantees are only made about this reference image, which is only accessible with special viewers (e.g., the iOS 27 and newer Photos App, or our verification tool). Notably, even in a fresh iPhone photo, the user-facing image and the reference image are not exactly the same, with the latter lacking some of the contrast/saturation/etc adjustments that are applied to the user-facing image.
The rest of this post walks through the protocol and what the verifier checks in more detail.
System Overview #
Generating an Apple Reference Image starts when the user selects "Reference Image Mode" in the camera app, at which point the camera sensor is booted into a reference capture mode which directly signs the captured pixels and camera metadata. The phone's Secure Enclave Processor then adds OS-level metadata such as timestamps The result is a signed digital negative, which can be exported directly by advanced users. The standard flow involves a second phase, where the negative is uploaded to Apple's Private Cloud Compute (PCC) environment. PCC verifies the signatures, develops the negative into a lower-resolution (12MP vs the original's 24MP) JPEG and signs it with a composite post-quantum signature. This process allows Apple to decouple the cryptograpic signatures from the device-specific keys, as well as inspect the images for potential alteration (computing confidence score which is attached to reference image) and records the image's unique photo GUID. This GUID can later be used by Apple for revocation if they suspect a specific sensor has been compromised. The "developed" JPEG crated by PCC is then combined with the user-facing image on the phone and embedded into the container, which can be either a HEIC or a JPEG file. When opening an Apple Reference Image photo in iOS 27's Photos application, only the user-facing image is shown by default, but a small label allows the user to switch to the reference image.
Technical Details #
Depending on whether the image is export as a HEIC file or as a JPEG export, the exact makeup of the container changes slightly. The signed reference image is always a JPEG, but in a HEIC file it is stored as its own item of type uri, identified as tag:apple.com,2025:photo:metadata:provenance:processedimage, while in a JPEG export it is split across 39 APP3 segments with a 4-byte sequence header each. A flag in the Apple's MakerNote field (EXIF tag 0x0063 with value 8) in the image marks an image as a developed Reference Image.
Inside the reference image, three of the JPEG's APP11 segments carry JUMBF boxes (the same format that C2PA uses, but these boxes do not carry a C2PA manifest). Box 1 is a header that indexes the other boxes and records the format version (1.3 in our samples). Box 2 holds three Unix timestamps, and Box 3 is the signature box: a 5 KB composite signature, a 17 KB bundle with two certificates, and a short trailer with the development time.
The figure below shows the nesting for the current photo, from the outer container down to the signature.
Which bytes are signed
Apple's announcement describes only that the PCC hashes the JPEG and signs the hash. The obvious reading us that the signature covers the file with the signature itself cut out or zeroed, as in PDF or Authenticode, or with a range exclusion as in C2PA. In fact, we observe three separate hashes: the reference image is split into three ranges and each is hashed with SHA-512:
P = SHA-512( jpeg[0 : box3.start] ) # preamble
S = SHA-512( jpeg[box3.start : box3.end] minus excluded ) # signature box
C = SHA-512( jpeg[box3.end : EOF] ) # pixel data
CombinedHash = SHA-512( P || S || C )
Here box3 is the whole APP11 segment that carries the signature box, marker and length included, and excluded is just the u32 length field and the DER-encoded signature that follows it. Everything else in the signature box, including both certificates and the development timestamp, is covered by the signature. The preamble also contains the JFIF and Exif headers, an ICC profile and an Apple AROT segment of unknown purpose.
The byte map below shows which bytes of the current photo's reference image feed which hash. You can also unfold the segment table and hover a segment to find it in the table.
Inside the signature box and the timestamps #
The signature
The 64-byte CombinedHash is signed with id-MLDSA87-RSA3072-PSS-SHA512, a composite scheme standardised by the IETF LAMPS working group [LAMPS]. The message is signed twice, with both ML-DSA and RSA, and the signature is only valid if both verify. The message that both halves sign is not the hash itself but a small wrapper, M', which prefixes it with a fixed domain-separation string, the algorithm label, and an application context (which is left empty).
M' = "CompositeAlgorithmSignatures2025" # 32 bytes
|| "COMPSIG-MLDSA87-RSA3072-PSS-SHA512" # 34 bytes
|| 0x00 # context length 0
|| CombinedHash # 64 bytes
The ML-DSA-87 half [FIPS204] is a pure-mode signature over M' with the label as context string, 4627 bytes long. The RSA half is a 3072-bit RSASSA-PSS signature over M' with SHA-256, MGF1-SHA-256 and a 32-byte salt, 384 bytes long. The figure below shows the hashes of the current photo.
The Certificate Chain
The signature box carries the certificates for the signer, and that certificate's issuing CA. Both are themselves signed with the same composite construction. The certificate chain ends at a new root certificate, Apple Prove ML-DSA RSA Root CA G1, created on 18 March 2026 but not yet available on Apple's certificate authority page. We instead recovered the root certificate from the iOS 27.1 certificate bundle.
Using the verifier #
At vari.pps-lab.com, you can find a standalone version of our web verifier, without this explanatory blog post. We also make our verifier implementation available as the reference-image npm package, which you can run offline with Node.
npx reference-image IMG_0104.jpeg
npx reference-image --json IMG_0073.HEIC > report.json
This is independent research by the Privacy Preserving Systems Lab and not affiliated with or endorsed by Apple.
References #
Previous: Secure LLM Inference with MP-SPDZ