libremkey-hotp-verification is not reproducible

[tlaurion]

Side details:

• libremkey is a checkout of nitrokey, renaming directory. Name should be vendor neutral if there is agreement.
• vocabulary used under Heads should be consensual on what should be used to refer to actually used technology and not confuse users furthermore. Is it "HOTP-validating USB security dongle" as opposed to "OpenPGP security dongle" when HOTP visually attesting security features is to be used under Heads?

Technical details here:

• EDIT: The trick applied upstream to fix commit IDs (download specific commit ID related github archives) instead of cloning from git, cannot be applied because it relies on hidapi submodules. That needs to be fixed since, once again, upstreamed version changed last week and CI caches builds unless cache are flushed manually and restarted, which can then builds from scratch, else, git is not redownloading, which is problematic.

On local copy of Heads which was already used to build, that means:
make BOARD=YourBoard real.clean && rm -rf crossgcc && rm -rf build/*/.

Else stating that your builds are working on latest Heads commit id is meaningless and won't produce the same hashes for the same board.

Tasks:

• Agree on vocabulary to be used to talk about GPG card. (OpenGPG security dongle, USB security dongle, USB security key, Heads security dongle/key. Unify language to be used also per manufacturer to describe the product name.
• Find a way to pin libremkey-hotp-verification to a specific commit ID, including it's dependency to hidapi

[tlaurion]

@kylerankin please reply once clarified with Nitrokey.

[kylerankin]

@tlaurion Could you elaborate on what needs to be clarified with Nitrokey? My understanding was that you and Nitrokey were working out what verbiage you wanted to use. I don't have a strong opinion as long as the term isn't too technical (the initial driver for the Librem Key naming originally was avoiding confusion back when some Nitrokey Pros didn't support this feature and we were the only company supporting this use case with Heads--both are no longer the case), and as long as it is applied consistently throughout the UI.

If the phrase used to describe the category of devices ends up being too technical we may end up sticking with "Librem Key" in the fork we ship with our laptops, since we ship them with Librem Keys and that's the easiest way to describe them to our customers who might have a wide range of technical experience. There is already some confusion out there about Librem Key/Nitrokey vs. a regular USB thumb drive since they have a similar appearance (and since in our case we ship both Librem Keys and USB thumb drives with these orders).

[jans23]

How about a less-technical term which instead refers more to the actual use case:

1. "Heads compatible" - however I doubt that Purism's, Insurgo's and soon Nitrokey laptop customers necessary know what Heads is.
2. Better may be "measured boot supporting USB key" or "measured boot compatible USB dongle".

[elsehow]

I'll preface this by saying that I'm most familiar with the Insurgo reownership use-case, so these notes come primarily from this perspective.

From the user's point of view, the device in their hands should always be called the same thing. Qualifying the term "USB security dongle" with terms like "measured boot supporting" or "boot compatible" may be more complex than required: ultimately, the user needs to know what device to grab, and have enough information to discover what role that device plays in the context of reownership and boot.

In that spirit, the most succinct solution for the Insurgo use-case may be to refer to the device as a "USB security dongle" or "USB boot dongle," and to specify HTOP or GPG functionality in context throughout reownership.

[kylerankin]

and to specify HTOP or GPG functionality in context throughout reownership.

I believe the second part of this is in place throughout most of the code base. I know that in the sections we've contributed, whenever the device is being used for GPG we try to use a generic term like "USB security token" because you could use a Yubikey or any number of other USB security tokens that work with GPG. So far we have said "Librem Key" when referring to HOTP operations, like "Please insert your Librem Key" for the reasons I stated above.

So given that multiple companies are supporting this and that devices that are labeled "Nitrokey" and "Librem Key" on the outside would work, it makes sense to change it, since "Please insert your Librem Key" wouldn't make sense to someone who has a Nitrokey, and "Please insert your Nitrokey" wouldn't make sense to someone with a Librem Key. The only question is whether whatever term everyone agrees on would also apply to a Yubikey ("USB security token") and if that's the case, whether anyone is concerned about possible confusion there when using the HOTP function.

There are also functions within Heads like generating a GPG key or flashing a new ROM that prompt the user to insert a USB disk (usually referred to in the UI as "USB drive") so that's another area where picking the wrong term could cause confusion.

[elsehow]

There are also functions within Heads like generating a GPG key or flashing a new ROM that prompt the user to insert a USB disk (usually referred to in the UI as "USB drive") so that's another area where picking the wrong term could cause confusion.

To my eye, "USB drive" or perhaps "USB thumb drive" are sufficiently common parlance as to not be confused with a "USB security token."

It seems the first order of business is to ask: does anyone disagree with the term "USB security token" to describe both Librem Key and Nitrokey? (We can discuss the HOTP/GPG function once there's consensus).

[jans23]

I don't think the term "token" is good because I experienced people misinterpreting it for a software token, like an access token for OpenID or such. Instead I prefer "key" or "dongle" so that would make it "USB security dongle".

[elsehow]

@jans23 That makes sense to me. I would add that "key" might cause similar confusion (key could be a file, like a PK).

In that case, any objections to "USB security dongle"?

[jans23]

@tlaurion pointed out the risk of confusing it with a Yubikey #641 (comment)

To avoid such confusion we should list the supported devices clearly in the documentation. Any suggestions where exactly?

We could underline this aspect by using the term "compatible USB security dongle" which implicates that not all USB security devices would work.

[elsehow]

I think the README is as reasonable a place as any (and is relatively easy to update).

I think it's reasonable to use the word "compatible" on first introduction, along with a reference of where to find compatible keys for your version. After first mention, the term "USB security dongle" alone will probably suffice.

[jans23]

Sounds good to me.

[alex-nitrokey]

I created a quick variant. Please have a look what you think about it.

This change would allow vendor specific versions of the tool. Maybe it is better to overcome this kind of separation upstream altogether though. I am not sure.

There are atches of the upstream version. I am wondering if we should just include them upstream as well (at least those that makes sense there), instead of patching in heads...

[szszszsz]

Just stumbled on this conversation. Let me reuse my comment from Nitrokey/nitrokey-hotp-verification#11 (comment):

Just an idea by the way: brand can be taken from the used device, and stored for the later use for UI needs. No need to have it hard-coded in multiple binaries, unless there is a need to accept only one particular device model.

That is assuming there is any storage available at the boot time. Additionally, all supported devices could be mentioned during the prompt, since they are listed in the binary anyway:

https://github.com/Nitrokey/nitrokey-hotp-verification/blob/1ae3c5be091a3bd8d2bf2b2469d9694be2be06e2/device.c#L41-L46

[kylerankin]

I like @szszszsz 's idea of taking advantage of the fact that we know the list of supported devices in advance, and each now do have unique USB IDs, so we should be able to detect and present the appropriate device name to the user once it has been enrolled (although for the initial "Insert your ____" warning that might require us to store that state somewhere, either as a config value in the cbfs, which would mean reflashing each time we update HOTP, or possibly in the file that contains the HOTP incrementing counter in /boot).

[mfc]

sorry to jump into this thread late -- I like the simple, generic approach outlined by @elsehow.

why not also include the word "Heads" in the name, given we are discussing a HOTP-enabled USB security key/dongle for use with Heads?

the term is very accurate, vendor-neutral, and most consumers (besides Purism customers) will be aware that Heads is the technology being used to provide boot attestation for them. for Purism, it shouldn't be difficult to inform customers about the technology being used given they are informed about coreboot.

re: dongle vs key, my preference would be Key as people are familiar now with keys potentially being USB sticks (Yubikey, Google Security Key, etc).