|
| 1 | +%!TEX root = ../notes.tex |
| 2 | +\section{March 18, 2026} |
| 3 | +\label{20260318} |
| 4 | + |
| 5 | +\subsection{Hardware Secure Module (HSM)} |
| 6 | + |
| 7 | +In Intel SGX, you can do arbitrary computations. However, HSM can only do restricted computations, for example, encryption/decryption. Alice can have an HSM that encrypts a message and she sends the encryption to Bob who has an HSM to decrypt the message. Another example is an HSM that takes in a ciphertext, decrypts it, then re-encrypts it with a new secret key. |
| 8 | + |
| 9 | +This is used in places like Visa and a lot of bank systems. This is because they do not want to store the key anywhere, so that the user can only interact with the HSM like a black box without seeing the key. |
| 10 | + |
| 11 | +\textit{How does an encrypt/decrypt HSM pair agree on a key?} The encrypt HSM (Alice) randomly samples $k_1, k_2, k_3$ such that $k_1 \oplus k_2 \oplus k_3 = k$. Then the 3 of them will be mailed to the decrypt HSM (Bob) using 3 different carriers, and the decrypt HSM will reconstruct the key $k$ on its own. |
| 12 | + |
| 13 | +\subsection{Secure Multi-Party Computation} |
| 14 | + |
| 15 | +\subsubsection{2-Party Computation} |
| 16 | + |
| 17 | +We've seen this before, but it is whensome parties want to compute the output of some function on their individual inputs, without revealing their own inputs. |
| 18 | + |
| 19 | +\begin{example} |
| 20 | + Alice and Bob just returned from a date, and want to figure out if they each want a second date. Alice has some choice bit $x$ and Bob some choice bit $y$. They want to jointly compute $f(x, y) = x\land y$. |
| 21 | +\end{example} |
| 22 | +\begin{example} |
| 23 | + Alice and Bob want to compare riches (who is richer?). They compute |
| 24 | + \[f(x, y) = \begin{cases} |
| 25 | + 0 & \text{if }x>y \\ |
| 26 | + 1 & \text{otherwise} |
| 27 | + \end{cases}\] |
| 28 | +\end{example} |
| 29 | +\begin{example} |
| 30 | + Alice and Bob meet for the first time and want to see if they have friends in common. They have sets of friends $X,Y$, and compute |
| 31 | + \[f(X, Y) = X\cap Y.\] |
| 32 | + There are variants of this which only give cardinality of $X\cap Y$, etc. |
| 33 | +\end{example} |
| 34 | + |
| 35 | +\Graphic{images/2023-03-16/2pc.png}{0.6} |
| 36 | + |
| 37 | +In general, this is when two parties have inputs $x, y$ and want to compute some function $f(x, y)$ on them. |
| 38 | + |
| 39 | +Use cases include: |
| 40 | +\begin{itemize} |
| 41 | + \item Password breach alert (Chrome/Firefox/Azure/iOS Keychain) runs a set intersection on your passwords and server leaked passwords. |
| 42 | + \item Privacy-preserving contact tracing for COVID-19 (Apple and Google). We want to know if we have contact but not who had contact with. |
| 43 | + \item Ads conversion measurements/personalized advertising (Google/Meta). We want to match conversions without either party knowing who converted. |
| 44 | +\end{itemize} |
| 45 | + |
| 46 | +\subsubsection{Multiple Parties!} |
| 47 | +The general case of this is Secure Multi-Party Computation (MPC) |
| 48 | + |
| 49 | +\Graphic{images/2023-03-16/mpc.png}{0.4} |
| 50 | + |
| 51 | +This is when we have some parties $P_i$ and want to compute input on $f(x_i, \cdots, x_n)$. |
| 52 | + |
| 53 | +Here are some applications: |
| 54 | +\begin{itemize} |
| 55 | + \item Privacy-preserving Inventory Matching (J.P. Morgan) |
| 56 | + \item Distributed key management (Unbound/Coinbase) |
| 57 | + \item Federated learning (used in Google Keyboard Search Suggestion). We want to run machine learning, federated amongst multiple devices. However, we don't want to leak the actual training data from users. |
| 58 | + \item Auctions (Danish sugar beet auction). Nobody should reveal their bid in the clear. |
| 59 | + \item Also deployed in Boston area to analyze the wage gap between genders without revealing the individual salaries. |
| 60 | + \item Study/Analysis on Medical Data. Every institution has limited data, but they cannot openly share that data due to regulations. How could they jointly do analysis on this data without revealing the data. |
| 61 | + \item Fraud Detection (banks). Users might have cards at multiple banks, they want to jointly detect fraud but do not want to share their transactions. |
| 62 | +\end{itemize} |
| 63 | + |
| 64 | +When we normally talk about cryptography, we talk about `slowing down' the system (crypto makes everything slower). In the case of MPC, though, we've enabled new features that were not otherwise possible without these tools. |
| 65 | + |
| 66 | +\subsection{Definition} |
| 67 | +Our setting is that we have $n$ parties $P_1, \dots, P_n$ with private inputs $x_1, \dots, x_n$. They want to jointly compute $f(x_1, \dots, x_n)$. |
| 68 | + |
| 69 | +In terms of communication infrastructure: we usually assume point-to-point channels between each pair $(p_i, p_j)$. We know how to do this (key exchange, authenticated encryption, etc). Sometimes, we also assume a reliable broadcast channel where every other party gets information. |
| 70 | + |
| 71 | +There is a single adversary that can ``corrupt'' a subset of the parties (at most $t$). |
| 72 | + |
| 73 | +\emph{What properties do we want out of this system?} Here are some common security properties we might want: |
| 74 | +\begin{description} |
| 75 | + \item[Correctness.] The function is computed correctly. |
| 76 | + \item[Privacy.] Only the output is revealed. |
| 77 | + \item[Independence of Inputs.] Parties cannot choose their inputs depending on others' inputs. |
| 78 | +\end{description} |
| 79 | +Also with security guarantees: |
| 80 | +\begin{description} |
| 81 | + \item[Security with Abort.] The adversary may ``abort'' the protocol. This prevents honest parties from receiving the output. This is the weakest model. |
| 82 | + \item[Fairness.] If one party receives the output, then all parties will receive the output. |
| 83 | + \item[Guaranteed Output Delivery (GOD):] Honest parties \emph{always} receive output. Even if adversarial parties leave, the honest parties will simply continue the protocol. |
| 84 | +\end{description} |
| 85 | + |
| 86 | +We also have some characterizations of adversaries: |
| 87 | +\begin{itemize} |
| 88 | + \item Allowed adversarial behavior: |
| 89 | + \begin{itemize} |
| 90 | + \item Semi-honest (or passive/honest-but-curious): They follow the protocol description honestly, but they try to extract more information by inspecting the transcript. This is the weaker model. |
| 91 | + \item Malicious/active: These adversaries can deviate arbitrarily from protocol description. |
| 92 | + \end{itemize} |
| 93 | + \item Adversary's computing power: |
| 94 | + \begin{itemize} |
| 95 | + \item Unbounded computing power: this gives us information-theoretic (IT) security. |
| 96 | + \item PPT bounded: this gives us computational security. |
| 97 | + \end{itemize} |
| 98 | +\end{itemize} |
| 99 | + |
| 100 | +If you're interested, you can look into the literature of how to define security for MPCs. The idea is similar to that of ZK proofs---everything an adversary can do (see the transcript) can be simulated by a simulator who only has the input and output. |
| 101 | + |
| 102 | + |
| 103 | +\subsubsection{Feasibility Results} |
| 104 | +In the computational security setting, if we have a fundamental building block, a semi-honest oblivious transfer (OT), we can get semi-honest MPC for any function $t<n$. At a high level, using zero-knowledge proofs to enforce correctness of the protocol, we can convert any semi-honest MPC into a malicious MPC. |
| 105 | + |
| 106 | +In terms of information-theoretic (IT) security. We can also get semi-honest and malicious MPC for any function with $t < \frac{n}{2}$. We call this an \ul{honest majority}. This is a necessary bound, we cannot do any better than this. |
| 107 | + |
| 108 | +\subsection{Oblivious Transfer} |
| 109 | +\begin{definition}[Oblivious Transfer] |
| 110 | + An \ul{oblivious transfer} is a protocol in which a sender, with messages $m_0, m_1\in\{0, 1\}^l$ gives a choice to the receiver to receive either $m_0, m_1$. |
| 111 | + |
| 112 | + Given a choice bit from the receiver $b\in\{0,1\}$, the receiver gets $m_b$ and the sender also gets no information about the messeage transferred. |
| 113 | + |
| 114 | + \Graphic{images/2023-03-21/ot.png}{0.6} |
| 115 | +\end{definition} |
| 116 | + |
| 117 | +We'll learn about constructions of OT later, but we black-box its implementation until later. |
| 118 | + |
| 119 | +Using a semi-honest OT, we can use Yao's Garbled Circuit to construct semi-honest 2PC for any function. We can also use the GMW compiler to compile this into a semi-honest MPC for any function. We'll focus on the first approach in this lecture, but we'll learn GMW in the following lectures. |
0 commit comments