mitigate relay attacks

Nobody has claimed this yet.

**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](https://www.kicksecure.com/wiki/Verified_Boot#Firmware_authentication.2C_avoiding_relay_attacks), where relay attacks are described in detail as well as potential solutions. (Written by @ArrayBolt3 with minor edits by myself.)

Start by reading the linked Firmware authentication page and the referenced relay-attack article, then review the proposed serial or USB challenge-response approach and listed alternatives. No implementation files, tests, or entry points are named; done would require a defined, accepted design for mitigating relay attacks in Heads.

Written by the indexing model from the issue text.