 Hello, I'm Benjamin Schlosser, and I'm going to present you the paper Financial-Backed COVID Security, which is a joint work with Sebastian Faust, Kamita Zay and David Kressler. This work belongs to the area of multi-party computation, short MPC. MPC, in general, deals with protocols that allow distressing parties to compute some function on private inputs. And typically, we require the security guarantees, correctness and privacy to hold for these protocols. When analyzing the security of a protocol, we need to specify an adversary model. There are different classes of adversaries. On the one side, there are semi-honest adversaries. These adversaries follow the protocol description as it is described. They try to learn additional information from the interaction with other parties. On the other side, there are malicious adversaries. These adversaries may behave arbitrarily. In particular, they may deviate from the protocol description. While security against malicious adversaries provide a much higher level of security, semi-honest the secure protocols are still way more efficient. As a middle ground between efficiency and security, Aumann and Lindel propose security against covert adversaries. These types of adversaries may deviate arbitrarily from the protocol description, but it is only willing to cheat if it's not getting caught. Let's take a closer look at covert security. The covertly secure protocol needs to guarantee that if there is some malicious party that cheats in the protocol execution, then with a fixed probability called the deterrence factor epsilon, this cheating will be detected. And on the contrary, with probability 1 minus epsilon, cheating will be undetected. The notion was extended by Asharov and Orlandy with the notion of publicly verifiable covert security, short PVC. Here the covertly secure protocol is extended by two algorithm. The blame algorithm takes the view of an honest party as input after cheating is detected and generates a certificate. This certificate is then or can then be passed to any third party which utilizes the judge to verify the validity of the certificate. If it's a valid certificate, then the third party will be convinced about misbehavior of the corrupted party. The definition of PVC defines this judge algorithm as non-interactive. This has the advantage that the certificate can be sent to any third party later on, even if the party does not contribute to the protocol execution at the beginning. The intuition of PVC is that due to the publicly verifiable the deterrent effect should be increased. However, we observed that there is a problem in settings like the internet where party can hide behind digital identities and these identities can easily be changed. Therefore, our goal is to connect detected cheating directly with financial punishment. Our contribution is threefold. First, we present the definition of our new notion called financial backed covert security, short FBC. Then we present construction of FBC protocols. In total, we present three different or constructions for three different classes of protocols. All our constructions benefit from very efficient verification of misbehavior. And as a third aspect, we evaluate our construction and provide benchmark results. Let's start with our notion of financial backed covert security. Here, we extend the model that besides the parties that want to execute some protocol, we have a so-called judge party. Let me emphasize that this is different to the judge algorithm of a PVC protocol. Here, we have a party that may interact with other parties. At the beginning, all parties send some coins to this judge party, which are kind of security deposits. Then the parties execute covertly secure protocol. Here, the judge does not need to contribute. Afterwards, the algorithm can use the blame algorithm. So each party can, each honest party can execute the blame algorithm for himself using his view as an input to check if the other party was maliciously during the execution. In case there is no malicious behavior detected, the parties execute a so-called punish protocol, which due to no cheating happened, just inspect the security deposits to the other parties, to the honest parties. So in case there is a malicious party, then due to covertly secure protocol, the blame algorithm will detect cheating with a fixed probability. In this case, the output of the blame algorithm will be some certificate that is used as input to the punish protocol. At the end of the punish protocol, which might require interaction between parties, the security deposits are only sent back to the honest parties. The security deposits of the malicious party will be burnt. We require two security properties of FPC protocols. The first one is called financial accountability. It states that if an honest party detects cheating, then there exists also a corrupted party that doses its deposit. The second property is called financial defamation freeze. It states that the adversary cannot force an honest party to lose its deposits. While these security properties are analog to PVC protocols, we are the first to present formal security games for both properties. We now turn to the question, how to instantiate a judge party? While the definition in general allows that just a single party act as a judge, our construction utilizes blockchain technologies. This way, instead of putting trust into a single party, we need to trust the correctness of the system, which is based on an honest majority assumption. In addition, blockchain technologies have several advantages properties. First one is that for most of the blockchain technologies, an integral part is to maintain ledger where parties possess some coins and can transfer these coins between them. The second aspect is that many blockchain technologies allow the execution of so-called smart contracts. These are small programs which enable money transfer based on predefined rules. Therefore, our construction on a high level work that at the beginning, the party sent a security deposit to a smart contract. Then the parties executed a covalent security protocol. Next, in case there is some cheating detected, the parties engage in a punishment protocol where others can use the certificate as input and if there was some cheating, then only the honest party gets this money back. Here we need to take special care of the complexity of the punish protocol or to be precise of the judge party in the punish protocol because for every information that needs to be stored on the smart contract and every operation that needs to be executed on the smart contract, we need to pay fees. For example, for Ethereum, we need to pay in gas. Before heading to over construction, let me first introduce or mention an important building block we use throughout our construction and this is a Merkle tree. A Merkle tree allows to commit to a set of data chunks here, x1 to x8 and the Merkle tree root constitutes a commitment on all of these values. In addition, it's easy or it's efficiently possible to prove that a specific data chunk is indeed part of the Merkle tree. To this, we create a so-called Merkle proof which consists of all these hash values that are siblings of these values that sit on the path from the data chunk to the Merkle tree root. This allows to create a Merkle proof with only logarithmic many values where n is the number of data chunks. Our first construction yield an input independent protocol. Such a protocol can be used for the offline phase or the pre-commutation phase of so-called offline online protocols for example, speeds and authenticated garbling. These offline protocol works on a high level that they use an offline protocol where the parties only use some random values as input to set up some correlated randomness. Then this correlated randomness can be used to speed up the online phase where the party actually use their inputs to get the output of the functional evaluation. Here, the first part is totally independent of the secret inputs of the parties. We now take a look how can we construct such an F, how can we construct an FVC protocol for such an input independent protocol? As a starting point, we start with a semi-honest version of this online protocol. Then we use the cut and choose and porch which means we execute not just once the semi-honest offline version, offline protocol. We execute it several times where the party uses different random values as input. Then at the end of the cut and choose, in the opening phase of cut and choose, we open all but one of these instances. For all the open instances, we reveal the inputs that are used so that we can verify if the parties behave correctly in this execution. Since we leaked the inputs in these phases, we have to throw them away. However, there is still one instance left which can be used for the online execution. As a next key feature, we require that the behavior of the parties throughout the protocol execution are deterministic based on the random values used as inputs. This can easily be achieved by deriving all random choices from these random inputs. As a next key feature, we require that the parties sign a public transcript after the protocol execution but before the opening phase of the cut and choose protocol. And as a fourth feature, we require that for all the opened instances, the parties obtain a publicly verifiable initial state or publicly verifiable inputs. This can easily be achieved by first sending sign commitment at the beginning and then in the opening phase of the cut and choose, the parties get no decommitment values for the other parties' inputs. All of these key features are already provided by known input independent PVC protocols. In particular, there exists generic compilers from semi-unsecurity to PVC security which also provide these features. So we can directly use such a PVC protocol and transform it into an FPC protocol. Our natural question is, is it just possible to take the judge algorithm of a PVC protocol and let it run by the judge party of the FPC protocol? To see the problem with this approach, let's have a closer look at the verification of just a single instance. So to verify, we start, each party starts the protocol execution within some initial state. For input independent protocols, this initial state just constitutes exists of the random value you set input. Next, all, next the behavior in each round can be computed using some compute round function. This function takes as input a state of the previous round together with a set of message that were received in the previous round. Since there are no message received before round one, we start with an empty set. The function computes an updated state together with a set of messages. In this case, only one message that are sent to the other parties. So next they exchange messages and they perform the same step again. All random choices that need to be done in this compute round function can be derived from the state. So this means that the compute round function is totally deterministic. This is necessary to allow for verification data on. Now verification works that given the stage and all messages that were received by some party, we can recompute to compute round function for each round of this party. And then we can compare the message that were sent during the real protocol execution with the message that should be had been sent. And most of the known PVC protocol in particular, these ones that can be obtained using the generic compilers require that a third party recomputes the whole protocol execution to detect cheating. And this is not plausible for smart contracts because protocol execution might require too much computational effort. So instead we extend, we use the same formalization. So we use the compute round function which on input the state and the set of message, compute an updated state and set of messages. And now when Alice wants to send a message to Bob in the first round, it sends the message that is intended to Bob together with a set of hashes where each message that is sent to some other party is hashed and then the set of hashes is given to Bob. This is an explicit way how to formalize the public transcript property. And finally, we add a commitment on the intermediate states in the form of a hash of this stage. The same is done by Bob. And after the last round, all the message hashes are used to compute a Merkle tree as we have seen before. And then the parties exchange signatures on the roots of these hashes. This is done for the message hashes as well as for the states. We can order the message and the states in such a way that ordering is unique and all the parties sign the same roots. Now what does it help to have these intermediate commitments on the intermediate states? So now take a look at how can Bob check if Alice behaves correctly or behave correctly? So Bob knows for all rounds, the messages that were sent by Alice to Bob together with the hashes of the messages that were sent from Alice to some other parties and the intermediate state commitments. In addition, it knows signatures on the roots of the Merkle trees over the hashes, the message hashes and the states. And due to the publicly verifiable initial state property, we also have the state, the initial state of some party of all parties. And then Bob can recompute all messages that should have been sent by Alice together with the intermediate states. Now let's assume Bob detects some malicious behavior. For example, Bob detects that Alice sent to some party M in round K, an incorrect message. This means that all messages before this message are correct, but then this is the first message that is incorrect. And this message is also part of the public transcript, which was signed or where the Merkle tree root was signed by Alice. Now in the punishment protocol, Bob can create a certificate and send this one to the judge where the certificate contains the signatures on the commitments on the message hashes together with the states. So the signature on the Merkle tree root for the states. The state of the previous round of Alice, so for round K minus one together with all messages that were received in round K minus one by Alice and the incorrect message. Now the last three components are all sent together with Merkle proofs. These Merkle proofs show that the messages and the state are indeed part of the Merkle trees that were assigned by Alice. And now after checking that the signatures and the Merkle proofs are correct, the judge can execute this compute round function based on the previous state. So state of the after round K minus one and the messages that were received to obtain the messages that should have been sent by Alice and round K. And finally, the judge can make the check whether this message is correct or not. So whether the send message was the right one or not. So let me emphasize that here, although our punishment protocol in general allows to be interactive here, we can non-interactively send the certificate. In addition, we just require the judge to compute a single step of the protocol execution. So this is way more efficient than most of the known PVC protocols. We then have a second construction which yields dependent protocols. And here the parties directly use the secret inputs for the computation. So we need to take special care that the privacy of these secret inputs is still guaranteed. For details, I'd like to refer to our paper. So next we had the question. So that all PVC or non-PVC protocol as well as the construction one and two require that after the execution of the semi-honest protocols, the parties need to agree on a protocol transcript. So we had the question, can we relax on this requirement? This can we construct FPC protocols without any form of public transcript. This would reduce the communication cost for the honest execution. We answer this question with yes for the input independent case. And here we exploit the interactivity of the punishment protocol. So let me show up this picture again. We had before for the input independent case and now we just removed the public transcript property. And yeah, we can obtain such a protocol from taking the PVC protocol with public transcript and just removing the public transcript property. Now in case we only have two parties, we always have a common transcript because messages are either sent or received. So we need to take a look at more than two parties to see what are the challenges. So let me give you this scenario here. Here we have an honest execution between three parties in round K. Alice sends a message to Bob and about this message Bob learns no information. So no information is given to Charlie about this, even not a hash of it. Then in the next round in the round K plus one, Bob sends a message to Charlie. And this message now depends on all previously received message. So also on the message sent from Alice to Bob in round K. Now let's assume that Alice is malicious. Then he might send an incorrect message in round K and although Bob behaves correctly, the message M' now looks incorrectly from the point of view of Charlie. So how can we prevent that Charlie now accuses Bob of being malicious to this? To this end, we introduce a two-phase punish protocol where all parties first submit accusations and then only the first accusation. So the one that claims the earliest message that is incorrect will be verified later on. So this way we identify one accuser and one blame party. And then the second question is, since we have no publicly signed transcript, how can we provide information about the messages to the judge party? And for this, one of the parties first suggests message history in case they agree, then the judge can use this message history in case they do not agree, we use the so-called bisection protocol. This bisection protocol is an interactive protocol between these two parties and allow them to narrow down the disagreement to just a single message or the first message on which they disagree in the message history. And then the judge can again re-compute only a single round to identify which of these parties were maliciously. So what's more, for all of our three constructional we provide formal security proofs. Moreover, even we require that the judge just to perform a single round, we could even improve more. That is, we can lower the requirements on the judge such that it only needs to re-compute a single gate of an arithmetic circuit. Here we need interaction between the parties so we can apply this extension to all our construction. However, if we apply it for the first and the second construction, then these construction will also require an interactive punish protocol. And as a third aspect, we implemented a smart contract in Solidity and we measured the gas costs to make an efficiency evaluation and providing benchmark results. So as a conclusion, we consider our FPC construction and notion to have several advantages over PVC. In particular, we think that the effectiveness of the deterrence is increased because now we directly link and detect the cheating with financial punishment. Then we improve on the computation costs of the judge by requiring only to re-execute a single step or even a single gate gauge of the whole protocol. And finally, we lower the communication costs in the honest execution by relaxing on the requirement of the public transcript. Thank you very much for your attention. If you have any question, feel free to get in contact with my colleague, David, or myself. Thank you.