No Silver Bullet: A Brief Survey of Key Management Technology

Transcript

and applied cryptography and this sort of thing so today I want to kind of just talk about the low level Key Management stuff that we do kind of underneath everything just to give a little bit of idea of like when we're trying to make decisions how do we make those decisions what should we think about so um to start let's kind of think about the depressing state of things right now look in in web 3 basically everything that you do is mediated by a key right you want to generate a transaction you want to anything you want to do somehow you generate a signature for it so you have a key okay unfortunately Key Management is hard or at least it can be and this means web3 is hard okay this seems a little silly but I think this is the experience that that many people uh

hit and so this is kind of where we start from okay so how do we make it easier well maybe one way to start thinking about like teasing these things apart is thinking about what it would look like to have really great Key Management what would we want well we want it to be easy to implement we want it to work with any chain we want access control and Automation and we want backups and we want Audits and we want security and we want probably other things too but let's come back to security so what is what does it mean for it to be secure well to answer that question we have to say what is the attacker able to do we need an attacker model so an attacker model says this is what the attacker can do this is what the attacker wants to do so for example

in TLS we say the attacker controls the order of packets sent over the network and still we should be secure and many cryptographic protocols if we're using a cryptographic primitive we say the attacker can't break that primitive otherwise we probably wouldn't use it um in um in Economic Security protocols we have this idea that the attacker just wants to maximize his profit the attacker is rational or something like this okay so these are the sorts of things that we say about an attacker and these let us think about the security of concrete protocols so let's start with really terrible one that I hope nobody does and that is just give everyone a copy of all the keys um and then everyone just gets to make transactions with those keys and this this really happens a surprising amount and the reason I guess or one of the reasons is

it's super easy to do right and like it works anywhere and it's compatible with automation in and it probably gives you Disaster Recovery because like not everyone's laptop is going to crash at the same time um but of course it gives you other terrible things like you can't have access control right once I give you a key I cannot be convinced that you've deleted it and of course I can't audit anything because if everyone has a copy of a key then anything that happens could have been done by anyone but okay so how about security as such well is this secure not quite the right question instead we want to say under what attacker model would it be secure like what do we have to believe in order to think that this could be secure well we have to assume at least that everyone who gets a copy

of the key will remain honest forever right because they're going to have the key and so if they become corrupted they steal the money okay we also have to think that an attacker won't be able to just take control of their machines and steal the key right if we if they can then we're kind of sunk okay um so this is well intuitively like we don't actually believe these things and this is why we say okay this is crazy this is not secure if anyone here is doing that don't don't leave now or that'll like reveal to us that you're doing it but like sneak out later and fix it okay good so what do we do instead okay so one thing maybe the next logical step would be we said well if the attacker could steal the key life would be bad so maybe let's make it such

that each of us has a piece of the key uh and and then the attacker has to steal many pieces in order to put the key back together and this is called secret sharing so concretely in this very simple model we're going to say we're going to first like put all the key all the pieces of the key back together and then we're going to use the standard signing procedure to generate a signature and then we're going to make sure to delete that reassembled key so that the attacker can't steal it okay um and so an example of secret sharing just like in terms of how do we implement this is like the simplest example is additive secret sharing we just break the key into two pieces and you sum the two pieces and there's your key this has a big downside that if I

lose one of the pieces I've lost the whole key um so it kind of increases the likelihood that I lose my key compared to just keeping a single key because now there's two things to lose right so an alternative that is kind of nice is we break the key into many pieces and then some you know subset of sufficient size is sufficient to sign and this is called threshold Secrets hearing so the classic approach here is shamir's secret sharing and in one picture this is from your secret sharing I'm not going to go into it but basically polynomial random uh the evaluation at zero is the secret I can just give out other evaluations if the pro if the polynomial has degree K minus one then K shares is enough to reconstruct the polynomial and get the secret so there it is Shimmer secret sharing and this is really nice because

now we actually get this threshold property that we want okay so again when is this secure what do we have to believe about the attacker well we have to believe that the attacker can't steal enough shares to reconstruct the key and we also have to believe that the attacker can't just steal the reconstructed key at the moment that we're signing it because remember we said we're doing this naive thing where we're just putting the key back together okay and so the first of these assumptions we can actually you know relax a little bit just by using a fancier protocol that lets us re-randomize the shares every once in a while but the second one is kind of fundamental because we're reconstructing the key so there's this tiny sliver of time where all the attacker has to do is steal one key so how do we get around

that well we use something a little more complicated we can use something called a threshold signature scheme so the idea here is we're going to break the key into shares just as before but now we're going to use multi-party computation to actually generate the signature without ever reconstructing the key okay so what is multi-party computation okay as many of you know this is a cryptographic protocol or one of a family of cryptographic protocols we have a set of players each player has a secret in their head and everyone agrees ahead of time on some computation queue which in this case is going to be the signing procedure so the players sort of all run the protocol and at the end everyone comes out with the same answer which is Q applied to all the secrets so in this case the signature but importantly the key itself was never materialized during

this protocol the crypto cryptography lets us evaluate the function without sharing the secrets among or without you know revealing any of the secrets okay good so again when is this secure well um we have to believe that the attacker can't steal the shares just like before but now the key is never explicitly reconstructed so we don't have to worry about that little sliver of time but we do unfortunately have to worry about something else that I've been sweeping out of the rug the whole time and that is roughly speaking complexity so these are potentially very complex protocols especially in the case of something like ecdsa which was never designed to be a good signature scheme it's just a shame um and and so like we actually have to worry about kind of two variants of this issue one is that the protocol itself could be theoretically insecure like

it's just not correct cryptography we could also worry that the protocol is not correctly implemented in spite of being cryptography and both of these things have actually happened in the wild but since we're at a conference that includes verification a natural question is can we verify these properties and the answer is sort of but not quite right now so like verifying the theoretical security of a complex cryptographic protocol is still in the realm of research question um and verifying the implementation of some complex distributed system that involves cryptography and all sorts of things is again something where depending on what you're trying to verify it's actually quite hard to like actually write a mechanical proof for these things it's becoming more possible

over time and so this is the sort of thing that we should be pushing towards but today yeah the implementations don't really give you the kind of strong guarantees that you might want nevertheless this is a really nice direction that we we hope to go okay so we started getting into this like kind of mire of complexity by saying well look the attacker could steal keys and what are they okay so what if we can just say look we're going to prevent the attacker from stealing the keys that seems a little bit simple but this is the idea behind a Hardware security module or secure Hardware generally it's it's a piece of Hardware that stores the key and now the key is a physical object so if the attacker wants the key they have to steal from a object for me which seems like kind of a nice model and

these things are all over the place your credit cards have them your cell phones both in the SIM card and in the phone um ledgers and hsms and trusted platform modules all of these things are one variant of secure Hardware or another and they all basically give some interface that's like you can ask for a signature but you can't ask for the key itself so once the key goes in it doesn't come out again okay so what do we have to believe for this to be secure well we kind of have to believe that the attacker can't access or steal a physical object and here there's a small sidebar there are a lot of attacks against secure Hardware elements almost all of those involve stealing the thing bringing it to a lab with an electron microscope and doing some ugly stuff to it so here I'm like

explicitly assuming the thing's not going to get stolen and the way that you can back up that assumption is like well for example you can use Amazon who has hsms in their data centers and they have men with guns outside the data centers and nobody's going to steal the hsms because it's really tough to get in there um the other thing you have to believe is that the HSN M software does not just allow the key to escape and again we can ask is this something we can verify and the answer it turns out is yes for the most part so this is something like an information flow control type property what that means is we we make a formal statement like the secret in the software will never Flow to the network or something like this and this is actually the kind of thing that the

academic Community has spent a lot of time in the last decade and change maybe two decades working on and we're actually pretty good at it at this point not me but other folks um one other thing that I should definitely mention is something with an HSM if I have a physical device now I worry that a meteor hits the physical device and the physical device is gone and there are different answers to this question depending on what the HSM might be but one is if you go to a cloud provider somebody like Amazon KMS has multi-region HSM so they do geographical replication of the keys and if something happens on the Eastern Seaboard and U.S east one isn't available I can go to Ireland and US West one and I can get the same key from that at least if I thought I had to set it up that way okay

so to recap this was sort of a whirlwind but is it secure not quite the right question instead is my attacker able to do something right and so what this means is the first step is to understand what the attacker can and can't do and finally I this has been implicit up to this point but explicitly complexity counts as an attacker choose the simplest solution that you can because every extra line of code is an extra opportunity for bugs every extra Bill and whistle that you don't need is something that could turn around and bite you so with that thank you very much