Verifiable ASICs: trustworthy hardware with untrusted components

Transcription

1 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 The University of Virginia April 8, 2016

2 You (probably) shouldn t trust your hardware...

3 You (probably) shouldn t trust your hardware...

4 You (probably) shouldn t trust your hardware...

5 You (probably) shouldn t trust your hardware because fabs sometimes make mistakes

6 You (probably) shouldn t trust your hardware because fabs sometimes make mistakes [Tehranipoor and Koushanfar. A survey of hardware Trojan taxonomy and detection. IEEE DTC, 2010.]

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 ]

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 ]

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 ]

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 10 8 worse performance! [Bhunia, Hsiao, Banga, and Narasimhan. Hardware Trojan attacks: threat analysis and countermeasures. Proc. IEEE, Aug ]

11 Roadmap 1. Problem statement: verifiable ASICs 2. Probabilistic proof systems, briefly 3. Zebra: a system for verifiable ASICs 4. Implementation and evaluation

12 Roadmap 1. Problem statement: verifiable ASICs 2. Probabilistic proof systems, briefly 3. Zebra: a system for verifiable ASICs 4. Implementation and evaluation

13 Problem statement: verifiable ASICs Principal Ψ specs for P,V

14 Problem statement: verifiable ASICs Supplier (foundry, processor vendor, etc.) Principal Ψ specs for P,V Foundry

15 Problem statement: verifiable ASICs Supplier (foundry, processor vendor, etc.) V Principal Ψ specs for P,V Integrator P Foundry

16 Problem statement: verifiable ASICs Supplier (foundry, processor vendor, etc.) Principal Ψ specs for P,V Integrator Foundry Operator V P

17 Problem statement: verifiable ASICs Operator V P

18 Problem statement: verifiable ASICs Operator V x P

19 Problem statement: verifiable ASICs Operator V x y P

20 Problem statement: verifiable ASICs Operator V x y proof P

21 Problem statement: verifiable ASICs Operator V x y proof P P is efficient, but can deviate arbitrarily from the protocol

22 Problem statement: verifiable ASICs Operator V x y proof P P is efficient, but can deviate arbitrarily from the protocol Honest P always convinces V that y = Ψ(x)

23 Problem statement: verifiable ASICs Operator V x y proof P 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

24 Problem statement: verifiable ASICs Operator V x y proof P 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 outside world (see paper for more discussion)

25 Problem statement: verifiable ASICs Operator V x y proof P 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 outside world (see paper for more discussion) Goal: V and P together should outperform Ψ executed in trusted substrate

26 Roadmap 1. Problem statement: verifiable ASICs 2. Probabilistic proof systems, briefly 3. Zebra: a system for verifiable ASICs 4. Implementation and evaluation

27 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover verifier prover program, inputs outputs [Walfish and Blumberg. Verifying computations without reexecuting them: from theoretical possibility to near practicality. CACM, Feb ]

28 Probabilistic proof systems, briefly A weak verifier checks the work of a powerful prover verifier prover program, inputs outputs + 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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

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 generalized boolean circuit over F p + 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 ]

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 ]

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 layered vs. unlayered 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 ]

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 depth = 3 width = 8 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 ]

40 Roadmap 1. Problem statement: verifiable ASICs 2. Probabilistic proof systems, briefly 3. Zebra: a system for verifiable ASICs 4. Implementation and evaluation

41 Zebra s starting point: Interactive proofs Zebra is an IP-based protocol [CMT12, Allspice13] (We discuss why not arguments in the paper)

42 Zebra s starting point: Interactive proofs

43 Zebra s starting point: Interactive proofs 1. V sends inputs

44 Zebra s starting point: Interactive proofs 1. V sends inputs 2. P evaluates circuit, returns output y

45 Zebra s starting point: Interactive proofs 1. V sends inputs 2. P evaluates circuit, returns output y

46 Zebra s starting point: Interactive proofs 1. V sends inputs 2. P evaluates circuit, returns output y

47 Zebra s starting point: Interactive proofs 1. V sends inputs 2. P evaluates circuit, returns output y y

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

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 4. V cross-examines P

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 4. V cross-examines P, ends up with claim about second-last layer

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 4. V cross-examines P, ends up with claim about second-last layer 5. V iterates

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 4. V cross-examines P, ends up with claim about second-last layer 5. V iterates

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 4. V cross-examines P, ends up with claim about second-last layer 5. V iterates

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 4. V cross-examines P, ends up with claim about second-last layer 5. V iterates, ends up with claim about inputs

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 4. V cross-examines P, ends up with claim about second-last layer 5. V iterates, ends up with claim about inputs 6. V checks consistency with the inputs

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 4. V cross-examines P, ends up with claim about second-last layer 5. V iterates, ends up with claim about inputs 6. V checks consistency with the inputs V s work is O(depth log width)

57 Pipelined proving in Zebra V questions P about Ψ(x 1 ) s output layer. Ψ(x 1 )

58 Pipelined proving in Zebra V questions P about Ψ(x 1 ) s output layer. Simultaneously, P returns Ψ(x 2 ). Ψ(x 2 ) Ψ(x 1 )

59 Pipelined proving in Zebra V questions P about Ψ(x 1 ) s next layer Ψ(x 1 )

60 Pipelined proving in Zebra V questions P about Ψ(x 1 ) s next layer, and Ψ(x 2 ) s output layer. Ψ(x 1 ) Ψ(x 2 )

61 Pipelined proving in Zebra V questions P about Ψ(x 1 ) s next layer, and Ψ(x 2 ) s output layer. Meanwhile, P returns Ψ(x 3 ). Ψ(x 3 ) Ψ(x 1 ) Ψ(x 2 )

62 Pipelined proving in Zebra This process continues until the pipeline is full. Ψ(x 1 ) Ψ(x 2 ) Ψ(x 3 ) Ψ(x 4 )

63 Pipelined proving in Zebra This process continues until the pipeline is full. Ψ(x 1 ) Ψ(x 2 ) Ψ(x 3 ) Ψ(x 4 ) Ψ(x 5 )

64 Pipelined proving in Zebra This process continues until the pipeline is full. V and P can complete one proof in each time step. Ψ(x 1 ) Ψ(x 2 ) Ψ(x 3 ) Ψ(x 4 ) Ψ(x 5 ) Ψ(x 6 ) Ψ(x 7 ) Ψ(x 8 )

65 Other hardware optimizations V Input (x) queries responses queries responses queries responses Sub-prover, layer d 1 prove.. Sub-prover, layer 1 prove Sub-prover, layer 0 prove P Output (y)

66 Other hardware optimizations Proving machinery Sub-prover circuit P s work is mainly local to each gate

67 Other hardware optimizations Sub-prover circuit Remaining sub-prover machinery gate prover gate prover gate prover gate prover P s work is mainly local to each gate P s design leverages this with gate prover circuits

68 Other hardware optimizations Sub-prover circuit Remaining sub-prover machinery gate prover gate prover gate prover gate prover 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

69 Other hardware optimizations Sub-prover circuit Remaining sub-prover machinery gate prover gate prover gate prover gate prover 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)

70 Architectural challenges and limitations Interaction between V and P requires a lot of bandwidth

71 Architectural challenges and limitations Interaction between V and P requires a lot of bandwidth Zebra uses 3D integration

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]

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

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)

75 Roadmap 1. Problem statement: verifiable ASICs 2. Probabilistic proof systems, briefly 3. Zebra: a system for verifiable ASICs 4. Implementation and evaluation

76 Evaluation How does Zebra perform on computations of real world interest? Number theoretic transform Curve25519 point multiplication

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

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

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)

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

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 Ψ

82 Number theoretic transform Performance relative to native baseline (higher is better) log 2 (NTT size)

83 Curve25519 point multiplication Performance relative to native baseline (higher is better) Parallel Curve25519 point multiplications

84 Recap Zebra enables verifiable ASICs. + Untrusted P improves the performance of trusted V

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

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

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

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!