With these Hooks the OTP wont show up:

HOOKS=(systemd consolefont sd-plymouth tpm2-totp autodetect modconf block filesystems keyboard fsck)

I use systemd instead of udev.

Similar to #74, TOTP is not displayed when using systemd initramfs, i.e. following mkinitcpio.conf hooks on Arch:
HOOKS=(… systemd tpm2-totp …)

I tried writing a small systemd unit file and accompanying installation hook, but no luck.
I checked that all the files are present in the initramfs with lsinitcpio and tried to trace unit execution with systemd-analyze plot.
The unit always gets started way too late in the boot process, long after systemd-ask-password-console.service.

Also, tpm2-totp seemed to fail on first invocation during initramfs stage with:
tpm2-totp[…]: failed to allocate dbus proxy object: Could not connect: No such file or directory
Could this be a side effect of having tpm2-abrmd installed? I saw that it uses dbus and usr/lib/libtss2-tcti-tabrmd.so got included in the initramfs.

On a side note - I haven't researched how to stop the service after the initrd.target. Right now it keeps lingering in the booted system until stopped manually.

Thanks for writing awesome tpm2 tools ;)

For reference, the systemd unit (commented out parameters are from exploring possible permutations):
tpm2-totp.service

[Unit]
Description=Display attestation using tpm2-totp
#Requires=dev-tpm0.device
#After=dev-tpm0.device
Before=systemd-ask-password-console.service
DefaultDependencies=no

[Service]
Type=exec
#ExecStart=/usr/bin/show-tpm2-totp
ExecStart=/usr/lib/tpm2-totp/show-tpm2-totp
#StandardOutput=kmsg+console
StandardOutput=tty

#[Install]
#WantedBy=sysinit.target
#WantedBy=initrd.target

… and a small install hook:
sd-tpm2-totp

#!/bin/bash

build() {
    add_systemd_unit "tpm2-totp.service"
}

NOTE: The unit has to be installed in /usr/lib/systemd/system, not /etc/systemd/system, otherwise the add_systemd_unit function fails silently during mkinitcpio and the unit doesn't get included in the initramfs.

Before setting the CLI API in stone for a long time in milestone v1.0, I suggest remodeling the semantics of the sub-commands slightly.

For example:
generate and calculate are semantically not too dissimilar and generate at least some amount of cognitive friction on usage (e.g. generate could just as well refer to generating the TOTP).
I suggest e.g. the following transition:

• generate -> init (ubiquitous and well understood from modern CLI design)
• calculate -> attest or simply show

Also refer to the request for a status command in #85.
Great reference on modern and idiomatic CLI design e.g. here, specifically on sub-commands and noun verb vs verb noun ordering here.

This is less of a pressing issue, than an invitation for an open collection of ideas about future CLI design :)

P.S.: I hope, creating a number of issues is not considered rude - it surely isn't intended that way.

Passing the password as an argument exposes it to other processes via /proc and constitutes a potential leak of this critical secret.

The password should only ever be passed via a file descriptor, possibly stdin per default or if called interactively.

Quoting README.md:

It is not yet possible to specify specific PCR values independent of the currently set PCR values. This would allow disabling the password-less calculate operation after booting the device. This makes most sense, once a TSS2 FAPI is available that will enable an interface to a canonical PCR event log.

Probably the most convenient way to handle this is to add a new option that accepts a file generated by tpm2_pcrlist --out-file.

Since this requires breaking changes to the library ABI, it would be good to implement this before releasing version 1.0.

Currently running tpm2-totp generate with a secret already stored results in

Calling Esys_GetRandom for 20 bytes
Calling Esys_CreatePrimary
WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:333:Esys_NV_DefineSpace_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:122:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x0000014c) 
ERROR in tpm2totp_storeKey_nv (src/libtpm2-totp.c:590): 0x0000014c

ERROR in main (src/tpm2-totp.c:337): 0x0000014c

We should at least use tss2-rc to also return a human-readable error message like "NV Index or persistent object already defined".

Additionally custom error message for common error cases, e.g. "Secret already stored, use tpm2-totp calculate to show the TOTP or tpm2-totp clean to delete the stored secret", would be nice as well.

I'm currently trying to package TPM2-TOTP for QubesOS. As part of this, I would like to verify the source code as released. However, I've been unable to find the public key used to sign releases. I have also noticed that none of the other Linux distributions are using GPG verification of the release tarballs.
Would it be possible to either reply to this issue with the public key or commit it to the repository in a similar way as TPM2-Tools?

Thanks for your work on this.

tpm2-software/tpm2-tss#1417

It would be nice to be able to set the TCTI that is used by the library with an environment variable, see tpm2-software/tpm2-tss-engine#62 for inspiration. This would also make it possible to configure the integration tests to run on a TPM simulator, see tpm2-software/tpm2-tss-engine#86.

Either via doxygen or via .md file

actual default PCRs: 0,2,4 here

documented default PCRs: 0,2,4,6 here and here
In other places, the actual 0,2,4 is documented.

Which ones should it be?

Use these things for more convenience:

• https://github.com/tpm2-software/tpm2-tss/pull/1412/files
• tpm2-software/tpm2-tss@70c3f9e
• tpm2-software/tpm2-tss@2da32c3

I think this is now "calculate"?

May I also ask to generate a new release so that this finds its way into the arch repos?

In order to display the TOTP during boot on Debian/Ubuntu/..., add initramfs-tools hooks to add (plymouth-)tpm2-totp to the initramfs generated by these distributions.

Hello! This is a really neat project and I have a feature request.

Following some of the conversation in issues #74 and #82 I seem to have the plymouth systemd module running correctly. However, I'm not seeing any output. I think it might be because my current setup is a little unique: I'm using the systemd-cryptsetup module to load my encryption key out of the TPM. I see elsewhere (e.g. in this talk) that the code is usually shown while the decryption password is being entered.

I'm wondering if there is a way to get the cryptsetup module to wait until after the Plymouth screen, and if there could be a pause at boot where the TOTP is shown before the disk is decrypted using cryptsetup, with a "Press any key to continue" sort of setup.

I realize that not entering a password is potentially less secure, but I'm in the process of building secure devices for folks with lower tech literacy, and the though of distributing thousands of decryption passwords to them that they have to type in at boot is not a desirable option.

I am experimenting with Debian 12 (bookworm) and measured boot. For that, I have compiled (current latest revision 826c103) and initialized tpm2-totp successfully.

./configure --sysconfdir=/etc --prefix /usr
make -j$(nproc)
make install
tpm2-totp init

When requesting the TOTP value with tpm2-totp show -t I get the correct value 2023-05-06 16:45:06: 005163root@vmware ~ # . I also have installed plymouth that gets also added to the initramfs.

When trying to unlock the encrypted disk from initramfs, however the TOTP values are not shown until the LUKS password was entered locally, which is not what is the intended use of measured boot. ;-)

When logging in via dropbear TOTP values are also not displayed automatically. However, having tpm2-totp added to the initramfs, the correct TOTP values are displayed. The execution of plymouth-tpm2-totp -t from command prompt blocks, but does not output any text on the following line (cursor stays on line start):

~ # plymouth-tpm2-totp -t

Here is a screenshot of the output when operating on console (not via dropbear; roughly waited 5 minutes until LUKS password was entered):

Just for completion, the built Debian package is here (.zip file because Github doesn't support extension .deb):
tpm2-totp_0.3.0+git20230105.826c103-1.deb.zip

Does anyone have an idea what I am doing wrong?
May this be related to #92?

Implement a GUI client in Gnome, GTK, KDE, QT, wxWidgets or whatever for setting up a totp binding.
Thus making it "Desktop ready"

I moved to a systemd-based initramfs. It took me quite a while to figure out there was an sd-tpm2-totp hook added 3 years ago.

It would enhance the documentation if available hooks were added to the man page or the README on this repo. Thanks for your consideration!

Implement an executable that uses plymouth to show the totp value during early boot.
This will alllow the inclusion in initrd systems.

I just tested this package in a fresh Fedora 31 VM (KVM and swtpm).
In the bootlog (journalctl -b) I found this line:

Dec 22 11:11:19 localhost.localdomain systemd-udevd[407]: /etc/udev/rules.d/80-tpm2-totp.rules:1 Invalid value "/sbin/initqueue --settled --onetime /bin/show-tpm2-totp & show_tpm2_totp_pid=$!" for RUN (char 79: invalid substitution type),ignoring, but please fix it.

The strange thing is, it works! I see the correct totp code on the screen.
I built tmpm2-totp from git, following the README.

Before next release, switch to tctildr as stated here: #18 (review)

Some inline declarations of strtok_r (specifically in Sourcery CodeBench Lite 2016.11-19) contain code where an '__s' local variable can be used uninitialized.

When GCC expands that declaration in 'parse_pcrs', __s becomes an alias to the local variable 'saveptr', which in fact is not initialized, but this is not relevant, since the 'str' argument is knowingly not NULL when passed to strtok_r because it comes from 'optarg' in parse_opts.

Anyway, applying the attached patch to initialize saveptr to NULL prevents the compilation error.

fix-compilation-failure.txt

Fixes: http://autobuild.buildroot.net/results/5693a35e4d6bc76a1f46fe0e217abc49f7188aad/

Hello,

is there a possibility to integrate tpm2-totp into pam?
This is already possible with pam_oauth, but the file with the secret needs to be stored on the harddrive. Protecting the secret in the tpm2 would increase the security a lot.

Having a sub-command à la tpm2-totp status to show the currently enrolled configuration would be helpful and very much appreciated.

Infos to display could include:

• general enrollment status
• selected PCR registers
• • possibly with short description for well-known PCRs (man 1 systemd-cryptenroll has a nice summary)
• resealing possible? (enrolled with password or not)
• PCR banks
• nvindex used
• label
• etc.

Possibly/Optionally in YAML format.