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: 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: 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. ✪
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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 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: 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: 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: 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. ✪