Software Obfuscation

Let us stop and think of the notions we have seen in cryptography. We have seen that under reasonable computational assumptions (such as LWE) we can achieve the following:

• CPA secure private key encryption and Message Authentication codes (which can be combined to get CCA security or authenticated encryption)- this means that two parties that share a key can have virtual secure channel between them. An adversary cannot get any additional information beyond whatever is her prior knowledge given an encryption of a message sent from Alice to Bob. Moreover, she cannot modify this message by even a single bit. It’s lucky we only discovered these results from the 1970’s onwards— if the Germans had used such an encryption instead of ENIGMA in World War II there’s no telling how many more lives would have been lost.

• Public key encryption and digital signatures that enable Alice and Bob to set up such a virtually secure channel without sharing a prior key. This enables our “information economy” and protects virtually every financial transaction over the web. Moreover, it is the crucial mechanism for supplying “over the air” software updates to smart devices, whether they be phones, cars, thermostats or anything else. Some had predicted that this invention would change the nature of our form of government to crypto anarchy and while this may be hyperbole, governments everywhere are worried about this invention.

• Hash functions and pseudorandom functions enable us to create authentication tokens for deriving one-time passwords out of shared keys, or deriving long keys from short passwords. They are also useful as a tool in a password based key exchange, which enables two parties to communicate securely (with fairly good but not overwhelming probability) when they share a 6 digit PIN, even if the adversary can easily afford much much more than \(10^6\) computational cycles.

• Fully homomorphic encryption allows computing over encrypted data. Bob could prepare Alice’s taxes without knowing what her income is, and more generally store all her data and perform computations on it, without knowing what the data is.

• Zero knowledge proofs can be used to prove a statement is true without revealing why its true. In particular since you can use zero knowledge proofs to prove that you posses X bitcoins without giving any information about their identity, they have been used to obtain fully anonymous electronic currency.

• Multiparty secure computation are a fully general tool that enable Alice and Bob (and Charlie, David, Elana, Fran, etc.) to perform any computation on their private inputs, whether it is to compute the result of a vote, a second-price auction, privacy-preserving data mining, perform a cryptographic operation in a distributed manner (without any party ever learning the secret key) or simply play poker online without needing to trust any central server.

(BTW all of the above points are notions that you should be familiar and be able to explain what are their security guarantees if you ever need to use them, for example, in the unlikely event that you ever find yourself needing to take a cryptography final exam…)

While clearly there are issues of efficiency, is there anything more in terms of functionality we could ask for? Given all these riches, can we be even more greedy?

It turns out that the answer is yes. Here are some scenarios that are still not covered by the above tools:

Witness encryption

Suppose that you have uncovered a conspiracy that involves very powerful people, and you are afraid that something bad might happen to you. You would like an “insurance policy” in the form of writing down everything you know and making sure it is published in the case of your untimely death, but are afraid these powerful people could find and attack any trusted agent. Ideally you would want to publish an encrypted form of your manuscript far and wide, and make sure the decryption key is automatically revealed if anything happens to you, but how could you do that? A UA-secure encryption (which stands for secure against an Underwood attack) gives an ability to create an encryption \(c\) of a message \(m\) that is CPA secure but such that there is an algorithm \(D\) such that on input \(c\) and any string \(w\) which is a (digitally signed) New York Times obituary for Janine Skorsky will output \(m\).

The technical term for this notion is witness encryption, by which we mean that for every circuit \(F\) we have an algorithm \(E\) that on input \(F\) and a message \(m\) creates a ciphertext \(c\) that is CPA secure, and there is an algorithm \(D\) that on input \(c\) and some string \(w\), outputs \(m\) if \(F(w)=1\). In other words, instead of the key being a unique string, the key is any string \(w\) that satisfies a certain condition. Witness encryption can be used for other applications. For example, you could encrypt a message to future members of humanity, that can be decrypted only using a valid proof of the Riemann Hypothesis.

Deniable encryption

Here is another scenario that is seemingly not covered by our current tools. Suppose that Alice uses a public key system \((G,E,D)\) to encrypt a message \(m\) by computing \(c=E_e(m,r)\) and sending \(c\) to Bob that will compute \(m=D_d(c)\). The ciphertext is intercepted by Bob’s archenemy Freddie Baskerville Ignatius (or FBI for short) who has the means to force Alice to reveal the message and as proof reveal the randomness used in encryption as well. Could Alice find, for any choice of \(m'\), some string \(r'\) that is pseudorandom and for which \(c\) equals \(E_e(m',r')\)? An encryption scheme with this property is called deniable, since we Alice can deny she sent \(m\) and claim she sent \(m'\) instead.¹

Functional encryption

It’s not just individuals that don’t have all their needs met by our current tools. Think of a large enterprise that uses a public key encryption \((G,E,D)\). When a ciphertext \(c=E_e(m)\) is received by the enterprise’s servers, it needs to be decrypted using the secret key \(d\). But this creates a single point of failure. It would be much better if we could create a “weakened key” \(d_1\) that, for example, can only decrypt messages related to sales that were sent in the date range X-Y, a key \(d_2\) that can only decrypt messages that contain certain keywords, or maybe a key \(d_3\) that only allows to detect whether the message encoded by a particular ciphertext satisfies a certain regular expression.

This will allow us to give the key \(d_1\) to the manager of the sales department (and not worry about her taking the key with her if she leaves the company), or more generally give every employee a key that corresponds to his or her role. Furthermore, if the company receives a subpoena for all emails relating to a particular topic, it could give out a cryptographic key that reveals precisely these emails and nothing else. It could also run a spam filter on encrypted messages without needing to give the server performing this filter access to the full contents of the messages (and so perhaps even outsource spam filtering to a different company).

The general form of this is called a functional encryption. The idea is that for every function \(f:\{0,1\}^*\rightarrow\{0,1\}^*\) we can create a decryption key \(d_f\) such that on input \(c= E_e(m)\), \(D_{d_f}(c)=f(m)\) but \(d_f\) cannot be used to gain any other information on the message except for \(f(m)\), and even if several parties holding \(d_{f_1},\ldots,d_{f_k}\) collude together, they can’t learn more than simply \(f_1(m),\ldots,f_k(m)\). Note that using fully homomorphic encryption we can easily transform an encryption of \(m\) to an encryption of \(f(m)\) but what we want here is the ability to selectively decrypt only some information about the message.

The formal definition of functional encryption is the following:

The software patch problem

It’s not only exotic forms of encryption that we’re missing. Here is another application that is not yet solved by the above tools. From time to time software companies discover a vulnerability in their products. For example, they might discover that if fed an input \(x\) of some particular form (e.g., satisfying a regular expression \(R\)) to a server running their software could give an adversary unlimited access to it. In such a case, you might want to release a patch that modifies the software to check if \(R(x)=1\) and if so rejects the input. However the fear is that hackers who didn’t know about the vulnerability before could discover it by examining the patch and then use it to attack the customers who are slow to update their software. Could we come up for a regular expression \(R\) with a program \(P\) such that \(P(x)=1\) if and only if \(R(x)=1\) but examining the code of \(P\) doesn’t make it any easier to find some \(x\) satisfying \(R\)?

Software obfuscation

All these applications and more could in principle be solved by a single general tool known as virtual black-box (VBB) secure software obfuscation. In fact, such an obfuscation is a general tool that can also be directly used to yield public key encryption, fully homomorphic encryption, zero knowledge proofs, secure function evaluation, and many more applications.

We will now give the definition of VBB secure obfuscation and prove the central result about it, which is unfortunately that secure VBB obfuscators do not exist. We will then talk about the relaxed notion of indistinguishablity obfuscators (IO) - this object turns out to be good enough for many of the above applications and whether it exists is one of the most exciting open questions in cryptography at the moment. We will survey some of the research on this front.

Let’s define a compiler to be an efficient (i.e., polynomial time) possibly probabilistic map \(\mathcal{O}\) that takes a Boolean circuit \(C\) on \(n\) bits of input and outputs a Boolean circuit \(C'\) that also takes \(n\) input bits and computes the same function; i.e., \(C(x)=C'(x)\) for every \(x\in\{0,1\}^n\). (If \(\mathcal{O}\) is probabilistic then this should happen for every choice of its coins.) This might seem a strange definition, since it even allows the trivial compiler \(\mathcal{O}(C)=C\). That is OK, since later we will require additional properties such as the following:

(Note that the distributions above are of a single bit, and so being indistinguishable simply means that the probability of outputting \(1\) is equal in both cases up to a negligible additive factor.)

Applications of obfuscation

The writings of Diffie and Hellman, James Ellis, and others that thought of public key encryption, shows that one of the first approaches they considered was to use obfuscation to transform a private-key encryption scheme into a public key one. That is, given a private key encryption scheme \((E,D)\) we can transform it to a public key encryption scheme \((G,E',D)\) by having the key generation algorithm select a private key \(k\leftarrow_R\{0,1\}^n\) that will serve as the decryption key, and let the encryption key \(e\) be the circuit \(\mathcal{O}(C)\) where \(\mathcal{O}\) is an obfuscator and \(C\) is a circuit mapping \(c\) to \(E_k(c)\). The new encryption algorithm \(E'\) takes \(e\) and \(c\) and simply outputs \(e(c)\).

These days we know other approaches for obtaining public key encryption, but the obfuscation-based approach has significant additional flexibility. To turn this into a fully homomorphic encryption, we simply publish the obfuscation of \(c,c' \mapsto D_k(c) ~\ensuremath{\mathit{NAND}}~ D_k(c')\). To turn this into a functional encryption, for every function \(f\) we can define \(d_f\) as the obfuscation of \(c \mapsto f(D_k(c))\).

We can also use obfuscation to get a witness encryption: to encrypt a message \(m\) to be opened using any \(w\) such that \(F(w)=1\), we can obfuscate the function that maps \(w\) to \(m\) if \(F(w)=1\) and outputs error otherwise. To solve the patch problem, for a given regular expression we can obfuscate the function that maps \(x\) to \(R(x)\).

Impossibility of obfuscation

So far, we’ve learned that in cryptography no concept is too fantastic to be realized. Unfortunately, VBB secure obfuscation is an exception:

Proof of impossibility of VBB obfuscation

We will now show the proof of Theorem 20.3. For starters, note that obfuscation is trivial for learnable functions. That is, if \(F\) is a function such that given black-box access to \(F\) we can recover a circuit that computes it, then we can obfuscate it. Given a circuit \(C\), the obfuscator \(\mathcal{O}\) will simply use it as a black box to learn a circuit \(C'\) that computes the same function and output it. Since \(\mathcal{O}\) itself only uses black box access to \(C\), it can be trivially simulated perfectly. (Verifying that this is indeed the case is a good way to make sure you followed the definition.)

However, this is not so useful, since it’s not hard to see that all the examples above where we wanted to use obfuscation involved functions that were unlearnable. But it already suggests that we should use an unlearnable function for our negative result. Here is an extremely simple unlearnable function. For every \(\alpha,\beta\in\{0,1\}^n\), we define \(F_{\alpha,\beta}:\{0,1\}^n\rightarrow\{0,1\}^n\) to be the function that on input \(x\) outputs \(\beta\) if \(x=\alpha\) and otherwise outputs \(0^n\).

Given black box access for this function for a random \(\alpha,\beta\), it’s extremely unlikely that we would hit \(\alpha\) with a polynomial number of queries and hence will not be able to recover \(\beta\) and so in particular will not be able to learn a circuit that computes \(F_{\alpha,\beta}\).²

This function already yields a counterexample for a stronger version of the VBB definition. We define a strong VBB obfuscator to be a compiler \(\mathcal{O}\) that satisfies the above definition for adversaries that can output not just one bit but an arbitrary long string. We can now prove the following:

The adversary in the proof of Lemma 20.4 does not seem very impressive. After all, it merely printed out its input. Indeed, the definition of strong VBB security might simply be an overkill, and “plain” VBB is enough for almost all applications. However, as mentioned above, plain VBB is impossible to achieve as well. We’ll prove a slightly weaker version of Theorem 20.3:

(To get the original theorem from this, note that if VBB obfuscation exists then we can transform any private key encryption into a fully homomorphic public key encryption.)

Indistinguishability obfuscation

The proof can be generalized to give private key encryption for which the transformation to public key encryption would be insecure, and many other such constructions. So, this result might (and indeed to a large extent did) seem like a death blow to general-purpose obfuscation. However, already in that paper we noticed that there was a variant of obfuscation that we could not rule out, and this is the following:

It is a good exercise to understand why the proof of the impossibility result above does not apply to rule out IO. Nevertheless, a reasonable guess would be that:

1. IO is impossible to achieve.

2. Even if it was possible to achieve, it is not good enough for most of the interesting applications of obfuscation.

However, it turns out that this guess is (most likely) wrong. New results have shown that IO is extremely useful for many applications, including those outlined above. They also gave some evidence that it might be possible to achieve. We’ll talk about those works in the next lecture.

Comments

Comments are posted on the GitHub repository using the utteranc.es app. A GitHub login is required to comment. If you don't want to authorize the app to post on your behalf, you can also comment directly on the GitHub issue for this page.

Compiled on 11/17/2021 22:36:16

Copyright 2021, Boaz Barak.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Produced using pandoc and panflute with templates derived from gitbook and bookdown.