 Hello everyone, I am Subradit Chakraborty and today I will be talking about reverse firewalls for actively secure NPCs. This is a joint work with Stefan Zimboski and Jesper Buznielsen. In the classical setting, we would like to think of two parties Alice and Bob with their private inputs XA and XB and they want to engage in a protocol to produce some outputs YA and YB respectively. And we think of an adversary sitting in the middle and observing the transcript of communication between Alice and Bob and potentially corrupting one of the protocol participants, in this case Bob, to learn some useful information. And we say that this protocol is secure if the adversary cannot cause any harm to Alice even after corrupting Bob and seeing the messages that are exchanging between the two parties. However, in the real world, it's not just Alice who talks to Bob, but it's Alice's trusted computer who implements all the operations in the name of Alice because Alice cannot compute bilinear maps in her head. So this brings us to the question, should Alice trust her computer? The computer looks nice and innocent so far, but one can never be too careful. So in particular, if Alice's trusted computer is replaced with this tampered implementation with red eyes, instead of sending the first legitimate message to Bob, it can just send Alice's password over to Bob and in the second message, send over Alice's credit card number to Bob. Bob might be a bit confused, but our adversary will certainly be happy. While one can argue that this is obviously detectable, but the adversary can be smart and it can use its own encryption key to encrypt this information or leak information steganographically. And this is not only a theoretical prospect or a concern. There has been widespread, apparently accidental bugs in cryptographic software like the poodle, the hurt bleed, Apple's go to failure, the DBN failure, lock jam attacks and so on and so forth. And while these attacks seem to be apparently accidental, unfortunately there has been deliberate corruption of hardware and software that has been done by government agencies. For example, the NSA and we've got to know that cryptographic tools and standards can be subverted. One more recent example is the Chinese chip hack that also infiltrated the hardware and affected the technology supply chain of the US on a massive scale. So this brings us to this line of cryptography, which is called post Snowden cryptography, which asks the following seemingly absurd question. Can we do crypto on tampered machines? In particular, can we get meaningful security for cryptographic protocols in the presence of an adversary who can arbitrarily tamper with the victim's computer? And in fact, there has been a statement by the ICR in Eurocrypt 2014 that much research should be done along these lines and one should develop effective techniques to protect personal privacy against government and corporate overreach. So there has been some prior works addressing these issues, starting with the work of Simons in 1984 on subliminal channels, divertable protocols, cryptography and crypto virology. Unfortunately this line of works kind of died off after the 90s and it was resurrected only after the Snowden revelations and one of the earlier works to address this was the work of Belare Patterson and Rogovay who coined the name Algorithm Substitution Attacks. This mostly studied symmetric encryption in this model and there has been works such as back.prgs by Doddys et al. So this brings us to the second part of the talk about cryptographic reverse firewall. So this model of cryptographic reverse firewall was introduced in Eurocrypt 2015 by Ilya Miranov and Stefan Davidovic. So what is a cryptographic reverse firewall? So we can think of a reverse firewall as an active intermediary or a router that sits between Alice's network and the outside internet represented by Bob here. It is a stateful algorithm that takes as input its current state and some message m and it outputs an updated state and some message m tilde. So in particular we think of the firewall as sitting on the edge of Alice's network and it sees the incoming and outgoing messages that are sent and received by Alice and it modifies these messages. So in particular Alice sends m1 the firewall malls it to m1 tilde, Bob sends m2, firewall malls it to m2 tilde and so on. One important requirement is that it should be transparent to legitimate traffic. So this means that while Alice sends a single message to the firewall, the firewall should send the same message to Bob. So it's not like Alice and the firewall are exchanging 20 messages back and forth. So in that sense Alice should be completely oblivious that there is a firewall sitting on its network. And the most important point is that the firewall shares no secret with Alice. So for example we are not delegating the trust to the firewall. So the firewall is not a trusted third party, it's just a helpful third party as I'll shortly demonstrate. So the properties from such a CRF are as follows functionality preserving. So suppose there is an underlying classical protocol in which Alice and Bob talks and Alice outputs YA and Bob outputs YB. So we want that the protocol with the firewall should not screw up the functionality. So if Alice's implementation is honest, the protocol with the firewall should also allow Alice to output YA and Bob to output YB. So this is extremely straightforward. The second more important property is that of security preservation. So suppose there is an underlying classical protocol that satisfies some security requirement. Say this is modeled by some crazy game in which the adversary corrupts Bob and might have oracle access to multiple copies of Alice and so on. And still the adversary cannot break the security of the protocol. So now we want to say that if there is a firewall and if Alice's implementation is corrupt the security of the protocol will be preserved. So in particular the protocol with the firewall should satisfy the same security requirements X but now Alice's implementation is replaced with any efficient corruption. And we want to say that the adversary also loses in this firewall protocol when it gets access to this firewall diversion of Alice. And here we make a distinction between strong versus weak security preservation which I'll shortly explain. And I want to stress this point that we always assume that there should be a protocol that is functional and secure without the firewall. And the protocols that are not functional in the first place are not interesting. So the types of corruption that we will be considering are suppose there is a classical protocol that satisfies some functionality F and security requirement S. So the first model of corruption is strong corruption where we assume that there is any efficient arbitrary tampering strategy and secondly weak corruption that says that the tampering strategy can be arbitrary as long as it does not break the correctness of the protocol. However, it might still behave arbitrarily a negligible fraction of time. For instance, suppose there is an oblivious transfer protocol in which Bob's first message is uniformly random over some set and Bob learns MB and it should not learn the other message whereas Alice should not learn the bit B. Now it might happen that for a particular choice of the first message of Bob say all zero strings Alice just encodes the XOR of both M0 and M1 into the output represented by Z1 tilde here to Bob. And Bob when it is corrupt can just send this all zero string to learn the XOR of the two messages which otherwise would not have been possible for a secure OT protocol. And the third property that we need is that of exfiltration resistance which says that a corrupt implementation of Alice cannot leak any information to an attacker via the reverse firewall. So in particular in the world above Alice's tampered implementation is clubbed with the firewall and we see this as a joint party and in the second world Alice is honest and is clubbed with the firewall and we want to say that in both these worlds are indistinguishable and again we make a distinction between strong versus weak exfiltration resistance. So when I say strong I'm referring to the strong model of corruption and weak I'm referring to the weak model of corruption and in this case if Bob is corrupt we call security against peer party else we call security against an eavesdropper. So the first work of Miranov and Stephen W. David's constructed reverse firewall for arbitrary two-party protocols via constructing an RF compatible private function evaluation protocol and their techniques used re-randomizable garble circuit and re-randomizable OT. And they also show a general method to compile any protocol to an exfiltration resistant protocol. However the disadvantage is that it recompiles the protocol into the encrypted domain which makes the protocol not transparent. So in the follow up work by Doris Miranov and Stephen W. David's they construct secure message transmission protocol in the RF setting and there is another follow up work which shows how to construct reverse firewalls for functionalities that are realizable by smooth projective hash proof systems. And finally in a recent work Ganesh Magri and Vanchuri shows how to construct CRS for interactive proof system via malleable sigma protocols. So quoting Miranov and Stephen David's from their original paper the holy grail would be a full characterization of functionalities and security properties for which reverse firewall exist. So in this paper we solve this open problem and give a full characterization of such functionalities. In particular we construct multi-party computation with reverse firewall. So in this setting there is a bunch of parties each with their private inputs XI and they want to compute a function F over their inputs. And a subset of these parties can be corrupted by the adversary and we want to say that nothing other than the output should be leaked that is F of XI to XN. And this can be formalized using the real world ideal world paradigm which I will not go into. So in the reverse firewall setting again each of the parties have their own private inputs and a subset of them can be corrupt as before but now the remaining honest parties can also be corrupt albeit in a functionality maintaining way. So we consider all the parties in the MPC protocol can now be corrupted, some subset of them can be corrupted in an arbitrary way as in the original MPC protocol and the remaining honest parties can also be corrupt but in a functionality maintaining way. And for those parties which are corrupted in a functionality maintaining way we replace those parties with the party with the tampered implementation of the parties clubbed with the firewall and we call this parties as this joint parties with a hat. So in particular PI hat is the firewall composed with PI and we want to say that when the parties the honest parties are honest the firewall protocol should not break the functionality. Security preservation says that now when we replace this PI's with PI hats the security property of the MPC protocol should be retained and exfiltration resistance says that for example P3 hat cannot leak any information via the firewall to any other parties and similarly we can define it for P1 hat and P5 hat and so on. So in this paper we construct the first actively secure MPC protocol in this setting and we show a generic compiler that takes any passively secure MPC protocol and compiles it to an actively secure MPC protocol in the RF setting. So the way we do that is we take the GMW compiler and show how to make it reverse firewall compatible. So the main contribution of our work is how to construct a multi-party coin tossing protocol in this setting and finally we show that all these individual building blocks when they are made RF compatible they compose together to give the final actively secure protocol. And as a result of independent interest we also show a compiler for reverse firewall in the broadcast module. So let us just quickly recall ourselves about the blueprint of the GMW compiler. So it takes any semi honest MPC protocol PI and compiles it to PI prime as follows. All the parties first commit to their input by running an input commitment protocol and then the parties fix their random tapes by running a coin tossing protocol and finally they run the parties then run each step of the semi honest MPC protocol and prove in zero knowledge that the computation was correct and is consistent with their committed inputs and their random tapes. And the claim is this this protocol is actively secure by now it is well known. And now to lift this compiler to the reverse firewall setting we need to replace each of this highlighted component into the reverse firewall counterpart. So I will mostly focus on the coin tossing protocol which will give you an idea about the techniques that we use for the rest of the protocols as well. So for that we let us briefly recall ourselves about non-interactive zero knowledge proofs which allows a prover to convince a verifier that he knows a witness without revealing the witness and the completeness is that the honest prover should always convince the verifier if it knows the witness soundness is that the cheating prover cannot convince a verifier if the statement is not in the language. And we want the property of simulation sound extractability which says that even if after seeing many simulated proofs if the adversary comes up with a new proof there is an extractor who can extract a witness and it is easy to see that SSE implies non-malleability. So although we are talking about multi-party coin tossing but let us just consider the case of two parties which will give the ideas behind the coin tossing protocol. So the functionality that we want to achieve is that two parties initially have no inputs and then one party would end up with a uniformly random M bit stream and the other party would get commitment to the string. So this follows by the classical commit and proof paradigm where P1 first samples a string S commits to it and then proves in zero knowledge the commitment is consistent and sends the commitment and the proof to P2. P2 also samples some string S2 and sends this S2 to P1 and then the P1 computes the final string as the XOR of S1 and S2 and commits to this string S and proves in zero knowledge that the initial commitment C1 was also consistent and C is also consistent with the choice of the randomness and the strings S1, S2 and sends this final commitment and proves to P2 and the output of P1 is the XOR of these two strings and the output of P2 is the commitment to the string S. Now let us consider this protocol in the reverse firewall setting, let us consider the case where P2 is corrupt and now P1 is corrupt in a functionality maintaining way. So what can go wrong? First P1 might commit to a bad string S1. Also the randomness R1 that is used to commit to S1 might leak information about the committed element and finally the final commitment proof might also be leaky. Now let us consider the case where P2 is corrupt in a functionality maintaining way, surely it can choose a string S2 that acts as a subliminal channel to trigger some bad behavior of P1. So if we want to construct a coin tossing protocol in the reverse firewall setting we should be able to account for all these facts. So let us see how to do it. So the first idea is that when P1 is corrupt and there is a firewall sitting on top of P1 it should be able to mall the commitment string C1 so as to transform itself into a commitment to a uniformly random string with fresh randomness and it turns out that if we can replace the commitment with any homomorphic commitment scheme which allows for mulling and re-randomization this is sufficient. However, at this point the proof pi1 is no longer a valid proof and for the firewall to maintain the functionality it should be able to mall the proof as well. However, there is one inherent difficulty here since the proof is simulation sound extractable and this implies non-malleability by definition it cannot be mauled by the firewall. And also a bigger problem is that even if the proof is malleable somehow the firewall does not know how to mall it since it does not know the committed string or the witness in the first place. So to resolve this we use the idea we replace the NISIC proof of knowledge or the simulation sound extractable NISIC with a controlled malleable NISIC proof system that I define next. So this was introduced in the paper of chess et al from Europe Group 2012. So this is a NISIC proof system that satisfies completeness and soundness as before and in addition it satisfies malleability which says that given a bunch of proofs valid proofs for some statements there is a public evaluation procedure that takes these statements and proofs and malls it into a valid proof for a transform statement T where T belongs to some class of transformation. Note that ZK eval does not need the witness to compute this valid proof and we want re-randomizability which says that any proof can also be re-randomized in a way that it is indistinguishable from a fresh proof. And we want derivation privacy which says that the output of ZK eval is indistinguishable from the case if the prover was giving a fresh proof on the transform statement and the transform witness. And finally we want the property of control malleable simulation sound extractability which says that even after seeing many simulated proofs if the adversary comes up with a proof pi star for some statement X star there is an extractor who can extract either the witness such attesting to the fact that X star is in the NP language so far this is same as SSNZ but also a tuple such that X star can be explained via this statement X prime and the transformation T such that X prime was previously queried by the adversary and basically it was shown in the paper that assuming decision linear assumption one can instantiate this control malleable physics in particular the grad Sahai proofs are control malleable. So now equipped with this homomorphic commitments and control malleable proof let us see how to do reverse firewall for the coin tossing protocol. So the idea would be the firewall should mall each and every step of the protocol and this is how it does. So after receiving the first C1, pi1 it the firewall computes a fresh commitments on its on its own and homomorphically adds the commitment and defines the transformation to be this homomorphic operation and derives a proof by using this ZK eval algorithm. So in fact you need to re-randomize this proof as well. So first it re-outputs this proof using ZK eval and re-randomizes the proof and sends this to P2. P2 then sends S2 and now the firewall malls S2 by the offset it chose in step one and sends this mall S2 hat to P1 and when P1 sends the final C, pi it also appropriately malls the statement and malls the proof and hands over this proof to P2. So one can show that the output of the coin tossing protocol is consistent. So the firewall did not screw up the functionality and this is quite easy to see. And in our paper we show that if the underlying building blocks satisfy the properties required the firewall satisfies security and exfiltration resistance against P2 in this weak model of corruption. Now the coming to the input commitment protocol. So here the party PI has its input xi and ri and it commits to its input and then proves in zero knowledge the commitment was consistent and the firewall protocol is the idea is very similar. So first the firewall computes a commitment to zero and hands over this and homomorphically computes the commitment and malls the proof and hands over this proof to the other parties. And we also show that the firewall weakly preserves security for P1 and its exfiltration resistance for P1 against P2. So in particular we prove the multi-party version of this theorem. And as the last missing piece we show a reverse firewall for the authenticated computation protocol. Note that after the coin tossing and the input commitment protocol the inputs and the random tapes of each party is fixed and all other parties holds commitment to all other parties inputs and randoms tape and at this point we can just run the passively secured MPC and prove in zero knowledge that each computational step is valid. So for the reverse firewall version of this we just need to re-randomize the proof which we can do using the re-randomizable musics. And we also show that this firewall weakly preserves security for P1 and its exfiltration resistance against any PJ. So finally as a result of independent interest we show how to construct a compiler for reverse firewall for the broadcast model. Note that the assumption of broadcast channels in the RF setting is a stronger assumption than in the classical setting. So we instantiate this using the dollop strong protocol and the main idea would be to transform the dollop strong protocol to a unique message protocol and this we do it by replacing the signatures with unique signatures. So at any point there is a unique choice of the next message that a party can send which is a signature and since it is corrupted in a functionality maintaining way it is forced to send this correct message. And this can be generalized for the class of re-randomizable signatures as well. So to summarize we show the first feasibility result for actively secure MPC in the setting of reverse firewalls. We show how to upgrade the GMW compiler to be made RF compatible and this we do by exploiting the homomorphic properties of the underlying commitment scheme and the control malleability feature of the underlying NISIC argument system. And we prove a generic composability theorem and show a reverse firewall for the broadcast model. So some of the interesting open problems are can we construct more efficient and round optimal MPC in the RF setting say two round MPC in the setting. Can we construct adaptively secure MPC in the RF setting? Also note that since we use non-interactive zero-knowledge proofs we rely on the trusted setup phase. So can we remove the trusted setup assumption? So with this I would like to conclude my talk and one can find the e-print version of our paper with report number 1317. Thank you.