WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: Marjan Olesch <marjan.olesch@gwdg.de>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Hardware Security Token
Date: Wed, 29 Jul 2020 14:27:05 -0400
Message-ID: <CAH8yC8=V_69QctjdZMpjgkA=ze7KzW8k+HP4xYN_zz3-xDW6OA@mail.gmail.com> (raw)
In-Reply-To: <cd5b0b55-fe63-e4ec-7ee3-b68fc9e95e31@gwdg.de>

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

  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15  8:29 Marjan Olesch
2020-07-29 18:27 ` Jeffrey Walton [this message]
2020-07-29 18:37   ` Phil Hofer
2020-07-29 18:42     ` Jeffrey Walton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH8yC8=V_69QctjdZMpjgkA=ze7KzW8k+HP4xYN_zz3-xDW6OA@mail.gmail.com' \
    --to=noloader@gmail.com \
    --cc=marjan.olesch@gwdg.de \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git