It is not always the case that the full BIOS ROM is authenticated. Here is some prior research that leveraged OEM customization of the boot splash to exploit a vulnerability in the bitmap parser to implement a boot kit: http://www.blackhat.com/presentations/bh-usa-09/WOJTCZUK/BHUSA09-Wojtczuk-AtkIntelBios-SLIDES.pdf
On Thu, May 30, 2013 at 6:47 PM, shawn wilson <[email protected]> wrote: > I was not asked to keep this off list but removing attribution just in > case. > > > > > On Thu, May 30, 2013 at 8:49 PM, shawn wilson <[email protected]> > wrote: > > > Thanks for all of the input. In the end I think I'm going to go with > > > the simplest solution (along the way, I found ima-linux and signelf). > > > > > > Let me know if what issues there are with this: > > > Encrypt the LUKS passkey in a text file. > > > Encrypt a user defined message and file checksums in another file with > > > a different password. Decrypt this file first and display the message > > > (letting the user know that if it doesn't look right, they should > > > stop). Get the hashes of all of the files and compare them with the > > > data in the text file and report if anything didn't match. If all is > > > good, prompt for the password of the second file. > > If the evil maid installs herself in the BIOS or a periphery's ROM, > > then there's not a lot you can do. The user's password will always be > > exposed. You could even boot to a thumb drive, perform the integrity > > check, and things would still look fine from the outside. > > > > If the hardware is altered in an undetectable manner, you're right. But is > the boot image is altered (ROM or otherwise) the checksum process would > fail. I could even have a simple pass/fail test case to show the user that > diff or comm were not altered. > > Also, I think there is kernel support for reading most BIOS models. So > maybe next, I should look into that. Though, I think at the point of > altering hardware is where I need to call it quits - someone could modify > any PCI card and as long as it was loaded at that point, there will be at > least some leakage and I can't verify everything. Either way, I'll see how > far I can get with dumping hardware data and hashing it as well. > > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography > >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
