New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How easy is it for a server admin to read secret keys from memory on a KVM system?
k9banger02
Member
in General
How easy is it for a server admin to read secret keys from memory on a KVM system?
If you encrypt your disk on a KVM system, what are the OS and hardware based systems which make it difficult/impossible for the server admin to read your keys from memory, setting aside known exploits and vulnerabilities which may make it easier?
Do newer server CPUs have additional features which make it harder or well nigh impossible if supported by the OS?
Comments
If you process some confidential data consider AWS or colocate your own hardware. I think second option is more suitable for you.
Never forget...
dumping the memory is easy, recovering data out is the harder part
Major strugle is competence. A lot of providers just simply incompetent to do memory dump and its decoding.
I think this is not an issue for Law Enforcement
If they know what they're doing, really easy.
For example with libvirt: https://github.com/nailfarmer/debian-luks-suspend/issues/2
It is just two commands.
If you don't trust your provider to keep your data safe, do not store it on their systems.
The only solutions are AWS (Nitro) or colocating your own hardware with bulletproof physical security (locked rack, shutdown on chassis intrusion, encrypted memory)
If AMD ever manage to get SEV fully secure then that is also an option, but providers either charge a ridiculous 10x premium on it (Azure, GCP), or are dodgy and hard to sign up to (Oracle)
The tools to dump and decrypt require minimal script kiddie level of skill, even for dedis. Assume that any provider is capable of using them. The only counterplay is hardware
how about encrypting your (virtual) disk? will it lower the chances?
LOL.
No virtualized environment will be safe from that EVER. AMD SEV, Intel SGX - all have exploits, and are all backdoored, not to mention there is no magical solution to any of that. There is no readily available RAM encryption that works for entire system.
Your only option is colo and locking down the system as much as possible. Gluing RAM sicks and sensible connectors that could be used for flashing malicious firmware, disabling all connectors you don't want used(serial, usb, etc), cctv on rack, hardware "traps", and a lot of time to watch for suspicious activity are just a few things you may want to do.
Encrypting disk does not affect data in ram.
Unless you process top secret data ofc
If you want protection, you want it to be as good as possible.
You recommending AWS for "confidential" things is absolutely laughable. Its strictly for Govt and Corpos(basically same level in many cases) - which are protected mostly by contracts, and not technical capabilities.
All protection layers must be justified due to overhead. You won't spend that much effort for protecting your Bitwarden instance for example.
Bitwarden is encrypted on its own, it does not need additional encryption of any kind.
RAM is also safe because private key is stored on devices to which encrypted data is being sent(e2e).
You got my point.
This.
Best would be to find someone who most definitely doesn't have a conflict of interest and has a public persona of the individuals running the company such that they are motivated not to do something scummy.
If you have to ask those kinds of questions, then you don't trust the provider. Co-locate your own Servers Or host it yourself.
I personally host everything that is critical and private information myself. Then, I encrypt the data and upload it to an off-site Nas Server that I co-locate.
You should read up on the hardware and processes behind AWS Nitro
They are the only game in town for confidential computing at low end prices (T4g range)