Thank John! Sounds like the best way is to compile a key into a binary and decrypt partitions or files that way.
I'm certain obfuscation is my only real option without manual intervention, and I'm OK with that. I know it won't actually be secure. Mostly I just want to stop curious eyes, I don't need to stop someone really determined. I just want to make sure there isn't some standard way to obfuscate partitions/data in VMs used as appliances. On Tue, Dec 9, 2014 at 11:38 AM, John Merriam <[email protected]> wrote: > 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
