HOTP concerns

[clinkist]

How much effort would be required to add such a support? The aim would be to not force the user to use OpenPGP-compatible smartcards/tokens. There is a gnupg-pkcs11-scd project, but I'm unsure how feasible it would be to incorporate it.

I hope this isn't too ignorant a question — unfortunately, I'm not very good with technicalities.

[Ingo-Albrecht]

The Nitrokey 3 (main token used for heads, with reverse-hotp support) does have PIV slots as well, i.e. you can use both with it. If you skip reverse-hotp, yubico tokens support both as well.

[clinkist]

But that wasn't really the question, at least I hope I didn't make it sound this way. I'd like to use smartcards/tokens that are not OpenPGP-compatible, like Smartcard-HSM.

[tlaurion]

But that wasn't really the question, at least I hope I didn't make it sound this way. I'd like to use smartcards/tokens that are not OpenPGP-compatible, like Smartcard-HSM.

I don't quite get the use case here @clinkist. You want to replace OpenPGP smartcard for a pkcs#11 one (that answers the what), but not the why nor how.

Purism and Heads developped reverse HOTP on top of nitrokey pro version 1,which became nitrokey pro v2/librem key, so that OpenPGP secured private key could be used to continue to sign content, while the nitrokey could be used through reverse HOTP for remote attestation. So the OpenPGP smartcard+firmware of the usb security dongle could be used to sign and for remote attestation.

Yes Heads could use another standard for signing, with HSM dongles if there is a a need for them. But why and how? What would be used instead, which technology to be used for remote attestation, and who would do the work?

[clinkist]

Does it really need that big justification? Some people, like myself, consider smartcards to be more secure in some specific threat models. Also, what does the "reverse HOTP" bring to the table? User could verify the OTP themselves, manually, like they could always do in Heads, IIRC.

I'm also not sure what is the reason of the question of "who would do the work". I am merely asking a question about effort needed, to get some better view and maybe some pointers for dabbling in it myself. I'm not sure why such feature proposals/question should carry the burden of planning/assigning the work – isn't proposing new features and improvements a benefit for open-source projects in itself? Of course, as long as they don't completely lack merit and aren't completely off-topic, and I hope my proposal meets these criteria.

[tlaurion]

Does it really need that big justification? Some people, like myself, consider smartcards to be more secure in some specific threat models. Also, what does the "reverse HOTP" bring to the table? User could verify the OTP themselves, manually, like they could always do in Heads, IIRC.

@clinkist please take a look at http://osresearch.net/Prerequisites#usb-security-dongles-aka-security-token-aka-smartcard which was updated last week.

And tell me what is left unclear to what HOTP brings to the table in terms of remote attestation, TOTP limitations on clock requiring to be in sync for manual verification (which is often skipped by experience) and why HSM smartcard better then any Yubikey solo key or other currently supported keys (without reverse HOTP).

I'm also not sure what is the reason of the question of "who would do the work". I am merely asking a question about effort needed, to get some better view and maybe some pointers for dabbling in it myself. I'm not sure why such feature proposals/question should carry the burden of planning/assigning the work – isn't proposing new features and improvements a benefit for open-source projects in itself? Of course, as long as they don't completely lack merit and aren't completely off-topic, and I hope my proposal meets these criteria.

I'm asking because whatever additional tools would need to be packed, it would need to be wrapped under oem-factory-reset for OEM use case + user re-ownership, tested and supported forever in init up to kexec boot for everything signature related.

This is why I ask for "why" first. What card, why better. As prior answer from community member, current supported usb security dongle could also support PKCS#11. There is desire to switch from gnupg to another pgp toolstack (for OpenPGP smartcard forever support), where space in SPI chips is limited and tools addition needs real good justifications.

Sorry to insist here: why the need of support for additional smartcard support? Server space? Cloud computing? Unattended smartcard interaction? I need to understand better the use case.

For example, if post quantum crypto is better supported in XYZ, that opens the door to justify looking for alternatives and SPI chips space consomption. Ideally using a toolstack that would support user needed smartcard, but first understanding why is needed.

[tlaurion]

Current codebase:

• use pgg public distro key to verify iso integrity+authenticity of tails, archilux, qubesos, user detached signed iso.
• use gpg +smartcard +fused user public Key in firmware to sign /boot digest and verify /boot integrity and authenticity at each boot so user can be assured things are as last signed with smartcard protected private key
• reverse HOTP is used to verify/attest automatically TPMTOTP + counter (as opposed to TOTP time based protocol) against supported USB security dongle, will return to heads success/failure and visually attest to user (flashing green/red) firmware state prior of continuing with automated boot if successful.

[clinkist]

One advantage of smartcards over hardware keys: PIN pad support. Technically, this only shifts the attacker's PIN-sniffing efforts from software to "real life", but for some, this might be precisely the goal.

As for HOTP/TOTP, clock syncing can definitely be problematic. However, with HOTP's "automatic attestation", there is a risk that my security key could be replaced by a device designed to confuse me and subvert my trust. I know that's a very specific threat scenario, but it is one that is made possible by that "automation".

Also, if I understand correctly, HOTP would be vulnerable to replay attacks. What would stop me from launching an "evil maid" attack where I boot your laptop a few times to gather HOTP codes and then provide those to my custom malware that will deceive your hardware token?

[Ingo-Albrecht]

There are no HOTP codes to gather, replay is not a feasible scenario. There are attacks to extract the HOTP secret from a token (like there are attacks for any secret on them, incl. smartcards). With previous token generations there were also related CVE assigned for successful attacks against their secrets (incl. HOTP but not limited to it). That's a general risk and can happen anytime. To my knowledge, none of the CVE-assigned attacks were feasible remotely, i.e. physical access to the token and disassembly was necessary. The latter mitigates the risk more or less, depending on individual usage.

Your argument re PIN pad support certainly holds. Smartcard readers with pinpad avoid the USB interface. That would be an advantage of a smartcard. On the other hand, a current token PIN can be alphanumeric (higher entropy), and there is no limit on changing it. For example, if you had to use the token on a PC with unknown integrity, you could change the PIN next time and - given the token is physically safe meanwhile, the risk to attack the measured boot due to the PIN sniffing is limited due to the preconditions.

[clinkist]

There are no HOTP codes to gather, replay is not a feasible scenario.

How is that so? As I understand it, an OTP code is generated in Heads (after the secret is unsealed) and sent to the hardware token. I can boot your system, insert a dummy token to receive the codes and then replace Heads with my own software that will send the OTP codes from memory. This will trick you into thinking that everything is OK. This scenario wouldn't work if the codes sent to the hardware keys weren't really OTP codes, and if there were a challenge-response mechanism instead. However, my understanding is that this is not the case.

[tlaurion]

There are no HOTP codes to gather, replay is not a feasible scenario.

How is that so? As I understand it, an OTP code is generated in Heads (after the secret is unsealed) and sent to the hardware token. I can boot your system, insert a dummy token to receive the codes and then replace Heads with my own software that will send the OTP codes from memory. This will trick you into thinking that everything is OK. This scenario wouldn't work if the codes sent to the hardware keys weren't really OTP codes, and if there were a challenge-response mechanism instead. However, my understanding is that this is not the case.

Documentation for HOTP is under the projects usage section of README.md https://github.com/Nitrokey/nitrokey-hotp-verification?tab=readme-ov-file#verifying-hotp-code

[clinkist]

Yes, I've read that. I do not see anything preventing the evil maid / replay attack I described.

[tlaurion]

Yes, I've read that. I do not see anything preventing the evil maid / replay attack I described.

The counter being incremented, it cannot be reused for a calculated HOTP value to be "replayed" unless shared secret is known and combined to generate HOTP code to be validated?

The counter can be read/written under /boot. It is incremented on successful validation of HOTP. Am I missing something?

[clinkist]

Am I missing something?

Believe me, it's awkward for me to suggest so, but I think you may be!

1. Leave your laptop somewhere I have access to.
2. I turn your laptop on a few times with my own version of Nitrokey plugged in. This device saves the HOTP codes received from Heads.
3. I replace Heads on your laptop with a fake one, that will send the codes I got in step two.
4. You return to your laptop unaware of what happened. You insert your Nitrokey and boot the system. The Nitrokey flashes green – it received valid HOTP from the fake firmware I planted. Your Nitrokey's counter wasn't increased, and I have saved quite a few of them, which will hopefully last for enough boots to give me opportunity to get to your laptop again and obtain the decryption password you entered.

[tlaurion]

Am I missing something?

Believe me, it's awkward for me to suggest so, but I think you may be!

1. Leave your laptop somewhere I have access to.
2. I turn your laptop on a few times with my own version of Nitrokey plugged in. This device saves the HOTP codes received from Heads.
3. I replace Heads on your laptop with a fake one, that will send the codes I got in step two.
4. You return to your laptop unaware of what happened. You insert your Nitrokey and boot the system. The Nitrokey flashes green – it received valid HOTP from the fake firmware I planted. Your Nitrokey's counter wasn't increased, and I have saved quite a few of them, which will hopefully last for enough boots to give me opportunity to get to your laptop again and obtain the decryption password you entered.

Reverse HOTP value is shared secret +counter, where counter is incremented at each success of reverse HOTP verification.

Your attack scénario requires attacker to have both usb security dongle and platform to compromise both devices at once and capture exchanged data and put back counter on usb security dongle prior of incremented. Correct?

[clinkist]

No, I don't think my description of the attack scenario suggested that's it necessary to compromise both devices.

OK, let me ask differently. What defines "successful" verification? Could I program a fake Nitrokey so that it would tell Heads "thanks for the OTP, verification successful, go on"?