-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/29/2017 07:38 PM, David Hobach wrote: > 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: SHA256 >>>> >>>> On 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 boot >>>>> >>>> >>>> AEM 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...
Well, of course. You always have to trust *something*. The ultimate goal is to reduce the trusted code base to bare minimum and provide methods for end-users to verify that the code running actually *is* the one advertised by vendor (eg. ITL). > So the strongest method remains OpSec & physical security. This can > also prevent things. Layered security is the best approach, yes. > 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. Reasonable reaction always depends on the sophistication level of adversary you're trying to defend against (ie. your defense "budget"). Nation states? Burn the laptop. Opportunistic black-hats? You'll be fine simply reinstalling. Cheers, Patrik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZpakTAAoJEFwecd8DH5rl1ewP/1Ewz/i4wEEAUizlgDzstwlf 41/2PVh6bvhzb+QhK95O7UxtbHhqFF4NttrkAzlQw7Uwsi/l6i0tRuvAZu7tLTqw KfaQj2F2lGm3GVSNwhuVH2NcZaZ5U3FpBk4/PcP/ONBoLp0blxlIbEvfEfScP9Ly xW1T7sbINqS76qKh42ds9hf8FYrN8vrHMxRYfLZAlmXNZvTIvMpF1YwiZyHiDdrQ vprfXU9dPHEjUN63f22G+CaDCYYXdk/Pb7QDAbA0YuN1tQyxgkgZMB2Ks37A0UD7 vDQBiM91ynU703QOVDr8Icn0otshv/RR+GFxfJPugA+3YUjYN+dOY5c1qAaM4bVZ QoCoe2ApFpEt2HCKq5grm1cge6LEK+d4ym6sjB9PoL4/T4FMq2fnO6s+xoIlvWZZ 1FmQVJtTEmuiaMOHtwxLaM80sD6s/9cq/w7fIMlba86uFlesNOgpkDfm9SoYtQYc 94RT6CAd7CyThn+lhTH3YGNrt320cP/fFPTp4gjHQOf9su7vjtrN7tKVD6o6bD1n PlbRqw40SQRovtTSR5UPJEMlqbScC91aeL/glDXNuXEcz+Jz+YvmHiAi/UCz79k9 XwEc/2wjD5xMw+hmajaXNQOOnUA5VRNJNLuPBOxrZxxBpZef7SV0lcf5WqDkdhq9 QA8qanASHTTQo3y5r9JA =cZ7m -----END PGP SIGNATURE----- -- 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/37ed7d3f-921e-8cac-adb0-df3e0c1897cd%40gmail.com. For more options, visit https://groups.google.com/d/optout.
0x031F9AE5.asc
Description: application/pgp-keys
0x031F9AE5.asc.sig
Description: PGP signature
