* Hardware Security Token
@ 2020-07-15 8:29 Marjan Olesch
2020-07-29 18:27 ` Jeffrey Walton
0 siblings, 1 reply; 4+ messages in thread
From: Marjan Olesch @ 2020-07-15 8:29 UTC (permalink / raw)
To: wireguard
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
Hi,
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
Best Regards,
Marjan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5406 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Hardware Security Token
2020-07-15 8:29 Hardware Security Token Marjan Olesch
@ 2020-07-29 18:27 ` Jeffrey Walton
2020-07-29 18:37 ` Phil Hofer
0 siblings, 1 reply; 4+ messages in thread
From: Jeffrey Walton @ 2020-07-29 18:27 UTC (permalink / raw)
To: Marjan Olesch; +Cc: wireguard
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Hardware Security Token
2020-07-29 18:27 ` Jeffrey Walton
@ 2020-07-29 18:37 ` Phil Hofer
2020-07-29 18:42 ` Jeffrey Walton
0 siblings, 1 reply; 4+ messages in thread
From: Phil Hofer @ 2020-07-29 18:37 UTC (permalink / raw)
To: noloader; +Cc: Marjan Olesch, wireguard
[-- Attachment #1.1: Type: text/plain, Size: 229 bytes --]
> 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.
>
"Roughtime" https://roughtime.googlesource.com/roughtime
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 477 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Hardware Security Token
2020-07-29 18:37 ` Phil Hofer
@ 2020-07-29 18:42 ` Jeffrey Walton
0 siblings, 0 replies; 4+ messages in thread
From: Jeffrey Walton @ 2020-07-29 18:42 UTC (permalink / raw)
To: Phil Hofer; +Cc: wireguard
On Wed, Jul 29, 2020 at 2:37 PM Phil Hofer <phil@sunfi.sh> wrote:
>
> > 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.
>
> "Roughtime" https://roughtime.googlesource.com/roughtime
That's it, thanks.
It sucks getting old...
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-07-29 18:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-15 8:29 Hardware Security Token Marjan Olesch
2020-07-29 18:27 ` Jeffrey Walton
2020-07-29 18:37 ` Phil Hofer
2020-07-29 18:42 ` Jeffrey Walton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).