<q3k>
The Unpatchable Silicon: A Full Break of the Bitstream Encryption ofXilinx 7-Series FPGAs
<mwk>
... oh, someone beat me to it
<mwk>
... still have my chance with spartan 6
<q3k>
fwiw i would find it much more useful to have an s6 open toolchain than to break fpga crypto ^^
<mwk>
yeah, figured the same
<ZirconiumX>
Yeah the decoded bitstream is not very meaningful if you don't know what it does :P
<q3k>
i think people who employ bitstream encryption aren't in it for the anti-RE fector, but the licensing factor
<q3k>
i'm sure anti-RE is part of it
<q3k>
but this shits in their capitalist cereal anyway
<somlo>
I always thought of bitstream encryption as simply another DRM scheme -- it "works" as long as nobody cares enough to break it, and can't scale when literally millions of devices under their owners' control are expected to "collaborate" with the vendor :)
<mwk>
*shrug* they still screwed up bigger than necessary
<somlo>
yeah, but the point is that it's a quantitative, not qualitative screwup :)
<mwk>
I mean, bitstream encryption is perfectly capable of being unbreakable without physically opening the chip
<mwk>
this one is not :p
Hoernchen_ is now known as Hoernchen
<somlo>
mwk: I'm genuinely curious about this (I'm *not* an FPGA ninja by any means). So, skimming through the paper, there's an AES key loaded onto the fpga by the vendor. My point re. scalability was that this key (or keys, in case they try to vary them to keep an attacker guessing) needs to be in some database, and eventually needs to be handed to the toolchain
<somlo>
both the chip and the toolchain are under the physical control of the attacker. How's *can* this be any more scalable or "secure" than any other garden variety DRM scheme (for audio/video media) ever?
<jn__>
q3k: anti-cloning perhaps
<jn__>
cloning doesn't require RE
<q3k>
yeah that's what i meant
<q3k>
but words difficult today
<mwk>
somlo: no
<daveshah>
In any of the remotely secure bitstream encryption variants the key is provided by the person programming the FPGA
<mwk>
the key is loaded into the fpga by the bitstream designer, not fpga vendor
<mwk>
so the bitstream designer loads their key into the fpgas they're shipping with their bitstream, and they ship the encrypted bitstream in the flash or whatever
<daveshah>
There are some less secure modes using baked-in keys, but hopefully noone uses them for anything important
<mwk>
since the key cannot be read back from the device, this means you cannot clone the device (you won't be able to use the encrypted bitstream with your own fpga)
<somlo>
oh, so it's like a secure bootloader type of thing on PCs (not the crappy baked-in MS key, but rather one that lets the owner pick a key, then be expected to sign the kernel with it)
<mwk>
... I guess? I don't really know how that thing works
<somlo>
ok, I think I get it now -- thanks :)
<mwk>
but yeah, the whole security shebang is completely up to whoever programs the FPGA
<mwk>
they ship from the factory blank, with no crypto material
<somlo>
So "Alice" and "Bob" are the developer and the chip, respectively; "Eve" the eavesdropper is the happless end-user, at least in the typical use case :D
<mwk>
pretty much
<mwk>
except the attack model is not eavesdropping, but tying Bob to a torture rack