On Tue, 9 Dec 2014, Nathan Wheeler wrote: > Hi everyone, > > We use OpenBSD currently on physical hardware and manage it in our > customers location. We want the option to give out VMs to host on > customer premises and we'll still manage the VM (but not the VM > platform). > > The problem is not letting the customer access to our proprietary data > as they could easily mount the virtual hard drive somewhere else. The > obvious answer is disk encryption, but we can't require manual > intervention to enter a passphrase or to provide a key. > > I'm sure I'll have to settle with obfuscation, which I'm OK with, but > I'm curious if there is a good/best way to go about that. > > Is the only option to change things we need to hide into binaries? > Compile the kernel with a key to decrypt? > > I've taken a look at how other vendors do it like Juniper. With their > VM I can mount the boot partitions, but they only have boot > information and the kernel. I can't mount the extended partitions, > they don't even seem to be formatted with a filesystem. My guess is > they compile the kernel with a key or something, but its just a guess. > > Thanks for any advice! > > Nate >
You said that you are already letting your proprietary data out in the wild since you have machines on customer premises with this data in unencrypted form. If it moves from a physical machine to a virtual one it is true that it makes it easier for someone to access it but not that much easier. Anyway, the way I see it, the only way to keep someone from accessing your data is encryption. Obfuscation alone will make it harder but not impossible. To avoid manual intervention when using encryption you need a way to get the key/passphrase to the machine/application. If you were using application/file level encryption, you could compile the key in to a binary application that would then work with the data. That is still obfucation to an extent because they could still decompile the binary and find your key. Another option I just thought of is if you coded your application that accesses the data to download (over an encrypted connection of course...) the key from a server that you control at your location that the application would then use to decrypt the data. If you wanted to use FDE without manual intervention you would need to modify the OS source to find the key somewhere (unallocated sectors at the end of the disk or between partitions?) that it could access before it tries to decrypt the partition. Obfuscation again. But pretty well obfuscated. Another thing you could do is have a separate partition that is not the boot partition (like /data) that is encrypted and have the boot scripts decrypt and mount the partition. You would need to cary around the passphrase/key on the unencrypted boot partition though. Obfuscaction again (but maybe you could combine this with downloading the key/pass from a server of yours?). The only thing I mentioned that doesn't involve obfuscation or manual intervention is coding an/your application that will download the key from a server to decrypt the data that has been encrypted. You would need to use something like HTTPS with username/password or SCP to transfer the key. The server serving the key should have access to it restricted by IP. Oh, but wait, they could still get the key if they decompile the program that downloads the key and do exactly what it does. Hmmm, still obfuscation I guess. Oh, and no matter what you do, they could always dump the RAM from your VM instance and get your data from there after it's been decrypted. So, yeah, no really good answer that I know of. I'm not an expert in areas such as this, but this is the way I see it. Your best bet is probably encryption combined with some good obfuscation as to what the key is/where to get it. Not moving your data to a VM would make some of these attacks harder but not impossible for a determined attacker. -- John Merriam
