02.05.2016 10:43, Fredrik Thulin пишет:
On Monday, May 02, 2016 12:37:50 AM Paul Selkirk wrote: ...
The AVR has to do approximately the following: - receive a tamper
interrupt from an external circuit (currently a panic button) -
wipe the MKM - raise an interrupt on the ARM, so it can do whatever
it needs to do - light an LED (red, of course)

If we get that right, we might never have to upgrade the AVR.

I agree. I would consider it nice to have (or harmful =) ) to have a
 software upgrade path for the AVR before Berlin. We could absolutely
 make a way to transfer firmware to the AVR from the FPGA using
GPIOs, but with close to zero benefit at this stage.

I think, some people will even object to DFU option being present for the tamper detection block. What if malicious user crafts dummy tamper detection firmware, that only lights the red panic LED, but skips actual wiping of the secret key?

My reasoning:

The whole tamper circuitry is currently a development module. It is
nice to have a way to erase any keys in the device when re-purposing
it or similar, but it currently requires pressing a button on the
bottom side of the PCB. If someone wants to actually add tamper
protection to the Alpha using the AVR GPIOs, it is not unreasonable
to expect them to program the AVR using an ISP programmer connected
to the programming header.

I agree that if someone wants to customize the tamper detection block, he will most probably know how to deal with the hardware part (add new sensors to board, support them in the tamper detection firmware, etc), so he will definitely have AVR programming cable and won't need the DFU option.


So the main reason to make DFU for the AVR I can see would be to
streamline manufacturing, and I think we have other things to focus
on first.

/Fredrik



--
With best regards,
Pavel Shatov
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech

Reply via email to