Reverse HOTP support

[tlaurion]

@oxalica @ZenithalHourlyRate any interest into developing reverse HOTP inside of canokey?
linuxboot/heads#1671 (comment)

Originally posted by @tlaurion in #6 (comment)

Reference : Nitrokey/nitrokey-pro-firmware@cff9575

[tlaurion]

I guess first step would be canokeys/canokey-core#83

@ZenithalHourlyRate @agreenbhm @dangfan @z4yx @z4yx @cnZary @cnZary @Yonghui-Lee
Sorry to ping you all, but this would have important implications for the whole ecosystem, including emulated and hardware based security dongles.

Please contact me through linuxboot/heads project or through https://osresearch.net/community/

I see possible NLnet based funding by co-writing a grant application.

Thank you for your time.

[tlaurion]

Ping. Interest from your side would be needed first .

You can see past collaboration under grant from my side under linuxboot/heads#1729 and ongoing linuxboot/heads#1741

This is serious proposition, while canokey first need to show interest in doing effort.

Please poke me through https://osresearch.net/community/

[dangfan]

@tlaurion Please describe the usage scenarios for this feature, as the goal of Canokey is to serve as a personal identity authentication device rather than an HSM (Hardware Security Module). Understanding the context in which this feature would be used is essential for us.

Additionally, we welcome your pull request (PR) and look forward to your contributions.

[tlaurion]

@dangfan Heads (https://github.com/linuxboot/heads) Open source firmware uses reverse HOTP sealing into the dongle to store a secret,/reverse challenge it. That secret is generated by TPMTOTP, which is coreboot measured boot based, which is a detail, which is basically a hash resulting of coreboot TPM measured boot sealed secret unsealed value, being a challenge against HOTP slot.

On a high level, it is easy to do when HOTP exists, its basically a reverse handshake, using a value to be checked against with the dongle, and the dongle needs to have leds to report if the dongle reports ok(green0/nok(red).

@dangfan We need competition in the realm of security dongles. Today there is two reverse hOTP compliant devices out there: the Librem Key (nitrokey pro 2 clone, firmware updates discontinued by nitrokey) and the Nitrokey (nitrokey pro, nitrokey pro 2, nitrokey storage 2, nitrokey 3: messy for Remote attestation see https://www.nitrokey.com/blog/2024/heads-v25-and-nitrokey-3-firmware-v171-security-update), on which Heads partners depend today)

Your virtualized implementation would be a first test against this, where hotp-verification used under Heads could be an insight on what is currently used by Nitrokey to communicate with the dongle from a client perspective for reverse HOTP verification: https://github.com/Nitrokey/nitrokey-hotp-verification/

<nk3 dongles used gpg Admin PIN set new hotp secret in one predefined slot.

Let me know if you would be interested. More USB Security dongles to compete with Librem key/Nitrokey NK2/NK2 Pro/Nitrokey Storage would be welcome in the ecosystem for remote attestation over personal USB Security dongles, with additonal and met requirements of those dongles being OpenPGP smartcards.

You can test this today with Heads with non-hotp variants, whish uses canokey inside with qemu:
https://github.com/linuxboot/heads/blob/master/README.md#jump-into-nix-develop-created-docker-image-for-interactive-workflow

With docker installed, one can do:
./docker_repro.sh make BOARD=qemu-coreboot-fbwhiptail-tpm2

Goal would be for someone to be able to use HOTP variant with canokey as high level requirement:
./docker_repro.sh make BOARD=qemu-coreboot-fbwhiptail-tpm2-hotp

Let me know if interested. You can contact me over Matrix/Signal from contact link: https://insurgo.ca/#contact