 Thank you. Good afternoon, everyone, and welcome to this talk about Securify. Securify is a smart contract verification tool which was developed by the people that you can see on this slide. It was developed at ETH Zurich, which is a leading technical university in Switzerland, and you can learn more about Securify by visiting the various links that will appear in these slides, and I will make these slides available afterwards, after this talk. So first, let me tell you the reasoning behind Securify, and motivate the creation of Securify. So, most of you are aware, assume in this room of the various security flaws that have plagued Ethereum since the beginning. So the most famous one remains the DAO bug, which eventually led the developers to a hard fork of the chain, so as to revert the state changes created by the attackers. Another more recent security flaw was the multi-security bug, which resulted in 30 millions in Ethereum robbed by attackers. So, let me go into details of these second flaws more precisely. So it was a case of in-privilege right to storage. Here I have a really simple example of this kind of flaw. So just keep in mind for all the examples that are going to come, that these are meant only to illustrate the flaws and not meant to have a real logic in themselves. So as you see here, it's really a toy example. So this is a wallet contract, which contains a storage variable, honor, which specifies the honor of this wallet. And there are two functions, this initialization function initWallet, which can change the honor, and this withdrawal function through which the honor can actually withdraw money. So you can see here, if this works, so you can see here that there's actually a check to prevent anybody else from withdrawing money. But the problem in that case is that anybody can actually change the honor variable, which is a problem because it makes the check useless. So this is, this is, in a sense, the multi-seq parity bug. That is, you allow anybody to write to your storage, even though you rely on it for crucial operations. So of course, the exploit in a multi-seq parity bug was much more complicated because the contract itself was more sophisticated, but the basic vulnerability is the same. So there are many more security bugs that are possible with the Ethereum platform. One of them is the category of unexpected Ether flows. For instance, when you expect Ether to go to your contract, but don't provide any means to withdraw it. So you end up with locked Ether in your contract. In-secure coding, such as the multi-seq parity bug, so providing ways to write to your storage without checking whether the user should be able to do that or not. The use of unsafe input, whenever you use, for instance, timestamp or block numbers and pretend that these are random variables and even fit them into cryptographic functions. For instance, to create a pseudo-random generator, then this is bound to failure because these variables can be biased by miners. So, for instance, a miner can decide not to process your transaction right away and thus it's going to be delayed by at least one block, which is going to result in a higher timestamp. Reinterred method calls. This is basically the DAO bug. And manipulating Ether flows via transaction reordering. So this is a bit specific to the Ethereum platform where all the transaction can be processed concurrently. So for the details of this one, I have another toy example, this token contract where you have two storage variables. One is the price of this token and the other is the owner of this contract. And so you can set the price where only the owner can change this price. And the second one is a sell token where some Ether is transferred. As you can see here, a user can call this function according to a given price. So what happens in practice is that a user can read the price variable on the blockchain. Everything is public and you don't even need to create a transaction to read the value of this variable. But what happens here is that once a user decides to call this function, the owner can still call another function. So what would happen is that the owner would realize that there is a transaction pending with this function. And then decide, okay, maybe I want to increase the price or lower the price depending on what he wants to do. So the thing is when you have a transaction pending, you have no guarantee that it's going to be executed within the context that you just read. And so in a sense the two operations do not commute and you shouldn't expect them to commute either. So how to detect this kind of bugs? I'm going to talk about automated security analysis as a way to make sure that these bugs are not implemented in your contracts. So if I were to draw a big drawing of all the possible behaviors, I would have something with all the possible behaviors and within them a lot of security bugs that you want to avoid when implementing smart contracts. The problem is that you cannot enumerate all possible behaviors. For instance, if you have an integer argument in your function, you cannot call this function with all possible integers and just say, okay, this trace is faulty. So at one point you have to make a trade-off and decide how to find the bad behaviors. So the different security analysis approaches that you can have are here represented. So the first one would be testing where you actually try to cover one path. And from this one path you're going to extract one trace and try to check whether or not it's faulty and whether or not it corresponds to what you expected. Dynamics symbolic analysis, which is an improvement on basic testing because you're not able to cover way many more paths. So this is a bit testing plus plus if you want. So you have the same kind of guarantees that is testing and dynamic analysis report true bugs that actually exist in your code since they provide you with traces of what happened. But they can still miss bugs because you have an issue of code coverage which is not equal to 100% so this is a problem because you can never be sure unless you have covered all your codes that is 100% coverage you can never be sure that your code doesn't contain any of these bugs. And the last one in the focus of my talk today is automated verification which makes a different trade-off that is it can report false alarms but it has no missed bugs. So what is the current state of the art for the Ethereum platform? What do we have? What tools do we have? And why do I suggest today? So on the testing side we have Truffle and Populus which are respectively JavaScript and Python frameworks and help the developer to implement their contracts and associated tests and deploy them efficiently on the local dev chain. And this way the developer can run these traces and check their assertions in an efficient manner. On the dynamic analysis side you have Oriente which was just presented and which allows the developer to cover many more paths in his code execution. And on the automated verification side we now have Securified that I'm presenting today and which as I said makes a different trade-off that is it provides you with strong guarantees that the bug that you are trying to find doesn't exist in your code. On the other hand it can also report that the bug might exist in your code and then you have to look at it on your own and tell whether or not it's here. So this is really a different trade-off from the two previous categories. So if I were to summarize Securify in a few words I would say that Securify is fully automated. One click formal verification system for Ethereum smart contract. So I've prepared a short demo and so I hope it's going to work. So this is recorded. So here you have the interface of Securify. You can see that by default there is some example of Solidity code. So this is the website itself. So here you have some Solidity code that you can input so that you can verify it afterwards. You can also feed some bytecode or you can also input the address of a contract already deployed on the main chain. So the thing to keep in mind here is that Securify actually works on bytecode. So even if you give Solidity code what is this going to do under the hood is this going to compile this code and work on the EVM code. So now if we look at this simple example of a simple bank you can see here is that you have a storage variable balances which contains the balances of the users. You have a deposit function which allows a user to deposit some money. And you also have a withdrawal function. So there are many things that are wrong with this code and I just want to show one of the codes. So here you can click formally verify and you have a security report with various patterns that are checked or not. So the one that I'm interested in right now is gas-dependent re-intrancy. So basically the DAO bug. So if we click on the match line to find out where the 40 code is we're going to see that here there is actually some ether which is sent and some storage value which is set to another value after the call. So this means that the attacker through his fallback function can call this function again and this function is going to be executed within the same state which is the DAO bug. So one solution for this bug in this particular example is just to remove this line and put it before which is a quick and dirty solution let's say. So if we click formally verify again we're going to get another security report and in that case you can see that the pattern is no longer going to check. So you have made sure that your contract is no longer, can no longer be a victim of gas-dependent re-intrancy. And this is a strong guarantee that is you're 100% sure of that there is no notion of code coverage here. Or let's say that the code coverage is 100%. So another example now is this flow-the-wallet contract. So here you have a storage variable which is honor which is the honor of the contract. So this is the example I showed earlier. You can initialize the honor of the contract through the first function in it-wallet. And the second function allows some transfer of ether if the message sender is the honor. So we're now going to try to get the security report out of this contract. So if you remember it's a multi-stake party bug. So you see different patterns and here the one that I want to focus on is unprivileged write to storage. So I explained it earlier is just that you allow anybody to write to your storage without any check. So if we click on the match line we're going to see that the faulty line is where you assign the honor to another variable without any check. So here's a solution that we can use and that was actually used in a multi-stake party bug was to have a modifier only honor which is going to make sure that the function will be executed only if the message sender is the honor. So basically having the same check as you had in this function but for the initialization function. So here you click formally verify again and if you look at the patterns nights it's safe. So now your contract is guaranteed to be to be deprived of any unprivileged write to storage. One last example quickly is that of the token with a changing price. So this is the other transaction reordering example that I showed earlier where you have this set price function through which the owner can change the price. And you also have this cell token which is meant to be used by the user. So if you click formally verify you're going to see here that the transaction may affect either amount. So this is a case of transaction reordering because the amount that can be sent depends on the variable which is not constant. So here a quick fix would be to just decide that the price is constant and remove any ability to change the price in the future. So if we click formally verify again we're going to make sure that this pattern is checked. So of course in that precise case it removes one feature of the contract that is changing the price. So you would need to do a bit more to keep this feature. That's it for the demo. So now let's talk a bit about what's under the hood of Securify. So first as I said earlier, Securify works on the EVM code. So you're going to feed it the EVM binary that you obtain for instance by combination of your Solidity code. And using this, Securify is going to obtain an intermediate representation. This intermediate representation is only meant to be easier to process by static analysis. This static analysis provides you with a set of basic facts about your code. For instance, you know that this variable is a constant or you know that this variable is a balance. And so all these basic facts are the number zero of your iterations that you're going to run to have more and more facts. So basically you have a set of inference rules. That is, for instance, if A is a constant, B is a constant and C depends only on A and B. You will know that C is a constant as well. So you can imagine the sort of inference rules that we have in Securify to obtain more and more useful facts about the code. So iterating over this, you finally obtain a set of facts which is a fixed point with respect to these inference rules. And so from all these facts, you can infer the security report that I showed to you earlier. So basically you match the facts against security patterns. So we have a few now and we hope to increase the number in the coming months. So what is important to remember here is that this is fully automated. That is, the only thing you do is at the beginning providing the source code of your contract. And then Securify is going to do all this part and provide you with a security report. And this is easily extensible because you can add new patterns along the way. So in our experience so far it was easy and quite quick to add new patterns because the platform provides sufficient primitives. So our hope is that we won't have to modify Securify that much in the future to provide new patterns. So following this experience with Securify and automated tools to analyze smart contracts, a startup was created in Switzerland to audit blockchains and smart contracts. And the loop is really between auditing contracts and seeing the common patterns and try to extract the routine out of it. And so this releases feedback loop that we try to maintain to develop new tools that will improve on the current state of art. So you can check out the information about chain security if you're interested on this website. So to summarize our presented Securify, which is fully automated, provides strong guarantees. That is, when it tells you that the bug doesn't exist, that it means that it really doesn't exist in your contract. And it's also extensible via a domain-specific language to create new patterns using the primitives already implemented. Following the experience with Securify, chain security was created, a startup that specializes in audit of smart contracts and automated program analysis. And with this, thank you for your attention.