5 ms·
OpenSK: a fully open-source security key implementation
- sam_lowry_ 7y agoGreat news! Yubikeys are priced at 50€, these thingies are 5 times cheaper.
- iambvk 7y agoHaving NFC or Bluetooth on the hardware makes me paranoid. Aren't their software stacks large enough to be a security risk?
- yjftsjthsd-h 7y agoI 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?
- bb88 7y agoAlso even better if there was a solder pad that needed to be connected before the wireless would work.
- ecesena 7y agoThis 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.
- bb88 7y agoI have a solo btw. Its rather nifty. Good job on it.
- tonyarkles 7y agoI'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.
- dochtman 7y agoStill want something with NFC and USB-C, though.
- EspadaV9 7y agoSoloKeys have this (I have one from KickStsrter) - https://solokeys.com/products/solo-tap-usb-c-preorder?variant=27688258863168 https://solokeys.com/products/solo-tap-usb-c-preorder?varian... - they work really well. Been using mine for nearly a year now I think.
- ur-whale 7y agoHardware isn't Open-Source though.
- ungzd 7y agoThey 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.
- swetland 7y agoApart 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.
- zgramana 7y agoFor a mature, non-Google open source _and_ open hardware option: https://solokeys.com/ https://solokeys.com/ Software: https://github.com/solokeys/solo https://github.com/solokeys/solo Hardware: https://github.com/solokeys/solo-hw https://github.com/solokeys/solo-hw
- ungzd 7y agoNot 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.
- nonninz 7y ago> 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 https://www.nordicsemi.com/Software-and-tools/Software/S140
- swetland 7y agoNordic 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/ https://foundries.io/insights/2018/01/08/20180110-ble-dongle... and I believe there are others out there in various stages of completion.
- beagle3 7y agoFIDO2 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)
- CameronNemo 7y agoSeriously, 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 https://www.crowdsupply.com/solokeys/somu
- ecesena 7y agoSupport for openpgp is almost there: https://github.com/solokeys/openpgp 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.
- jeremyw 7y agoLooks 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-2-3/ https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-...
- beagle3 7y agoAwesome! Thanks, I missed that update!
- traceroute66 7y agoHave 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.
- om42 7y agoSeems 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 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.