Network security in the microservice environment

Posted Apr 13, 2017 22:02 UTC (Thu) by davidstrauss (guest, #85867)
Parent article: Network security in the microservice environment

> if PKI is used, each node must be supplied with its private key and the relevant certificates.

Perhaps I'm assuming distribution because of the word "supplied" being used for both the key and the certificate, but private keys ought to be generated on hardware local to the machine that needs them -- and never sent anywhere. The only certificate setup steps that should involve a network hop are (1) the certificate signing request and (2) the certificate returned for it.

Network security in the microservice environment

Posted Apr 14, 2017 15:52 UTC (Fri) by madhatter (subscriber, #4665) [Link] (6 responses)

Firstly, it's my article, so that's my fault. Trireme's README on github states only that "when using PKI, the PrivateKey and corresponding CA certificate must be available locally on the node", so I have added an implication that was not there by my choice of words, for which I apologise.

That said, I don't agree that there are no valid reasons whatsoever to generate a keypair off-host. You can find me attempting to consider both pros and cons in my answer to this ServerFault question from a few years back.

Network security in the microservice environment

Posted Apr 14, 2017 19:11 UTC (Fri) by davidstrauss (guest, #85867) [Link]

> That said, I don't agree that there are no valid reasons whatsoever to generate a keypair off-host. You can find me attempting to consider both pros and cons in my answer to this ServerFault question from a few years back.

I agree that a design like that can make sense, but it's more of a way to package and ship entropy than part of the actual PKI architecture. You could create a file with random data, send it to the server, and pump it into the kernel's entropy sources to get a similar effect.

Network security in the microservice environment

Posted Apr 14, 2017 19:23 UTC (Fri) by davidstrauss (guest, #85867) [Link] (3 responses)

I should add to my previous comment that shipping entropy ought to be better than shipping the keypair, not just comparable. When you ship entropy to the keypair-generating system (KGS, to spare myself later verbosity), the result should be *at least* as random as shipping the key itself. That is, if the KGS has no entropy or predictable "entropy," it shouldn't undermine the entropy of the data shipped to it; xor-ing random data with predictable data (in equal parts) still produces an equally random result. But, the upside is that, if the KGS has any usable entropy, the private key will not be known or guessable to other systems (to whatever degree that KGS has entropy).

So, I think the worst case has similar attack surface to the "ship the keypair" design, but the best case has less.

Network security in the microservice environment

Posted Apr 14, 2017 19:31 UTC (Fri) by madhatter (subscriber, #4665) [Link] (2 responses)

Yes, and no. A communications mechanism that can be trusted to ship a block of entropy undamaged and secure, from a secure endpoint (for who else should be allowed to generate this) can be trusted to do the same for a key.

I don't mean to suggest that it's done deal either way, merely to note that the matter is capable of reasonable argument, and that to have a preference either way isn't necessarily foolish.

Network security in the microservice environment

Posted Apr 14, 2017 19:53 UTC (Fri) by davidstrauss (guest, #85867) [Link] (1 responses)

> A communications mechanism that can be trusted to ship a block of entropy undamaged and secure, from a secure endpoint (for who else should be allowed to generate this) can be trusted to do the same for a key.

I'm not referring so much to the trustworthiness of the transport as this distinction:

* If Machine P generates the keypair and sends it to Machine Q, both have had access to the full private key.
* If Machine P generates a batch of entropy and ships it to Machine Q (which has less or less trustworthy entropy), and Q generates the keypair, then only Q knows the full private key. Machine P may have lots of useful data to start guessing the private key, but any local entropy on Q -- as well as which parts of P's entropy that Q chooses to use for the keypair (versus other entropy-consuming tasks) -- make that much harder.

The distinction for attack surface could matter in various scenarios:

* Machine P is directly compromised.
* Machine P is a VM, and the host gets compromised.
* Machine P accidentally logs the data it's sending, and that data gets sent elsewhere (like an ELK stack).
* Machine P turns out to use predictable entropy sources.
* The transport from P to Q is compromised. (Even with all the security that's possible, it's still worse to leak the private key than just entropy used in creating it.)

And, unlike how you can use an HSM to sign CSRs on the certificate authority (preventing many attacks from getting the private key data), Machine P necessarily has to handle the entropy or keypair data that it's sending to Machine Q.

Network security in the microservice environment

Posted Apr 14, 2017 19:59 UTC (Fri) by madhatter (subscriber, #4665) [Link]

As I said, I think the matter is capable of reasonable argument, and I'm certainly not saying you don't have a point. I think that what I'm doing is defensible, but I wouldn't dream of suggesting that anyone else do it. I would dream of suggesting that anyone who's got to generate a keypair should think about the threat model they think they face, and take their own position on what to do, rather than blindly following anyone's stern prescriptions.

Network security in the microservice environment

Posted Apr 14, 2017 20:18 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Generate them on a TPM - if you know the node's EK in advance, this even gives you a mechanism to prove identity.