On 08/29/2017 06:32 PM, cooloutac wrote:
On Tuesday, August 29, 2017 at 12:25:51 PM UTC-4, cooloutac wrote:On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256On 08/29/2017 04:50 PM, [email protected] wrote:Leo Gaspard, I have read about AEM but have never used it, it seems like it is geared towards protecting from USB's with malicious firmware on them. Does AEM actually verify the integrity of /boot before using? This is what I am looking for, either a method of encrypting /boot or even better, a secure method to verify its integrity during bootAEM does verify the integrity of /boot using the TPM seal/unseal operation. If any of the boot components change, AEM falls back to regular, unmeasured boot -- the user is expected to notice this and cease using the potentially-compromised system (the lack of explicit indication of failed AEM boot is deliberate, see the last FAQ item at [1]). The security provided by AEM is much more stronger than encrypted /boot could ever offer, because as already pointed out, there is always a little first-stage bootloader stub on the disk unencrypted and it would be easy to overwrite it with a malicious version that would intercept the encryption passphrase and exfiltrate it using eg. unused disk sectors. If someone did the above with AEM, the TPM would refuse to useal the AEM secret as the platform state would be different.
You still have to trust the TPM manufacturer, some closed source Intel blob and some ITL code, i.e. I'd definitely test changes to /boot & your BIOS to cause the TPM to deny revealing the secret if I had to rely on it - the cheapest implementation is an "everything's ok" on every request after all...
So the strongest method remains OpSec & physical security. This can also prevent things.
Moreover the fewest people tend to buy new hardware once they detect a change via their TPM even though that would be the only reasonable reaction. So if you don't plan to do that, I'd forget about AEM.
-- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e6756da2-fc92-085c-b3ee-df45a2ed1379%40hackingthe.net. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
