Re: keys to the Kingdom
Peter Alfke wrote:
> Let's not quibble over the price tag, and whether $10,000 is a
> meaningful hurdle.
>
> The debate was about key security, and the consensus in the crypto
> community is that things like efuses can be read out with moderate
> effort, while battery-backed up SRAM data is either much more secure or
> even perfectly secure, i.e. has never been cracked.
>
> Some people think batteries are a pain, others think they are just fine
> and last >15 years.
>
> It's security vs convenience. Xilinx picked security, Altera picked
> convenience.
> The choice is yours.
> Peter Alfke, Xilinx Applications
>
Any security system must be convenient, or it won't be used. A hefty
proportion of windows users have firewall software that came with their
machines, but it's turned off - simply because it is too inconvenient.
When it's enabled, the firewall keeps asking these daft questions about
whether your programs are allowed to do this or that - it's far easier
just to turn the stupid thing off. An advanced application level
software firewall may theoretically be more secure than a simple
"incoming bad, outgoing good" firewall, but it's no help if people don't
use it.
The same thing probably applies here. I've no experience with either
Altera's or Xilinx's solutions, but I can understand the principle that
it's possible to read out efuses but not sram bits. If Altera's
solution is more convenient, then perhaps it is more secure in that
developers are more likely to use it? After all, all they need to do is
choose some options in the software - there is no need to add batteries
to the card, and to handle the support costs of dealing with lost keys
(users are so imaginative - "I took out the battery to make sure the
card got a proper reset").
As to how secure Altera's solution is - the Altera guys are not idiots,
and it is unbecoming of you to them as such. Sure, it's possible to
read out the efuses in theory, but my guess is you're going to have to
do a lot more than just a couple of $5000 rounds. I'm sure there are
theoretical methods of breaking Xilinx's security too, such as probing
the bit stream out of the decoder. Since you have to get access to the
device while power is on, it's going to be difficult - but I'm sure it
can be done given enough time and money (and boards to practise on). To
be secure, all a method has to do is raise the stakes high enough that
alternative methods are cheaper - once it is easer and cheaper to bribe
the original engineers for a copy of the code, the device is secure enough.
|