I don't understand how this avoids any simple attack both for audio or video:<p>- Alter/manipulate the audio/video has much as you want.<p>- Play it.<p>- Have a "attested" microphone/video recording the "manipulated audio/video".<p>For video maybe you can actually try to prove that's recording a screen not the real event, but seems much harder for audio, you can just say the echos/ distortions came from the environment...
I would say there is a better way of doing this. In the forensic community it has been long known that audio can be timestamped and fingerprinted by the 50/60hz electrical hum in the background. In many countries this hum is recorded so it can be used later as evidence.<p>Unless counter-forensics are applied, AI audio is not going to have the right hum.<p>It’s not cryptographically secure, but it gives good assurance and doesn’t require tamper resistant hardware (which makes the cryptographic security dependent on how secure the resident keys are)<p><a href="https://en.m.wikipedia.org/wiki/Electrical_network_frequency_analysis" rel="nofollow noreferrer">https://en.m.wikipedia.org/wiki/Electrical_network_frequency...</a>
> The hardware manufacturer can destroy the private key after it is placed on the device. By doing so, the private key is inaccessible!<p>I'm pretty sure the private key is very accessible, if it's used at runtime which it is. Just not easily.
> In our setting, we can compute a function that computes the hashes of the inputs and outputs the edited audio from the inputs. By revealing the hashes, we can be assured that the inputs match the recorded audio!<p>I don't understand how this works, or what exactly is being proven here. For instance, you could silence the given inputs and inject some other unrelated audio, so the fact that your output hash incorporates the input hashes doesn't seem very meaningful.<p>I figure I must be missing something here.