Basics



Types of "engine":
+/-
  • Management engine which can do many things, including network access, remote control.

  • Trusted module / hardware security module (HSM) which contains crypto keys and runs crypto algorithms.

  • Trusted store which contains an audit trail of system actions.

Some/all of these used to be a separate chip (co-processor) from the CPU, or a dedicated part of the CPU (secure enclave), but now often they're a separate part of the same silicon ("SoC") so no one can spy on the connection between CPU and security module.



Wikipedia's "Trusted execution environment"
/u/SupposedlyImSmart on reddit 11/2018
Gwern's "How Many Computers Are In Your Computer?"
Matthew Garrett's "PKCS#11. hardware keystores, and Apple frustrations"



From ekr's "Hardware Security Modules":
+/-
... Instead of deriving the encryption key from the password, they generate a random encryption key inside of a piece of hardware security module (HSM). What "secure" means varies but ideally it's something like:
  • It can do encryption and decryption internally without ever exposing the keys.

  • It resists physical attacks to recover the keys. For instance it might erase them if you try to remove the casing from the HSM.
In order to actually encrypt or decrypt, you first unlock the HSM with the password, but that doesn't give you the keys, but just lets you use the HSM to do encryption and decryption. However, until you enter the password, it won't do anything.

The main function of the HSM is to limit the rate at which you can try passwords. ...





TPM (Trusted Platform Module)



TPM 1.x and TPM 2 are quite different. In the future, there will be "Pluton", which is backward-compatible with TPM (2?), but has TPM functionality on same chip die as the CPU, and adds more functions.



What a TPM can do/provide:
+/-
  • Provide a hardware random-number generator (RNG).

  • Provide hardware hash and encryption functions.

  • Generate and store cryptographic keys, maybe in association with a password supplied by the user.

  • Provide Platform Configuration Registers (PCRs) that form history chains.
    "each operation that wants to add a value to these PCRs doesn't set them, but rather 'extends' them, which essentially means creating a new hash based on the current value plus the new value".

  • Store a private key, so OS/software holding the public key can securely communicate with TPM.

nandhithakamal's "How to TPM - Part 1: TPM Vocabulary"
nandhithakamal's "How to TPM - Part 2 : TPM Software Stack"
Paolo Fabio Zaino's "Hardware: TPM module"



What a TPM can be used for:
+/-
  • Automatic disk decryption at boot, using a key stored in the TPM, so the disk can't be attached to any other system and decrypted.

    From reddit 2/2024:
    +/-
    > How is TPM-backed full-disk encryption more secure than using a
    > passphrase when (if I understand correctly) the device just
    > starts up without needing any user input at boot?
    > While TPM can prevent evil-maid attacks, how does it prevent
    > someone from just turning on and using your laptop without
    > any passphrase?

    ...

    If your computer boots directly into your desktop without any password, then you're right. However, you should not get to a point where you have access to your data on the computer, without having to put in a password. This does mean that you're dependent on the security of the OS not to let anyone get around the login screen.

    ...

    The TPM doesn't release the encryption key unconditionally.

    It does so only when certain conditions are met as measured by the platform firmware, and this generally enables the owner to unlock the disk only for a known, signed, operating system.

    The purpose is to make file permissions enforceable in practice. Without it, anyone can boot any OS and read, modify, or execute whatever they like without your knowledge. It is not necessary to remove the internal drive to do this, since by design a PC should be capable of booting from external media, like the flash drive you used to install linux.

    Once the disk is decrypted and your OS is running, it can enforce whatever authentication it likes upon the user, including a standard user login.

    ...

    Wwith a tpm unlock you still don't have immediate access to your files. The OS loaded and is up and running, but you still need to input your user password to login, and here you rely on the OS security itself. If you have some form of user auto-login, you skip the DM login somehow, then yes, that's terrible practice and pointless.

    That said, it's important to note that a tpm does not release the keys unconditionally. You actually set what conditions guarantee a key release, you can relax this or tighten this as you see fit. Things that can get measured and taken into account to decide are bootloader integrity, kernel integrity, the computer's firmware integrity, and many others.

    Once you decide on a group of checks (pcr registers to validate), the tpm will always make sure they're the same. Disk got removed to a new computer? Firmware check fails. You have an unencrypted boot partition, and someone placed a malicious kernel to unlock your OS? Kernel check fails. There's even a check for kernel parameters, so no one can just boot up in single[-user] mode and call it a day.

    Of course, all these checks come at a price. It's the same price for the tpm itself. Convenience vs effort. A tpm is all about convenience. "it's my computer, my system, it's me the owner, this whole setup is legit, let me in in few seconds and save me from typing a complex password". But as you add more tpm checks, you're slowly chipping away at this convenience. So you want a kernel check? Now after every kernel update you'll need to boot with luks password, then reset the pcr registers. Convenient? Hassle? Your choice. I personally don't check if it's the same kernel, but instead, I sign the kernel with a personal key (automatic pacman hook, I use arch btw), and trust that my secure boot setup will check that signature and refuse to boot if it's bad. So in that regard, it's also a multipronged approach where different security mechanisms complement each other.

    Oh, and I see comments here about how awful it is to use a tpm because you're locked out if you remove the disk and such. There is ALWAYS a master password. You can't have a tpm unlock in a luks slot without another password luks slot.

    In conclusion: a tpm is all about convenience. If you think about how most people create passwords, store passwords, and try to recall them, then a tpm is much more secure than having a weak or hackable password. You wanting to still input a complex and secure password on every reboot is a 100% valid choice and I will not argue against it. But if you want ease without security compromise, it takes some effort to create it, test it, and understand the angles of attack you personally might face, and you can have that convenience :)


  • Measured boot, where each step's check-sum is added to a PCR and if the final result doesn't match the expected value, something has been changed / tampered with.

Secure Boot does not require a TPM; see "misperceptions" list in Wilkins and Richardson's "UEFI Secure Boot in Modern Computer Security Solutions". There are ways that Secure Boot can use a TPM to provide enhanced features ?



Paraphrased from MiniTool's "AMD CPU fTPM":
"There are 5 types of TPM 2.0 implementations: Firmware TPM (fTPM), Discrete TPM (dTPM), Software TPM (sTPM), Integrated TPM (iTPM), Hypervisor TPM (hTPM)."

In Windows, check by pressing Windows Key + R, type "tpm.msc", then click OK.

In Linux, check via:

fwupdmgr security --force
ls /sys/class/tpm/
cat /sys/class/tpm/tpm0/tpm_version_major
sudo fwupdtool security --force   # security state of system

In BIOS, Advanced Settings, there may be choice between fTPM (firmware TPM) or Discrete TPM. Also there is Intel PTT.

AMD Security Processor may serve as a TPM; your OS may say you have a TPM even though there is no TPM option in BIOS.

Michael Peters' "What Can You Do with a TPM?"
Sergio Prado's "Introduction to TPM (Trusted Platform Module)"
ArchWiki's "Trusted Platform Module"
Microsoft's "TPM recommendations"
Microsoft's "How Windows uses the Trusted Platform Module"
UAPI's "Linux TPM PCR Registry"
Raymond Chen's "Notes on BitLocker and the TPM and the pre-boot password or PIN"
Dell's "Dell Trusted Device: BIOS Security"
Will Arthur, David Challener, and Kenneth Goldman's "A Practical Guide to TPM 2.0" (book)
Lenovo's "A Technical Introduction to the Use of Trusted Platform Module 2.0 with Linux"
Paolo Fabio Zaino's "Linux: What can I do with a Trusted Platform Module (TPM)?"
Pid Eins's "The Strange State of Authenticated Boot and Disk Encryption on Generic Linux Distributions"
Eric Chiang's "The Trusted Platform Module Key Hierarchy"
Michael Altfield's "Trusted Boot"

From someone on reddit 7/2021:
+/-
A big advantage is that the TPM is a separate physical device not all that coupled to the main system, is designed to be physically difficult to impossible to get keys out of, and can enforce brute-force protections via hardware. Every time you fail a PIN, it exponentially backs off and saves that state even across power state changes.

Those keys can be protected not only with a PIN but also with a measurement state of files used to boot the system, up to and including the kernel and loaded modules. That's where things get more complicated, and very inflexible related to the more-freewheeling nature of Linux use vs. Windows use.

I think that difference, as well as possibly a bit of a lingering mistrust (not necessarily unfounded) in TPM manufacturers and the government make TPM much less trusted in general by the open source community. TPM design itself is definitely not open source.

I feel like we've gotten to a very good state regarding TPMs in the Linux world. If you want to be a "user" and run a distro from a vendor, you can enable secure boot and do that. If you want to be a "developer" and modify your system at will, then not as much, ...

"... just about any modern PC, phone, or tablet is relying on some kind of TPM or TPM-like device to provide disk encryption and other security protections. ChromeOS uses TPMs, Android phones use TPMs or equivalent features, and Apple's devices all use the 'Secure Enclave' to handle many TPM-ish functions."

Intel-based Macs have a "T2" chip running "BridgeOS".
Jeffrey Paul's "On Trusting Macintosh Hardware"

"China has its own [alternative] standard called the Trusted Cryptography Module (TCM)"



TPM 2

+/-

# kernel modules, but they may include non-TPM2:
ls -la /lib/modules/`uname -r`/kernel/drivers/char/tpm

ls -l /dev/tpm*
dmesg -T | grep -i tpm
fwupdmgr security --force
ls /sys/class/tpm/
cat /sys/class/tpm/tpm*/tpm_version_major
sudo fwupdtool security --force     # security state of system

sudo apt install tpm2-tools
man -k tpm2
sudo tpm2_getcap -l
sudo tpm2_getcap algorithms | less
sudo tpm2_getcap commands | less
sudo tpm2_getcap properties-fixed | less
sudo tpm2_selftest --fulltest --verbose ; echo $?

# TPM2 Access Broker and Resource Manager
sudo systemctl status tpm2-abrmd --full --lines 1000
sudo dnf install tpm2-abrmd
sudo systemctl enable tpm2-abrmd
sudo systemctl start tpm2-abrmd

sudo dnf install tss2
sudo tssgetcapability -cap 0 | less
man -k tss2

Paolo Fabio Zaino's "Linux: Configure and use your TPM 2.0 module on Linux"
James Bottomley's "TPM2 and Linux"
"Use TPM2.0 to securely decrypt the hard drive in Linux"
Kowalski7cc's "Automatic LUKS 2 disk decryption with TPM 2 and Clevis on Fedora 31"
Javier Martinez Canillas' "Automatic LUKS volumes unlocking using a TPM2 chip"
Alexander Wellbrock's "Automatically decrypt your disk using TPM2"
ijlal-loutfi's "TPM-backed Full Disk Encryption is coming to Ubuntu"
man clevis
Philippe Daouadi's "The ultimate guide to Full Disk Encryption with TPM and Secure Boot"
Loup Vaillant's "Fixing the TPM: Hardware Security Modules Done Right"

From someone on reddit 4/2022:
[In latest Arch and Fedora, use systemd-cryptenroll:]

Fedora:

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7+8 $device 
sed -ie '/^luks-/s/$/,tpm2-device=auto/' /etc/crypttab
dracut -f

Alexander Wellbrock's "Use systemd-cryptenroll with FIDO U2F or TPM2 to decrypt your disk"




Two articles about same operation:
Dan Goodin's "Trusted platform module security defeated in 30 minutes"
Dolos Group's "From Stolen Laptop to Inside the Company Network"



Firmware TPM

+/-
From Helge Klein's "Why Your Machine (Almost Certainly) Has a TPM":
"... chances are excellent that your CPU has an embedded TPM. Ever since Skylake (6th gen), nearly all Intel CPUs have an embedded TPM 2.0 that Intel calls Platform Trust Technology (PTT). AMD CPUs have an embedded TPM 2.0 called fTPM since the AM4 platform (2016)."

MiniTool's "AMD CPU fTPM"





Intel Management Engine (AKA 'ME' or 'CSME')



Wikipedia's "Intel Management Engine"
Intel's "Intel Converged Security and Management Engine (Intel CSME)"
Lily Hay Newman's "Intel Chip Flaws Leave Millions of Devices Exposed"
Erica Portnoy and Peter Eckersley's "Intel's Management Engine is a security hazard, and users need a way to disable it"
Purism's "Intel's Management Engine"
coreboot Wiki's "Intel Management Engine"
Ronald Minnich talk (video)
Igor Skochinsky's "Intel ME Secrets"
Igor Skochinsky's "Intel ME: Two Years Later"
"AMT for Linux"
From someone on reddit:
"Do you have an Intel CPU from the last 10+ years? If so, then yes ME is enabled. If it weren't via HAP, you'd know."
Shane McGlaun's "Here's How To Disable Intel Management Engine And Slam Its Alleged Security Backdoor Shut"
"Sakaki's EFI Install Guide / Disabling the Intel Management Engine"
Steven J. Vaughan-Nichols' "Computer vendors start disabling Intel Management Engine"
Skochinsky and Corna's "Intel ME: Myths And Reality" (PDF)
corna's "me_cleaner"
Vault Labs' "What every CISO and security engineer should know about Intel CSME"
Intel Management Engine Interface driver for Linux
Intel Management Engine Client bus API for Linux
Russell Coker's "AMT/MEBX on Debian"
libreboot's "Intel Management Engine (ME)" section
"Intel ME and AMT" section of PrivSec article
"ls /dev/mei*"

Test your system ?
Intel's "Management Engine Critical Firmware Update (Intel-SA-00086)"

intelmetool from coreboot / coreboot ? But the project's build process is very strange, and failed for me. Also tried to build just intelmetool, and failed.

From someone on reddit:
"After I did the firmware update for my version of IME, I just made sure and disabled everything relating to IME/vPro in my BIOS/UEFI settings and also disabled its related services and related serial port in device manager in Windows."

From someone on reddit:
"Intel ME listens on ports 623, 664 and 16992-16995. So if you're behind a firewall block these ports. Though you'd be better off to create a whitelist instead."





AMD's PSP and CCP



AMD's PSP (Platform Security Processor) and CCP (Cryptographic Coprocessor) hardware.

Wikipedia's "AMD Platform Security Processor"
Google's "AMD Secure Processor for Confidential Computing - Security Review"
"What is known about the capabilities of AMD's Secure Processor?"
"AMD PSP 2.0 AMD Secure Processor"
Specter's "Reversing the AMD Secure Processor (PSP) - Part 1: Design and Overview"
Specter's "Reversing the AMD Secure Processor (PSP) - Part 2: Cryptographic Co-Processor (CCP)"
PSPReverse project/repos
libreboot's "AMD Platform Security Processor (PSP)" section
Apparently this just verifies firmware contents, it has no remote capability ? But see: reddit thread


sudo lshw -class generic
sudo ss -lptun | grep :8732	# supposedly listens here; not on my system

sudo dmesg -T | grep -i -E 'ccp|psp'
grep -i ccp /proc/crypto
modinfo ccp
Greg Marsden's "Using AMD Secure Memory Encryption with Oracle Linux"
CCP-related source code in kernel
more kernel code
OpenSSL and AMD Cryptographic CoProcessor (CCP)
"apt show librte-pmd-ccp20.0"
https://doc.dpdk.org/guides/cryptodevs/ccp.html
"apt show dpdk"
https://forum.gigabyte.us/thread/9479/bug-linux-x570-aorus-initialize
https://elixir.bootlin.com/linux/latest/source/drivers/crypto/ccp/ccp-dev-v5.c#L791
AMD CCP dev says it's a BIOS issue.




Other Security Engines



Chiefio's "For deep security, use ARM, avoid Intel & AMD processors"
But ARM has "TrustZone", used in Android at least ?
Scott Thornton's "Arm TrustZone explained"
Sergio Prado's "Introduction to Trusted Execution Environment and ARM's TrustZone"



Most smartphones have a baseband module running a proprietary OS.
Wikipedia's "Baseband processor"



Qualcomm's AMSS, running in the baseband processor.
Wikipedia's "REX OS"
"AMSS on Qualcomm's MSM Platform"
"Qualcomm amss file structure and compilation process analysis"
vrushabh sutar's "Qualcomm MSM boot process"



From Ronald Minnich talk (video):
"There are 2.5 hidden OS's in the [Windows/Intel/UEFI] system: Intel ME, SMM (the .5), and UEFI."



System Management Mode (SMM):
Microsoft's "System Management Mode deep dive"
"System Management Mode has been around since the 486."
Ronald Minnich talk (video)
Igor Bogdanov's "Security features of the Intel/Windows platform secure boot process"
Jeremy Boone's "Stepping Insyde System Management Mode"



UEFI:
Wikipedia's "UEFI"
Igor Bogdanov's "Security features of the Intel/Windows platform secure boot process"



Anton Shilov's "HP's Endpoint Security Controller: More Details About A New Chip in HP Notebooks"



Pluton:


Raspberry Pi has GPU acting as a management engine:


If you're using a "server" motherboard:
You might have a Baseboard Management Controller (BMC) or IPMI.
Chris Siebenmann's "Sorting out IPMI and BMC terminology and technology"
Patrick Kennedy's "Explaining the Baseboard Management Controller or BMC in Servers"
"ipmitool" or "ls -d /dev/ipmi*" on Linux.
Wikipedia's "Out-of-band management"
Dell iDRAC.



One idea: don't connect network to motherboard's network interface, instead use a third-party network interface board, which the ME shouldn't know how to use.



Thom Holwerda's "The second operating system hiding in every mobile phone"



iPhone:
From article:
"When an iPhone is turned off, most wireless chips stay on. For instance, upon user-initiated shutdown, the iPhone remains locatable via the Find My network. If the battery runs low, the iPhone shuts down automatically and enters a power reserve mode. Yet, users can still access credit cards, student passes, and other items in their Wallet. ... On recent iPhones, Bluetooth, Near Field Communication (NFC), and Ultra-wideband (UWB) keep running after power off ..."



OpenTitan (open-source Root Of Trust chips)
Titan C chip is used in Framework Chromebook computer: article.





Miscellaneous



Gabriel Sieben's "Remote attestation is coming back. How much freedom will it take?"
But see comments.



Sergio Prado's "RPMB, a secret place inside the eMMC"