Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Librem Key support to Heads #426

Merged
merged 10 commits into from
Nov 7, 2018

Conversation

kylerankin
Copy link
Collaborator

The Librem Key is a custom device USB-based security token Nitrokey is
producing for Purism and among other things it has custom firmware
created for use with Heads. In particular, when a board is configured
with CONFIG_LIBREMKEY, this custom firmware allows Heads to use the
sealed TOTP secret to also send an HOTP authentication to the Librem
Key. If the HOTP code is successful, the Librem Key will blink a green
LED, if unsuccessful it will blink red, thereby informing the user that
Heads has been tampered with without requiring them to use a phone to
validate the TOTP secret.

Heads will still use and show the TOTP secret, in case the user wants to
validate both codes (in case the Librem Key was lost or is no longer
trusted). It will also show the result of the HOTP verification (but not
the code itself), even though the user should trust only what the Librem
Key displays, so the user can confirm that both the device and Heads are
in sync. If HOTP is enabled, Heads will maintain a new TPM counter
separate from the Heads TPM counter that will increment each time HOTP
codes are checked.

This change also modifies the routines that update TOTP so that if
the Librem Key executables are present it will also update HOTP codes
and synchronize them with a Librem Key.

The Librem Key is a custom device USB-based security token Nitrokey is
producing for Purism and among other things it has custom firmware
created for use with Heads. In particular, when a board is configured
with CONFIG_LIBREMKEY, this custom firmware allows Heads to use the
sealed TOTP secret to also send an HOTP authentication to the Librem
Key. If the HOTP code is successful, the Librem Key will blink a green
LED, if unsuccessful it will blink red, thereby informing the user that
Heads has been tampered with without requiring them to use a phone to
validate the TOTP secret.

Heads will still use and show the TOTP secret, in case the user wants to
validate both codes (in case the Librem Key was lost or is no longer
trusted). It will also show the result of the HOTP verification (but not
the code itself), even though the user should trust only what the Librem
Key displays, so the user can confirm that both the device and Heads are
in sync. If HOTP is enabled, Heads will maintain a new TPM counter
separate from the Heads TPM counter that will increment each time HOTP
codes are checked.

This change also modifies the routines that update TOTP so that if
the Librem Key executables are present it will also update HOTP codes
and synchronize them with a Librem Key.
The section in gui-init that modifies the Heads TPM counter when signing
config was accidentally removed. This change adds that section back.
TPM v1.2 has a limitation in that only a single monotonic counter can be
incremented between reboots [1]. So in the event we are using HOTP
monotonic counters, we need to reference those for the Heads rollback
counter when we update file signatures in /boot, otherwise the increment
stage at kexec-sign-config will fail since at each boot, the HOTP
monotonic counter has already been incremented.

[1] https://projects.csail.mit.edu/tc/tpmj/UsersGuide.html#inccounter
The HOTP counter isn't a secret but is just used to prevent replay
attacks (the time-based counter in TOTP isn't a secret either) so it
doesn't need to be protected in the TPM and storing it as a TPM
monotonic counter was causing conflicts with the Heads configuration
counter as TPM 1.2 can only increment one counter per reboot.

This change moves the HOTP counter into the file in /boot that was
previously keeping track of the TPM counter id.
Currently the Librem Key tests will time out after 40 seconds, which
adds to the boot time significantly if the user wants to boot without
inserting it. This patch changes that timeout to one second.
Granted the user should really be using the Librem Key/phone to check
for tampering (since an attacker could control the Heads background
color) but this provides another visual queue for the user with
the GUI menu to catch less sophisticated tampering.
@tlaurion
Copy link
Collaborator

tlaurion commented Jun 28, 2018

@kylerankin : having a hard time to get a clear answer from Nitrokey guys on when the Nitrokey Pro v2 will be available (was supposed to be during June).

  1. Do you have any insight on that?
  2. Is there any differences, firmware wise, between Nitrokey's and Librem's?

Thanks!

@kylerankin
Copy link
Collaborator Author

kylerankin commented Jun 28, 2018

@tlaurion

  1. I don't have any insight on their release schedule for their next model, unfortunately.
  2. The Librem Key will use the very latest Nitrokey Pro firmware, this commit in particular: Nitrokey/nitrokey-pro-firmware@664c11b
    This contains specific changes for integration with this Heads PR and those firmware changes were only recently committed. Nitrokeys purchased in the past would be running older firmware that wouldn't contain software changes that enable HOTP checks. Anything running firmware at the above revision would match the Librem Keys. I know that Librem Keys will have that firmware revision but I don't know at what point Nitrokey Pros will include those features.

@tlaurion
Copy link
Collaborator

tlaurion commented Jun 30, 2018 via email

@kylerankin
Copy link
Collaborator Author

Very, very soon! We will make a big announcement on our website when they are ready for purchase.

@tlaurion
Copy link
Collaborator

Nitrokey Pro v2 are ready to order!

@tlaurion
Copy link
Collaborator

@kylerankin : you see any problems that would arise in porting this to other laptops?
The keys will arrive soon! :)

@kylerankin
Copy link
Collaborator Author

kylerankin commented Jul 27, 2018

The underlying code within this PR doesn't have any Librem laptop-specific hooks. If you have a key, the laptop itself shouldn't matter as long as CONFIG_LIBREMKEY is set so the userspace tools are built for that image the next time you build Heads.

That's once this branch gets merged of course :)

@tlaurion
Copy link
Collaborator

@kylerankin Nitrokey Pro v2 contains Nitrokey/nitrokey-pro-firmware@664c11b.

Any documentation on how to enroll laptops with purekeys/nitrokey pro v2?

@tlaurion
Copy link
Collaborator

tlaurion commented Jul 30, 2018

@kylerankin When attempting to build this branch on debian-9 with cmake 3.7.2-1 installed:

2018-07-30 19:44:38-04:00 CONFIG libremkey-hotp-verification
INSTALL=/home/user/Downloads/heads-x230/install cmake -DCMAKE_TOOLCHAIN_FILE=./Toolchain-heads.cmake -DCMAKE_AR=/home/user/Downloads/heads-x230t/build/../crossgcc/x86_64-linux-musl/bin/x86_64-musl-linux-ar . 
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.10 or higher is required.  You are running version 3.7.2

Any reason why depending on 3.10+? On which distro are you building this to be reproducible?

@kylerankin : Note that cmake 3.11 and libusb-devel should be added as a requirement in the doc

@tlaurion
Copy link
Collaborator

tlaurion commented Jul 31, 2018

@kylerankin : I see that cmake 3.11 is in fedora-28.

@kylerankin
Copy link
Collaborator Author

@tlaurion There is no documentation yet as we haven't released Heads + Librem Key as a product combination yet but if you build a ROM with CONFIG_LIBREMKEY, then after you flash and are prompted to refresh the TOTP secret, you will also get prompted to insert your Librem Key after it displays the QR code. It will then prompt you for the Librem Key passcode and it will then update the shared secret between the TPM and Librem Key.

Note that if you are also using the key as a smartcard for signing, you'll want to store a copy of your GPG signing key on it so you can update the signatures on the kexec_ files in /boot, otherwise I suppose you can swap physical keys around.

@tlaurion
Copy link
Collaborator

tlaurion commented Sep 3, 2018

@kylerankin @osresearch @flammit This pull request breaks the unsealing of disk encryption key from TPM_Unseal and cannot be merged as is without causing a regression.

To replicate issue, I've used this branch containing coreboot 4.8 and changes needed to have fbwhiptail working without glitches on x230 with LIBREMKEY required changes included. LUKS release of key through TPM doesn't work. Otherwise, HOTP feature works on the x230, with ordered Nitrokey Pro v2.

Then I tested with this branch which doesn't include LIBREMKEY changes and correctly releases the LUKS encryption key through TPM allright.

@1989gironimo
Copy link

Will the Nitrokey Storage 2 support Heads as well?

@kylerankin
Copy link
Collaborator Author

@1989gironimo The Nitrokey Storage, to my knowledge, uses completely different firmware from the Nitrokey Pro v2 and the Librem Key.

@tlaurion
Copy link
Collaborator

tlaurion commented Sep 12, 2018

@kylerankin @1989gironimo : Nitrokey says that the Nitrokey Storage 2 supports HOTP "but id doesn't contain the Purism-specific verification feature yet."

@1989gironimo
Copy link

1989gironimo commented Sep 12, 2018 via email

@tlaurion
Copy link
Collaborator

tlaurion commented Sep 12, 2018

@1989gironimo

What means "yet" in this context? Is this planned to implement in the future™ or is it just possible to implement but there's no interest in implementing this?

HOTP interaction with Heads has been implemented in Nitrokey Pro v2/LibremKey.
Nitrokey Pro v2 firmware is still not user friendly upgradeable without breaking the plastic shell of the key and hack it's way through the upgrade. As opposed to Nitrokey Pro, the Storage firmware version is user upgradeable.

Nitrokey has the intention of doing it with it's Storage 2, while not giving a clear roadmap on when it will happen.

I've opened a ticket here to track your request.

@1989gironimo
Copy link

1989gironimo commented Sep 12, 2018

@1989gironimo

What means "yet" in this context? Is this planned to implement in the future™ or is it just possible to implement but there's no interest in implementing this?

HOTP interaction with Heads has been implemented in Nitrokey Pro v2/LibremKey as a beginning.
Nitrokey Pro v2 firmware is still not user upgradeable without breaking the key plastic shell and hack it's way through.

Nitrokey has the intention of doing it with the Storage 2, while not giving a clear roadmap on when it will happen.

FYI: As opposed to Nitrokey Pro, the Storage firmware version is user upgradeable. Pressure them for a clearer roadmap! I've opened a ticket here to track the request.

Thanks for your clarification 👍
The reason for asking about the implementation for the Nitrokey Storage 2 is the possiblity to upgrade the firmware which would be more future-proof I suppose.

@tlaurion
Copy link
Collaborator

@flammit : had time to troubleshoot this?

@tlaurion
Copy link
Collaborator

tlaurion commented Oct 17, 2018

@kylerankin @flammit @osresearch : This is a blocker into promoting and using LibremKey / Nitrokey Pro v2 with Heads.

I digged into the code. Merging this PR with coreboot 4.8.1 and gcc8 without activating LIBREMKEY into board config doesn't break TPM LUKS releasing encryption key for default boot. Once LIBREMKEY is activated into the board config file, that feature breaks TPM LUKS release of the key. TPM measurements seem incoherent at that point.

@osresearch : neither @flammit @kylerankin or myself found the real source of the problem regression. Hypothesis is that the TPM measurements are messed with here or there, but your comprehension and insights are needed for this bug to be fixed and #426 to be merged without causing regression.

@kylerankin
Copy link
Collaborator Author

@tlaurion @osresearch Yes, I'm at a loss here since my changes don't touch the LUKS code. Could running the Librem Key userspace hotp code, or loading of the USB modules affect the measurements in a negative way?

@osresearch
Copy link
Collaborator

(Coming into this discussion way late...)

Loading the USB module will affect a PCR since insmod measures the module before it loads it. This allows attestation to reflect which modules were loaded. Is this causing the TPM to not unseal the key?

@tlaurion
Copy link
Collaborator

tlaurion commented Oct 30, 2018

@kylerankin tlaurion@caad2f6 and 54eaba3 needs to be cherry picked.

As pointed by @flammit , the problem was in the sealing, PCR5 being modified by USB modules being loaded.

@tlaurion
Copy link
Collaborator

tlaurion commented Nov 7, 2018

54eaba3 is a partial fix in regard of #470 #471

@kylerankin
Copy link
Collaborator Author

Is 54eaba3 required for this PR though? It seems like it's specifically for usb booting and not to fix the LUKS regression.

When the Librem Key is enabled, the kernel loads USB modules at boot,
this causes PCR5 to change and breaks unsealing the LUKS key (if set).
This change retains the protection of the PCR5 check unless Librem Key
is enabled.
@osresearch osresearch merged commit 79a09e7 into linuxboot:master Nov 7, 2018
@kylerankin kylerankin deleted the add_librem_key_support branch November 7, 2018 21:55
@tlaurion
Copy link
Collaborator

tlaurion commented Apr 13, 2019

@1989gironimo HOTP PR in Nitrokey Storage since January. Should come with next release.

See referred ticket: Nitrokey/nitrokey-storage-firmware#71

Sent from my Galaxy S3 using FastHub-Libre

@1989gironimo
Copy link

@tlaurion cool thing! Has this been tested already with HEADS? I'd be glad to be the Guinea pig :)

@tlaurion
Copy link
Collaborator

tlaurion commented Apr 13, 2019 via email

@szszszsz
Copy link
Contributor

Hi! FYI Nitrokey Storage v0.54 now supports HOTP validation similarly to Nitrokey Pro. Needs small adaptation of the client app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants