The problem Proof of Physical Item solves

A set of commodity NFC chips exist currently (namely the NTAG 413 and NTAG 424) that use an on-device AES key, auto-incrementing read count, and UID to generate an AES-CMAC SUN message that can be used to verify the chips authenticity and uniqueness. As the reader needs to be within an intimate distance of the chip to receive the data, and the data changes on each read, it is can be assumed that each set of (UID, Count, SUN) is a unique, physical interaction. This allows a framework of products for physical+digital services, such as logistics tracking, authenticity of high end items, proof of physical presence, etc.

Unfortunately the message signature is computed with AES to best operate on these ultra low power chips. As AES is a symetric key encryption system, until now centralized services were required to be available to host and trusted to validate the signature.

By implementing the message signature verification in a ZK proof, a number of the concerns and issues with the current state of the chips is resolved. First, because the proof binary and receipt can be generated by distributed networks or local devices, availability of a third-party oracle is no longer a concern. Second, as the private key can be burned into the proving software at deployment, a smaller group of trusted parties is required, namely only the party that built and deployed the binary.

Challenges I ran into

Challenges around key privacy: Unfortunately the ability to handle private state is still a problem in smart contracts and ZK proofs. Ideally, there would be a way to deploy the proving binaries in a way that the key would be available as a private input into a general program, but that currently isn't the case with any ZK solution I have seen so far.

To get around this, chips will be deployed in batches, where a number of them are coded into a map in a distinct proving binary. This isn't ideal as external organization data will be need to map which chip can be proved with which prover, but this is attainable. Also, as physical products generally get manufactured in batches, it isn't as big an issue as with purely digital products.

In theory, a malicious Risc0 proving host could attempt to halt the prover execution to inspect the stack and try to extract the AES keys. Solving this issue is likely outside the scope of a hackathon, and probably depends on economic and implementation specifics of the product using the chips, the network of host provers, etc.

Challenges around testing:
I have a handful of NTAG 424 chips that I used to generate UID, Count and SUN signatures for testing the Risc0 host+guest program. In practice, the chip provides these as URL parameters to a device which reads the chip, opening in a browser. A more dedicated product would probably point the chip URL to a web app that retrieves and verifies the proving binary and runs it on the device. For testing, I simply copied the values into my

host

code definition in the repo, and ran it there.

I would be happy to provide a chip to the judges if they would like to play with this themselves.