You can optionally enhance the security of a WireGuard connection between two hosts by configuring it to use a secret, randomly-generated preshared key. This secret should be 256 bits (32 bytes) long, and be supplied as a base64-encoded string (when base64 encoded, it will appear as 44 alphanumeric characters, ending with an equals sign). It should not be reused for a connection between any other two hosts.
On Linux, you can generate a random preshared key with the following WireGuard command:
$ wg genpsk /UwcSPg38hW/D9Y3tcS1FOV0K1wuURMbS0sesJEP5ak=
Copy and paste the output of this command into the Preshared Key field in Pro Custodibus (or as the “PresharedKey” setting in a wg-quick-style configuration file).
If you configure one side of a WireGuard connection with a preshared key, you must configure the other side of the connection with the exact same key.
The connection between two WireGuard peers is secured by the Noise protocol, using ChaCha20-Poly1305 encryption with an ephemeral symmetric key derived via ECDH from the X25519 public-key pairs of the two peers. While there are no known practical attacks against this, eventually it might become practical for quantum computers to “crack” this encryption, by calculating the private key of one peer from its paired public key.
To hedge against this possibility (or the possibility that one of the private keys might be stolen by conventional means), you can configure the connection between two peers with a secret preshared key. WireGuard will mix this key into the derivation process for its ephemeral encryption keys.
So when using a preshared key, for an attacker to be able to decrypt the data exchanged between the two peers, she would not only have to steal or crack the private key used by one of the peers, she would also have to steal the preshared key (a randomly-generated preshared key will not be “crackable” by quantum computers, nor by any other means).
In order for two hosts to communicate over WireGuard, they must be configured with corresponding endpoints. Each host must have an interface configured with a unique public-key pair, representing the interface’s own peer identity; and each interface must have an endpoint configured with the other interface’s peer identity (ie the other interface’s public key).
From the perspective of the first host, its own interface is the local side of the connection, and this interface’s public-key pair is its local peer identity. The second host’s public-key pair is the remote peer identity, and that peer is connected to the first host’s interface as a remote endpoint of that interface.
The perspective of the second host is the mirror image. To the second host, its own local interface, using its own local peer identity, is the local side of the connection; and the endpoint of its local interface configured with the first host’s peer identity represents the remote side of the connection.
So the first host is configured with Peer 1 for its local interface, with a remote endpoint to Peer 2. The second host is configured with Peer 2 for its local interface, with a remote endpoint to Peer 1. These two endpoints represent the two sides of the same connection — each endpoint corresponds to the other. The first endpoint is the remote endpoint from the perspective of the first host; and the second endpoint is the remote endpoint from the perspective of the second host.
These two corresponding endpoints must either be configured with the exact same preshared key, or they must be configured with no preshared key at all.
Because a preshared key is useful only if it remains secret, the Pro Custodibus UI will not display the key directly (except on the page that allows you to change the key, or on the page that allows you to download the configuration settings for an interface). Instead it will display the SHA-256 hash of the preshared key (which reveals nothing about the content of the key, yet identifies it pseudo-uniquely).
The hash that Pro Custodibus displays is calculated from the raw, unencoded preshared key itself — not the base64-encoded version of the key (although the hash itself, once calculated, is displayed with base64 encoding). On Linux, you can calculate the SHA-256 hash of a base64-encoded preshared key the same way as Pro Custodibus, with the following command:
$ echo /UwcSPg38hW/D9Y3tcS1FOV0K1wuURMbS0sesJEP5ak= | base64 -d | sha256sum | cut -d' ' -f1 | xxd -r -p | base64 zsi4Ky9Kp0JVWkdDozwfDBQUZoRJUpPRVEj+7cuxxAg=
To rotate the preshared key used by an endpoint, follow these steps:
Click the Hosts link in the app header.
Find the host containing the endpoint’s interface in the list, and click the host’s name to view the host’s main status page.
Find the endpoint in the Endpoints panel, and click its name to view the endpoint’s main status page.
Scroll down to the Preshared Key panel, and click the “shield” icon on the right side of panel to modify the endpoint’s preshared key.
The preshared key currently used by the endpoint will be displayed in the Preshared Key field. It will be blank if no preshared key is used; or will display “[Key Not Stored]” if a preshared key is used but not stored with Pro Custodibus.
Click the Regenerate button next to the field to generate a new random preshared key. Alternately, you can generate a new preshared key with the following WireGuard command:
$ wg genpsk AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
(But do not use the above example key, as it is all zeros.) If you generate (or manually enter) a new key, the SHA-256 Hash for the new key will be displayed below it.
To stop using a preshared key with the endpoint, delete the content of the Preshared Key field.
If the corresponding endpoint to the endpoint you’re modifying is registered with Pro Custodibus, you will be able to select the Update corresponding endpoint checkbox. If checked, Pro Custodibus will also queue a change to update the preshared key for the corresponding endpoint to match this endpoint’s preshared key.
If the corresponding endpoint to the endpoint you’re modifying is registered with Pro Custodibus, Pro Custodibus will display the SHA-256 Hash of the preshared key currently used by the corresponding endpoint (or if the corresponding endpoint is not using a preshared key, it will be blank).
If you enter a new key in the Preshared Key field, make sure the SHA-256 hash displayed for that key matches the SHA-256 hash of its corresponding endpoint. If it does not match, the two endpoints will not be able to connect.
If the SHA-256 hash of the preshared key of the corresponding endpoint does not match the SHA-256 hash of the key in the Preshared Key field, select the Update corresponding endpoint checkbox. Pro Custodibus will update the corresponding endpoint to make it match.
Click the Update button to submit the form and queue the changes for the endpoint (and optionally the corresponding endpoint, as well).
The next time the Pro Custodibus agent on the endpoint’s host pings the Pro Custodibus servers, the agent will receive the information about the endpoint update, and execute it.
The connection between this endpoint and its corresponding endpoint will be interrupted until the preshared key has been updated on both sides of the connection. On monitored hosts, this should take less than two minutes.
If one side of the connection is not to a monitored host, you will have to update that side manually with the new preshared key.
To rotate all the preshared keys used by all the endpoints of a peer, follow these steps:
Navigate to the main page for the peer.
Click the “shield” icon on the right side of the Peer panel.
Click the “Select All” checkbox at the top of the checkboxes column in the Peer Connections panel (or click individual checkboxes for connections from the list).
Click the Rotate Preshared Keys button at the bottom of the panel.
Click the OK button in the “Rotate Preshared Keys” confirmation dialog.
A progress bar will be displayed at the bottom of the “Rotate Preshared Keys” dialog while a new preshared key is generated for each connection, and changes queued to update the connections' endpoints. When all the changes have been queued, the page will reload to list the queued changes.
Each connection will be interrupted until the key rotation process completes on both sides of the connection. On monitored hosts, this should take less than two minutes.
If one side of the connection is not to a monitored host, you will have to update that side manually with the new preshared key. See the Manual Rotation section for details.
When you use the Bulk Rotation tool to rotate the preshared key of a connection between a monitored host and an unmonitored host, you will have to manually update the rotated key on the unmonitored host.
Such hosts will have a blank (or old) “Last Ping” value in the Peer Connections panel (and the host, interface, and endpoint columns also may be blank). For each such connection, follow these steps:
Click the link to the endpoint used by the monitored host (it will be named with the peer used by the unmonitored host).
If the endpoint’s State is listed as “Update Pending”, wait until all its pending updates have been applied (this should take less than two minutes).
Scroll down to the Preshared Key panel, and click the “shield” icon on the right side of panel to view the endpoint’s newly-rotated preshared key.
Copy the value of the Preshared Key field and transfer it to the unmonitored host (for example, SSH into the unmonitored host, or send a secure message to a colleague who has physical access to the unmonitored host).
On the unmonitored host, open the WireGuard configuration for the host, and paste the transferred preshared key into the
PresharedKeysetting for the
[Peer]entry that represents the endpoint to the monitored host.
Save the WireGuard configuration change, and restart WireGuard on the unmonitored host.
To perform steps 4-6 above, you will need to either have physical access to the unmonitored host, or have a remote connection to the unmonitored host that isn’t itself tunneled through a WireGuard connection which you’re in the process of updating (for example, an SSH connection to the unmonitored host that doesn’t go through WireGuard, or an RDP connection through WireGuard to the unmonitored host from a host other than the monitored host, etc).