> On Tuesday, February 23, 2016 at 1:54:30 AM UTC-8, Marek Marczykowski-Górecki 
> wrote:
>> 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.)

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 post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to