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?) -- 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 firstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1f4c2d7c-e25c-4143-b988-fb3a72acf4b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.