3 ms·

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

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 secrecy thereof. (And to protect secrecy of private key material, it comes down to physical security either way.) What it's bad for is vendors relying on DRM to protect their assets. Which is normally diametrically opposed to user freedom.

pmorici 7y ago
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.
- eqvinox 7y ago
  The chain of trust could already be attacked by replacing the entire FPGA chip with an unkeyed/open one, and then loading you own malicious bitstream. 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.)
  - pmorici 7y ago
    On these chips the encryption and integrity checking feature is one and the same you can't turn on one without the other. Whether or not you use the same key over every device in a product line or a per device key is up to the oem. So you can still verify firmware in the former instance. Replacing the FPGA chip is a lot harder than re-flashing an eeprom and they would also have to put a lot of effort in to replicating your firmware just to insert their change.

pmorici 7y ago

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.

eqvinox 7y ago
The chain of trust could already be attacked by replacing the entire FPGA chip with an unkeyed/open one, and then loading you own malicious bitstream. 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.)
- pmorici 7y ago
  On these chips the encryption and integrity checking feature is one and the same you can't turn on one without the other. Whether or not you use the same key over every device in a product line or a per device key is up to the oem. So you can still verify firmware in the former instance. Replacing the FPGA chip is a lot harder than re-flashing an eeprom and they would also have to put a lot of effort in to replicating your firmware just to insert their change.