search

tillitis / tillitis-key1

Board designs, FPGA verilog, firmware for TKey, the flexible and open USB security key 🔑
https://www.tillitis.se
382 stars 24 forks source link

Enhancement idea: persistent upcounter for audit logs #156

Open gvegidy opened 5 months ago

gvegidy commented 5 months ago

Idea: Add a counter to the hardware that stores it's value within the secured boundary. The counter can only be increased and not be decremented or overflow (=fail instead of overflow).

Usecase

Consider you want to use your tillitis key for very sensitive operations, for example code signing or authorizing other keys. You want to be able to fully audit these operations afterwards, as in being able to proof that only the sensitive operations that are in the logfile took place and neither were any of them done "off books" nor the log was falsified.

Use of the counter

Any applet on the tillitis can choose to increase the counter and there is just one counter for all applets to use together. Usually this increment operation will be combined with a signing operation or a multi-step signing operation that includes using an external timestamping service or similar. The new counter value and the data that led to the increase of the counter is then signed with the private key of the tillitis and applet.

In the end the log is stored externally and contains the counter value, metadata like timestamp, applet, operation, hash that was signed and so on and a signature created with the private key of the key and applet. The user is responsible for safe storage of this logfile.

Auditing

This log can then be compared to the actual current value of the counter and checked for any missing entries of counter values. Also mismatching signatures of course. This allows to proof that the log contains entries for all events that the counter was increased and these entries are not manipulated.

If there are one or more entries in the log missing, it is not possible to reconstruct what happened and which applet was used to increment the counter.

Hardware implementation

The counter should be big enough to not easily overflow when used reasonably, for example 24 or 32 bit should suffice. Since the least significant bits will be written very often, the hardware implementation should probably contain some kind of wear levelling mechanism to prevent wearout of the flash/eeprom cells used.

The counter must be protected from external overwriting or resetting. This will most probably mean that it should be part of the secret storage that keeps the private key inside the fpga. Since the ice40 to my knowledge does not allow something like this, this feature is probably something for when you design an ASIC for the tillitis in the future. Maybe it could also be prototyped and emulated beforehand by adding an external HSM IC just for this, for example ATECC608B.

dehanj commented 3 months ago

This is a great feature. You are right however that the ICE40 does not have any persistent memory, so some external component would be needed. A flash memory would work, storing encrypted data, but would of course quite easily be erased by someone that carries out a physical attack. Is a physical attack something this would need to withstand in your opinion?

I see that I need an NDA with Microchip to dig deeper into ATECC608B, but it seems to have some IO protection so one cannot simply read out/eavesdrop the data over I2C.

gvegidy commented 3 months ago

Is a physical attack something this would need to withstand in your opinion?

I'd say yes. If you leave your tillitis key laying around and someone gets hold of it for some time they would be able to reset the counter. The traditional evil maid scenario.

Also if you add an extra hardware storage component for it, you could either add something like a dumb I2C EEPROM or something secured like the ATECC608B. It is both times just one additional IC requiring similar board space.

I have found the full datasheet for the predecessor ATECC608A with a bit of searching and without NDA. AFAIK the ATECC608A and ATECC608B are the same die, they just updated the firmware to harden it against some power side channel attacks that were found. So it is probably very similar. But going the NDA route is probably the proper way when including it in future designs.

You can establish a secure communication channel between the FPGA and the ATECC that is derived from the main secret within the FPGA once. Then all further comms between the FPGA and ATECC is encrypted and authenticated with that.