 It's a pleasure to be here to present our work at Tocanomics 2020. So I'm Gabriele Coste, I'm a system professor at IMT School for Advanced Studies in Leucine, Italy. And I'm going to present you our work about the security of, let's say, the security implementation of a reliable and fair back bounty program support system that we are carrying out with my colleagues, Andrea Canidio and Letterio Galletta. So let's start from the problem. The problem is that open source is almost everywhere nowadays. Well, in general code is everywhere, but open source in particular is a very interesting subset of all the code that is outside the world. We use a lot of open source tools like web browsers or entire operating systems like Linux or Android. And also, perhaps more interesting, open source is typically part of larger software that might also be commercial or proprietary software. And another interesting thing is that many security critical utilities are also open software, open source software. The reason is that it is very important to be able to verify the implementation of these systems that are so relevant for so many applications. I mean, all the problem is that the vulnerabilities in open source software are very dangerous because these can affect a lot of systems and may affect the life of citizens. And one might think that verifying open source software can be easier because we have access to the source code, but code verification is not such a simple matter. And authentication is hard in general, even when we have source code. For this reason, we had in the last year, many parties starting bug bounty programs. So the idea behind the bug bounty program is that a certain authority or a certain actor offers bounties. That means they give you a reward if you can find some bugs or errors in a piece of code. The idea is that there are bounty hunters, which are ethical hackers or security experts that spend their time in investigating these vulnerabilities that they can even federate in large groups of ethical hackers. And eventually they disclose these vulnerabilities in order to acquire the bounty that have been the bounties that have been promised by the bounty issuer. And the interesting application of these scenario as is also the new foster project that has been also extended to you foster to that is a bug bounty program for third parties application. So in this project European Union acknowledged that there are several open source projects that are very critical for the European community, and they offered the rewards for people that could find bugs in these very critical software. And that's exactly an example of a bug bounty program that is open. So we are used to think that the bounty issuer is somehow the owner of the code. But when we are referring to open source code, even third parties might be interested in paying a reward for finding bugs. And this is a very interesting market, a growing market, but we have a problem here. The problem is that we have two markets. We have let's say a white market that is the bug bounty market. And we also have the zero day exploit market is what we might call the black market. So zero day exploit can be sold on the deep web. And there are people that can buy these. So you can offer not a vulnerability. So you have found an error in the code, but a way to exploit this error to attack someone or to attack a platform. The problem is that if you can turn your bug into an exploit, the value of your information increases significantly just to make a concrete example for Google Chrome. And if you check on the official bug bounty program, you can aim for $5,000 reward in the best case, but the very same vulnerability that you convert into an exploiter is $300,000 worth. You might think that when you have a vulnerability, it is complex or unusual to turn this into an exploiter, but actually this is not what happens because many bounty issuers before paying for a vulnerability also require for the bounty hunter and evidence of the bug. And the evidence is typically an exploit. So it's very common that when you find a vulnerability you also need to create an exploit to prove that the vulnerability is actually there. And also, when you disclose vulnerability sometimes you have to perform an extra effort, because they might ask you to develop remediation plan, while when you provide an exploit you sell an exploit on the black market nobody asked you to fix the bug. The very last issue, but in our opinion, a very important issue is that bug legibility is decided by the bounty issuer after the bug is disclosed, which gives the bounty hunter very limited bargaining power when they disclose the bug because we apply for a bug bounty. We provide all the information and then eventually the bounty issuer says no, this bug is not eligible, but they already have all the information to replicate and fix the bug. And all of these reasons make the bug bounty market quite inefficient in general, in our opinion, and we also have several evidence, evidence is confirming this problem. So the problem here is that there is no fair information trading, as I said, we, we know that this market suffers for an old problem. And we want to avoid this. The first thing that we have to do is to introduce symmetry in the information exchange protocol. This is a paper by owner and three parts describing how to implement this fair fair trading system by means of a sequence of tests tests are executed to somehow checking the validity of the information that the bounty hunter in this case is going to sell. If these days tests are faster, this means that information has a fair amount of quality, let's say it is good enough to be to be sold and the bounty issuer can actually decide to pay. One of these solutions that there is a total lack of commitment by the two parts. So the bounty issuer and bounty hunter are untrusted might even be anonymous. And they don't trust each other, and they might retreat from the protocol without completing it so trying to get the money without revealing the information, trying to selling fake information, and trying to acquire information without paying for that. But this problem we investigate the possibility of applying the blockchain by means of smart contracts. So the deal is that we want to implement the mechanism for ensuring the commitment of the two parts to smart contracts that are public verifiable and cannot be removed from the blockchain so they provide a commitment by by the one of the two parts. And for the initial disclosure, I will show you something more detailed later on, we will use the same approach of orange creepers. So this is our protocol that we are implementing in various. So we have these two parties the bounty issuer and they come and bounty hunter and they communicate to smart contracts on the blockchain. So the bounty issuer is some party that publishes a smart contract defining what kind of bugs they are interested in and what kind of rewards they plan to pay for that. Then we have bounty hunters that look for bugs and when they find something they can claim the bounty. When this happens, we start what we call the bounty claim protocol that is at the very core of our of our proposal and then going to tell you something more in detail about this. The bounty claim protocol is basically a non chain fair exchange protocol between the bounty issuer and bounty hunter. The bounty hunter starts by sharing what we call a trace commitment, which is an initial description of a failure state that the bounty hunter could obtain to a certain execution. These information is not enough to replicate the execution, but is enough for the bounty issue to evaluate whether whether this is interesting for the point of view of the bug bounty program. This means that bounty sure can check the eligibility of this bug and decide whether or not to start the protocol. So the bounty issue is authorized to retreat from the protocol at this point, but in this case the bounty hunter preserves the information and do not does not share it with anyone. So can sell it somewhere else. And then bounty hunter bounty hunter can even negotiate some parameters that are not very relevant for the execution. But we are also investigating as part of our future work and we tell you something more about for instance the partial world computation method. But let's see the protocol in more detail. So we have the initial commitment that is sent by the bounty hunter to the bounty issuer so from right to left to the blockchain. And then eligibility is compute the and the main part of the protocol is inside this loop and these loop implements a challenge, a challenge response protocol for information disclosure. So the very core is this part of the protocol that I'm discussing more in detail now. First of all, I need to provide you with some information about what the program trace is and what we mean by commitment. The execution trace is a sequence of program states that starts from initial state of the program, typically state where we passed the input for the program. And roughly speaking, each state in the in the trace is just a finite mapping between variables and values. So we might have as in this example that variable X is assigned to 42 while we're variable Y is assigned to true, and so on and so forth. So that an execution trace uniquely identifies a single execution of a program and can be used to repeat that execution. So this is an evidence that something went wrong. This is an evidence if the last state is a faulty state like the very common segmentation fault error that we might have while running a program, but this might be anything so the final state shows highlights the vulnerability, but just by looking at the final state we don't know what was the input for running this program. So commitment in this case is important because we must make sure that the bounty hunter cannot change the trace during the protocol. So as in this picture taken from Ghostbusters, the bounty issue must show that the trace is not changing. So the card is displayed clearly and cannot be modified, but eventually we also need to do the commitment. The commitment means providing a cryptographic secure hash code for the sequence of states. And the commitment means providing a state and we can compare the hash code with the state which is equivalent to showing a certain state of our trace and making a step farther in our session. I'm saying a farther step and not a step forward because what we are doing is executing this backward. The reason is that if we go forward we start from the initial state and the initial state has enough information to replicate the bug with no need for the entire trace. Instead we go from the final state to the initial state. And this is our challenge response loop. So the idea is that the bounty hunter to implement the proof of knowledge protocol where the bounty hunter sells a certain segment of the execution trace. The challenge is published on the smart contractor so that on the blockchain to a smart contract so that the execution of the contract can be invoked by the bounty issue. To put it in a simple way, publishes a contract saying if you can solve this challenge, this means that you know the previous state from which I could reach the next state in the sequence. So we go backward from the final state the arrow state to the initial one. It is very important that the challenge is complex to be solved by someone that doesn't know an actual trace. So we need an NPR problem to be encoded in the smart contract. And we have a good candidate in the form of the satisfiability model theory formulas and the way to generate satisfiability model theory formulas from a program code is through backward symbolic execution. To put it simply, what we do is starting from a certain point in the program, and as the bounty issue computing some constraints about the previous data few steps before, few instructions before, and asking the bounty challenger, if you really know a trace, you know a valid assignment of variables that satisfies this formula. And if you don't know this assignment that you have to compute it right now, and it will take a lot of time. So you can solve this challenger in a reasonable amount of time. So let me make an example, because this technique might be, it's a bit technical. Imagine we have this very simple program that is made by a single function called foo that takes a single variable called C. Okay. C is a chart in C. This means a small integer. The program just check whether this C is greater than zero and increase in that case increases C by one, then creates another variable called D that is where we store the C plus one again, and then eventually we compute X as 42 over D. So imagine that this is our open source, open source project, and someone tells us about the answer tells us I found a division by zero in this program. Okay, so although this program is very simple, it is not immediate to find the value of C that leads to an execution where D is equal to zero. If we are interested in finding division by zero, this is exactly what we need to say, okay, I want to pay for this, provide me with a trace. So let's see how to compute a challenge. With those backwards symbolic execution, which means let us see we want D to be equal to zero, right. So right before doing this division 42 over D, we want D to be equal to zero. But at the previous statement we have that D is equal to C plus one, which means that if we move one step above, we have that C plus one must be equal to zero. Now we have a condition. Well, for condition we have more complex rules that make the formula in trees in size. And what we have is these disjunction where we say that either C is greater than zero and C plus two is equal to zero or C is less or equal to zero and C plus one is equal to zero. And this is our challenge. So what we put on the blockchain is this expression. And we say, I'm ready to pay if you can show me a value of C that satisfies this formula, which is part of a trace. This is just a single step. And this is done in a certain amount of time. So you can take all the time that you want. This is a very simple example, but you might find that this is not so trivial. And if the bounty bounty hunter can exhibit the value that satisfies the formula, then the smart contract automatically pays for that. So we cannot retreat from the protocol after publishing the challenge. And in this case, let's say an honest bounty hunter might show that a possible value is 254. Okay. So, to conclude my talk. Very us is aiming at implementing a fair and reliable market for bug bounty programs also open because on the blockchain everyone can publish bounties. So we can even implement in this way a med campaigns for finding certain families of bugs. We're implementing the contracts in solidity. Some of the contracts are already available. And we still have to do some, some work in particular we are studying equilibria for partial reward, which is not trivial because it depends on the characteristic of the execution trace because we don't want to reveal too much information during the process to avoid the bounty hunter to a leak information that the bounty show might use to retreat from the protocol without paying. So there should be an equilibrium between these two operations. We are evaluating alternatives for the challenge response implementation in particular for computing the challenges with other techniques. And we are also considering the possibility to make a formal verification of this protocol that in our opinion is very important to prove that that the protocol is secure in general. So, and that's everything on my side. Thank you very much.