RAM encryption / Confidential Cloud

Patrick · October 24, 2024, 6:07pm

Investigating practicality of process memory encryption techniques using frozen cache and TRESOR/RamCrypt

Patrick · January 1, 2025, 11:48am

mitigate relay attacks

opened 10:57AM - 29 Dec 24 UTC

**Is your feature request related to a problem? Please describe.** Quote http…s://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.)

Patrick · January 1, 2025, 11:57am

github.com/keylime/keylime

mitigate relay attacks

opened 11:57AM - 01 Jan 25 UTC

adrelanos

Does keylime mitigate relay attacks? From what I've read, I would not know how i…t could. What do you I mean by relay attack? Quote [Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)](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. Notes: * Yes: This is about re**lay** attacks. (There is no "`p`" inside the word "`relay`".) As in "to relay", "proxy", man-in-the-middle (MiTM). * No: This is not about `replay` attacks. It is similar to the following issue with OpenPGP / gpg. ``` gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. ``` Or SSH. ``` @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00. Please contact your system administrator. Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message. Offending RSA key in /var/lib/sss/pubconf/known_hosts:4 RSA host key for pong has changed and you have requested strict checking. Host key verification failed. ``` Even with a TPM EK (endorsement key) when provisioning a new server in a untrusted cloud, there does not seem even conceptually a way to resolve this issue. With the TPM EK there is evidence that the customer is talking to "a real TPM". That TPM however might be proxied (MiTMd) through another machine and another TPM. Potential solutions: * TOFU: Ignoring this issue and trust on first use. * local, physical provisioning: Customer provisions their own hardware locally to learn the TPM EK and then ships the hardware to the cloud provider. * cloud provider should publish the TPM EK fingerprint upfront: Before provisioning a server, the cloud provider should be expected to reveal the TPM endorsement key fingerprint. Would that help or would that still be vulnerable to relay attacks? The initial SSH key setup might still get intercepted? 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.) * https://github.com/linuxboot/heads/issues/1881 Purpose of this ticket: * Solve this issue and/or, * document the issue in user documentation / threat model.