Re: Hardware Security Token

[Jeffrey Walton <noloader@gmail.com>]

On Wed, Jul 29, 2020 at 5:18 AM Marjan Olesch <marjan.olesch@gwdg.de> wrote:
>
> I'm a student in computer science and currently writing my master
> thesis. It's about an STM32F103 based security token, that is
> specifically designed for the WireGuard authentication. For now, it has
> more like a proof-of-concept character, and I'm aware of the possible
> security flaws, which also have been discussed here before
> (https://lists.zx2c4.com/pipermail/wireguard/2016-July/000243.html).
>
>
> Nevertheless I want to briefly present my team's concept, as well as our
> progress.
>
> The Noise IK pattern shows clearly, that it is not enough to just
> outsource DH(SiPriv, SrPub) to the token, since this part would be
> static, as long as the private static key or the peer’s public key does
> not change. Considering chapter 5.4 in the wireguard paper (initiation
> scenario), at least the operation (Ci, k) := Kdf2( Ci, DH(SiPriv, SrPub)
> ) needs to be ported to the token, since it is the Ci that is based on
> ephemeral keys. Furthermore, the k, resulting from the KDF2 is a secret,
> that is needed to create the AEAD. This means, that the k is kept on the
> device, while the AEAD is also calculated on the token. Because the AEAD
> calculation requires a timestamp, the device needs to run an RTC.
> Considering all this, an attacker that intercepts the communication
> between token and computer cannot replay the handshake with the
> information transceived, since he is not able to alter neither the time
> stamp, nor the k.
>
> Unfortunately, the STM32F103 can - from our findings - only run the
> time, not the date, while powered off (with backup battery connected).
> So for now the date has to be delivered once a day in our
> implementation. The delivery can be protected by a password and/or a
> hardware button for better security. The most important algorithms
> Blakse2s, curve25519 and chacha20-poly1305 run on the STM32 and we were
> able to reconstruct the operations needed, in order to source out the
> particular parts from the handshake initiation. The communication to the
> (virtual COM) device runs via USB and a really simple rpc protocol. We
> used wireguard-rs for the development and everything stated above works
> at the moment.
>
> I don’t want to bother you with too much information. Please let me
> know, if you have thoughts about this idea and/or the implementation. I
> would be pleased to present you everything in more detail.
>
> Code can be found on https://gitlab.gwdg.de/uenigma

One comment on the date/time problem...

Getting the current date/time has been a problem as long as I can
remember. Early mobile phones without SIM cards would not fetch time
from the carrier, so just about anything X.509-related could fail
depending on the phone's default time (which was usually something
like January 1, 2000).

I believe Google has a secure time server/protocol for this problem,
but it is only a partial fix. I don't recall the name of the protocol
or the server.

The IETF has some recommendations at https://tools.ietf.org/html/rfc8633.

I believe one of the fixes in the IoT age is a gossip protocol. If a
dozen devices around you agree on a time, then the time is likely
correct. You don't need to contact a network time server when the
community agrees on the time. You can contact a secure time server for
higher assurances, but the gossip'd time should be OK to get you to
that point.

Jeff