Add support for active authentication

zk-passport / proof-of-passport

Proof of passport protocol using zk-SNARKs

https://proofofpassport.com

245 stars 32 forks source link

Add support for active authentication #62

Open 0xturboblitz opened 4 months ago

0xturboblitz commented 4 months ago

Right now, we only use passive authentication by checking the passive attestation placed by country signing authorities in the SOD file. This has a drawback: it's possible for an attacker to copy the data and generate a proof of passport without physically owning the passport anymore.

We want to support active auth and/or chip auth. See country coverage here. The active auth pubkey is in the DG15 of the SOD file which can be easily checked like the DG1 is currently.

The FreedomTool team has worked on this in circom.

It's apparently also been done in Noir by Michael here.

hero5512 commented 2 months ago

How can we identify a passport holder exectly own this passport? Can we authenticate the public key of the passport holder in chip by using active authentication?

0xturboblitz commented 2 months ago

Hi, There is no biometric check or password so we have to assume the person that physically owns the passport is the holder. With active authentication, the passport's public key is hashed in the DG15 with is then signed by the issuing authority, so we can authenticate the validity of the public key.

hero5512 commented 2 months ago

OK, thank you

hero5512 commented 1 month ago

Just found another problem about the active authentication. The length of the challenge to be signed is just 8 bytes which is not enough for most use cases. Do you have any idea about this problem?

0xturboblitz commented 1 month ago

Hi If there is no way of signing more data at once, my guess is doing multiple signatures to cover a whole hash.

hero5512 commented 1 month ago

I think the problem is that an attacker may be able to combine four signatures for 8 bytes. And then pass all the signatures verification step.

0xturboblitz commented 1 month ago

Very interesting question. My guess is the following:

if implemented in a circuit, the signatures can be passed as private inputs so this is not a problem. You would reconstruct the 32 bytes sha-256 transaction hash in the circuit from 4 signatures of 8 bytes
if implemented in solidity, as long as the hash function is preimage-resistant this should not be a problem either. The number of possible rearrangements grows as (4n)^4 but finding a meaningful preimage still looks infeasible.