Page 1 of 1

nbde over internet

Posted: 2020/10/17 13:32:20
by whoop
In most examples I've seen about nbde it seems to be used to unlock luks machines over a local (secure) network.
Communication doesn't need tls because it is stateless. The machine is unlock comparing keys.
What encryption is being used when communicating between clevis client and tang server?
Is it "wise" to unlock an encrypted machine using nbde over the internet?

Thanx.

Re: nbde over internet

Posted: 2020/10/18 18:01:43
by aks
Not over the Internet.

Re: nbde over internet

Posted: 2020/10/19 17:21:55
by whoop
That's what I gathered also. But why?
So every time I need to reboot a remote server I need to get on the road or use some dropbear/dracut-ssh/partial encryption scheme to get things going again? There's no automation?
I would think that nbde would be ideal in this situation. Stuff can be rebooted automatically and in the event a clevis machine gets stolen you just pull the tang service.
I am under the impression that a man-in-the-middle attack will not work and the communication between clevis and tang do not contain any information that could compromise the encryption (so there's no risk). The only problem would be DDOS, but that risk counts for every network service in the end; in some way.

Why isn't nbde being advertised as being able to solve this problem. I can't be the first one to think of this. What am I missing?

Re: nbde over internet

Posted: 2020/10/25 18:10:39
by aks
Why is it not a good idea to send secrets over a public network? (they are secrets - why else are you encrypting).

Yes these things can be automated with some thought.

Re: nbde over internet

Posted: 2020/10/28 17:11:17
by whoop
aks wrote:
2020/10/25 18:10:39
Why is it not a good idea to send secrets over a public network? (they are secrets - why else are you encrypting).

Yes these things can be automated with some thought.
Hhmm, I am confused. I was under the impression that tang does not know anything about the decryption key of the clevis client.
So these "secrets", you are talking about, that I shouldn't be sending over a public network don't make sense to me. At least under my current understanding.
By that rationale you shouldn't use ssh or https over a public network which does not make sense.

But again, I am always open to the idea that I am missing something. Just trying to understand why you shouldn't be doing this....

Re: nbde over internet

Posted: 2020/10/29 19:26:12
by aks
Okay, are you planning to mitigate man in the middle?

Re: nbde over internet

Posted: 2020/10/31 22:03:21
by whoop
aks wrote:
2020/10/29 19:26:12
Okay, are you planning to mitigate man in the middle?
Uhhmm, no? I was under the impression that I did not have to. (I am not planning anything btw, I am just trying to figure stuff out).
The decryption key is computed client side using information from the server and the client. So a man in the middle could technically not do anything because impersonating either the client or the server (or just listening) would not result in acquiring enough information to compute the decryption key.

I believe the most dangerous thing in this case would be a stolen private key from the server, but you would need physical access for that, at the very least.