linuxboot
mitigate relay attacks
Is your feature request related to a problem? Please describe.
Quote https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/
Relay attack
While the TOTP solution cleverly solves the replay attack, it’s still vulnerable to a relay attack.
An attacker could steal your laptop and leave behind an identical-looking malicious laptop. When you (unknowingly) boot the malicious relay laptop, it communicates out to your real laptop — which relays the 6-digit OTP code down to the malicious laptop. You verify that the 6-digit OTP is correct and type your FDE decryption password — which is relayed out to the attacker with your real laptop.
Describe the solution you'd like
a high-speed device, connected via a serial or perhaps USB interface, to manage authentication. This device can send an authentication challenge, receive a response, measure its timing, and verify it. If the response is both valid and received quickly enough, we can trust that the device and its firmware are authentic.
Describe alternatives you've considered
- FlashKeeper
- CPU features
- many more
Additional context
See also Firmware authentication, avoiding relay attacks, where relay attacks are described in detail as well as potential solutions. (Written by @ArrayBolt3 with minor edits by myself.)
This is an interesting discussion to have.
Quick notes from phone.
EK from TPM coukd resolve situation for both tpm1/tpm2. Ref: https://mjg59.dreamwidth.org/70630.html
Stem of problem for replay attacks resides in lack of uniqueness of identity. One direct solution to this coukd be to use TPM manufactured private key, currently unused, to sign/quote/seal/unseal PCRs.
History to not have explored that path up to now is that tpm1 tpm toolstack for tls, needed to deal with tpm and EK counterpart was not supported by mbedtls. Tpm2 toolstack relies in openssl, where tpm1 toolstack could be based on openssl as well since legacy boards (8mb flash) went unmaintained recently.
Tldr: relying on TPM EK would introduce somehow trackable identity, while hidden, and could be used to introduce uniqueness per machine (per tpm).
I haven't digged down that yet, but would solve the problem here, while introducing some drawbacks.
Will revisit this issue and read referred articles. Later.
I don't think the EK will help here, this is relay attacks, not replay attacks. The tricky thing with this is that only authentic data is being shown to the user, but the computer showing the authentic data is not the computer that generated it. Thus a user can be fooled into thinking they're using their own laptop when in reality they're using an attacker's device that will steal their disk encryption passphrase or other data.
Preventing a relay attack, AFAICT, requires ensuring that the computer you're talking to is not only the right computer, but that the right computer is in the location you expect. The easiest way to do this I can think of is to use a high-speed challenge-response authentication mechanism, since a relay will (in theory) add a noticeable amount of delay to the authentication routine. There might be other ways to verify the location of the authentic device but I've not thought of anything robust there (GPS has too many problems to work in that way and who wants their BIOS to have to use a GPS as part of the authentication routine?).
See the quote from the referenced blog article - an attacker can replace a victim's authentic laptop with a malicious one. Theoretically the attacker could then extract TOTP codes from the authentic laptop as needed, and set up the malicious laptop to retrieve one of these extracted codes for display to the user. Obviously this would require a rather sophisticated and targeted attack, mainly because of the difficulty involved in remotely fetching the TOTP codes from the attacker's machine somehow, but it is theoretically possible and very likely feasible. (You could probably embed a Raspberry Pi or similar device with a cellular modem inside the malicious laptop, which could fetch the codes over the Internet and then provide them to the malicious machine's firmware over some sort of bus that could be accessed from inside the machine, not sure if USB would be usable here or not.)
On Wed, Jan 1, 2025 at 12:48 AM Thierry Laurion @.***> wrote:
What would relay what @ArrayBolt3 https://github.com/ArrayBolt3 ?
— Reply to this email directly, view it on GitHub https://github.com/linuxboot/heads/issues/1881#issuecomment-2566876879, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZAFFEXRSQIJCZGJ2Q665I32IOFUXAVCNFSM6AAAAABUKWCAHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRWHA3TMOBXHE . You are receiving this because you were mentioned.Message ID: @.***>
This is result of long local, phone driven discussion with perplexity.ai to play devils advocate with all references that were known to me.
Replay attacks in Heads' context are already highly impractical due to the integration of TPM-sealed secrets and runtime measurements. However, incorporating the TPM Endorsement Key (EK) could further enhance uniqueness and effectively defeat such attacks. Below is a comprehensive analysis.
Replay Attacks in Heads’ Context
Replay attacks rely on replicating or relaying valid data to bypass authentication mechanisms. In Heads, this would require:
- Firmware Cloning: The attacker must replicate the exact firmware, including the GPG keyring, which requires cloning the ROM content.
- Disk Cloning: The LUKS-encrypted disk must also be cloned because the TPM-sealed disk unlock key is tied to the hash of the LUKS container header.
- Runtime Measurements: The kernel and modules loaded during boot are measured into TPM PCRs. Any deviation in runtime state would result in mismatched PCR values, preventing unsealing of the TPM disk unlock key.
- Relay Mechanism: The attacker must forward TOTP codes and FDE passwords in real-time without introducing detectable latency.
These requirements make replay attacks highly impractical under Heads’ current design.
How TPM-Sealed Disk Unlock Keys Work
The LUKS disk unlock key is sealed by the TPM against specific PCR values that reflect:
- Firmware State: Measurements of Heads firmware, including the GPG keyring.
- Runtime State: Measurements of the kernel and loaded modules after boot.
- LUKS Header Hash: The hash of the LUKS container header ensures that only the original disk can be unlocked.
The TPM will only unseal this key if all measured states match exactly. This means that even if firmware and runtime states are replicated, an attacker would also need to clone the LUKS-encrypted disk to succeed.
How EK Enhances Uniqueness
The TPM Endorsement Key (EK) introduces hardware-level uniqueness that could further defeat replay attacks:
- Unique Public Key: Each TPM has a unique EK public-private key pair (EKPub/EKPriv) burned into it during manufacturing. Measuring EKPub into PCRs during boot ties trust not only to firmware and runtime state but also to a specific hardware device.
- Cryptographic Proof: Only the original TPM with EKPriv can respond to cryptographic challenges tied to EKPub, ensuring that measurements cannot be relayed from another device.
- Hardware Binding: Incorporating EKPub into PCR measurements ensures that even if firmware and disks are cloned, trust cannot be transferred to another device without access to the original TPM.
Defeating Replay Attacks with EK
Incorporating EK-based validation into Heads would defeat replay attacks as follows:
- Unique Measurements: By measuring EKPub into PCRs, Heads ensures that PCR values are tied not just to firmware and runtime state but also to a unique hardware identity provided by the TPM.
- Challenge-Response Validation: Using EKPub for challenge-response authentication ensures that only the original hardware can produce valid responses, as it requires access to EKPriv.
- Complete Cloning Requirement: To execute a replay attack, an attacker would need not only cloned firmware and disk but also access to the original TPM or its private EKPriv—a near-impossible task.
Privacy Considerations
Using EKPub raises potential privacy concerns because it acts as a static identifier for the device. To address this:
- Heads could use Attestation Identity Keys (AIKs) derived from EK as privacy-preserving aliases.
- Alternatively, EKPub could be used solely for local validation within Heads without being exposed externally.
Conclusion
Heads already provides robust protections against replay attacks through its use of TPM-sealed secrets tied to firmware measurements, runtime state, and LUKS header hashes. Incorporating EK-based validation would further enhance security by adding hardware-level uniqueness, ensuring that trust cannot be relayed or transferred between devices.
By measuring EKPub during boot and validating it against its unique private counterpart (EKPriv), Heads could cryptographically bind trust to specific hardware, making replay attacks infeasible even under advanced threat models.
We welcome further discussion on implementing this feature and balancing its benefits with potential challenges.
Citations : [1] Chapter 10. Configuring automated unlocking of encrypted volumes ... https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening [2] [PDF] Making Contactless EMV Robust Against Rogue Readers Colluding ... https://fc19.ifca.ai/preproceedings/177-preproceedings.pdf [3] Unlocking of LUKS-encrypted volumes by using TPM 2.0 https://forums.opensuse.org/t/unlocking-of-luks-encrypted-volumes-by-using-tpm-2-0/153976 [4] Trusted Platform Module (TPM) fundamentals - Microsoft Learn https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/tpm-fundamentals [5] electrickite/luks-tpm: Utility to manage LUKS keyfiles sealed ... - GitHub https://github.com/electrickite/luks-tpm [6] Ensuring Cross-Chain Transmission Technique Utilizing TPM and ... https://www.mdpi.com/2079-9292/13/15/2978 [7] TPM no longer unlocks device - Ubuntu Forums https://ubuntuforums.org/showthread.php?t=2491692 [8] [PDF] Avoiding Man-in-the-Middle Attacks When Verifying Public ... https://www.cs.ru.nl/J.H.Hoepman/publications/verifying-public-terminals.pdf
I don't think the EK can help here though because the point of a relay attack in this scenario is to fool a user into trusting a malicious device by using authentic data. Even if you use a challenge-response mechanism that depends on the TPM's EK for signing data in order to prove the authenticity of the device, that doesn't prevent some other device from passing the challenge by just proxying the challenge to the authentic device. If the attacker is in possession of the authentic device, they can take a challenge as input and return the appropriate response as output by using the intact, authentic machine to generate the response. The user asks the malicious device to authenticate itself, the malicious device contacts an attacker's server asking it to provide the appropriate response, the attacker's server provides the challenge to the authentic device, the authentic device authenticates itself to the attacker by calculating the response to the challenge, then the attacker's server sends that response back to the malicious machine, which provides it to the user, thus passing authentication. Essentially the user does authenticate the authentic device, but is led to trust a man in the middle because they think the device they're touching is the device they're authenticating, when really they're two separate machines. A similar strategy should work with TOTP.
Now it is true that it would be tricky at best to make a malicious device that would have the user's data present and accessible on it, assuming the user is using TPM-based FDE. However, TPM-based FDE alone is not enough to protect the contents of a disk, since an FDE key can be extracted from RAM after the system is booted (there are multiple techniques to do this, https://archive.org/details/D3T312201308022200RamMemoryAcquisitionUsingLiveBiosModificationRuudSchramp is one example I saw recently). This kind of FDE bypass could be prevented by using a combination of a TPM FDE key and a PIN or other passphrase, but if the user inputs that PIN or passphrase into an attacker-controlled machine, the attacker can bypass FDE using the stolen passphrase. The user is much more likely to enter their passphrase or other passwords into a malicious machine if that machine looks authentic, and if that machine can pass a cryptographic challenge via a relay attack, that would greatly increase the odds that the user would incorrectly trust the wrong machine.
The AI does have a point with the relay having to not introduce too much delay. I don't think Heads has delay-sensitive code in its authentication routines though.