Trusted Design In FPGAs by tvHU28l4


									Trusted Design In FPGAs

      Steve Trimberger
     Xilinx Research Labs
      During base array design and manufacture
         Same as custom device design and manufacture
         Do you trust your suppliers?
         But FPGA application functionality is
          not 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?

    The IC Manufacturing Flow

          Design         Concerns:
                            Theft of the design
       Mask making          Overbuilds
                            Tampering with
     Wafer fabrication       the design
                         Challenges: securing
        Sort (test)      the design
                            Through all phases
                            For all parties
        Final test          For months of
                             elapsed time

    FPGA Flow
     Sensitive algorithm is in       Non-Secure Manfacturing Facility
     the programming.
     It is not exposed through
     the manufacturing
     process.                              Generic FPGAs

     It can be loaded into the       Secure Facility
     device at a trusted facility.       Add Secret
     The “secret sauce” never
     leaves your basement in
     the clear.                      Non-Secure Environment
     The IC manufacturing
     problem evaporates, but
     we must still secure the
     design in the field.
    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

    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

    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

    The Silicon View: Hardware-Enforced
     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 after
          encrypted 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

    Check Designs in the Field
     ICAP – Internal Configuration Access Port
     Manage self-
         Read back

         Check configuration
          against ECC bits
         Fix configuration

     Trust Verification for FPGA Design Tools

      Compare extracted
      netlist with expected         Design
          Network comparison
                                   Merge IP
          Formal verification     Libraries

      Detects tool “defects”      Place and
      Detects bad libraries

                                 Extract netlist   Compare

     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 devices
     to attack.
         Most (nearly all) FPGAs will not be used in
          sensitive applications.
         Large numbers can be (destructively) tested.
         Statistical assurance has better statistics.
     Thorough checking, if needed, can be focused
     on the security logic.

     Concluding Remarks

      Key observation: FPGA programming does
      not go through the IC manufacturing process.
      FPGAs change design trust in the field from
      a physical security issue to an information
      security issue.
      Known solutions to the information
      security problem have been applied to
      FPGA bitstreams.


To top