 I'm Ethan Wessel. I am a software engineer at AirSwap. You don't know what AirSwap is. It's a desk block against that. But this presentation is going to be about securely storing private keys for application use on AWS. So I want to note that we are not storing user private keys. This is for our back applications. This can be for side projects or integrations. I might have heard one of them mention yesterday by Drew Richardson, which was our TAP project. So first off, application wall security. Data can be in three states. It can be at rest. It can be in use or it can be in motion. And the moment that the key is with memory, it's vulnerable. So we have to have tools and practices around our infrastructure that allow us to ensure the wallet security so that we're doing trading like that. So again, once compromised, a private key and everything tied to it is gone forever. So that means tokens, our wallet, our functionality, any of the things that we're doing is aggrasable. So there are four main criteria we have. We have auditability, which is, can we see what happened? Can we see who accessed? At what time we have encryption? Are these keys unusable when they're not being used? And I want to note, the keys I'm talking about here are the keys to encrypted data. They're not the public private keys. So this is taking encryption keys and then using those to encrypt and securely store your private keys. We also have it needed to be easy. So if you're a developer, you don't want to be tumbling around with trying to like, can we go buy the keys and secure it? So developers and DevOps engineers need to be able to use a tool with these. And it needs to be permissioned. You can be able to lock it down. If you can't do that, then that's not good. There's too much access to it. Not really, yeah. So we have four main tools that are disposable for AWS. And the first one is key management service. The second is Securities Manager. We have Assistance Manager, parameter store. We have Kubernetes secrets. So I'll 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 for the key management service, its main job is to create and control the encryption keys used to encrypt data, like I said earlier. In terms of its auditability, it integrates other tools and provides logs. So you can easily see these logs and see what's happening. The encryption, sorry, in 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 ready to go by default to allow you to encrypt the data. And it's permission, so you can use IAM policies, key policies, and throw access control on top of it. The Secrets Manager, its job is to manage secrets for applications and services. Again, it's audible, it has logs in terms of its encryption. Secrets and keys are encrypted at rest. But it really shines with how easy it is to use. So instead of putting hard coding credentials inside of your applications and making it visible, it uses an API call or an SDK, which makes it much easier for development just to like to throw it in. And on top of that, Secrets Manager also provides additional functionality that allows you to auto rotate your keys. And again, it's also permissioned. So you can grant permissions to individuals on perform list roles, which is also very nice. There's another one here, which is the Systems Manager parameter store. This is pretty akin to Ansible. I don't know if anybody's ever used it, but there's something called Vault Ansible. And the Systems Manager really shines with regards to the secrets that are interpolated at runtime. In terms, again, of its auditability, encryption, and permission, these are all pretty standard of AWS services. But again, it's very easy, and most of these are just injected to container services through environment variables, and they're never visible. The last one is Kubernetes Secrets. And its job stores, manages, sends the information to Kubernetes. So you can put password, you can put sH keys, you can do pretty much anything, plain text, which eventually becomes encrypted. So in terms of its auditability, it's great, it also logs, but there are big problems with this, where you can actually expose secrets. And when you expose a secret inside of your logs, it's forever left for logs that become vulnerable, then you're kind of screwed, it's visible. Again, things aren't encrypted at rest, but via the EBS volume. And it's also easy, so you can attach the pods, and you can inject your secrets to the pods. However, in terms of the permission, even though access is on a per pod basis, you have to be careful because a pod can see those secrets, and that's not good. So again, you'll have vulnerability stuff. Overview, KMS, as we have found, is good for general encryption management. Service Manager is, again, to manage secrets and applications for services. And the parameter store is good for configuring data for the Plymouths. And you have Kubernetes Secrets, which is really good for securing sensitive data in clusters. This documentation, I'm sure, will be available afterwards. Thank you.