Re: [cryptography] Integrety checking GnuPG
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 ag4ve...@gmail.com 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 ag4ve...@gmail.com 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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
shawn wilson wrote: I guess I should've said what my use case is: I want a boot system that unlocks a partition where everything is checked [...] However, someone could replace gpg with a version that logs to something. OK, simply provide a Faraday cage to the user and instruct them to boot the device inside of it, hence ensuring a boot process without any RF connection to the exterior. I'm only half joking: if you don't trust the hardware for having a trustworthy boot in some read-only section in the device, then you stated an impossible problem. Also, you may be paranoid about a user device being replaced altogether without the victim noticing the replacement. Do you check that the serial number of your favorite gadget remains stable over time? So in practice you must bear some residual risks when you tailor the boot process towards your goal. In the tailoring project, you might find that GPG is an overkill when only hash/signature validation is required. This is sort of a trusting trust question. So you knew the answer already. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
On Wed, 29 May 2013, shawn wilson wrote: This is sort of a trusting trust question. However, is there a way to have gpg verify it has not been altered? Maybe by compiling it with an internal key file and it asking for a password before decrypting itself and then presenting some type of verification. I'm asking whether something like this exists or is possible? Ie, how does malware do integrety checking / try to thwart people from running it if something is amiss? Can this type of thing be put into gpg? If you run your (linux) kernel in FIPS mode, by passing fips=1 as kernel argument, some OSes such as RHEL or CentOS indeed do have .hmac files they check against the supported crypto libraries to see they have been tampered with. That currently covers libgcrypt, openssl nss and gnutls and the fips approved kernel algorithms. Fips mode also disables non-fips approved (eg blowfish) or weak (eg md5) algorithms. But it's a race. Any (root/admin) compromise on your OS and those checking functions can also be compromised. Paul ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
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 ag4ve...@gmail.com 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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
Herewith my 2c: - run static code analyzer against GPG source code (e.g. llvm's scan-build). Verify GPG source code against keys provided after downloading. (Of course is manual inspection also a possibility, but at least for our team scan-build catches more errors than the humans involved). - Question: do you trust your toolchain?. - Compile from inspected source on a different (never Internet connected and cleanly installed) system. - generate checksums on binary and other related files. - generate GPG keys. - burn GPG binary and GPG keys to CD. - mount CD (read-only) on system-at-risk using a cd-player without writing capability. - run GPG from CD. Caveat: doesn't protect against e.g. live in-memory attacks on running GPG and/or on data presented to user on screen, but minimizes the risk for a lot of other possible mischief. Criticisms concerning cookbooklet above more than welcome. Sincerely, Erick On 05/29/2013 07:20 AM, shawn wilson wrote: This is sort of a trusting trust question. However, is there a way to have gpg verify it has not been altered? Maybe by compiling it with an internal key file and it asking for a password before decrypting itself and then presenting some type of verification. I'm asking whether something like this exists or is possible? Ie, how does malware do integrety checking / try to thwart people from running it if something is amiss? Can this type of thing be put into gpg? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
I guess I should've said what my use case is: I want a boot system that unlocks a partition where everything is checked to prevent an evil maid attack. I can sign / check everything but the key and the integrity checker. However, someone could replace gpg with a version that logs to something. I could use some system like tripwire to check the files but this just moves the vulnerable component to something else. Maybe it's possible to use a signed kernel module that does the integrety checking of the files via a hash that could be compiled into the kernel? Again, this is for a boot system. So I'm in initramfs at this point (shouldn't matter but just thought I'd mention it). On Wed, May 29, 2013 at 1:58 AM, Erick Staal elst...@xs4all.nl wrote: Herewith my 2c: - run static code analyzer against GPG source code (e.g. llvm's scan-build). Verify GPG source code against keys provided after downloading. (Of course is manual inspection also a possibility, but at least for our team scan-build catches more errors than the humans involved). - Question: do you trust your toolchain?. - Compile from inspected source on a different (never Internet connected and cleanly installed) system. - generate checksums on binary and other related files. - generate GPG keys. - burn GPG binary and GPG keys to CD. - mount CD (read-only) on system-at-risk using a cd-player without writing capability. - run GPG from CD. Caveat: doesn't protect against e.g. live in-memory attacks on running GPG and/or on data presented to user on screen, but minimizes the risk for a lot of other possible mischief. Criticisms concerning cookbooklet above more than welcome. Sincerely, Erick On 05/29/2013 07:20 AM, shawn wilson wrote: This is sort of a trusting trust question. However, is there a way to have gpg verify it has not been altered? Maybe by compiling it with an internal key file and it asking for a password before decrypting itself and then presenting some type of verification. I'm asking whether something like this exists or is possible? Ie, how does malware do integrety checking / try to thwart people from running it if something is amiss? Can this type of thing be put into gpg? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Integrety checking GnuPG
On Wed, May 29, 2013 at 11:02 AM, shawn wilson ag4ve...@gmail.com wrote: I guess I should've said what my use case is: I want a boot system that unlocks a partition where everything is checked to prevent an evil maid attack. I can sign / check everything but the key and the integrity checker. However, someone could replace gpg with a version that logs to something. I could use some system like tripwire to check the files but this just moves the vulnerable component to something else. Maybe it's possible to use a signed kernel module that does the integrety checking of the files via a hash that could be compiled into the kernel? You might be interested in checking out Anti Evil Made http://theinvisiblethings.blogspot.it/2011/09/anti-evil-maid.html , an implementation of a TPM-based static trusted boot included in Qubes OS http://qubes-os.org/ . Cheers, alfonso ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
