How does the encryption of FPGA works?

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.