TL;DR
In today's digital world, it's hard to distinguish between real and fake content. We need a way to certify if something came from a real camera that can't be forged. We verify that images are authentic using the magic of zero-knowledge cryptography and blockchains.
Inspiration
In the past, trust in the digital world was simple: a picture was a snapshot of reality. Today, that's no longer true. Generative AI is completely disrupting our relationship with authentic content. In today's digital world, anything is possible: from dogs hosting podcasts on mountains and the pope wearing puffers. Just this past week, we've seen the hyper realistic videos Sora is capable of producing; people are already falling victim to deepfakes. Soon, it will be impossible to distinguish what is reality and what is fiction.
It's time to separate what's real from what's fake. We need a solution that is practical, uncensorable, and unforgeable. That's where the the power of zero-knowledge and blockchains come in. Cryptography is the only way to ensure that the content we see in the digital world is real. We want to live in a future rooted in truth, not trust.
But this is a difficult task. Signing images with a cryptographic signature is a promising way to verify that content is taken from a camera and not created by AI: Cameras have a private key in their hardware that signs an image when it is taken. However, there are only a few cameras on the market with the necessary hardware to support these cryptographic signatures — not to mention that they cost upwards of $9,000. Furthermore, the signature becomes invalid when the photo is transformed in anyway. This is a huge problem for media organizations who want to crop an image, photographers who want to prove the veracity of their pictures, sites that need to compress image files, or just everyday people who want to brighten their portrait a touch. Finally, it is currently impossible for any individual to simply verify the authenticity of an image, as the public keys signing images are not in a publicly accessible space.
What it does
We built a more practical way to verify that an image was taken by a real camera (and not AI-generated), using next-generation cryptography to create the first end-to-end verifiable image pipeline. From the point at which an image is captured on your iphone, through any image edits, and finally when the image is posted somewhere in the digital world, anyone can verify that the image is real using the power of cryptographic signatures and zero-knowledge proofs. These cryptographic signatures serve as certificates that content is authentic, i.e. that an image was taken by a camera, and cannot be forged.
*We have included a "Crypto FAQ" down below to define cryptography terms.
How we built it
The three main components of our project were verifiable image capture, image transformation, and the image's existence in the world.
(1) Image Capture: We created a POC iphone app that uses Apple's Secure Enclave Storage API to generate a private key to cryptographically sign images taken with the iphone, which serves as an attestation that the image was taken by a hardware device. This private key cannot be extracted from the Secure Enclave so it is the most secure way to verify an image's authenticity. Our app then uploads the image, the signature, and any transformations to our ZK prover node to compute and store a zero-knowledge proof of verifiability. We store all registered iphone public keys in a merkle tree and post a merkle root of these public keys so that anyone can verify the authenticity of the image source without revealing which device actually took the image.
(2) Image Transformation: We created an image editor library that verifies the initial signature as well as allows the authenticity of an image to be verified even through (reasonable) edits. We use the power of zero-knowledge cryptography to allow the image authenticity to be verified without revealing the actual edits performed / having to replicate them yourself. We created the first-of-its-kind Rust library that performs the image transformations in the state-of-the-art zkVM (SP1) and produces a ZK proof along with the edited image. In order to ensure that someone doesn't just edit every pixel of the image, we defined a set of reasonable image transformations (e.g. rotate, brighten, crop) that image-editor library supports. We also verify the image's ECDSA signature in the circuit before applying transformations.
(3) Image Existence: When an image is uploaded to the internet, it includes metadata that contains the image signature. To ensure that both the iphone that took the image is verifiable (to ensure that a camera took the image, not AI-generated) and that the ZK proof outputted by the image transformations is verifiable, we store a merkle tree of registered iphone public keys and the ZK proofs on-chain. Blockchains are quite important as a storage mechanism here because they are transparent, uncensorable, and decentralized. Anyone can verify the published signatures /proofs and no one can tamper with them (decentralization is important in the presence of adversarial centralized parties for example).
Challenges we ran into
(1) Apple hardware: The only way to truly securely authenticate a public key is from an iPhone is for Apple to store a private key in the hardware's secure enclave and publish a Merkle root of iPhone public keys to a public database. However, Apple does not do these things. This is why we used Apple's secure storage API to generate a private signing key and uploaded the public key onto the blockchain. However, Apple does authenticate code that runs on the iPhone using its private keys so we do have some security guarantees that people are unable to interfere with the protocol.
(2) Rust: The ZK image verification and transformation library was difficult to build in such a short timeframe. This was our first time developing something in Rust that wasn't printing "Hello World." We had to go through quite a bit of the official Rust documentation in order to build out the library, as well as deeply understand the inner-workings of the zkVM.
(3) Newly released zkVM: Because the SP1 zkVM was released just this past week (Feb. 14th), we ran into a few challenges while building our image-editor Rust library. For example, for one of the Rust crates we were using, image-rs (handles image processing), there were a few functions that the crate used that wasn't supported in the zkVM, such as "round" and "roundf". Thus, we had to implement those functions ourselves and make the compiler use our local implementations of those functions.
Because SP1 and the whole ZK community is quite open source forward, we were able to add PRs to the SP1 repo that helped address some of the challenges we faced while using the zkVM / docs — which we hope will help future developers in the ZK community :)
Accomplishments that we're proud of
We were honestly quite surprised that we were able to create a whole ZK library in just 36 hours — as well as integrate the library into a compatible iPhone app, launch a ZK prover node, and create accompanying smart contracts to add the keys and proofs on-chain. As a team who is generally very excited about crypto, we were excited to make use of cutting-edge developer tools in the space (like SP1 and QED) and participate in the open-source dev culture.
We also didn't think it was possible to sign images taken by an iPhone (since it's dependent on the iPhone's private key), so we are really happy that we were able to find an actually cryptographically secure and verifiable solution!
What we learned
We had some theoretical cryptography background coming into TreeHacks, but in order to develop the image verifier library using ZK in such a short time, we decided to use the new state-of-the-art zkVM, SP1 (announced just this past week)! Since this was our first time using Rust, we learned a lot about the nitty gritties of the language but came out as proud Rustaceans.
This whole experience has made us very hopeful about the future of verifiable computation and the open source ZK community. A big thank you to SP1 and QED protocol specifically for their contributions to the ZK developer space!!
What's next
Verifiability, transparency, and security are of utmost importance in today's digital world. We hope that our project is a call to action for companies like Apple to add hardware that support signatures on images (and eventually video). We are excited to see what is next for attested images with zero-knowledge proofs! We have already made the crate available for the open source community.
Crypto FAQ
Q: What is a cryptographic signature? A: Cryptographic digital signatures use public key algorithms to provide data integrity. When you sign data with a digital signature, someone else can verify the signature, and can prove that the data originated from you and was not altered after you signed it.
Q: What is a public key and a private key? A: A private-public key pair is a pair of cryptographic keys assigned to an entity where the private key is not known to anyone and the public key is known to everyone. The private key is used to sign data to produce a digital signature and the public key is used to verify the signature.
Q: What is a zero-knowledge proof? A: A zero-knowledge proof is a way to mathematically prove a claim in constant time without revealing any evidence for that claim. In our case, we prove that an edited image is authentic without revealing the initial image or the edits. Zero knowledge proofs form the basis for new blockchain scaling technology (zk rollups) such as QED protocol.
Q: What is a merkle tree? A: A merkle tree is a data structure frequently used in cryptography to prove that an element is part of a set without revealing the contents of the set (via a merkle proof). This is encoded in a merkle root, which is cheap to publish to the blockchain.
Log in or sign up for Devpost to join the conversation.