51–60 of 93 posts
Getting your hands to raw gate configuration helps with cloning. It's pita to reverse engineer.
Any device that uses Xilinx 7 or Virtex 6 SPI or BPI Flash remote update is potentially fucked. There is HMAC in bitstream and no other authentication.
Earlier quoted context omitted.
> But if an attacker is already "inside" your system [...] I think you have already lost... It's not necessarily true. Protecting the system from physical attackers is a legitimate requirement in cryptography. 1. While all hardware secrets can be broken with physical access, but there's a different in cost, cost and cost. A commercial HSM - used by CAs, businesses, banks to hold private keys - contains RF shields, te…
> A commercial HSM - used by CAs, businesses, banks to hold private keys - contains RF shields, temper-detection switches, sensors for X-ray, light, temperature, battery-backed SRAM for self-destruction, and so on, it's extremely unlikely that anyone has ever succeeded to break into a HSM A service to lift firmware from Gemalto chips used in SIM, and credit cards costs $25k here at most
Earlier quoted context omitted.
This attack breaks the encrypted and authenticated bitstream. I thought that the title "A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs" would give some information even for those who don't want to read the article before commenting. :)
As the paper explains, the attack requires alternately tampering with the encrypted bitstream (to write one word of the decrypted data at a time to a non-volatile register) and then resetting the FPGA and loading a separate, attacker-created, unencrypted bitstream to read that register's contents. I don't know enough about Xilinx FPGAs to definitively say whether setting the fuse that OP mentions would prevent the at…
>3.4 Attack 2: Breaking Authenticity
>Therefore the attacker can encrypt an arbitrary bitstream by means of the FPGA as a decryption oracle. The valid HMAC tag can also be created by the attacker, as the HMAC key is part of the encrypted bitstream. Hence, the attacker can set his own HMAC key inside the encrypted bitstream and calculate the corresponding valid tag. Thus, the attacker is capable of creating a valid encrypted bitstream, meaning the authenticity of the bitstream is broken as well
I don't know what the best prctices are now, but it used to be best practice to blow the CFG_AES_Only eFUSE when using bitstream protection, which prevents the loading of a bitstream which isn't authenticated, and thus foils this attack. If a manufacturer went to the trouble of encrypting the FPGA but then allowed loading of plaintext bitstreams they probably didn't really understand what they were doing.
This attack breaks the encrypted and authenticated bitstream. I thought that the title "A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs" would give some information even for those who don't want to read the article before commenting. :)
As the sibling comment mentions, the attack requires programming a plaintext bitstream in order to perform the readout of the WBSTAR register after the automatic reset caused by the HMAC authentication failure. Blowing the CFG_AES_Only eFUSE prevents the loading of that plaintext readout bitstream and the first stage of the attack is thus foiled (preventing the second stage of the attack from taking place as well).
Earlier quoted context omitted.
This attack breaks the encrypted and authenticated bitstream. I thought that the title "A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs" would give some information even for those who don't want to read the article before commenting. :)
While I understand that without the proper context (knowing a bit about bitstream protection in the Xilinx 7-Series FPGAs) my comment may seem a bit obscure, I did read the paper. As the sibling comment mentions, the attack requires programming a plaintext bitstream in order to perform the readout of the WBSTAR register after the automatic reset caused by the HMAC authentication failure. Blowing the CFG_AES_Only eFUS…
Earlier quoted context omitted.
As the paper explains, the attack requires alternately tampering with the encrypted bitstream (to write one word of the decrypted data at a time to a non-volatile register) and then resetting the FPGA and loading a separate, attacker-created, unencrypted bitstream to read that register's contents. I don't know enough about Xilinx FPGAs to definitively say whether setting the fuse that OP mentions would prevent the at…
Attack can be used to encrypt bitstreams also. >3.4 Attack 2: Breaking Authenticity >Therefore the attacker can encrypt an arbitrary bitstream by means of the FPGA as a decryption oracle. The valid HMAC tag can also be created by the attacker, as the HMAC key is part of the encrypted bitstream. Hence, the attacker can set his own HMAC key inside the encrypted bitstream and calculate the corresponding valid tag. Thus,…
> With the first attack, the FPGA can be used to decrypt arbitrary blocks. Hence, it can also be seen as a decryption oracle. Thus,we can also use this oracle to encrypt a bitstream, as shown by Rizzo and Duong in [41], and generate a valid HMAC tag
This requires the first stage of the attack to succeed. If it fails and the FPGA cannot be used as a decryption oracle, there's no way to generate a valid encrypted bitstream with the technique outlined in the paper.
Earlier quoted context omitted.
While I understand that without the proper context (knowing a bit about bitstream protection in the Xilinx 7-Series FPGAs) my comment may seem a bit obscure, I did read the paper. As the sibling comment mentions, the attack requires programming a plaintext bitstream in order to perform the readout of the WBSTAR register after the automatic reset caused by the HMAC authentication failure. Blowing the CFG_AES_Only eFUS…
That was the first attack. How about the second attack where they show how to encrypt a bitstream?
This isn't bad for "security" or "secure microcontrollers." It is in fact good for security. Designs running on these FPGAs can now be analyzed and inspected for accidental or intentional security issues. Mind you: the security issues are there whether you know about them or not. The function that the FPGA implements can (and should) still be secure - since the security of its algorithms should never rely on the secr…
This encryption is the only way that you can ensure the integrity of the firmware at the chip level so anything relying on that as part of their chain of trust is going to have to redesign their device now. Firmware is loaded from an external eeprom on these devices DRM wasn't the sole use of this feature.
Also, encryption never ensures integrity; it ensures confidentiality. Integrity would've come from the accompanying signature scheme, which apparently was badly implemented and broken at the same time.
If anything, the encryption makes it impossible to conduct spot checks on a batch of devices you receive, since it prevents the end user from verifying bitstream integrity. (The keys are device specific AFAIK, so the bitstream is device specific too, and signature public keys aren't known.) To establish trust, you ideally need an unencrypted, verifiable, signed bitstream.
(An encrypted, signed bitstream with the keys available does not protect against manufacturer collusion; they can cooperate in sending you a tampered device. An unencrypted bitstream allows comparing a device you received against other devices around the planet.)
Earlier quoted context omitted.
The way to protect secure hardware tokens is not bitstream encryption, it's tamper protection. You store the key material in SRAM that is erased when the device detects any attempt at manipulating. If your Bitcoin Wallet or whatever token is affected by this, it was IMHO badly designed to begin with, since apparently it was relying on an AES-CBC bitstream encryption scheme. That should've been a red flag even if it w…
> The way to protect secure hardware tokens is not bitstream encryption, it's tamper protection. You store the key material in SRAM that is erased when the device detects any attempt at manipulating. You need both. First, make all external storage (that hold keys, firmware, configurations) unreadable to everything else besides the main processor itself. Also, in the ideal world, implement tamper detection, in most HS…