Paper 2017/926

How to Construct a Leakage-Resilient (Stateless) Trusted Party

Daniel Genkin, Yual Ishai, and Mor Weiss

Abstract

Trusted parties and devices are commonly used in the real world to securely perform computations on secret inputs. However, their security can often be compromised by side-channel attacks in which the adversary obtains partial leakage on intermediate computation values. This gives rise to the following natural question: To what extent can one protect the trusted party against leakage? Our goal is to design a hardware device $T$ that allows $m\ge 1$ parties to securely evaluate a function $f(x_1,\ldots,x_m)$ of their inputs by feeding $T$ with encoded inputs that are obtained using local secret randomness. Security should hold even in the presence of an active adversary that can corrupt a subset of parties and obtain restricted leakage on the internal computations in $T$. We design hardware devices $T$ in this setting both for zero-knowledge proofs and for general multi-party computations. Our constructions can unconditionally resist either $AC^0$ leakage or a strong form of ``only computation leaks'' (OCL) leakage that captures realistic side-channel attacks, providing different tradeoffs between efficiency and security.

Metadata
Available format(s)
PDF
Publication info
A major revision of an IACR publication in TCC 2017
Keywords
Leakage-ResilienceSecure Multiparty ComputationAlgebraic Manipulation DetectionAMD Circuits
Contact author(s)
mormorweiss @ gmail com
History
2017-12-04: last of 3 revisions
2017-09-24: received
See all versions
Short URL
https://ia.cr/2017/926
License
Creative Commons Attribution
CC BY

BibTeX

@misc{cryptoeprint:2017/926,
      author = {Daniel Genkin and Yual Ishai and Mor Weiss},
      title = {How to Construct a Leakage-Resilient (Stateless) Trusted Party},
      howpublished = {Cryptology {ePrint} Archive, Paper 2017/926},
      year = {2017},
      url = {https://eprint.iacr.org/2017/926}
}
Note: In order to protect the privacy of readers, eprint.iacr.org does not use cookies or embedded third party content.