Download
1 / 18
E N D
1. Identity Theft Prevention using Aggregated Proof of Knowledge Elisa Bertino, Abhilasha Bhargav-Spantzel,
Anna Squicciarini,
Rui Xue
3. Multi-Factor Identity Verification
4. Overview of our Approach We have a logical entity called the registrar which establishes and maintains identity commitments used to establish proof of knowledge of strong identifiers used later for multifactor identity verification.
Two main Phases:
Enrollment or Registration: User commits his strong identifiers to be used later as proofs of identity.
Usage: Before revealing the actual value of a required attribute one has to verify the commitments of other attributes as proofs of identity.
5. Example Explanation:
EXAMPLE 1. Consider Alice, an individual who wants to join federation E-Mall. EMall
offers a safe environment for online Business, comparison shopping, web hosting,domain
registration, banner advertising, website advertising and so forth. To freely access the Emall
portal Alice first establishes a SSO Id and password with an IP, say IdP1. Before
registering and using the strong identifiers, Alice contacts the issuer of the strong identifier
to get a certificate which contains the commitment of the strong identifier, created by Alice,
and a unique number associated with the strong identifier which is generated by the issuer.
For example, she contacts her bank, who issued her a credit card number (CCN), to get
a certificate that uses the blinded or committed value of the CCN and associates it to a
unique number corresponding to it.
She then registers her CCN with registrar Reg1 to be safely used
within the federation. Reg1 thus creates a new identity record for her.
Reg1 upon receiving the CCN first verifies that the submitted CCN has not been already
registered by some other individual in federation E-Mall. If this condition holds, Alice and
Reg1 execute the registration protocol to sign the desired commitment for the CCN which
will be used subsequently when this CCN is used as a proof of identity. This information is
encoded in Alices registration certificate if desired.
Alice, as a member of the federation can now proceed with the request of a service from
an E-Mall store, say SP-Shop. The store requires Alices CCN along with a different form
of identity verification from Alice for authentication. SP-Shop thus challenges Alices SSN.
Note that SP-Shop has no actual interest in knowing the value of the SSN; but it wants to
be assured that (i) Alice knows the SSN of the owner off the CCN and that (ii) they both
refer to Alice (as identified by her first and last name). Because SSN is a strong identifier,
Alice wants to protect it from identity theft. As such Alice submits an additional request
to Reg1 for registering her SSN. Reg1 does the necessary checks to see if the information
provided in clear (e.g. first name and last name) is consistent with Alice record, and that
no one else has registered the same SSN. If these checks are performed successfully, then
Reg1 updates the IdR of Alice with the new SSN commitment. A corresponding certificate
storing the IdR is then re-issued to Alice, and the previous one discarded.
Alice is now in the position to send the updated certificate and to be able to construct the
proof of knowledge of the required identifiers for the SP-shop to resume her original request.
SP-Shop verifies the ownership of the certificate with the help of the proof, followed
by validating the CCN itself. Note that, because SSN value is verified, the store only needs
to see the proof of such verification and not the SSN number itself.
CCN validation information is sent to Reg1 if the transaction is successful. This way, Reg1
now knows that the CCN registered initially is valid and can update this information in
Alices IdR. Alice can thus complete the transaction.
-----
ATTACK:
Consider a malicious user Mallory, who has managed to steal Alice's
CCN after Alice has registered. Mallory's main aim is to be able to
use Alice's CCN, to buy goods from SP-Shop. When SP-Shop challenges
Mallory to provide the SSN, corresponding to this CCN, then Mallory
could try one of two possibilities. First she could attempt to use
the public IdR of Alice and try to construct the proof of knowledge
of the registered commitments. This is not possible because we prove
that our aggregate proof of knowledge is sound, meaning that if a
correct proof is constructed then the prover knows the actual values
of the committed strong identifiers and also the random secrets
associated with them. Therefore Mallory does not gain any advantage,
even if she manages to learn the value of the SSN and not the random
secrets associated with the commitments. The second possibility, is
to be able to register the CCN of Alice, with her own SSN. However,
when Mallory sends a request to register the CCN, due to our
duplicate detection mechanism, the registrars can verify if this
strong identifier has already been registered and disallows the
registration. Thus Mallory cannot use Alice's CCN, once Alice has
registered it with the federation.
Explanation:
EXAMPLE 1. Consider Alice, an individual who wants to join federation E-Mall. EMall
offers a safe environment for online Business, comparison shopping, web hosting,domain
registration, banner advertising, website advertising and so forth. To freely access the Emall
portal Alice first establishes a SSO Id and password with an IP, say IdP1. Before
registering and using the strong identifiers, Alice contacts the issuer of the strong identifier
to get a certificate which contains the commitment of the strong identifier, created by Alice,
and a unique number associated with the strong identifier which is generated by the issuer.
For example, she contacts her bank, who issued her a credit card number (CCN), to get
a certificate that uses the blinded or committed value of the CCN and associates it to a
unique number corresponding to it.
She then registers her CCN with registrar Reg1 to be safely used
within the federation. Reg1 thus creates a new identity record for her.
Reg1 upon receiving the CCN first verifies that the submitted CCN has not been already
registered by some other individual in federation E-Mall. If this condition holds, Alice and
Reg1 execute the registration protocol to sign the desired commitment for the CCN which
will be used subsequently when this CCN is used as a proof of identity. This information is
encoded in Alices registration certificate if desired.
Alice, as a member of the federation can now proceed with the request of a service from
an E-Mall store, say SP-Shop. The store requires Alices CCN along with a different form
of identity verification from Alice for authentication. SP-Shop thus challenges Alices SSN.
Note that SP-Shop has no actual interest in knowing the value of the SSN; but it wants to
be assured that (i) Alice knows the SSN of the owner off the CCN and that (ii) they both
refer to Alice (as identified by her first and last name). Because SSN is a strong identifier,
Alice wants to protect it from identity theft. As such Alice submits an additional request
to Reg1 for registering her SSN. Reg1 does the necessary checks to see if the information
provided in clear (e.g. first name and last name) is consistent with Alice record, and that
no one else has registered the same SSN. If these checks are performed successfully, then
Reg1 updates the IdR of Alice with the new SSN commitment. A corresponding certificate
storing the IdR is then re-issued to Alice, and the previous one discarded.
Alice is now in the position to send the updated certificate and to be able to construct the
proof of knowledge of the required identifiers for the SP-shop to resume her original request.
SP-Shop verifies the ownership of the certificate with the help of the proof, followed
by validating the CCN itself. Note that, because SSN value is verified, the store only needs
to see the proof of such verification and not the SSN number itself.
CCN validation information is sent to Reg1 if the transaction is successful. This way, Reg1
now knows that the CCN registered initially is valid and can update this information in
Alices IdR. Alice can thus complete the transaction.
-----
ATTACK:
Consider a malicious user Mallory, who has managed to steal Alice's
CCN after Alice has registered. Mallory's main aim is to be able to
use Alice's CCN, to buy goods from SP-Shop. When SP-Shop challenges
Mallory to provide the SSN, corresponding to this CCN, then Mallory
could try one of two possibilities. First she could attempt to use
the public IdR of Alice and try to construct the proof of knowledge
of the registered commitments. This is not possible because we prove
that our aggregate proof of knowledge is sound, meaning that if a
correct proof is constructed then the prover knows the actual values
of the committed strong identifiers and also the random secrets
associated with them. Therefore Mallory does not gain any advantage,
even if she manages to learn the value of the SSN and not the random
secrets associated with the commitments. The second possibility, is
to be able to register the CCN of Alice, with her own SSN. However,
when Mallory sends a request to register the CCN, due to our
duplicate detection mechanism, the registrars can verify if this
strong identifier has already been registered and disallows the
registration. Thus Mallory cannot use Alice's CCN, once Alice has
registered it with the federation.
6. Preliminary Concepts {
8. Pedersen Commitment ZK Prove know how to open Public commitment c = gxhr (mod p)
Private knowledge x,r
Protocol:
P: picks random y, s in [1..q], sends d = gyhs mod p
V: sends random challenge e in [1..q]
P: sends u=y+ex, v=s+er (mod q)
4. V: accepts if guhv = dce (mod p)
9. Bilinear Maps Let G1, G2, and Gt be cyclic groups of the same order.
10. Aggregated signatures (Boneh, et al.) Signatures on different messages by multiple signers can be combined into one small signature.
Scheme requires bilinear map (in Gap DH groups)
BGLS Details:
12. Preliminary Concepts }
13. Proving aggregated signature on committed values
14. Proving aggregated signature on committed values and open
15. Proving aggregated signature on some committed values and opening some
16. Integrating the zero-knowledge proof into the verification
17. Zero-knowledge proof the aggregated signature
18. Efficiency Analysis
19. Conclusion Identity theft is a major problem
Our approach supports the strong verification of identity attributes, which is a component of comprehensive solutions against identity theft
