Wiki needs improvements

[ThatLurker]

The entire install section should be redone as its really hard to follow and understand.

we could "merge" the content from the current guide with this as base https://github.com/mfc/flashing-docs/blob/master/walkthrough%20for%20flashing%20heads%20on%20an%20x230.md

[tlaurion]

@pahakalle : This guide is unfortunately obsolete.

Can you clarify which section was harder to understand?

If there is one guide I would merge, it would be the one from @merge and promote a simple external programmer for users to use and order which, with flashrom compiled can be used from a secondary computer with:
sudo ~/flashrom/flashrom --programmer ch341a_spi -w ~/heads/build/x230-flash/x230-flash.rom -c MX25L3273E

[ThatLurker]

The instructions mainly line 35 (Ok, now comes the time to write the 4MB...) are a bit hard to follow/read beacause its just a lot of text.

The guide merge has on skulls is a actually really good and with small modifications could just replace the one here

[GittCatt]

Well, I think the wiki still needs improvements, but for me the worst part is configuring TPM — there just isn't anything useful there. Are the appropriate sections from the outdated guide quoted by @pahakalle still applicable, maybe?

[tlaurion]

@Freewolny : using a board config enforcing gui-init instead of generic-gui is not covered at all by the current wiki pages, which still covers everything from the command line and per generic-init usage, and where most command line commands were replaced by simpler ones or by the GUI which manages those tasks easily and manage error situations automatically.

(see x230 board config or x230-hotp-verification, which later requires a Nitrokey Storage/Nitrokey Pro v2/ Librem Key to enforce HOTP verification ).

Following last link: screenshots, instructions etc should take into consideration whiptail usage that is applicable with/without beautiful graphic enforced by FBWhiptail (which is unusable in remote terminal).

For example, the kgpe-d16 PR enforces gui-init without fbwhiptail for servers while enforcing graphical interface with FBWhiptail for the workstation. So that even on compatible server platforms, gui-init can be used instead of currently documented generic-init under wiki, which became kinda deprecated.

Meanwhile this beginner's page was created, which doesn't cover configuration and Heads daily usage.

Any help welcome redoing the wiki pages.... Is there volunteers?

[GittCatt]

Well, when I manage to do everything myself – reflashing the boards in X230, installing Heads and so on, I'll gladly edit the wiki to make it work for complete newbies like me… but I have a feeling that before this happens, I will need a ton of support myself, unfortunately.

[tlaurion]

@Freewolny please read last link of my previous reply. Your concerns are answered there.

[GittCatt]

One more question – is it currently possible to have an additional keyfile for LUKS encryption stored in TPM?

[tlaurion]

@Freewolny yes. Its called a Disk Unlock Key and is enforced by setting a boot default under Heads on all boards having a TPM, but Purism ones, by default.

TPM NVRAM space releases the key on good Disk Unlock Key passphrase if LUKS header and firmware measurements are valid.

When setting a new boot default, the Disk Revovery Key (key slot 0) is required to be typed to renew/change Disk Unlock Key passphrase (slot 1).

[GittCatt]

But from what I understand, in the solution described by you, the TPM is in possession of the whole decryption key, but releases it only after I authenticate myself to it. So if there was a way to extract the key from the TPM, the attacker would only need my laptop and would have the whole disk decrypted. Admittedly, if the attacker is able to do it, he can probably also employ an evil maid attack and sniff my decryption password, but it's still more effort, as I see it.

I'm looking more for a solution described here:

If an attacker is able to capture the user's keystrokes (hidden camera, electromagnetic leaks), the attacker doesn't need Evil Maid attack anymore, and so doesn't need to bother with compromising the system boot anymore. This is because the attacker can just sniff the disk decryption password, and then steal the laptop and will get full access to all user data.

In order to prevent such a “keystroke sniffing” attack, one can use an additional sealed secret on the Anti Evil Maid stick that would be used as a keyfile for LUKS (in addition to passphrase). In this case the knowledge of the sniffed LUKS passphrase would not be enough for the attacker to decrypt the disk. This has not been implemented, although would be a simple modification to dracut-antievilmaid module. If you decided to use this approach, don't forget to also create a backup passphrase that doesn't need a keyfile, so that you don't lock yourself from access to your data in case you lose your stick, or upgrade your BIOS, or something! You have been warned, anyway.