README Warning

[tandy-1000]

I'm not sure I fully understand your wording on the warning in the readme.

Most installs do not currently encrypt /boot; and therefore the client private key should be considered untrusted/compromised.

I understand that FDE systems don't encrypt boot, so the private key will be stored unencrypted, but I don't get what you mean by:

It is highly recommended that a separate point-to-point wireguard network with proper port blocking is used for remote unlocking.

Could you clarify this?

Thank you.

[r-pufky]

Sure, It's a defense in depth tactic.

Since the key is untrusted, it means a highly-motivated/resource-backed attacker could obtain the key and connect to the network.

A separate point-to-point WG network (or untrusted network with many clients) would only allow enough access to the ensure the machine connecting is not compromised / updated / etc.

By having a "untrusted/non-privileged" network, you can:

• Harden that specific network to only allow the communication you wish on that network; and denying all other traffic (whitelist approved traffic) -- e.g. a firewall on the WG endpoint that filters traffic from that network.
• If the key is known to be compromised, you only need to swap the public/private keys for that network, instead of your main WG network (and updating all systems on it) -- deleting the WG endpoint's private key will render all untrusted nodes removed from the network.
• Validate that the system is in the correct / right state before allowing it onto the full WG network. This means different things for different people. but essentially it's validating that the system hasn't been popped, or that all updates are applied, etc.

The reality for most people is that this is a "best practice", but heavily depends on what your landscape looks like and your threat model.

I think I answered your question -- if not, let me know and I can follow up.

[tandy-1000]

Oh I see, so the config that is used in the initramfs basically needs to be a "hardened" network with very tight rules, I understand now.

Thank you for the explanation!

[teadur]

Sure, It's a defense in depth tactic.

Since the key is untrusted, it means a highly-motivated/resource-backed attacker could obtain the key and connect to the network.

A separate point-to-point WG network (or untrusted network with many clients) would only allow enough access to the ensure the machine connecting is not compromised / updated / etc.

By having a "untrusted/non-privileged" network, you can:

• Harden that specific network to only allow the communication you wish on that network; and denying all other traffic (whitelist approved traffic) -- e.g. a firewall on the WG endpoint that filters traffic from that network.
• If the key is known to be compromised, you only need to swap the public/private keys for that network, instead of your main WG network (and updating all systems on it) -- deleting the WG endpoint's private key will render all untrusted nodes removed from the network.
• Validate that the system is in the correct / right state before allowing it onto the full WG network. This means different things for different people. but essentially it's validating that the system hasn't been popped, or that all updates are applied, etc.

The reality for most people is that this is a "best practice", but heavily depends on what your landscape looks like and your threat model.

I think I answered your question -- if not, let me know and I can follow up.

https://github.com/NHAS/wag would be one method how to implement the untrusted initial access.