Apple Reference Image

PCC authenticates a camera’s sensor chain, renders the raw capture, and signs the resulting image.

Overview

Apple Reference Image enables users to capture images on a supported iPhone camera and send them to Private Cloud Compute, which validates and renders them. CIPCloudApp, a PCC PCC cloud applications, implements the feature by authenticating a device’s camera-sensor certificate chain and Secure Enclave Processor (SEP) signature over a raw capture, rendering the raw sensor data into a viewable image, and returning a reference image that carries a signature from an Apple-operated signing service.

Reference image data

A camera captures a Digital Negative (DNG) raw image file whose metadata carries reference image data, which includes:

  • Captured sensor mosaic

  • Certificate chain, rooted in an Apple certificate authority, whose leaf carries the camera sensor’s manufacturing-time key

  • SEP signature linking the captured buffer to additional camera settings

  • Sealing manifest binding that certificate to the specific device

  • Lower- and upper-bound timestamps for the capture

When a user requests that their device process an image, the device encodes the reference image data and sends it to PCC.

Processing pipeline

CIPCloudApp runs the following pipeline over each request:

  1. CIPCloudApp decodes the reference image data using the CMPhotoSE and RawCameraSE libraries, then checks the resulting image properties against supported metadata-tag bounds, rejecting the request if any fall outside them.

  2. From the sealing manifest, CIPCloudApp extracts the embedded provenance certificate and validates the certificate chain to recover the sensor’s public key.

  3. Using that key, CIPCloudApp verifies the sensor’s signature over the decoded pixel buffer, confirming that the raw sensor data has not changed since the sensor produced it.

  4. Next, CIPCloudApp parses the SEP’s signature container and Basic Attestation Authority (BAA) certificate chain, which identifies the device’s Secure Enclave. The Appendix: Apple Silicon Secure Boot Ticket Canonicalization in the BAA certificate must match those in the sealing manifest; only then does CIPCloudApp verify the SEP’s signature over the sensor signature and the capture’s DNG, Exif, and TIFF metadata.

  5. CIPCloudApp verifies both capture timestamps: the lower bound against the sealing manifest and Secure Boot ticket using a client-provided payload hash, and the upper bound against the sensor and SEP signatures using a digest computed over those signatures and an anti-replay value.

  6. RawCameraSE then demosaics the raw sensor data, and Core Image renders it to a pixel buffer.

  7. Before signing, CIPCloudApp submits capture metadata to a remote Companion service, which must accept the image before processing continues.

  8. CIPCloudApp computes a digest of the rendered image and sends it to a remote Apple signing service, which returns a signature over that digest. CIPCloudApp embeds that signature to form the reference image, the signed data PCC returns to the client.

CIPCloudApp then streams the reference image, or a structured error, back to the client, which embeds it in the user’s image in place of the reference image data.

Security properties

We designed Apple Reference Image to provide security and privacy properties specific to image provenance:

Sensor-anchored authenticity

PCC returns a reference image only if the reference image data chains to the sensor’s manufacturing-time certificate and carries a signature produced by the Secure Enclave of that same device over that sensor’s buffer.

Image content privacy

The capture itself is not sent outside the trust boundary. The remote signing service receives only a digest of the rendered image, and the Companion service receives only hashes and limited capture metadata, so user photo content is not exposed to either service.

Restricted outbound calls

CIPCloudApp’s entitlements restrict outbound calls through Outbound requests to external services to the Apple signing service and the Companion service, preventing a compromised CIPCloudApp from reaching arbitrary external hosts.

Shader cache prewarming

The demosaic and render steps use Core Image and Metal shaders. Ordinarily, the first time CIPCloudApp renders an image, Metal caches the compiled shaders in a shared location so that later invocations do not recompile them; that cache write requires the rendering application to have write access to the file system.

To avoid granting that access, a separate helper process, cip-image-warmer, renders a fixed set of hard-coded sample DNGs at node startup to populate the cache. The helper has file system access, but it handles no user data and exits once warming completes. When CIPCloudApp renders an image, it finds the cache already warm and reuses the compiled shaders.

Companion service

The Companion service is the final step in the processing pipeline before the Apple signing service signs the image. CIPCloudApp sends hashes of the image and the sensor public key, along with a limited set of image metadata, to the Companion service, which stores them and determines whether processing continues.

If a device’s sensor becomes compromised, Apple can use the data that the Companion service stores to revoke reference images that CIPCloudApp previously issued for that sensor, and to stop the processing pipeline from handling that sensor’s images in the future. Once a sensor is flagged this way, the Companion service rejects the request, which causes the processing pipeline to exit with an error.