On Thursday, September 7, 2017 at 9:40:47 AM UTC-4, Patrik Hagara wrote: > -----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-----
only problem with remembering to start the sys-usb is we all forget sometimes. -- 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/06ae6ab7-bfc6-44b2-a603-3e73ea40e104%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
