Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIDO2 stack on nRF52840 DK + BLE support? #501

Open
coco21 opened this issue Jan 21, 2021 · 3 comments
Open

FIDO2 stack on nRF52840 DK + BLE support? #501

coco21 opened this issue Jan 21, 2021 · 3 comments

Comments

@coco21
Copy link

coco21 commented Jan 21, 2021

Hello,

I was wondering how easily it is to port and make run your FIDO2 stack on a nRF52840 DK and that communication goes over BLE rather than USB. Studied quite deeply your porting doc pages and understood main interfaces between your FIDO2 stack and the communication channels is (today) USB HID abstraction layer. I was thinking about running your FIDO2 stack on a Nordic native Zephyr-based OS as you can find in their sample code and use their e.g. S313/340 based softdevice BLE stacks (https://www.thisisant.com/developer/components/nrf52832/).

My question: how hard, difficult would it be to achieve that? Does this make sense in your eyes?
I also am testing and running OpenSK FIDO2 stack but that also is missing BLE stack support as of today with a connection to the FIDO2 stack.

Thank you for a quick answer, I do this for an evaluation phase and need to take some decisions.

@nickray
Copy link
Member

nickray commented Jan 21, 2021

Hi @coco21, this is two questions in one :)

On the one hand, portability as such. The existing v1 key C code did run on other platforms in the past, and has been adopted by other projects. The idea would be to add a new target under targets/. Whether it's a good idea, especially integrating into an embedded OS, I do not know. For the v2 key Rust code (coming very soon!), I intend to port it to the nRF52840 Dongle ASAP, as a proof of concept of that code base's "modularity and portability". However, this would be in that code base's frameworks (https://rtic.rs/ for scheduling, our own Trussed framework for cryptography and secure storage). The blocker for that is USB support (nrf-rs/nrf-hal#133, nrf-rs/nrf-hal#199, nrf-rs/nrf-hal#199).

The other is Bluetooth. The open question is how sensible that is for a security key in general. As for specifics, on the Rust side, I don't have any experience with BLE, so I can't say much unfortunately.

If you'd like to discuss, I'm @nickray on Keybase, or you can hop into https://matrix.to/#/#solokeys-dev:matrix.org

@coco21
Copy link
Author

coco21 commented Jan 22, 2021

Hey @nickray thanks so much, that was quick!
I have good hopes to port Solo FIDO2 stack onto another platform, and it's C, that one we master. Liked the idea of weak definitions and HID as the interface between the FIDO2 stack and the USB stack - was thinking swapping out USB by BLE stack at HID level plus some tweaks would make it. Regarding the BLE stack I am about to bring in Nordic's (Thisisant) S340 Softdevice bin blob, easy to integrate at Solo end? At Nordic end suppose that shall be via some placeholders already proposed by Nordic.
Regarding security and such don't mind, this is for evaluation - so if we even can get rid of BT pairing that's perfectly OK.

Ok I get it, let me study your answer during that weekend and discuss with my team. Good news you don't say no but rather are talking options, like that. Will come back quickly. Will check to hop into your link, thank you, cool! Cheers Chris

@coelner
Copy link

coelner commented Jan 30, 2021

FYI: https://github.com/google/OpenSK/ and related to that: google/OpenSK#266

and furthermore: https://crates.io/crates/rubble-nrf52

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants