Threat Model

We classify threats according to the following categories.

Threats from Issuers

Because issuer countries can store all passport attestations, they could lock users out by registering their identity before them.
- For passports supporting Active Authentication, we plan on updating to checking AA as soon as possible, which will require minimal change to our architecture.
- For passports that don’t, we don’t know of a straightforward way to mitigate this threat. Until we have better solutions, we can use privacy-preserving analytics to monitor which DSCs and CSCAs are used in registration proofs. This can be done without revealing user’s private data, or linking those analytics with disclosure proofs. If we detect suspect behavior, we can eventually place restrictions on which CSCA or DSC signed a passport in the disclosure circuit, because their hash is committed to the identity commitment.
Issuers could keep the private keys associated with Active Authentication.
- In this case, even Active Authentication can’t help distinguish the user from the issuing state. We believe if that happens, this is uncommon.
Issuer countries can issue fake passports.
- We don’t have good mitigations aside from the monitoring described above. We believe this threat to become a concern only if our protocol is used at scale. In the future, we can support many attestation types such as other ID card or port zk proofs of emails or web2 data, and require users to bring multiple attestations with matching attributes à la https://github.com/0xturboblitz/totem with a scoring system, so that one issuer cheating does limited damage.
An issuer country could spam our on chain trees with fake DSC or passports, so that the tree becomes too large to be downloaded by users. We can only mitigate it with the solutions mentioned above. Also, this attack is not very practical because of gas costs.
Issuer lying on the nationality field of DG1. For instance, North Korea could sign passports with USA as the country code in DG1. Since both the DSC and CSCA are committed to the identity commitment, we can verify nationalities using certificates on top of the nationality field of DG1.
Issuers could leak certificate keys, allowing attackers to sign fake passports. Just like before, we can blacklist those certificates at disclosure time.

Threats from attackers accessing passports

Passport attestations can be read from passports at airports or by attackers accessing the passports, which would allow them to register en masse.
- Just like in the case of issuers storing attestations, the main solutions are using Active Authentication when available, and monitoring for other cases.
Attackers accessing passports could extract private keys if chips are not secure. We believe those attacks are currently impractical.

Threats from cryptography

Our work relies on standard cryptographic assumptions. In particular, on the security of all SHA functions from SHA-1 to SHA-512 and signatures from RSA-2048 bits exponent 3 to ECDSA with 512 bit keys.
- Because we commit to the DSC and CSCA in each identity commitments, in the future, we can blacklist identities from any certificate that is deemed insecure. This would use either a list or a non-inclusion proof using a sparse merkle tree. Applications could also choose their level of security by requiring those non-inclusion proofs to be done or not.
We rely on the security of Groth16. It’s arguably the most widely used zero-knowledge protocol in production. It relies on standard cryptographic assumptions such as discrete log hardness. Also, breaking dlog breaks soundness but not secrecy, so previous proofs stay privacy preserving.
The Groth16 trusted setup has a 1/n trust assumption on the participants. As outlined above in the Trusted Setup section, our trusted setup will be open and auditable.
In the current circuits, the index of the public key in the certificate data is passed as an input by the prover. No checks are done to ensure it’s the correct position, because we assume other positions would yield public keys for which it’s not feasible to find the corresponding private key. Some work has been done on ASN1 parsing in circom (c.f. https://github.com/zkemail/asn1-parser-circom), which would allow us to constrain this better if that ever becomes necessary.
- In ECDSA, the keys in certificates are in uncompressed form, so an attacker would have to find a couple (x, y) that corresponds to a valid point on the curve. For instance for secp256r1, the uncompressed size of the public key is 512 bits, and the verification circuit checks that points are on the curve at each step. The group of valid secp256r1 points has roughly ~2^256 elements, while there are ~2^512 possible points, so the probability that a random point lands on the curve should be around 2^256/2^512 = 2^-256
- For RSA circuits, the problem comes down to factoring a random 2048 bit number, which is currently considered hard even if it is not a product of two ~1024 bit primes like in valid RSA key generation.

Supply chain attacks

Most users will be accessing our protocol through our mobile app. Compromising our mobile app could compromise their passport data. We respect standard security procedures with regards to two-factor authentication and access to mobile app releases. Users that don’t feel safe using our mobile app can always build our circuits and merkle trees from the repo, generate their proofs locally and send all proofs on chain by themselves.

PreviousTrust assumptions NextQuickstart

Last updated 3 days ago

Threat Model

We classify threats according to the following categories.

Threats from Issuers

Because issuer countries can store all passport attestations, they could lock users out by registering their identity before them.
- For passports supporting Active Authentication, we plan on updating to checking AA as soon as possible, which will require minimal change to our architecture.
- For passports that don’t, we don’t know of a straightforward way to mitigate this threat. Until we have better solutions, we can use privacy-preserving analytics to monitor which DSCs and CSCAs are used in registration proofs. This can be done without revealing user’s private data, or linking those analytics with disclosure proofs. If we detect suspect behavior, we can eventually place restrictions on which CSCA or DSC signed a passport in the disclosure circuit, because their hash is committed to the identity commitment.
Issuers could keep the private keys associated with Active Authentication.
- In this case, even Active Authentication can’t help distinguish the user from the issuing state. We believe if that happens, this is uncommon.
Issuer countries can issue fake passports.
- We don’t have good mitigations aside from the monitoring described above. We believe this threat to become a concern only if our protocol is used at scale. In the future, we can support many attestation types such as other ID card or port zk proofs of emails or web2 data, and require users to bring multiple attestations with matching attributes à la https://github.com/0xturboblitz/totem with a scoring system, so that one issuer cheating does limited damage.
An issuer country could spam our on chain trees with fake DSC or passports, so that the tree becomes too large to be downloaded by users. We can only mitigate it with the solutions mentioned above. Also, this attack is not very practical because of gas costs.
Issuer lying on the nationality field of DG1. For instance, North Korea could sign passports with USA as the country code in DG1. Since both the DSC and CSCA are committed to the identity commitment, we can verify nationalities using certificates on top of the nationality field of DG1.
Issuers could leak certificate keys, allowing attackers to sign fake passports. Just like before, we can blacklist those certificates at disclosure time.

Threats from attackers accessing passports

Passport attestations can be read from passports at airports or by attackers accessing the passports, which would allow them to register en masse.
- Just like in the case of issuers storing attestations, the main solutions are using Active Authentication when available, and monitoring for other cases.
Attackers accessing passports could extract private keys if chips are not secure. We believe those attacks are currently impractical.

Threats from cryptography

Our work relies on standard cryptographic assumptions. In particular, on the security of all SHA functions from SHA-1 to SHA-512 and signatures from RSA-2048 bits exponent 3 to ECDSA with 512 bit keys.
- Because we commit to the DSC and CSCA in each identity commitments, in the future, we can blacklist identities from any certificate that is deemed insecure. This would use either a list or a non-inclusion proof using a sparse merkle tree. Applications could also choose their level of security by requiring those non-inclusion proofs to be done or not.
We rely on the security of Groth16. It’s arguably the most widely used zero-knowledge protocol in production. It relies on standard cryptographic assumptions such as discrete log hardness. Also, breaking dlog breaks soundness but not secrecy, so previous proofs stay privacy preserving.
The Groth16 trusted setup has a 1/n trust assumption on the participants. As outlined above in the Trusted Setup section, our trusted setup will be open and auditable.
In the current circuits, the index of the public key in the certificate data is passed as an input by the prover. No checks are done to ensure it’s the correct position, because we assume other positions would yield public keys for which it’s not feasible to find the corresponding private key. Some work has been done on ASN1 parsing in circom (c.f. https://github.com/zkemail/asn1-parser-circom), which would allow us to constrain this better if that ever becomes necessary.
- In ECDSA, the keys in certificates are in uncompressed form, so an attacker would have to find a couple (x, y) that corresponds to a valid point on the curve. For instance for secp256r1, the uncompressed size of the public key is 512 bits, and the verification circuit checks that points are on the curve at each step. The group of valid secp256r1 points has roughly ~2^256 elements, while there are ~2^512 possible points, so the probability that a random point lands on the curve should be around 2^256/2^512 = 2^-256
- For RSA circuits, the problem comes down to factoring a random 2048 bit number, which is currently considered hard even if it is not a product of two ~1024 bit primes like in valid RSA key generation.

Supply chain attacks

Most users will be accessing our protocol through our mobile app. Compromising our mobile app could compromise their passport data. We respect standard security procedures with regards to two-factor authentication and access to mobile app releases. Users that don’t feel safe using our mobile app can always build our circuits and merkle trees from the repo, generate their proofs locally and send all proofs on chain by themselves.

PreviousTrust assumptions NextQuickstart

Last updated 3 days ago