3
$\begingroup$

Suppose I have two users who are issued two different UProve IDs. The Issuer has guaranteed that one UProve token bearer will never have more than one UProve token ID.

  • How can I use UProve to guarantee that two users are "different" without disclosing their actual private ID?

Here is a scenario: An online voting system wants to use UProve to anonymously collect votes. They decide to trust an Issuer who has full knowledge of the end user, but the relying pary has to accept the fact that they will know nothing about the end user at all.

The polling station (relying party) only needs to know that the same UProve ID wasn't used to cast a second vote. The only UProve scenario I know of that would work here is proving the user's SSN (or similar fixed ID).

In this case I don't want to disclose anything.

Is this possible?

Improve this question
$\endgroup$

4 Answers 4

Reset to default
2
$\begingroup$

The U-Prove Technology Overview V1.1 shows that this can be done. The issuer knows who the individual is but can't correlate that with verifier or prover use.

Upon setup the issuer can have extra attributes available that upon request of authorization from the prover the verifier can have access to. The verifier could use such an attribute and only successfully verify if it hasn't seen that attribute before.

Improve this answer
$\endgroup$
2
  • $\begingroup$ So that means the issuer needs N attributes, and selectively disclosing them one by one? I suppose I need to mention that the quantity of locations the UProve user will be dealing with numbers in the the millions. A UProve token with just 255 proofs takes quite a long time to generate. I hope there is another solution. $\endgroup$
    – makerofthings7
    Commented Mar 27, 2013 at 16:53
  • $\begingroup$ What information would be in that attribute? Is it encrypted data? $\endgroup$
    – makerofthings7
    Commented Sep 27, 2013 at 14:58
1
$\begingroup$

Uprove/anonymous credentials in general seems a bit heavy handed for that. You could accomplish it with simple Chaum style e-cash. The issuer does a blind signature on a serial number. To vote, you reveal the serial number and signature. Its anonymous and doesn't allow duplicate voting.

In fact, since u-prove credentials are single show, you could cause u-prove to do this by simply only issuing a single credential to each user.

As a general note, you can do what you want with locally revokable anonymous credentials since the relying party can simply revoke the credential once it's used. I don't believe Uprove supports this, but other systems do.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I'm very interested in learning how this would operate, though the Wiki page for ecash is of no use, and all the pages are dead. Do you have any more info or references so I can understand what you mean by a "blind signature on a serial number"... and it's removal? $\endgroup$
    – makerofthings7
    Commented Apr 11, 2013 at 0:35
  • $\begingroup$ @makerofthings7 There is a rather decent wikipedia article on blind signatures that shows the basic RSA construction. Is that insufficient? $\endgroup$
    – imichaelmiers
    Commented Apr 11, 2013 at 19:25
  • $\begingroup$ I see it here.. will read it. en.wikipedia.org/wiki/Blind_signature $\endgroup$
    – makerofthings7
    Commented Apr 11, 2013 at 20:05
1
$\begingroup$

U-Prove TokenID is a hash output, so it may be not the best way to prove "not the same" statement. One would also consider inequality proof for a subset of user attributes instead. For each such attribute pair, "not the same" would mean an inverse exists for attribute difference, modulo group order. One would prove knowledge of such inverses while keeping them secret, "AND"-combined with regular proof of knowledge of attributes.

To run a prover for such a protocol, one needs sharing attributes for that users, so it is not always desirable. This makes straightforward not-equal proof outlined less applicable for voting scenario.

One would approach voting with registration authority assigning distinct userID attributes, and another authority running an accumulator for that IDs while accepting ballots. U-Prove fits handling attributes.

Improve this answer
$\endgroup$
0
$\begingroup$

If the user's SSN is an attribute in the Token, maybe you could use the "Attribute inequality proof" which is explained in the U-Prove Extensions or for more details in U-Prove Inequality Proof Extension. The inequality proof is comparing two Tokens and their IDs (Hashes) (as Vadym Fedyukovych mentioned). It should also be possible to compare two Tokens attribute without disclosing them to the Verifier. But the downside, you have to be aware of the other Token I guess.

Another approach could be the use of device-protected Tokens. A counter inside the device could only allow one vote for this Token.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.