On Wed, Jul 29, 2020 at 5:18 AM Marjan Olesch <[email protected]> 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
