Basically, your VM images are encrypted in memory, and only that which is explicitly shared with the hypervisor (for virtio devices, typically) is unencrypted. Even with full access to the hypervisor, the content of your VM’s memory can’t be parsed.
It adds a layer of additional security when running workloads one would rather not be introspected, though one still has to trust the remote machines and such. There are ways to do validate the environment cryptographically, at least in theory.
Unfortunately, the cheapest options are around $35/mo for an awful lot more VM power than I really need, unless I consolidate a few services - which I may very well do.
Well, you’ll also need to trust the tunnel, and no breakthroughs in encryption that negates 4096 bit keys… I mean it’s fine for ordinary security if you need cloud resources, but why wouldn’t you run it local instead?
Looking into it a bit more, it looks like there ought to be a way to validate, from the VM, that you’re on an actual AMD platform, in a guest with memory encryption enabled. Their little security processor handles the crypto work, I think. I need to poke more.
Breaking RSA would be a major inconvenience, but we already have workable alternatives. Breaking all of the integer factorization problem, the discrete logarithm problem and elliptic-curve cartography simultaneously (working quantum computing at scale) would be more interesting. I’m not sure that alternatives are available in that scenario, although research has been going on for years.
Is RSA involved? Maybe in the validation somehow? Looks like AES is used for the memory encryption, which makes a lot more sense (it’s a symmetric algorithm).
I believe RSA is used for validation of the platform, but actual memory encryption is AES. I linked some of the docs above that cover the details of various ways of using SEV - AMD has a number of different methods of using the system depending on your threat models.
One time keys for the most important things. You can do meta-analysis, but for the amount of one time key you have, it’s basically unbreakable. (assuming a good random number source)
By one time key, do you mean something different from one time pad?
I’m not aware of a way to use one time pads to replace all that asymmetric cryptography can do. As far as I know they provide privacy and at the cost of a secret which must be shared over a secure channel, be stored or destroyed securely, and be as big as message to be encrypted.
One time pads are definitely provably secure, but, as SirDrew notes, you basically move the problem from “How do I transmit 1MB of message securely” to “How do I transmit 1MB of one time pad securely”?
“Good random” is also depressingly harder than it should be.
And while modern processors come with hardware random generators, I’ll just leave this here…
But it’s easy enough these days to provide a few TB of ‘random’ on a BD-R, and assuming your communications are simple text, that should last a lifetime.
As for the random source? I’d say something like sensor noise is the ideal method.
That said, once you hit the ‘keep conversations between random parties secure’ problem (versus two known entities) it’s a little more difficult, but then again, so is preventing metadata spread (X talked to Y at Z time).
How do you fit a few TB on a BD-R? The capacity only goes up to around 100GB and random is rather uncompressible (to the point where if it actually compresses, it’s a good reason to suspect your random source isn’t).
By the way, pedantic point: once the “random” is fixed it’s no longer random, it’s arbitrary. Worse, it’s arbitrary that is vulnerable to playback attacks.
