335 lines
15 KiB
TeX
335 lines
15 KiB
TeX
\documentclass[11pt,a4paper,notitlepage,twoside]{report}
|
|
\usepackage[ngerman, english]{babel}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage[a4paper, top=3cm, bottom=3.5cm, inner=3.5cm, outer=5cm, marginpar=3.8cm]{geometry}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage{amssymb}
|
|
\usepackage{amsmath}
|
|
\usepackage{listings}
|
|
\usepackage{eurosym}
|
|
\usepackage{wasysym}
|
|
\usepackage{extdash}
|
|
\usepackage{amsthm}
|
|
\usepackage{mwe}
|
|
\usepackage{tabularx}
|
|
\usepackage{multirow}
|
|
\usepackage{multicol}
|
|
\usepackage{tikz}
|
|
\usepackage{mathtools}
|
|
\usepackage{setspace}
|
|
\usepackage{titlesec}
|
|
\usepackage{fancybox}
|
|
\usepackage{fancyhdr}
|
|
\usepackage[binary-units,per-mode=fraction]{siunitx}
|
|
\usepackage[hidelinks]{hyperref}
|
|
\usepackage{commath}
|
|
\usepackage{graphicx,color}
|
|
\usepackage{ccicons}
|
|
\usepackage{subcaption}
|
|
\usepackage{float}
|
|
\usepackage{footmisc}
|
|
\usepackage{array}
|
|
\usepackage[underline=false]{pgf-umlsd}
|
|
\usetikzlibrary{calc}
|
|
\usepackage{epstopdf}
|
|
\usepackage{pdfpages}
|
|
\usepackage{etoolbox}
|
|
\usepackage{catchfile}
|
|
\usepackage{minitoc}
|
|
\usepackage{minted} % pygmentized source code
|
|
%\usepackage[pdftex]{graphicx,color}
|
|
%\usepackage{showframe} % Useful for page layout debugging
|
|
|
|
\DeclareSIUnit{\baud}{Bd}
|
|
|
|
\DeclarePairedDelimiter{\ceil}{\lceil}{\rceil}
|
|
\DeclarePairedDelimiter{\paren}{(}{)}
|
|
|
|
\usepackage[
|
|
backend=biber,
|
|
style=numeric,
|
|
natbib=true,
|
|
url=false,
|
|
doi=true,
|
|
eprint=false,
|
|
% Make the split online / other resource bibliographies behave
|
|
defernumbers=true,
|
|
]{biblatex}
|
|
\addbibresource{../main.bib}
|
|
\DeclareSourcemap{
|
|
\maps[datatype=bibtex]{
|
|
\map{
|
|
\step[fieldsource=doi,final]
|
|
\step[fieldset=isbn,null]
|
|
\step[fieldset=issn,null]
|
|
\step[fieldset=url,null]
|
|
}
|
|
\map{
|
|
\step[fieldsource=isbn,final]
|
|
\step[fieldset=issn,null]
|
|
\step[fieldset=url,null]
|
|
}
|
|
}
|
|
}
|
|
|
|
\renewcommand{\thesection}{\arabic{section}}
|
|
\renewcommand{\thesubsection}{\arabic{section}.\arabic{subsection}}
|
|
\renewcommand{\thesubsubsection}{\arabic{section}.\arabic{subsection}.\arabic{subsubsection}}
|
|
|
|
% Re-define heading formats to force single line spacing
|
|
\titleformat{\section}{\normalfont\large\bfseries\singlespacing}{\thesection}{1em}{}
|
|
\titleformat{\subsection}{\normalfont\large\bfseries\singlespacing}{\thesubsection}{1em}{}
|
|
\titleformat{\subsubsection}{\normalfont\large\bfseries\singlespacing}{\thesubsubsection}{1em}{}
|
|
|
|
\newcommand{\degree}{\ensuremath{^\circ}}
|
|
\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
|
|
\definecolor{todoboxcolor}{RGB}{251 224 252}
|
|
|
|
\pagestyle{fancy}
|
|
|
|
\fancyhead[C]{}
|
|
\fancyhead[ER]{\footnotesize%
|
|
\ifdefined\thesispreviewmode %
|
|
(draft \texttt{\input{version.tex}\unskip}) %
|
|
\fi %
|
|
\leftmark}
|
|
\fancyhead[OL]{\footnotesize\rightmark}
|
|
\fancyhead[EL,OR]{\thepage}
|
|
|
|
\fancyfoot[LCR]{}
|
|
|
|
\fancypagestyle{plain}{%
|
|
\fancyhf{}%
|
|
\renewcommand{\headrulewidth}{0pt}%
|
|
\renewcommand{\footrulewidth}{0pt}%
|
|
}
|
|
|
|
\raggedbottom
|
|
|
|
\renewcommand{\chaptermark}[1]{\markboth{Chapter \thechapter: #1}{}}
|
|
\renewcommand{\sectionmark}[1]{\markright{\thesection\ #1}}
|
|
\addtolength{\headwidth}{\marginparsep}
|
|
\addtolength{\headwidth}{\marginparwidth}
|
|
\addtolength{\headwidth}{-1cm}
|
|
|
|
\newcommand{\todo}[1]{
|
|
\ifdefined\thesispreviewmode
|
|
\marginpar{
|
|
\setlength{\fboxsep}{2mm}
|
|
\shadowbox{
|
|
\parbox{3cm}{
|
|
\singlespacing
|
|
\raggedright
|
|
\textsf{
|
|
\small\textbf{To do}\\
|
|
\footnotesize#1
|
|
}
|
|
}
|
|
}
|
|
}
|
|
\fi
|
|
}
|
|
|
|
\newcommand{\todoplaceholder}[1]{\textbf{TODO}\todo{#1}}
|
|
|
|
% https://tex.stackexchange.com/questions/30720/footnote-without-a-marker
|
|
\newcommand\blfootnote[1]{%
|
|
\begingroup
|
|
\renewcommand\thefootnote{}\footnote{#1}%
|
|
\addtocounter{footnote}{-1}%
|
|
\endgroup
|
|
}
|
|
|
|
\newcommand{\figurepath}{figures}
|
|
\graphicspath{{\figurepath}}
|
|
\newcommand{\figureattrib}[1]{%
|
|
\input{\figurepath/#1.latex_meta} %
|
|
\scriptsize
|
|
\ifdefined\thesispreviewmode\resourcestate\ \resourcescale\\\fi%
|
|
Resource: %
|
|
\texttt{\resourcerepo/\resourcepath} %
|
|
rev \texttt{\resourcerev} %
|
|
(\underline{\href{\resourceurl}{link}})%
|
|
}
|
|
|
|
\newcommand{\draftgraphics}{\ifdefined\thesispreviewmode\textcolor{red}{\bfseries Not final graphics. }\fi}
|
|
\newcommand{\camerareadygraphics}{\ifdefined\thesispreviewmode Camera-ready graphics. \fi}
|
|
\newcommand{\scaledgraphics}[1]{\ifdefined\thesispreviewmode scaled-#1\else#1\fi}
|
|
|
|
\newcommand{\imgsource}[4]{\scriptsize%
|
|
Image source: #1, #2 (\underline{\href{#4}{link}}). %
|
|
Licensed #3.}
|
|
|
|
\hyphenation{a-me-na-ble}
|
|
|
|
\begin{document}
|
|
\dominitoc
|
|
\faketableofcontents
|
|
|
|
\chapter{Multiparty Computation in Scalable Hardware Security Modules}
|
|
\ifdefined\thesispreviewmode
|
|
{\Large \textbf{Draft build}, git revision \texttt{\input{version.tex}}}
|
|
\fi
|
|
\minitoc
|
|
\newpage
|
|
\setstretch{1.3}
|
|
|
|
\section{Fast MPC and Slow HSMs}
|
|
|
|
Multiparty Computation (MPC) is a cryptographic construct that allows several networked parties to jointly perform a
|
|
computation in such a way that the inputs to the computation remain private to the parties providing them, and no single
|
|
party must be trusted for the computation to produce the correct result. Conceptually, MPC is similar to a secret
|
|
sharing scheme that shares computation instead of data between untrusted parties. The computation primitive MPC offers
|
|
is a cryptographic answer to the issue of bootstrapping trust in a computing system.
|
|
|
|
%The most challenging scenarios in computing arise when multiple
|
|
%parties such as manufacturers and operators, servers and clients, or sellers and buyers need to interact through
|
|
%computation. In many practical situations, it is impossible to create a single computer that can be trusted by every
|
|
%participant. MPC is a generic solution to a multitude of such scenarios reducing the problem of creating a single,
|
|
%shared computer everyone can trust simultaneously to everyone creating their own computer that they only can trust.
|
|
|
|
We can deconstruct the problem of trust in computing into two largely disjunct parts: Establishing trust in a computing
|
|
system during its creation is one, and maintaining this trust throughout its life is the other. For the second part of
|
|
this problem, maintaining trust in a system once trusted, we have an ample supply of good methods such as encryption,
|
|
authentication, and formally proven protocols. In contrast, establishing trust in a computing system is largely
|
|
intractable and despite a large corpus of academic research on approaches such as hardware trojan detection and
|
|
physicaly unclonable functions, only two approaches find practical adoption: In one, we build the system ourselves from
|
|
the ground up, making sure to leave no part vulnerable to third-party compromise. In the other, we arbitrarily buy a
|
|
computer from a randomly chosen physical store, assuming that while an attacker can target any particular system, they
|
|
cannot target all systems simultaneously and we give them too little time to target the system we buy.
|
|
|
|
A limitation of both approaches is that in either case, while the party creating or acquiring the system can trust it,
|
|
they cannot prove its trustworthiness to other parties. MPC solves this issue by allowing every party to contribute
|
|
their trusted system to the protocol, cryptographically bootstrapping common trust in the computation and its
|
|
output\footnote{
|
|
In fact, MPC does more than just bootstrapping from each participant trusting their own system to a trusted shared
|
|
computation. In an MPC protocol providing semi-honest or better security, MPC even \emph{relaxes} each party's trust
|
|
requirement from trusting their own system to trusting that any $n$-of-$k$ out of all systems contributing to the
|
|
protocol.
|
|
}.
|
|
|
|
MPC is a uniquely powerful cryptographic primitive, yet it has still not found widespread practical adoption. This is
|
|
because MPC is extremely resource-intensive to run. MPC protocols exist on a continuum trading off between extreme
|
|
memory and bandwidth requirements on one end and intense computational requirements on the other end. At a first glance,
|
|
MPC and Hardware Security Modules look like they would complement each other well, but HSMs cannot keep up with the
|
|
intense computational requirements posed by MPC.
|
|
|
|
Commercially available HSMs are quoted to perform between X and Y\todo{Look up number range} individual cryptographic
|
|
operations per second. Meanwhile, an MPC protocol doing something as simple as a single AES encryption, corresponding to
|
|
X\todo{look up numbers} logic gates or Y\todo{look up numbers} x86-64 instructions, requires
|
|
\emph{millions}\todo{Validate and add citation} of cryptographic operations when performed in MPC. As a result, applying
|
|
conventional HSMs to MPC at any practical scale is infeasible by multiple orders of magnitude.
|
|
|
|
HSMs are slow compared to contemporary computers because they are limited in their power dissipation, and power
|
|
dissipation is largely proportional to processing speed. In the limited fields where HSMs have found commercial
|
|
application, this limitation was never considered important and market forces pushing towards faster HSMs remain
|
|
light\todo{Can we find a citation here?}. Fundamentally, conventional HSMs must envelope the entire payload in a tamper
|
|
sensing mesh to detect drilling attacks, but a tamper sensing mesh that is impermeable to a drill is also impermeable to
|
|
air. As a result, any heat conducted from the HSMs processor to the outside world must pass through the mesh. At the
|
|
same time, the mesh cannot be thinned either because thinning it would enable micro-drilling attacks. The result of
|
|
these constraints is a high thermal resistance between the HSM's processor and an external heat sink, which limits
|
|
maximum power dissipation to a fraction of what is achieved in modern CPUs or even GPUs.
|
|
|
|
Inertial HSMs solve this issue since they allow their payload to be air cooled without compromising security, and they
|
|
expand the feasible security boundary size from the several hundred milliliters offered by conventional HSMs to several
|
|
liters and more, enabling the integration of standard, off-the-shelf server components such as mainboards, CPUs, CPU
|
|
coolers, and power supplies. In this chapter, we will first provide a short overview of the theory of MPC before
|
|
elaborating a design of an IHSM tailored to MPC tasks including performance calculations and unique design aspects. We
|
|
will conclude with an outlook of applications unlocked by our design as well as promising areas for future improvements
|
|
of our design.
|
|
|
|
\section{The Fundamentals of Multiparty Computation}
|
|
|
|
\subsection{Fundamental Primitives}
|
|
\subsubsection{Secret Sharing}
|
|
\subsubsection{Oblivious Transfer}
|
|
|
|
\subsection{Boolean MPC}
|
|
% Yao's Garbled Circuits
|
|
|
|
\subsection{Arithmetic MPC}
|
|
% BGW
|
|
|
|
\subsection{Practical Application}
|
|
\subsubsection{Preprocessing and Online Phases}
|
|
\subsubsection{OT extensions}
|
|
\subsubsection{Constant-Round MPC}
|
|
|
|
\subsection{Security Models in MPC}
|
|
|
|
\subsection{Performance}
|
|
|
|
\subsection{Practical Deployments}
|
|
|
|
\subsection{MPC in HSMs}
|
|
|
|
\subsection{HSM Construction}
|
|
|
|
\subsection{Solutions}
|
|
|
|
\section{A High-Performance IHSM for MPC Applications}
|
|
|
|
\subsection{A Practical Performance Target}
|
|
|
|
\subsection{Hardware Requirements}
|
|
|
|
\subsection{A Joint Cooling and IHSM Envelope Powertrain}
|
|
|
|
\subsection{Rotation-Invariant Envelope Power Supply}
|
|
% Twisted Inductor paper
|
|
|
|
A central engineering challenge in inertial HSMs is transferring power and data between the payload and the rotating
|
|
mesh cage. Industrially, power and data transfer through rotating joints is usually done using slip ring assemblies. A
|
|
slip ring consists of one or more contacts that wipe on a rotating circular surface. Industrially, metal spring contacts
|
|
plated with hard gold or other common surface coatings are used for transferring small currents and data signals, and
|
|
carbon brushes are used for higher currents. Slip rings are widely used in motors and other rotating machinery.
|
|
|
|
For use in IHSMs, slip rings have several limitations. First, they are complex precision-machined components and thus
|
|
are rather expensive. Beyond cost, they also have performance limitations. Generally, slip rings are most well-suited to
|
|
slow rotation, as high rotation increases the wear of the contacts. The design target of \qty{1000}{rpm} we use in IHSMs
|
|
are at the upper end of what commercial slip rings usually support. A third disadvantage is that they are sensitive, and
|
|
any misalignment or contamination by dust can increase wear and cause intermittant contact.
|
|
|
|
An IHSM's data link can easily be realized using optical communication. Although power transfer using light is also
|
|
possible---and we have in fact demonstrated it in our first prototype IHSM---it comes at the disadvantage of a heavy
|
|
rotating assembly since large solar cells are needed, and it has poor end-to-end efficiency. For the large-scale meshes
|
|
needed in a high-performance IHSM tailored to SMPC applications, we engineered a better solution: A rotation-invariant
|
|
inductive Wireless Power Transfer link.
|
|
|
|
While Wireless Power Transfer (WPT) can be implemented in many different ways, the vast majority are variants of
|
|
Inductive WPT, where the primary and secondary side are linked primarily through the magnetic component of the
|
|
electromagnetic field, and coils are used as the transmitting and receiving antenna. Inductive WPT uses low frequency,
|
|
which reduces circuit complexity, and it is well-suited for transferring high power across short distances. The
|
|
electronic realization of a WPT link is usually similar to that of a DC/DC converter, except that in place of the
|
|
inductor or flyback transformer, the pair of transceiver coils is used. Compared to a flyback transformer, the WPT
|
|
link's transceiver coil pair has a lower coupling coefficient that varies with distance.
|
|
|
|
A challenge in WPT links is the strong dependency between link inductor coupling coefficient and distance. In a naïve
|
|
implementation that uses the link coils as a simple transformer, link efficiency would drop sharply with distance. To
|
|
decrease the impact of this distance dependency, almost all WPT implementations combine the transceiver coils with
|
|
capacitors to form a pair of tuned tank circuits that are driven like they would be in a resonant converter. Like in
|
|
resonant converters, a variety of topologies such as series, parallel, or series-parallel LC are used for these tuning
|
|
circuits.
|
|
|
|
|
|
|
|
\subsection{Software Considerations}
|
|
|
|
\subsection{Fast Zeroization of Non-Customizable Memories}
|
|
% Thermite experiements and paper
|
|
|
|
\section{Outlook}
|
|
|
|
\clearpage % clearpage flushes all figures. force this here so we don't get figures floating in between references.
|
|
% TODO when breaking this out into a template for building both the whole thesis and individual chapters, we have to
|
|
% decide whether we want to keep the bibliography per-chapter or only once for the whole thesis. In the latter case, we
|
|
% probably want to replace subbibintoc with bibintoc, or add a custom "bibliography" chapter and adjust the second
|
|
% bibliography's heading
|
|
\newrefcontext[labelprefix={W}]
|
|
\printbibliography[type={online},title={Web sources},heading=subbibintoc]
|
|
\newrefcontext
|
|
\printbibliography[nottype={online},resetnumbers,heading=subbibintoc]
|
|
|
|
\appendix
|
|
|
|
\end{document}
|