OpenSK: a fully open-source security key implementation | Hacker News Reader

OpenSK: a fully open-source security key implementation

security.googleblog.com

151 pointsel_duderino26 comments

For a mature, non-Google open source _and_ open hardware option: https://solokeys.com/

Software: https://github.com/solokeys/solo

Hardware: https://github.com/solokeys/solo-hw

Not sure if STM32L432 is more "open source" than nRF52840 (does latter require blobs for radios?), but I think OpenSK can be ported to STM32 too. It's probably easier to port TockOS-based OpenSK to different MCUs than STM32_hal-based Solo to something other than STM32.

> nRF52840 (does latter require blobs for radios?)

Yes it does ([1]).

But honest question are there any chipsets out there which doesn't? Maybe some open source projects? The radio protocols are incredibly complex so I would be (pleasantly) surprised if there was.

[1] https://www.nordicsemi.com/Software-and-tools/Software/S140

Nordic provides binary blobs for BLE, but also provides full register level documentation for the radio peripheral, so there's nothing in the way of an open source radio solution with the NRF52 family parts.

Here's one: https://foundries.io/insights/2018/01/08/20180110-ble-dongle... and I believe there are others out there in various stages of completion.

Seems like they're not using the CryptoCell to drive crypto ops and have instead written the cypto algos in software in Rust... from the README (https://github.com/google/OpenSK):

We're currently still in the process on making the ARM® CryptoCell-310 embedded in the Nordic nRF52840 chip work to get hardware-accelerated cryptography. In the meantime we implemented the required cryptography algorithms (ECDSA, ECC secp256r1, HMAC-SHA256 and AES256) in Rust as a placeholder. Those implementations are research-quality code and haven't been reviewed. They don't provide constant-time guarantees and are not designed to be resistant against side-channel attacks.

FIDO2 is nice and all.

I do want a good pgp/ssh compatible card with Curve225519 and can’t find one - yubikey has RSA and P384 iirc, but none have 25519.

(I need to sign data often; rsa 2048, the minimum rsa length acceptable at this point, is both slow on hardware elements and very long)

Looks like this changed for series 5 keys.

In August 2019: "the YubiKey now also supports ... Curve25519, the default curve used in ssh (EdDSA and Diffie-Hellman)", "Addition of Ed25519 signature support, a modern ECC curve".

See https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-...

Have the OpenSSH devs finally relented and allowed support for PKCS#11 with ECC then ? ;-)

Last I saw there were patches put forward to the devs since 2015 and they consistently refused to look at them, let alone merge them.

When last I checked, at least on linux/ubuntu the blocking issue was in opensc-pkcs11, not ssh.

Awesome! Thanks, I missed that update!

Seriously, this is my exact use case. I am using a yubikey with rsa 2048 right now, and I want something a bit stronger. Inexplicably, the Somu stretch goals start with ECDSA then go to Ed25519. Not that either will be reached anytime soon, or that reaching a stretch goal on a crowd funded campaign magically makes the feature appear.

https://www.crowdsupply.com/solokeys/somu

Support for openpgp is almost there: https://github.com/solokeys/openpgp

Note that the ed25519 is not as easy as it seems, ssh agent doesn’t support it yet. I wrote a couple notes/details in the somu campaign you linked, towards the end.

Still want something with NFC and USB-C, though.

SoloKeys have this (I have one from KickStsrter) - https://solokeys.com/products/solo-tap-usb-c-preorder?varian... - they work really well. Been using mine for nearly a year now I think.

Having NFC or Bluetooth on the hardware makes me paranoid. Aren't their software stacks large enough to be a security risk?

I've never implemented NFC, but the embedded BLE stacks I've looked at from various vendors make my eyes bleed. I somewhat feel that way about USB as well, but at least USB is sufficiently simple that interfacing directly with the USB peripheral (on the microcontroller side) is tractable.

I love the silicon that exists in the world today, I truly do, but I really do wonder whether or not TI or ST aught to be building their own SDKs. They just don't have the same software talent that they have on the hardware side.

I mean, if it's properly open source and user-controlled, you should be able to build a firmware that just comments out all of that, right?

Also even better if there was a solder pad that needed to be connected before the wireless would work.

This is more or less what we do with Solo. The NFC keys (both usb-a or usb-c) have an extra NFC chip that harvests energy and powers up the main micro controller. The non-NFC keys don't have that chip, so it's pretty evident by just looking at the board.

I have a solo btw. Its rather nifty. Good job on it.

Great news! Yubikeys are priced at 50€, these thingies are 5 times cheaper.

Y5 Yubikeys cost that much, because they do a lot more than just FIDO/U2F. U2F Yubikeys cost more like $20.

Except you need to program them, and the recommended BOM for that is almost 900USD (unless OpenOCD works, but you still need JTAG hardware).

Hardware isn't Open-Source though.

They don't define hardware in this project. It supports only nRF52840 for now, but I don't think it's too much tied to it and that it cannot be ported to something other.

Apart from having a pretty generous chunk of RAM and flash, the '840 is a 64MHz Cortex M4F -- there's a pretty huge variety of ARM M MCUs out there, especially if you don't care about the radio.

Reply on news.ycombinator.com