I have a similar problem with remote systems on cloud farms. You cannot touch the firmware. You can logon to admin panel via internet browser, boot your instance from there, interact with its console, enter the fde password. All this is visible to the cloud farmers.
Ideally, openbsd's boot sequence should pick-up the fde password from a secure server on my premises, automatically, using a sort of remote tpm. Sent from ProtonMail Mobile On Sat, Oct 14, 2017 at 4:26 PM, Bryan C. Everly <br...@bceassociates.com> wrote: > Hi misc@, In playing around with Libreboot and Coreboot, my belief that > physical access to the hardware really ups an attacker’s ability to win > against most security has been massively reinforced. For example, someone > with enough practice could take my Thinkpad T500 apart, force flash the BIOS > (as I have been doing), reassemble it and put it back on my desk in ten to > fifteen minutes (or maybe faster). The payload they flash could easily > include a root kit and keylogger which would mitigate the advantage of Full > Disk Encryption (because they could grab your passphrase keystrokes and send > them off to the mother ship). So my happy little bubble that FDE would give > me protection against all but a brute force attack has been popped. Here’s my > thought. What if we modified our boot code to do a hash of the BiOS and > stored it persistently across boots? Then we could compare it this time to > the last value and take some action / issue some warning that something > changed. It would be mildly annoying if you actually did just update your > BIOS to a new version but that would be a small trade off in my mind at > least. The sticking point is this - where do you store the previous hash? If > we stored it outside of the FDE container, the attacker could just rewrite it > on boot and we wouldn’t be able to detect a change. Put it inside the FDE and > you would have to type your passphrase (sending it to the attacker) to read > it. So now to my ask - would a feature like this be of any interest to > others? If so, any thoughts on how to securely persist the hash to solve the > problem I describe above? Thanks for any and all feedback. -- Thanks, Bryan
