Network security in the microservice environment [LWN.net]

Network security in the microservice environment

Posted Apr 14, 2017 19:23 UTC (Fri) by davidstrauss (subscriber, #85867)
In reply to: Network security in the microservice environment by madhatter
Parent article: Network security in the microservice environment

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.

to post comments

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 (subscriber, #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.