openmic.social is an uncensored community. You may encounter strong language, controversial opinions, and mature or NSFW material. You must be 18+ to browse. Illegal content is prohibited and removed on sight — please report it. By continuing, you accept that you may see content you personally disagree with.
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?
Mate, digital cinema uses this encryption /decryption method for KDMs.
The keys are tied into multiple physical hardware ids, many of which (such as player/.projector ) are also married cryptographically. Any deviation along a massive chain and you get no content.
Those playback keys are produced from DKDMs that are insanely tightly controlled. The DKDM production itself even more so.
And that’s just to play a movie. This is proven tech, decades old. You’re not gonna break it with premiere.
This is for restricting use, not proving authenticity of the videos recording. Anyone can spin up keys and sign videos, so in a legal battle it would be worthless.
The technology would be extremely easy to adapt, with the certs being tied to the original recording equipment hardware. Given i don’t see a $60 ip cam having a dolphin board it would probably be relegated to much higer end equipment, but any modification with a new key would break the chain of veracity
This is blatantly not true, it would be extremely simple to circumvent. How do you “tie” the cert to a specific hardware without trusting manufacturers? You just can’t, it’s like putting a padlock on a pizzabox.
As with everything, trust is required eventually. It’s more about reducing the amount of trust required than removing it entirely. It’s the same with HTTPS - website certificates only work if you trust the root certificate authorities, for example. Root manufacturer keys may only be certified if they have passed some level of trust with the root authority/authorities. Proving that trust is well-founded is more a physical issue than an algorithmic one. As it is with root CAs it may involve physical cybersecurity audits, etc.
But how would one simple member of the audience easily determine if this whole chain of events is valid, when they don’t even get how it works or what to look out for?
You’d have to have a public key of trusted sources that people automatically check with their browser, but all the steps in between need to be trusted too. I can imagine it is too much of a hassle for most.
But then again, that has always been the case for most.
This is just standard public key cryptography, we already do this for website certificates. Your browser puts a little lock icon next to the URL if it’s legit, or provides you with a big, full-page warning if something’s wrong with the cert.
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.