4
$\begingroup$

I work with U-Prove. In U-Prove they talk about a trusted Issuer, but I never saw how the trust is verified. The trust is essential, because the Verifier wants to know if the token was created with a trusted Issuer or not.

The U-Prove Cryptographic Specification V1.1 describes how to verify the signature of the Issuer. But there is no direct link if the signature is from a trusted Issuer or mayby from the Prover itself. The Issuer-Parameter could not be used, they are variable and created everytime a Prover wants to get a token.

Does someone has an idea or link where the trust establishment is described?


Updated question 24.02.2017

Maybe my first question was a bit unclear. Lets imagine that the Prover wants to create a token by himself. He creates the IssuerParameters and runs the protocol (Figure 8) by its own (this means he simulates the Issuer). Now he is the holder of the Issuer private key $y_0$. The Prover presents the created token to the Verifier. Signature (Figure 4) for the presented token is correct. But the Verifier does not know if it was a trusted or untrusted Issuer, who created the token with the Prover. The Verifier just knows that the received token relates to the private key $y_0$.

What I understand out of the Issuance protocol (Figure 8) and saw in the SDK-Implementation is, that every time the Prover requests a token, the IssuerParameters (generators $g_i$, $i$ = # attributes) and the private key $y_0$ (as well as $g_0$) are generated new.

$\endgroup$
2
  • 1
    $\begingroup$ Issuer parameters are generated only once, on setup. $\endgroup$ Feb 24, 2017 at 19:12
  • $\begingroup$ @VadymFedyukovych Thanks a lot. Now I know what I have done wrong. The U-Prove SDK is not prepared for using the IssuerParameter more than once (my opinion). Because the attributes and the IssuerParameter $e$ are bounded together. Now my solution takes a pre-defined max attribute value, which creates the $g_0$ and the private key $y_0$. Attributes and $e$ are unlinked. It is possible to order a bunch of attributes smaller than the pre-defined max attribute value. It seems to work, I only have to test to usage of the IssuerParameters more than once. Thank you again for your valuable help. $\endgroup$
    – lmb1
    Feb 27, 2017 at 18:38

1 Answer 1

0
$\begingroup$

For any credentials scheme, trust is defined out of the scheme. It might be your employer or your government.

Please note there is no clear separation whether signature is coming from Issuer or Prover. Signature on token public key $h$ is verified with Issuer public key (Figure 4) as a proof of equality of two logarithms. However, it is created by running a blind signature protocol running both by Issuer and User (Figure 8). There is no chance to create this signature without Issuer private key $y_0$.

Please consider to double-check Issuer parameters generation (section 2.3.1): once on scheme setup.

$\endgroup$
2
  • $\begingroup$ Thank you for your good answer. I see your point and agree with you that it is only possible to create the signature if you are aware of the private key y0. “Please note there is no clear separation whether signature is coming from Issuer or Prover.” Do you mean that it is not possible to figure out if the Prover signed the token by himself or the Issuer did? (Please see the updated question above (had insufficient place for posting it here), it may prove this statement) $\endgroup$
    – lmb1
    Feb 24, 2017 at 9:25
  • 1
    $\begingroup$ @BoLei For "separation": I did mean that both Prover and Issuer are running a protocol, as shown on Figure 8, and there is no chance for Prover to sign the token himself becasue of Issuer private key $y_0$. Verifiers need to accept Issuer parameters in a trusted manner. $\endgroup$ Feb 24, 2017 at 19:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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