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

Add support for active authentication #62

Open
0xturboblitz opened this issue Feb 21, 2024 · 9 comments
Open

Add support for active authentication #62

0xturboblitz opened this issue Feb 21, 2024 · 9 comments
Labels
help wanted Extra attention is needed medium

Comments

@0xturboblitz
Copy link
Member

0xturboblitz commented Feb 21, 2024

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.

See here too.

@hero5512
Copy link

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
Copy link
Member Author

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
Copy link

hero5512 commented May 1, 2024

OK, thank you

@hero5512
Copy link

hero5512 commented May 9, 2024

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
Copy link
Member Author

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

@hero5512
Copy link

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
Copy link
Member Author

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.

@Dedigraz
Copy link

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I have developed lots of systems that had to handle safety, authorization and authentication taking into account the structure and dynamics of the system and how it's used.

How I plan on tackling this issue

The approach would depend on what works with the original user experience but solves the problem, which as of yet I have not determined

@ChrisFernandezVivas
Copy link

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

Electrical engineer with 3 years using c++

How I plan on tackling this issue

Circom and using active verification

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed medium
Projects
None yet
Development

No branches or pull requests

4 participants