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