>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.
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.
> "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."
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.
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. ;)
On a CoreStorage Filevault 2 system, the Recovery HD is used as the boot loader, calling an EFI program named "boot.efi" present on the filesystem.
On a APFS system things are a bit different; the Recovery HD is still used, however this is now a Logical volume presented from the main volume group, with the update to High Sierra a Firmware upgrade was pushed out to all supported systems enabling the EFI to grok APFS.
This isn't just one of many possible modes, it is automatically enabled on pretty much every new Windows laptop.
I used to work on BitLocker so I'm biased, but it's not pointless at all. If the hardware configuration, firmware, bootloader, boot settings, etc. are unchanged, as measured by Secure Boot and then each subsequent boot component, the TPM releases the key and automatically unlocks the drive. From that point forward, security depends on OS-level authentication and authorization. Even assuming poor hardware-level security, this will still protect against the only reasonable threat faced by most people: access to private data by device thieves or physical intruders.
If you are in the tiny minority that actually wants to protect yourself against sophisticated actors who have exploits for the OS-level security, or the ability to extract keys from a running system or with a cold boot attack, you will want to be selective about your hardware and you might want to additionally rely on a PIN, password, or dongle in conjunction with the TPM/SecureBoot protection.
For Bitlocker it was necessary to print the key after it was generated and keep it somewhere because even some software updates and reboots could get you a screen where you had to type many many numbers and letters -- you could not use some password of yours there. Which wasn't pleasant.
That meant that if you wanted to travel you had to have the printed key with you, or at such reboots at least phone somebody to who you have given that key. Which isn't a problem in an organization, were that somebody are the admins, who were those who made the keys before they gave you the notebook.
I don't know how it works currently, if MS invented something more convenient recently.
You can recover using your Live Account, which contains a copy of the key.
But you still have to type it in.
I do this regularly as a recent W10 upgrade broke the SoftTPM in my Ryzen CPU (no longer recognised at boot), so I type it in everytime I boot windows (so once or three times a month).
It's very resilient since it has a built-in Error Detection Code for each 6 digit pair entered, if you make a typo, it likely will immediately complain and prevents entering any more of the code.
You should use the manage-bde cli tool, or the bitlocker GUI, to remove the TPM protector and replace it with a passphrase. You’ll need to set one of the group policy options to enable using a passphrase.
Have you tried running tpm.msc and resetting it? Maybe also try resetting it in the bios/firmware? Those seem to usually do the trick for solving TPM issues.
The default behaviour is that the secret is uploaded to Microsoft and tied to your Live credentials. You just log into the recovery site and are given an unlock code.
The interesting thing about whole disk encryption is that it is not really breakable if a reasonably long password/phrase is used. Using a TPM adds a huge attack surface for no practical reason. A large enough attack surface in this case that it is almost for sure going to be broken. The user only is going to be entering the password/phrase once per boot.
Things are different in the case of something like a phone. In that case you are pretty much forced to use some low entropy key that could otherwise be brute forced. Then a secure hardware device makes sense, particularly if the phone does not use the device for everything but the kitchen sink as in this case.
Exactly and to elaborate, it means that the only secret a user needs to remember is a short PIN for OS-level authentication. The TPM's protection against modified boot and OS components make a brute force very difficult. Further, Windows will actually feed that PIN to the TPM for purposes of OS-level authentication, which leverages the TPM's enforcement of rate limits and lockouts in addition to OS-level implementations of those protections.
A nice improvement would be to use a PIN entered at boot for purposes of drive decryption and then automatically pass it through to the OS-level login.
It sounds like your threat model doesn’t interactive hardware adversaries. Mine does, so worry about how they might capture my long pass phrase is a big concern.
Well, to whom do I tell my long passphrase? Right: my computer. Every morning. Is it running the same software as last night, no keyloggers, etc?
If the machine (1) has soldered-on RAM (preventing cold boot attacks) and (2) the portions of the OS that run prior to user authentication are sufficiently secure, then it really doesn't seem to be a problem.
Last I knew, Windows does not like to let you enable this mode in a machine with removable RAM that don't have compensating security features.
in what sense is it pointless? If the attacker can’t log into the system, and can’t modify the boot process without invalidating the TPM, then so long as the TPM
is reasonably tamper proof it’s perfectly sufficient for the 99% use case for full disk encryption - a stolen laptop
It doesn’t decrypt the whole disk every time because that takes forever. It releases the key so you can use the disk while it’s encrypted.
It is kind of useless as it’s practically impossible to keep secrets from a local attacker on the Intel platform, but against an attacker that’s not very determined it helps. At least you can’t just boot a Linux cd or put the disk in another machine to get the data.
"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 ?
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
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.
But isn’t the concern about Intel ME mostly on servers which pretty much all have it and aren’t behind firewalls? This surely wouldn’t show on a remote desktop session?
Honestly I care a lot less about ME on servers because at the end of the day, if I see a server misbehaving (sending packets on the wire where it shouldn't) that's going to be a big red flag. Not to mention, egress traffic is indeed filtered. Could they compromise how my applications run? probably. Is there a need to do that? Maybe. Would I see it? certainly.
the concern of ME is for my laptop which many wifi access points have "direct" line access to, it stores all the secrets of my server environment, and even if encrypted a persistent backdoor in ring -1 of my CPU is going to compromise those thousands of servers and in exactly the way I can't defend against.
server ME does not connect to ethernet but BMC do. They may enable something like Secure Boot which requires signing to prevent 3party unauthorized backdoors.
> 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.
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?
Judging from other replies here, answer to your question is "being behind NAT is most probably safe in terms of random remote ME exploitation".
But since there are other attack vectors, and since NAT can technically be circumvented (due to bugs in router, etc., which are NOT uncommon) - you should definitely disable ME if you can (and now there are tools to do that).
Any protection at the router level is from the firewall, not NAT, which only rewrites addresses. NAT does not provide any security benefits on it's own. (see [1] for a longer explanation)
I think the idea here is being that if NAT is used, in the most common meaning, that usually means that the machine behind the router is not Internet-routable. There is no address which can be reached from the internet, that will go to the machine directly. (Which has actual security benefits.)
Of course the abbreviation "NAT" really has a broader meaning, and one can of course set up certain network configurations where the machine would still be Internet-routable, even though NAT is used for something, or the other way around, etc.
Is this what you meant? Judging by the link it seems so.
A clarification could be important, so do you suggest perhaps that the question should have been more like "If my machine does not have a direct Internet address, due to NAT configuration, am I safe from ME exploits"?
> There is no address which can be reached from the internet
Maybe read my previous [1] again?
If you are behind a NAT only - which would be highly unusual - you probably can send packets to it from the internet. The router will simply forward packets that have an internal (RFC 1918) DST address.
That only thing NAT does is rewrite address fields. The reason you usually cannot receive packets directly from the internet is due to the stateful firewall.
> "If my machine does not have a direct Internet address, due to NAT configuration, am I safe from ME exploits"?
Drive by downloads are very much an issue regardless of NATing. Taking advantage of browser exploits or bugs to download and execute arbitrary code/executables.
note: this is common in compromised or malicious ad networks, so just safe browsing habits are not necessarily enough.
I was thinking more in-terms of attacks requiring zero user interaction. But you are right that NAT has no interaction with unwitting-user-type drive-by downloads
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.
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.
IPv6 is also pushing towards a more firewall-heavy network rather than a firewall-less network, usually a NAT implies the presence of a firewall though.
I am no security expert, but if a machine in the local network gets infected and tries to access your ME, then NAT can't prevent the attack. That's the only other vector I can think of.
There's the danger of automated updates, if they are not signed or if the key is compromised.
The NotPetya malware infected a large number of machines by being injected into the update server of a company which developed a tax preparation program. When the program fetched the new "update", the machine got infected.
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.
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