This application note focuses on SHA-256 authentication reference designs (RDs) using MAXREFDES34# for 1-Wire and MAXREFDES43# for I2C. Each of the reference designs (RD) describes either a Verilog® implementation of a state machine or a "C" bare-metal implementation in a microcontroller. Each implementation is tested on the corresponding FPGA demo board.
For 1-Wire® designs, the reference code defines a combined SHA-256 processor and 1-Wire master on the host FPGA. For I2C designs, the reference code defines a SHA-256 processor and utilizes existing FPGA I2C protocol. The RDs use one of the following secure authenticators:
To interface the Maxim secure authenticator IC with the FPGA demo board, each RD ships with a compatible plugin module—a Pmod™ port standard developed by Digilent, Inc. The corresponding IC is soldered onto the Pmod board. Regarding the 1-Wire designs, with minor tweaking a SHA-256 authenticator with larger memory density could be used, such as the DS28E22 or DS28E25.
The section Why Apply Security to an FPGA System? details important security concerns that designers face. The following section entitled Securing Your FPGA demonstrates how authentication actually secures FPGA systems.
Figure 1. Testing for authenticity with a challenge-and-response sequence.
One way to make the SRAM-based FPGAs more secure is to leverage multichip packaging and mount the nonvolatile (NV) memory inside a package along with the FPGA. Yet if someone opens the package, the data interface between the memory and the FPGA is exposed and the configuration pattern can be compromised. Multichip packaging can also be an expensive endeavor.
The structure of the configuration bit stream (i.e., the sequence of data elements and how they are coded and identified) is largely undocumented. The obscurity, complexity, and size of the bit stream make the reverse-engineering process difficult and time consuming, although theoretically possible. If successful, even partial reverse engineering of the configuration stream makes it possible to hack a set-top box to steal services or tamper with power-train settings in a vehicle, causing liability problems for the original manufacturer.
Xilinx 7-Series. High-end FPGAs protect internal IP by using security keys and bit-stream encryption. These protection mechanisms greatly mitigate the risk of the IP on the bit file being snooped. Furthermore, these FPGAs do not store sensitive data in insecure SRAM. However, implementing these built-in cryptographic security mechanisms can become cumbersome. Added manufacturing steps mean greater cost. But more importantly, if these cryptographic keys are programmed during contract manufacturing, then the subcontractor will know the keys and you can no longer be assured that your IP is safe.
Solution: In both the high- and low-end FPGAs, challenge-and-response authentication can be used to provide IP protection. An authentication sequence is added to the FPGA implementation code. If there is a Maxim secure authenticator with a valid security key on the bus, then the FPGA knows that the system is authentic. Specifically in the case of an FPGA with built-in security, using this IP protection solution could be an attractive alternative. A separate manufacturing step of programming the decryption key on an FPGA's OTP EPROM is not required; nor is a battery required to support secure BBRAM. In the Maxim alternative solution, the RD calls for the authentication key to be embedded securely into the FPGA implementation code so that the subcontractor would never know this key.
License Management. At other times, companies create and sell RDs. These are subsequently bought, licensed to, and manufactured by third parties. The RD vendors require barriers to prevent unauthorized use of the intellectual property. For revenue reasons, it is also necessary to track and confirm the number of reference uses.
Overbuild Protection. In all cases, designers might wish to build their end product using third-party contract manufacturing. Subcontractors can be a great extension of a supply chain, and they can manufacture embedded systems efficiently and cost effectively. However, less scrupulous contract manufacturers (CMs) have been known to build more widgets than contracted. Then they can produce bootleg products of the same quality and authenticity as the originals. Indeed, by overbuilding, an unscrupulous CM freeloads on all of the R&D and marketing costs that the designer incurred.
Solution. A practical solution for all three of these security issues is secure authentication. For Feature Management, device settings would only be stored in the user EEPROM of the secure authenticator, and a secure challenge and response would be required to read these settings. For License Management, a RD vendor would require a secure authenticator with a valid secret to be supplied to the licensee or third-party manufacturer. The RD would be made unable to operate without a secure challenge and response. Licensees would be supplied to the secure authenticator through one of two secure methods: 1) preprogrammed by the company licensing the reference, or 2) preprogrammed by Maxim per the licensing company's input and then delivered to the third-party manufacturer. In either case, the number of devices sent to the licensee or manufacturer is known and can be used to validate license fees. Overbuild Protection works just like License Management in that a contract manufacturer would only be able to build as many units as it can procure secure authenticators. A designer would be able to control how many authenticators that the CM can procure by working with Maxim.
For more information on all the potential applications of secure authentication, refer to application note 3675, "Protect Your R&D Investment with Secure Authentication."
To implement the authentication in the most secure manner, the following are used as general guidelines:
In the context of the FPGA environment, the way that the challenge-and-response authentication works is shown in the following numbered statements. The letters (e.g., A, B, C) correspond to data flows in Figure 2. This section describes SHA-256 symmetric authentication.
If the expected response and the actual response are identical, then the FPGA knows that the authenticator is genuine. If genuine, your security goals—IP protection, counterfeit protection, etc.—are achieved.
Figure 2. Challenge-and-response authentication flows in greater detail. Proves authenticity of hash originator—the secure authenticator.
As previously mentioned, authentication between an FPGA and a secure authenticator achieves the security of points 1 through 3 of the Why Apply Security to an FPGA? section. Now, let's observe how to physically set up a security system based on the following block diagrams.
To implement counterfeit protection, a system configuration, as shown in Figure 3, should be used. The FPGA, and its corresponding security implementation, resides in an embedded system. Some peripheral device—perhaps a sensor, disposable, consumable, or another embedded system—is the object that, as a designer, we wish to secure. The Maxim secure authentication IC resides in this peripheral device.
Figure 3. Block diagram for counterfeit protection of peripherals.
For all other security needs described in the section entitled, Why Apply Security to an FPGA?, the hardware setup shown in Figure 4 should be used. The FPGA, and its corresponding security implementation, resides in an embedded system along with the Maxim secure authentication IC.
Figure 4. Block diagram for IP protection, and other applications.Available Reference Designs
|Reference Design||FPGA||Demo Board||Implementation||Authentication IC Used||Interface of Authentication IC|
|Avnet® Spartan-6 LX9 MicroBoard||Verilog||DS28E15||1-Wire|
MAXREFDES43# with the DS28C22 is unique because it implements bidirectional, small-message encryption of sensitive data communicated between the FPGA and the DS28C22. This encryption feature is optional; the most common use is when the DS28C22 is inside an attached peripheral subsystem. Or, perhaps it is necessary to encrypt sensitive sensor data, calibration data, feature setting data, or personal data (e.g., patient heart rate or SSN).
For more information on the encryption feature of the DS28C22, refer to application note 5785, "Implement Heightened Security with a SHA-256 Master/Slave Authentication System."
MAXREFDES44# with the DS28E35 utilizes asymmetric ECDSA authentication instead of implementing symmetric SHA-256 authentication. For symmetric authentication, both the FPGA and authentication IC must store the same key, and therefore the sensitive secret key data resides on both sides of the system. However, with asymmetric authentication, the FPGA holds only the public key, and the DS28E35 holds the private key. The only sensitive data is the private key; the public key need not be secured.
Using asymmetric cryptography could be more attractive from two standpoints:
MAXREFDES34# with DS28E15 implements symmetric authentication using SHA-256. These authentication schemes require both the FPGA-side secret keys and secure authenticator keys to be secure. For the following reasons, the MAXREFDES34# successfully secures the FPGA-side secret keys:
Designers of FPGA embedded systems face many potential security threats including counterfeiting of peripherals and copying of FPGA implementation, among others. Using a Maxim secure authenticator along with either of these reference designs protects FPGA systems from these potential issues.