algernon ludd on Nostr: nprofile1q…utslx Wireguard keys in initrd are... effectively plain text. ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq0cq07ulfyc7y2l8rczk9s36g8j65tq3m6xk9us8hr3ua4ktfmaqqeutslx (nprofile…tslx) Wireguard keys in initrd are... effectively plain text. Technically, I store them in a sops-encrypted file, which is unlocked by the initrd's ssh key. But since the initrd's ssh key is copied to the initrd in plain, if someone copies the initrd, they'll have access to the WG key too.
Regarding the copying: you have a point. But I think I have a workaround for that scenario: if there's no WG on Quickbeam (the home server), there's nothing their clone can connect to. So: what if the VPS didn't try to WG to the home server? But rather, would host its own initrd-specific WG, which the home server would connect to, and then the VPS can talk to the home server's Tang.
This way, to unlock the VPS's disk, not only would they need to clone the initrd, but they'd need to get my home server to connect to their clone, too. Or steal the home server initrd too.
Hmm. I guess I'll go back to the drawing board a little and ponder more about attack vectors!
Regarding the copying: you have a point. But I think I have a workaround for that scenario: if there's no WG on Quickbeam (the home server), there's nothing their clone can connect to. So: what if the VPS didn't try to WG to the home server? But rather, would host its own initrd-specific WG, which the home server would connect to, and then the VPS can talk to the home server's Tang.
This way, to unlock the VPS's disk, not only would they need to clone the initrd, but they'd need to get my home server to connect to their clone, too. Or steal the home server initrd too.
Hmm. I guess I'll go back to the drawing board a little and ponder more about attack vectors!