Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PoC LockZKP #29

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

PoC LockZKP #29

wants to merge 1 commit into from

Conversation

rohanjacin
Copy link

This is a PoC for a protocol to authenticate a smart lock on the blockchain using Zero knowledge proofs.

The following assumptions are made

  1. The lock is simulated as a nodejs process running javascript, but in the real world the code can be converted to native C or C++ to run on an SoC like [nrf5340] (https://www.nordicsemi.com/Products/nRF5340) with h/w cryptocell to execute the equivalent of the npm crypo libs (basically ECC point addition and regular stuff like hashing, Key derivation etc).
  2. The guest needs to be in vicinity of the lock for the authentication process to take place once. But most likely in all use-cases like AirBnB check-in etc that's how it happens (PIN is provided on the day of check-in if not 1 day prior).
  3. The lock is not connected to the internet/blockchain, this is advantageous in remote areas and reduces cost.

I developed the code for the frontend, backend and smart contract. Although the frontend is pretty rudimentary and is incomplete as a product, as this is only a PoC. It can be worked on in the future. The backend runs locally on the owner's laptop, this is very the security handshake and owner proof generation happens; in production it needs to be better designed for scalability in case the owner has multiple listings.
For the guest proof generation ive used semaphore- protocol for group membership, also the assumption here is that the member secret is shared by the owner to the guest via off-channel mechanism like Telegram/Email etc.

Signed-off-by: Rohan Jacinto <[email protected]>
@Divide-By-0
Copy link
Owner

This is a PoC for a protocol to authenticate a smart lock on the blockchain using Zero knowledge proofs.

The following assumptions are made

  1. The lock is simulated as a nodejs process running javascript, but in the real world the code can be converted to native C or C++ to run on an SoC like [nrf5340] (https://www.nordicsemi.com/Products/nRF5340) with h/w cryptocell to execute the equivalent of the npm crypo libs (basically ECC point addition and regular stuff like hashing, Key derivation etc).
  2. The guest needs to be in vicinity of the lock for the authentication process to take place once. But most likely in all use-cases like AirBnB check-in etc that's how it happens (PIN is provided on the day of check-in if not 1 day prior).
  3. The lock is not connected to the internet/blockchain, this is advantageous in remote areas and reduces cost.

I developed the code for the frontend, backend and smart contract. Although the frontend is pretty rudimentary and is incomplete as a product, as this is only a PoC. It can be worked on in the future. The backend runs locally on the owner's laptop, this is very the security handshake and owner proof generation happens; in production it needs to be better designed for scalability in case the owner has multiple listings. For the guest proof generation ive used semaphore- protocol for group membership, also the assumption here is that the member secret is shared by the owner to the guest via off-channel mechanism like Telegram/Email etc.

Hey -- cool idea. I'm not sure I fully understand; what exactly does the smart lock do in this setting? Why don't you just allow the owner to add certain ENS addresses or Eth addresses to an allowlist, then emit a merkle tree of that to the users (or let the user do PIR on the tree for the Merkle path), then let the user's phone make a zk proof that they are in the Merkle tree, then use that to unlock the door?

In general, these kinds of physical solutions are very hard because the actual mechanism of actuating the lock is fundamentally driven by a certain power output for a certain time, and someone could just go into the mechanism or lock and deliver that power (so to match the security of a physical lock, the casing of any power delivery inputs to the lock must be as secure as the lock itself).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants