Decrypt with Evervault: Kyle Mistele from Zelus

Listen on:

• Spotify
• Apple Podcasts
• Amazon
• iHeartRadio
  

This episode of Decrypt features Kyle Mistele, Blockchain and Product Lead at Zelus — the easiest and most innovative web3 wallet to view, store and send your digital assets across multiple blockchains. Kyle has been able to merge his deep knowledge in cybersecurity with his excitement for emerging web3 technologies. At Zelus, he designed and implemented the backend component of their wallet application and performed security assurance for Zelus smart contracts and related blockchain infrastructure. A true startup multiple-hat-wearer, he also manages their bug bounty program, oversees security audits and handles infrastructure and DevOps projects. Kyle loves learning new things and sharing them with others, which shines through in our conversation.

A few highlights from their conversation include:

• 02:35: How watching an exploit called Eternal Blue used in the WannaCry ransomware attack sparked his interest in cybersecurity
• 08:36: Security concerns that are specific to blockchain applications
• 09:43: The importance of keeping users’ keys secured and ways to solve for it
• 11:23: How secure enclaves and encrypted storage completely ensure wallet security
• 23:43: That the current moment of AI and LLMs are akin to the invention of fire when it comes to technology

Listen to the full episode on YouTube or wherever you get podcasts. You can find Kyle on Twitter @0xblacklight and on LinkedIn.

Liz (00:35):

So tell me a little bit about your career in tech.

Kyle (00:39):

Sure. So I started writing JavaScript when I was, I think 12 years old. Growing up I was always really into computers, which I'm sure is pretty standard for most people in this space, but I really enjoyed being able to get under the hood and see the internals of how they worked. So I self-taught myself through high school. I went to a really, really small Catholic school, and so we didn't have any computer classes or AP computer science or anything, so I self-taught through that. While I was in high school, I had the opportunity to do a little bit of contract work, which led to doing an internship or two. And then I got to college, I studied computer science and cybersecurity and did a multitude of internships and some freelancing while I was in college and here I am.

Liz (01:35):

Great. And what is it that you do now? What's kind of the space that your current work is focused on?

Kyle (01:42):

So I wear a lot of hats, but my primary role is I'm the Product Lead for Zelus Wallet. So we are a multichain cryptocurrency wallet. We also have a couple of different SaaS products that help brands and agencies activate in the web3 space. So I lead the product team for the Zelus wallet and for those products. I also do a lot of the security work for Zelus. For example, I manage our bug bounty program. I oversaw our security audits and we actually don't have a full-time infrastructure guy. We build everything on AWS and I pick AWS up very quickly. So I also do a lot of our infrastructure and DevOps type stuff. So a lot of hats.

Liz (02:30):

Nice. What sparked your interest in cybersecurity?

Kyle (02:35):

So I knew from pretty early on when I started coding that I didn't want to just sit at a desk and write code all day. I just knew that that really didn't appeal to me. And when I got to college, I saw a poster for SMU Cybersecurity Club, and I went to a meeting and I watched a guy named David Brockler, who I'm now very good friends with, break into a Windows server. And I remember thinking, wow, I want to do that. That's really cool. I actually remember all the specifics of it. It's an exploit called Eternal Blue that was used in the WannaCry ransomware attack, which lots of people have heard of, but I just remember being wowed by that. I didn't even know that that was a career field or that something you could do. And so that interested me a lot.

(03:25):

So I decided to specialize in cybersecurity for my comms side degree. I did a lot of cybersecurity competitions, both offensive and defensive, either on the red team side, breaking into simulated environments or on the blue team side, defending them. And I really enjoyed that. I also did a little bit of R and D. I did a little bit of malware development for a red team for a local consulting company. And I really enjoyed all of that. I found it really challenging and thought-provoking, and I really enjoyed the technical communication aspect of it too.

Liz (04:03):

That sounds super, super interesting. Watching any of those where people get up on stage and do an exploit and break into stuff, it's magic, honestly. It's really, really fun to watch. How did you get then from the cybersecurity world into the web3 space?

Kyle (04:25):

That's a great question because I know that's not necessarily a natural transition. So by the time I was finishing up in college, I had a couple different job offers from various cybersecurity firms, and I had actually accepted one, but my friend who was working for Zelus, where I am now, asked me if I would do some development work for him. And actually originally he told me what he was doing and that he was going to be in the crypto space, and I told him, "That's dumb. You shouldn't do that. Crypto is dumb." And so long story short, he eventually asked me to do some development work for them while I was still in school.

(05:09):

And I told them yes, and I think that's where I had my aha moment. I really fell in love with the product that we were building. I really love our team, and I just became fascinated by the problems in the space. I think where there is some overlap between blockchain and web3 and cybersecurity is encryption. Obviously blockchains are cryptographic primitives, and so I was really interested by that and how this was a really interesting use case of asymmetric cryptography and all of the different possibilities that enabled.

Liz (05:50):

That makes a lot of sense. I guess when you look at it from that angle, there is more of a natural overlap there than someone might think of on face value. So tell me a little bit more about the problems that you've run into. You mentioned there were some really interesting problems and I'd love to hear more about what some of those are, if you can talk about them.

Kyle (06:10):

Yes, for sure. So one of them that I can talk about, I guess what most people know about a blockchain who are in the tech space but aren't maybe super familiar with it, is that it's a distributed public ledger. And so from this, it might be easy to get the idea that it's like an Excel spreadsheet that all of your assets are on. And this is not even remotely close to being the case. It would be a lot easier if it were, but the blockchain that we work with the most, which is Ethereum and various EVM networks, they use an account model. So for Ethereum balances like, "Oh, I have five Ethereum," you have that two column Excel spreadsheet situation. But for everything else it's much more difficult because Ethereum is programmable. And so all of the assets and coins that are on Ethereum aren't actually part of the blockchain itself.

(07:14):

They're part of smart contracts which are like, they're not contracts, they're like applications or pieces of code that live on the blockchain. And so Ethereum is like a ledger or database of these different applications, which once are on the blockchain are more or less immutable and the assets are defined by these. And so actually if you want to find out all of the assets i.e, the Ethereum, the coins, the NFTs that are in someone's Ethereum wallet, you have to go index every single one of those smart contracts of which there are thousands and thousands and thousands, and go ask each of them and interrogate them for what assets they define and what a user's balance of those assets is. And so it's a much more complicated problem when you're building a wallet to show someone what's in their wallet. Than you would maybe get the idea of, from just, "Oh, it's a public ledger." We can't just go look and see, here's the line item for this person. It's a lot more complicated.

Liz (08:16):

So I guess how do you figure out the security risks in this space because it is so new? And to my knowledge it's still pretty new, it hasn't been around that long. How do you determine what to look for and what sort of threat vectors there are in a space like this?

Kyle (08:36):

Yes. So a lot of traditional security concerns still apply, but a lot of them are the cases that it's more of a different emphasis. So for example, people talk about these things called decentralized applications, which usually they're React apps or single page applications that don't have a backend. They use the blockchain as their backend because the blockchain enables storage and it enables execution and so forth. And the front end lives on something like IPFS, Interplanetary File System or Arweave, which are distributed storage networks. And so the application is basically just a React app that lives on a distributed file system and then the blockchain's backend. And so instead of usually having to think about your backend application security and some of your more traditional infrastructure concerns, you have to think a lot more about things like cross-site scripting, when people are connecting their wallets to this application.

(09:43):

And if you mess that up, it can potentially ask them to sign transactions that they don't want to sign and steal their money, which would be much harder to do in the traditional finance space. Smart contract security has been a very big field and is very much still very new and we're still learning a lot about it. It turns out securing applications that once deployed are immutable is a lot harder than securing a node JS app that you can just patch when someone discovers a flaw in it. So those are kind of different emphasis. And then obviously on the wallet side, keeping users' keys secure is really important, and this is actually something we're using Evervault for, is how do you store users' private keys and their cryptocurrency wallets in ways that are secure? And so our core wallet just keeps it on the user's device and so it never leaves their device.

(10:44):

Because if it did, if it ever touched our servers, then we would have access to the assets in that wallet because your private key functions has access to your funds. And so we don't ever want to touch users' private keys, unencrypted. And so for our noncustodial wallet, we don't ever upload that. And we've seen in the space what happens when, for example, a wallet company misconfigures their century configuration or something and there's a trace that suddenly has a user's private key in it, and all the user funds get stolen because it had 10 million in Ethereum and one of the devs at that company decided that they couldn't miss out on that.

(11:23):

So as a wallet, we have to be really careful to isolate how we store and manage users' keys, but we're also building a product that's more like an embeddable wallet that is easier for companies that are not in the web3 space to integrate and to use, to allow them to give things to their users that are like NFTs, digital collectibles and so forth without the user having to generate a private key on their device and then share the public address and so forth. And that's really, really what we're using Evervault for, is the ability to generate and store those keys using secure enclaves and encrypted storage so that we can't ever touch those wallets and we can prove that cryptographically using attestations from secure enclaves. But Evervault can't touch it either because you guys don't have the data, you only have the keys. And so it's a really interesting use case that's helping us solve this problem of how do we make wallets more usable in the web3 space.

Liz (12:25):

I didn't really know until I started getting into this work just how many places data can leak out and how catastrophic that can be. The story that you shared of someone's thousands, hundreds of thousands or tens of thousands of coins getting stolen. I've heard I've so many stories like that recently too, of just keys getting leaked places and somebody's open AI bill getting totally ramped up, so it's a real problem. I guess, do you have any advice for people that are struggling with key management or figuring out a good key management practice?

Kyle (13:09):

Yes, I think my advice for that is what they drill through your head in college security classes, about implementing your own encryption in general, which is don't let someone who's better at it than you do it. Let experts do it because if you do it yourself, you're going to have a bad time and it's just not going to be as secure because it takes a special type of domain expertise to do it. The only time that we ever want to hold user's keys or that we let our code hold user's keys is if that's only sitting on their device and we've prevented anything from touching that. Anytime you're storing, you don't ever want to try and roll your own solution to store keys in a database or anything like that. We designed our system from the very beginning so that we did not want to touch any of that information, but for most people, that's not a realistic possibility. And so if you do have to store that type of information, you don't want to be designing your own solution to that.

Liz (14:14):

That is not a weekend project that one should pick up and try to run with.

Kyle (14:20):

Don't do the FTX style, store users private keys and your Mongo database on encrypted, you're going to have a bad time.

Liz (14:28):

Oh, yikes. You mentioned that you do a lot on AWS and I have recently been building more stuff on AWS and I can really empathize with people. I think I mentioned this maybe in another show recently. I feel like when you're just trying to get something to work, you set everything up and you're just like, "Oh, I'll go back and fix this later. I'll change this permission later." And then sometimes later just never comes. And then if you're building a demo like what I'm building, it's probably not that big of a deal. But if you're building something that's managing people's money or private data or whatever, then that's not a good idea.

Kyle (15:06):

Yes. AWS does a pretty good job making things relatively secure by design, certainly with their default firewall configurations and access controls and those type of things. But it's also really easy to do something that has serious security implications without realizing what you're doing. If you've never written IM policies before, they're not the most obvious thing in the world. And so it's really tempting to use the wildcard sometimes, which is a really bad idea, but if you're just using AWS for the first time, or if you don't have someone that knows what they're doing and you just need it to work, that's what you're going to do. And it's really easy to do that and then to forget you did that.

Liz (15:50):

So I love asking this question from developers, but I feel like every developer has that one problem that's really annoying to solve. I feel like time zones is one that comes up a lot, but I'm wondering if you have anything like that where every time you're going to have to work on it, you dread it.

Kyle (16:09):

Yes. Timezone normalization is definitely one. The friend that I mentioned earlier, Will and I, we met in college and we worked on building a really small startup while we were in college, and part of it had to do with notifications and scheduling, and we wanted the scheduling to be native to the user's time zone, and so we tried to do timezone normalization and get what timezone the user was in and schedule things based on that, and it caused us some problems, and we ended up losing a customer because they were in a funny time zone that just made something break because it's not like you just have your latitude and longitude.

(16:47):

It's jagged lines everywhere. And then does this country do daylight savings time? Does it not do daylight savings time? And that's a pain. I haven't run into issues with that in a long time. I do run into Arcane AWS issues sometimes. We recently had several of our fortunately non-critical microservices just stop streaming logs for some reason, and we started playing with IM policies a bunch and couldn't figure it out, and we rebooted the service and it worked fine. It was like the-

Liz (17:18):

Classic turn it off again, turn it back on.

Kyle (17:21):

... Execution role had lost, I don't know, something to do with cash credentials, but we run into Arcane AWS policy and permissions issues from time to time. We have a particular developer on our team that does a lot of the infrastructure for that team. So I do a lot of it for a wallet team, and he does it for his SaaS team. And sometimes I wake up in the morning, because he's in Eastern Europe, and I'll see a Discord notification badge on his profile that says I have six messages waiting from him, and I just know it's going to be a long day because I'm like, "Oh, not again," because it's always some Arcane AWS issue. Just takes all day to resolve, but it's still easier than running your own stuff on-prem and hiring a full infrastructure team.

Liz (18:17):

I guess what's your experience been like working at a startup? It sounds like you came on pretty early on and I guess from a technical side, what's the experience been like for you?

Kyle (18:32):

Yes. It's been fantastic. Honestly, I think everyone should work at a startup because it forces you to learn so many things so much faster than if you were working a more traditional role at a larger company. If your job is to be a React developer or a backend developer, there's nothing wrong with that and that's great, but that's pretty much all you're going to be doing most of the time. And working at a startup, there's fewer silos and our teams are much more cross-functional, and so the front end guys are working with the design team to iterate on the designs and find something that both looks really good and also isn't going to take six months to implement. Our backend guys are working with me and one of the other developers that works on the AWS infrastructure so we can coordinate, here's what the infrastructure is going to look like and how do we design the application so that it works well based on the distributed configurations for it.

(19:36):

It also just lets you get a lot closer to the business side of things because you're sitting in the same room with all the guys that are doing the marketing, and while we're on calls with other FinTech companies for banking rails. And it just exposes you to so many more things. I learned more in my first year at Zelus probably than I did in four years of college. From the standpoint of practical hands-on knowledge, it's like drinking from a fire hose. So sometimes it can be overwhelming, but it's just so much information because sometimes you can't punt a problem to your senior dev because he's busy or because there's no one more senior than the person that's working on it already. And so you as a team have to sit down and work out the solution. It's great. I think everyone should do it.

Liz (20:37):

I agree with you. I worked at a startup probably like eight years ago, and then I went to a big enterprise company right after, and then I went to a mid-size company, and then now I'm at Evervault, which is still in startup scale up mode. And it is so nice to be able to just say, "I think we should do this," and then you just do it. It's amazing. There's no nine levels of approvals that it has to go through. And you're right, I think you do learn so much, especially just because there are a lot of different types of problems that you have to solve.

(21:15):

I actually saw something recently, I think it was on Twitter where people were talking about how a lot of folks that were at bigger tech companies that, for whatever reason, now are no longer there, a lot of them were reflecting that I learned so many skills of how to grok this particular organization, but now I'm realizing that that might not apply to another place that I go. And I just thought that was interesting because it is sometimes the larger a company gets, the more it can become just about figuring out how to navigate it versus doing whatever role it is that you do as your main priority.

Kyle (21:57):

There can definitely be so much more red tape. When I was in college, I interned for a company where you had to go fill out a form and submit it and wait two days to get approval to run as local administrator on your computer. If you couldn't install something to your local user, you had to install it as an administrator. You had to fill out a form and email it to someone and keep bugging and it was awful. So yes, definitely so much less red tape. And I think also, especially with FANG and some of the other really big tech companies, they very much have their own, not just idioms in terms of their processes or organization, but their own technological idioms that you get really used to doing. And nobody else does things that way because the company has pretty much their own internal stack.

(22:44):

I know Google especially is really notorious for this. All their services use GRPC and [inaudible 00:22:50] and they use a lot of other technological things that everyone there is really used to working with, that just nobody else uses because it works really well when you're at Google Scale, but if you're not Google, you can't scale it. You can't build it in the first place because the team that's required to do that is bigger than your entire company. So you don't have those weird idioms at startups and smaller companies.

Liz (23:18):

Definitely. I'm very curious to see too, just now that things are changing in tech, between AI and just the change in the market, I think it'll be interesting to see the things that come out of this period of time. And I'm wondering, is there anything in particular that you feel excited about within tech, like a new technology or something in the web3 space?

Kyle (23:43):

Yes. I know at this point this sounds like a boring answer, but I think AI obviously, I'll say there's a search engine called you.com that I use. It's like ChatGPT with internet access and it'll cite at sources and everything when you search for things. I haven't used Google in probably six months because I use this AI search engine, and it's so much better. It can also be fine-tuned for when you're looking for code versus when you're looking for research papers. And so it's so much better. And I think collectively, we're just really scratching the surface of what AI can do. It seems like every week someone's figured out how to do something new, whether that's creating deep fakes of Drake songs or writing these little autonomous GPT agents. I think it's like an event horizon. It's hard to see past because I don't know where we're going to be with it in five years. Someone compared ChatGPT to being AI's iPhone moment. I think it's more accurate to say it's the invention of fire. It's like we have no idea what comes next.

Liz (25:00):

That is true because there's just so many applications and there's endless ways that it's going to be integrated into, not only our careers and our work in tech, but just in every facet of life.

Kyle (25:18):

Yes, because it opens up a new dimension for applications. You can think about it as the way that applications used to be written. You pretty much just had syntactic data. Users could give you information and you could transform it mathematically or using other APIs and indexers and so forth, and you could use that, but you couldn't code semantics. You couldn't say, "I want you to do this." And so applications were limited in that way. And now AI and GPT in particular allows you to build applications that have semantic content. A user can express that they want to do something or they can upload a photo and now you can, instead of just saying, "Oh, here's a photo, apply a filter to it," you can say, "What is in this photo?" And you can get the semantic meaning of that, or you can just do so many things that used to be so much harder just by making an API call to open AI. And so I think it's really exciting.

Liz (26:23):

Are you building anything with AI yourself at the moment?

Kyle (26:28):

I've played around with it a little bit, just really small side project type situations, but I'm pretty heads down focused on the web3 space for work, at least.

Liz (26:40):

That totally makes sense. What is something that you've learned that you'll never forget? Something that just really made a huge impact in your life as a technologist and a programmer?

Kyle (26:58):

I don't know that this is necessarily came from a single person. I think it's a lesson I learned over time, but it's that instead of focusing on tools to learn or frameworks or languages, you should understand the underlying concepts and primitives and understand those things really well. And then from there, you can go much broader or deeper where you need to without being limited to your framework. So for example, when I was doing a lot of the ethical hacking type things in the cybersecurity space, there's a million tools out there, but you can memorize how to run a million tools or you can understand how the application that each of them is checking or scanning or whatever.

(27:44):

You can understand how that application works and how it can be misconfigured. And then based on that understanding, you can then go poke and prod at it where you need to, instead of having to run six tools. And I think the same thing applies for software engineering. Instead of saying, "Oh, I'm going to learn no JS or React or Next JS," it's like understand how applications work, understand client server separation and networking protocols, and you'll be much better at building systems. And if you understand programming languages really well, you can go learn a new programming language really quickly. Obviously some of them have their own ADMs, some more than others, but don't learn skills, learn skill acquisition, if that makes sense.

Liz (28:28):

Yes. That is something that a lot of people told me. I did a software engineering bootcamp, and the number one piece of advice from every mentor that I had was like, "Now you have the basics. Go learn where those come from." Because Python was the first language that I learned and then I needed to learn Java pretty quickly. And so they were like, "Data structures, algorithms, just get all of these basics and you'll be fine." And I remember at the time, it just did not make any sense to me. I was like, "How can this be true?" Because I don't think there's an analogous, at least not one that comes to mind for me. There's something else that's like that to learn that way where you can just trust that if you get those basics, then it will translate into any stack that you might want to use within reason. But I think that's definitely very good advice.

Kyle (29:21):

And I think it can be counterintuitive sometimes too because I remember learning all these things in college like operating systems or data structures, and you're like, "Why do I need to know how to reverse a link list? I'm never going to write this from scratch. Why do I need to learn how least recently used page replacement works and the Linux kernel? I'm never going to use that." But then you're writing an application and you're like, "Oh, okay. This needs to be a really small service that can be horizontally scaled. And so it needs to be really memory efficient. And so how do I design the application and pick data structures and primitives that will allow me to write something that's really memory efficient?" And you would just have a much harder time doing that if you didn't understand what was going on underneath the hood.

Liz (30:07):

Absolutely. This has been great, Kyle, thanks so much for telling us a little bit about the work that you do and the web3 space in general. Is there anything else that you'd like to share?

Kyle (30:22):

No, I just thank you so much for having me. It's been really fun and I really appreciate it.