Intel ME and AEM/HEADS

[Frank Beuth]

Can someone explain the interaction between Anti Evil Maid/HEADS and the Intel
Management Engine to me?

I read an article which stated that disabling Intel ME also prevents installing
AEM (and related technologies), but I am not sure why (or if this is really
true). Is ME needed to access the TPM?

[Chris Laprise]

Someone correct me if I'm wrong... IIRC the ME processor is needed to
operate the TXT feature which verifies code present at boot. TXT
utilizes a TPM but is separate.

https://en.wikipedia.org/wiki/Trusted_Execution_Technology

Newer systems also have the TPM built into the CPU and I believe these
integrated TPMs also rely on ME to function.

-

Qubes is essentially based on the premise that you have to trust the CPU
manufacturer, but hopefully (someday) _only_ the CPU manufacturer. IOW,
reducing the number of trusted parties as much as possible. However,
many of us believe there needs to be progress beyond even this goal and
that fully open source CPUs should be used as the main component in PCs;
this would have the effect of bolstering trust and accountability.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Frank Beuth]

On Tue, Jan 29, 2019 at 10:09:23PM -0500, Chris Laprise wrote:
> On 1/29/19 8:59 PM, Frank Beuth wrote:
> > Can someone explain the interaction between Anti Evil Maid/HEADS and
> > the Intel Management Engine to me?
> >
> > I read an article which stated that disabling Intel ME also prevents
> > installing AEM (and related technologies), but I am not sure why (or
> > if this is really true). Is ME needed to access the TPM?
>
> Someone correct me if I'm wrong... IIRC the ME processor is needed to
> operate the TXT feature which verifies code present at boot. TXT utilizes
> a TPM but is separate.
>
> https://en.wikipedia.org/wiki/Trusted_Execution_Technology
>
> Newer systems also have the TPM built into the CPU and I believe these

That makes sense, thank you.

Apologies if this is getting offtopic, but: one author suggested that modern
versions of Coreboot could (in absence of Intel ME or AEM) reduce Evil Maid
attacks to physical attacks requiring the attacker to open the laptop and
physically reflash the SPI flash.

Does this sound correct?

[Alexandre Belgrand]

Le mercredi 30 janvier 2019 à 13:07 +0630, Frank Beuth a écrit :
> Apologies if this is getting offtopic, but: one author suggested that
> modern
> versions of Coreboot could (in absence of Intel ME or AEM) reduce
> Evil Maid
> attacks to physical attacks requiring the attacker to open the laptop
> and
> physically reflash the SPI flash.
>
> Does this sound correct?

When flashing Coreboot for the first time, you usually need an SPI
flash cable with physical access to hardware. On some low-end boards,
you may flash directly without physical access.

Once Coreboot is installed, you can reflash your bios within GNU/Linux
using flashbios utility. In this case, Coreboot offers no bios
protection. Coreboot developers have beend asked for a password
protection, but they think it is useless and will not develop such a
feature.

The advantage of Coreboot is that it claims to be able to disable or
limit Intel ME backdoor. In recent versions, Coreboot embeds Intel
blobs, so installing a limited version of Intel ME might not be
sufficient to completely disable it.

[Frank Beuth]

On Wed, Jan 30, 2019 at 09:02:57AM +0100, Alexandre Belgrand wrote:
>Once Coreboot is installed, you can reflash your bios within GNU/Linux
>using flashbios utility. In this case, Coreboot offers no bios
>protection. Coreboot developers have beend asked for a password
>protection, but they think it is useless and will not develop such a
>feature.

Apologies again if this is offtopic, but it sounds like there is a way to
disable software reflashing of Coreboot entirely? Or am I misinformed?

[Alexandre Belgrand]

Le mercredi 30 janvier 2019 à 15:50 +0700, Frank Beuth a écrit :
> Apologies again if this is offtopic, but it sounds like there is a
> way to
> disable software reflashing of Coreboot entirely? Or am I
> misinformed?

https://doc.coreboot.org/flash_tutorial/index.html

Quoting : "Updating the firmware is possible using the internal method,
where the updates happen from a running system, or using the external
method, where the system is in a shut down state and an external
programmer is attached to write into the flash IC."

After flashing coreboot, your bios is wide open for reflashing.
Personally, this is what stops me from adopting Coreboot.

[Maillist]

Only if you configure it that way.Also, even if you do, you wanna make
sure it only accepts updates signed by your personal key.


cheers

[Alexandre Belgrand]

Le mercredi 30 janvier 2019 à 12:38 +0100, Maillist a écrit :
> Only if you configure it that way.Also, even if you do, you wanna
> make
> sure it only accepts updates signed by your personal key.

Interesting. Could you point out the documentation explaining how.
Thanks.

[Frank Beuth]

On Tue, Jan 29, 2019 at 10:09:23PM -0500, Chris Laprise wrote:

>On 1/29/19 8:59 PM, Frank Beuth wrote:
>>Can someone explain the interaction between Anti Evil Maid/HEADS and
>>the Intel Management Engine to me?
>>
>>I read an article which stated that disabling Intel ME also prevents
>>installing AEM (and related technologies), but I am not sure why (or
>>if this is really true). Is ME needed to access the TPM?
>
>Someone correct me if I'm wrong... IIRC the ME processor is needed to
>operate the TXT feature which verifies code present at boot. TXT
>utilizes a TPM but is separate.
>
>https://en.wikipedia.org/wiki/Trusted_Execution_Technology
>
>Newer systems also have the TPM built into the CPU and I believe these

That makes sense, thank you.

[Maillist]

Yes, that is correct.

[Maillist]

Hello,

i woulnd be aware of any documentation regarding this, except this:

https://coreboot.org/status/kconfig-options.html

The option you want to set while configuring coreboot is, depending on
your goal:

INTEL_CHIPSET_LOCKDOWN

and:

LOCK_SPI_FLASH_NO_ACCESS

Quote from the Documentation:

Select this if you want to protect the firmware flash against all
further accesses (with the exception of the memory mapped BIOS re-
gion which is always readable). The locking will take place during
the chipset lockdown, which is either triggered by coreboot (when
INTEL_CHIPSET_LOCKDOWN is set) or has to be triggered later (e.g.
by the payload or the OS).

NOTE: If you trigger the chipset lockdown unconditionally,
you won't be able to write to the flash chip using the
internal programmer any more.

As you can see, depending on how you configure it, imo coreboot is a lot
more secure then stock BIOS, not to mention the fact that it is
opensource , and you can do a lot of fun stuff with payloads, like 2fa
und full disk encryption, which also prevents Evil-Maid attacks at /boot.

Personally, i just like the idea of controlling my own devices, the
security is a nice added benefit tough.;)

I only really go down the security rabbithole with older architectures
like Sandy/Ivy bridge, im not convinced its worth the effort with new,
fully blobbed architectures personally.

Also, keep in mind that if it comes to Evil Maid attacks, the best one
can do is take care of the low hanging fruits.There are just so many
options, and while you also could prevent reflashing the BIOS-chip
externally , i wouldnt be aware of any practical ways of preventing
stuff like hardware-keyloggers in your keyboard etc. Of course, one can
always glue in all screws, or fill the holes with glitter-glue, so any
modifications would be visible.

cheers

[Alexandre Belgrand]

Le jeudi 31 janvier 2019 à 14:21 +0100, Maillist a écrit :
> INTEL_CHIPSET_LOCKDOWN

Nice feature. This makes impossible to update BIOS without physical
access to the chip. I was unaware of this feature, thanks.

[Illidan Pornrage]

On 1/30/19 4:45 PM, Alexandre Belgrand wrote:

I recently answered much of the spcifics in this mailing list, search
for my name.

Write to me directly for specific inquiries, you are explicitly allowed
to post my answer to the mailinglist.

[Frank Beuth]

On Wed, Jan 30, 2019 at 11:00:25AM +0100, Alexandre Belgrand wrote:
>After flashing coreboot, your bios is wide open for reflashing.
>Personally, this is what stops me from adopting Coreboot.

See the recent thread on the Coreboot list about this:
https://mail.coreboot.org/hyperkitty/list/core...@coreboot.org/message/VT6Q6MPIW4PJVT5JALXBQ32W3PD5JFE5/

"Locking coreboot against internal flashing"