Remove TOTP message when HOTP build is used

[UndeadDevel]

Is your feature request related to a problem? Please describe. In my understanding (and as per NitroKey support answer) there are different Heads builds, some of which come with TOTP functionality and some with HOTP functionality; those with HOTP functionality don't support TOTP (this is what I asked support about), so the "secret" displayed there is not actually a relevant secret in my understanding.

Describe the solution you'd like Therefore, to not confuse the user, on HOTP builds the TOTP message (QR code and statements about the secret as well as the plain text secret) should not be displayed.

Describe alternatives you've considered Alternatively it should be made clear to the user that the displayed TOTP secret is irrelevant (if HOTP build is used).

[tlaurion]

@UndeadDevel there is misinformation here. Can you point to the original exchange or quote it here please?

HOTP is technically a "sealing" of TOTP secret into the usb security dongle. Therefore, HOTP variants use TOTP secret for HOTP, where TOTP doesn't need HOTP.

TOTP secret and Qr code is offered by default so that a user can still validate TOTP on phone if HOTP dongle is lost. TOTP is basically a calculated secret based on TPM PCR content which is then sealed inside of TPM nvram with those measurements, and the unseal operation can only succeed if the measurements are the same as when the secret was sealed.

Purism boards deactivate TOTP Qrcode output at tpm reset and relative prompts edit: skip confirmation prompt for convenience since they always shop their products with a Librem key, but at the risk of not having a backup plan if HOTP USB Security Dongle is lost whole waiting for a replacement. TOTP in that case can be used to validate firmware integrity in the momentary absence of a HOTP dongle to reverse HOTP (hotp is a standard) against. I would advise keeping them both, as well as generating keys in ram with backup on usb thumb drive and copying keys to smartcard. That way, if HOTP dongle is lost, you can still sign with that usb thumb drive as if it was a USB security dongle, as well as depend on TOTP to validate firmware integrity prior of typing any passphrase or releasing secrets on your computing device. If we remove TOTP and qrcode we loose that backup plan for remote attestation when usb security dongle is kissing.

Does that make it his clearer?

[JonathonHall-Purism]

As @tlaurion said, Purism ships CONFIG_TOTP_SKIP_QRCODE=y which skips a "Press Enter" prompt between TOTP and HOTP. I can comment on that and the implementation, but I have not reviewed Nitrokey's distribution and I can't speak for them of course :wink:

@tlaurion I think there's a reasonable suggestion here that even though HOTP and TOTP are related internally, we don't necessarily have to show both in the UI, and it is confusing.

@UndeadDevel At least in PureBoot, TOTP can work as a backup - we favor the HOTP path, but it's possible. I think that's why it's still there, I wouldn't want to take away something that might be in use, even if it is uncommon. In PureBoot it's still possible to scan the QR code even though we skip that "Press Enter" prompt (there is another "Press Enter" while it's still on screen). I think the code is still shown on the menu in case you did that and wanted to use it.

I think a great solution, if a bit green-field, would be to make this more runtime-configurable. TOTP could be enabled separately from HOTP, and maybe HOTP could be configured in user config rather than only compile time. Maybe related to #1521 , we could ask in re-ownership what sort of setup you are using - HOTP dongle? TOTP auth? Backup flash drive? Etc. Based on those answers we can decide which features to enable initially.

The challenge I see is that the "serial prompting" nature of our UI makes it difficult to ask a lot of questions like this. A few pictures you can pick from, like "laptop+dongle+phone" or "laptop+flash drive", etc. would go a long way, or even a few check boxes to make it easier to see what questions you need to answer, but we don't have a good way to do either of those. (I hope someday though :wink: )

[JonathonHall-Purism]

Purism boards deactivate TOTP Qrcode output at tpm reset and relative prompts for convenience since they always shop their products with a Librem key, but at the risk of not having a backup plan if HOTP USB Security Dongle is lost whole waiting for a replacement

Actually we don't deactivate the TOTP QR code. We do skip a "Press Enter" (that's all that CONFIG_TOTP_SKIP_QRCODE actually does, maybe the name should be different), but there's another "Press Enter" right around the same time since we also enable HOTP on all boards. Otherwise you're getting multiple "Press Enter"s in a row which is a bit clunky IMO.

I can't speak to the original intent, but the reason I have not changed any of that is to ensure I don't take away something that might be in use, even if it is uncommon.

[tlaurion]

@UndeadDevel this would be a great "discussion" to open.

@JonathonHall-Purism unrelated, but I reviewed code of vaultboot last night before going to bed, and your new PR (untested) to check qubes rootfs would go a long way if combined with their modifications with boot partition labeling and automatic unlocking of LUKS without passphrase for Heads case and asking for passphrase when passing DUK to final OS. I think the UX was bad before and was preventing OEM from shipping that feature which has evolved since then, where security benefits outstands now UX backfire.

The reason I'm adding this unrelated note here is that TOTP / HOTP sealing tales the same password-less sealed nvram secret for a dual case which is somewhat related and could be extended to other use case.

I agree those could be configurable as well, which goes right back to the opened discussion in link of oem-factory-reset/re-ownership next steps, which would benefit of intended use cases to cogite about with input from users.

[UndeadDevel]

Thank you both for your answers! I looked over my exchange with NK support again and I see where the misunderstanding comes from; because of the way I asked the question, linking TOTP to QR code, their answer was actually correct, but I misunderstood it, because I didn't know that "non-QR-code TOTP" is still used in HOTP.

Regarding your discussion then I agree that keeping the TOTP on screen even for HOTP builds makes sense, since the secret is relevant as I now realize.

Closing as not applicable.