ZK10: ZK Microphone - Hardware Attested Audio - Eito Miyamura

Transcript

Um hey guys. So, I'm Eito. Um and I'm going to be talking about ZK microphones, which is sort of a beginning to a solution against deep fakes in this world where the cost of content generation is moving down to zero. So, deep fakes um already have a potential to pose a state-level um threat to society. Uh you can see examples of for example, Trump getting arrested or pictures of that. The Zelensky deep fake that's telling the Ukrainians to retreat because, I don't know, Zelensky's uh surrendered to Putin. And just a lot of reverse um porn sorry, revenge porn deep fakes as well.

Uh that's really ruining the lives of many women. Um so, the naive solution that you can come up with for uh how to protect uh and verify authenticity and provenance of content is just having cryptographic signatures uh embedded within the audio. So, for example, for microphone, uh you might have a secret key uh that is in the secure enclave of the microphone. And then, you would essentially sign the uh audio. And using public key cryptography, you can verify that um a particular audio that was signed with the secret key was indeed recorded on that particular microphone uh and verify the hardware authenticity.

So, you know that a given audio was indeed recorded with a specific microphone. Now, there are a few issues with this. Um one of the issues is like, "Okay, well, let's say there was background noise uh in the audio." Then, you can't do anything about it. Like, you if you try and edit it out, it just destroys the signature. Uh you know, if there was confidential information that was mentioned uh in the audio, then, you know, you can't uh censor that or bleep that out. And you also can't run compression algorithms to essentially make the audio um more sort of yeah, storage efficient. Uh and so there's been a rise um by a coalition of companies, namely like Microsoft, BBC, Intel, Sony, etc. um of a rising

standard called C2PA, which is essentially, okay, you do this whole like um signature thing on a hardware level, right? So, you still sign the audio with um some kind of secret key, uh but then, you know, let's say uh you like have an audio recorded and you want to bleep out some stuff. Uh well, you will use some kind of audio uh editing software uh provided by the coalition, and then you will basically say, "Hey, I edited this audio like this." And send that to the coalition, and the coalition will like sign the audio for you to verify that the edit was done correctly, so that you can, you know, compress your uh audio files, you can bleep out um sensitive information, uh and etc. Um

and then verify the hardware authenticity uh by verifying both the hardware signature as well as the proof of edit signature, which is provided by the C2PA coalition. And this is generally considered to be, uh you know, in the original web 2 world to be the solution against deep fakes. Um there are issues with the C2PA standard, namely it's just the fact that it's extremely centralized between the coalitions of the Microsofts, the Adobes, and the like. Uh and, you know, you end up with the situation where you the the power is centralized between the coalition. Uh you don't have censorship resistance, you know, if Microsoft wanted to censor something, uh they can

totally do that. And you also don't have this end-to-end encryption, so user uh sort of user privacy is violated by the C2 uh C2PA coalition. And so, uh that's why we came up with ZK Microphone as a initial step towards solving this deep fake problem as well as the problem of centralization with standards like C2PA. And we actually became the most engaged ETH Global project of all time. And yeah, this here is like the actual microphone we built. So, what we built was essentially a Raspberry Pi like hardware microphone where you have the signature

on the Raspberry Pi and then we built also an editing software. So, how it worked broadly was okay, so you still have you know, the Raspberry Pi and the microphone and you just like do the signature using the secret key stored in there. The Raspberry Pi was supposed to sort of substitute for a secure enclave. And then you have some kind of video editing operation. In our demo, we just had it so that you can um like bleep out let's say I think 1 second of the audio. And then you just create a zero knowledge proof, right? Of the bleeping operation such that it preserves two properties.

So, number one, you want it to be privacy preserving. So, when you bleep out the audio, you want it to be the case that you don't know what was said in the original thing. And signature preserving. So, it preserves this original digital signature that was signed on the audio. So, you can verify that it was edited correctly and that it came from a legit microphone. And then you get around the C2PA um sort of centralization problem by essentially storing the audio and the signature so the proof of edit into IPFS and then just verify on like a layer two or a layer two sorry, a layer one or a layer two

which you assume to be sufficiently decentralized. Um, think one of the coolest uh technological innovations we've made uh while we were developing ZK microphone was essentially by optimizing the proof generation time by operating the proofs in the hash space rather than the actual audio files themselves. So, we were using like WAV files because they had nice properties. Uh but the problem is uh the file sizes got pretty big pretty quickly. So, something like 5 seconds of audio would be something like 500 kilobytes. Uh and trying to run ZKPs on that was extremely extremely slow. So, what we did was essentially you have the original WAV file, you would um use this

particular uh hash function, the poly hash function, um to essentially turn it into a hash, and then you would generate zero knowledge proofs um of the composed transformations that you run on the audio, uh and then generate the proof as well as the subsequent edited audio. And the reason why uh this is great is because well, for one, it shortened the proof time from something like 5 hours to 5 seconds. And the other thing is because you're operating on the hash space, um this sort of the data size that you operate on here is all constant size, which means it also extends very nicely to, you know, other types of uh larger media

files such as um video or photo or any kind of other um senses that you can have um and no matter how big they are, you compress them into the exact same um size hash of 256. Uh and so, you can run these uh composed transformations uh in a way that's still um is ZKP uh like uh I guess preserved. Uh and generate the proof in exactly the same time. So, those are some of our main innovations.

Uh and then where we're sort of uh going with this um potentially is to build like open standards um unlike C2PA, which is um extremely centralized, uh to essentially build a open standard that people can use on the internet to make sure provenance of content on the internet. And you can contact uh these guys uh here uh to get in touch uh to talk about content provenance. And that's it. THANK YOU VERY MUCH. DO YOU WANT THIS ONE?

UH I THINK WE GOT IT NOW. Thank you. Uh thank you very much for the talk. Any questions on that? One, two. That's it. First bidders. Let's start with you. Yep. Okay. Um I might have missed this, but when you were talking about operating in the hash space, don't you need to know how your video I'm sorry, how your audio editing transformations operate in hash space? Like don't you in effect need to be able to commute taking a hash and performing the transformation?

Yeah, um exactly. So, that's why we used um this particular hash function and like the specific um like operation that we did, which was just like zeroing it out the bits. Um you would need to be a bit more clever in the way you like uh engineer the hash space so that you as you said, you have the commutativity. Um but you can design different hash functions uh depending on what kind of operations you would need to do. Uh and then I think you can get around that problem. Cool.

Uh couple of unrelated questions. The first one was, um, are you using something like recursion to compose the transformations? And second question was, have you had much engagement yet with trying to build these open standards? Uh, yeah. Um, we're not using any recursion. I mean, we kind of uh, we wrote all of the circuits just using Noir, um, without any of like the private public state um, like functionality. We just used as a basically a Circom, um, like substitute.

Uh, and then as for the uh, open standard, uh, it's not something that I'm putting personally a lot of time into, but um, I think I think it's interesting as a countermeasure uh, to the coalition. And you know, C2PA is still this very like niche thing that's only known between like web enthusiasts. Uh, and I think there will be space to uh, where that would make sense. Uh, especially due to sort of like intercompany politics uh, between let's say the Microsofts and some other competitors and stuff like that. Uh, because this um, the C2PA uh, it's it's quite subtle, but it's actually like uh, if C2PA works, um, it effectively gives a power to like these coalition

companies to determine what is true and what is false. And that's sort of a uh, asymmetric power that probably shouldn't be controlled by any singular entity. Well, in this case it's a oligopoly. We actually have time for one more. Wonderful. How it like you mentioned this confidentiality and this peer-to-peer? Like how are you achieving that in this mechanism of hashing then applying editing transformations and getting a proof?

Sorry, what do you mean? Could you I You mentioned this the problem of confidentiality that you don't want to reveal the whole audio, but you want to reveal the proof. Like how is this method like achieving that? By going into the hash space and then like applying the Got it. Got it. Um yeah, the hash space uh where is it? Yeah, the hash space stuff is just a optimization um to like make it faster, but like just imagine we don't do any of this hash stuff. Uh it's just a straightforward like zero-knowledge proof of computation where the zero-knowledge element is the like the privacy preservation where you don't know what you cut out.

Uh and then like the succinctness is just like, you know, when you submit the proofs on chain. And then like yeah, the the way to think about the hash function uh the hash space thing is basically we just do it so that you're operating on like a fewer absolute on an absolute basis of fewer number of bits, but you also know that like uh the hashes and the audio match and there's a one-to-one mapping assuming that there is no sort of hash collisions between different audio files. Yeah?

Wonderful. Can I quickly ask, does it work This works then for highly compressed audio, too? Sorry? Does this work for compressed audio in the end? Uh so for compressed audio, I think it will be a bit more complicated, but as long as you come up like with with the appropriate hash function, you should be able to. Like we iterated uh we spent majority of the time actually working on the appropriate hash function such that it's like um it preserves the right properties uh with like the specific edit operations that we were doing. And you just like need to make sure that the commutativity holds uh when you're doing these um up like the specific operations. I I don't know how audio compression algorithms work, admittedly, but you

would make it so that like the commutativity like halts. That's fascinating. Well, keep us posted. I think CK podcast needs to be the first ones to use those mics. Yeah. So, yeah. Thank you very much for coming too.