Embedded SFE: Offloading Server and Network Using Hardware Tokens

Abstract

Abstract. We consider Secure Function Evaluation (SFE) in the clientserver setting where the server issues a secure token to the client. The token is not trusted by the client and is not a trusted third party. We show how to take advantage of the token to drastically reduce the communication complexity of SFE and computation load of the server. Our main contribution is the detailed consideration of design decisions, optimizations, and trade-offs, associated with the setting and its strict hardware requirements for practical deployment. In particular, we model the token as a computationally weak device with small constant-size memory and limit communication between client and server. We consider semi-honest, covert, and malicious adversaries. We show the feasibility of our protocols based on a FPGA implementation.

Truly Efficient String Oblivious Transfer Using Resettable Tamper-Proof Tokens

“…Further, evaluating garbled circuits (our main application) involves transferring them (megabytes or gigabytes of data, especially in the malicious model) to the client. In large-scale deployment of SFE (e.g., by banks and service providers), these communication costs cannot be afforded; fortunately, they can be avoided by generating circuits from a seed by the server-issued token [20]. This solution requires reliance on tamper-proof/tamper-resistant tokens, forces their use, fits well with our setting, and further justifies it.…”

Twin Clouds: Secure Cloud Computing with Low Latency

“…The authors propose to use a tamper-proof hardware token which generates GCs in a setup phase that are afterwards evaluated in parallel by the cloud. The token receives the description of a boolean circuit and generates the corresponding GC using a constant amount of memory (using the protocol of [22]). The hardware token is integrated into the infrastructure of the cloud service provider either in form of a Smartcard provided by the client, or as a cryptographic co-processor.…”

“…For each 2-input non-XOR gate the garbled table has size ≈ 4t bits, where t is the symmetric security parameter (e.g., t = 128); creation of the garbled table requires 4 invocations of a cryptographic hash function (e.g., SHA-256) and evaluation needs 1 invocation. As shown in [22], generation of GCs requires only a constant amount of memory (independent of the size of the evaluated function) and only symmetric cryptographic operations (e.g., SHA-256). The implementation results of [31] show that evaluation of GCs can be performed efficiently on today's hardware: GC evaluation of the reasonably large AES functionality (22,546 XOR; 11,334 non-XOR gates) took 2s on a single core of an Intel Core 2 Duo with 3.0 GHz.…”

(Efficient) Universally Composable Oblivious Transfer Using a Minimal Number of Stateless Tokens

“…(In particular, parties can create the tamper-proof tokens themselves rather than obtain them from a trusted provider as in [34], and there is no assumption regarding what code a malicious party puts in a token it creates.) Secure hardware may also potentially result in more efficient protocols; indeed, it has been suggested for improving efficiency in other settings (e.g., [18,14,15,6,31,38,42,23]). In addition to introducing the model, Katz showed that tamper-proof hardware tokens can be used for universally composable computation of arbitrary functions under additional cryptographic assumptions.…”