[MINUTES] W3C CCG Credentials CG Call - 2024-09-03

Thanks to Our Robot Overlords and Our Robot Overlords for scribing this week!

The transcript for the call is now available here:

https://w3c-ccg.github.io/meetings/2024-09-03/

Full text of the discussion follows for W3C archival purposes.
Audio of the meeting is available at the following location:

https://w3c-ccg.github.io/meetings/2024-09-03/audio.ogg

A video recording is also available at:

https://meet.w3c-ccg.org/archives/w3c-ccg-weekly-2024-09-03.mp4

----------------------------------------------------------------
W3C CCG Weekly Teleconference Transcript for 2024-09-03

Agenda:
  https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Sep&period_year=2024&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date
Organizer:
  Harrison Tang, Kimberly Linson, Will Abramson
Scribe:
  Our Robot Overlords and Our Robot Overlords
Present:
  Harrison Tang, Gregory Natran, Greg Bernstein, Will Abramson, 
  Vanessa, Jenn Greene, MCSM, Alberto Leon, Hiroyuki Sano, TallTed 
  // Ted Thibodeau (he/him) (OpenLinkSw.com), James Chartrand, 
  Kimberly Linson, Geun-Hyung Kim, Manu Sporny, Anil John, Jennie 
  M, Leo, Alex H, Tim Cappalli, David Waite, Greg Natran, Rashmi 
  Siravara, Steve Magennis, Jeff O - HumanOS, Dave Longley, Erica 
  Connell, Joe Andrieu

Our Robot Overlords are scribing.
Harrison_Tang: Right you're good to go.
Manu Sporny: https://github.com/w3c/tpac2024-breakouts/issues
Manu Sporny:  Yep uh just a couple of quick ones uh the first 1 
  I'll put the link in um the worldwide web consortium's um 
  technical planner is coming up um there are a number of us that 
  are going uh in their breakout sessions uh already uh that have 
  been uh raised here um of interest to this community.
Manu Sporny: https://github.com/w3c/tpac2024-breakouts/issues/38
Manu Sporny:  Uh is a 1 around did method standardization um so 
  I'll put that link in here.
<harrison_tang> We will not have the CCG meeting during that TPAC 
  week (September 24)
Manu Sporny: https://github.com/w3c/tpac2024-breakouts/issues/37
Manu Sporny:  And so that is uh going to involve uh Kim and Gabe 
  uh and possibly myself speaking to some of the advancements that 
  we've been making with other communities uh diff Iota um uh w3c 
  this this community you know um on did method standardization um 
  so there'll be an active discussion happening uh at TPAC about 
  that there is also going to be a breakout session around uh the 
  future of verifiable credentials um that includes um new features 
  that a number of people in the community are uh planning uh we'll 
  have an agenda up shortly um but you know expect a lot of 
  discussion there.
Manu Sporny:  And then a couple other ones uh you know popped up 
  that are of interest um 1 of them uh by uh Tim kapali which I 
  think who just joined uh on um identity related web platform apis 
  and harmonizing them um that has to do with like you know um the 
  digital credential API and Web author and and uh fed CM API and 
  that that sort of thing so um lots of cool stuff happening uh at 
  TPAC this year um.
Manu Sporny:  If you have a breakout session that you want to 
  propose uh please get it on the agenda there uh the other uh real 
  quick uh heads up is that um.
<tim_cappalli> There's also a general breakout session about Real 
  World Identity on the Web as a followup from last year's session
Manu Sporny: https://github.com/w3c/controller-document
Manu Sporny:  The controller documents so this is a did document 
  basically um uh had been moving fairly rapidly through the 
  process but as of 2 weeks ago there have been a number of issues 
  raised uh on it uh if you care about the documents or the future 
  of them you might want to pay attention uh to the poll requests 
  and the issues in that repository you'll see that they're like a 
  100 comments you know raised issues and PRS and whatever uh last 
  week uh so just a heads up to keep an eye on that.
Manu Sporny:  You know um.
Manu Sporny:  Something to keep an eye on uh that's it for 
  updates from me.
Greg Bernstein:  All right let's get screen sharing going again.
Greg Bernstein:  Of the window.
Our Robot Overlords are scribing.
Greg Bernstein:  Different figures or a different sizes 
  credential attacks.
Greg Bernstein:  We have a 3-party model for credentials issuers 
  holders and verifiers.
Greg Bernstein:  So I was very confused after I talked gave my 
  Susan them talk and somebody kept telling me you forgot to tell 
  about how.
Greg Bernstein:  Help prevent evil Alice and I go.
Greg Bernstein:  I don't even know who evil Alice is okay.
Greg Bernstein:  And we're going to get to that.
Greg Bernstein:  They were thinking about in cryptography we have 
  a and b Alice and Bob and then a 2-party model you have Alice and 
  Bob and you can have evil Bob or good Bob and Alice.
Greg Bernstein:  So if you hear somebody talking about evil Alice 
  or evil Bob that's what they mean but this is I've got evil 
  issues evil holders and evil verifiers okay as well as somebody 
  out there who's going to be our credential Steeler.
Greg Bernstein:  BBS what's the deal with that we talked about 
  tracking.
Greg Bernstein:  Okay and we talked about BBS producing unlined.
Greg Bernstein:  If not done properly the verifiers.
Greg Bernstein:  Can talk to each other and say Hey you know.
Greg Bernstein:  I can identify the holder buy stuff in the 
  signatures within the secured credential and so we can track them 
  from sight to sight.
Greg Bernstein:  That's what I mean by an evil verifier.
Greg Bernstein:  Evil issuer meaning maybe the verifiers report 
  back to the issuer without the holder's knowledge or consent 
  there's a legitimate reasons to do these things right there's a 
  legitimate reasons reasons to understand who's doing what out 
  there but people should know when they're being tracked okay 
  illegitimate reasons or you know we want to figure out how to 
  sell you more something that you really don't need okay third 
  model is this is the verifiers all report to some third party 
  what holder has been Vision visiting them.
Greg Bernstein:  1 Of the key things about BBS style signatures 
  is the cryptographic information is on linkable okay so the 
  cryptography is not the problem.
Greg Bernstein:  Types of signatures.
Greg Bernstein:  Schemes cryptography schemes those values are 
  unique.
Greg Bernstein:  Can be used for tracking whether that's an issue 
  depends on the application but we are trying to be privacy 
  preserving here now besides evil issuers and verify our tracking 
  Around the Net.
Greg Bernstein:  We have to worry about stolen credential use 
  right.
Greg Bernstein:   So you.
Greg Bernstein:  Using a verifiable credential what that the 
  holder's consent or knowledge okay and how could that happen 
  intercepting credentials between issuer and holder or holder and 
  verifier or a data breach at the issue or holder or verifier 
  write any of those things happens all the time we get those 
  notices then there's another kind and this is the evil Alice 
  case.
Greg Bernstein:  So complicit credential abuse the illicit use of 
  a credential with complicity of the credentials holder okay 
  somebody other than the intended holder is using credentials with 
  without with with the holder's knowledge right oh you want to see 
  something from that website I already paid for it here use my 
  thing and I'm gonna sell it off to all sorts of people okay so 
  account sharing.
Greg Bernstein:  Beyond contracted limits not me.
Greg Bernstein:  Wearing my subscription to the times or the 
  economists with my kids because we all just read it once in a 
  while right you know that's within the contracted limits.
Greg Bernstein:  Restrictions of Asians age limits okay.
Greg Bernstein:  1 Of the things is unlink can make this abuse 
  easier could you can't tell when somebody comes back if they're 
  the same person right.
Greg Bernstein:  So you could easily set this up so somebody 
  could allow other people to use their credential in a unlink.
Greg Bernstein:  Now last time we talked about these pseudonym 
  things and it's like oh they keep you from being tracked but they 
  allow the verifier to remember you so you can have services from 
  that verifier blah blah and have a relationship with them but 
  they also help mitigate this kind of credential abuse and was 
  just on.
Greg Bernstein:   A email.
Greg Bernstein:  Folks on blind BBS signatures and pseudonyms 
  talking about.
Greg Bernstein:  More examples of this and like for voting 
  systems even.
Greg Bernstein:  Saying we're using this for voting systems okay.
Greg Bernstein:  So we have credential stealing credential abuse 
  we have tracking what about forging credentials okay well the 
  truth is this is extremely difficult this is what cryptographic 
  papers and algorithms are all about.
Greg Bernstein:  Okay if you could Forge a credential say an 
  ecdsa or eddsa signature.
Greg Bernstein:   We would.
Greg Bernstein:  Stop using it okay that's why we move on to 
  different types of cryptography okay it is difficult if they are 
  implemented correctly.
Greg Bernstein:  Oh and the key is kept secret.
Greg Bernstein:  So you may Wonder it's like.
Greg Bernstein:   Why did.
Greg Bernstein:  These guys always talk about these methods where 
  they can figure out a couple extra bits of the key.
Greg Bernstein:  You know all these weird things timing attacks 
  and looking at the power used by the cryptographic processor 
  anything that gets them a little more information of the key.
Greg Bernstein:   About the.
Greg Bernstein:  They can try and guess the key easier than all 
  those values so.
Greg Bernstein:  People try and get around the cryptographic 
  algorithms if they're implemented correctly if the keys kept 
  secret you've got to go around it and that's where they 
  concentrate a lot of their attacks.
Greg Bernstein:  Through our job is to make sure we use the 
  cryptography properly okay.
Greg Bernstein:  So let's look at some mechanisms questions I'm 
  not looking at the chat because I'm sharing my screen so if 
  there's questions somebody will let me know so mitigating.
Greg Bernstein:  The first set of these is kind of like it's 
  being stolen between the holder and the verifier right so it's 
  got intercepted or somebody hacked the holder okay and these 
  would be normally talked about as replay attacks.
Greg Bernstein:   We've got some.
Greg Bernstein:  Ms generally in v and verifiable credentials to 
  deal with these.
Greg Bernstein:   There's some.
Greg Bernstein:  So in the VC data integrity and the model 
  there's a challenge value and then in data Integrity when you 
  verify your proof you're supposed to do something with that value 
  so let's look at that flow.
Greg Bernstein:  And you'll notice the flow is kind of long and 
  complicated the verifier comes up with a fresh challenge value.
Greg Bernstein:  For the holder to use now the holder doesn't.
Greg Bernstein:  Can't do anything with that.
Greg Bernstein:  Because they don't issue the credential they 
  have to take that challenge value send it over to the issuer the 
  issuer secures the VC including a proof with the check covering 
  the challenge value okay the holder then sends that back to the 
  verifier and we can tell we don't like this flow why.
Greg Bernstein:  Because we have to go back to the issuer at some 
  time to get this done right so it's it's not it's okay but.
Greg Bernstein:  Not what we think about okay.
Greg Bernstein:  So holder has to get issued to involved in 
  providing a fresh challenge value.
Greg Bernstein:  Let's look at a different cryptographic scheme 
  and its support.
Greg Bernstein:  Okay nbbs there's something known as the 
  presentation header we'll get we'll remind folks about this in a 
  sec okay.
Greg Bernstein:  In the BBS ietf draft it talks about 
  presentation header particularly for using this in the verifiable 
  credential w3c spec we give you hooks to use the presentation 
  header.
Greg Bernstein:  What is the flow look like oops not yet sorry 
  I'm gonna remind you.
Greg Bernstein:  Is a 3 3 party model.
Greg Bernstein:  Okay they'll use the term sir uh prover and 
  verifier we use the terms issuer holder and verifier okay.
Greg Bernstein:  So issuer to holder the issuer uses the sine 
  function covering multiple messages right we take our verifiable 
  credential we do our Json LD Pro processing end up with a bunch 
  of messages statements okay sign that send the signature and the 
  messages over to the holder the holder can verify that if they 
  wanted to okay.
Greg Bernstein:  But the holder uses a separate procedure called 
  proof jet.
Greg Bernstein:  No secret key of the issuer is involved it just 
  has the private key public key sorry.
Greg Bernstein:  Has the signature involved it's got a header.
Greg Bernstein:  The Header information is information must that 
  must be shared by all parties.
Greg Bernstein:  We make use of that with verifiable credentials 
  in the DI spec for BBS we put things like mandatory reveal 
  information in that header.
Greg Bernstein:  However this presentation header thingy.
Greg Bernstein:  Is only shared between the holder and the 
  verifier.
Greg Bernstein:  In addition it's secured okay.
Greg Bernstein:  So we have a model that looks like this.
Greg Bernstein:   The issue.
Greg Bernstein:  Uses BBS to sign a VC sends it to the holder.
Greg Bernstein:  Verifier says sends information like a challenge 
  but we don't call it a challenge it doesn't have to be 
  incorporated in the VC directly over to the holder containing 
  what they want to see in the presentation header.
Greg Bernstein:  Okay the holder.
Greg Bernstein:  Creates another secure VC what we call a derived 
  proof.
Greg Bernstein:  Okay different languages based on w3c versus 
  okay we have a base proof we put into the sign BC a drive proof 
  in the secured VC we put in the presentation header okay that is 
  secured with the BBS algorithm and the verifier can verify it so.
Greg Bernstein:  BBS has a built-in anti-reflux to the issuer to 
  do that okay.
Greg Bernstein:  I used to know question.
Greg Bernstein:  Okay so um yeah I don't bring up presentation 
  here so the holder would then.
Greg Bernstein:  Come up with a presentation and sign the 
  presentation.
Greg Bernstein:  That yeah so then we have to have the holders.
Greg Bernstein:  Public key known to the verifier and we'll have 
  the issuers public key known to the verifier.
Greg Bernstein:  And we're going to hit something like that in a 
  second so yeah that's a completely legit way to do it too um.
Greg Bernstein:  I just we're going to see something like that in 
  a second and where we have both issuer and holders having public 
  private key Pairs and we'll use that for a little bit more 
  security so.
Greg Bernstein:  So I think maybe I don't give a fair shift to 
  challenge being used here um.
Greg Bernstein:  Let's take a.
Greg Bernstein:  Look at the next level of security where we bind 
  and we'll see that once the holder has a okay.
Greg Bernstein:  That leads us to the next issue okay well what 
  if somebody what if we want to make sure that it's really coming 
  from the holder.
Greg Bernstein:  Okay how do we bind the credential to a holder 
  we've been hearing more demands for this okay the ud wallet 
  people of God and what we talked about how far they want to go 
  with it okay.
Greg Bernstein:  How does this work the holder is going to have a 
  public private key pair.
Greg Bernstein:  Creating digital signatures such as ecdsa type 
  signatures something we use with credentials.
Greg Bernstein:  The public key from the holder the holder's 
  public key is sent to the issuer for inclusion in the credential 
  that is sent.
Greg Bernstein:  Why does the holder need to get their public key 
  back.
Greg Bernstein:  Oh when requesting the credential the verifier 
  also includes a message acting as a test.
Greg Bernstein:  Older signs this message with their private key 
  oh.
Greg Bernstein:  It includes it with the credentials sent to the 
  verifier are you keeping all this in your head we're going to see 
  a diagram in a second.
Greg Bernstein:  Okay so we have 2 different sets of public 
  private keys.
Greg Bernstein:  The holders public key gets sent to the issuer 
  and incorporated into credential the verifier is going to send a 
  test message or.
Greg Bernstein:  Nuts or what challenge or whatever you want to 
  call it.
Greg Bernstein:  To the holder to sign to verify or then 
  validates the signature on the test message with the holder's 
  public key that was contained in the VC and verifies it with this 
  credential with the issuer's public key ah let's look at the 
  diagram.
Greg Bernstein:   The whole.
Greg Bernstein:  Folder has a.
Greg Bernstein:  The issuer has a public key the holder sends 
  their public key to the issuer.
Greg Bernstein:  The issuer signs the VC with their secret key 
  but also includes a copy.
Greg Bernstein:  Which is signed over of the holders public key.
Greg Bernstein:  So they're saying look I'm issuing this 
  credential to the holder and the holder I've verified somehow 
  that the holder this is the holder's public key.
Greg Bernstein:  Only the holder should have the secret key.
Greg Bernstein:  Okay they don't send the secret key to the 
  issuer.
Greg Bernstein:  Okay the verifier can send a test message 
  whatever they like can also be used for anti-reflux.
Greg Bernstein:  So what is the holder do.
Greg Bernstein:  A forward on the secured VC.
Greg Bernstein:  Which the issuer remember signed over their 
  public key and they're going to sign this test message.
Greg Bernstein:  They got from the verifier the verifier then 
  does 2 things they verify this credential.
Greg Bernstein:  Issuers public key they make sure it's from the 
  issuer okay.
Greg Bernstein:   From the.
Greg Bernstein:  Out what the issuer said is the holders public 
  key and they verify.
Greg Bernstein:  The sign test message with that public key 
  meaning only the holder.
Greg Bernstein:   Who had.
Greg Bernstein:  Has its secret key corresponding to the public 
  key could have created and signed the signed the test message so 
  the verified 2 things.
Greg Bernstein:  Okay they verified the credential and they 
  verified that only the credential.
Greg Bernstein:   Could have.
Greg Bernstein:  This combination of things could have come from 
  the holder it's only the holder knows the secret key so this is 
  strong holder binding okay the issuer issued it to the holder 
  knowing that the holder had this public key and only the holder 
  has the secret key hopefully right if they lose the secret key or 
  if somebody else gets the secret key all bets are off okay.
Greg Bernstein:  So this so we see Auntie replay we see a nice 
  flow here notice if you go to another verifier.
Greg Bernstein:  Okay the holder doesn't have to go back to the 
  issuer all they have to do is get a different test message from 
  this other verifier send them the secure VC and another sign test 
  message so we don't have that icky flow like we saw before okay.
Greg Bernstein:  Pros prevents anyone from using the credential 
  without the holder's consent.
Greg Bernstein:  And it's as strong as the ability of the holder 
  to keep their private key Secret.
Greg Bernstein:  Or to make sure there's no fraud in this over 
  here between the holes or the issuer right right if somebody's 
  trying to impersonate the holder and get the issuers that's 
  another process right remember the cryptography when implemented 
  well is strong very strong so people are going to do whatever 
  they can to get around it.
Greg Bernstein:  Where the rest of us come in right we're not 
  cryptographers but we have to make sure how we handle the rest of 
  these things.
Greg Bernstein:  Or we know about the cryptography we have to 
  handle the rest of these things in a secure way.
Greg Bernstein:  Look at the con.
Greg Bernstein:  The holders public key and a VC is a unique 
  identifier for the holder.
Greg Bernstein:  And allows tracking on every credential use.
Greg Bernstein:  This public key value is unique it better be 
  because it corresponds to the holder secret key if 2 people have 
  the same public key that means they have the same secret key 
  essentially.
Greg Bernstein:  Are good enough okay.
Greg Bernstein:  This public key holder binding flow.
Greg Bernstein:  Doesn't stop the tracking.
Greg Bernstein:  Very secure okay.
Greg Bernstein:  People are going to try and get around things 
  they're going to try and steal the private keys so you want to 
  put your private key someplace really safe so no 1 can steal it 
  you only want to use it in a real leafe place so nobody can look 
  at it and learn it okay and this is why people are talking about 
  trusted execution environments and.
Greg Bernstein:  Trusted platform modules and the like associated 
  with wallets and things like that okay there's these things 
  called TPMS if you've got a modern laptop PC or whatever most 
  likely you have 1 in it windows I think starting in Windows 11 or 
  10 required 1 this diagram shows an older block diagram of a TPM 
  okay but what do they have in them they've got random number 
  generators they have algorithms they Implement algorithms TPM 2.0 
  includes crypto elliptic curve cryptography that kind of stuff we 
  have for ecdsa eddsa for credentials because those are more 
  efficient especially as far as key sizes.
Greg Bernstein:  Sometimes you'll hear these called 
  hardware-based roots of trust.
Greg Bernstein:  People Hardware manufacturers make chips for 
  everything from laptops to iot devices that can do these kind of 
  things okay.
Greg Bernstein:  So they'll Generate random not secure random 
  numbers they can generate key pairs they can do all sorts of good 
  things what we care about is.
Greg Bernstein:  Repair generation remember that public and 
  private key pair okay only the public key ever comes out private 
  Keys never would leave the secure element.
Greg Bernstein:  Now in addition to doing this in Hardware you 
  can also do this in a.
Greg Bernstein:  Secure piece of software that's that trusted 
  execution or secure element things.
Greg Bernstein:   So how.
Greg Bernstein:  And such like that how you achieve that okay but 
  private Keys Never Leave the secure element unless they are 
  encrypted that's 1 trick that they figured out with TPMS it's 
  like oh people might have a lot of product private key pairs.
Greg Bernstein:  We can export them right out of the TPM as long 
  as they are.
Greg Bernstein:  Okay they call that key wrapping so we have 
  private so we have that production we have key pair generation 
  protecting the private keys if you need to have a lot of them and 
  you can sign things.
Greg Bernstein:  People get very excited we'll have this in this 
  root of trust okay.
Greg Bernstein:  But remember once you got something really nice 
  and secure.
Greg Bernstein:  Somebody's going to go around it they're going 
  to subvert it they're going to take over it and things like that 
  okay.
Greg Bernstein:  Can't extract the private Keys that's what they 
  were good for but they'll go around try and go around it anyway 
  possible.
Greg Bernstein:  We get in all sorts of issues about how do apps 
  get Fair access so somebody else can make a wallet and things 
  like that is it going to be limited just to the right now getting 
  control or being able to use those.
Greg Bernstein:   Secure element.
Greg Bernstein:  Um quite limited the hardware can be slow to 
  evolve okay.
Greg Bernstein:  Current ECU support in these things is limited 
  to specific curves and specific signing algorithms.
Greg Bernstein:  People are pushing to modernize these things and 
  such but remember we.
Greg Bernstein:  Do we always need this level of security can we 
  always get it.
Greg Bernstein:  Right now um you know should we halt all 
  Innovation just because we don't have a hardware root of trust 
  no.
Greg Bernstein:  I've been on many conversations lately with uh.
Greg Bernstein:  And they say oh yeah we need a secure platform 
  to do our discussions and such like that we'll use signal.
Greg Bernstein:  That's done in software but all the algorithms 
  are open source all the cryptographers have been able to see how 
  signal implements their protocols and such like that and 
  everybody says that's good and Signal came out first and then 
  other people came out and did those things later alright WhatsApp 
  Google something or other messaging uses signals organs.
Greg Bernstein:  Okay so how are we going to make this anonymous.
Greg Bernstein:  What we're going to use BBS okay.
Greg Bernstein:  Now we had this public key holder binding and we 
  got some cool Concepts from it okay.
Greg Bernstein:  Giving them verifiers public key allows the 
  holder.
Greg Bernstein:  Giving the verifier the holders public key 
  allows the holder to prove that they know a secret right.
Greg Bernstein:  I'm going to sign whatever you give to me okay 
  and you can use my public key.
Greg Bernstein:  To verify that I knew the secret key that 
  corresponded it by checking the signature.
Greg Bernstein:  Okay so I'm able to kind of prove something to 
  the verifier they know this thing though that identifies me 
  that's a downside the public key is bound to the private key.
Greg Bernstein:  But but public key is linked to the secret key 
  and doesn't hide the holder.
Greg Bernstein:  We learned about something like this last time 
  with pseudonyms.
Greg Bernstein:   This is.
Greg Bernstein:  With cryptographers kind of call a commitment or 
  a commitment scheme.
Greg Bernstein:  Wanted to come.
Greg Bernstein:  Chosen secret value while keeping it hidden from 
  others with the ability to reveal it later.
Greg Bernstein:  Commitment schemes are designed so that a party 
  cannot change the value or statement they have after they've 
  committed it to it committed to it.
Greg Bernstein:  There's 2 main properties cryptographic 
  properties binding.
Greg Bernstein:  The commitment is generated Alice can only open 
  it to a single message no changing the message after the 
  commitment has been made.
Greg Bernstein:  Hiding this is what we don't get.
Greg Bernstein:  With the public key-based hold your binding the 
  commitment strength C should reveal no information about the 
  committed message.
Greg Bernstein:  Okay even if the message set is under control of 
  the adversary for us we don't want to be tracked ah.
Greg Bernstein:  Now last time we said there's a number of ways 
  you can come up with commitment schemes.
Greg Bernstein:  Let M be the message being committed or value 
  choose a random R take a hash of the concatenation of the message 
  with the brand of value R hash functions cryptographic hash 
  functions you can't reverse them okay you can't figure out the M 
  from.
Greg Bernstein:  The value of the commitment and the R value if 
  you could you'd be a Bitcoin billionaire right.
Greg Bernstein:  Because that's what a lot of those Bitcoin proof 
  of works are all checking hash function values and wasting a 
  tremendous amount of energy and natural resources okay 
  verification on reveal of n by checking.
Greg Bernstein:  So you can.
Greg Bernstein:  There's another type of commitment that's fairly 
  famous.
Greg Bernstein:  Uses these things called groups Prime order 
  groups and they're based on the difficulty of the discrete 
  logarithm problem.
Greg Bernstein:  Which is the same as ecdsa eddsa and BBs is tied 
  to the discrete logarithm problem right.
Greg Bernstein:  If you didn't know so how these work.
Greg Bernstein:  Let X be the number the message to be committed 
  let R be a another random number we call that the blinding or 
  hiding factor into the commute the compute the commitment is 
  simply as raising this number g i called a generator to the power 
  x and H multiplied by H to the power r.
Greg Bernstein:  Now you're going but if we reveal the secret 
  wait.
Greg Bernstein:   What could.
Greg Bernstein:  Is committing to this thing and hiding it with 
  his commitment if we have to reveal it.
Greg Bernstein:  That's where we get to the modern stuff.
Greg Bernstein:  Where we get to things called zero knowledge 
  proofs because what we're not ever going to do is reveal.
Greg Bernstein:  The value X.
Greg Bernstein:  We're going to do is we're going to prove that 
  we know these values.
Greg Bernstein:  We're going to prove it and what's called zero 
  knowledge.
Greg Bernstein:  Okay so you've heard about these things so let's 
  talk about them a bit so you'll know the jargon okay we're not 
  going to do the proofs like we went through a little bit last 
  time I put the slides in but I know we're going to run out of 
  time.
Greg Bernstein:  And we want to have some time for questions so 
  zero knowledge proofs.
Greg Bernstein:  Okay they have to satisfy 3 things it's a 
  procedure that goes on between approver and a verifier.
Greg Bernstein:  Hence the terminology in the BBS draft where the 
  you have a signer an approver and a verifier.
Greg Bernstein:  PBS is a zero knowledge proof.
Greg Bernstein:   Between the.
Greg Bernstein:  Approver and the verifier to prove that they 
  know.
Greg Bernstein:   All the.
Greg Bernstein:  And the signature on the message and the 
  signature corresponds to those sets of messages okay so they're 
  not just saying I know the signature but I know the signature 
  corresponds to this particular set of messages and I know the 
  messages Okay so.
Greg Bernstein:  A procedure that goes on between these 2 folks 
  it's complete.
Greg Bernstein:   If you.
Greg Bernstein:  Run the protocol okay.
Greg Bernstein:  And the statements drew the verifier will accept 
  it okay so if you truly know the signature.
Greg Bernstein:  Truly know the messages and they all correspond 
  to each other.
Greg Bernstein:  The verifier will accept it.
Greg Bernstein:  They use the term sound meaning your argument to 
  the sound the to say if the statement is false the verifier 
  follows the protocol.
Greg Bernstein:  Verify it cannot be convinced okay you can't 
  fool me the prover can't prove to you okay.
Greg Bernstein:  The protocol if they don't really know the 
  information okay.
Greg Bernstein:   So you can't.
Greg Bernstein:  That's that you can't fool me property complete 
  means you'll accept it if it's really true property and zero 
  knowledge means.
Greg Bernstein:  You're not going to learn anything extra other 
  than the fact the statement is true I know the secret value.
Greg Bernstein:  Okay there is you don't need to have this public 
  key you this extra stuff okay to accept my proof of it I'm going 
  to give you this proof of it but you're not going to learn 
  anything other than I know the value.
Greg Bernstein:  In case when you read some of these things and 
  you hear about ZK snarks and ZK Starks and such like that.
Greg Bernstein:  To be technical.
Greg Bernstein:  Proofs need to be sound remember you can't fool 
  me even against computationally unbounded provers so the provers 
  can have all the computer power in the world that's the formal 
  definition of proof where an argument only needs to re preserve 
  the you can't fool me property against limited computation okay.
Greg Bernstein:   So that.
Greg Bernstein:  Technical term hence.
Greg Bernstein:  If you go and look up things zero knowledge 
  you'll hear people talking about zero knowledge proofs in general 
  okay but when they get try and get more technical you'll see 
  acronyms like ZK snark zero knowledge.
Greg Bernstein:  Succinct non-interactive those things succinct 
  meaning short non or n or active meaning we've compressed this 
  into a a single round we don't have to go back and forth and back 
  and forth argument for knowledge argument is the more correct 
  technical term but we just use proof to talk about these things 
  in general okay took me a while I was like why are these guys 
  talk about arguments well the whole thing is called a proof.
Greg Bernstein:  Technical thing okay.
Greg Bernstein:  So just to summarize the BBS proof provided by a 
  holder through a verifier is a zero knowledge proof.
Greg Bernstein:  BBS has been using this stuff and has been 
  around this type okay.
Greg Bernstein:  For quite a while there's a lot of current work 
  still going on on zks because they're trying to prove more 
  General things.
Greg Bernstein:  Ckps have a certain form proving very specific 
  types of statements okay that's why BBS though gets away with 
  very small proofs.
Greg Bernstein:  Very small signatures and very efficient 
  compared to others UK Pro techniques.
Greg Bernstein:  Now with BBs each proof generated uses a 
  different set of cryptographic random numbers and hence different 
  proofs cannot be linked to each other.
Greg Bernstein:  Okay that's where we get that even that good on 
  trackability on linkability okay.
Greg Bernstein:  Here's repeat of what I said with the references 
  to tell you where to see these things and.
Greg Bernstein:  Folks we're getting some interest with these 
  things and standardizing this set of proof techniques okay.
Greg Bernstein:  So just to let you know that's.
Greg Bernstein:   Some current.
Greg Bernstein:  At ZK the ZK proof folks are talking about 
  taking some of that and bringing that over the ietf we're talking 
  with them to see how to incorporate more General proofs of things 
  into things now.
Greg Bernstein:  You may be using a bunch of this stuff already 
  but.
Greg Bernstein:   An example.
Greg Bernstein:  Proof of the.
Greg Bernstein:  Okay so here's a little bit about signal private 
  messaging okay not to be confused with other things that okay.
Greg Bernstein:  Once again they're algorithms okay and there's 
  security Protocols are used in WhatsApp Google messages and other 
  things okay.
Greg Bernstein:  In february this year they announced usernames 
  okay so you don't need to share your phone number okay.
Greg Bernstein:  I just discovered as I've been working on 
  pseudonym stuff.
Greg Bernstein:  This nice article that explains their use of 
  usernames along with the zero knowledge proofs based on these 
  discrete log things.
Greg Bernstein:  Are also kept secret from signal.
Greg Bernstein:  Does something similar with.
Greg Bernstein:  With uh if you set up groups like we have a 
  family chat and Signal we had all these members they keep that 
  information.
Greg Bernstein:   Nice and.
Greg Bernstein:  Okay people can't see who's talking to who the 
  same way okay as you can on other social media platforms because 
  it's not a social media platform it's a private messaging app.
Greg Bernstein:  So the usernames consists of a nickname and a 
  number okay.
Greg Bernstein:  Like win Cadet 1 1 17 okay that's not really my.
Greg Bernstein:  Username but I just wanted to have an example 
  they commute a computer commitment kind of just like that uh 
  flavor of what we call the Patterson commitment okay they take a 
  hash kind of randomizes things.
Greg Bernstein:  Times it by a group element this is actually 
  something called scalar multiplication okay they take the 
  nickname turn it into a number multip do a scalar multiplication 
  with a group element and finally they take that number and do the 
  scalar raised G3 to a power they sent this information okay this 
  is sent by a signal to Signal by the owner of the username.
Greg Bernstein:  Okay signal never sees the username only the 
  commitment to the username okay to connect with another user you 
  must know their username they had to tell you it you can't get it 
  from signal okay and you don't even tell it to Signal what you do 
  is compute the commitment along with a proof.
Greg Bernstein:  A zero knowledge proof that you know the 
  username.
Greg Bernstein:  We saw this before.
Greg Bernstein:   Oh yeah.
Greg Bernstein:  Yeah when we.
Greg Bernstein:  We said the prover or us the holder will have a 
  secret value.
Greg Bernstein:  Okay they'll compute a commitment.
Greg Bernstein:  To that value along with 1 of these zero 
  knowledge proofs of knowledge okay and they'll keep some 
  information to themselves about how they blinded it that blinding 
  Factor they can send that over.
Greg Bernstein:  To the issuer.
Greg Bernstein:  Who can then check to make sure using the proof 
  procedure.
Greg Bernstein:  These guys really know this value without 
  feeling the value and we use this for what we called.
Greg Bernstein:  Hidden paid pseudonyms it was used to generate 
  pseudonyms without anybody knowing.
Greg Bernstein:  Anything about the pseudonyms no tracking 
  possible.
Greg Bernstein:  Except to verify I'll be able to know you and 
  see you again but they can't correlate you across other verifiers 
  so we did this stuff kind of before.
Greg Bernstein:  Okay this is what signal does okay.
Greg Bernstein:  So we talked about this is like a Patterson 
  commitment it just says a lot more instead of just 1 secret value 
  it broke it up into multiple secret values.
Greg Bernstein:  Okay we're not going to review the interactive 
  proofs or the proof of correctness we did now what do we do with 
  this stuff.
Greg Bernstein:  There's something known as a blind signature you 
  can ask somebody to sign something for you without them actually 
  knowing it okay it's a cryptographic thing okay.
Greg Bernstein:  TBS can support blind signatures we have a draft 
  okay on how to do it okay and how does it work you make a 
  commitment the holder makes a commitment they provide a 
  commitment a proof a zero knowledge proof that they actually know 
  the value ship both the commitment and the proof.
Greg Bernstein:   Of the.
Greg Bernstein:  For the commit.
Greg Bernstein:  To the issuer the issuer can verify the proof 
  and use that commitment straight and sign that commitment okay.
Greg Bernstein:  So what is this signature API look like.
Greg Bernstein:  Looks like just what I said the issuer has their 
  secret key their public key they get a commitment with proof.
Greg Bernstein:   From the.
Greg Bernstein:  Holder and that everything looks kind of the 
  same.
Greg Bernstein:  The interesting thing is.
Greg Bernstein:  When we do blind proof generation the holder.
Greg Bernstein:  Can I have a whole set of committed messages 
  this is General blind signatures okay we're just going to have 1 
  okay and they don't have to reveal them or they can reveal them 
  okay so this is a more General protocol than we we need for 
  holder binding.
Greg Bernstein:  Okay scary formula scary formula but I just 
  wanted to show you here we do all these multiplications and this 
  is done in the right order okay we have the commitment formula 
  okay we have a value in the group we have a secret proverb blind 
  the blinded we have a bunch of committed messages from the holder 
  not to be confused with the issuer messages we're just talking 
  about 1 message the secret.
Greg Bernstein:  For hold your binding but there could be others.
Greg Bernstein:  For use in pseudonyms.
Greg Bernstein:  The signing formula.
Greg Bernstein:  4 BBS signatures takes place in 2 main pieces 
  this is down right in the guts of how BBs works it has some stuff 
  in it to help you randomization and important things 
  cryptographically but the core part is taking another set of 
  these generators.
Greg Bernstein:  And combining them with all the messages from 
  the issuer.
Greg Bernstein:   And I.
Greg Bernstein:  I took these from 2 different specs so they're 
  not differentiated sorry but.
Greg Bernstein:  It adds in the commitment oh so it all kind of 
  looks the same.
Greg Bernstein:  Then we do the final signing formula this is why 
  BBS works so well with blind signatures with very little change 
  the cryptography is the same we're just have this extra procedure 
  of the commitment commitment with proof.
Greg Bernstein:  What is our flow look like here okay Anonymous 
  holder binding flow.
Greg Bernstein:  The holder generates the secret.
Greg Bernstein:  They keep it secret.
Greg Bernstein:  They generate a commitment to the secret and 
  they generate a.
Greg Bernstein:  Proof a zero knowledge proof that they actually 
  know that secret and corresponding to with how the commitments 
  made okay the issuer issues a blind a BBS signature.
Greg Bernstein:  BBS using blind BB BBS over the messages the 
  credential Plus.
Greg Bernstein:  This the hidden secret okay.
Greg Bernstein:  The holder needs to use their.
Greg Bernstein:  Secret to generate a BBS proof they never reveal 
  their secret they don't that's just a message that's never 
  revealed to the verifier okay so we have the same properties.
Greg Bernstein:  We saw with.
Greg Bernstein:  Public key holder binding except.
Greg Bernstein:  We stay Anonymous or we we keep our unlink 
  ability okay.
Greg Bernstein:  Anonymous we may want to throw in Sudan HMS on 
  top of this is 1 of the things we discovered after looking at 
  this stuff more.
Greg Bernstein:  Now ah we're gotten short on time.
Greg Bernstein:  But that's about where we're at Okay so.
Greg Bernstein:  You may be thinking wait if people know how to 
  do zero knowledge proofs and they're trying to do zero knowledge 
  proofs.
Greg Bernstein:  For more General type of complicated functions 
  for smart contracts and all sorts of things might they try and do 
  this.
Greg Bernstein:  Existing signatures especially since right now 
  roots of trusts only currently support ecdsa type signatures.
Greg Bernstein:  Yeah this could make an existing signature on 
  linkable okay but this isn't easy.
Greg Bernstein:  Right now it might take about a gig or a couple 
  hundred Meg.
Greg Bernstein:  Space in about half an hour on a full laptop 
  I've tried some of these computations.
Greg Bernstein:  Okay so nothing's quite as efficient will will 
  be as quite as efficient and practical as BBS in this scenario 
  but.
Greg Bernstein:  These are the kind of things we want for 
  practical as a I'm quoting a Neil John we want practical privacy 
  preserving.
Greg Bernstein:  Cryptography for verifiable credentials.
Greg Bernstein:  Meaning that we got to work in this third party 
  model too.
Greg Bernstein:  Okay I've been talking Non-Stop.
Greg Bernstein:  Questions comments this is.
Greg Bernstein:  Where we're at we're Oops I did not mean to do 
  that um.
Greg Bernstein:  We are trying.
Greg Bernstein:  Trying to get uh all these uh.
Greg Bernstein:  Requirements figured out and we've kind of 
  figured out that we really want both Anonymous holder binding and 
  pseudonyms.
Greg Bernstein:  At the same time.
Greg Bernstein:  Um we yeah I mean that's where we're okay so 
  there's 2 different pieces.
Greg Bernstein:  We'd like to get things ratified.
Greg Bernstein:  Eyes and we see a bit of hey we're going to let 
  the ietf kind of standardize it and then maybe we'll bless it 
  those standards those bodies we did see with the Udi our stuff 
  that a bunch of cryptographers all came out and said you know.
Greg Bernstein:  What you guys have isn't going to meet the 
  requirements you put into the laws and what you really should do 
  is use BBs.
Greg Bernstein:  And variance of it and then.
Greg Bernstein:   People can.
Greg Bernstein:  Back and said but we want a hardware route of 
  trust.
Greg Bernstein:  And then we said oh but then 1 person that 
  worked on TPMS and algorithms for TPMS came back and said oh well 
  you know we were working with TPM vendors and a lot of our stuff 
  is done in firmware and we were trying to get some of that stuff 
  fixed up and we could do this this and this so.
Greg Bernstein:  So it's fluid that way and I will remind people 
  that we got secure messaging not because it got dictate or better 
  privacy private messaging not because of it getting incorporated 
  into Hardware but because an open source effort like signal went 
  and did it did it well made all the protocols.
Greg Bernstein:  You know they wrote them up nicely so people 
  could cryptographically reviewed them and Implement them well and 
  then they privacy shamed the other guys WhatsApp and Google right 
  so it's like are we gonna wait for this like to get all the way 
  down in Hardware before we consider it so that's why.
Greg Bernstein:  1 Last sales pitch data Integrity allows us to 
  use multiple signatures right we can have a proof set we can sign 
  it with.
Greg Bernstein:  Cdsa selective disclosure we can sign up with 
  BBs for Selective disclosure.
Greg Bernstein:  So if somebody really doesn't trust 1 of those 
  they can use the other right we're not locked into 1 
  cryptographic scheme here.
Greg Bernstein:  Yeah and yeah we all like Hardware roots of 
  trust but if you've ever tried to use a TPM yourself or an 
  application you'll go gee it only seems like the uh operating 
  system vendors get to use these things for anything and does that 
  mean they're gonna own the platform and we're not going to be 
  able to use that good cryptography well then we're gonna have to 
  figure out.
Greg Bernstein:  A way to do that that maybe doesn't use the root 
  of trust but I am hopeful we can get access to some of those 
  things because it's nice.
<dave_longley> hardware protections are really best for 
  protecting a user's device *on behalf of the user* (protecting 
  them from malware, etc., whatever), vs. trying to protect the 
  user's device *from the user* (which is extremely difficult and 
  liberty-harming)
Greg Bernstein:  Okay great talk to everyone later.
<harrison_tang> Love the presentation, Greg!

Received on Tuesday, 3 September 2024 21:50:34 UTC