Securely Storing Wallet Private Keys for Application Use by Ethan Wessel (Devcon5)

Transcript

[Applause] my amazing muscles I am a sovereign air air club you know I have swap this is the test lock against that but as presentations would be about securely storing credit keys for an application news on AWS and so on no I'm not that we are not no more able user private keys this is for our family nominations this can be for side profits or integrations I've heard one of them mention actually library which the synth which was our top round so first off application wall security they didn't be in three states it can be addressed it can be in use or

can be the motion and at the moment that's the key is in memory it's honorable so we have to have the infrastructure that allow us to ensure the wallet Security's doing training so again once compromised a private key and everything tied to it is gone forever so that means tokens are you know our wallet our functionality anything is that we're doing is an address so there are four main criteria you have we have audits ability which is can you see what happened can you see who access at what time we have encryption are this Keys unusable when they're not being used and I want to know the keys I'm talking about here are the keys to encrypt the data they're not the public private keys

so this is taking encryption keys and then using those to encrypt and like securely state storage or our packages we also have easy easy so if you're a developer you don't want to be fumbling around with trying to like so developers DevOps engineers need to be able to use a tool with music any speed permission can be able to lock it down you can't do that then that's not good it's just too much access to it so we have four main tools at our disposal for AWS and the first one is key management service the second is assess your secrets manager we have assistance manager parameter store we have cocoon any statements don't talk about each of these but again this is a bit more of an infrastructure talk of how we kind of

like organize these so if the key management service its main job is to create control in clicking keys used to encrypt data against another in terms of its auditability it integrates with other tools and divides log so you can easily see these logs this is happening the encryption with sorry regards to encryption the keys are encrypted at rest they're not accessible or not visible and it's very easy so as soon as you make an account there's a key to go by default to allow you in Krita and it's permission so you can use aia policy as key policies we can throw access controls on top of it the secrets manager its job is to manage sequence for applications and services again it's audible it has logs encryption keys and

keys or encrypted at rest and but it really shines with how easy it is to use so instead of putting hard-coded credentials inside of their applications and making visible it's used as an API call our SDK which makes it much easier for a dollar just to like to throw it in and on top of that students manager also provides some additional functionality that allows you to auto-rotate oh geez and again that's also permission so these definitions individuals on perform list roles which is all spirits there is another one here which is the assistant manager of parameter store this is pretty akin to ansible I don't know if you've ever anybody's ever used it but there's something called vaults danceable and the assistance manager really shines with regards to the secrets that are interpolated at one

time in terms again the path auditability fiction and permission these are all pretty standard of Veda best services but again it's very easy and most people are just rejecting the container services to your vigor variables and they're never disappoint the last one is too many secrets and its job storage and too sensitive information for enemies so you can put passwords SSH keys pretty much anything plaintext which essentially becomes encrypted so in terms of its own ability it's great it also logs but there are being problems with this where you can actually expose secrets and when you expose secret inside of the law because for every lots that were becoming vulnerable that and every kind of it's visible again things aren't cryptid at rest via the EBS

volume and it's also easy so you can attach the pod you can Jack's your your secrets to the pods however in terms of the permission even though accessing a pearl on basis you have to the character because a pod can see those secrets and that's not good so again you'll have a polar realities though overview kms as we have found is good for general encryption management service manager is against - newest applications for services and the parameter stores it for configuring data for deployment and you have community secrets which is really good for us sharing sensitive data in clusters without mutation or email afterwards [Applause]