Video evidence is relatively easy to fix, you just need camera ICs to cryptographically sign their outputs. If the image/video is tampered with (or even re-encoded) the signature won’t match. As the private key is (hopefully!) stored securely in the hardware IC taking the photo/video, any generated images or videos can’t be signed by such a private key.
So whatever way the camera output is being signed, what’s stopping you from signing an altered video with a similar private key and then saying “you can all trust that my video is real because I have the private key for it.”
The doubters will have to concede that the video did indeed come from you because it pairs with your key, but why would anyone trust that the key came from the camera step instead of coming from the editing step?
You can enter the camera as evidence, and prove that it has been used for other footage. Each camera should have a unique key to be effective.
So if you create a new key, it won’t match the one on am existing camera. If you steal the key, then once that’s discovered, the camera should generate a new one.
You, the end user, don’t have access to your camera’s private key. Only the camera IC does. When your phone / SD card first receives the image/video it’s already been signed by the hardware.
It’s pretty standard practise these days to have some form of secure enclave on an SoC - Arm’s TrustZone, Intel’s SGX, AMD’s SME/SEV. This wouldn’t be any different. Many camera ICs are already using an Arm CPU internally already.
getting the picture to perfectly replicate the image on the screen without it being noticeable that it’s just a picture of a screen would be so difficult it would probably be easier to modify the camera instead
Video evidence is relatively easy to fix, you just need camera ICs to cryptographically sign their outputs. If the image/video is tampered with (or even re-encoded) the signature won’t match. As the private key is (hopefully!) stored securely in the hardware IC taking the photo/video, any generated images or videos can’t be signed by such a private key.
So whatever way the camera output is being signed, what’s stopping you from signing an altered video with a similar private key and then saying “you can all trust that my video is real because I have the private key for it.”
The doubters will have to concede that the video did indeed come from you because it pairs with your key, but why would anyone trust that the key came from the camera step instead of coming from the editing step?
You can enter the camera as evidence, and prove that it has been used for other footage. Each camera should have a unique key to be effective.
So if you create a new key, it won’t match the one on am existing camera. If you steal the key, then once that’s discovered, the camera should generate a new one.
You, the end user, don’t have access to your camera’s private key. Only the camera IC does. When your phone / SD card first receives the image/video it’s already been signed by the hardware.
so you want the hardware to be significantly more opaque and almost impossible for new manufacturers to compete?
It’s pretty standard practise these days to have some form of secure enclave on an SoC - Arm’s TrustZone, Intel’s SGX, AMD’s SME/SEV. This wouldn’t be any different. Many camera ICs are already using an Arm CPU internally already.
deleted by creator
Wouldn’t this be as easy to break as to point a camera at a screen playing whatever you want?
Perhaps not with light field cameras. But then you could probably tamper with the hardware somehow.
getting the picture to perfectly replicate the image on the screen without it being noticeable that it’s just a picture of a screen would be so difficult it would probably be easier to modify the camera instead