Succinct Scriptable NIZK via Trusted Hardware

Abstract

Non-interactive zero-knowledge proof or argument (NIZK) systems are widely used in many security sensitive applications to enhance computation integrity, privacy and scalability. In such systems, a prover wants to convince one or more verifiers that the result of a public function is correctly computed without revealing the (potential) private input, such as the witness. In this work, we introduce a new notion, called succinct scriptable NIZK, where the prover and verifier(s) can specify the function (or language instance) to be proven via a script. We formalize this notion is UC framework and provide a generic trusted hardware based solution. We then instantiate our solution in both SGX and Trustzone with Lua script engine. The system can be easily used by typical programmers without any cryptographic background. The benchmark result shows that our solution is better than all the known NIZK proof systems w.r.t. prover’s running time (1000 times faster), verifier’s running time, and the proof size. Finally, we show how the proposed scriptable succinct NIZK can be readily deployed to solve many well-known problems in the blockchain context, e.g. verifier’s dilemma, fast joining for new players, etc..

A SGX implementation

As we mentioned in Sect. 6, our SGX-based prototype is implemented in C++ using the Intel(R) SGX SDK v2.5 for Linux. Our implementation is built on top of [34], and we added OpenSSL lib functions for common cryptographic primitives, such as SHA256, ECDSA, etc. Since system call is not allowed in enclave, we also simulated a simple file system to support the Lua interpreter. The size of the compiled enclave binary is approximately 3.2 MB.

Up on execution, the prover first creates an instance of the Lua script engine enclave in the SGX and transfers the target information of QE into the Lua script engine enclave, which will be used later to generate the report for QE. The prover then produces his proof by calling specific function interface of the enclave, $\mathsf {VerifySign}$, taking the script $\mathcal C$ and the public input $\mathsf {Input}_{\mathrm {pub}}$ as the arguments of the function. In our prototype, the script $\mathcal C$ and statement $\mathsf {Input}_{\mathrm {pub}}$ are pre-loaded into the simulated filesystem. After loading $\mathsf {Input}_{\mathrm {priv}}$ from the prover and putting it into the simulated filesystem, the enclave invokes the Lua interpreter to process the script $y\leftarrow \mathcal C (\mathsf {Input}_{\mathrm {pub}},\mathsf {Input}_{\mathrm {priv}})$, where the script can access the statement and witness through Lua file operations. Note that Lua heap size need to be predefined while compiling the Lua script engine enclave, such as 32 MB, which restrict the class of script it can support.

After the script execution, the enclave hashes $h:=\mathsf {hash}(\mathcal C,\mathsf {Input}_{\mathrm {pub}},\mathsf {Input}_{\mathrm {priv}})$ and then put $(\mathsf {tag},h)$ in to the $\mathsf {REPORTDATA}$ field of the report structure, and generate the report $r(\mathsf {tag},h)$ for QE to sign. The prover will then fetch the report $r(\mathsf {tag},h)$ and send it together with signature revocation list (which can be obtained from the Intel IAS and SPID (which is assigned by the Intel IAS when user registers to the Intel IAS) to the QE. The QE will verify the report using its report key and compute an non-revoked proof for the signature revocation list, generating a quote consisting of the $\mathsf {ReportBody}$ field of the report, the non-revoke proof and some other necessary information. The prover then will send the quote to the Intel IAS server for attestation verification report.

Table 2. QuoteBody structure

Reducing Proof Size. Naively, the prover can send the entire signed attestation verification report as the NIZK proof. The proof size is 731 Bytes (IAS report size) $+$ 256 Bytes (the signature size). To reduce proof size, we observe that Intel’s signature is signed on top of the hash of the attestation verification report, so the prover does not need to give the entire report as a part of the proof as far as the verifier can reproduce the hash of the report. However, the verifier is interested in some field of in the $\mathsf {isvEnclaveQuoteBody}$, such as $\mathsf {REPORTDATA}$. Notice that SHA256 uses Merkle-Damgård structure, i.e., the final hash digest is calculated by iteratively calling a compression function over trunks of the signing document. Therefore, the prover can give the partial hash digest of the first part of the signing report, including ID, timestamp, version, $\mathsf {isvEnclaveQuoteStatus}$. The $\mathsf {isvEnclaveQuoteBody}$ structure is shown in Table 2. The verifier is only interested in the five fields marked in grey background, and they can be reconstructed from the public input of the verifier. Moreover, currently, all the reserved fields must be 0. Moreover, the verifier also wants to check $\mathsf {isvEnclaveQuoteStatus} = \mathsf {OK}$; nevertheless, we observe that the attestation verification report whose $\mathsf {isvEnclaveQuoteStatus} = \mathsf {OK}$ has a fixed length n. Otherwise, the length of the attestation verification report is different from n. Based on that observation, we can regard the length n as another public input of the verifier. Then when the verifier receives a proof, he/she can check whether the $\mathsf {isvEnclaveQuoteStatus}$ field of the associated attestation verification report is $\mathsf {OK}$ by putting the length n into the end of the report as the total hashed length. then if the $\mathsf {isvEnclaveQuoteStatus}$ field is not $\mathsf {OK}$, the report hash is not aligned probably, resulting a wrong hash digest.

We let the prover give the partial hash digest until $\mathsf {misc\_select}$ field. Denote the partial hash digest of the report as ph. The prover needs to provide the $\mathsf {attributes}$ field, denoted as $\mathsf {attr}$, which is 16 Bytes². The proof is $(ph,\mathsf {attr}, \sigma )$. The verifier can use reconstruct the hash of the report and then check the validity of the signature. The proof size is now reduced to 41 Bytes $+$ 256 Bytes ( the signature size), which is 297 Bytes.