Eric: > On Tuesday, February 23, 2016 at 1:54:30 AM UTC-8, Marek Marczykowski-Górecki > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On Tue, Feb 23, 2016 at 04:11:55AM +0000, Rusty Bird wrote: >>> marmarek: >>>> On Mon, Feb 22, 2016 at 08:52:43PM +0000, Rusty Bird wrote: >>>>> Though even now it should be possible to use AEM without TXT? >>>>> Just don't install the SINIT blob, in which case *only* the LUKS >>>>> header(s) would be protected by the TPM. >>>> >>>> But not having xen/kernel/initrd measured means AEM is pretty >>>> useless. The whole purpose is to verify the thing that prompt you >>>> for LUKS passphrase. Without such measurement you'll have no way >>>> to really know if those binaries were even loaded from your USB >>>> stick (and not from some additional one plugged in by the attacker, >>>> for example). >>> >>> If the order is fixed, i.e. USB before SATA, and you don't see another >>> USB drive sticking into the notebook you left at home, then the part in >>> parentheses wouldn't apply? >> >> It is easy enough to hide USB device inside the USB socket itself (those >> devices are small these days). Or inside your notebook (for example >> instead of bluetooth card, which is also USB device in most cases). >> >> Some more sophisticated attack would be installing some "USB proxy" in >> USB socket. Which would hijack only initramfs reads. You'll not see >> any additional USB device in the system in that case. >> >>>> Such replaced initrd script can present still unmodified LUKS >>>> header to TPM, unseal the secret, show it to you, then record LUKS >>>> passphrase. >>> >>> But Xen/kernel/initrd are on the AEM stick you take with you, so the >>> attacker would have to modify the BIOS. In which case TXT wouldn't help >>> much, because a BIOS rootkit can effectively hide itself from TXT if I >>> understand Joanna right. >> >> But attack hidden from TXT is much more complex than attack simply >> changing boot order. It all depends on your threat model. >> >>>>> If a per-boot BIOS password has been set, maybe this kind of >>>>> setup is even sort of reasonable? >>>> >>>> You are joking, aren't you? >>> >>> Not really. If these assumptions are correct: >>> >>> 1. a BIOS rootkit can hide itself from TXT; >>> 2. an attacker who can boot their own medium can, more and more >>> probably, also persist such a rootkit in the BIOS; >>> 3. there are no BIOS master password lists anymore (are there?), >>> or other easy password prompt bypasses (are option ROMs loaded >>> early enough from ExpressCards?); >> >> I wouldn't rely on BIOS password protection. It failed so many times >> in the history, so I can't assume that magically now BIOS vendors >> learned how to do it properly. >> >>> then it seems to me that a per-boot BIOS password without TXT could work >>> out better than the converse, TXT without a PBBP. Not to say that both >>> together aren't best though! >>> >>> AEM protecting the LUKS header would still be (barely) worthwhile >>> without TXT, if it's easier / faster / less conspicuous for the attacker >>> to take out the HDD and rewrite a few blocks than to infect the BIOS. >>> >>> (BTW Marek, regarding VM random seeds: Have you considered somehow >>> harnessing whatever it is that Thunderbird+Enigmail use to place line >>> breaks in my mails after I hit send) > > Just bought a laptop with a Skylake processor for running Qubes, and from > looking around on Intel's website it appears that no Skylake Core-branded > processors support Intel TXT. Any point in running Anti-Evil-Maid at this > point? Can I use a YubiKey to store hashes of the xen/initramfs and use that > for AEM? (probably not, since it's a USB device?) >
I was just looking around for information on AMT/ME a minute ago. It appears that some Skylake Core i5/i7's do support TXT. (On their website, TXT might fall under the umbrella of vPro.) https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_microprocessors#Skylake_microarchitecture_.286th_generation.29_2 https://en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors#Skylake_microarchitecture_.286th_generation.29_2 -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b9cd97d6-0b62-01bd-1f3f-256fa6f029e6%40gmail.com. For more options, visit https://groups.google.com/d/optout.
