[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unencrypted boot with encrypted root
From: |
Ellen Papsch |
Subject: |
Re: Unencrypted boot with encrypted root |
Date: |
Sat, 04 Apr 2020 10:12:46 +0200 |
User-agent: |
Evolution 3.34.1 (by Flathub.org) |
Am Freitag, den 03.04.2020, 21:44 +0200 schrieb pelzflorian (Florian
Pelz):
>
> So using a single encrypted partition instead of separate /boot
> protects from script kiddies (siblings/“friends”?) with hardware
> access that know how to put their own grub.cfg on an unencrypted
> /boot
> partition and then wait for you to unsuspectingly use your machine.
>
Yes, it is better known as "evil maid attack", because the original
thought included a hotel room[0].
> But it would still be possible for an attacker to flash or replace
> the
> motherboard’s UEFI, or perhaps the part of GRUB installed on the
> unaltered motherboard would willingly load a manipulated hard disk?
> Or just install a keylogger.
>
Yes, though it should not be so easy like with unprotected /boot
partition.
You have these boot stages in a modern UEFI system (just numbered
sequentially):
- hardware initialization
- stage 0, which is a minimal bootloader including the Secure Boot key
on ROM.
- stage 1, which is Management Engine on Intel platforms or Platform
Security Processor on AMD platforms. Some of it is on ROM, while most
can be (not easily) flashed. ME is a Minix derivate with its own little
processor (ARM IIRC).
- stage 2, which is your UEFI BIOS.
- stage 3, which is the program that gets put in the /boot/efi
directory and registered with the BIOS, i.e. GRUB.
- stage 4-n, Guix!
If you are interested in the flaws of stage 1, check out [1] and [2].
[3] is very interesting too, as it not only presents hardware flaws but
also suggests possible way forward. (These are the same video URLs I
initially posted.)
Breaking any earlier stage gives you control over the later stages.
The general gist is that all common (consumer) hardware is flawed and
with it the software that runs on it. That makes free hardware ever
more important. It's also why people are interested in breaking stage
1; not so much for attack, but because it is closely linked to the
hardware and prevents their freedom.
Regards,
Ellen
[0] https://en.wikipedia.org/wiki/Evil_maid_attack
[1] https://media.ccc.de/v/36c3-10694-intel_management_engine_deep_dive
[2]
https://media.ccc.de/v/thms-38-dissecting-the-amd-platform-security-processor
[3]
https://media.ccc.de/v/36c3-10690-open_source_is_insufficient_to_solve_trust_problems_in_hardware
- Unencrypted boot with encrypted root, Pierre Neidhardt, 2020/04/02
- Re: Unencrypted boot with encrypted root, pelzflorian (Florian Pelz), 2020/04/03
- Re: Unencrypted boot with encrypted root,
Ellen Papsch <=
- Re: Unencrypted boot with encrypted root, pelzflorian (Florian Pelz), 2020/04/04
- Re: Unencrypted boot with encrypted root, Ellen Papsch, 2020/04/06
- Re: Unencrypted boot with encrypted root, Ludovic Courtès, 2020/04/07
- Re: Unencrypted boot with encrypted root, Ellen Papsch, 2020/04/07
- Re: Unencrypted boot with encrypted root, Ludovic Courtès, 2020/04/07
- Re: Unencrypted boot with encrypted root, Ellen Papsch, 2020/04/08
- Re: Unencrypted boot with encrypted root, Alex Griffin, 2020/04/07
- Re: Unencrypted boot with encrypted root, Vagrant Cascadian, 2020/04/07
- Re: Unencrypted boot with encrypted root, Ellen Papsch, 2020/04/08
- Re: Unencrypted boot with encrypted root, Alex Griffin, 2020/04/08