Verifiable ASICs: trustworthy hardware with untrusted components - - PowerPoint PPT Presentation
Verifiable ASICs: trustworthy hardware with untrusted components Riad S. Wahby , Max Howald , Siddharth Garg , abhi shelat , and Michael Walfish Stanford University New York University The Cooper Union
Riad S. Wahby◦⋆, Max Howald†⋆, Siddharth Garg⋆, abhi shelat‡, and Michael Walfish⋆
⋆New York University †The Cooper Union ‡The University of Virginia
June 10th, 2016
Setting: ASICs with mutually distrusting designer, manufacturer chip design
(government, chip designer)
(“foundry”
Setting: ASICs with mutually distrusting designer, manufacturer chip design
(government, chip designer)
(“foundry”
RAM cache register file ALU
in[0] in[n]
D Q D Q
Setting: ASICs with mutually distrusting designer, manufacturer
(Other concerns, e.g., secret state, are important but orthogonal)
For example, stealthy trojans can thwart post-fab detection [A2: Analog Malicious Hardware, Yang et al., IEEE S&P 2016; Stealthy Dopant-Level Trojans, Becker et al., CHES 2013]
For example, stealthy trojans can thwart post-fab detection [A2: Analog Malicious Hardware, Yang et al., IEEE S&P 2016; Stealthy Dopant-Level Trojans, Becker et al., CHES 2013]
✗ Only 5 countries have cutting-edge fabs on-shore ✗ Building a new fab takes $$$$$$, years of R&D
For example, stealthy trojans can thwart post-fab detection [A2: Analog Malicious Hardware, Yang et al., IEEE S&P 2016; Stealthy Dopant-Level Trojans, Becker et al., CHES 2013]
✗ Only 5 countries have cutting-edge fabs on-shore ✗ Building a new fab takes $$$$$$, years of R&D ✗ Semiconductor scaling: chip area and energy go with square and cube of transistor length (“critical dimension”) ✗ So using an old fab means an enormous performance hit
e.g., India’s best on-shore fab is 108× behind state of the art
For example, stealthy trojans can thwart post-fab detection [A2: Analog Malicious Hardware, Yang et al., IEEE S&P 2016; Stealthy Dopant-Level Trojans, Becker et al., CHES 2013]
✗ Only 5 countries have cutting-edge fabs on-shore ✗ Building a new fab takes $$$$$$, years of R&D ✗ Semiconductor scaling: chip area and energy go with square and cube of transistor length (“critical dimension”) ✗ So using an old fab means an enormous performance hit
e.g., India’s best on-shore fab is 108× behind state of the art
input
x y proof that y = F(x) input
x y proof that y = F(x) input
x y proof that y = F(x) input
Babai85 GMR85 BCC86 BFLS91 FGLSS91 Kilian92 ALMSS92 AS92 Micali94 BG02 GOS06 IKO07 GKR08 KR09 GGP10 Groth10 GLR11 Lipmaa11 BCCT12 GGPR13 BCCT13 KRR14 . . .
x y proof that y = F(x) input
Babai85 GMR85 BCC86 BFLS91 FGLSS91 Kilian92 ALMSS92 AS92 Micali94 BG02 GOS06 IKO07 GKR08 KR09 GGP10 Groth10 GLR11 Lipmaa11 BCCT12 GGPR13 BCCT13 KRR14 . . . SBW11 CMT12 SMBW12 TRMP12 SVPBBW12 SBVBPW13 VSBW13 PGHR13 Thaler13 BCGTV13 BFRSBW13 BFR13 DFKP13 BCTV14a BCTV14b BCGGMTV14 FL14 KPPSST14 FTP14 WSRHBW15 BBFR15 CFHKNPZ15 CTV15 KZMQCPPsS15
x y proof that y = F(x) input
advanced fab might offset these costs
Babai85 GMR85 BCC86 BFLS91 FGLSS91 Kilian92 ALMSS92 AS92 Micali94 BG02 GOS06 IKO07 GKR08 KR09 GGP10 Groth10 GLR11 Lipmaa11 BCCT12 GGPR13 BCCT13 KRR14 . . . SBW11 CMT12 SMBW12 TRMP12 SVPBBW12 SBVBPW13 VSBW13 PGHR13 Thaler13 BCGTV13 BFRSBW13 BFR13 DFKP13 BCTV14a BCTV14b BCGGMTV14 FL14 KPPSST14 FTP14 WSRHBW15 BBFR15 CFHKNPZ15 CTV15 KZMQCPPsS15
101 105 109 103 107 1011
worker’s cost normalized to native C
matrix multiplication (m=128) 1013 P e p p e r G i n g e r P i n
c h i
a a t a r C M T n a t i v e C A l l s p i c e T i n y R A M T h a l e r P e
x y proof that y = F(x) input
Babai85 GMR85 BCC86 BFLS91 FGLSS91 Kilian92 ALMSS92 AS92 Micali94 BG02 GOS06 IKO07 GKR08 KR09 GGP10 Groth10 GLR11 Lipmaa11 BCCT12 GGPR13 BCCT13 KRR14 . . . SBW11 CMT12 SMBW12 TRMP12 SVPBBW12 SBVBPW13 VSBW13 PGHR13 Thaler13 BCGTV13 BFRSBW13 BFR13 DFKP13 BCTV14a BCTV14b BCGGMTV14 FL14 KPPSST14 FTP14 WSRHBW15 BBFR15 CFHKNPZ15 CTV15 KZMQCPPsS15
x y proof that y = F(x) input
x y proof that y = F(x) input
Arguments [GGPR13, SBVBPW13, PGHR13, BCTV14] e.g., Zaatar, Pinocchio, libsnark IPs [GKR08, CMT12, VSBW13] e.g., Muggles, CMT, Allspice
x y proof that y = F(x) input
Arguments [GGPR13, SBVBPW13, PGHR13, BCTV14] e.g., Zaatar, Pinocchio, libsnark IPs [GKR08, CMT12, VSBW13] e.g., Muggles, CMT, Allspice
x y proof that y = F(x) input
Arguments [GGPR13, SBVBPW13, PGHR13, BCTV14] e.g., Zaatar, Pinocchio, libsnark IPs [GKR08, CMT12, VSBW13] e.g., Muggles, CMT, Allspice
x y proof that y = F(x) input
Arguments [GGPR13, SBVBPW13, PGHR13, BCTV14] e.g., Zaatar, Pinocchio, libsnark + nondeterministic ACs, arbitrary connectivity + Few rounds (≤ 3) IPs [GKR08, CMT12, VSBW13] e.g., Muggles, CMT, Allspice – deterministic ACs; layered, low depth – Many rounds
x y proof that y = F(x) input
Arguments [GGPR13, SBVBPW13, PGHR13, BCTV14] e.g., Zaatar, Pinocchio, libsnark + nondeterministic ACs, arbitrary connectivity + Few rounds (≤ 3) Unsuited to hardware implementation IPs [GKR08, CMT12, VSBW13] e.g., Muggles, CMT, Allspice – deterministic ACs; layered, low depth – Many rounds
x y proof that y = F(x) input
Arguments [GGPR13, SBVBPW13, PGHR13, BCTV14] e.g., Zaatar, Pinocchio, libsnark + nondeterministic ACs, arbitrary connectivity + Few rounds (≤ 3) Unsuited to hardware implementation IPs [GKR08, CMT12, VSBW13] e.g., Muggles, CMT, Allspice – deterministic ACs; layered, low depth – Many rounds Suited to hardware implementation
V P x
V P x thinking...
V P x thinking...
V P x thinking...
V P x y
y to last layer’s input wires
V P x y thinking...
y to last layer’s input wires
V P x y
sum-check [LFKN90]
y to last layer’s input wires
claim about second-last layer
V P x y
sum-check [LFKN90]
y to last layer’s input wires
claim about second-last layer
V P x y
sum-check [LFKN90] more sum-checks
y to last layer’s input wires
claim about second-last layer
V P x y
sum-check [LFKN90] more sum-checks
y to last layer’s input wires
claim about second-last layer
V P x y
sum-check [LFKN90] more sum-checks
y to last layer’s input wires
claim about second-last layer
inputs, which it can check
V P x y
sum-check [LFKN90] more sum-checks
Soundness error ∝ p−1 V P x y
sum-check [LFKN90] more sum-checks
Soundness error ∝ p−1 Cost to execute F directly: O(depth · width) V’s sequential running time: O(depth · log width + |x| + |y|) (assuming precomputed queries) V P x y
sum-check [LFKN90] more sum-checks
Soundness error ∝ p−1 Cost to execute F directly: O(depth · width) V’s sequential running time: O(depth · log width + |x| + |y|) (assuming precomputed queries) P’s sequential running time: O(depth · width · log width) V P x y
sum-check [LFKN90] more sum-checks
P executing AC: layers are sequential, but all gates at a layer can be executed in parallel
P executing AC: layers are sequential, but all gates at a layer can be executed in parallel Proving step: Can V and P interact about all of F’s layers at once?
P executing AC: layers are sequential, but all gates at a layer can be executed in parallel Proving step: Can V and P interact about all of F’s layers at once?
P executing AC: layers are sequential, but all gates at a layer can be executed in parallel Proving step: Can V and P interact about all of F’s layers at once?
But: there is still parallelism to be extracted. . .
V questions P about F(x1)’s output layer.
V questions P about F(x1)’s output layer. Simultaneously, P returns F(x2).
V questions P about F(x1)’s next layer
V questions P about F(x1)’s next layer, and F(x2)’s output layer.
V questions P about F(x1)’s next layer, and F(x2)’s output layer. Meanwhile, P returns F(x3).
This process continues. . .
This process continues. . .
This process continues until V and P interact about every layer simultaneously—but for different computations. V and P can complete
step.
Input (x) Output (y) prove prove prove Sub-prover, layer 0 Sub-prover, layer 1 Sub-prover, layer d − 1
V P
queries responses queries responses queries responses
. . . . . .
This approach is just a standard hardware technique, pipelining; it is possible because the protocol is naturally staged.
Input (x) Output (y) prove prove prove Sub-prover, layer 0 Sub-prover, layer 1 Sub-prover, layer d − 1
V P
queries responses queries responses queries responses
. . . . . .
This approach is just a standard hardware technique, pipelining; it is possible because the protocol is naturally staged. There are other opportunities to leverage the protocol’s structure.
For each sum-check round, P sums over each gate in a layer
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2}
layer:
H[k] =
δ(g, k)
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k)
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
gate prover δ(0, 0) gate prover δ(1, 0) gate prover δ(2, 0) gate prover δ(3, 0) . . .
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
gate prover δ(0, 0) gate prover δ(1, 0) gate prover δ(2, 0) gate prover δ(3, 0) . . .
RAM
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
gate prover δ(0, 0) gate prover δ(1, 0) gate prover δ(2, 0) gate prover δ(3, 0) . . .
RAM
Adder tree
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
gate prover δ(0, 0) δ(0, 1) gate prover δ(1, 0) δ(1, 1) gate prover δ(2, 0) δ(2, 1) gate prover δ(3, 0) δ(3, 1) . . .
RAM
Adder tree
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
gate prover δ(0, 0) δ(0, 1) δ(0, 2) gate prover δ(1, 0) δ(1, 1) δ(1, 2) gate prover δ(2, 0) δ(2, 1) δ(2, 2) gate prover δ(3, 0) δ(3, 1) δ(3, 2) . . .
RAM
Adder tree
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
gate prover δ(0, 0) δ(0, 1) δ(0, 2) δ(0, rj) gate prover δ(1, 0) δ(1, 1) δ(1, 2) δ(1, rj) gate prover δ(2, 0) δ(2, 1) δ(2, 2) δ(2, rj) gate prover δ(3, 0) δ(3, 1) δ(3, 2) δ(3, rj)
RAM
Adder tree
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
gate prover δ(0, 0) δ(0, 1) δ(0, 2) δ(0, rj) gate prover δ(1, 0) δ(1, 1) δ(1, 2) δ(1, rj) gate prover δ(2, 0) δ(2, 1) δ(2, 2) δ(2, rj) gate prover δ(3, 0) δ(3, 1) δ(3, 2) δ(3, rj)
RAM
Adder tree
For each sum-check round, P sums over each gate in a layer, evaluating H[k], k ∈ {0, 1, 2} In software:
// compute H[0], H[1], H[2] for k ∈ {0, 1, 2}: H[k] ← 0 for g ∈ layer: H[k] ← H[k] + δ(g, k) // δ uses state[g] // update lookup table // with V’s random coin for g ∈ layer: state[g] ← δ(g, rj)
layer:
H[k] =
δ(g, k) In hardware:
state[0] gate prover δ(0, 0) δ(0, 1) δ(0, 2) δ(0, rj) state[1] gate prover δ(1, 0) δ(1, 1) δ(1, 2) δ(1, rj) state[2] gate prover δ(2, 0) δ(2, 1) δ(2, 2) δ(2, rj) state[3] gate prover δ(3, 0) δ(3, 1) δ(3, 2) δ(3, rj)
Adder tree
e.g., pipelined proving e.g., parallel evaluation of δ by gate provers
e.g., no RAM: data is kept close to places it is needed
e.g., pipelined proving e.g., parallel evaluation of δ by gate provers
e.g., no RAM: data is kept close to places it is needed e.g., latency-insensitive design: localized control
e.g., pipelined proving e.g., parallel evaluation of δ by gate provers
e.g., no RAM: data is kept close to places it is needed e.g., latency-insensitive design: localized control
e.g., computation: save energy by adding memoization to P e.g., hardware: save chip area by reusing the same circuits
Interaction between V and P requires a lot of bandwidth
✗ V and P on circuit board? Too much energy, circuit area
Interaction between V and P requires a lot of bandwidth
✗ V and P on circuit board? Too much energy, circuit area ✓ Zebra uses 3D integration
Interaction between V and P requires a lot of bandwidth
✗ V and P on circuit board? Too much energy, circuit area ✓ Zebra uses 3D integration
Protocol requires input-independent precomputation [VSBW13]
Interaction between V and P requires a lot of bandwidth
✗ V and P on circuit board? Too much energy, circuit area ✓ Zebra uses 3D integration
Protocol requires input-independent precomputation [VSBW13]
✓ Zebra amortizes precomputations over many V-P pairs
Interaction between V and P requires a lot of bandwidth
✗ V and P on circuit board? Too much energy, circuit area ✓ Zebra uses 3D integration
Protocol requires input-independent precomputation [VSBW13]
✓ Zebra amortizes precomputations over many V-P pairs
Precomputations need secrecy, integrity
✗ Give V trusted storage? Cost would be prohibitive
x y proof that y = F(x) input
prei
Interaction between V and P requires a lot of bandwidth
✗ V and P on circuit board? Too much energy, circuit area ✓ Zebra uses 3D integration
Protocol requires input-independent precomputation [VSBW13]
✓ Zebra amortizes precomputations over many V-P pairs
Precomputations need secrecy, integrity
✗ Give V trusted storage? Cost would be prohibitive ✓ Zebra uses untrusted storage + authenticated encryption
x y proof that y = F(x) input
Ek(prei)
software or hardware V’s interactions with P
Zebra can produce 10k–100k proofs per second, while existing systems take tens of seconds per proof!
Zebra can produce 10k–100k proofs per second, while existing systems take tens of seconds per proof!
x y proof that y = F(x) input
Baseline: direct implementation of F in same technology as V
x y proof that y = F(x) input
Baseline: direct implementation of F in same technology as V Metrics: energy, chip size per throughput (discussed in paper)
x y proof that y = F(x) input
Baseline: direct implementation of F in same technology as V Metrics: energy, chip size per throughput (discussed in paper) Measurements: based on circuit synthesis and simulation, published chip designs, and CMOS scaling models Charge for V, P, communication; retrieving and decrypting precomputations; PRNG; Operator communicating with V
x y proof that y = F(x) input
Baseline: direct implementation of F in same technology as V Metrics: energy, chip size per throughput (discussed in paper) Measurements: based on circuit synthesis and simulation, published chip designs, and CMOS scaling models Charge for V, P, communication; retrieving and decrypting precomputations; PRNG; Operator communicating with V Constraints: trusted fab = 350 nm; untrusted fab = 7 nm; 200 mm2 max chip area; 150 W max total power
350 nm: 1997 (Pentium II) 7 nm: ≈ 2017 [TSMC] ≈ 20 year gap between trusted and untrusted fab
Ratio of baseline energy to Zebra energy
6 7 8 9 10 11 12 13 0.1 0.3 1 3 log2(NTT size) baseline vs. Zebra (higher is better)
Ratio of baseline energy to Zebra energy
84 170 340 682 1147 0.1 0.3 1 3 Parallel Curve25519 point multiplications baseline vs. Zebra (higher is better)
and trusted fab (for V)
Applies to IPs, but not arguments
and trusted fab (for V)
Design principle IPs
[GKR08, CMT12, VSBW13]
Arguments
[GGPR13, SBVBPW13, PGHR13, BCTV14]
Extract parallelism ✓ ✓ Exploit locality ✓ Reduce, reuse, recycle ✓ Argument protocols seem friendly to hardware?
Design principle IPs
[GKR08, CMT12, VSBW13]
Arguments
[GGPR13, SBVBPW13, PGHR13, BCTV14]
Extract parallelism ✓ ✓ Exploit locality ✓ ✗ Reduce, reuse, recycle ✓ Argument protocols seem unfriendly to hardware: P computes over entire AC at once = ⇒ need RAM
Design principle IPs
[GKR08, CMT12, VSBW13]
Arguments
[GGPR13, SBVBPW13, PGHR13, BCTV14]
Extract parallelism ✓ ✓ Exploit locality ✓ ✗ Reduce, reuse, recycle ✓ ✗ Argument protocols seem unfriendly to hardware: P computes over entire AC at once = ⇒ need RAM P does crypto for every gate in AC = ⇒ special crypto circuits
Design principle IPs
[GKR08, CMT12, VSBW13]
Arguments
[GGPR13, SBVBPW13, PGHR13, BCTV14]
Extract parallelism ✓ ✓ Exploit locality ✓ ✗ Reduce, reuse, recycle ✓ ✗ Argument protocols seem unfriendly to hardware: P computes over entire AC at once = ⇒ need RAM P does crypto for every gate in AC = ⇒ special crypto circuits
and trusted fab (for V)
Common to essentially all built proof systems
and trusted fab (for V)
and trusted fab (for V)
System Amortization regime Advice Zebra many V-P pairs short Allspice [VSBW13] batch of instances
short Bootstrapped SNARKs [BCTV14a, CTV15] all computations long BCTV [BCTV14b] all computations
long Pinocchio [PGHR13] all future instances
long Zaatar [SBVBPW13] batch of instances
long Exception: [CMT12] with logspace-uniform ACs
and trusted fab (for V)
and trusted fab (for V)
For example, libsnark [BCTV14b], a highly optimized implementa- tion of [GGPR13] and Pinocchio [PGHR13]: V’s work: 6 ms + (|x| + |y|) · 3 µs on a 2.7 GHz CPU
and trusted fab (for V)
For example, libsnark [BCTV14b], a highly optimized implementa- tion of [GGPR13] and Pinocchio [PGHR13]: V’s work: 6 ms + (|x| + |y|) · 3 µs on a 2.7 GHz CPU ⇒ break-even point ≥ 16 × 106 CPU ops
and trusted fab (for V)
For example, libsnark [BCTV14b], a highly optimized implementa- tion of [GGPR13] and Pinocchio [PGHR13]: V’s work: 6 ms + (|x| + |y|) · 3 µs on a 2.7 GHz CPU ⇒ break-even point ≥ 16 × 106 CPU ops With 32 GB RAM, libsnark handles ACs with ≤ 16 × 106 gates
and trusted fab (for V)
For example, libsnark [BCTV14b], a highly optimized implementa- tion of [GGPR13] and Pinocchio [PGHR13]: V’s work: 6 ms + (|x| + |y|) · 3 µs on a 2.7 GHz CPU ⇒ break-even point ≥ 16 × 106 CPU ops With 32 GB RAM, libsnark handles ACs with ≤ 16 × 106 gates ⇒ breaking even requires > 1 CPU op per AC gate, e.g., computations over Fp rather than machine integers
V P
x y proof that y = F(x) input
+ Verifiable ASICs: a new approach to building trustworthy hardware under a strong threat model + First hardware design for a probabilistic proof protocol + Improves performance compared to trusted baseline
V P
x y proof that y = F(x) input
+ Verifiable ASICs: a new approach to building trustworthy hardware under a strong threat model + First hardware design for a probabilistic proof protocol + Improves performance compared to trusted baseline – Improvement compared to the baseline is modest – Applicability is limited:
precomputations must be amortized computation needs to be “big enough” large gap between trusted and untrusted technology does not apply to all computations
V P
x y proof that y = F(x) input
+ Verifiable ASICs: a new approach to building trustworthy hardware under a strong threat model + First hardware design for a probabilistic proof protocol + Improves performance compared to trusted baseline – Improvement compared to the baseline is modest – Applicability is limited:
precomputations must be amortized computation needs to be “big enough” large gap between trusted and untrusted technology does not apply to all computations
https://www.pepper-project.org/