The present disclosure relates to securely upgrading field programmable devices, such as Field Programmable Gate Arrays (FPGAs).
FPGAs are widely used in devices that have been deployed in the field, e.g., within host devices that are installed in fixed locations such as in data center electronics, network devices and mobile devices such as cellular phones and tablet devices. Field programmable devices, e.g., FPGAs, offer advantages over other approaches such as one-time programmable devices in that they are reconfigurable or reprogrammable during startup of their host device. Field programmable devices are typically programmed at the time of manufacture, with software upgrades having new features and bug fixes distributed at a later date. In order to upgrade a field programmable device, a new software image or bitstream is downloaded to the field programmable device. New image downloads often occur over a network from a remote location or locally at the host device itself.
One issue with providing field programmable device upgrades from a remote location is the security of the image during transit. In such situations, it is possible to intercept the image during transit. In other scenarios, a would-be hacker can extract the image from the physical hardware or steal encryption keys. Many field programmable devices run software that is the product of many man-years of software development and represents a significant cost to the device manufacturer. In order to secure the field programmable device image, a symmetric key is stored in the field programmable device and used to decrypt either stored or upgraded images. Thus, all of the devices manufactured for a particular host device model or in a particular timeframe have the same symmetric key. If the symmetric key is compromised, then all devices with that key are potentially compromised. One solution to this problem is to provide device specific keys. However, device specific keys require complex key management for which many manufactures are not willing to support, or to take the risk of lost keys.
a and 3b illustrate an example of a flowchart for operations at a device with an FPD for upgrading the FPD.
In one embodiment, a method includes receiving a first encrypted software image configured to program a field programmable circuit or device in a computing device that contains the field programmable circuit, wherein a plurality of keys are stored in the computing device. The first encrypted software image is encrypted using a first key that corresponds to one of the plurality of keys. The first encrypted software image is decrypted using a second key of the plurality of keys to obtain a software image. The software image is encrypted using a third key of the plurality of keys to generate a second encrypted image. The second encrypted software image is stored in a storage device configured to provide the second encrypted software image to the field programmable circuit.
The first encrypted image may be further signed with an associated digital signature, where the digital signature is verified upon receipt at the computing device in order for the field programmable circuit software image to be upgraded. The computing device is booted up and the second encrypted software image is loaded into the field programmable circuit. The second encrypted software image is decrypted using a fourth key of the plurality of keys to obtain the software image. The first and second keys may comprise a public/private key pair according to a Public Key Encryption (PKI) scheme, and the third and fourth keys may comprise symmetric keys or a public/private key pair.
Thus, computing device 100 may take any of a variety of forms, so as to be encoded in one or more tangible (e.g., non-transitory) storage media for execution, such as with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and any processor may be a programmable processor, programmable digital logic (e.g., an FPGA) or an ASIC that generally comprises fixed digital logic, or a combination thereof. In general, software may be embodied in a processor readable medium that is encoded with instructions for execution by a processor that, when executed by the processor, are operable to cause the processor to perform the functions described herein.
Processor 110 and tamper proof chip 130, as, well as FPD 140 and PROM 150, may form a Trusted Computing Base (TCB). A TCB of a computer system, e.g., device 100, is the set of all hardware, firmware, and/or software components that provides a secure computing environment. In this regard, the tamper proof chip 130 may be a tamper proof cryptography chip (TPCC) that securely stores authentication, encryption keys, and decryption keys. The keys stored on tamper proof chip 130 may be supplied to processor 110 and FPD 140 for the authentication, encryption, and decryption techniques described herein. In another example, certain aspects of the authentication, encryption, and decryption techniques may be performed on tamper proof chip 130.
It is noted that the functionality described herein for computing device 100 is generally implemented as part of an embedded device such a cell phone or a network router. The techniques may also be implemented by non-embedded applications such as general purpose computers for which field programmable software images need to be securely downloaded during upgrade. The downloads may be performed over various network types, e.g., over a wireless or wireline network such as a Wide Area Network (WAN) or a Local Area Network (LAN), or network subset such as a Virtual Private Network (VPN) via one of networks interfaces 125.
Turning now to
At 220, an upgrade software image is generated for programming the programmable processing device, e.g., field programmable device 140. The upgrade image is typically developed by engineers to solve software defects (bugs) or to add new features. The image is typically be tested in a test lab facility and passed to a marketing or upgrade team. At 230, the image is encrypted using a first key (e.g., a shared public key) to obtain a first encrypted image. Although a public key is generally referred to in the context of a Public Key Infrastructure (PKI) scheme (for private key decryption), other encryption mechanisms may be employed.
At this point, process 200 may branch, and the first encrypted image may be sent to the computing device, or optionally, the first encrypted image is digitally signed prior being sent. At 240, the first encrypted image is sent to the computing device, e.g., to computing device 100. From 240, the process continues to 310 in
In order to send or download the first encrypted or signed image, any number of techniques may be employed. For example, the Trivial File Transfer Protocol (TFTP) may be used to transfer the encrypted image from a remote location to computing device 100 when computing device 100 is in a fixed location, e.g., routers and switches in a data center. The Simple Network Management Protocol (SNMP) may be used to manage computing device 100 during download. In one example, the new image may be stored in one section of partitioned NVM or in one of several NVMs such that the previous image version remains stored. The SNMP can be used to switch a pointer to point to the new image for use the next time the computing device is started or booted. Should an operational issue occur when executing the new image, the computing device can be switched back to the previous image. In another example, a user may connect a portable device, e.g., a cell phone or music player, to a general purpose computer such as a Personal Computer (PC). The upgrade image may then be downloaded via a web page or a device specific application running on the PC.
Referring now to
In
After a period of time or immediately after the second encrypted image is stored, the second part of FPD Update Manager software 300, i.e., as depicted by flowchart 300b shown in
The techniques described in connection with process 200 and operations of software 300 provide a solution to existing security problems when upgrading field programmable devices. The security of FPGAs is relied upon to provide additional security of larger systems. Issues such as image counterfeiting and reverse engineering have led FPGA vendors to implement mechanisms such as bitstream encryption to secure an FPGA image when it is stored external to the FPD, e.g., in Static Random Access Memory (SRAM) based FPGAs. Bitstream encryption provides encryption, or encryption and authentication for the FPGA configuration to ensure that an external entity can not reverse engineer the bitstream and obtain the intellectual property contained therein. Additionally, encryption can help prevent counterfeiting because a key is needed to decrypt the bitstream, yet the key is held by the manufacturer and within the FPGA. A stolen bitstream may be loaded onto another device and exploit the advances of the intellectual property in the stolen FPGA image exploited.
In a typical bitstream encryption scheme, the bitstream is the firmware that programs the FPGA logic. In many FPGAs, the image is loaded into the FPGA at every power up of the device. The FPGA vendor provides a capability to insert a symmetric key into an FPGA (typically during manufacturing). The same symmetric key is used to encrypt the bitstream produced during development (tooling) by the FPGA vendor. Therefore, when the bitstream is programmed into a flash part or delivered to the system, it is encrypted with this symmetric key and ‘protected’ from being cloned or modified on that product. This form of protection exists, in part, because the FPGA itself uses a bitstream decryption key to decrypt and obtain the bitstream.
A problem with the existing bitstream encryption solutions used by FPGA vendors is in many cases they rely on cryptographic operations based on private keys stored within the FPGA itself. FPGAs and other programmable devices are typically poorly equipped to protect either keys or attacks on the cryptographic operations themselves, e.g., by way of side channel attacks. This weakness exists regardless of the type of cryptography used, e.g., symmetric or asymmetric.
There are tradeoffs that vendors face when choosing to activate a bitstream encryption scheme to protect an FPGA bitstream. Once activated, an FPGA cannot use a non-encrypted bitstream. There are two deployment models used today with bitstream encryption. With a first model, the vendor inserts a unique symmetric key into each FPGA at the time of manufacturing and then encrypts each FPGA image. The manufacturer is required to maintain these unique keys so that if a field upgrade of the FPGA bitstream is needed, each unique key can be used to deliver a uniquely encrypted bitstream to the device in the field. Thus, to be able to maintain per device keys, individually encrypted images are delivered. In a high volume operation, individual encryption becomes untenable.
With a second model, the vendor uses the same symmetric key across multiple devices, e.g., typically across a product line. The bitstream key per product line model has the weakness that if the symmetric key of a single product in a product line is ever compromised, then the entire product line is compromised.
Furthermore, new forms of hacker attacks have and are being developed. For example, side channel attacks that rely on differential power analysis are used to extract the symmetric key. Once the symmetric key is extracted, reprogramming of the device by a thief is possible, and if the same bitstream encryption key is used across every product in a product line (e.g., as the only viable use case for commercial vendors to employ), then entire product line is compromised.
The techniques described herein solve both of the above-described issues. By storing the appropriate keys on the host device, unique keys can be used for each field programmable device. Namely, a unique symmetric key can be programmed into each FPGA, thereby conserving FPGA logic and permitting manufacture of large volumes of FPGAs. In other words, each FPD has a unique symmetric key for encryption and decryption of the image executed by the FPGA. The unique symmetric key is not used in any other FPGA and may be stored in the host device or the FPGA itself, or both. It should be understood that while symmetric key cryptography is described herein in connection with FPGA or FPD cryptographic operations, any type of cryptography may be used, e.g., asymmetric key cryptography such as PKI.
Referring to
At 430, the product manufacturer develops a new FPD image that includes new features and/or fixes to software defects. The product manufacturer may send the new FPD image to a server for download or to an FPD deployment team. The image may be upgraded by the field deployment team, e.g., for devices under control and ownership of the computing device. Alternatively, individual devices may be upgraded by individual device owners, e.g., directly by way of a server or a web browser initiated download that acts a convenient user interface.
At 440, the developer of the new FPD image makes the image available to the end user. In the case that many devices are to be upgraded within a short timeframe, a field deployment team may be used for the multi-device upgrade, e.g., using a multicast broadcast. Regardless of the environment, the new FPD image is encrypted and optionally signed. The image is delivered to devices, e.g., using SNMP.
At 450, a deployed device receives the new upgrade FPD image. If the image is signed, it is authenticated by the deployed device. The new FPD image is decrypted, e.g., using a stored private key. The new FPD image is re-encrypted using a symmetric key. By virtue of being a symmetric key, it is the same symmetric key that may be stored on the FPD. Once re-encrypted, the new re-encrypted FPD image is stored in memory, e.g., a configuration PROM. When the FPD is restarted, e.g., by a power up or external command, the re-encrypted image is loaded into the FPD. The re-encrypted image is decrypted, e.g., using the symmetric key. Accordingly, a unique symmetric key can be stored on the FPD and/or the TPCC.
To summarize, techniques are presented herein for securely upgrading an FPD, while enabling a unique, per FPD, key. Tamper proof chips are much more secure for cryptographic processing than are FPGAs. As a result, by combining tamper proof chips with FPGAs via an FPGA update manager, the bitstream encryption capabilities can be leveraged without creating unsupportable complexity or creating a single point of exposure via the FPGAs.
Thus, a method is provided comprising receiving a first encrypted software image configured to program a field programmable circuit in a computing device that contains the field programmable circuit, wherein a plurality of keys are stored in the computing device, and wherein the first encrypted software image is encrypted using a first key that corresponds to one of the plurality of keys; decrypting the first encrypted software image using a second key of the plurality of keys to obtain a software image; encrypting the software image using a third key of the plurality of keys to generate a second encrypted image; and storing the second encrypted software image in a storage device configured to provide the second encrypted software image to the field programmable circuit.
An apparatus is provided comprising a field programmable circuit; an image storage circuit configured to store software images for programming the field programmable circuit; a key storage circuit configured to store a plurality of keys; a network interface device configured to enable communications over a network and to receive a first encrypted software image configured to program the field programmable circuit, wherein the first encrypted software image is encrypted using a first key that corresponds to one of the plurality of keys; and a processor. The processor is configured to decrypt the first encrypted software image using a second key of the plurality of keys to obtain a software image; encrypt the software image using a third key of the plurality of keys to generate a second encrypted image; and store the second encrypted software image in the image storage circuit.
Further still, a processor readable storage media is provide that is encoded with instructions that, when executed by a processor, cause the processor to receive a first encrypted software image configured to program a field programmable circuit in a computing device that contains the field programmable circuit, wherein a plurality of keys are stored in the computing device, and wherein the first encrypted software image is encrypted using a first key that corresponds to one of the plurality of keys; decrypt the first encrypted software image using a second key of the plurality of keys to obtain a software image; encrypt the software image using a third key of the plurality of keys to generate a second encrypted image; and store the second encrypted software image in a storage device configured to provide the second encrypted software image to the field programmable circuit.
The above description is intended by way of example only.