How to implement high-security in low-cost FPGAs

"Device DNA" can protect your design and embedded code from cloning, overbuilding, and reverse-engineering while still using outsourced manufacturing and assembly facilities.

in today’s global market, the competition is fierce. This makes first-to-market revenue gains key to fund R&D of new products which takes months, if not years, and millions of dollars of investments into the next generation products.

With more manufacturing, assembly, and testing now moving global and outside of a company’s facility to be done at contract manufacturers; security of the critical design and information has become a top priority. According to the International Anti-counterfeiting Bureau, US companies lost more than $200 billion in revenue in 2005 due to theft.

Traditional reverse-engineering used to be the most common security breach. This refers to the practice whereby systems are torn apart and design techniques are extracted to reduce the perpetrators R&D cost and time-to-market.

Today, designers have new threats to the security of products that include cloning and overbuilding. Cloning is simply the direct copying of a design, IP, or software, normally with no feature improvement and even with no time spent determining the design technique.

With minimal investment, this can provide the cloners with fast time-to-market and often direct replacement of the cloned product in the established customer base of the initial product. This ultimately allows the cloners to reap greater profits and offer lower cost products than the OEM.

The result can be to greatly reduce the original company’s market potential leaving them with reduced product revenue. The revenue lost to cloners is a permanent loss and is unrecoverable to the initial company.

Overbuilding occurs when a contract manufacturer or assembly house builds extra product and sells it without the knowledge or authorisation of the designing company. Overbuilding offers an even faster time-to-market than cloning. In fact, overbuilt products have even been known to hit the market prior to the original product! With no engineering investment or development cost, overbuilders receive the best profits and can offer the lowest product price. Overbuilding can result in much more than just revenue and market share loss. First, the original company has no idea how much “real” product is in the field. This makes the support burden difficult to manage and potentially much higher than they can manage. Secondly, if a company does not know if a product in the field is real or an exact duplicate, not only the support costs can get out of hand but several other factors come into play such as maintaining the product price in the market. Additionally, there’s no way to guarantee the same level of quality. This can significantly impact the bottom line with RMAs that need to be validated and processed. Another area that becomes a burden is product reliability.

With both overbuilding and cloning, it opens an enormous liability and responsibility on the company to weed out those products. If a company cannot control and weed out the “fake” units, their name, reputation and corporate image can be at stake, which can be significant in determining future sales and the company’s longevity.

Unique Device DNA

FPGA bit-stream protection can be effective against reverse engineering and even some cloning, but it leaves a potential gap when it comes to overbuilding. In order to protect designs from reverse engineering, cloning, and overbuilding there is the new “Device DNA” feature available only in members of the new Spartan-3A family from Xilinx.

The Spartan-3A is a low cost FPGA that addresses and increases the level of security at a design level. This security solution is far more robust and flexible than the older technology of bit-stream encryption. Bit-stream encryption does not stop a competitor or a thief from copying the information in the device and making multiple copies (cloned or overbuilt) which can then be sold.

One of the downsides to encryption is that the key is kept somewhere on the device. With device diagnostic techniques, the security can be broken or key can be found and defeated. Once the device security has been defeated all other products using that device are vulnerable.

The Device DNA design-level security used in members of the Spartan-3A family has many facets to improve the level of security across the whole design. This security protection can be used for many pieces of the design such as critical data, IP, embedded code, or the complete design.

The authentication algorithm is user-defined and implemented as part of the design for maximum flexibility; it allows the designer to choose the type of authentication algorithm, the level of security and the amount of logic used for security.

This flexibility not only allows the designer to change the security algorithm from model to model or generation to generation, but also during field upgrades, increasing the overall security and reducing the ability to reverse engineer the algorithm. The basic concept of Spartan-3A design level security can be compared to when you access an Automated Teller Machine (ATM); you insert your bank card (the Device DNA) and authenticate your identity by entering a Personal Identification Number (Authorisation Algorithm). If someone steals your ATM card, they cannot use it without also having your PIN number.

The weakness with ATM security is that if someone gains access to both your ATM card and your PIN number you can “kiss your cash goodbye.”

The PIN Authorisation algorithm number is easily cloned. This is why the authorisation algorithm is incorporated into the design itself. The algorithm is placed in the most secret location inside of programmable logic with millions of configuration options.

Implementation of Device DNA design level security

At the heart of the Spartan-3A design level security is the Device DNA. The device DNA is a unique ID for each FPGA device; this ID is essentially a non-volatile, permanently-programmed, factory-set serial number that is unchangeable and tamper-resistant.

The fact that the Device DNA number is different in every device allows a design to be authorised to just a single device. If someone tries cloning the design to a different Spartan-3A device, the DNA number would be different resulting in the design not being unauthorised.

The basic Device DNA is 57 bits in length and is designed with added flexibility so the designer can increase the security by increasing the bit length to any size desired. The Device DNA can be read via the “DNA_PORT” block from within the fabric of the Spartan-3A device. It can also be read externally by using the JTAG port and the appropriate JTAG commands. The output of the DNA_PORT is connected to the user defined authentication algorithm. So what is the authentication algorithm? Simply, it’s the designers secret! Something in the authentication process must be a secret, the algorithm being unknown is the key to the security.

The algorithm just becomes another group of configuration bits in the millions of configuration bits in the bit-stream. Unless you know how the bits fit together, or the algorithm, it’s just a mass of numbers to an onlooker or cloner for instance.

The authentication algorithms could be a simple DES, or Triple DES, AES 64, 128 or 256bit or even a fully customised polynomial algorithm that solve the security requirement at the appropriate cost.

For additional security, it is recommended to change at least the algorithm key from generation to generation of the design. The Spartan-3A FPGA configures from an associated configuration memory. The memory contains both the FPGA configuration bit-stream and a previously generated authorisation code. This code is stored in the memory by a trusted/secured manufacturer or registration process. The memory itself does not require any special features, just enough memory to contain both the FPGA bit-stream and the authorisation code. The Spartan-3A FPGA has an internal unique Device DNA value.

At power-up, the FPGA configures normally. Once configured the FPGA application includes circuitry that validates that the design is authorised to operate on the associated Spartan-3A FPGA. The Device DNA will be read by the authentication algorithm which in turns generates the active authorisation code that is compared to the previously generated authorisation code. If both codes are equal, the device is authenticated. Handling of failed authentication is one of the strengths of the Device DNA design level approach. The additional advantage of the authentication being integrated in to the design circuit is that multiple responses can result from an unauthorised design such as No functionality, Limited functionality, Time bomb, and Active defence. No functionality halts the operation of the design or stops the signals from leaving the Spartan-3A device. This is easily accomplished by connecting the authorisation circuit control to any of the global controls within the Spartan-3A family. Stopping the design operation can be achieved by asserting the global Set/Reset signal to put all the registers at ‘1’ or ‘0’ state, for example, or by turning all the outputs OFF with the global three state control, or even by disabling the clocks with the global clock enable or by asserting the digital clock manager (DCM) reset.

Limited functionality provides partial or basic functionality, with the real value “secret sauce” being bypassed or completely shut off. This approach helps protect from overbuilding. Manufacturing or assembly can build the systems but never get the generated authorisation code to save to the memory. So when the system is turned ON, the Spartan-3A device will be unauthorised and only partially functional. A time bomb allows an unauthorised design to operate full for a period of time. This approach can be of use in the case of manufacturing and assembly houses that need to have full functionality to verify the complete system. In this case, the test time (with some padding for tester setup) becomes the period of time the design operates before shutting down. This gives full testability but still stops overbuilding and cloning. Customers would not be happy with a system that has to be power cycled every 10 minutes for example. This approach can also make a potential attack significantly more difficult. If the system functions for awhile before failing, significantly more time is required to attack the system using a brute force approach. Similarly, using a random time-out value makes it difficult for an attacker to determine if he or she cracked the system or whether there is an inherent system design problem.

Active defence is where the system monitors actively and takes action to defend against attacks. The active defence can take many forms depending on the application requirements. For example, the application can track the number of failed authentication attempts.

Once the number of failed attempts reaches a pre-defined threshold, the application can take more drastic protection means such as erasing the configuration memory or permanently locking down sectors in a flash memory. The flexibility of Device DNA design level security does not stop with the design, but can be extended to protect the IP and even the embedded code. Corporate IP or IP suppliers can take advantage of the Device DNA by incorporating authentication right into their IP. This allows them to secure IP that may be used in multiple designs and not have to worry about each individual design protection of their valuable IP. IP suppliers can have a safe try before you buy program without having concerns of IP overbuilds. Also, IP suppliers have the ability to move their IP to a royalty based business model, providing pay-as-you-go solutions. Embedded microcode security is becoming the competitive system advantage as hardware and IP are standardised. Thus the need to secure embedded code is imperative to secure the value of the system. The Spartan-3A FPGAs’ Device DNA identifier provides an additional level of security for embedded applications.

The Device DNA forms a key used to encrypt and decrypt both code and data to protect an embedded processor application. The Spartan-3A Device DNA identifier forms a key to encrypt and decrypt both code and data.


The Spartan-3A FPGA family helps protect designs from cloning, overbuilding, and reverse-engineering with the use of Device DNA design level security. This security will protect the design along with IP, and even embedded data and code.

The Spartan-3A family offers the next generation of protection methodology while still offering the flexibility in the type of authentication algorithm and the amount of security at a cost to match the exact design requirements. Additional information and implementation details are available in the Spartan-3A Generation Configuration User Guide, which is available from

Mark Moran is a senior strategic marketing manager for the General Products Division at Xilinx. For Further information regarding Xilinx products, contact Nu Horizons Electronics Pty Ltd on Melbourne 03 97206444 or Sydney 02 97461411.

Leave a Reply