 Good afternoon everybody and welcome to our last two sessions of the day We're going to start with two talks about certificates and our first speaker is going to be Tyler Good afternoon everybody, and I want to say thank you to the organizers for inviting me to speak really is lovely to be here So who in this room uses the web on a daily basis? And we use it for a number of different things Don't we to conduct online sensitive transactions online banking online shopping To connect to our nearest and dearest, but why do we trust the web? I would argue that we trust the web for some definition of trust because we have TLS that works in combination with a public key Infrastructure a PKI now I know a fair bit about TLS But I've always sort of taken this PKI component for granted and at Mozilla as a browser vendor We obviously care a lot about this component because problems in the web PKI Mean problems for every single user on the web Now most people should be fairly familiar with how the web PKI works We have these things called digital certificates and they map an identity's identity to its public key And they are issued by certificate authorities or CAs Now at the top of this chain We have a root CA and it acts as a trust anchor and Its certificate is embedded in the root store of a browser Now there might be a number of intermediate CAs along the way before an entity certificate is issued and at each stage The appropriate digital signature is added And this is effectively how we create a chain that leads all the way back to the root And this is how we inject trust into the web But what if something goes wrong It's estimated that over 500,000 private keys were leaked because of the heartbeat vulnerability and Estimates vary so it's probably a lot more than 500,000 private keys And what does this mean? Well, this means that an attacker could successfully man in the middle your TLS connection and decrypt the current session or An attacker could impersonate a server or perhaps even decrypt past sessions. So this is bad Now what should happen when a private key gets compromised while the corresponding Digital certificate that relates to the public key should be revoked So the owner of that certificate should request revocation and the issuing CA should produce a public cryptographically Reifiable attestation that the certificate should no longer be trusted and the owners is on the client to check the revocation status of the certificates that it receives So revocation on the web is really really important The revocation in the wild is broken What I want to do over the next 35 minutes or so is talk about current methods for revocation checking on the web and why they Don't really work in the browser ecosystem Then I want to talk about CR light Which is a new way of doing things and this was an idea that was actually born in academia Then I want to talk about how we're translating this idea for use in Firefox and Specifically, I want to talk about what it's taken to build this thing Where we are now and we'll also consider whether or not we're done yet a question in crypto engineering Which often has the resounding answer of no If there's time I'd also like to talk about what it means for an academic idea to take root in industry and Whether or not initiatives like this are helping us to move towards a more robust web PKI So what methods currently exist for revocation checking on the web? Well, they are certificate revocation lists CRL's and these are just lists of revoked certificates that are produced and signed by the relevant CA When a CA issues a certificate it includes a URL to its CRL in the certificate And it's up to the client to download the CRL and check for revocation status of the certificate that it has just received But these things can go to multiple megabytes before a page can load So they slow down the connection they add latency, so we don't really like CRL's and we don't make use of them in Firefox Then there's the online certificate status protocol or OCSP This allows a client to query the revocation status of a single certificate by sending an OCSP request to a CA's OCSP Responder it receives the response which is signed by the CA so it can trust this response Now in theory this should be better But these things fail often. They're very unreliable They add latency to the connection and there are also privacy concerns Because they leak the information about the domains to which the client is connecting So what you may have noticed up until now is that the client is doing a lot of the hard work for revocation checking But what if we shift this work to the server and this is what happens in OCSP staple So the server is responsible for sending an OCSP request to an OCSP responder Receiving the response and stapling it or attaching it to a certificate that it is going to serve Now this is a bit better. It addresses the latency. It addresses privacy concerns But it's not quite perfect because an attacker can easily strip off an OCSP response and Happily fail open their way to victory and what does this mean? This means that of all of the methods that I've just described If they don't work if the client cannot determine the revocation status as a certificate It goes ahead with the connection anyway If it were to fail closed on the other hand It would terminate the connection as soon as it could not determine revocation status And that's why we really like OCSP must staple This is a TLS extension which signifies to the client that it will be receiving an OCSP response If that OCSP response is not present it immediately terminates the connection The problem with OCSP must staple though is that it's not widely deployed on the web and many hosts don't actually support stapling So of all of the methods that I've just described that are deployed at scale there are problems They add delays they add latency to the connection. They fail open and there are privacy concerns But what if we could push all revocation information to all clients? We might not need to fail open and we would address the privacy concerns now. There are some initiatives in the space Google has CRL sets and Mozilla has one CRL in which we push partial revocation information To clients. We don't push all revocation information to clients. Why not? I'll let you think about that for a minute There are also other methods that have been suggested for distributing revocation Information and one of them includes using FM radio to do this I really don't think that all clients are going to install FM receivers, but you know, it's a cute idea in theory So why don't we send all revocation information to clients? Well, the issue is size it matters and this is a lot of information And this is where CRL light comes in CRL light aims to compactly and efficiently get all revocation information to all clients And it does this by making very clever use of bloom filters Now because of initiatives like certificate transparency and internet scanning We have a very good view of the certificate ecosystem so CRL light takes this view and takes all of this information and Puts it in a data structure that supports the queries to the finite set of unexpired certificates And this is how it gets all revocation information to all clients So as a reminder a bloom filter is a probabilistic data structure that allows for the insertion of arbitrary sized elements We need a bit array of size M and we need k hash functions for mapping to array indices Now this is a very contrived example for the purposes of illustration So say now we want to put data item D into the filter or we do this We compute h1 of D. This gives us four. So we set the bidding index four to one We compute h2 of D. This gives us 11. So we set the bidding index 11 to one and we keep going Saying the bidding index nine to one and the bidding index two to one But what if I want to put another data item into the filter? it might look something like this and You might be able to see that there's a purple bit up there And that's because both of these data items have collided on this index and that is very very possible So how do we check if an item is in this filter? If any of the HID star values for an item D star is zero Then it's definitely not in the filter if all of those HID star values is one Then it might be in the filter. So maybe it's a legitimate insertion, but maybe it's not So we are going to have false positives and the false positive rate P is determined by MK and the occupancy of the filter Now going forward we're going to think about the set R Which is the set of revoked certificates and the set S Which is a set of unrevoked certificates and together they make up the finite set U of unexpired certificates So say no we want to store the set R into a bloom filter Well, we can do that, but there are going to be false positives But what if we take those false positives and we store them in another bloom filter And this is the idea of cascading bloom filters and this is what Sierra light makes use of So we do something like this we start with the set R and we put it into bloom filter number one But they are going to be false positives These are the elements of S that should not be in bloom filter one But we can find those false positives and we put them into another bloom filter bloom filter number two Again, they are going to be false positives and these are the elements of R that shouldn't be in bloom filter number two We can find these false positives and put them in yet another bloom filter and we keep going until we can't find any more false positives and we don't need another bloom filter Now because we've worked with the finite set U we're in a position to determine whether or not an element Is it are whether not a certificate has been revoked? If a data item is not in the first bloom filter, then it is not in R If it is in the first bloom filter, then we don't know so we move on to the next bloom filter If it is in the first bloom filter, but not in the second bloom filter Then it is in R because it means it's not a false positive. So it's legitimate element of R If it's in both of them, then we don't know and we move on to the next day If an item is in bloom filter one and bloom filter two but not in bloom filter three Then it's not in R because we actually confirm it to be a false positive It's actually part of the set S if it isn't all of the bloom filters for a three level cascade Then it is in R. So you can almost think about these even navid filters as acting as strike lists for R They contain all of the elements that are not really in R, but have made their way into the filter So there is a simple method for checking not whether a certificate is revoked So if we look at a certificate U, we start with I is equal to 1 and we keep going until U is not in bloom filter I If I is odd, then it's not in R. It's not revoked. If it's even then it is in R If U is in all of the bloom filters in all of the BFI, then we look at the number of levels in our bloom filter And if the number of levels is odd, then it is in R. If the number of levels is even then it's not in R Now this does make sense and you might want to think about it for a minute But in case you need it, I have created this diagram So you start with the questions of what bloom filter this is in so is it in bloom filter one? Is it in bloom filter two? Is it in bloom filter three and you make decisions accordingly? Now we obviously want the minimum possible size of this cascaded bloom filter Now a single bloom filter is minimized when K is this value and M is that value But for filter cascades the question becomes how do we choose P so that we have the minimum possible size? Now the authors of the CR light paper did some analysis and they found that it was Optible to choose P1 for the first layer of the bloom filter and P for all of the other bloom filters And we said P1 to be this and P depends on the size of R the size of S and the false positive rate P And when P is equal to a half we get close to a theoretical lower bound for the size of this bloom filter The authors did a few simulations in the paper and they confirmed this and they also state that this cascaded bloom filter Doesn't grow considerably with the size of S. It actually grows with the size of R, which is good So in terms of the CR light architecture, there are two entities that you need to keep in mind There's the client that needs to get these bloom filters and check for revocation Then there's the CR light aggregator, which is responsible for creating these bloom filters and getting this information to clients Now I've shamelessly stolen this picture from the academic paper and this is the academic architecture and you can see on the left They're using certificate scans or internet scans and certificate transparency To make to get a view of the certificate ecosystem Then from that they construct their sets R and S and they make use of CRLs and OCSP responses Then they put R into this filter cascade this multi-level filter and they produce a daily filter file which in the academic setting has a size of 10 megabytes and They also produce a delta update file which has a size of about 0.5, 0.6 megabytes And this delta update file is the difference between yesterday's filter and today's filter So if a client downloaded a filter yesterday, it doesn't have to download the entire filter again It just downloads the update You might also notice that there are audit log files and these are present so that any External party can confirm that the bloom filter or the cascade has been constructed correctly And in the academic setting the client actually has to go and fetch these filter files the daily file as well as the delta file Now at Mozilla, we realized that serial light was going to help us do things the Mozilla way We care a lot about privacy and the reduction in latency would also be great So this is a slide I took from one of the serial light engineers and it's from about 18 months ago When the team was deciding whether or not serial light would be good for Firefox and The reasons as to why it would be good is because it has serial light properties It is small data sizes which are fast to pass it allows for incremental updates It's going to scale well and it builds on the useful properties of certificate transparency So our architecture looks something like this and we actually only make use of certificate transparency to get a view of the Certificate ecosystem because we think this gives us a pretty good view We then construct our set R and we only make use of CRLs We don't use OCSP for this because OCSP is unreliable and it's slow We then construct our filter cascade and produce our daily filter file Which at the moment is about 1.4 megabytes Our delta update files are 0.4 megabytes and we actually want to distribute these things four times a day And not only once a day We also have the architecture for signing and pushing these things to clients So that's already part of our system. We didn't have to think about building that Now the academic paper did have a prototype and they built it as a Firefox extension and In the academic paper they had to make use of TLS JavaScript APIs for certificate checking and JavaScript can be slow and can be quite cumbersome in our situation We can make this native to the browser and we're using C++, Rust and a little bit of JavaScript Now the academic paper cites 10 milliseconds to check a certificate chain and for us to check one Certificate against CRLite on a local machine is about 0.04 milliseconds But we're coming in at under 8 milliseconds if we take all of our Firefox calls into account So we only use CRLite to check for end NTC certificate revocation We still make use of one CRL for checking the revocation status of intermediate certificates So we haven't discarded that mechanism So up until now I've given you a very broad very high level overview of our system architecture But we actually had to go about and build these components for Firefox and That meant that we had to create our aggregator to produce filter files We had to write the client side code for the checking of these filter files And we also had to link all of this up to our remote settings infrastructure to push these files to clients and Trust me. These are not simple steps. If you just think about step one There are over 2 billion entries in the certificate transparency logs and all of those have to be processed at least once by our aggregator And we need to use this information to create the sets S and R and S If you remember is the set of unexpired and revoked certificates and R is the set of unexpired with revoked certificates And one of our engineers JC Jones has been working on this and he recently said to me It's hard Tyler. It's just plain hard So initially we did all of our testing in our experimentation on a single high-performance server with a very large disk drive In some ways development in the setting is easier because you have only one environment to worry about But it required constant monitoring particularly when we're getting close to running out of space So our cloud opt-in in the infinite wisdom said well, why don't you make use of external storage mechanisms for all of this data? So we now take certificate transparency data And we use Google's fire stores in the cloud to store relevant certificate information And we make use of a reddish cash just all these certificate identifiers that are actually going to go into our bloom filters Now getting something of this nature to work had a lot of teething problems from Choosing reddish cash sizes and dealing with a slowdown as these sets grew to encountering go lang timeouts With the fire store. So it really was a learning curve for us and we expected this But JC being the wonderful engineer that he is persisted and we now have a serve an aggregator architecture that looks like this We're making use of Kubernetes that is running in the Google cloud platform And I'm not going to go into too much detail But we have components for processing our CT logs We have jobs that can create these filters We can store these filters and then we have components that are responsible for publishing these filters for sending them out to our remote settings Infrastructure, which will eventually get it to our clients Now JC is very kindly put together some performance graphs for our infrastructure And this is CPU usage of our Kubernetes cluster for filter generation and each of these peaks Corresponds to a generation run and you can see that even at the top peak over there We're not even close to capacity. We're at less than 25 percent of allocatable CPU Now in terms of how long it takes to actually build these filter files on our infrastructure To create these sets R and S takes us on average about 35 minutes and to actually produce these filter files These cascaded filters that we're going to send to clients. We're at about 20 minutes on our infrastructure Now some of the other steps were easier to navigate, but they did present a few bumps So writing our client-side code was delayed by waiting on other Mozilla teams to provide rust bindings for us So this slowed down our development there and linking up to our remote settings infrastructure Didn't present too much of a problem, but it has raised an interesting process question for us Typically our remote settings infrastructure isn't used all that often once a day Maybe less but now we want to make use of this thing four times a day And we wanted to do it in a highly automated fashion So we're going to have to work with our remote settings team to get this working to send our deltas four times a day So hopefully I've given you a small sense of what it's like to try and build this thing for use in a production environment So where are we now? Towards the end of last year. We landed a very basic functional prototype of Sierra light in Firefox nightly and nightly is the highly experimental version of our browser and we landed it in telemetry only mode And what does this mean? This means that we don't actually make use of Sierra light for revocation checking We still make use of OCSP But when OCSP runs we also do a check against Sierra light to compare the difference in the results particularly in terms of speed Now this chart we're seeing some very basic telemetry on whether or not this thing is actually working So we have a big sample which collected over a 12-day period in December the sample runs into the millions and you can see that about 10% of the time the filter was not available and This was actually very useful information to us because it pointed to a problem in our push infrastructure in getting these filter files to Clients so some clients will not receiving these filter files and this is something that we're investigating Then for over 60% of the time the issuer was not enrolled And that's something that I'm going to talk about in a few minutes Some of the time the certificate was too new It wasn't captured by Sierra light and in this instance you really do have to rely on traditional methods like OCSP for revocation checking So for about 15% of the time Sierra light found valid unvoked certificates and although it's not graphically represented There were 289 revocation hits using Sierra light where Sierra light correctly identified revoked certificates Now recall that I'd say we were running this thing in telemetry only mode and particularly we're looking at the difference between Sierra light and OCSP and how much faster Sierra light is than OCSP and This is that information and you can see some of the time It's not faster than OCSP some of the time the difference is around zero milliseconds But we do have a median difference of about 125 milliseconds And we're seeing some very interesting behavior in the tail over here And this is the effect of the one second timeout of OCSP So for over 10% of the time OCSP is timing out, but Sierra light is very quickly getting to a result And then there's some more information here later on and maybe this is when OCSP isn't timing out or OCSP has a much longer timeout So Sierra light is faster than OCSP This is what we expected, but it has been nice to be able to confirm this and with our very functional prototype So there are a few technical caveats that I need to mention We don't currently catch the let's encrypt entries in our filter And this is because let's encrypt isn't making use of serals This is likely to change or we hope it's going to change in the near future So all of the let's encrypt entries will be in our filter But for now they're not and because of that There's some extra computation time because the client actually needs to determine whether or not it can use serial light for vacation checking Sometimes it won't be able to and then it has to fall back to OCSP So we're not fully fail closed yet And I do want to stress that we are still in prototype mode So no, we're not done yet Now in terms of security there was a brief security analysis section in the academic paper But a lot of the paper was set aside to describe how the system functioned Now I spoke briefly about this work at one of our Mizzita summits and Afterwards Tom Shrimpton who's with us came up to me and engaged me in discussing some work that he and the students were doing On the use of probabilistic data structures in adversarial environments And we started talking about how this work might relate to the serial light setting At the same time Kenny Patterson informed me that he'd set a student to work on looking at attack scenarios and threat models for serial light And we are fortunate to be in communication with both of these groups And I hope they're going to join forces and we're still also working with the serial light academic team particularly Christo Wilson and Dave Lemon and My hope is that we're all going to be able to work together to make serial light as robust as possible Before it hits a production ready state So specifically we want to look at some deeper security questions and attack scenarios We want to stress test this thing And what's going to happen when we size it with very big sets and what happens to the p values at all of these levels And this is something Kenny has been thinking about We also need to make sure that we've got enough crypto agility What if we need to upgrade our hash functions very quickly will we be able to do that in our system? We want to look at some architecture enhancements and currently the engineering team is looking at how to produce smaller Delta files and what's the best method of compression and what's the best method of getting those Delta files so that they can be usable So we really do want to make serial light as safe as possible Before it is going to be used in full-scale production So I think a project like this has a lot of nice Collaboration between academia in industry and I think that both spheres have contributed equally The idea was born in academia. It was designed as an academic idea We now have an industry team that's building this thing for use at scale and there are more academic teams That are going to help refine this thing further to make sure that it is going to be as safe as possible for our users So what has it been like taking an idea like this with the intention of landing it in Firefox As I said earlier, we felt that serial light was going to help us do things the Mozilla way So the idea tracked well and the fact that there was already a Firefox extension helped us But the paper couldn't and it didn't take into account our existing infrastructure and in our case the existing infrastructure helps because we have this mechanism for already signing and pushing these filter files after clients and I also think that the timing for a solution like this is good Serial light can exist because of enhancements in other tools, particularly certificate transparency So for us the process of taking this academic idea and trying to get it ready for production looks something like this It started as an intern project and after the internship ended There was some further development and we now have a very basic functioning prototype and over the next couple of months or however long it takes We're going to refine it and then after that we're going to decide on a production plan for serial light And how much we'll actually be able to rely on it for evocation checking in our clients So when I asked one of the serial light engineers what he thought about the system and the entire process He said it's an excellent solution to a problem. We shouldn't have and This is interesting because we have mechanisms like must staple which work really well for evocation checking on the web But they are not deployed at scale and I think the reasons for that go beyond engineering So I don't particularly want to open that can of worms right now But it does raise interesting questions for the web Pki The web Pki is undoubtedly fundamental in establishing trust on the web But it's very very fragile and our systems like this going to help us move towards a more robust web Pki. I Definitely think that it's going to help And I really do believe that the relationship between academia and industry is important I think that by harnessing this relationship together. We can build stronger and safer systems and To drive that point home I want to let you hear from some of the people who are doing the hard work on serial light and I have a video. So let's hope that the video gods are with us And we started working on serial light there had been a long history of developing new techniques for transmitting revocation data Unfortunately, the general consensus amongst everyone in the Pki was that there was no way to transmit revocation data to all clients Without consuming way too much bandwidth But we were determined we figured there has to be a better way because the Pki demands it the specs says that every client has to check for revocations Really only with the advent of certificate transparency logs. Did it finally make a solution possible? So in a funny way the same folks who had said it was impossible to check for revocations Were the ones who gave us the ingredients that finally made it possible After our paper was published Mozilla reached out to us to include serial light into Firefox Which as an academic it's just been a crazy amazing opportunity I think the reason they ultimately decided to pick it up was because they had folks who were Simultaneously writing the TLS one three spec which says all clients have to check for revocations Well at the same time making a client that they knew wasn't always checking for revocations So I think they realized that no browsers were faithfully implementing the protocol But that was serial light it would finally give them the opportunity to do so the question We had was whether we could meet the necessary preconditions in the real world for ser lights Guarantees to hold true could we tell if the certificate was going to be in the filter? Could we tell if an issuing certificate authority was behaving properly? And even with answers to those questions We still had to prove out that we could build a robust infrastructure for a notoriously not robust web pki And that took most of 2019 So while we were implementing this we were discussing it at the security summits that Mozilla runs and peak the interest of Other academic teams who could help us validate the security properties of the production system I think it's great to see a system that makes clever use of probabilistic data structures Making its way into an industry product But it's really crucial to get the security aspects of such a system right before it hits full-scale production And I think there's still some work to do here, but I'm really looking forward to working with Mozilla on that So as I've said, we're very fortunate to be working with these academic teams to help get it robust before we deploy it And I really think that there's going to be a fruitful collaboration going forward So thank you to all of you for listening and I want to thank everybody who is involved in the clite project Who has been involved who may be involved and do go and check out our clite blog posts. They should be live right now Thank you very much Hi to two quick related questions. The first one. I'm just curious kind of from afar You chose to use this cascaded bloom filters, which is not I mean, it's related to bloom filter But it's not the most standard structures. There is like cuckoo hashing and so on Is there a particular reason why you happen to choose this one? We chose this one because the academic paper chose this one They do have a small footnote in the paper saying Oh, you could use other filters or other data structures And I think it's an interesting question to see if other data structures are actually going to be better For an application like this. So I think this has been a question that has already been raised Okay, and I guess very quickly Can you you assume you support like addition and you know, like new certificates and so on so it's it's all okay Yes, yes Hi, similar to the previous question on the data structure It sounds like with the cascading bloom filters the whole probabilistic nature of the filter is Gone because you have to keep doing that till you have no false positives And I was wondering if things like a radix tree or other data structures have been considered For starting this yes There have been other data structures considered as I said previously We just went with what was in the paper, but I think there might be other data structures that could be better All right, super cool talk. I love bloom filters. They're great Approximately how big is your set of revoked certificates you're working with? Ah Good question. This isn't our blog post. Um, I think at the moment We only have about 700 000 in there because we don't have the whole of the less encrypted entries Thanks Hi, so you mentioned that you expect the let's encrypt situation to change Is that because you're going to start checking ocsp or require ca's to Publish crls or something else? I think we're hoping that let's encrypt is going to start using crls Because we want to make use of crls because we find ocsp slow and unreliable to use for construction All right, thanks. And one other question. What's the um input to the what's stored in the bloom filters as a thumbprint? right Yes, it's um a hash a sharp 256 hash value of a serial number and some other data and concatenated with again some um, um Certificate specific information. It's I can't remember the exact format right now But it is in our blog posts of what it is. All right. Thanks Um, so my question is do you see this as replacing as as a sort of Intermediate step before we have ocsp must staple or do you see this replacing? uh ocsp must staple And I'd like to just say i'm a bigger fan of this Great, thank you. Um I think ocsp must staple the idea has been around for a while and it hasn't seen much uptake I don't know if that situation is going to change So we're sort of thinking about this as more of a replacement Can you speak briefly to the big bar on the bar chart the 60 of requests or certs where the issue or wasn't enrolled? Yes, that's because we don't have let's encrypt data in our bloom filter and a lot of that data is that 60 percent Yet we don't have it yet Have you looked at the bandwidth requirements of ocsp must staple the size that that adds to each request by each client versus the size of the crl light um delta Updates and how it may actually be more advantageous in terms of the of the demand on the network for crl light versus ocsp Must staple right. I don't know what the the difference is there, but It could be more advantageous with crl light here Let's thank tyla again Our next speaker is Dan shumo who asked me to mispronounce his name So uh don shumov That's good. Nadia offered to mispronounce my name So i'm here to ask uh the question uh whether or not certificate thumbprints are unique and hopefully answer that as well This is a project uh done by greg zaverucha and myself uh on the microsoft research security and cryptography team So before we get into it, uh, I've figured it'd be prudent to talk about what certificate thumbprints are Um, you may not have come across them unless you're implementing something Or analyzing, uh certificates. Um So certificate thumbprints are just simply a hash of the whole certificate asn one structure Including the to be signed part as well as the signature um And what's in what's really important to note here is that the thumbprint hash does not necessarily uh, it's not that it's necessarily the same as the signature hash and um Thumbprints still may use md5 or shot one So they're essentially just identifiers for certificates of more concise identifier They're displayed in interfaces config files. They can be used to refer to certificates in code um, and they're sometimes similar to a The way a hash is used in a hash table so thumbprints are uh cryptographic hash But they're not really considered a core security Feature in the same way that like the signature hash it is So, um, if you're gonna take anything from this the tldr is uh, that thumbprints are aliases for certificates This work answers the question of, um Certificate uniqueness first by defining the properties we would want For this uniqueness and then using these uh definitions to determine that thumb fingerprints are not in fact unique This ain't csi folks. This is cryptography. So we have to be a little more careful with our thumbprints We didn't find any way to exploit this Or any evidence that it was being used in practice either so now if you want to tune out you can so uh Thumbprint uniqueness Like given that thumbprints are used as identifiers for certificates and Implemented with cryptographic hashes it begs the question if they are unique Especially given that they may be using md5 or shot one Um, and furthermore Because they're not really considered this core security Uh feature function We've encountered devs pushing back on us when we've said hey, you should uh migrate away from these weaker hash functions So that caused us to ask these questions. So to the best of our knowledge, this work is the um, the first place where any sort of properties about um, the Certificate uniqueness have been introduced So informally the two, uh, the there are two properties That we want from certificates that uh certificate thumbprints that identify both directions of uniqueness that we would have So, uh property u1 is that no two Different certificates, uh Should have the same thumbprint and then in the other direction that a thumbprint should uniquely identify a certificate so This property u1 that different certs shouldn't have the same thumbprint um You know as this is a hash of the certificate, uh Collision resistance is going to be enough to guarantee this u1 uniqueness But in practice because md5 and shot one are used that may not be the case So We'll actually show how a certificate issuer can create two certificates with the same thumbprint um However, this is slightly more complex than a Collision attack because the thumbprint is computed over the whole certificate including the signature So this property u2 is that a certificate should have a unique thumbprint associated with it um So if the certificate is held constant then changing the thumbprint means modifying the signature for a given cert and as such this u2 property is related To both strong unforgeability of the ca signing algorithm and also encoding malleability And this property in particular has an implication for security um in Certificate revocation lists Like the last talk that we saw um so To demonstrate how we can break this u2 property I have here the pEM for a certificate that has Two different thumbprints. Um This is because ecdsa is cryptographically malleable. You just re-sign Generating a new blinding value that will generate a new signature and then you'll have two different thumbprints um RSA is not cryptographically malleable because of padding Um, but the asn1 dr encoding can be mangled Um in a way to modify to create different thumbprints. So specifically the way this works is You have a cert laid out like a tbs certificate A signature algorithm And then a signature value This signature algorithm is an algorithm identifier sequence The second field of which is optional. So there are two different ways that this could be encoded with a null type Or just without the field So the x509, uh standard specifies that Signature algorithm must match the signature field of the tbs certificate But This is not actually enforced in windows. We'd like to thank the anonymous reviewer who pointed that out to us So in some cases you may find that you can Exploit this so and we did in fact find certificates in the wild with this difference So now on to creating colliding thumbprints. That's breaking that u1 property So certificate thumbprints still often use sha1 And uh, as I mentioned before it's not exactly clear whether a collision attack alone can be used to create colliding thumbprints Because of the extra structure with the signature So what we did is we used an md5 chosen prefix collision attack because when we did this work sha1 Chosen prefix collisions were not feasible as that was just demonstrated earlier today for the first or presented earlier today for the first time so, uh We actually additionally required a key substitution attack to create colliding thumbprints And uh, i'm not going to go into the details of key substitution attacks You can see those in our paper if you would if you're interested, but i'll just say that Essentially every x509 certificate in use today is signed with an algorithm that allows a key substitution attack on it And so what we demonstrate is how uh a ca or a certificate issuer can create two certificates with the same md5 thumbprint So What's going on here and why we need more than just a collision attack is because certificates are laid out with a Pre-signature part the tbs Certificate and then the signature after that so if you did the collision in this p part of the cert The signature would change because the signature signs A cryptographically strong hash So what that means is that additionally? The attacker is going to have to control the signature as well so to sort of Give the high-level layout of how this attack would work The attacker wants to Create a certificate With the same thumbprint as a honest certificate c1 So the attacker first is going to execute a hash collision attack Creating a colliding block And insert that into the ski of Their malicious cert c2 Then the attacker is going to compute the signing hash of their modified cert and signature Sorry, they're modified cert and ski And then they'll use a key substitution attack to sign this new hash and create a matching signature t Then they'll go back and get a cert issued for their The key that they generated with the key substitution attack and they'll have a valid cert that will verify In the in the pk so After we demonstrated this We scanned for colliding thumbprints in the wild we did we did this by getting data sets From project sonar Published at scans.io This represented 125.8 million unique certificates and What we did there was we computed thumbprints And looked for certificates that may have the same md5 sha1 and sha256 thumbprints. We didn't find any We ran md5 and sha1 collision detection Did not detect anything there And we also additionally looked for key substitution attacks By looking for certificates with matching signatures And we did in fact find several certificates with matching signatures But on closer inspection none of these appeared to be created with key substitution attacks So In short we found no evidence of Colliding thumbprints or any of these attacks So while checking for key substitution attacks, we actually found something interesting greg found something interesting particularly so We found that 380 such There were 380 self-signed certificates That had the same ecdsa r value And as it turned out this led to the discovery of an actual cve Specifically that certain sysco hardware Had insufficient entropy in the drbg and ended up generating the same ecdsa blinding value So in conclusion We introduced two properties to describe the uniqueness of certificates Of uniqueness of certificate thumbprints And in terms of these two properties, we showed that with We cash functions certificate thumbprints are not unique and we provided examples of this We looked for a way that this could be exploited in software such as tricking software to accept a new certificate When it had been presented an honest one previously with The same thumbprint, but we did not find any examples of this And we also searched for certificates with colliding md5 or sha one thumbprints In internet scans, and we did not find any there either So based on this work, we have a few recommendations Specifically that applications should Migrate their thumbprints to the stronger hash functions sha 256 or 512 Um if digest length is an issue Truncating a stronger algorithm To a shorter digest length is preferable to using a weak algorithm in this case and If you can't change the hash algorithm used for thumbprints use collision detection And we would encourage projects monitoring pki such as a certificate transparency to check md5 and sha thumbprints A sha one thumbprints with collision detection as well So also to any devs who are working With certificates and certificate thumbprints You know look for ways in your software that non unique thumbprints could be used to exploit security Because we obviously don't have visibility into all the places that thumbprints are used So thank you very much for your attention and you can check out the full version of the paper on the eprint In any hash collection situation The collisions may be Unprobable probabilistically they can't occur I mean the formula for that is well known well documented that you have maximum population size deploy population size What's the probability of collision? It may be probabilistically very low, but it is real what happens us if a collision occurs naturally In the in the ring that you're doing probabilistically. It's unlikely probabilistically it must be assumed that it will occur well, uh, so for the thumbprint case, I mean the the more critical Case of this would be in for the signing hash so You know so Because The hash functions are defined in such a way that you know they Would be you know at one time we're fine for signing It's not it wasn't not that's not really as much of a concern in this case So if you would get two certificates with the same thumbprint In terms of any collection Yeah, so you would have to have it's The square root of the total size of the range right probably the if you want to give you the formula offline There is a formula for that that that that is there for population of m Of n m m deployed. What's the probability of collision and it's it's not the square it's it's different formulas Uh, so it's it's different than the birthday It's much more realistic. You know what what is the chance of a 1% collision? What's the chance of 100% collision? Okay for that. Well, not not the wasp was kind of of a guaranteed collision. Well, yeah, we didn't cut we did not compute that probability but You know, it's a bigger problem for the signing hash I would argue and also In that case, uh, we're more concerned about Easy to compute collisions on these thumbprints Yes, so, um, it's probably my fault for not being up to date with this area of the literature But you you mentioned a couple of times checking for collision detection Um, how do you do that? What does that mean? Oh, that's uh, that was introduced by mark stevens Uh, when analyzing, uh, the flame attack in, uh, counter crypt analysis Uh And basically what you can do is while computing an md5 or shot one hash you can check Uh For differences in the message input blocks that would cause a collision so you can in fact filter out Inputs to hash functions that uh are causing a collision while you're hashing just one of the objects cute. Thank you So those certificates you found with matching signatures. What's the story behind those? Uh There is an extensive list of these in the uh in the full version. Um, there were Versions that looked like Firewalls replacing certs, uh, without sort of replacing the signature There were bugs there were normal corruptions there there were many different reason Reasons for this greg did a pretty extensive analysis of those Thanks Hi, um, I wanted also to ask about the up here I wanted also to ask about the, uh The colliding signatures. I was wondering like was this only old hardware like in the case of mining pz and q's or Is it also newer hardware? Uh The cisco one, I mean The the cisco cv that greg found. Yeah, because my so there was a similar situation for mining your pz and q's were like Scanning rsa public keys. I'm sure one prime and my understanding was that that was caused by low entropy during boot. Yeah Yeah, yeah, yeah the poor random number generation. I was wondering if that was also the cause It's yeah, it's it's like a in an abstract sense. It's like a similar cause Yeah, like root cause. Yes, but is the hardware any newer than that? Uh Did you look at ecdsa and the mining pz and q's? Just because recently I read something like oh newer hardware doesn't have the problem of low entropy during boot so the Actually, we had a follow-up paper to pz and q's and it was in 2016 marcella who gave it one of the talks earlier was one of the co-authors um, and New vendors keep introducing the same flaws over and over again So it's never going away. All right So, uh, we are over time. So let's thank dan again Okay, um, so our next talk will be jointly presented by christianne and jago Okay, hello everybody um Let me start with thanking the team at abron emerald bank for some of the inputs when we compiled this story In particularly, I would like to thank babara and yerun. Babara is here today So feel free to seek her out and also ask her some questions Before we dive into the case of abn emerald bank I would like to put this into perspective and just give you a figure That is yearly surveys, you know, there's service on security on everything but there's also an encryption and this There's a yearly survey Which basically stated for the last one that 45 percent of all large enterprises have A encryption and key management strategy that is consistently applied throughout the enterprise So just to give you an idea 45 percent of large enterprises encryption and key management What we want to talk about is a crypto strategy that goes beyond encryption and key management It contains it And to show Yeah, how we started from defining this strategy to the implementation and jago will start this off Thank you So in 2016 which is when this story begins I was the head of the crypto services team within navy and emerald And when it came to cryptography, this is a little bit the situation that we have First of all, we have a two factor authentication system based on pki for our Corporate laptops, which makes us very proud. We've had it for many many years And I think that's a good thing On not so good things. We have a central certificate management service, which is basically a mailbox So if you're a developer and you need a certificate, you have to send an email to our mailbox and there's some Pinkpong going back and forth and eventually if you're if everything goes, okay, you get your certificate Generally speaking this process would take about a week one week to get a certificate We also have a central key management service And the key management service is basically a very large and very secure three factor authentication safe And we have very good written procedures to access the key material inside of it So I think this is actually Quite secure quite good on security front. It's not very scalable and it's also painfully slow every time you needed to Insert a key into some system It's a process that would take at least half a day to a day and multiple people would have to be involved We also have a number of hsm's for our payment systems So our core systems where our banking is They we deal with hsm's and our crypto services team is centrally managing those So we know hsm's well And also in 2016 Google and microsoft were basically saying issuing a patch that was saying enough is enough No more shall one so This that we're seeing here back in 2016. I think we're just doing the bare minimum And we needed a strategy so in 2016 we gave IBM a call and said, okay, can you help us out here and we Created a crypto strategy which in a nutshell was Trying to create something like this. So in 2016 we're saying three years from now This is what we're going to have to do in a high level And the application side of cryptography is mostly about central services That would be delivered to the whole bank while the innovation side is mostly about capabilities that the bank must have Capabilities that might or might not be delivered from the central crypto services team And then this is High level what we had back in 2016 and nowadays we have a much more comprehensive set of services central crypto services as well as capabilities implemented within the bank Now I don't want to borrow you to death with All of these kind of stuff that we're currently doing But I think it would be really interesting to share some of the lessons learned that we had as we implemented this crypto strategy And to do that we're going to share four stories The first story is about shallow migration So that patch was coming along if you have a certificate we shall want it's no longer going to work So all we have to do as a bank is just migrate away from all of these certificates So for that we set up a task force The first task force was looking for external facing certificates And this was a relatively simple process our we Know very well our external facing websites. They're our most important ones or were We're using chat two certificates now for years. So that was a relatively simple thing. We're talking about a few hundreds of systems The problem became with the internal facing certificates because the internal facing certificates we couldn't really rely on the Inventory that we had And that was because to get an internal facing certificate. You'd have to wait a week to Get your certificates. So generally speaking developers would try to bypass this process as much as humanly possible And this created a huge amount of certificates, which were really not Knowledgeable to us in the central team So what we had to do is to scan the entire network for certificates trying to find what the Certificates exist which ones are which ones have shall one on them We'd have to do multiple passes of the scanner because some some parts of the network you really couldn't access And some certificates would appear in some scans, but disappear in the next Some certificates would appear multiple times in one scan. So how the hell did that happen? And We eventually had to set up a whole team of six or seven people that had to work on these On this for well over a year And just to give you an idea This is one of the dashboards that we're sharing with one on our internal stakeholders This is the magnitude of systems that we're talking about thousands of systems Tens of thousands of certificates each each one would be its own special little snowflake So eventually we did it we migrated away at a very painful way in a very high cost So our lesson learned here was know where your crypto is And we can start with certificates because as you As organizations become more and more autonomous and we let teams become more and more autonomous It's extremely important that the central team still knows where all of the different Instances of your cryptography are because when you want to move migrate away from something whether that's certificates or anything else Then having the inventory Makes a huge difference Our second story is about hsm's so You remember that we had the hsm for our payment systems We know those well and in 2016 we decided to augment that because we already have the hsm for payment systems Those are fine and up and running and they work fantastically So we can't get network attached hsm's The beauty about network attached hsm's is that they allow for an abstraction Layer for the developer, which generally speaking doesn't know cryptography that well By providing that abstraction layer we simplify their experience When it comes to cryptography and we incentivize them to use Central services where the cryptographic operations are done in a central in a protected environment As opposed to let them code the single aspect of any kind of cryptography which they're using Our lesson learned here was As much as possible we have to try to make Crypto easy to use and and and deploy Especially for our developers The more the easier you make the experience for developers the more they all want to come to you and to use your central services And nowadays what we have is a far more comprehensive set of hsm solutions For all the different platforms that we use and for that will enable also us to have a much better key management service Which will feed from all of this Now for the third story i'll hand over to christiane. Okay. Thank you So what you heard till now key management certificate management There was operational that was getting the basics right But there was also the ambition like next time they didn't want to call me or my colleagues But they want to say can we do this ourselves? We need to have the knowledge in house. We want to do consulting want to do Knowledge sharing And we need to build this up and that's kind of what we set out to do We defined the skills we found the people and we you know Went from a purely operational team to a team that can do consulting and advice the business and one of the topics you know because I like post quantum cryptography. That's a topic I brought in there and then people were like, whoa Shaw one was such a pain this deprecation. We don't want to do this again Should we start when should we start and the answer was I said we start now, right? So that's the answer And nowadays there's a team of crypto consultants that works Um with the business explains the issues to the business prepares them mentally, right? I mean, this is just thing but they also talk to academic researchers industry researchers to find out Peel the poles and just Find out what is coming And not just wait for nist to finish a standardization process because what we learned crypto migrations Take time and they're very costly So I've seen the topic only once, you know famous In industry we talk a lot about this crypto agility at the moment So what I want to explain here is that there's a lot of People shout for crypto agility But for the bank it actually means for the enterprise it means Need to do it end to end you need to look at the whole stack and what we learned from the migrations is Maybe fairly simple to change something in a script More complicated to go to applications, but if you go to s player or all the way down to hardware it will be More costly will be more effort to do all this, right? So when we talk about we need some solutions we need to prepare for the next move It's not, you know I don't think there's one solution that fits all so we need to look at the whole stack and the whole landscape And that's basically what the team is nowadays doing doing and they're Started with certificates inventories, but they're also going further inventorizing libraries and so Last story is then, you know ambitions were there already In 2016 and finally it was like we not only want to Run our systems. Well, we don't want to just do some consulting But the banning said we want to do innovation I said, okay, you want to do innovation? Okay, how do we set this up? And what we we helped them to to come up with was that we talked to the innovation department And we said, you know, you guys in the bank has an innovation department you do You talk to the business. You know what their problems are We have now people in house who know photography You know, maybe we can bring you guys together Right, so it doesn't make really sense to have the operational team and a siso Organization to do innovation themselves, but it makes sense that they work together with the innovation department and Try to look at what is actually needed and how can you bring cryptography? to the use of the bank and What they also do and especially also the innovation department is they go out and they talk to researchers both in academia and in industry and try to find out Solutions that then can be, you know, developed and then applied and run as part of the security organization and Just something we too. We can't get credit for this, but you just want to show this as an example one of the What what came out of this strategy in this? Perception that finally you have to do something and crypto can do something for you is that the researchers in avian amuro. They worked with with a researcher with industry researcher that was IBM research back then and then later also with TNO and and other banks together and what they did the use case is actually fraud detection The business they don't care about cryptography. I'm very sorry, but they care about fraud detection at bank And they came out with clever algorithms and they came even with a way to share insights with other banks Running the same fraud detection algorithms and they can do this with the magic of multi-party computation So they can change exchange information without revealing any Confidential information about their own customers or Operations So this is just an example from how you start with fixing your your basics To consulting to innovation and then what they did in research actually then implementing it and making it work for the bank and now We we want to close off with what's next right There's still a couple of things going on So we mentioned past quantum cryptography crypto agilities on everyone's mind but of course there's also a big push to go to to public cloud to to DevOps and that's where we try to say not only dev sec ops, but we want to have crypto properly used in from the start and The team is working hard and we're working with them together to get this right and prepare also how to use crypto securely in times of big data That's it. Thanks a lot. Thanks for your attention Um, you mentioned uh Sort of preparing for the post quantum crypto and i'm wondering what are specific steps You know, are you guys taking in what will you recommend to other enterprises to do in regards to that issue? so um The first thing you have to do is is to have an inventory of of Your to-do list basically and when it comes to post quantum, there are two aspects of it the symmetric cryptography Which we know we're still waiting for nis to to standardize For everybody here at nis. We're rooting for you please hurry up and um As for a symmetric cryptography is something that we can start doing already today by doubling the key length for for uh for stuff um So the the thing that I could recommend for for very large enterprises is the the hardest part is likely going to be Knowing that having your to-do list when it comes to to a symmetric cryptography Which is not just specifically certificates So start doing that and as soon as nis says gives us the thumbs up then we as an industry can start migrating away We're short on time. So let's thank christianne and tiago again So our final talk of this session and the second talk in the enterprise crypto Section of this session is going to be given by gavin watson. Okay, so Um, thanks. Uh, yeah, so i'm gavin watson. I come from a visa research and what i'm going to talk today is about a Threshold crypto scheme which was designed within visa research And we're in an ongoing effort to then take that to put it to the the wider visa Um, so that they can uh use it with an enterprise setting So i'll talk about is how we can take this kind of theoretical instruction And what we need to add to it to make it suitable to be used in such a setting So I don't need to tell anyone in this room. The encryption is important And we all know that it's important. It gives us all jobs And so what I will say is that one thing with encryption is what we're doing is we're taking Data that when we have in plain tech that we're encrypting it. So we're removing the risk from that data to the keys themselves So now we just need to protect the keys to make sure that the data is secure And but what that leaves us with is the problem of key management So we heard a little bit about key management in the in the last talk and in the financial industry It's important that sometimes we use hsm's and key management kind of equates to all we use an hsm for this But if we consider the context of data arrest encryption How is an hsm actually used? Well in practice, we don't actually send all the data to this network to apply in hsm because that's a lot of data We need to send across the network and so what we employ is we have a key hierarchy So we have a key encryption key which is held inside the hsm That key encryption key is going to be used to encrypt data encryption keys So when I want to encrypt some data If I don't have a data encryption key and I'm going to generate one in software I'm going to use that to encrypt my data And I'm going to make a call to the hsm to encrypt the data encryption key with the key encryption key So then what I store a longer term is the encrypted data along with this encrypted key So the benefits of this approach is it's fast because the actual encryption of the large amount of data is happening in software at the application And we get the benefit that we have harbor harbor protection of the keys. Thanks to the hsm But the downside of this approach is that it still requires an expensive hsm And that the data encryption key is left unprotected in memory And when it's when it's not in use And that might not seem too bad because we're just encrypting a file and we immediately encrypt the key back under the kek But in practice, that's not the case It'll often be the case that I Unwrap my data encryption key and then I hold it in memory at my application for weeks at a time Encrypting large amounts of data. So during that kind of two week period it could Possible that the data encryption key is going to be exposed And if we look at kind of the requirements for key management, which come from the kind of financial setting And so this is a quote from the PCI DSS document. So PCI is payments card industry So that's the body of all different major players within Financial industry who define kind of what it means to be secure The DSS is a specific document, which is the data security standards and requirements 353 that i'm highlighting here Is what it tells us to do about key management Um, so what are the things we need to do we need to do some or all of these different things So the first point is about this kek deck that I just mentioned Second point is maybe about using an hsm and the third point is well if we're not using these Then we need to kind of distribute the keys. So they're not held all together in one place So what we want with this threshold encryption scheme, which we call dice is we want a pure software solution Um, but still with strong security. We're not just going to be holding keys Uh to be exposed in an application. We're using a threshold scheme. So these keys are going to be distributed So dice is the the solution we have for this where dice stands for Distribute symmetric encryption Okay, so dice was originally published by some of my colleagues at ccs in 2018 And so peter and peyman are here today Um, it was also presented at the mist workshop on threshold cryptography last year Um, so if you were either of those two previous talks, you would have got kind of the technical details about dice I don't have time to go into the full technical details So I'll just give a high level and then move on to talk about kind of the deployment challenges when we're taking such a scheme To use it within an enterprise setting So here's the high level overview of dice. So as I mentioned it's a threshold encryption scheme So it means is we have a collection of nodes We distribute the key the master key across those nodes each each nodes getting a different share of that key When an application or a user wants to encrypt some data, what's going to happen? So I want to encrypt some data d I'm going to do a cryptographic commitment to that data that I want to encrypt I then send These commitments out to a threshold number of the nodes in the network Those each of those nodes together with their key share calculate some new value And actually what's happening here is we're calculating. Uh, we're performing a distributed prf And you can even in fact view this as a distributed key derivation um And so dice itself has two different um modes one which is based on using a yes And another one which is based on elliptic carpet coffee As I mentioned earlier if you want the fuel details are referred to the paper or come and talk to one of us after the talk Um, so yeah, so once these nodes have done this calculation They send these parts back to the the the encryptor of the the data They can then reform this into an ephemeral one time data specific key So this key is going to be tied to the data that we are performing We are encrypting we then use this to encrypt the data itself So the ciphertext is now going to be posed off this encrypted data Along with that commitment we we calculated earlier because we're going to need that commitment later when we want to do decryption Because decryption will just be the same thing We do this distribute prf to re recalculate the key to then do the decryption later So benefits of this approach is that the master key always remains distributed It never needs to be recombined at any time As a threshold encryption scheme it's secure against a t minus one. So it's up to one less than the threshold number of um parties as long as they are No more than that are compromised. We're still going to be secure Um as a very small network cost because again, we're not sending the full data across these nodes We're just sending this very small cryptographic commitment And on the other side of that because we're just sending the cryptographic command We get data privacy none of these nodes will ever learn what i'm encrypting because they only ever have that full data Back at my application where i'm going to encrypt the data Okay, so in terms of performance if we look at the aes based version of uh dice We get really good figures in terms of the performance. Um, there's a much more detailed Kind of figures in the in the paper if you want more details But here's just one example of one of the setups we did and here we get really good figures You can see throughput throughput of a million encryption per second and a latency of half a millisecond per encryption If we wanted to compare dice with other approaches So first of all going back to the hsm story. Um, so because it's a pure software solution It's cheaper and more scalable on hsm's If we compare it to secret sharing which we heard a little bit about earlier today Um the benefit of dice is we don't need to recombine that master key to do our encrypt decrypt operation The master key will always remain distributed And then comparing to mpc And because we're just doing this distributed key derivation and then actually encrypting our data locally We can get much better performance than you would with with mpc Okay, so that's a very high level very quick Um overview of dice. So now I want to talk about well, what are the things we've needed to add To our kind of academic code of dice to make you something which is usable in an enterprise setting So going back to the story of key management, which again we heard in the previous talk Um, so we can have some nice funky crypto which allows us to generate the master key in a distributed fashion So no one ever learns the full key Um, but in practice we may need some other functions around that So we may need to be able to import and export master keys from the system Consider we have a deployment of dice in north america and we have another deployment in europe So they're both going to be encrypting decrypting the same data But they're going to be doing that in different places. They need the same master key So you're not going to be able need to be able to import the master key from one System to export it from one system to import into the other. So you're going to need extra functions that allow you to do that You may in some sense if you're if you're very prudent you might want to export it So you can take a backup of that master key and some other secure location From an interoperability perspective because in any large enterprise we have many different systems We're going to need to be able to migrate system from Some system into the dice network using these different keys We might need to later migrate data out of being encrypted using dice to encryption under some other system So we're going to need to be able to have flows which allow us to do that in a in a nice easy fashion And then finally because it's the compliance because it's the financial industry We really compare about compliance And going back to that pc i standard sometimes we really need to tick that box that's saying we have a hardware root of trust It might seem contradictory to what i've said already But maybe in some instance we need to talk tick that box for the auditor And it could be as simple as that the master key backup is held within some secure hardware The next deployment reality authentication and authorization. So I saw in my high level Can I depiction of dice? We have this user calling into the network to perform an encrypt or a decrypt But really we have to check that this is a person that's permitted to making these making these calls And so the first thing we need to do is we need to authenticate them and we can just do that based on standard practices So give that person a client side certificate and then they're authenticated based on the mutual tls channel that they establish But then once they're authenticated, what are they permitted to do? So one thing we can do in terms of authorizing what they can do is that in that commitment we calculate For dice when we commit to the data we're being we're encrypting We can also commit to an identity of a user which will be later permitted to perform the decryption And in that time of decryption the dice knows can check that that user calling to do a decryption is the permitted user One of the other things we can do is that sometimes in an enterprise setting We have many different applications and we need to separate them within different key zones So different applications are permitted to use different keys. They have different master keys for dice, let's say So at the time of the making the call We need to check whether they're authorized to use the master key that they're calling to the particular set of dice nodes that they're calling for Next point api and connection management So when designing any cryptographic api we have to bear in mind It's not going to be used by experts not going to be used by cryptographers necessarily So we want it to be really simple to use. So we want a really minimal api So from this perspective to some extent all we really want it to say is do encrypt or do decrypt We don't want it the the developers who have to understand that you're making calls to these two different dice nodes to then Regather these together to calculate some ephemeral key, which we're going to use that should all be hidden behind in the library That's that's going to be helping you with that But then the library itself because it's making calls to these many different dice nodes It needs to be able to manage all those connections. It needs to know who it's talking to and where it's reaching out to And so what we do with dice is we add this traditional entity, which we call a broker And so this connection broker you can think of like a phone directory or maybe even like a dns server So that's basically just going to help you you can reach out to it And it tells you where the the dice nodes are that you need to reach out to which dice nodes are currently live It might help in the future with some some load balancing And so then with that information back at the library it can reach out to the appropriate dice nodes To then perform the distribute key derivation But of course if we're adding in this broker We don't want it to be a single point of failure. We don't want the dice nodes to be single points of failure So firstly in terms of dice itself. We need to set the appropriate threshold So we need to set the right amount of dice nodes themselves and we need to set them up with an appropriate threshold It's going to give us a good level of security We need some redundancy in the broker We don't want the broker to go down and then the application doesn't know where any dice nodes are that needs to contact So we need some redundancy there And then the final point which is maybe A little bit funky. So we want to Create a varied attack surface So we have many different dice nodes if I'm an attacker and I want to Break into the dice system. I need to break more than a threshold number of these nodes So if I kind of make these dice these nodes very different Then he's going to need to perform different attacks on different nodes to be able to break the whole system So I could have some nodes which are window servers some which are linux servers And so it's going to be much harder for him to to break into it They kind of the practical issue with this is it makes it much harder for system administrators They now have a much more diverse landscape. They need to manage so it might be a pain point for them to do that in practice Okay, so that's kind of some of the realities we faced when working with The actual teams that use these systems in practice. So we're currently ongoing in terms of getting us up and running so we can get a Look at and use really in an enterprise setting We're also working internally through our processes to be able to open source this So hopefully in a month or so I should have some positive news and we can share it with you guys And you guys and you can also have a play at using our our threshold encryption scheme And so thanks and any questions Thank you Gavin. Um, is there any interest in this kind of context of adding key rotation functionality Where you either change the data encryption keys or the key encrypting keys and what kind of techniques do you have in place for that? Yeah, so there's obviously that would be a very useful thing to have. Um It's not something we initially have at the moment Um, as I mentioned, we have kind of two Types of dice. There's the aes based one and there's the curve based one So they live to curve based one. Maybe there is some scope for doing something there on the aes based one It might be more complicated that would be some more thought And and have you done a risk analysis that says this kind of diversity of platforms Reduces the risk compared to using an hsm And if not, how do you kind of persuade the business that this is the right way to go for your architecture? Um, that's a good question. We've not done any kind of concrete analysis of that. Um But I think They see some some validity in this approach and maybe not going to do it for every single project And but for some projects, they see that as something which would be useful Thanks for the talk You mentioned one of the things with deployment is if you can you know get into a threshold of servers Then you can attack the system and then you also mentioned using like different platforms like windows linux and such Um, I suspect you're probably using some sort of shared library for the cryptographic implementation So if you're shipping projects like that, how do you ensure that? Um, that library itself is not compromised and then shipped alone where it could start, you know sending off Keys to other places that that is a good. Yeah, that's a good question. Um Um, I don't I don't necessarily have a good answer to that You could have different implementations off the library different implementations off dice So you have different versions of the library which then gives you that additional level of complexity But again practically that's kind of an issue because then you're managing Much more different versions of the library Let's all thank Gavin again And let's thank all the speakers of this wonderful session and that concludes our program for today