On Tuesday, February 23, 2016 at 1:54:30 AM UTC-8, Marek Marczykowski-Górecki 
> 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 qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to