[Cryptech Tech] road to berlin
Pavel Shatov
meisterpaul1 at yandex.ru
Mon May 2 13:26:40 UTC 2016
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
More information about the Tech
mailing list