Advancing Secure Credentialing: The Impact of Non-Interactive Threshold Signature Schemes

Hi guys. I'm Leandro. I'm a PhD student from the Technical University of Stead, and today I'm gonna talk about something that maybe sounds quite complicated. It's non-interactive threshold signature schemes, but yeah, it's in collaboration with the chair of applied Cryptography. But don't worry, I will try to leave out all the complicated mouth part and, and give you a high level overview of what this, these signature schemes can do for you and what we did there. So probably, you know about anonymous credential schemes.

If not, let's recap the notion that we are using, at least we have an issuing party. That issuing party is able to issue credentials, for example, an ID card, but you can imagine any other sort of credentials, attributes there. And then Erica in this case is able to go off to a verifier and do some requests, request some service. The verifier could ask to get to know some attributes of Erica. And Erica is then able to select, disclose those attributes.

For example, if she's of a German residency, if she's an adult, stuff like this without revealing her identity if she doesn't want to or if it's not required. So then the technical foundation behind those credential schemes are usually, of course, signature schemes and there are many signature schemes to choose from. But in recent years, what was a very promising choice to realize it is BBS plus. Why is it so well suited?

Although it's still in ongoing efforts when it comes to standardization because it has selective disclosure directly built into its cryptographic system, the signature size is actually constant. So you could have thousands or millions of attributes in one credential and have the same signature size all along. And in the end, these schemes really plug in well into existing zero knowledge proof schemes. So of course we want to apply it in some way, and we, we could argue certainly that credentials are ideally suited for zero trust architectures.

There are many reasons for this to be the case, but I would argue it's really nice to decouple authentication from identity of course only when, when we want to have this because in, in some cases it makes my sense to, to lock Erica's identity when she's accessing some file, for example. And these credentials also with the many attributes that they can hold, allow us to have a really fine-grained access control if we want to have it. But of course, the elephant in the room here is that we don't want to rely on a single entity. We are in a decentralized track.

So probably we, we want to secure ourselves from the possibility that there's a malicious party control controlling our issuing instance and is then issuing own credentials that alter with our security. So of course we want to distribute, and in cryptography we call this threshold cryptography because now we, let's say, let's say we have three issues and we define a threshold two out of three in that case, so that we, we demand that at least two signatures are available from, from our set of issuing parties.

So now we have a very robust system because one party could, could be malicious in, in that case really nice, okay, we eliminate a signal point of failure. And then the, the way to further use cases that involve blockchains of certain identity is not far. But in that case, for our work, we don't want to use blockchain and therefore we need to to think about how we want to distribute. So how do you do, we want these issuing parties to be structured in our architecture.

So the naive way of doing this is you, you have like one big server in in your, in your, in your company and you just put all issuing instances on that server. And of course that's not really smart because now you just take the single point of failure and move it one abstraction level up and now the hardware is becoming the single point of failure here. So the next best thing to do is have different servers with like nice networks segmentation such that if your server is attacked, of course the other servers hopefully remain intact and can work.

And our two out of three scheme is, is still still secure. But then if you're an enterprise level, on an enterprise level, you should maybe consider using cloud instances and go to data centers use, use different cloud instances for that case. But we always need to think about that the the level or the, the, the abstraction level when it comes to the single point of failure could potentially now move just again, one level up. Because if you have one admin administrator that is controlling those cloud instances, the account of the administrator is becoming the single point of failure again.

So we could argue if we have, we are in an enterprise level, we maybe want to choose different business units. So we have an IT security unit in the us in Germany, in the uk, and maybe each of these should be responsible to having one issuer in this, in this constellation. So let's do this. But nothing is for free. We need to distribute, but distribution is usually from a cryptographic point of view, very expensive. We have communication, we have computation, we maybe need more expensive machines to, to do this work. And usually we have also a higher round complexity.

That means during the issuance, the parties need to communicate several time with each other in order to issue the credential. In the end, this becomes very, very costly. If we are in a very distributed setup, for example, if we have these, these instances that are far away from each other, because even today the, the latency when you communicate from the US to to Germany one round can be above 100 milliseconds. This might be fine if you are in a use case where Erica is able to wait one second to have a credential.

But if you want to have millions of credentials in a short amount of time, if you're having iot use case for example, you, you have or real time credential issuance, you don't want to wait that long. And usually, for example, with B bs plus and other interactive signature schemes, you then have these many, many rounds of communication until Alice is able to receive her credential. So this is a real problem because the high latency between is issuing parties will not allow us to have a very nice architecture that scales well with the amount of issuing parties.

We probably want to have more than three issuing parties, for example. And then the, the high cost we have for the infrastructure, for the servers, for the cloud instances becomes even higher because we need to have these instances on demand, but they probably need to wait for the other instances, instances to compute something. And further we could argue because there we now have the technological isolation, we have the organizational isolation, but because there is so much communication going on, we have another attack vector for a magis malicious party to attack attack our architecture.

And this is what we were working on with on the, on the project that I'm presenting you today because our goal was to use bbbs Plus and what was previously not possible to make the issuance process completely silent and non-interactive. So there is no communication between the issuing parties only to, to Erica in that case, and I don't want to get too much into the mouth part and the, and the cryptographic cryptographic part, but in general how this works is that we now have the issuance in two phases. So we have one phase in which the party's pre-compute empty credentials.

So they do the heavy lifting beforehand without needing any attributes or identity to fill the credentials with. And then the parties are able to issue silently without needing to communicate any further. On a bit more technical level, there needs to be some communication of course, and there is, so there is a seed generation phase in which the party jointly join in a multi-party computation protocol. So this is not a central party that is, that is responsible to give out the seats there.

This is a joint computation, but this is only very limited or minimal in the interaction the parties require. So if you want to have numbers, it takes usually a few seconds, maybe minutes to have the seat generation being conducted. And then they go into an seed expansion, which allows them to use their seeds to silently whenever they want, produce these empty credentials and store them in a database to have them available later.

And this is actually the expensive part of our protocol because here, although it's not interactive, which which is really nice, the main computational effort needs to be done. And then after all this work, we come to the nice part because now if Erica is requesting a credential to our issuers, every issuer is just taking one empty credential out of their database and inter it's going into a, a very small and simple interact, a non-interactive signing protocol, which probably can be done on a raspberry pie or some really simple system and then issue the credential to Erica.

So what does this give us? Because we want to do something with this. Of course we now have a really nice trade off because the computationally demanding part is the pre-processing in which we use our, our expensive servers or cloud infrastructure, but then we have the highly efficient low latency issuance process in practice.

We can, we can gain a lot from this because now we are able to use our, our resources in a much better way. Before we had these expensive servers that needed to be available all the time in order to allow Erica to have the credential in one second. So they needed to be ready.

But, but now we can decide to pre-compute basically whenever we want, utilize our infrastructure to the maximum pre-compute as many pre empty sign, empty credentials as possible, and then use the service for something else, for example. And of course we are flexible because we can pre-compute whenever we want. So if our servers are on low demand during the night, we could just say, okay, tonight there's, there's not much going on. We use our capacity to generate the empty pre signatures to have 1 million for the next few months. And then we are on an enterprise level here.

So probably what is especially nice is when you are using cloud instances, because before, if you have an interactive scheme, you would have like these big AWS cloud instances that are, that are really expensive and need to be ready to, to issue one credential maybe on a low demand period in every few minutes. But you need them to be available so you don't really utilize them very, very well.

But now with pre-com computation, of course you can just take the pre-com computation during night, utilize your expensive instance for a few hours and then cancel it and then go for a load tier instance for example. And then of course, in elastic cloud environments like Azure and AWS, you have spot instances if you are, if you want to compute stuff that is not really time critical and usually they offer very nice discounts if you are, if you don't want the instance to have to have it be like one hour or you can, you can just put do it overnight and save a lot of money here.

So in conclusion, basically, of course, never rely on a, on a single issuing party, we want to distribute, but it is expensive and in our opinion, non-interactive signature schemes for credentialing can mitigate this a bit. And, and we've seen that even schemes that allow for pre-processing potentially offer us financial, financially, financially interesting aspect to, to all of this.

And yes, if you're interested in the really technical details, you can look up our paper. It's currently in Preprint and yeah, there are also the, the email addresses and everything there. So feel free to reach out if you have any questions.

But yeah, and oh, not to forget, there's also a GitHub repository with a demo and everything is implemented, so feel free to to look that up. Thank you so much. Thank You, Leandro. We still have like one minute left, so if we have any questions in the audience, if you take them, we have one question online, maybe you can do that one.

Yeah, Sure. How do BBS plus signatures facilitate selective disclosure of attributes in anonymous credentials?

How, yeah, how? Okay. Basically like, like any other signature scheme that allows for, for selective disclosure, the, the request or the, the verifier asked the, the party that wants to prove proof, her attributes, which attributes to disclose, and then the, the, the ver the, it's do you want to note on a cryptographic level or, or on a high level because, because then she can, she can, she can just send over her attributes, for example, with a zero knowledge proof scheme without disclosing, disclosing them. Okay.

I know it depends what the audience member I probably, so you, you would use a zero knowledge proof scheme in that, in that case. Perfect. Do we have any more questions? Perfect.

Well, if I may ask on my own Oh yeah, sure. Like, again, like with the previous speaker, I had this feeling that, yeah, well it sounds so obvious now that you have this proposal, like what do you need now to turn this academic research into a practical subject?

Yeah, it, it would be really nice of course to have some industry partner that would usually have like a real use case to, to test it with, with, with customers or internally with, with some credential scheme that you want to roll out among your employees. So that, that of course would be really interesting, especially customers that are interested with these highly distributed approach where you have issuing instances all around that globe. So maybe there's also a connection to apply it in the blockchain space. Certainly this can be interesting for self-sovereign identity. Yeah.

So anybody who's, who's looking for something like this, feel free to, to reach out to me. Okay, awesome. And if you do not have any further questions, well thank you Leandra. Thank you so much.