unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ellen Papsch <ellen.papsch@wine-logistix.de>
To: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
Cc: guix-devel@gnu.org
Subject: Re: Unencrypted boot with encrypted root
Date: Sat, 04 Apr 2020 10:12:46 +0200	[thread overview]
Message-ID: <a96461003ce1ff51cf8a39cdb56a8685c2e2a8dd.camel@wine-logistix.de> (raw)
In-Reply-To: <20200403194423.m3pvz654qslug7g3@pelzflorian.localdomain>

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

  reply	other threads:[~2020-04-04  8:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02  8:59 Unencrypted boot with encrypted root Pierre Neidhardt
2020-04-03 15:32 ` pelzflorian (Florian Pelz)
2020-04-03 15:44 ` Ellen Papsch
2020-04-03 16:13   ` Pierre Neidhardt
2020-04-03 17:16     ` Ellen Papsch
2020-04-03 19:56       ` Guillaume Le Vaillant
2020-04-04  9:02         ` Pierre Neidhardt
2020-05-17 15:39         ` Pierre Neidhardt
2020-05-20  8:49           ` Guillaume Le Vaillant
2020-05-20  9:42             ` Pierre Neidhardt
2020-04-03 19:44   ` pelzflorian (Florian Pelz)
2020-04-04  8:12     ` Ellen Papsch [this message]
2020-04-04 10:18       ` pelzflorian (Florian Pelz)
2020-04-06 12:00         ` Ellen Papsch
2020-04-07  9:46           ` Ludovic Courtès
2020-04-07 11:34             ` Ellen Papsch
2020-04-07 20:19               ` Ludovic Courtès
2020-04-08 12:37                 ` Ellen Papsch
2020-04-07 15:05             ` Alex Griffin
2020-04-07 16:47               ` Vagrant Cascadian
2020-04-08 12:25                 ` Ellen Papsch
2020-04-08 15:07                   ` Alex Griffin
2020-04-08 16:22                   ` Vagrant Cascadian
2020-04-08  7:57               ` Pierre Neidhardt
2020-04-08 12:19                 ` Alex Griffin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a96461003ce1ff51cf8a39cdb56a8685c2e2a8dd.camel@wine-logistix.de \
    --to=ellen.papsch@wine-logistix.de \
    --cc=guix-devel@gnu.org \
    --cc=pelzflorian@pelzflorian.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).