Trusted Design In FPGAs

2. Trusted Design In FPGAs Steve Trimberger Xilinx Research Labs

3. Vulnerabilities • During base array design and manufacture • Same as custom device design and manufacture • Do you trust your suppliers? • But FPGA application functionality isnot exposed • During application design • Same as custom device design • Do you trust your tools and libraries? • During deployment • Same as software • Bitstream piracy • Loading malicious bitstream • Do you trust your customers?

4. Design Mask making Wafer fabrication Sort (test) Packaging Final test The IC Manufacturing Flow • Concerns: • Theft of the design • Overbuilds • Tampering withthe design • Challenges: securing the design • Through all phases • For all parties • For months ofelapsed time

5. FPGA Flow Non-Secure Manfacturing Facility • Sensitive algorithm is in the programming. • It is not exposed through the manufacturing process. • It can be loaded into the device at a trusted facility. • The “secret sauce” never leaves your basement in the clear. • The IC manufacturing problem evaporates, but we must still secure the design in the field. Generic FPGAs Secure Facility Add Secret Bitstream Non-Secure Environment

6. The Hostile Field Environment • The attacker has physical access to the FPGA in the end system • The attacker can observe the bitstream • The attacker can tamper with the bitstream as it is being loaded • The attacker can observe the operation of the configured device • The attacker is a commercial entity • Resources limited by potential gain

7. Xilinx Bitstream Security Goals • What we intended to do: • Prevent unauthorized copy • Prevent reverse engineering • “Prevent ” means “Make it expensive” • What we didn’t intend to do: • Enable a cores business • Restrict access to the FPGA • Prevent malicious damage • What were our worries? • Security holes • Testing

8. Bitstream Security Methods • Plan A: program once, ship without external configuration storage • Battery backup • Plan B: Bitstream Encryption (since Virtex-II) • Virtex-II and Virtex-II Pro: 3DES • Virtex-4, Virtex-5: AES256 • Keys erased if tampered • Battery backup • HW enforced restrictions

9. The Silicon View: Hardware-Enforced Restrictions • No readback if encryption used. • No partial configuration if encryption used. • Decrypted configuration must be alone inside the FPGA • No warm re-configuration if encryption used. • Configuration cleared before and afterencrypted bitstreams. • An attempt to access keys clears the keys and configuration data. • Data integrity check of decrypted data assures no modification of encrypted bitstreams. • The decryptor is not available for encrypting or decrypting user’s data after configuration

10. Check Designs in the Field ICAP – Internal Configuration Access Port • Manage self-reconfiguration • Introspection • Read back configuration internally • Check configuration against ECC bits • Fix configuration errors ICAP

11. Design Merge IP Libraries Synthesis, Place and Route Extract netlist Compare Trust Verification for FPGA Design Tools • Compare extracted netlist with expected netlist • Network comparison • Formal verification • Detects tool “defects” • Detects bad libraries

12. Trust of the Base Array is Easier • The secret part of the design is not in others’ hands for months during manufacture. • An attacker does not know which devicesto attack. • Most (nearly all) FPGAs will not be used insensitive applications. • Large numbers can be (destructively) tested. • Statistical assurance has better statistics. • Thorough checking, if needed, can be focusedon the security logic.

13. Concluding Remarks • Key observation: FPGA programming does not go through the IC manufacturing process. • FPGAs change design trust in the field froma physical security issue to an information security issue. • Known solutions to the informationsecurity problem have been applied toFPGA bitstreams.