Linux Foundation missing out on OnlyKey?

As described at “Report picks holes in the Linux kernel release signing process” at The Register it seems hardware keys are not mandated and where they are being used they do not provide enough protection:

…the Linux Foundation recommends that kernel developers use smart cards, specifically Nitrokeys, to secure their private key material…[however]…Linux Foundation-issued Nitrokeys do not require users to perform any physical actions when using smart card functions.

The report itself at OSTIF recommends:

…mandating the use of smart card devices that require physical touch to validate each smart card operation.

The Foundation responded in the report:

…because the Yubikey with touch activation is not open source, it is not possible to use for critical infrastructure security.

Seems like OnlyKey could be ideal for them?

@Ian You make a very compelling point here. I would agree OnlyKey meets the objectives of the statements above by the Linux foundation. It’s open source, it works with GnuPG and requires physical touch for all private key operations, it works with SSH and not only requires physical touch it also may require a challenge code to entered via physical touch - OnlyKey User's Guide | Docs

This provides an extra layer of security where a code is generated for the specific application you are using and if a rogue application were to prompt you instead this would generate a different code. Smart card devices do not not have this feature and any application on the device can typically use the smart card without user authorization.

We would be happy to have a conversation with the Linux Foundation on how OnlyKey can help. If you would like to get in touch with them to get the conversation started that would be great.

That’s great - I’ll reach out and let you know.

Hi I went to OSTIF as they were running the project and they have said their security people will look into it to see if it is viable. They were curious if the firmware is a reproducible build? I couldn’t find anything to confirm this myself.

I am not sure what you mean by reproducible build. There is an issue that has yet to be resolved where it is essentially impossible to release security devices that adopt the GPL open source license (the one Linux uses). Because there is something in that license called a tivoization clause. Essentially to be release under this license you have to make it so anyone can load their own firmware on a device, however any security device that allows anyone to load their own firmware is arguably not a security device as it would also allow an attacker to load malicious firmware. Hopefully this will be addressed in a future release of GPL. OnlyKey firmware is released under our own open source license that is similar to the OpenSSL license. You can only load firmware signed by CryptoTrust on an OnlyKey for security reasons About Security | Docs

A reproducible build means a snapshot of the source code will always produce the exact same binary, regardless of who compiles it. It would prove that the source code provided by OnlyKey is EXACTLY the code that is contained in the distributed firmware: reproducible builds

It requires care in the build toolchain to eliminate any transitory data that may change the end binary. For example if a compiler embeds a timestamp in the files it outputs then that would produce a different binary every time.

Regarding the tivoization clause I know that Purism faced a similar situation with their laptops - a requirement to verify that the firmware/boot process is secure by inspecting signed binaries but also allowing end users to control it. They use Heads with a Trusted Platform Module to provide this security/control: Librem adds tamper-evident features, now most secure laptop under full customer control