potential preshared-key changes

potential preshared-key changes

[Jason A. Donenfeld]

Hi folks,

Trevor and I have been discussing for some time changing the semantics of
preshared keys. I thought about this 18 months ago, but erred on the side
of keeping things as is. After a recent conversation in SF, I'm beginning
to reconsider. I wanted to open this up for discussion, as there are
several pros and cons.

Summary: Currently the handshake mixes in the preshared-key *first*. This
means that the initiator's identity is not revealed until after the
receiver has decrypted using the preshared-key. This in turn means that
preshared-keys must be _per-interface_ instead of _per-peer_. This has
some advantages and some disadvantages. The proposal is to change the
crypto so that the preshared-key is mixed in *last*, so that
preshared-keys become shared _per-peer_.

Pros of per-interface preshared-keys (current method):

  * Simplicity.
  * That's how things work now.
  * The preshared-key protects the identity hiding in a post-quantum
    setting.
  * The preshared-key contributes to the DoS MACs and the cookie
    encryption.

Cons of per-interface preshared-keys (current method):

  * When using WireGuard with multiple peers, the peers must all share the
    same key, which increases the potential for compromise of the
    preshared-key (though the session is of course stil protected with the
    ordinary public key crypto).

Pros of per-peer preshared-keys (proposed method):

  * Compromise of the preshared-key is less likely, since it does not need
    to be shared by all peers.

Cons of per-peer preshared-keys (proposed method):

  * The identity hiding is no longer protected in a post-quantum setting.
  * The DoS MACs and cookie encryption no longer benefit from using the
    preshared-key.
  * It requires changing things.
  * Kevin and I have slightly more Tamarin work to do.

Thoughts? Opinions?

Regards,
Jason

Re: potential preshared-key changes

[crasm]

Forgive me in advance if this is a horrible or misinformed idea, but why
not blake2s the preshared-key with each peer's public key and distribute
that as a per-peer "preshared" key, mixing it in last? That would reduce
the risk of key compromise, since each peer would have a unique key and
the real key is not copied to each peer.

I do like identity hiding, but I can't tell if there's a way for the
above to work without exposing public keys (at least considering roaming
IPs).

Re: potential preshared-key changes

[Fredrik Strömberg]

Hi everyone,

Jason, you already know my opinion on this, but I will restate it here
for the sake of discussion.

Summary:
Yes, we should make the change so that Pre-Shared Keys are per-peer.
The benefits of per-peer PSKs vastly outweigh the disadvantages.

Premises:
A. The current (or proposed) implementation of Wireguard should not be
used post QC
B. Tunnel traffic from the current (or proposed) implementation of
Wireguard should optionally be protected even post QC
C. A PSK shared between all peers is much more likely to leak than a
PSK shared only between individual peers.

Conclusion:
Because of B and C I'm in favor of changing the handshake to enable
PSKs that are (potentially) unique to every peer. The negative
security impact of the change is also probably quite limited as
discussed below.

The only relevant security impact I see from the change is that in a
post QC world an attacker who has saved the handshakes will be able to
learn S(pub,i), assuming it already knows S(pub,r).

In some situations it's certainly likely that the attacker has
previous knowledge of S(pub,r). One such example would be a public VPN
service. However, in the context of a publicly available VPN service,
if the attacker has taken actions to learn S(pub,r) she will almost
certainly also know the PSK, because the VPN service will provide it
as part of the configuration package. In that case, the identity
hiding is broken anyway, so it's merely a question of whether
historical traffic remains confidential or not.

Furthermore, consider that the IP addresses of the peers will most
likely be available to the attacker.

Finally, I suspect that in practice in a situation where the attacker
has knowledge of S(pub,r) it will also have knowledge of the PSK.

The change would in other words only have a negative security impact when:
1. The attacker somehow knows S(pub,r) but not the PSK
2. The attacker gains an advantage by knowing S(pub,i) which is not
gained by already available metadata (such as the IP addresses)

Discussion of pros and cons:

On Sun, Apr 23, 2017 at 12:22 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Pros of per-interface preshared-keys (current method):
>
>   * Simplicity.
Operators can still choose to set the same PSK for all users. The
change merely offers the option of making it per-peer.

>   * That's how things work now.
Wireguard is still in the development phase. Protocol incompatibility
should not be a concern.

>   * The preshared-key protects the identity hiding in a post-quantum
>     setting.
The identity is still protected assuming S(pub,r) is not known. See above.

>   * The preshared-key contributes to the DoS MACs and the cookie
>     encryption.
This only makes a difference in situations where the attacker knows
S(pub,r) but not the PSK. See above.

> Cons of per-peer preshared-keys (proposed method):
>
>   * The identity hiding is no longer protected in a post-quantum setting.
It is if S(pub,r) is not known to the attacker. See above.

>   * The DoS MACs and cookie encryption no longer benefit from using the
>     preshared-key.
In practice the attacker will probably know the PSK if it has gained
knowledge if S(pub,r). See above.


Finally, thank you again for developing Wireguard.

Regards,
Fredrik Stromberg

Re: potential preshared-key changes

[Fredrik Strömberg]

Hi! :)

On Sun, Apr 23, 2017 at 9:05 AM,  <crasm@wireguard.1.email.vczf.io> wrote:
> Forgive me in advance if this is a horrible or misinformed idea, but why
> not blake2s the preshared-key with each peer's public key and distribute
> that as a per-peer "preshared" key, mixing it in last? That would reduce
> the risk of key compromise, since each peer would have a unique key and
> the real key is not copied to each peer.
>
If I understand you correctly you're suggesting:

1. Peer PSK = BLAKE2S( "Real PSK" + "Peer's static pubkey" )
2. Mix in the peer's PSK the same way Jason suggests

In practice this is equivalent to the discussed change, and "Peer PSK"
would be the real key, for that peer.

Regards,
Fredrik Stromberg

Re: potential preshared-key changes

[crasm]

On Sun, Apr 23, 2017, at 06:49 AM, Fredrik Str=C3=B6mberg wrote:
> [...]
> Furthermore, consider that the IP addresses of the peers will most
> likely be available to the attacker.
> [...]
> 2. The attacker gains an advantage by knowing S(pub,i) which is not
> gained by already available metadata (such as the IP addresses)

At least in my case, my IP addresses are pretty closely linked to my
identity. I don't change my VPSs as often as I should and I'm fairly
sure my residential IP is the same as it was months ago.

But isn't the public key of the initiator sure proof of identity if the
handshake is completed? An IP address would only be circumstantial and
would require extra information, like a log/account request to the ISP,
before they'd know with certainty.

In the context of a public VPN and per-user PSKs, a user's usage can be
tracked by a global adversary even if they hop networks. And their
location or movement can also be estimated. I believe interface PSKs
could prevent that if every user was trusted (private VPN?), but that
seems impossible for a public service, since someone malicious could
simply sign up for the service to get the PSK.

On Sun, Apr 23, 2017, at 07:13 AM, Fredrik Str=C3=B6mberg wrote:
> Hi! :)

Hello!

> In practice this is equivalent to the discussed change, and "Peer PSK"
> would be the real key, for that peer.

Ah, so that would be an implementation detail for how the keys are
generated.

Re: potential preshared-key changes

[Mathias]

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

We should definitely change to per peer PSKs.
Following Storömberg's observations, the following points may also be
worth considering:

1. Partial deployment

Per peer PSK allows organization to deploy PSK to a subset of peers and
have a smooth transition should they wish to implement it later.

2. Compromise of endpoints

All it takes is one compromised endpoint and PQ secrecy fails completely.
If an employee ever leaves his laptop unencrypted and unattended, the PQ
secrecy of all the corporations VPN connections could be lost.

Furthermore, if an administrator suspects this may be the case,
he has to deploy new keys to all endpoints in a PQ secure manner (e.g
sending them over HTTPS is meaningless);
he most likely has to physically install the new PSK on every client!

In case of compromise, the peers public key must be updated regardless
and updating the per peer PSK along with it seems a manageable task.

3. Disclosure of data under a warrant

Suppose the organization deploying Wireguard is forced to decrypt the
data to/from a single peer.
Currently this is not possible, because of forward secrecy, however in a
post-quantum setting it would be.
Limiting the disclosure to a single peer is substantially harder with a
globally shared PSK.
*
*Periodically rotating the PSKs and completely avoiding the case above
is much easier if the PSK is per peer.
*
*4. Public VPN*

*If Wireguard is deployed as a public VPN, there is no hope of PQ
security with a global PSK.
In the case of a per peer PSK, this may be achieved by meeting in person
or exchanging the PSK with PQ crypto, e.g
the overhead of McEliece may be acceptable, since the PSK is only
transfered once.

5. Users and secrets*
*
Since the key is shared, you can count on Alice asking Bob for his VPN
configuration,
you can also count on Bob sending said configuration over email.
Again the PQ security for the entire organization is lost.

As the organization grows, the probability of such an event goes to 1.

Regards,
Mathias

[-- Attachment #2: Type: text/html, Size: 2816 bytes --]

Re: potential preshared-key changes

[Kalin KOZHUHAROV]

I finally read through all the thread :-D

(and very good write-up, Mathias!)

Obeying the KISS principle, while erring on security should lead to
"per-client PSK", the proposed method.

I see some scenarios where the current method (per-iface) works
better, mainly in small private VPNs, usually temporary and all
trusting each other; in such cases identity hiding is not an issue and
simple initial setup (one PSK) is a plus.
( think a bunch of short-lived VPC instances, started/owned by single person)

To eat the cake and have it whole, supporting both methods MAY be
possible, iff (=if-and-only-if) this does not introduce lots of
complexity in code.

Thinking about code, how would that be implemented, how do we define user?
I am wondering what happens after Alice establishes a connection to
SERVER_1 with PSK_A from IP_1:
* then someone (Eve?) establishes another connection with (stolen)
PSK_A from IP_2 ? -> log or ignore
* then Bob establishes another connection with own PSK_B from IP_1
(same company GW)? -> hopefully possible!

I guess part of the design of WG is to not keep state or logs, so
those will "simply work" (TM) :-D

Regards,
Kalin.