Real World Crypto conference 2020: session 10

good afternoon everybody and welcome to our last two sessions of the day we're gonna start with two talks about certificates and our first speaker is going to be Tyler all right good afternoon everybody and I want to say thank you to the organizers for inviting me to speak it 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 pk I 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 and identities identity towards public key and now 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 it's certificate is embedded in the root store of a browser now there might be a number of intermediate CAS along the way before an end entity certificate is issued and in 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 five hundred thousand private keys were leaked because of the heartbleed vulnerability and estimates vary so it's probably a lot more than five hundred thousand keys and what does this mean well this means that an attacker could successfully man-in-the-middle war 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 that issuing CA should produce a public cryptographically verifiable attestation that the certificate should no longer be trusted and the onus is on the client to check the revocation status of the certificates that it receives so revocation on the web is really really important verification in the wild is broken and what I want to do over the next 35 minutes or so is talk about current methods for a vacation checking on the web and why they don't really work in the browser ecosystem then I want to talk about the CR Lite 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 questioning crypto engineering which often has the resounding answer of know if there's time I'd also like to talk about what it means for an academic idea to take root in the industry and whether or not initiatives like this are helping us to move towards a more robust web PKI so what methods currently exists for revocation checking on the web well they are certificate revocation lists CR ELLs and they are just lists of revoked certificates that are produced and signed by the relevant CA when a CA issues a certificate 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 ad latency so we don't really like CR ELLs and we don't make use of them in Firefox that means 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 and received the response which is signed by the CA to a contrast of 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 legal 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 a CSP staple so the server is responsible for sending an OCSP request to a no CSP 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 the methods that I've just described if they don't work if the client cannot determine the revocation status a certificate it goes ahead with a 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 I be really like Oh CSP must staple this is a TLS extension which signifies to the client that it will be receiving in 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 there are 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 science it matters and this is a lot of information and this is where Siara life comes in see our lights 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 Cyril 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 size to 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 H 1 of D this gives us 4 so we set the brain index 4 to 1 we compute H 2 of D this gives us 11 so we set the between index 11 to 1 and we keep going saying the billion index two one and the bidding index two two 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 M K 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 I said s which is a set of Unruh voke certificates and together they make up the finite set u of unexpired certificates so so now we want to store the set R into a bloom filter well we can do that but they 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 the CR lights makes you self 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 in R whether or not a certificate has been revoked if a data item is not in the first bloom filter there is not in our if it is in the first bloom filter then we don't know so we move on to the next blue filter if it isn't the first bloom filter but not in the second bloom filter then it is in our because it means it's not a false positive so it's legitimate element of our if it's in both of them then we don't know and we move on to the next day if an item isn't roomful to one and bloom filter too but not in bloom for two three then it's not in our because we actually confirm it to be a false positive it's actually part of the set is if it is in all of the bloom filters for a three level cascade then it is an R so you can always think about these even now it filters as acting as strike lists for our they contain all of the elements that are not really in our 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 you we start with I is equal to one and we keep going until you is not in bloom filter I if eyes aren't then it's not an R it's not revoked if it's even then it is an R if you 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 art then it is an 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 for two one is it in bloom fortitude is it in bloom for two 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 in is that value but for filter cascades the question becomes how do we choose piece that we have the minimum possible size now the authors of the C online paper did some analysis and they found that was optimal to choose p1 for the first layer of the bloom filter P for all of the other bloom filters and we said p1 to be this and P depends on the size of our the size of s and the false positive rate P and when P is equal to 1/2 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 confirm 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 this is the client that needs to get these bloom filters and check for revocation then there's the sierra 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 there using certificate scans or internet scans and certificate transparency to make to get a view of the certificate ecosystem then from that they construct a sets R and s and they make use of CR ELLs 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 the size of 10 megabytes and they also produce a delta update file which has a size block low point five nine point six megabytes and this Delta update file is the difference between yesterday's filter and today's filter so if a client downloaded a 40 yesterday it doesn't have to download the entire filter again and 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 i Priscilla we realized that Sarah Light was going to help us do things the mizzen away 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 Sierra Lite engineer and it's from about 18 months ago when the team was deciding whether or not Cyril light would be good for Firefox and the reasons as to why it would be good is because it has CR align properties in a 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 this to begin ecosystem because we think this gives us a pretty good view we then construct our set R and we only make use of Searles we don't use OCSP for this because o CSP 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 megawatts our Delta update files are north point 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 api is 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 well the academic paper cites 10 milliseconds to take a certificate chain and for us to check one certificate against your alight on a local machine is about noir point naught for milliseconds but we're coming in at under 8 milliseconds if we take all of our Firefox calls into account so we only use Sarah light 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 we actually had to go about and build these components for Firefox and that meant that we had to create our aggregator to produce photo files we had to write the client-side code for the checking of these filter files and we also had to link all of us 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 two 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 this assets s and R and s if you remember is the set of unexpired and revoked certificates and ours the set of unexpired but 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 op team 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 Redis cache 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 Redis cache sizes and dealing with a slowdown as these sets grew to encountering golang timeouts with a firestorm 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 CTO 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 photo 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% of allocatable CPU now in terms of how long it takes to actually build these filter files on our infrastructure to create these sets are an S takes us on average about 35 minutes and to actually produce these photo files these cascaded filters then 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 elements in the teams to provide rest 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 mode 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 Sarah 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 Sarah light for revocation checking we still make use of our CSP but when OCSP runs we also do a check against they are lights to compare the difference in the results particularly in terms of speed now this chart were seeing some very basic telemetry on whether or not this thing is actually working so we have a big sample which we 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 faults of files to clients so some clients will not receiving these photo 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 - knew it wasn't captured by saronite and in this instance you really do have to rely on traditional methods like OCSP verification checking so for about 15 percent of the time Sterilite found valid and revoked certificates and although it's not graphically represented there were 289 revocation hits using sarah land where sarah 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 sarah 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 0 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 1 second time out of our CSP so for over 10 percent of the time o CSP is timing out but Sarah light is very quickly getting to a result and then there's some more information here later on and maybe this is when o CSP isn't timing out or o CSP has a much longer time out so Sarah light is faster than no CSP this is what we expected but it has been nice to be able to confirm this and with our very functional project 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 that's encrypt isn't making use of Searles 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 here in life for a vacation checking sometimes it won't be able to and then it has to fall back to OCSP so we're not fully failed 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 Mozilla summits and afterwards Tom Shrimpton who's with us came up to me and engaged me in discussing some work that he and his 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 saronite setting at the same time can he Patterson informed me that he said a student to work on looking at attack scenarios and threat models for saralidze 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 Sarah light academic team particularly Christa Wilson and Dave lemon and my hope is that we're all going to be able to work together to make the airline 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 what's going to happen when we size it with very big safes 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 rigidity 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 reduce smaller Delta files and what's the best method of compression and what's the business and of getting those data files so that they can be usable so we really do want to make sure 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 and 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 gonna 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 thought that Sterilite 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 have taken to account our existing infrastructure and in our case the existing infrastructure helps because we have this mechanism for redesigning and pushing these photo files after clients and I also think that the timing for a solution like this is good I see our life 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 look 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 however long it takes we're going to refine it and then after that we're going to decide our production plan for Sarah light and how much we'll actually be able to rely on it for revocation checking in our clients so when I asked one of the see online 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 avocation 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 kind 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 Sarah lights and I have a video so let's look at the video gods are with us we started working on CRLA there had been a long history of developing new techniques for transmitting replication data unfortunately the general consensus amongst everyone in the PKI was that there was no way to transmit replication 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 spec 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 replications 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 sierra light into firefox which as an academic has 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 1 3 spec which says all clients have to check for replications while at the same time making a client that they knew wasn't always checking for replications so i think they realized that no browsers were faithful implementing protocol but that was Ciara alight 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 see our lights guarantee stall true could we tell if a 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 PGI and that took most of 2019 so while we were implementing this we were discussing it of security summits that Mozilla runs and piqued 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 more to do here but I'm really looking forward to working with Mozilla 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 this guy is 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 cni project who has been involved who may be involved and do go and check out our CLI blog posts they should be live right now thank you very much I - 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 was not the most standard structure there is the cuckoo hashing and so on is 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 oh and I guess very quickly can you you I assume you support like addition and you know like new certificates and so on so it's all okay 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 there's 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 supercooled talk I love blue filters the green approximately how big is your set of revoked certificates you're working with ah good question this isn't a blog post I think at the moment we only have about 700,000 in there because we don't have the whole the let's encrypt 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 CAS to publish CRLs or something else I think we're hoping and that Nate's encrypt is gonna start using Searles we want to make use of serials because we find OCSP slow and unreliable to use for construction thanks and one other question what's the input to the what's stored in the bloom filters is a thumbprint right yes it's a hash a sha-256 hash value of a serial number and some other data and concatenated with again some certificate specific information it's iCarly the exact format right now but it is in our blog posts of what it is all right thanks so my question is do you see this as replacing as a sort of intermediate step before we have OCSP must staple or do you see this replacing OCSP my staple and I'd like to just say I'm a bigger fan of this correct thank you I think OCSP my staple the ideas 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 briefly to the big bar on the bar chart the 60% of request services where the issuer wasn't 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% 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 Delta updates and how it may actually more advantageous in terms of the of the demand on the network for CRO light versus OCSP must staple right I don't know what the the difference is there but it could be more advantageous with your own idea let's think Tyler again [Applause] our next speaker is Dan Shima who asked me to mispronounce his name so don shuma nadia offered to mispronounce my name so i'm here to ask the question of whether or not certificate thumb prints are unique and hopefully answer that as well this is a project done by Craig's Arusha and myself on the Microsoft Research security and cryptography team so before we get into it I've figured it'd be prudent to talk about what certificate thumb prints are you may not have come across them unless you're implementing something or analyzing certificates so certificate thumb prints are just simply a hash of the whole certificate asn.1 structure including the to be signed part as well as the signature and what's what's really important to note here is that the thumbprint hash does not necessarily it's not that it's necessarily the same as the signature hash and thumb prints still may use md5 or sha-1 so they're essentially just identifiers for certificates a more concise identifiers they're displayed and interfaces config files they can be used to refer to certificates in code and there's sometimes similar to a head the way a hash is used in a hash table so thumb prints are cryptographic hash but they're not really considered a core security feature in the same way that like the signature hash it is so if you're going to take anything from this the TLDR is that thumb prints are aliases for certificates this work answers the question of certificate uniqueness first by defining the properties we would want for this uniqueness and then using these definitions to determine that some thumb prints are not in fact unique this ain't CSI folks this is cryptography so we have to be a little more careful with their thumbprint 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't so thumbprint uniqueness yeah like given that thumb prints 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 sha-1 and furthermore because they're not really considered this core security feature function we've encountered devs pushing back on us when we've said hey you should 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 the first place where any sort of properties about the certificate uniqueness have been introduced so informally the two there are two properties that we want from certificates that certificate thumb prints that identify both directions of uniqueness that we would have so property u1 is that no two different certificates 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 you know as this is a hash of the certificate collision resistance is going to be enough to guarantee this u1 uniqueness but in practice because md5 and sha-1 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 however this is slightly more complex than a collision attack because the thumbprint is computed over the holes certificate including the signature so this property you - is that a certificate should have a unique thumbprint associated with it so if the certificate is held constant then changing the thumbprint means modifying the signature for a given syrup and as such this YouTube property is related to both strong unfortunate e of the CA signing algorithm and also encoding malleability and this property in particular has an implication for security in certificate revocation lists like the last talk that we saw so to demonstrate how we can break this you to property I have here the PEM for a certificate that has two different thumb prints this is because ECDSA is cryptographically malleable you just resize generating a new blinding value that will generate a new signature and then you'll have two different thumb prints RSA is not cryptographically malleable because of padding but the ASN 1dr encoding can be mangled in a way to modify to create different thumb prints so specifically the way this works is you have a certainty BS 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 x.509 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 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 thumb prints that's breaking that u1 property so certificate thumb prints still often use sha-1 and as i mentioned before it's not exactly clear whether a collision attack alone can be used to create colliding thumb prints 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 sha-1 chosen prefix collisions were not feasible as that was just demonstrated earlier today for the first are presented earlier today for the first time so we actually additionally required a key substitution attack to create colliding thumb prints and 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 x.509 certificate in use today is signed with an algorithm that allows a key substitution attack on it and so what we demonstrate is how 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 gonna have to control the signature as well so to sort of give the high level layout of how this attack would work the attacker one 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 SK I 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 SK I 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 sir that will verify in the in the PK so after we demonstrated this we scanned for colliding thumb prints in the wild we did we did this by getting datasets from projects owner published at scans i/o this represented one hundred and twenty five point eight million unique certificates and what we did there was we computed thumb prints and looked for certificates that may have the same md5 sha-1 and sha-256 thumb prints we didn't find any we're an md5 and sha-1 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 thumb prints or any of these attacks so while checking for key substitution attacks we actually found something interesting Gregg 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 Cisco hardware had insufficient entropy and the drbg and ended up generating the same ECDSA blinding value so in conclusion we introduced two properties to describe the uniqueness of certificates uniqueness of certificate thumb prints and in terms of these two properties we showed that with weak hash functions certificate thumb prints 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-1 thumb prints in internet scans and we did not find any there either so based on this work we have a few recommendations specifically that application should migrate their thumb prints to the stronger hash functions sha-256 512 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 thumb prints use collision detection and we would encourage projects monitoring PK eyes such as certificate transparency to check md5 and sha-1 thumb prints with collision detection as well so also to any devs who are working with certificates and certificate thumb prints you know look for ways in your software that non-unique thumb prints could be used to exploit security because we obviously don't have visibility into all the places that prints are used so thank you very much for your attention and you can check out the full version of the paper on any print in any hash collection situation though collisions may be on probable probabilistic ly they can't occur I mean the formula for that is well known and well documented that you have maximum population size deployed population size what's the probability of a collision and maybe 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 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 so if you get two certificates with the same thumbprint in terms of any collection yet so you would have to have it's the square root of the total size of the right probably that if you want to give you the formula offline there's a form for that that that that that is therefore population of M of n mm deployed what's it probably the collision and it's since not the squirt it's it's different for me so it's it's different than the birthday now it's much more realistic you know what what is chance of a 1% collision what's a chance of 100% collision okay for that well not not the were supposed to have evolved a guarantee 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 we're more concerned about easy to compute collisions on these thumb prints so it's probably my fault for not being up to date with this area of the literature but you mentioned a couple of times checking for corrosion detection how do you do that what does it mean oh that's that was introduced by Mark Stevens when analyzing the flame attack in counter crypt analysis and basically what you can do is well computing an md5 or sha-1 hash you can check for differences in the message input blocks that would cause a collision so you can in fact filter out inputs to hash functions that are causing a collision well 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 there is an extensive list if he is in the in the full version there were versions that looked like firewalls replacing certs 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 I wondered also to ask about the up here I want also to ask about the the colliding signatures I was wondering like was this only old hardware like in the case of mining teasing queues or this is also a newer hardware the Cisco one I mean the the Cisco CVE that Gregg found yeah because my episode there was a similar situation for mining your P's and Q's were like scanning RSA public key is I'm sure one prime and my understanding was big that caused by low entropy during boot yeah yeah yeah yeah the poor random number generation I wasn't that was also there 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 did you look at ECDSA in the mining P's and Q's just because recently I read something like oh never have door doesn't have the problem of low entropy during boot so they're the actually we had a follow-up paper two P's and Q's and it was in 2016 Marcella who gave it one of the talks earlier was one of the co-authors and new vendors keep introducing the same flaws over and over again so it's never going away all right we are over time so let's thank Dan again [Applause] do we have slides okay so our next talk will be jointly presented by a Christian and Tiago okay hello everybody let me start with thanking the team at abran Emerald Bank for some of the inputs when we compiled this story and particularly I would like to thank Barbara and young Barbara is here today so feel free to seek her out and also ask for some questions before we dive into the case of ABN AMRO 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 encryption and this there's a yearly survey which basically stated for the last one that forty five 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 forty five percent of large enterprises encryption and key management what we want to talked about is a crypto strategy that goes beyond encryption and key management it contains it and to show how we started from defining this strategy to the implementation and Thiago 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 Amaral 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 server 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 ping pong 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 need it to insert the 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 HSMs for our payment systems so our core systems where our banking is they we deal with HSN and our crypto services team is centrally managing those so we know HSN as well and also in 2016 Google and Microsoft were basically saying issuing a patch that was saying enough is enough no more sha-1 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 gonna 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 have back in 2016 and nowadays we have a more comprehensive set of kryptos services central crypto services as well as capabilities implemented within the bank now I don't want to bother 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 implement the descriptive strategy and to do that we're gonna share four stories the first story is about Shaolin migration so that patch was coming along if you have a certificate which I want it's no longer gonna work so what 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 website there are most important ones all were using sha-2 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 certificate because the internal facing certificates we couldn't really rely on the inventory that we have and I was because to get an internal facing certificate you'd have to wait a week to get your certificate so generally speaking developers who try to bypass this process as much as humanly possible and it's created a huge amount of certificate 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 sha-1 on them we'd have to do multiple passes of the scanner because some acts 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 will appear multiple times in one scan so how the hell did that happen and we eventually have to set up a whole team of six or seven people that have 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 of our internal stakeholders this is the magnitude those systems that were 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 became 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 and migrate away from something whether death certificates or anything else then having the inventory makes a huge difference our second story is about HSN's so you remember that we had the HSN for our payment systems we know those well and in 2016 we decided to augment that because we really have the HSN for payment systems those are fine and up and running if they work fantastically so we can't get Network attached to HSN so the beauty about network attached systems is that they lie and they allow for an abstraction layer for the developer which they're generally speaking there's a new 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 you know in a protected environment as opposed to let them call 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 come to you and to use your central services and nowadays what we have is a far more comprehensive set of it's just it's just some 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 us now for the third story I'll hand over to Christian 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 were to say can we do this ourselves we need to have the knowledge in-house we want to do consulting we want to do in knowledge sharing and we need to build this up and that's kind of what we set out to do we define the skills we found the people and we you know went from a purely operational team to a team that can do consulting and advise 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 sha-1 was such a pain the step rotation 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 with the business explains the issues to the business prepares them mentally right thing but they also talked to academic researchers industry researchers to find out feel the pulse and just find out what is coming and not just wait for NIST to finish the 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 actually means for the enterprise it means you 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 layer 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 in the whole landscape and that's basically what the team is nowaday doing doing and they're starting with certificates inventories but they're also going further invent rising libraries and so forth 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 panning said do you want to do innovation I said ok I want to do innovation ok how do we set this up and what we we help them 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 in a SISO organization to do innovation themselves but it makes sense that they were together with the innovation department and try to look at what is actually needed and how can you bring cryptography to the user of the bank and what they also doing 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 do 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 the strategy in this perception that finally you have to do something in crypto can do something for you is that the researchers in ABN AMRO they worked with with 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 up with clever algorithms and they came in even with a way to share insights with other banks running the same fraud detection algorithms and they can do this with a 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 want to close off with what's next right there's still a couple of things going on so we mentioned post quantum cryptography crypto identities on everyone's mind but of course there's also big push to go to to public cloud to do DevOps and it's why we try to say not only dev sack ups 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 it [Applause] you mention a sort of preparing for the post quantum crypto and I'm wondering what are specific steps you know are you guys taking and what will you recommend to other enterprises to do in regards to that issue so the first thing you have to do is is to have an inventory of of your to-do lists basically and when it comes to post quantum there are two aspects of it the symmetric cryptography which we you know we're still waiting for NIST to to standardize for everybody here at NIST we're rooting for you please and as for symmetric cryptography is something that we can start doing already today by doubling the key lengths or four stuff so the thing that I could recommend for for very large enterprises is the the hardest part is likely gonna be knowing that you 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 NIST says gives us the thumbs-up then we as an industry can start migrating away okay we're short on time so let's think khristianne thank you 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 yes I'm Gavin Watson I come from visa research and what I'm going to talk today is about threshold crypto scheme which was designed within visa research and we're in our ongoing effort to then take that to put it to the the wider visa and so that they can use it with an enterprise setting so I'll talk about is how we can take this kind of theoretic instruction and what we need to add to it to made 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 the one thing with encryption is what we're doing is we're taking data that will be having plain text and we're encrypting it so 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 last talk and in the financial industry it's important that sometimes we use HSMs and key management kind of equates to or 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 clients HSM because that's a lot of data when you send across a 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 the 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 am 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 then what I store a longer term is the encrypted data along with this encrypted key so the benefits of this approach is is fast because the actual encryption of the large amount of data is happening and software the application and we get the benefit that we have Harper to Hardware protection and off the keys thanks to the HSM with 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 there might not seem too bad because we're just encrypting a file and we immediately encrypt the key back under the CAC but in practice that's not the case it'll often be the case that I 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 can a 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 requirement three five three there and highlighting here is what it tells us to do about key management and 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 cake I just mentioned second point is maybe about using 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 as we want a pure software solution and but still with strong security we're not just going to be holding keys it to be exposed in an application we're using a threshold scheme so these keys are going to be distributed so dice is the solution we have for this weird I stands for distributed symmetric encryption okay so dice was originally published by some of my colleagues CCS and 2018 and so Peter and Payman are here today and it was also presented at the NIST workshop on threshold cryptography last year and so if you were either of those two previous talks you will go kind of the technical details about dice I don't have time to go into the field technical details 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 threshold encryption scheme so 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 user wants to encrypt some data what's going to happen so I want to encrypt some data D I'm gonna 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 we're performing a distribute PRF and you can even in fact do this as a distributed key derivation M and so dice itself has two different modes one which is based on using AES alone which is based on a lip ticker for coffee as I mentioned earlier if you want the few details at average of paper or come and talk to one of us after the talk and so yeah so once these nodes I've done this calculation we send these parts back to the the encrypter of 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 where we are encrypting we then use this to encrypt the data itself so the cipher texts are now going to be posed of this encrypted data along with that commitment we recalculate earlier because we're gonna need that commitment later when we want to do decryption because decryption will just be the same thing we do this distributed PRF to really recalculate the key so then do the decryption later so benefits this approach is that the master key always remains distributed it never needs to be recombined at any time as a threshold encryption scheme is secured against a t minus 1 so it's up to 1 less than the threshold number of parties as long as they are no more than that are compromised we're still going to be secure and as a very small network cost because again we're not sending the full data across these nodes we're just ending this very small - graphic commitment and on the other side of that because we're just ending the cryptographic command we get data privacy none of these nodes will ever learn what I'm encrypting because I only ever have that field 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 dice we get really good figures in terms of the performance and 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 set ups we did and here we get really good figures you can see through thought 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 and so because it's a pure software solution is cheaper and more scalable than HSMs if we compare it to secret sharing which we heard a little bit about earlier today and the benefit of dices we don't need to recombine that master key to do our encrypt operation the master key will always remain distributive 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 and 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 it 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 so we can have some nice funky crypto which allows us to generate the master key and a distributed fashions no one ever learns the fuel key and 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 take 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 and together so you're going to need extra functions that allow you to do that you may in some sense in severe if you 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 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 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 I'm going back to that PCI standard sometimes we really need to tick that box that saying we have a Hardware of trust and my seem contradictory to what I've said already but maybe in some instance we need to talk tickler 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 kind of depiction of dice we have this user calling in to the network to perform an encrypt or decrypt but really we have to check this is a person that's permitted to move in 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 you're authenticated based on the mutual TLS channel that they establish but then once you're authenticated for the committee to do so one thing we can do in terms of authorizing what we can do is that in that commitment we calculate M 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 then that time of decryption the dice nodes can check that that user calling to do a decryption is the permitted user one of the other things we can do is sometimes in our enterprise setting we have many different applications and we need to separate them within different keys owns so different applications are permitted to use different keys they have different master keys for dice let's say so are the time of the making a call we need to check whether it authorized to use the master key that they're calling to the particular set of dice nodes calling for next point API and connection management so when designing any cryptographic API you 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 wanted to say is do you encrypt or or do decrypt we don't want it the developer to have to understand that you're making calls to these T different dice nodes to then we gather these together to calculate some ephemeral key which we're going to use I should all be hidden behind and in the library this is gonna 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 is talking to and where it's reaching out to and so what we do with dice is we add this additional 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 that's basically just going to help you you can reach out to it and it tells you where the dice nodes are you need to reach out to which dice nodes are currently live and my help in the future with some some load balancing and so then with the information back the library 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 security we need some redundancy in the broker and 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 AI system I need to break more than a threshold number of these nodes so if I kind of make these dice these it's very different then he's going to need to perform different attacks on different notes to be able to break the whole system so I could have some notes which a Windows server some with your Linux servers and so it's going to be much harder for him to to break into it the kind of the practical issue with this is it makes it much harder for system administrators and I have a much more diverse landscape they need to manage so it might be a pain point for them to do that in practice ok 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 this up and running so we can get a look at and used really in an enterprise setting and 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 guy and you guys and you can also have a play at using our our threshold encryption scheme and so thanks and any questions [Applause] 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 yes there's obviously that would be very useful thing to have and it's not something we naturally have at the moment and as I mentioned we have kind of two types of dice there's the AES based one and there's elliptic curve based one so the elliptic curve based one maybe there is some scope for doing something there on the ASP based one it might be more complicated 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 that's a good question we've not done any kind of concrete analysis of that but I think they see some some validity and in this approach it may be not going to do it for every single project and 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 you also mention using like different platforms like Windows Linux and such I suspect you probably using some sort of shared library for the cryptographic implementation so if you're shipping projects like that how do you ensure that that library itself is not compromised and then shipped alone where it could start you know sending off keys to other places and I don't I don't necessary have a good answer to that you could have different implementations afterlife different implementations off dice so your different versions of the library which then gives you the additional level of complexity again practically that's kind of an issue because then you're managing much more different versions of the library let's all thank Evan again and let's thank all those speakers of this wonderful session and that concludes our program for today [Applause]