I know that FPGAS of Altera enables you to encrypt the RTL code while you work with it, what I can't understand is why it is really encrypted since once I have the FPGA, I can take it and with flash reader (theoratilcly) read the encoded RTL code, and read the KEY of the FPGA and then I have the code.

what do I miss?

  • 1
    If you have the KEY then you are able to reverse the encryption process because of the key. You really should be talking to people who extreme amount of knowlege with the FPGA equipment your asking about. – Ramhound Feb 22 '12 at 15:57
  • Does the FPGA read data from external device on boot. If so this data can be read. If fpga has a private key, then its public key can be used to encrypt the data. Then not even you can read it, only the fpga, Altera (they will hava a copy if the private key) and some one with an electron microscope can read it. [This is all speculation as to how this fpga works] – ctrl-alt-delor Feb 23 '12 at 13:35

First Part: the Altera FPGAs have some models that allow you to store keys in volatile and non-volatile memory.

Altera explain that they use AES with 128 or 256 bits. The private key is stored in the FPGA and the external memory have the data encrypted with the public key. In the boot-up, the data in read from the external memory, decrypted with the private key inside the FPGA, and then processed to configure all the following reads (think like a config header).

Source: http://www.altera.com/devices/fpga/stratix-fpgas/about/security/stx-design-security.html

Second Part: they have anti-tamper measures to prevent someone from doing exactly what you're afraid off. See: http://www.altera.com/literature/wp/wp-01111-anti-tamper.pdf

In general, it's "easy" to open the chip and brute-force extract each component position inside it, doing a kind of reverse-code attack. FPGA are programable, so an already programed and a virgin FPGA will look the same at the phisical level attack. And you end up destroying the programming when you try to open the chip and extract something from it.

And, to protect you from extracting the key, there's no function like *read_private_key* . You can write and overwrite it, but you can't extract it.


What you're missing is that FPGAs don't provide any interface to read out the key, and in theory make key extraction extremely hard by e.g. adding metal layers inside the chip or erasing the key when tampering is detected.

There's a very good paper called "Side-Channel Attacks on the Bitstream Encryption Mechanism of Altera Stratix II" (Moradi, Oswald, Paar, Swierczynski) describing the attack on an encrypted bitstream of an older Altera Stratix II FPGA. The authors outline that while breaking such protection could have been very hard in theory, it's in fact surprisingly easy in practice due to very naive implementation issues such as:

  • using current PC time as the primary source of randomness
  • naively hiding the key material by spreading it inside a 40-byte array and storing two bits per byte
  • leaving debug information inside the crypto DLL
  • using a symmetric chipter (AES) for key derivation instead of a unidirectional function which makes key derivation trivially reversible
  • accepting external configuration clock which can be made arbitrarily slow so that the number of flipped bits in each decryption round can be trivially seen by looking at power consumption

Things have obviously improved since then, but in general FPGA bitstream crypto still remains a poorly reviewed / audited area which largely relies on obscurity.


From the bitstream to the netlist: http://www.univ-st-etienne.fr/salware/Bibliography_Salware/FPGA%20Bistream%20Security/Article/Note2008.pdf

FPGA Bitstream Security Broken: http://beta.slashdot.org/story/155120

if you want to devote time, a lot of it, then you can reverse-engineer FPGA's. Using differential power analysis (DPA) to retrieve the security key at power-up, then read the bitstream, reverse that to the netlist, then analyse that until you know the design or just clone it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.