SLIDE 1 Verifiable ASICs: trustworthy hardware with untrusted components
Riad S. Wahby◦⋆, Max Howald†⋆, Siddharth Garg⋆, abhi shelat‡, and Michael Walfish⋆
⋆New York University †The Cooper Union ‡The University of Virginia
April 8, 2016
SLIDE 2
You (probably) shouldn’t trust your hardware. . .
SLIDE 3
You (probably) shouldn’t trust your hardware. . .
SLIDE 4
You (probably) shouldn’t trust your hardware. . .
SLIDE 5
You (probably) shouldn’t trust your hardware. . . . . . because fabs sometimes make mistakes
SLIDE 6 You (probably) shouldn’t trust your hardware. . . . . . because fabs sometimes make “mistakes”
[Tehranipoor and Koushanfar. “A survey of hardware Trojan taxon-
- my and detection.” IEEE DTC, 2010.]
SLIDE 7 What’s a chip designer to do?
◮ Post-fab testing ◮ Hardware obfuscation ◮ Trusted manufacturer
[Bhunia, Hsiao, Banga, and Narasimhan. “Hardware Trojan attacks: threat analysis and countermeasures.” Proc. IEEE, Aug. 2014.]
SLIDE 8 What’s a chip designer to do?
◮ Post-fab testing ◮ Hardware obfuscation ◮ Trusted manufacturer
[Bhunia, Hsiao, Banga, and Narasimhan. “Hardware Trojan attacks: threat analysis and countermeasures.” Proc. IEEE, Aug. 2014.]
SLIDE 9 What’s a chip designer to do?
◮ Post-fab testing ◮ Hardware obfuscation ◮ Trusted manufacturer
– but a fab is expensive and hard to build. . .
[Bhunia, Hsiao, Banga, and Narasimhan. “Hardware Trojan attacks: threat analysis and countermeasures.” Proc. IEEE, Aug. 2014.]
SLIDE 10 What’s a chip designer to do?
◮ Post-fab testing ◮ Hardware obfuscation ◮ Trusted manufacturer
– but a fab is expensive and hard to build. . . – . . . so trusted fab might have 108× worse performance!
[Bhunia, Hsiao, Banga, and Narasimhan. “Hardware Trojan attacks: threat analysis and countermeasures.” Proc. IEEE, Aug. 2014.]
SLIDE 11 Roadmap
- 1. Problem statement: verifiable ASICs
- 2. Probabilistic proof systems, briefly
- 3. Zebra: a system for verifiable ASICs
- 4. Implementation and evaluation
SLIDE 12 Roadmap
- 1. Problem statement: verifiable ASICs
- 2. Probabilistic proof systems, briefly
- 3. Zebra: a system for verifiable ASICs
- 4. Implementation and evaluation
SLIDE 13
Problem statement: verifiable ASICs
Principal
Ψ → specs for P, V
SLIDE 14
Problem statement: verifiable ASICs
Foundry Supplier
(foundry, processor vendor, etc.)
Principal
Ψ → specs for P, V
SLIDE 15
Problem statement: verifiable ASICs
Foundry Supplier
(foundry, processor vendor, etc.)
Principal
Ψ → specs for P, V
Integrator V P
SLIDE 16
Problem statement: verifiable ASICs
Foundry Supplier
(foundry, processor vendor, etc.)
Principal
Ψ → specs for P, V
Integrator
V P
Operator
SLIDE 17
Problem statement: verifiable ASICs
V P
Operator
SLIDE 18
Problem statement: verifiable ASICs
V P
x
Operator
SLIDE 19
Problem statement: verifiable ASICs
V P
x y
Operator
SLIDE 20
Problem statement: verifiable ASICs
V P
x y proof
Operator
SLIDE 21 Problem statement: verifiable ASICs
V P
x y proof
Operator
◮ P is efficient, but can deviate arbitrarily from the protocol
SLIDE 22 Problem statement: verifiable ASICs
V P
x y proof
Operator
◮ P is efficient, but can deviate arbitrarily from the protocol ◮ Honest P always convinces V that y = Ψ(x)
SLIDE 23 Problem statement: verifiable ASICs
V P
x y proof
Operator
◮ P is efficient, but can deviate arbitrarily from the protocol ◮ Honest P always convinces V that y = Ψ(x) ◮ V must catch dishonest P except with negligible probability
SLIDE 24 Problem statement: verifiable ASICs
V P
x y proof
Operator
◮ P is efficient, but can deviate arbitrarily from the protocol ◮ Honest P always convinces V that y = Ψ(x) ◮ V must catch dishonest P except with negligible probability ◮ P cannot attack or disable V, or communicate with
- utside world (see paper for more discussion)
SLIDE 25 Problem statement: verifiable ASICs
V P
x y proof
Operator
◮ P is efficient, but can deviate arbitrarily from the protocol ◮ Honest P always convinces V that y = Ψ(x) ◮ V must catch dishonest P except with negligible probability ◮ P cannot attack or disable V, or communicate with
- utside world (see paper for more discussion)
◮ Goal: V and P together should outperform
Ψ executed in trusted substrate
SLIDE 26 Roadmap
- 1. Problem statement: verifiable ASICs
- 2. Probabilistic proof systems, briefly
- 3. Zebra: a system for verifiable ASICs
- 4. Implementation and evaluation
SLIDE 27 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover
verifier prover program, inputs
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 28 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover
verifier prover program, inputs
+ proof Idea: checking proof should be easier for verifier than executing program
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 29 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover Recent work is in three strands:
◮ Interactive arguments
◮ [Pepper12, Ginger12, Zaatar13]
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 30 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover Recent work is in three strands:
◮ Interactive arguments
◮ [Pepper12, Ginger12, Zaatar13]
◮ Non-interactive arguments (SNARKs)
◮ [PGHR13, BCGTV13, BCTV14]
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 31 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover Recent work is in three strands:
◮ Interactive arguments
◮ [Pepper12, Ginger12, Zaatar13]
◮ Non-interactive arguments (SNARKs)
◮ [PGHR13, BCGTV13, BCTV14]
◮ Interactive proofs
◮ [CMT12, TRMP12, Allspice13, Tha13]
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 32 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover Recent work is in three strands:
◮ Interactive arguments
◮ [Pepper12, Ginger12, Zaatar13]
+ Low round complexity + Mild cryptograhic assumptions
◮ Non-interactive arguments (SNARKs)
◮ [PGHR13, BCGTV13, BCTV14]
◮ Interactive proofs
◮ [CMT12, TRMP12, Allspice13, Tha13]
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 33 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover Recent work is in three strands:
◮ Interactive arguments
◮ [Pepper12, Ginger12, Zaatar13]
+ Low round complexity + Mild cryptograhic assumptions
◮ Non-interactive arguments (SNARKs)
◮ [PGHR13, BCGTV13, BCTV14]
+ Public verifiability, zero knowledge – Non-falsifiable cryptographic assumptions [GW10]
◮ Interactive proofs
◮ [CMT12, TRMP12, Allspice13, Tha13]
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 34 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover Recent work is in three strands:
◮ Interactive arguments
◮ [Pepper12, Ginger12, Zaatar13]
+ Low round complexity + Mild cryptograhic assumptions
◮ Non-interactive arguments (SNARKs)
◮ [PGHR13, BCGTV13, BCTV14]
+ Public verifiability, zero knowledge – Non-falsifiable cryptographic assumptions [GW10]
◮ Interactive proofs
◮ [CMT12, TRMP12, Allspice13, Tha13]
+ Simple and efficient prover and verifier + Information theoretic guarantees (no crypto) [Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 35 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover For all systems, expressiveness is somewhat limited:
◮ Arguments (interactive & non-interactive)
– Computation must be expressed as an arithmetic circuit
◮ Interactive proofs
– Computation must be expressed as an arithmetic circuit [Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 36 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover For all systems, expressiveness is somewhat limited:
◮ Arguments (interactive & non-interactive)
– Computation must be expressed as an arithmetic circuit
◮ Interactive proofs
– Computation must be expressed as an arithmetic circuit
generalized boolean circuit over Fp ∧ → × ∨ → +
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 37 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover For all systems, expressiveness is somewhat limited:
◮ Arguments (interactive & non-interactive)
– Computation must be expressed as an arithmetic circuit + Arithmetic circuit can have arbitrary connectivity, shape
◮ Interactive proofs
– Computation must be expressed as an arithmetic circuit – Arithmetic circuit must be layered, depth ≪ width [Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 38 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover For all systems, expressiveness is somewhat limited:
◮ Arguments (interactive & non-interactive)
– Computation must be expressed as an arithmetic circuit + Arithmetic circuit can have arbitrary connectivity, shape
◮ Interactive proofs
– Computation must be expressed as an arithmetic circuit – Arithmetic circuit must be layered, depth ≪ width
layered vs. unlayered
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 39 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover For all systems, expressiveness is somewhat limited:
◮ Arguments (interactive & non-interactive)
– Computation must be expressed as an arithmetic circuit + Arithmetic circuit can have arbitrary connectivity, shape
◮ Interactive proofs
– Computation must be expressed as an arithmetic circuit – Arithmetic circuit must be layered, depth ≪ width
depth = 3 width = 8
[Walfish and Blumberg. “Verifying computations without reexecuting them: from theoretical possibility to near practicality.” CACM, Feb. 2015.]
SLIDE 40 Roadmap
- 1. Problem statement: verifiable ASICs
- 2. Probabilistic proof systems, briefly
- 3. Zebra: a system for verifiable ASICs
- 4. Implementation and evaluation
SLIDE 41
Zebra’s starting point: Interactive proofs
Zebra is an IP-based protocol [CMT12, Allspice13] (We discuss why not arguments in the paper)
SLIDE 42
Zebra’s starting point: Interactive proofs
SLIDE 43 Zebra’s starting point: Interactive proofs
SLIDE 44 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
SLIDE 45 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
SLIDE 46 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
SLIDE 47 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
y
SLIDE 48 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
y
SLIDE 49 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
SLIDE 50 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
ends up with claim about second-last layer
SLIDE 51 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
ends up with claim about second-last layer
SLIDE 52 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
ends up with claim about second-last layer
SLIDE 53 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
ends up with claim about second-last layer
SLIDE 54 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
ends up with claim about second-last layer
- 5. V iterates, ends up with
claim about inputs
SLIDE 55 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
ends up with claim about second-last layer
- 5. V iterates, ends up with
claim about inputs
with the inputs
SLIDE 56 Zebra’s starting point: Interactive proofs
- 1. V sends inputs
- 2. P evaluates circuit,
returns output y
- 3. V constructs polynomial
relating y to values of last layer’s input wires
ends up with claim about second-last layer
- 5. V iterates, ends up with
claim about inputs
with the inputs V’s work is ≈ O(depth · log width)
SLIDE 57
Pipelined proving in Zebra
V questions P about Ψ(x1)’s output layer.
Ψ(x1)
SLIDE 58
Pipelined proving in Zebra
V questions P about Ψ(x1)’s output layer. Simultaneously, P returns Ψ(x2).
Ψ(x1) Ψ(x2)
SLIDE 59
Pipelined proving in Zebra
V questions P about Ψ(x1)’s next layer
Ψ(x1)
SLIDE 60
Pipelined proving in Zebra
V questions P about Ψ(x1)’s next layer, and Ψ(x2)’s output layer.
Ψ(x1) Ψ(x2)
SLIDE 61
Pipelined proving in Zebra
V questions P about Ψ(x1)’s next layer, and Ψ(x2)’s output layer. Meanwhile, P returns Ψ(x3).
Ψ(x1) Ψ(x2) Ψ(x3)
SLIDE 62
Pipelined proving in Zebra
This process continues until the pipeline is full.
Ψ(x1) Ψ(x2) Ψ(x3) Ψ(x4)
SLIDE 63
Pipelined proving in Zebra
This process continues until the pipeline is full.
Ψ(x1) Ψ(x2) Ψ(x3) Ψ(x4) Ψ(x5)
SLIDE 64 Pipelined proving in Zebra
This process continues until the pipeline is full. V and P can complete
step.
Ψ(x1) Ψ(x2) Ψ(x3) Ψ(x4) Ψ(x5) Ψ(x6) Ψ(x7) Ψ(x8)
SLIDE 65
Other hardware optimizations
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
. . . . . .
SLIDE 66 Other hardware optimizations
Sub-prover circuit Proving machinery
◮ P’s work is mainly local to each gate
SLIDE 67 Other hardware optimizations
gate prover gate prover gate prover gate prover
Sub-prover circuit
Remaining sub-prover machinery
◮ P’s work is mainly local to each gate ◮ P’s design leverages this with gate prover circuits
SLIDE 68 Other hardware optimizations
gate prover gate prover gate prover gate prover
Sub-prover circuit
Remaining sub-prover machinery
◮ P’s work is mainly local to each gate ◮ P’s design leverages this with gate prover circuits ◮ Gate provers reuse work from previous rounds
by maintaining local state
SLIDE 69 Other hardware optimizations
gate prover gate prover gate prover gate prover
Sub-prover circuit
Remaining sub-prover machinery
◮ P’s work is mainly local to each gate ◮ P’s design leverages this with gate prover circuits ◮ Gate provers reuse work from previous rounds
by maintaining local state
◮ Further low-level and protocol optimizations (see paper)
SLIDE 70 Architectural challenges and limitations
◮ Interaction between V and P requires a lot of bandwidth
SLIDE 71 Architectural challenges and limitations
◮ Interaction between V and P requires a lot of bandwidth
⇒ Zebra uses 3D integration
SLIDE 72 Architectural challenges and limitations
◮ Interaction between V and P requires a lot of bandwidth
⇒ Zebra uses 3D integration
◮ IP protocol requires precomputation for most Ψ
[Allspice13]
SLIDE 73 Architectural challenges and limitations
◮ Interaction between V and P requires a lot of bandwidth
⇒ Zebra uses 3D integration
◮ IP protocol requires precomputation for most Ψ
[Allspice13]
⇒ Zebra amortizes precomputations over many V-P pairs
SLIDE 74 Architectural challenges and limitations
◮ Interaction between V and P requires a lot of bandwidth
⇒ Zebra uses 3D integration
◮ IP protocol requires precomputation for most Ψ
[Allspice13]
⇒ Zebra amortizes precomputations over many V-P pairs
◮ Several other details (see paper)
SLIDE 75 Roadmap
- 1. Problem statement: verifiable ASICs
- 2. Probabilistic proof systems, briefly
- 3. Zebra: a system for verifiable ASICs
- 4. Implementation and evaluation
SLIDE 76 Evaluation
How does Zebra perform on computations of “real world” interest?
◮ Number theoretic transform ◮ Curve25519 point multiplication
SLIDE 77 Evaluation
How does Zebra perform on computations of “real world” interest?
◮ Number theoretic transform ◮ Curve25519 point multiplication
Goal: V and P together should outperform Ψ executed in trusted substrate
SLIDE 78 Implementation and method
Zebra’s implementation includes
◮ a compiler that produces synthesizable Verilog for P ◮ two V implementations (software and Verilog) ◮ library to generate V’s precomputations ◮ Verilog simulator extensions to support either hardware and
software V interacting with P design
SLIDE 79 Implementation and method
Zebra’s implementation includes
◮ a compiler that produces synthesizable Verilog for P ◮ two V implementations (software and Verilog) ◮ library to generate V’s precomputations ◮ Verilog simulator extensions to support either hardware and
software V interacting with P design For our evaluation, we build a detailed cost model based on analysis, simulation results, and published chip designs (see paper)
SLIDE 80 Implementation and method
Zebra’s implementation includes
◮ a compiler that produces synthesizable Verilog for P ◮ two V implementations (software and Verilog) ◮ library to generate V’s precomputations ◮ Verilog simulator extensions to support either hardware and
software V interacting with P design For our evaluation, we build a detailed cost model based on analysis, simulation results, and published chip designs (see paper) Baseline: direct implementation of Ψ in same technology as V ⇒ Assumption: computation is efficient as an arithmetic circuit
SLIDE 81 Implementation and method
Zebra’s implementation includes
◮ a compiler that produces synthesizable Verilog for P ◮ two V implementations (software and Verilog) ◮ library to generate V’s precomputations ◮ Verilog simulator extensions to support either hardware and
software V interacting with P design For our evaluation, we build a detailed cost model based on analysis, simulation results, and published chip designs (see paper) Baseline: direct implementation of Ψ in same technology as V ⇒ Assumption: computation is efficient as an arithmetic circuit Metric: energy required to execute Ψ
SLIDE 82
Number theoretic transform
6 7 8 9 10 11 12 13 0.1 0.3 1 3 log2(NTT size) Performance relative to native baseline (higher is better)
SLIDE 83
Curve25519 point multiplication
84 170 340 682 1147 0.1 0.3 1 3 Parallel Curve25519 point multiplications Performance relative to native baseline (higher is better)
SLIDE 84
Recap
Zebra enables verifiable ASICs. + Untrusted P improves the performance of trusted V
SLIDE 85
Recap
Zebra enables verifiable ASICs. + Untrusted P improves the performance of trusted V + First built system in the probabilistic proof literature where total cost of V + P is better than baseline
SLIDE 86
Recap
Zebra enables verifiable ASICs. + Untrusted P improves the performance of trusted V + First built system in the probabilistic proof literature where total cost of V + P is better than baseline – But this improvement is modest
SLIDE 87
Recap
Zebra enables verifiable ASICs. + Untrusted P improves the performance of trusted V + First built system in the probabilistic proof literature where total cost of V + P is better than baseline – But this improvement is modest, – and Zebra has limitations:
does not apply to all computations precomputations must be amortized computation needs to be “big enough” needs large gap between trusted and untrusted technology
SLIDE 88
Recap
Zebra enables verifiable ASICs. + Untrusted P improves the performance of trusted V + First built system in the probabilistic proof literature where total cost of V + P is better than baseline – But this improvement is modest, – and Zebra has limitations:
does not apply to all computations precomputations must be amortized computation needs to be “big enough” needs large gap between trusted and untrusted technology
Zebra is a first step—there are plenty of improvements to be made!
https://eprint.iacr.org/2015/1243
