OEM Factory Reset - operation cannot be done while there is no TPM on the motherboard.

[ghost]

@tlaurion

TEST inventory : KGPE-D16 and Nitrokey Start

link 1
link 2

[tlaurion]

@0rb677 Congrats, you found a bug where CONFIG_TPM is not validated as everywhere else in the code base prior to operation

[tlaurion]

@MrChromebox ?

[MrChromebox]

@tlaurion I'd fixed that locally and forgot to push a PR, I'll do that shortly

[MrChromebox]

addressed by #747

[tlaurion]

@0rb677 : merged into #472 Please report success/fail!

[ghost]

@tlaurion OEM FACTORY RESET can't reset gpg-key, on x220 it works.

[ghost]

@tlaurion @MrChromebox

Clear process on x220

[tlaurion]

@tlaurion OEM FACTORY RESET can't reset gpg-key, on x220 it works.

@0rb677
The x220 has CONFIG_TPM=y.
kgpe-d16 has CONFIG_TPM=n

https://github.com/osresearch/heads/blob/cbad9b663724c95508f0eec027841d93c723c006/initrd/bin/oem-factory-reset#L309-L320

Implemented this validation. Screenshots provided, coming from x220, is not testing previous PR.
Which is why it was advised to test new artifact on kgpe-d16 from #472 artifacts

[ghost]

@tlaurion

I dont understand it works with couple of bugs.
Now i attached gpg-card and external USB to PC when heads initialized. Then quit to shell and lauch oem-reset script.

1. It access to gpg-card
2. It generates oem-key
3. It changes Admin/Pin
4. Exporting key to USB
5. Reading Firmware
6. Adding gerenerate key to current firmware and re-flashing
7. Signed boot files and generate checksums

So it works?

[ghost]

@tlaurion congrats it done. but if i do it from recovery shell.

[ghost]

@tlaurion boot from Default boot Menu and /boot is signed by oem-key, also rom is signed too.

[tlaurion]

I'm confused with things unrelated to this ticket and not sure of your state with contradictory information,

If I recall well, your use case made me create:
boards/kgpe-d16_workstation-usb_keyboard/kgpe-d16_workstation-usb_keyboard.conf

so make BOARD=kgpe-d16_workstation-usb_keyboard which on a clear checkout should be at latest commit:

git fetch tlaution
git checkout  kgpe-d16_current_working
git reset --hard
git log

should show

Merge: a3de462 cbad9b6
Author: Thierry Laurion <insurgo@riseup.net>
Date:   Tue Jun 9 13:59:38 2020 -0400

    Merge remote-tracking branch 'mrchromebox/factory_reset_no_tpm' into kgpe-d16_current_working

commit cbad9b663724c95508f0eec027841d93c723c006 (mrchromebox/factory_reset_no_tpm)

[tlaurion]

@tlaurion i cant boot from Default boot Menu and /boot is signed by oem-key, also rom is signed too.

If you flashed a new public key, you changed your rom, measurements are now invalid.
You have to:

• Resign your configs
• Set a new boot default

Screenshots are always helpful.

[ghost]

@tlaurion can you join to channel? It too hard to answer you in so many threads.

[tlaurion]

so @0rb677 is having different behaviors when calling the script from command line vs from the GUI. The command line calls are successful from console, while doing it from the GUI results in this:
https://github.com/osresearch/heads/blob/master/initrd/bin/oem-factory-reset#L66-L68

with /tmp/gpg_card_edit_output being empty and uninformative.

@MrChromebox : any idea why GUI calling /bin/oem-factory-reset is different then from console calling it, which is functional?

[MrChromebox]

@tlaurion nothing jumps out at me, will have to take a look

[tlaurion]

@0rb677 is that still relevant?

[tlaurion]

@0rb677 the kgpe-d16 board is now TPM enabled. So if you want a TPM-less board, you will have to disable TPM inside of the board configs on master.

[tlaurion]

Please close this issue or tag me back if still relevant.

[MrChromebox]

@tlaurion are you still opposed to setting CONFIG_TPM dynamically upon boot as I do in PR #836 ?

[tlaurion]

@MrChromebox Im against rubber ducky USB dongle+storage ressembling nitrokey/librem key, able to sed everything in terminal in a glimpse of an eye where users could be totally unaware of what is happening, and make Heads gui-init, modified, lie about its real state as proposed in that PR while a green led would be flashing, yes.

AFAIK, even flashrom and sha256sum could be copied from that attached and mounted storageto ramfs with proper keyboard sequences and timings entered from rubber ducky HID input, and even interact in a way to fake expected measurements properly, by example mapping found git commit (obtained from /etc/config) and get the proper measurements stored under hashes.txt files for past commits builds, stored under the attached rubber ducky drive. I think we are loosening security bit too far going the convenience path over security, and detailed the reasoning behind it in that PR.

For TPM being dynamically detectable, I have nothing strong against that specific part of that PR following the point you made there. But I would prefer board definitions to specify directly the presence or absence of TPM, without that switch in code even being present at all. And to be frank, I don't really see why it should be dynamic at all but to remove that statement in boards configs. A board comes or doesn't come with a TPM, and in the current state of things, I wouldn't recommend having a USB Security dongle replacing TPM, like I said previously in other tickets, USB is brought too soon with USB keyboard support which was merged, then HID attack possibilities and now TPM dynimically switchable seems to me that we are opening the door for convenience at the cost of real added security.

[MrChromebox]

@tlaurion we have in fact many older Librem 13v2/v3 models which do not have a TPM, as well as ones that do. Having a separate board definition for those is a logistical nightmare, because many times the users aren't even aware. I'll resubmit the part of the patch setting CONFIG_TPM dynamically at boot as a separate PR if you agree, otherwise I'll just keep the patch in Purism's tree for now