On Thursday, September 7, 2017 at 12:49:05 PM UTC-4, cooloutac wrote: > 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.
though maybe for the next final release I will try aem too tks for the info. Although probably should only be doing it once I buy new hardwar. Its probably already too late for me lol, but i'm sure other changes could potentially happen as well. -- 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/1fc5b701-46f3-4822-845d-f8705e4e32a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
