[WireGuard] WireGuard key lifetime / keys in smartcard?

[gric]

> What's programming these things like?

They are Cortex-M3 ARM microcontrollers (STM32F103). So pretty standard.
No java involved. As said earlier, they have free toolchains.

> How much effort do you suppose it would take me to produce a very
> stripped-down firmware for one of these that has these simple USB
> operations:
>
> - load key from host input
> - multiply loaded key by host input
> - erase key
>
> What's the X25519 implementation in general like? Any architecture
> specific tricks required to avoid sidechannel attacks and such?

Keys should be generated on the card if possible.

I suppose this stripped down firmware will not conform to the OpenPGP
Card specification, especially considering that there is no need for
user-space to ever touch the keys.

The operations themselves are not harder than usual to implement,
however it should be noted that the MCU provides:

- No crypto facilities of any kind.
- No anti-tampering mecanisms.
- No side-channel and fault injection mitigation.
- No features designed for random-number generation. Gnuk/NeuG uses the
STM32 ADCs.
- No dedicated area to store the keys. They seem to be stored in NOR.
- No code signature verification.

The list goes on. It is not officially labeled as a HSM because it is
not one. It could possibly help to protect the keys a bit from a
compromise of the host, but it will not hold for more than a few minutes
if you loose physical control of the dongle. I wonder what kind of
non-invasive attacks have been attempted, especially against the EC modes.

For personal use when a host compromise is detected, key rotation is
often a small effort compared to decontamination. The main benefit is to
require the attacker to connect to the host in order to capture
temporary keys or directly inject traffic in the tunnel, and to deny him
the ability to do so when the dongle is removed.

For servers, the maximum number of connected peers will be limited by
the MCU performance. Unfortunately a very large number of peers with
difficulties to update the server public key would be the only case
where reusing a key after a host compromise looks excusable.

It might feel better than to store keys in ~, however the security
benefits in the case of the STM32 do not seem sufficient to justify a
lot of added complexity.