[teaearlgraycold]

There's been a slow march to requiring hardware-backed security. I believe all new devices from the last couple of years need a TEE or a dedicated security chip.

At least with Android there are too many OEMs and they screw up too often. Bad actors will specifically seek out these devices, even if they're not very technically skilled. The skilled bad actors will 0-day the devices with the weakest security. For political reasons, even if a batch of a million devices are compromised it's hard to quickly ban them because that means those phones can no longer watch Netflix etc.

[dataflow]

But you don't have to ban them for this use case? You just need something opportunistic, not ironclad. An entity like Google could publish those devices' certificates as "we can't verify the integrity of these devices' cameras", and let the public deal with that information (or not) as they wish. Customers who care about proving integrity (e.g., the media) will seek the verifiable devices. Those who don't, won't. I can't tell if I'm missing something here, but this seems much more straightforward than the software attestation problem Android has been dealing with so far.

[johnny22]

Woudln't that prevent most folks from being able to root their devices without making the camera lesser than everyone else's camera?

[dataflow]

What does this have to do with root? The camera chip would be the one signing the data flowing through it, not the Android kernel.

[8note]

If you do a jpeg compression, or crop the file, then does that signature matter anymore?

[A1kmm]

Cryptography also has answers for some of this sort of thing. For example, you could use STARKs (Succinct Transparent Arguments of Knowledge) to create a proof that there exists a raw image I, and a signature S_I of I corresponding to the public key K (public input), and that H_O (public input) is a hash of an image O, and that O is the output of providing a specified transformation (cropping, JPEG compression) to I.

Then you give me O, I already know K (you tell me which manufacturer key to use, and I decide if I trust it), and the STARK proof. I validate the proof (including the public inputs K and H_O, which I recalculate from O myself), and if it validates I know that you have access to a signed image I that O is derived from in a well-defined way. You never have to disclose I to me. And with the advent of zkVMs, it isn't even necessarily that hard to do as long as you can tolerate the overhead of running the compression / cropping algorithm on a zkVM instead of real hardware, and don't mind the proof size (which is probably in the tens of megabytes at least).

[dataflow]

Not if you do it, only if the chip also gives you a signed JPEG. Cropping and other simple transformations aren't an issue, though, since you could just specify them in unsigned metadata, and people would be able to inspect what they're doing. Either way, just having a signed image from the sensor ought to be adequate for any case where the authenticity is more important than anesthetics. You share both the processed version and the original, as proof that there's no misleading alteration.

[chii]

> You share both the processed version and the original, as proof that there's no misleading alteration

so you cannot share the original if you intend to black out something from the original that you don't want revealed (e.g., a face or name or something).

The way you specced out how a signed jpeg works means the raw data _must_ remain visible. There's gonna be unintended consequences from such a system.

And it aint even that trustworthy - the signing key could potentially be stolen or coerced out, and fakes made. It's not a rock-solid proof - my benchmark for proof needs to be on par with blockchains'.

[johnny22]

ah. I thought it'd be more in the vein of safetynet, but guess not.