Privacy preserving subject authentication mechanism for application with verifiable credentials #37
Comments
|
IIRC It feels like not revealing the credentialSubject.id but revealing image / age might be a better example. Assuming I assume this ZKP SD VC is then presented via something that supports replay attack mitigation? This makes me wonder if we can support domain / challenge in deriveProof... and make Seems like replay attacks are still a concern... the fact that the PRC has an image is actually confusing, because that feels like a solution to this problem... but it isn't... the data subject has both the credential, and the linked private key.... but every time they use them to derive a proof, an eavesdropper might capture a selective disclosure.... its weird to think of putting a credential with no subject in a verifiable presentation.... it would feel more natural if |
The main issue with this approach that then the generated N-Quads for the statements in the credentialSubject would then have to feature this ID meaning it would have to be known to a verifier and if not we would have to do some pretty weird credential specific logic about striping out credentialSubject.id before and after signature creation and verification.
Yeap much like the signature proofs to-date you are free to have other things feature in the proof e.g we support a nonce at the moment so if this is supplied by the verifier then you have replay attack prevention. For example a bound proof featuring a nonce would look like this
Yes so to be clear a VC of the form |
|
This makes sense, I also agree its wise not to take the VC Data Model as a dependency... everything can fit in the |
|
perhapse we would avoid the term subject....
|
|
multiformats/multicodec#185 has been merged. @tplooker wondering if we should define this key representation here now? We should generate some test vectors for G1 / G2 and (G1 + G2), and then provide JWK, base58 and multicodec examples. Also, should this suite define support for This gets to my least favorite part of linked data... key representation. IMO, tooling MUST support JWK, and MAY support any format which can be converted to JWK, included base58 or multibase. |
|
My only comment is that you'll want to make sure that the proof purpose is for |
|
@dlongley I think this is worth pondering a little more. A |
|
@brentzundel I can't assign, but during an IIW session Bren't said he'd take this issue and File a PR for it. |
|
commenting so I can be assigned |
|
@brentzundel sorry I missed the session on this. I assigned you, lmk how I can help. |
|
I am working on a PR to add this feature. It is not clear to me how the privacy of the holder is preserved when presenting a proof bound to their public BLS key. The example VP contains a reference to the holder's DID URL. |
|
@brentzundel thats why I wrote this up https://github.com/mikelodder7/commit_twin. The party storing the public keys knows your unique commitment in order to present but they don’t know your secret value. Also the public key is a pedersen commitment so it’s different per party and there’s no way it can be cross correlated between colluding parties |
|
@tobias @mikelodder7 @OR13 I believe that Commit Twin will be an excellent addition to this work moving forward and propose that it be considered as the mechanism for private holder binding a future version of this protocol. I do not think it will work for the 2020 version, primarily due to its limited review, as stated above. After thoroughly examining the mechanism proposed by Tobias in the preceding comments, it is not clear to me how such a mechanism could be considered privacy preserving. It may be that there is some aspect of it that I simply do not grasp. Even so, Tobias's mechanism is also something knew and would benefit from the same review as Commit Twin. Since plans are already underway to develop the next version of this specification, it does not make sense to me to add something new and untested to the 2020 version. In order to finish the 2020 spec and bring it into a condition such that a broader community can make use of it while we develop the next version, I propose that we simply use link secrets as the private holder binding mechanism. They are already included in the Ursa base implementation and are as well-reviewed as BBS+ signatures. This would allow us to complete this spec and rapidly deploy it with a familiar and effective mechanism for private holder binding, rather than spending the time to properly review the other proposals, and rather than simply adopting either of them without review. I am almost finished with my PR to add private holder binding to the spec. The further I got into it, the more concerned I became that what I was about to propose wasn't right. So I am sharing my concerns here and hope that we can come to agreement on the path forward. tl;dr I think we should use link secrets for private holder binding in the 2020 spec, but move to a different (and better) binding mechanism in the next version. |
|
@brentzundel thanks for reporting back, we should discuss this proposal further as the proposal of commit twin IMO is not directly about the credential binding technique instead it is how this binding can be used to achieve certain pseudonymity properties on top of the scheme. In essence I would like the binding to a credential to simply be a public key rather than a blinded public key (linked secret) because this makes the proof of private key signature more complex. |
|
I don't have a problem with a credential being simply bound to a public key, but couldn't understand how one could do so while providing privacy for the holder. If the proof of private key can be simpler than linked secrets while still avoiding revealing a correlating identifier, I'm all for it. I just don't see how it works, and am concerned that such a scheme will not have the necessary review. Could you help me understand how it works? |
|
@brentzundel understood, so if it is issuer correlation you are concerned about in this case, then it is solved by simply having a different public key per issuer. Because this public key is never revealed when generating a presentation with a verifier I believe all avenues of correlation we typically talk about are prevented? |
|
That's the part of it that isn't clear from your description above. Can you
walk me through how it works to not share the public key with the verifier,
because your examples seem to be doing that.
…On Mon, May 10, 2021, 15:34 Tobias Looker ***@***.***> wrote:
@brentzundel <https://github.com/brentzundel> understood, so if it is
issuer correlation you are concerned about in this case, then it is solved
by simply having a different public key per issuer. Because this public key
is never revealed when generating a presentation with a verifier I believe
all avenues of correlation we typically talk about are prevented?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPFKP3P4GSNNFMAMRYOIH3TNBGNBANCNFSM4RASIPAQ>
.
|
|
Sure, so here is the example from above based on the |
|
okay, that makes sense. Thank you for clarifying that for me.
And thank you for walking me through this.
Here are the steps, as I understand them:
1. holder possesses a BLS public/private keypair
2. holder gives public key to issuer
3. issuer incorporates public key into issued credential
4. holder receives credential
5. verifier requests presentation
6. holder generates derived credential for presentation
7. holder generates proof of knowledge of private BLS key
8. verifier receives presentation
9. verifier verifies provided proofs
First, please let me know if I've missed something, or added something
unnecessary.
Next, the steps that are unclear to me still:
3. how does the issuer incorporate the holder's public key? Mathematically,
how does this work?
7. Is there even a step 7? Or is knowledge of the private key required in
order for the holder to perform step 6? Again, how does this work
mathematically?
9. I'm assuming that as soon as I understand 3 and 7, I will understand 9,
but detail here would also be appreciated.
…On Mon, May 10, 2021 at 3:41 PM Tobias Looker ***@***.***> wrote:
Sure, so here is the example from above
{
***@***.***": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1",
"https://w3c-ccg.github.io/ldp-bbs2020/context/v1"
],
"type": ["VerifiableCredential", "PermanentResidentCard"],
"issuer": "did:example:12345",
"identifier": "83627465",
"name": "Permanent Resident Card",
"description": "Government of Example Permanent Resident Card.",
"issuanceDate": "2019-12-03T12:19:52Z",
"expirationDate": "2029-12-03T12:19:52Z",
"credentialSubject": {
"type": ["PermanentResident", "Person"],
"givenName": "JOHN",
"familyName": "SMITH",
"gender": "Male",
"residentSince": "2015-01-01",
},
"proof": {
"type": "BbsBlsBoundSignatureProof2020",
"created": "2020-04-26T04:21:07Z",
"verificationMethod": "did:example:12345#1",
"proofPurpose": "assertionMethod",
"proofValue": "jx2VhjyZqUT91e2OhzweJA7G2u2UvmiDtIfmr+wUWNHWno+UOAh0FaNpM8Br+5j2JBkH981/nO1I7/9PFaRrng6NXu7vzDroKtuyj6nHGkMmGq4OMmBzIqRnG3ybin/Sxmu5YwqOxPMRsWH3H+2wSA=="
}
}
based on the proof.type the verifier knows that in order for the holder
to have generated this presentation the holder had to have in its
possession the relevant private key of which the public key was known to
the issuer and bound during "issuance". The verifier has no idea the value
of this public key though. What they do have is the public key of the
issuer which is indicated by the "verificationMethod" property.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPFKP6EZMD7MBZLVNRLXRTTNBHJVANCNFSM4RASIPAQ>
.
|
Yes that flow is correct.
As is the case with all "messages" signed to produce a BBS signature, if your issuer public key is in G2 then the messages being signed have to result in being commitments in G1. The subject's public key is really just a special case of one of these messages that is being signed, special because:
As to how the holder proves knowledge of the secret key to the issuer prior to issuance, because the public key is just an ordinary public key in G1 we can reach for more standard and well known signature schemes such as a BLS signature in either basic or proof of possession mode. |
|
That last point is why I felt the linked secret design added complexity that threatened implementability of the scheme as with a blinded public key or linked secret style binding, the proof of knowledge of the secret key becomes another thing you have to define, rather than saying "we'll just use BLS signatures for that piece". |
|
Okay, that helps me to understand better. What is still missing for me is a place where this is written down that we can point to from this spec where the mathematics of it are set out for anyone to review. I'm feeling pressure to get the 2020 version "wrapped up" quickly and for that to happen in a way that it will be useable for me. For me to be able to use it and recommend it to others, it needs to include private holder binding. Your private holder binding sounds fantastic, but it is, as far as I am aware, only documented within this comment stream. So I ask again, can we use link secrets here? I agree that they add complexity, but they are already implemented as part of the Ursa BBS+ crate. The mathematics are already well-documented and reviewed. |
|
I agree with @brentzundel. I think that while this proposal is great, requires a good amount of cryptographic review and should not block the release of 2020 given the other changes we'd like to make to the spec after than. |
|
Hi all! I also have a question regarding this proposal. Question:If I’m not mistaken, the BBS+ proofs of security against adaptive message attacks here and here, take for granted that no message will be signed using the base generator of G1. If this is not enforced, a Holder could potentially forge a BBS+ signature. For example, consider an (unblinded) BBS+ signature to the messages Here, Proposed Possible Solution:If the above proves to be a problem, I think that not using the base generator of G1 and committing a message using any other (possible reserved) generator would work. That way the Holder’s secret message (private BLS key) becomes exactly like any other message signed by the Issuer. As a result, all the security proofs will continue to apply. Then, I think that security of the procedure could be proven, since if an adversary tries to create a PoK without knowing the Holder’s committed secret, will essentially have to forge a BBS+ signature. Please let me know If there is anything wrong with my understanding :) |
|
That's not entirely accurate. The math doesn't exactly check out as you describe. In this case, verify fails because of the multiply by two. If Alice sends anything other than the actual values signed, this also fails. We can see that using g_0 does not allow forgery in this case. Next, if we look at the proof generation, this also fails. Now let's change the verify function to receive all signed values except a proof of a signature instead. Verification becomes It still fails in this case. They are not equal. This equation holds even if all the messages are retained and not revealed. If Alice modifies any value including HOLDER_SK, the equation does not balance. Basically, using g_0 for the HOLDER_SK commitment doesn't necessarily harm it, but is not a good practice either. If Alice modifies the signature in any way or messages then the signature no longer verifies thus immune to adaptive message attacks. My recommendation is if there is a desire to use the same generator point for HOLDER_SK across the ecosystem we pick a nothing up my sleeve value and use hash to curve to generate it. This results in a generator whose discrete log is unknown and thus cannot be used to manipulate in any way. But we can see that using the same generator here is not harmful. |
@mikelodder7 Thank you very much for your reply. I entirely agree, but just to make sure that I correctly understood your definition;
It is of-course correct that this equation does not hold, but that is because here Alice tries to verify the new (forged) signature would hold, meaning that |
|
It’s not a security problem because that is similar to how the zero knowledge proof works. You randomize the signature and hidden values and balance the equation. So multiplying by 2 is similar to making a ZKP. The problem is if you modify the signature you have to modify EVERY value to make it work. Of course this has nothing to do with g_0. That’s a separate problem so there is no security problem here. It’s designed to work this way. |
I’m sorry, but I don’t think I understand your point. It is true that during ZKP generation
Maybe I’m mistaken, but I think that the above method is only possible if a Holder can make commitments (like a BLS public key) using g_0. If that is not the case, simply multiplying Perhaps a better example will be the following. Suppose again that Alice executes a chosen message attack as before, and gets a BBS+ signature The difference now is that instead of multiplying with 2 she will multiply by As before, that signature is a valid BBS+ signature to the messages Since Then the following equation (part of the ZKP of knowledge verification) holds, In the end, Alice will manage to convince a Verifier that she possesses a valid signature on |
|
Again look at your equations. They don’t balance. So no this is not a forgery |
|
Another reason is the messages must be revealed or use schnorr proofs. The verifier will only follow the verify equation which makes it so it doesnt balance |
|
The problem with your math is your assuming you can divide in the exponent which you can’t really do in finite fields |
|
First, I want to really thank you for taking the time to answer me here!
All messages can be viewed (by Alice) as elements of Z*p, which means that she can divide them (multiply with the inverse technically). Then she could use the result of that division to the exponent. Alternatively, she could raise an element to the power of the inverse of the message she wants to divide with (the Verifier does not need to do those operations). Even if there was a way to ensure that the messages cannot be divided, Alice could just use her attack to gain a BBS+ signature to the message m_1 = 1, and as a result, no division is needed. Lastly, in my first example I just raise to the power of 2, which should work regardless.
That is true, but Alice doesn’t have to reveal the original messages signed by the Issuer, but the ones she created the forged signature for. The entire point is for her to gain a BBS+ signature for some messages that the Issuer has not signed. For those messages (the ones that she will send to the Verifier), I don’t see why the equations don't balance. In the pdf here I have a more detailed explanation of why I think those equations hold, using the notation from here (which I think is more readable) and two simpler examples, similar to the ones I mentioned previously. |
|
Thanks for looking into this but your math is still incorrect. It's not as straightforward as you are claiming. Multiplying by m3 means EVERY value is now m3 bigger. If you multiply by 1/m3 it doesn't exactly carry straight thru as these the values are in-the-exponent which means it's not exactly divided. Instead, it would multiple 1/(e+x). This means you can't just multiply by 1/m3 and then assume every attribute is now 1/m3. It doesn't work that way. |
I don’t really see what the problem is if every value is m3 bigger, I would really appreciate it if you could explain that to me a little more.
Both (1/(e+x)) and 1/m3 are essentially elements of |
|
I think this would be better in a meeting than debating mathematics in GitHub. Email me and let’s discuss but your proposal for the vulnerability does not work |
|
Hi all! I met with @mikelodder7 where he was kind enough to explain to me what I was missing. In the end we concluded that using the base generator of G1 to create a commitment (BLS public key) may not be the best practice, since it can -in theory- lead to a potential forgery. Although this may not have any practical significance, perhaps it would be best to reserve a different generator (g0’) using a nothing-up-my-sleeve value as @mikelodder7 suggested, for the base generator of BLS keys. Doing that, BLS keys (using g0’) can still be used to authenticate the Holder, and the BBS+ signature will continue to be provably unforgeable. |
OR13
added
the
pending-close
|
I suggest we close this, and focus on cleaning up the spec. |
|
Open, for a week, no objections to closing.... and a draft has begun to address, when the draft can be referenced, we will attempt to do so without creating a downref. https://github.com/BasileiosKal/bbs-bound-signatures/blob/main/draft-bound-bbs-signatures.md |
BBS+ Signatures are a generalized digital signature scheme appropriate for a variety of applications, however their most immediate application is in the context of verifiable credentials.
Verifiable credentials in general define a cryptographically verifiable assertion format that allows an issuing authority to assert some information about a subject. In contrast to other assertion formats (e.g jwt based id_tokens in openid connect), verifiable credentials also focus on establishing a way for a credential subject to also authenticate, usually through a proof of key cryptographic mechanism.
The most common way this mechanism for subject authentication is realised in verifiable credentials is for the credential issued by the issuer to contain an identifier for the subject that when resolved contains the public cryptographic material required to verify a presentation of the credential originated from the subject it was bound to by the issuer.
Note The current reference implementation of BBS+ signatures enables this mode today.
However, the problem with this model is that it enforces the presence of a unique identifier for the credential subject to always be present in the verifiable credential leading to the ability for relying parties / verifiers to be able to trivially track the subject across credential presentations.
Instead we need a subject authentication mechanism for verifiable credentials that does not require disclosing a unique identifier for the credential subject. But still relies on a proof of key cryptographic mechanism when the subject would like to authenticate the presentation of a verifiable credential.
In order to accomplish this we propose the following way.
Simple Terms
When the issuer constructs a bound BBS+ signature one of the commitments they sign (other commitments being the individual statements in the verifiable credential), is the subjects BLS 12-381 G1 public key, therefore binding the signature to that key pair. In doing this in order for the subject to be able to derive a credential presentation for a credential featuring that signature they must possess the corresponding private key.
Examples
Issuer has a DID
Subject has a DID
Issuer issues credential of the following form
Subject can then create a selective proof (that requires them possessing the private key of the key pair the
BbsBlsBoundSignature2020was bound to)Edit
The text was updated successfully, but these errors were encountered: