
Potential impact of the Intel ME vulnerability - pgl
https://mjg59.dreamwidth.org/49611.html
======
upofadown
>The most common usage of TPMs is to protect disk encryption keys - Microsoft
Bitlocker defaults to storing its encryption key in the TPM, automatically
unlocking the drive if the boot process is unmodified.

I had to go look this up. Apparently there is mode of full disk encryption
that automatically decrypts the disk every time you boot up if some stuff has
not been modified. That strikes me as quite pointless.

* [https://en.wikipedia.org/wiki/BitLocker#Encryption_modes](https://en.wikipedia.org/wiki/BitLocker#Encryption_modes)

~~~
lemoncucumber
There are basically three options for how to do disk encryption unlocking:

* The way that e.g. macOS FileVault works, where you enter your password in EFI, before the machine boots and before the OS is loaded.

* The way that e.g. iOS works, where there is an unencrypted partition containing the OS (mounted read-only), and an encrypted partition containing the data. The OS boots off the unencrypted partition, then you have to enter your password to unlock the data partition.

* The mode you're describing, where the unlocking happens automatically if and only if nothing has been tampered with (the encrypted hard drive hasn't been swapped into another machine, etc). With this mode you're relying on the fact that when the OS boots it won't let you do anything without entering a password, even though the disk is already unlocked. Assuming there are no bugs in the login screen, no way to physically read the contents of RAM (where the encryption keys are), and no way to access the contents of the TPM, this approach is just as secure.

~~~
TehCorwiz
> "Assuming there are no bugs in the login screen, [assuming] no way to
> physically read the contents of RAM (where the encryption keys are), and
> [assuming] no way to access the contents of the TPM, this approach is just
> as secure.

That's a lot of assumptions. Or, as Jayne Cobb might say, "I'm smelling a lot
of 'if' coming off this plan."

~~~
marcoperaza
You're hitting a pet peeve of mine, which is the "all or nothing"
misunderstanding of security. You should evaluate security against a threat
model.

Those assumptions that you criticize hold true for the realistic threat faced
by the vast vast majority of people: opportunistic taking of personal data by
device thieves, intruders, and others with physical access to the machine. If
you are worried about more sophisticated attacks, then you can easily ratchet
up BitLocker's security by requiring a boot-time PIN, dongle, or password in
addition to the TPM/SecureBoot measurements. You will also want to be more
selective about the hardware that you use.

~~~
TehCorwiz
I meant only that the default behavior makes a non-trivial set of assumptions
about the higher-level layers. Of course there are trade-offs, especially
between usability/user expectations and security. Honestly I was just trying
to shoe-horn a fun quote into the conversation. ;)

------
rsync
"While AMT gives an authenticated user a great deal of power, it's also
designed with some degree of privacy protection in mind - for instance, when
the remote console is enabled, an animated warning border is drawn on the
user's screen to alert them."

Can someone point me to a picture, or screenshot, of this ?

~~~
mrsteveman1
Rebooted one of my AMT machines so I could take a video of what you see on the
physical screen during boot while the remote console is active:
[https://youtu.be/GDD8os3ZeCI](https://youtu.be/GDD8os3ZeCI)

~~~
vultour
So that’s what it was! I saw this at my previous university one day and no
amount of Google fu could point me towards what sort of remote access tool it
was.

------
krylon
> The big problem at the moment is that we have no idea what the actual
> process of compromise is.

Intel's behavior through this while story has struck me as rather peculiar.

The impression I get (which might be totally wrong - I sure hope that is the
case!) is that Intel hardly admits to anything more than is already public
knowledge.

I really hope I am just misinformed / judging on incomplete information. But
based on what I do know, I find the implications of Intel's behavior rather
disturbing. Even more disturbing than the specific security issues people have
found with the ME.

------
tomc1985
The $10000000 question... generally speaking, am I safe from a potential
drive-by infection if my PC is behind NAT? (Assuming, of course, the router is
not infected or vulnerable and my computer is not DMZ)

Or is there some new attack vector that can pierce those machines reliably?

~~~
jsmthrowaway
It’s safest to never consider NAT and security in the same thought, for a few
reasons. Two come to mind right away: IPv6 is pushing us toward less NAT, and
laptops go other places and interact with other networks than your own.

~~~
wiml
Also (as feikname points out in another comment) because if you're relying on
your NAT for security, your security boundary becomes your network, not your
machine. If you read post-mortems of security breaches, it's really common for
the initial intrusion to be a printer, or webcam, or an
intern's/secretary's/nonprivileged user's device, which then pivots using the
internal network to gain more access.

------
vog
It is quite a common theme on HN that actual infrastructure people speak up
against Intel ME. (for example:
[https://news.ycombinator.com/item?id=15796392](https://news.ycombinator.com/item?id=15796392))

The tone is always along the lines: The advantages of ME for server monitoring
are negligible, but the risks are huge, so they wish they could get all their
hardware without ME.

I wonder if there is any way for you to unite? Maybe to change Intel's mind.
Or to change your manager's mind, to be able to vote with your company's
wallet against ME.

Would that be feasible?

~~~
Asiasweatworker
This petition like a "responsible encryption".

A feasible and easier way is just buy a consumer laptop or shipped with non-
AMT ME and make ME boot into the recovery mode.

