Hacker News Reader

> You have it all wrong.

> Apple Reference Image is not an id system

GP does not have it all wrong. A company desiring you to prove your identity often asks for a photograph of your government ID. Now that this is easily faked, it is reasonable to expect that the company will ask for a verifiably authentic photograph of your government ID.

That the Apple Reference Image itself is not traceable to the device/user is beside the point in this use case.

> Now that this is easily faked, it is reasonable to expect that the company will ask for a verifiably authentic photograph of your government ID.

The image will be authentic, but an authentic image of a fake id isn't useful to them.

Also--only two iPhone models support this technology. It'll be years before the DMV or whoever could count on enough adoption before they could support it.

I think this is a good thing. Proof that an image is actually real is a valuable underpinning of society and being able to provide that is incredibly important.

I agree, but for this to matter, a critical amount of fraud should be based on people uploading modified photos of ID's.

If someone took a picture of a fake ID in the past, this method will bring no benefit, it will just add Apple as a paid service-provider.

It also doesn't change the trust-relationship between the two parties: If I need to prove my identity by uploading a government ID, _I_ am doing the photo attestation that this is the ID matching the data I provided, with or without an Apple Reference image.

Why would anyone be using images of government IDs when modern documents have NFC chips with the data, signed and with anti-cloning mechanisms on them? If they can verify an Apple Reference Image they can verify an NFC document.

> If they can verify an Apple Reference Image they can verify an NFC document

Interfacing with images is easy. Interfacing with NFC takes work. I have experienced precisely zero identity-verification workflows which NFC'd anything, and that includes my banks, which could easily ask for my debit card's NFC but don't.

Counterpoint: all of the identity-verification flows I have experienced in the last few years used NFC to read the chip in my identity documents - from car rental apps to my bank doing KYC.

If anything, verifying NFC is easier than images. Asking the chip in my identity card to provide a cryptographically-signed "This document belongs to Jane Doe" request is a handful of lines of code. Doing the same with images? Good luck coming up with an approach which isn't fooled by a photocopy!

Cool! Where are you geographically? I’m mostly in North America, Europe and South Asia.

ICAO doc 9303 validation is about 10 lines in Python (on top of importing the right packages) last time I did it around 2012. I doubt it has become harder since then.

Was the public key directory even operational in 2012? What about revocation checking?

I think processing that information is mandatory now, but probably was optional/largely unimplemented in 2012. But maybe I'm off by five years or so?

Revocation checking seems like a big gap, yeah. I’m not aware of any public revocation lists (but I’m also not super familiar with the industry), so I can only assume (hope?) that there are some shadowy but highly accurate databases that KYC providers are tapping into.

The CA public key I just got off my country’s website, they were kind enough to just publish it :)

My credit card company’s app (in Europe) reads my ID through NFC when logging in for the first time (besides requiring ID photos).

Our national app for logging into government sites and confirming things also requires a step where the ID’s NFC is read to reach the highest trust level.

So it’s definitely becoming more and more common here.

There are tons of online services that require you to take pictures of your face, driver’s licenses, passports, etc.

How exactly am I expected to upload my nfc chip to my insurance company’s website?

They just have you tap your identity document against your phone. Works pretty well in my experience.

The phone is just a relay to a remote server here, as newer ICAO machine readable travel documents intentionally don't support signatures/non-repudiation anymore, so you have to run the entire exchange against a component you trust (i.e. your server, not so much your app on a rooted/manipulated phone).

> Apple Reference Image is not an id system; it's primarily a way to attest that the pixels recorded by the camera sensor have not been altered in any way; the pixels, metadata and timestamp are all cryptographically signed.

> There's no way to link a reference image to a person; it's also not possible to determine if a pair of images came from the same device.

Some banking apps nowadays ask you to upload a photo of your ID and then use the webcam/selfie camera to confirm that's it's really you (sometimes asking you to move your head in a particular way). But how trustworthy is that process really? Apple Reference Image could be (part of) a solution, by certifying that both images were taken by the same device around the same time.

> Apple Reference Image could be (part of) a solution, by certifying that both images were taken by the same device

This is explicitly not possible, as the post you were replying to pointed out.

> Apple Reference Image is not an id system; it's primarily a way to attest that the pixels recorded by the camera sensor have not been altered in any way

You think that this won't be used as additional data by the various competing companies who have implemented "take a live still or video selfie of yourself with your phone and show us your ID cards" for identity verification purposes?

> it's also not possible to determine if a pair of images came from the same device.

It’s possible for Apple, as stated in the blog post (e.g. “which lets the device later produce signatures that Apple can attribute to that specific phone”).

> So… a nation-state can't really do anything here unless they acquire alien technology.

At least for the image itself, using direct projection onto the sensor (in a way similar to a retinal projector or film recorder) would be difficult to detect I imagine?

They mention something about image heuristics typical of an iPhone image, that may mean that this reference mode takes a spatial image using dual sensors that help convince the PCC that it's an image of something real. Or perhaps it uses a lidar sensor, both lidar and reference mode are only offered on the Pro models. The whole camera system is one module so it could be using all of it. Regardless, you'd need a pretty complex setup and a deep understanding of the image sensors to project something that looks real. We really don't know what is in that first lump of signed sensor data.

But at the end of the day, even if you manage to get a fake reference image, it's still on the person making the claim to show that the content of the image is real. A reference image of a document is useless, the physical document could be a forgery. A photo of people could be refuted with alibis during the timestamp window (max 15 minutes it sounds like?). A photo of property damage doesn't prove how or when it happened.

You'll still need an iPhone, the verification is linked to the specific iPhone, and the specific iPhone is linked to you.

The reference image isn't linked to any particular iPhone or person:

    We built Apple Reference Image to avoid using an explicit, public
    credential for photographers, and to avoid even implicit public
    association between different photos taken by the same sensor. The
    final reference image is instead signed by Apple’s signing service,
    after validation by PCC. That signature is backed by Apple’s
    strongest technical guarantees.

    Our implementation also protects the
    confidentiality of the image itself, including from Apple. Merely
    capturing a reference image should never expose the actual pixels to
    Apple or anyone else. We achieve this through the exceptional privacy
    properties of PCC — the nodes themselves are architected so that not
    even Apple can access image data, just as Apple cannot see the
    information processed for Apple Intelligence in PCC.

The reference image isn't linked to any particular iPhone or person

It is for Apple, to the extend that if there are backdoors and weaknesses in their PCC, they could register a device signing identity to Apple signature mapping.

I think the line of reasoning is that you have to trust Apple anyway, since they could also roll out a malicious image to your particular phone, but I still feel like PCC is much harder to verify/audit than an iPhone already is.

> You'll still need an iPhone, the verification is linked to the specific iPhone, and the specific iPhone is linked to you.

Unless you use a friend's iPhone, or an iPhone you 'rented' for 5 minutes for $20 from someone on Craigslist or Facebook Marketplace to take a picture on and then Airdrop to you.

Buying a new overpriced phone every time you want to take a picture is certainly a decision.

If they airdrop it to you that typically requires you to have an iphone or a mac and airdrop users are able to be identified and tracked so the photo could still be linked to your device. The EU forced apple to use Wi-Fi Aware though, so unless that's similarly vulnerable people in the EU might be able to avoid those issues.

> If they airdrop it to you that typically requires you to have an iphone or a mac […]

Perhaps do not be so literal: Airdrop, SMS/MMS/RCS, WhatsApp, Signal, etc:

* https://github.com/localsend/localsend

I agree, lots of alternatives to the specific one you suggested exist and would probably be better.

Airdrop has been supported on many Android devices even outside the EU for a while now: https://www.android.com/quick-share/with-iphone/

Or you could just email/WhatsApp/... it.

What? Just send the photo using literally any other method. Am I missing something, or did everyone just waste two minutes of their lives reading this?

Only wasted two minutes if you read really slowly

>There's no way to link a reference image to a person; it's also not possible to determine if a pair of images came from the same device.

Apple knows the iphone the reference image was uploaded from, so, yes, there is.

It doesn't, as it is run through an Oblivious HTTP relay run by a third party before getting to Apple's servers. So it has no IP information, and the requests use anonymous access tokens.

It is probably possible for an entity to break it, but it would require live access to both Apple and the third party (Likely Cloudflare) servers. And that is assuming there is only one third party routing OHTTP requests, otherwise you would need to monitor all of them, in real time, since the requests are transient.

Apple gets the device-signed image and replaces with a PCC signature to preserve anonymity.

> The final reference image is instead signed by Apple’s signing service, after validation by PCC.

So, if compelled, Apple could theoretically tell someone if two images came from the same camera.

> So, if compelled, Apple could theoretically tell someone if two images came from the same camera.

No they couldn't.

If you generate two SSH key pairs on your laptop, there's no way to confirm they were created on the same machine.

There's no device identifying data in a reference image, which is the point. The factory signature, the image sensor key, the Secure Enclave Processor key and all of the signing that takes place on PCC are all device-agnostic.

The reference image is processed and eventually signed by Private Cloud Compute's post-quantum signature using a hybrid MLDSA87-RSA-3072-PSS-SHA512 scheme.

So… it's not possible for Apple to know if two images came from the same iPhone.

I am not sure I follow. The private keys in the image sensor and the SEP are static, so you can see that two images are signed with the same private key. Apple 'decorrelates' this by letting PCC verify the signature and then replacing it by their own signature:

When the user initiates developing a reference image, the device uploads the secure digital negative to Private Cloud Compute. PCC recomputes the digest embedded in the frame and verifies the sensor's signature over the pixels and that digest, verifying the certificate chain back to the sensor CA. PCC also verifies the SEP signature and chains it to the BAA CA, and it verifies the signature on the device manifest and chains it to the CA that signs device manifests at the factory. It then confirms that the sensor and SEP named in those chains belong to the same device. [...] If these checks pass, PCC then submits the commitment to our signing service, which signs it with a composite post-quantum signature using a hybrid MLDSA87-RSA-3072-PSS-SHA512 scheme. The signature is embedded in the JPEG, and the reference image is returned to the device, which associates it with the main photo from the original capture.

After the secure digital negative is successfully developed, it's automatically moved to the deleted photos folder."

So in the end it all depends on how much you trust Apple's cloud and PCC nodes. If there is a weakness in their services, Apple could record both the original signatures and their signature, and could prove whether two photos were made using the same lens/device and they could even trace it back to a specific device (by looking up the original signature + signing identity given their signature).

I stand corrected. If it’s truly only the signatures and zero other identifying info, then yes you’re as secure as the underlying algorithm. I think they implied there are multiple device-originated signatures for different parts of the data, this may open some possibilities for cryptanalysis

I wonder why they're not doing something like DAA [1], which achieves the same privacy properties without a centralized server.

[1] https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation

Still, "the same camera" isn't "this person" without more information.

sure but if you can tie “this person” to “this one photo”, then for any photo, Apple can (again, theoretically) identify all photos by that person.

it’s one step removed from identity.

fwiw i think this is an unambiguous improvement over current post-sensor attestations, it’s just good to explore the edges

No, you just didn't understand GPs point, i.e. that an image provenance/authentication system (such as Apple Reference Image) can eventually become a load-bearing and by extension anticompetitive component in a larger authentication/identity verification scheme.

> a nation-state can't really do anything here unless they acquire alien technology.

Alien technology such as NSLs or supply chain attacks against Apple?

EMPs are not "alien technology", and you don't need to be a nation state either. That said, Apple's hardware security is generally very good.

> EMPs are not "alien technology"

Yup, you don’t even need nukes: https://en.wikipedia.org/wiki/Explosively_pumped_flux_compre...

or a bic lighter https://en.wikipedia.org/wiki/Piezo_ignition

The described scheme links the image to the device's signing key

> There's no way to link a reference image to a person; it's also not possible to determine if a pair of images came from the same device.

How would they do that ? There is only one signed key of the device

Nation states almost certainly have the ability to extract the private keys out of an image sensor and SEP. Outside of superpowers even if you're willing to do it destructively.

They can then sign their own fraudulent images.

> Nation states almost certainly have the ability to extract the private keys out of an image sensor and SEP. Outside of superpowers even if you're willing to do it destructively. They can then sign their own fraudulent images.

That's not how this works.

Let's pretend they're able to extract the sensor key and the SEP key. Then what?

An attacker won't have the ECDSA P-256 over SHA-256 signed timestamp token from the Apple Push Notification Service.

When Reference mode starts, the operating system supplies a SHA-256 digest to be embedded at a fixed location in the captured frame’s metadata. The digest is computed from the most recent secure timestamp, the device manifest, and the device's secure boot manifest.

More encryption and checking happens until the secure digital negative is sent to Private Cloud Compute:

    PCC recomputes the digest embedded in the frame and verifies the
    sensor's signature over the pixels and that digest, verifying the
    certificate chain back to the sensor CA. PCC also verifies the SEP
    signature and chains it to the BAA CA, and it verifies the signature
    on the device manifest and chains it to the CA that signs device
    manifests at the factory. It then confirms that the sensor and SEP
    named in those chains belong to the same device. Only if all these
    checks pass does processing continue.

Only PCC can create an Apple Reference Image; an attacker having the image and sensor private keys doesn't enable them to create a reference image.

> An attacker won't have the ECDSA P-256 over SHA-256 signed timestamp token from the Apple Push Notification Service.

Sure they can, they have everything needed to prove to Apple's servers that they're a real iPhone since pulling the keys means they have the cryptographic root of trust, and Apple's servers will happily be a signature oracle for them in that case.

> When Reference mode starts, the operating system supplies a SHA-256 digest to be embedded at a fixed location in the captured frame’s metadata. The digest is computed from the most recent secure timestamp, the device manifest, and the device's secure boot manifest.

And when you know what is measured into those manifests and the keys at the root of trust you can manufacture those too.

The entire scheme is dependent on not being able to extract device specific keys. At the end of the day, those are almost certainly efuses burnt based on a on-chip HRNG as a manufacturing step which is intended to never leave the device, but instead only signatures and associated public keys.

But when you have chip development hardware of the kind you'd have at a decent fabless semiconductor company, you can very clearly see burnt efuses.

I made a flow chart of the Apple Reference Image process; hopefully it clears up some misconceptions [1].

[1]: "How pixels become an Apple Reference Image" - https://news.ycombinator.com/item?id=49735284

That matches what I said.

The NSA has probably already forced Apple to hand the keys over to them.

Apple would be legally restricted from disclosing any government compromises, while still claiming their systems are secure and operating as intended in general.

We already know it's happening right now, and they know we know, but we can't do shit about it.

> Apple would be legally restricted from disclosing any government compromises, while still claiming their systems are secure and operating as intended in general.

I'm aware. The point is they can't give the NSA something they don't have. The photo sensor generates its own ECDSA P-256 signing key pair and never releases the private half.

Every device has a unique key pair and the private key is unavailable… there's not a way to give the NSA that would help them. The system is setup so that the image data, meta data, etc can't be accessed by anyone including Apple.

I believe them, but the process is hard to check. How do we verify that they don’t have the sensor burn in a private key generated by them?

(Similar to how many PGP hardware keys allow generating a private key on-device or writing your own provided key.)

Here's a flow chart; tell us at what point there's something Apple can be compelled by a 3-letter organization to produce: https://news.ycombinator.com/item?id=49735284

I think the chart exactly shows the weakness that some people have pointed out. Apple's PCC servers at some point in time know the signing identity for a photo and Apple's generated replacement signature. The relevant steps from your chart:

- verifies each link and its certificate chain, sensor signature over pixels, SEP signature, device manifest signature

- PCC Submits the commitment (the JPEG hash) to Apple's signing service.

So, at some point in time, Apple's servers have both the original certificate chain and the new replacement signature. If this is recorded, Apple can deanonimize photos and check whether two photos were from the same device/sensor.

Apple's system protects against most state actors, except Apple and the US, unless you fully trust that their PCC is watertight.

(Remember that Apple was part of PRISM and probably also its successor.)

I don't think law enforcement needs it, because when sending/posting a picture, people leak so much metadata anyway.

But people outside the US should certainly distrust these systems.

> The NSA has probably already forced Apple to hand the keys over to them.

Again, that's not how it works.

There's no set of keys and certificates they could give to the NSA. Every iPhone 18 Pro and Pro Max has a unique set of cryptographic keys, most of which can't be accessed by Apple.

The first thing that happens is when photo sensor is initialized at the factory, it creates its own ECDSA P-256 signing key pair; the private key is never disclosed. The public key is signed by the factory's certificate authority.

This ain't X.509 where VeriSign's key pair is sitting in a HSM at their HQ and in theory could be forced to sign a fraudulent certificate or revoke someone's valid website certificate.

They don’t need the signing keys though. Apple could roll out a separate version of sepOS to assist law enforcement that signs at they will.

Also, while the unique device ID is supposed to be burned into fuses by the SE during production, it is kinda hard to prove for anyone that is not Apple that this indeed happens in the way they state.

Personally I’m not a strong believer in such theories though. I think it’s more mundane and Apple helps law enforcement by having some weak defaults. Like how iMessage is end-to-end encrypted, but most chats are available to law enforcement because most people turn on iCloud Backups/Messages in iCloud and not ADP, resulting in chats only being encrypted at-rest in iCloud. This is only stated somewhere in a footnote in one of their security documents.

There are more weak defaults like that in various crucial apps (e.g. WhatsApp) that makes most important stuff available to law enforcement when needed.

<< Apple Reference Image is not an id system;

I think you have a point. I would only note that just because it is not explicitly designed as one, does not mean it will not be effectively utilized in that manner.

How is stealing/extracting a private key alien technology? Or even more simple, subpoena a private key to create fake authentic compromising pictures of pesky political opponents.

You seem to have it wrong. You don’t need an identification system for these use cases, you only need exactly what the tech does.

Looks like you saw the word ID and went off. OP never called it an ID system

I can tell its 'shopped because of the pixels