-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/07/2017 03:21 PM, cooloutac wrote: > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara > wrote: On 08/29/2017 06:25 PM, cooloutac wrote: >>>> On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik >>>> Hagara wrote: 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. >>>> >>>> The feature protecting dom0 from malicious USB devices [2] >>>> serves a different purpose and is not related to AEM. Plus, >>>> you always need to disconnect all untrusted USB devices while >>>> rebooting Qubes, regardless of whether you have USB qube set >>>> up or not. >>>> >>>> >>>> Cheers, Patrik >>>> >>>> >>>> [1] >>>> https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html >>>> [2] https://www.qubes-os.org/doc/usb/ >>>> >>>> my problem is unfortunately i can't keep buying new pc's. SO >>>> maybe its all for naught for me.. Also AEM does not seem as >>>> reliable as secureboot. Alot of issues on threads with some >>>> people. It seems complicated. even false alarms. But I really >>>> do think they are supposed to compliment each other. trusted >>>> boot and measured boot yes? AEM definitely comes in handy for >>>> people who would find it nescessary to buy new equipment. > > Well, it depends... If you can be reasonably sure that the > attacker did not modify any firmware (eg. the network card), you > could simply reinstall Qubes from a trusted install media and > restore VMs from a backup. This becomes trivial once stateless > computers [1] are a thing. > >>>> But I would still want an encrypted boot, if I was going to >>>> use aem, and key on a external usb disk, which >>>> unfortunately means I could not use a sys-usb. Am I wrong >>>> about this? Does this change in 4.0? > > It is possible to use AEM along with USB qube, you just have to > disable the early hiding of USB devices from dom0. But once Qubes > is fully booted and sys-usb started, you get the full USB qubes > protecion. > >>>> So this is where the what fits into you "security model" >>>> What are you more concered about. I assumed we had to choose >>>> between aem vs sys-usb? For people travelling with laptops >>>> in strange places where physical compromise is more likely >>>> aem is a good option. Some people would prolly not just buy a >>>> new laptop but know when to destroy theirs too lol. > > The only trade-off for AEM regarding USB devices is that the USB > stick you buy to install AEM on could be compromised already > (straight from the factory, or intercepted & infected during > shipping). And since you need to plug it directly into dom0 in > order to perform the install, it could exploit USB or filesystem > drivers and gain control of dom0. > > So it is kind of a trust-on-first-use scenario for the > installation step only. > > > Cheers, Patrik > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > > Doesn't Qubes assume the netcard will be compromised, hence > untrusted.
It does, but with compromised firmware the NIC can inject code into the OS during early boot (before the NIC is isolated from DMA using the IOMMU). AEM will catch/prevent this. > So good to know we can use a usb key with a sys-usb. IS there > some sort of risk to doing this? Do we have to pull out the usb > stick quickly after booting before system loads or something? Not sure about the currently available AEM version, but if/when my changes to AEM get merged, you get prompted to remove the AEM USB stick before Qubes will finish booting (so that the untrusted sys-usb cannot read the contents of the stick). In case the available version does not do this, one possible work-around is disabling sys-usb VM auto-start and start it manually after unplugging the AEM stick. This should IMO be the recommended thing to do anyway, as otherwise it is difficult and potentially insecure to update AEM/Xen/kernel stored on the stick, as you need to shut down sys-usb and manually re-assign the USB controller to dom0, which, if sys-usb was compromised and somehow altered the USB controller incapable of doing a proper PCI Function Level Reset (AFAIK this HW feature is commonly broken, especially for GPUs), it could gain control of dom0. Cheers, Patrik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZsUxSAAoJEFwecd8DH5rlpPQP/iV6UzUWh2W7z9R/7vQd9qh+ TMJTRJkczaBC38i/yNvN2vTDst7EArQYyViyKL1gSdTlbkkaDy1gvg3loav0Nc3I a6Bqnp046uY04152QFCaONFw/TyfN5eLLUYrLfKwtB5TIEVY7bBRkuMkbTnJO+DB VzTdtKY6vCAaFm30e8GDhj/9bfwTz0Y8hPTpJTCZ37BcYl52OjPhQ3VsrRjVorf8 3JtfxlJXMuU3Ap6vaM+HdhoJKKjraAasNYlwuJXjPWzBpuWYWEmMFohfkCdFr1N/ Gli4q4zS/QUHChxCSTHY5q4SOfAGWcBugGlWpW0GEgbi+bmXB4SAsFTmMDhg1nXo A85n0/idbJU5d7xOzTrfaA+uDAXueAktnACjTZ9CTplMGv0hBGOY9dp8N3a+UTHr dipgjZDpc+FByZLR1wZ89899T+lDDnzCU38/knhCsmlnxdhCd1mzspjWIir/Ngfs C/WKc5P4gHFEJNQmsU3lEAFX80dvG7NcYo8zEwppGYFQY8afpepvsifLHl8YnEdX xuR9BRKd626KiHEAPxXAHjCfJOkM+l3Oyq+hg8GDvJft6YjTarfPA2c/52y7hZej UW/pYuKJbK+Nkwsqxu8p6I1qf/MtWf6HsI+m5+e33FKnu/qY+oA+j1ETM1aOnN1I BYXLyrZLwh+4dhWknEU8 =RDNz -----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/016f1657-8861-495d-5f23-ac9cd8434096%40gmail.com. For more options, visit https://groups.google.com/d/optout.
0x031F9AE5.asc
Description: application/pgp-keys
0x031F9AE5.asc.sig
Description: PGP signature
