4 ms·

One of the striking things in this article was when he said they might have been compromised by their "CloudCo" (Cloud Provider). If I'm going to build any sys

One of the striking things in this article was when he said they might have been compromised by their "CloudCo" (Cloud Provider). If I'm going to build any systems that handle money or bitcoin in a cloud provider, I will make damn sure I don't trust the cloud provider with anything. Everything should be fully encrypted such that even a breach of trust from the hosting provider would not compromise your data/funds. I know this is hard to do, but it's mandatory when you're handling digital currency.

pzxc 11y ago
It's not just hard to do, it's impossible. For a cloud provider anyway. Given that your software has to be capable of executing Bitcoin transactions itself, and the VM manager sits at a higher level and controls allocation and access to your VM's memory (to isolate it from other VMs), you are at the very least trusting that (1) when your cloud provider says they are using VMware or whatever standard software they aren't lying, and (2) that VMware itself is securely designed to limit its own access (and access of its own operators) to the underlying VMs. If you don't want to trust your hosting provider with anything, you have to own the hardware.
gridspy 11y ago
Encryption won't protect you - the cloud provider has access to executables (in ram and perhaps on disc), your keys (ram and disc) and the data both pre and post encryption (in ram). Because they control the hypervisor, they control everything. That means they have as much access and authority as the code that you are running on their servers have. So the only way to protect yourself from them is to limit what your servers (deployed on their cloud) can actually do. So for instance you could have a secure backend server on a dedicated host in a trusted environment, with the cloud servers using an API to the backend server. If the API is suitably secure then the cloud servers could be compromised without allowing them to directly issue invalid commands in the same way the backend server could. Then you could use the cloud to scale out your web frontend without compromising yourself. The same is true of hardware on the dedicated host (such as the "Trusted Computing" Module) that you do not control. If that (or the BIOS) gets compromised you might not even know that your host is no longer secure.
- dantiberian 11y ago
  In a limited way, this is what Apple does with iCloud. The customer data is encrypted and stored at AWS and Azure, and presumably decrypted on servers Apple runs and controls.
- illumin8 11y ago
  You can use hardware security modules in datacenter space you physically control to store the private keys used to encrypt your data at "CloudCo". Amazon even offers this service and calls it Cloud HSM. There's always the in-memory vulnerability, which is harder to mitigate, but requires an attacker with physical access to the hypervisor, so it's much more difficult to execute (as most meat-space hacks are).
walrus01 11y ago
IMHO if you're doing anything financial and don't own the bare metal hardware that the hypervisor runs on and 100% control physical access to it, and run your own network gear (right up to your border with transit providers), you're doing something fundamentally wrong.

pzxc 11y ago

It's not just hard to do, it's impossible. For a cloud provider anyway. Given that your software has to be capable of executing Bitcoin transactions itself, and the VM manager sits at a higher level and controls allocation and access to your VM's memory (to isolate it from other VMs), you are at the very least trusting that (1) when your cloud provider says they are using VMware or whatever standard software they aren't lying, and (2) that VMware itself is securely designed to limit its own access (and access of its own operators) to the underlying VMs. If you don't want to trust your hosting provider with anything, you have to own the hardware.

gridspy 11y ago

Encryption won't protect you - the cloud provider has access to executables (in ram and perhaps on disc), your keys (ram and disc) and the data both pre and post encryption (in ram). Because they control the hypervisor, they control everything. That means they have as much access and authority as the code that you are running on their servers have. So the only way to protect yourself from them is to limit what your servers (deployed on their cloud) can actually do. So for instance you could have a secure backend server on a dedicated host in a trusted environment, with the cloud servers using an API to the backend server. If the API is suitably secure then the cloud servers could be compromised without allowing them to directly issue invalid commands in the same way the backend server could. Then you could use the cloud to scale out your web frontend without compromising yourself. The same is true of hardware on the dedicated host (such as the "Trusted Computing" Module) that you do not control. If that (or the BIOS) gets compromised you might not even know that your host is no longer secure.

dantiberian 11y ago
In a limited way, this is what Apple does with iCloud. The customer data is encrypted and stored at AWS and Azure, and presumably decrypted on servers Apple runs and controls.
illumin8 11y ago
You can use hardware security modules in datacenter space you physically control to store the private keys used to encrypt your data at "CloudCo". Amazon even offers this service and calls it Cloud HSM. There's always the in-memory vulnerability, which is harder to mitigate, but requires an attacker with physical access to the hypervisor, so it's much more difficult to execute (as most meat-space hacks are).

walrus01 11y ago

IMHO if you're doing anything financial and don't own the bare metal hardware that the hypervisor runs on and 100% control physical access to it, and run your own network gear (right up to your border with transit providers), you're doing something fundamentally wrong.