 Hey, everybody. Welcome to the end of day two now for DevCon. Thanks for sticking it out with us. We're just going to have a conversation about current state of security in Ethereum. We're going to do about 25, 20, 25 minutes of questions here, and then we'll take some questions from the crowd. So first, I guess maybe we'll introduce ourselves. You guys want to go down the line to say who you are and what you're doing. All right. I'm Martin Holstenslander and I work as the security lead for the Ethereum Foundation and also work at Gath Development. I'm Phil Diane. I'm at Cornell University in IC3. I'm a PhD student working on smart contract security. I'm Matthew Defronte. I'm the founder of Zika Labs, an Ethereum-focused auditing firm and also cryptographer. You know, by implementation, I do cryptography related things on the side. I'm Marellian, a founding member of Consensus Diligence and a smart contract auditor. Hey, I'm Dan Guido, the co-founder and CEO of Trailabits, a software security research development firm. Awesome. Thanks, guys. So we're going to start it off with the softball. What's the biggest change in Ethereum security in the last year? So I'll take it first. Yeah, go for it. I think there's been a couple of things I've noticed. The first is that the Solidity compiler itself is a little bit less on fire today than it was a year ago. There are certain patterns that we had implemented in our own static analysis tools that have been deprecated because the compiler now checks for those issues. Things like the constructor being the same name as the contract and having divergences of those two, allowing you to exploit uninitialized contracts and variables within them. Another thing that I think is pretty unique is that a lot of the less serious people have dropped out of the community. So the post-ICO kind of field of people that are left now are a lot more serious about developing applications that work. And I think that shift in culture has led to much better code. And the last thing is I think that today we have substantially better tools so that if you care to write good code, you can. Things from, you know, my company, Slither, Bantacor, Akidna, things from everyone else on this panel of experts here have demonstrably improved the code that I've seen from our clients. Yes, I was going to say that a year ago when we were in Mexico, there wasn't much of a security community and that's something which I feel has really taken off in the last maybe half a year. And most of the people who were interested in security came from the Ethereum space and really were Ethereum enthusiasts who were also interested in security. And now I think we've seen a kind of large influx from traditional security into the space. And that really changes things. Yeah, to speak to what Martin just said, sort of recently I attended an academic conference USENIX 18 and they had actually an entire session on smart contract security which had I think around four talks that were Ethereum related. And that's a community that's completely outside of this space. Those are people who normally would not be working on these tools. So definitely a lot of outside people have come in and we've also seen sort of the people who are already in the space start producing artifacts. So we've seen the first set of formally verified contracts. We've seen smoother processes for like engaging that and just a lot of improvement across the board. I think kind of everything is a little bit less on fire than it was a year or two ago. They've stopped adding tires to the fire. Yeah, it's still on fire. Yeah, I think sort of what everyone else has said. I think really like not only has the security community grown, there's been massive increased awareness in security issues. I think like most exchanges now require a security audit of some sort before they interact with products, which is surprisingly shockingly that wasn't the case always, right? There is more awareness generally that before you go live, you need a security audit. There's like the best practices that need to be followed. So like, you know, we're playing a bit less fast and loose and more realizing that, you know, if you write a smart contract, you know, that may hold even if you don't intend it to many millions of dollars and, you know, you don't want to be directly or indirectly responsible for a loss of that. It's hard to go after all these guys and have something original to say. So tools, it's been an explosion and I just want to like call out like Zeppelin, Chain Security, Trail of Bits really like coming on hard in last year as really like stepped everybody's game up. And then like Bernard and Mithril with Inconsensus are kind of going crazy, you know, good fun way. And then I think like maybe the thing I've heard more conversation about recently is like the awareness of incentives and how crypto economic mechanisms themselves can actually contribute to security in like one way is just like automated deterministic non-subjective bounties that pay out when you break the thing. I think that's amazing. Cool. So next one. Compared to securing traditional systems, how do the economic properties of smart contracts change how you approach their security? Okay, well. So I'm going to like what I think is one way that we're tackling that is actually through actually creating like incentives for coordination within the security community. So our Panvala project is a set of incentives that bring people together, developers, auditors to try to establish clarity around what is a safe contract to use. And if you're interested in that, we recently put a video of the process for seeking consensus around that. I'll tweet it after and we'd love to get your feedback on it. And we have got some already and I'm looking forward to more. Okay. I think like one of the big distinctions is the irreversibility and the transparency of the smart contract environment versus the you know like traditional security domain kind of you can usually treat traditional security almost like insurance you know it's like often less costly to just fix the issue after the fact than to prepare for it or you know you have like safeguards or abilities that you just don't have in smart contracts where you know somebody drains their contract I mean it's over there's there's no recourse. So and I think like it's it's a lot of people say hey look you know smart contracts just never going to work because look at all the exploits that have happened but I don't think it's a smart contract thing I think it's well of course it's a new space and it's a bit hard to have a good security framework in such a nascent space but I think this is a problem that's exist in all software and it's just far more clear in the smart contract space and damages are irreversible so it's more it's not that you know smart contracts are necessarily hard they're hard in a different way but I would say that the level of difficulty is similar to other domains it's just that if you're bad if you don't do your due diligence you don't fall the right process there is no hiding behind you know like a firewall or a closed garden there's no oh I'll report it if I have to it's just there for the world and so all mistakes are very clear so it seems like there's more but you know like there's banks have lost far more than smart contracts to the date to date. Yeah so I think for me economics sort of has a dual nature here in one way it's very helpful in securing these systems so something like just knowing the value of the system you're securing is not something that you can do in sort of classical systems like what is the value of a power plant's ethernet system or what is the value of an election system for a county or something like that so it makes some kinds of security analyses much easier on the other hand because a lot of the security assumptions we have to make to show that these systems are secure are themselves economic it also sort of brings security into this realm of economics which is much more subjective and nebulous where like even two economists might not agree on basic definitions or basic principles so I think we're gonna see a lot of subjective security sort of develop as the space starts to differentiate itself from traditional systems and I kind of look forward to that also on a personal note the economic nature of these systems kind of keeps me up at night so I don't know about you guys but when I'm doing an audit I'm you know I'm worried about that a lot more than yeah it's motivating exactly yeah and that's kind of really what you should you should be awakened that because of that because I mean if you come from traditional IT security you're trying to find vulnerabilities and you might find you know like cross-eyed scripting some SQL injection some data leakage you can take money even maybe sometimes from one account and do something but the stakes are so much higher here and it's like someone can randomly make a contract which all of a sudden has millions of dollars and we need to kind of realize that the stakes are so much higher so so easily in this system which is just nativities with currencies stuff I'll keep my answer brief I think the one sightable anecdote to backup Phil's point is this bank chain bug that came out just a few weeks ago where the blog post described hey we didn't do an audit of this because it would have cost more than the value held in the contract itself that's not something you can really do with a classical system and I totally agree with Phil's point there that this is something completely unique about the field that we're in so I think that's the biggest difference I could point to yeah cool and so actually Dan we were having this conversation the other day about bug bounties and whether a good practice or using tools to find repeatable bugs and you want to launch into that yeah sure so I think the concept of bug bounties makes sense if all you get if all you want to get from an auditor is a list of bugs if that's all you're expecting to receive from hiring anybody on stage here to review your project is a list of bugs then sure a bug bounty makes sense I wouldn't think that any of us expect to only provide that as a service the second really big issue here and really you should be upset if you've hired someone like one of us up here and that's all you get that's that's not the service that you should get in order to end up eventually getting secure code the second thing is you don't know how to measure the output of having that bug bounty so what did you receive like did enough people look at it how much code coverage was gained did they inspect it for the issues you actually care about you have no idea a lot of this has to do with just a lack of talent in the industry like people at trail of bits have done bug bounties before and the way that we do it is we spend about 10 minutes to just scan over the code by hand run our slither static analyzer on it and if it doesn't find anything we move on the smartest people in the space are not doing bug bounties because we have better things more impactful things to do to improve the ecosystem itself like build tools and do research than to spend it all on bug bounties so I think that a lot of people in the community have been misled about the efficacy of what bug bounties actually can accomplish so if you really really need security guidance you really should be talking to a smart human that can reason about security properties of your system and the bug bounty thing is just a secondary kind of cover your ass type type deal which sure you could have you could not have but it's not the first place you start and it it doesn't cover nearly as many bases as people think it does I agree I don't have anything dad okay um well sure I'll go and uh yeah I know I agree that the efficacy of bug bounties is dubious in certain circumstances I think like if you have like the contract is the bug bounty in a lot of cases right if you have a monetary compensation for being ethical that's like uh you know an auxiliary incentive like if if really the people who have who go around looking at contracts and testing if they're vulnerable uh you know randomly generally those are also unless you're like you know unless you're one of those hacker one types those are not the people who are gonna report the bug bounty to you there's like many there's many other ways to to profit besides reporting it to the you know responsibly to the to the company and you know and like I'd echo this statement that you shouldn't really just be looking for uh lists of bugs or vulnerabilities like how many vulnerabilities did this guy find it shouldn't be the metric for our quality security audit it should be how are we informed now to make better decisions in the future how have we gotten comments on improving our process such that you know we we don't make fragile code we don't get into bad situations in the future um I think realistically both in this industry and outside if possible it's always best to hire a security person internally right like someone should be with you every step of the way security is not like a an afterthought it's not like a thing at the end of the process it's part of the process of creating software and really in the blockchain space uh you know it's this is very evident but I hope that you know like even the traditional industry starts to think more this way so I agree with most of what's been said so far I do think Dan was maybe a little too too negative on bug bounties um so the way I see bug bounties is that it's obviously not a a sort of substitute for doing your homework so it's your job as a as a company to ensure that you hire the right people to have input into your code that you hire external people as well as yourselves that you run security processes and engage in critical review of your software that you understand the limitations of the people you're hiring because while all of us are competent security professionals we're humans who have like a certain amount of hours in the day and we all focus on different aspects of security so it's your your job to ensure you hire a diversity of opinions and skill sets to sort of inform you about how to proceed with your code but at the same time if you don't have a bug bounty you're you're sort of skewing the incentives for anyone who eventually finds a vulnerability in your program so you want to have something to sort of offer somebody who does find that vulnerability to stop them from just taking it to the chain or something like that so I think from an economic security perspective bug bounties are sort of necessary but not sufficient just to respond to that I agree with everything you said and I think that if you don't have an easy way to report bugs that are discovered in your application after it's been deployed you're making a huge mistake we have a little wiki that like talks about some easy things you can do to make it easier to communicate with your project I believe it's called blockchain security contacts so that if any security researcher does find a bug in your code they can actually communicate it to you so don't neglect that but yes you're completely correct yeah I just echo what Phil said I'm all for bug bounties but not exclusive or security work yeah yeah same I mean I don't think it should be the only security that's done I mean there should be like a process that you know makes your development more secure like there should be someone in house there should be a formal audit or three and then there should probably be a bug bounty like across it all I just think we've been sort of like the false equivalency there's like do an audit don't do a bounty instead of an audit and then run a bounty so that somebody has a reason to report it to you they're they're separate things right all right next one is what advice would you give someone who's interested in becoming more involved in smart contract security where would they start so my answer to that would be because that's the way I came into smart contract security to learn the intricate details and integrate the mechanics of the evm and execution of transaction from the bottom up that would be my first advice kind of yeah that's definitely great advice I would also say look at past security failures and replicate them yourselves so you should be able to pull off something like the dow hack you should be able to understand how to exploit various people's coding error and you should try it by example and then once you're sort of done doing that and you feel comfortable that you're at the state of the art maybe try finding something new even if it's not a very high severity thing find something that people haven't thought of yet in some edge case and whether that takes you three months or six months sort of at the end of that process you'll probably know a lot more about the evm and smart contracts yeah I know I agree with both of those statements especially the intricate details part like most security issues come from misplaced assumptions right so you have this black box and it has a set of properties that you like you do you feel comfortable with or that someone else has told you those are the properties and like it's that the telephone game right like depending on how far away the person that originally actually you know made the thing how many levels are on between you and that person like it's likely that the understanding of that black box is twisted and then you write code that has a bad understanding and misleads the next person and then it just you know builds up over and over right so the more you can open black boxes and say this is how that really works this is where that interacts the less prone you are to security mistakes and also just try just try to be a good developer and write antifragile code you know the the big one the one of the recent Bitcoin go bugs is a is a perfect example of that is when you write a function that seems like it makes a check you know like the name misleads it into into making you think that it makes a check like the the file it's in whatever and so somebody will see like oh fine that makes that check and I don't have to check it in the container function and then you get you know infinite money being printed so be really careful about your assumptions just cultivate that mind that's mindset of awareness that's how you become good at security ticks I guess take a bit different direction I'd say contribute like learn by doing so like participate in bounties which are like not that bad we agreed and like run the tools on the contracts before we do so that maybe you'll like get a list of things and make some money and then you'll feel great and then you'll do more and then you can start contributing to you know very like documentation our best practices would be great or like Dan's not so smart contracts as well as our smart contract weakness classification registry like you you know and then teach other people like that's that's how I would go about doing it and then show up at these things and ask good questions so I think it kind of depends on what you want to get out of working with the community like are you someone that wants to go like stun hack and flex on twitter about it are you a researcher that wants to build tools or are you a developer that needs to secure your code and with each of those different constraints there's probably a different pathway to learn what you need I think that each of those starts with two things and first to Martin's point you have to learn the lower level details of all the languages and tools that you're working with and the second is that you should review what's already been done we tried to do our best to make a compendium of that with the awesome ethereum security list just a few links in places where we think people can start off to learn but it's really important to keep in mind what your goals are because you know you want to spend the least time to get the most effort cool so I think we might actually go to the crowd now if anybody has any questions we have mics down here on either side of the stage if you want to come down I've got more questions to ask but that I might turn it to you you want to ask it the mic here hi I was making some notes my name is Dmitry I'm CEO and co-founder of cybersecurity consultant company Haken I've made about 70 audits for the last nine months and we are all based in Ukraine so what what's I made notice that you like we're saying that people from traditional cybersecurity companies are entering the industry yes and so I totally agree that the bug bounty is not enough but the my comment is that it's like the traditional people like I'm eight years dilute like what we want we want to have a methodology and guideline like what needs to be done in order to be sure that the audit was done correctly and I think that this is what is missing so far in this industry yes the weakness classification work is great but there are still like so many things needs to be done like there are two ways how you can do the methodology is a principle based approach like what are the risks and how to cover them or the second is the checklist what's what test needs to be done so my question is like how do you see what is the right roadmap to create this methodology who is leading this process and like like I want to underline I think this is one of the most important thing right now that needs to be done in this industry thank you yeah I'll fill that one yeah so we do have a a community called e-security which is a community that I lead and out of that we have a number of working groups so there's actually a working group for developer guidelines and as well as auditor guidelines or assessment guidelines so the smart contract alliance is one of the groups and Securif is making the developer guidelines so I encourage you to reach out and get involved in those groups because they are open if you want to hit me up on telegram I can add you to the correct channels yeah so I would caution against trusting any formal like checklist or process too much because the entire sort of point of an attacker in the security world is that they understand your assumptions and try to violate them so that checklist could actually lead to sort of blind spots in your process as well so what I would say is that any sort of halfway competent person you hire to take a look at your contract should sort of know subjectively like as a human being like where are my blind spots what have I looked at what have I not what state of the art stuff have I done what state of the art stuff have I not done and they should actually inform you about that as part of the process and and having someone internal who also understands the state of the art could help you with that too yeah sorry I just like to add that I think checklists are great but they're not for auditors therefore developers to kind of check why they write in the code but the auditor shouldn't have to you know rely on those who use those extensively yeah I will add those the developer and assessment guidelines are more framework for like as I enter into the product like as a developer what are the steps I'm going to go through so that I have a consistent product to then hand over to an auditor when they receive it so it's not just like a bunch of like files and and on the on the assessment side okay what are we going to be delivering back to the client and so that the process is a little bit more there's some expectations on what you give and receive somebody else over here hello I would like to ask you about security in a future proof of stake actually security of validators and because basically the issue is that let's imagine that I am validator I will put like 1000 of ether in the my wallet and I will register the wallet for for staking right I will register with my private key and what happened if I'm signing block with the same key in the in the network and let's say that someone will take my note can he actually use same private key to the register my note and actually take my stake or my question is how can I secure my stake in the future proposal I'm trying to find it but did you get it what I can I rephrase it because I'm not sure and I'm no proof of stake expert but what I think you're asking is the same as for proof of authority chains where the actual sealing requires the presence of the of the private key in the node yes and yes that is the case so you will actually have a network node which contains the private key or private secret alternatively can talk to back end to get something sealed or is there actually any solution how to do it so actually there is a solution there are different ways to do it one thing is that this I've been working like the last year building something called clay clef it's in the go theorem repo it's an account management tool which can also do signing for a clique blocks which is a the a proof of authority chain type so there are solutions but it's not production ready I guess yet so so from my conversations I've had with the Casper people and it's kind of hard to nail down because the spec is so constantly evolving it would certainly be possible to have a separate key for signing proof of stake messages then for moving funds and then essentially what you would do is you'd sort of delegate to that key and that key would put you at risk in the way that it could get your fund slashed if someone misbehaved on your behalf but maybe the protocol only allows funds to be slashed so quickly so you can still sort of get some guarantees by maintaining some sort of cold storage and I'm not sure if that will make it into the final protocol I think preliminary discussions I've had suggested that it might it's kind of an engineering detail but in theory that's sort of one way to to mitigate against those risks also I'll just say that if people have detailed technical questions they'd like to get answered by security experts they should join some of the communities that Kevin mentioned before and then personally Trail of Bits has open office hours we run every other week where people can just engage with us and pepper us with questions like that one and get sophisticated answers back cool so we got about two minutes left let's come back over to the side hi what should be added or changed to the standard development process to enhance security so it's built in and enhanced as much as possible during development not including the external audits and things like that uh yeah I feel like this is a chance for all of us to plug our tools here um yeah in general I think trying to work out like what are the properties that your code is supposed to have and the invariance that you don't think should ever be violated about it are kind of a good first step um you know we have a wealth of tools available now we mentioned uh in 2018 that we didn't have last year we have static analyzers that pick out examples of incorrect code but we also have tools that allow you to prove properties about your own code um so like at a basic level you should be running static analysis tools and bug finding tools like slither or mithril uh early on in the development cycle uh you should be thinking about what kinds of properties uh the spec or invariance that you'd like your code to hold and then using tools like a kidna manticore or k to actually prove that those properties hold for all the cases you think they do um and then you should be engaging with experts to think like you know in an adversarial fashion about how the environment that you're executing in can affect that contract so like whether you can be frontrunner or not um and then also uh whether there are ways for um people to uh work within your system to collect you know tokens or incentives and produce suboptimal results um and eventually just you know degrade the effectiveness of whatever the decentralized system it is that you've created um those are some things that I think I would think about if you want to end up with a a good product at the end write a damn spec please because otherwise we can have no way to understand what you think you're building so write a spec and make it as formal as possible yeah I'll say again write a spec write a lot of specs write specs every time your code changes and also code review with each other make sure everyone's on the same page about what your code does the like huge amounts of security issues come from the fact that just people are not on the same page um yeah so mythril mythril mythril um you should run it you should also run his uh run a linter I really like sodium and like if you if it's enforcing like some reasonable code style that goes much further than you might think um write a lot of tests ideally write write a spec and then write tests and then write the code that does the thing um uh yeah that's I don't have anything to add at this time awesome and that is all the time we have so thank you all for being here um I think we're gonna have to come back out and close this out thanks guys