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
