search

solokeys / solo1

Solo 1 firmware in C
https://solokeys.com/
Other
2.31k stars 274 forks source link

roadmap #199

Open Zjemm opened 5 years ago

Zjemm commented 5 years ago

Hi there,

I could not find any roadmap for the solokey's.

I know there where plans for adding SSH keys, openpgp keys e.t.c. maybe OTP?

but is there some planning on these functions?

bepvte commented 5 years ago

https://www.crowdsupply.com/solokeys/somu This is launching soon, and it looks like with it will come openpgp support for other devices

conorpp commented 5 years ago

We're working on OpenPGP right now which will work with gnugp and SSH. Campaign for Somu is launching soon, and the funds we raise from that will go to OpenPGP development.

Zjemm commented 5 years ago

Nice, and what about otp? And static passwords?

0x0ece commented 5 years ago

OTP is unlikely because it requires server interaction, as the keys have no way to keep track of time. I'm not excluding it completely and we could host a server, but I don't see much reasons for people to use otp on a security key vs an app. (also it'd require some good amount of pentest, yubikey 2 had a weak implementation of aes that lead to vulns in otp -- overall cost/benefit seems very low.)

Static passwords should be easier. It feels very insecure to me (if you click by mistake, your password gets visible), but if people want it, why not.

Zjemm commented 5 years ago

Ok otp seems a bit more complicated, but doable. You could put it on the roadmap.

Maybe start a poll for features like that?

About static, I'd really like that. Because it's used as an add-on static. So you type your password and ad a static string by pressing the key. It makes the password longer and therefore more secure

0x0ece commented 5 years ago

That's a great way to use static key, we should also add it/recommend it into the docs.

Zjemm commented 5 years ago

Isn't it also a good idea for solo to create a authenticator app for iOS/Android?

Solokeys could expand 😄

deepsweet commented 5 years ago

Somu:

We plan to add ECDSA keys first, followed by Ed25519.

Awesome. GPG/SSH Ed25519 is the reason I finally found Solo project and this particular issue after 2 days of researching about Yubikey, Nitrokey and such... Any plans to add Ed25519 to Solo USB-A/C later on?

Definitely going to try Somu, thanks for making this happen.

0x0ece commented 5 years ago

Thank you @deepsweet. Unfortunately Ed25519 in SSH is a bit more challenging than it seems. The space is fragmented and many features are lacking from other tools.

For example, while OpenSSH supports Ed25519 curves and we could add support to our firmware, connecting the dots isn't as straightforward as it seems.

Neither OpenSSH agent (the client) nor OpenSC (the PKCS11 driver) support Ed25519 curves. Any help to add support for Ed25519 curves in OpenSSH agent and OpenSC is greatly appreciated.

hardfalcon commented 5 years ago

OpenSSH's key agent does support Ed25519 (I've been using this for years), and is has done so since OpenSSH 6.5, which was released in December of 2013. However, some other SSH key agents don't support it or haven't supported it for a long time - one example was the agent included with gnome-keyring, until they finally decided to simply wrap OpenSSH's agent starting with GNOME 3.28.

The current stable version 2.40 of the PKCS#11 specification does not support EdDSA (the generic superset of Ed25519 and Ed448), which is probably the reason why OpenSC doesn't support it yet. PKCS#11 3.0 is supposed to support EdDSA, but that specification is still a working draft.

However, there's already preliminary header files available, which include said EdDSA support.

You may want to have a look at the SoftHSMv2 project which claims to have implemented support for Ed25519.

nickray commented 5 years ago

@hardfalcon: Yes, ssh-agent can cache Ed25519 keys that are in some file. As far as I know (please correct me if I'm wrong, because I'd love to be!), there is no way to inject non-file keys into ssh-agent apart from the PKCS#11 interface, which itself only just recently gained support for ECDSA (i.e. NIST p-256): https://www.openssh.com/txt/release-8.0.

Regards to your other comments (FYI):

hardfalcon commented 5 years ago

Sorry, my bad, I had overlooked the "for PKCS#11" detail.

Thanks for the FYI links, and thanks for maintaining python-pkcs11!

0x0ece commented 5 years ago

FYI, we presented Solo at Teardown 2019, including a couple minutes on our roadmap: https://youtu.be/ji7Hvg2L6i0?t=10721

Slides are here (roadmap is at slide 36): https://docs.google.com/presentation/d/17-CWeitWJsxishVSwDpjazVUtAuqNJikipDhnJyRo9g/edit?usp=sharing

I guess we need to find a way to formalize it/publish it somewhere.

returntrip commented 5 years ago

OTP is unlikely because it requires server interaction, as the keys have no way to keep track of time. I'm not excluding it completely and we could host a server, but I don't see much reasons for people to use otp on a security key vs an app. (also it'd require some good amount of pentest, yubikey 2 had a weak implementation of aes that lead to vulns in otp -- overall cost/benefit seems very low.)

Static passwords should be easier. It feels very insecure to me (if you click by mistake, your password gets visible), but if people want it, why not.

I would rather have TOTP on the solo than on an app because of portability (1 key can be used with many apps/devices) and also cause it is more likely you reset your phone and lose your TOTP vs resetting the security key. Hope it makes sense.

nickray commented 5 years ago

There are a bunch of issues with TOTP in the "obvious/direct" implementation

Given there will be need for "legacy" authentication methods such as passwords and TOTP seeds for.... the foreseeable future, which anyway need some companion management and browser extension/CLI tooling software, I'd currently favor a design along the lines of this:

In this way, Solo only needs to store one asymmetric key pair to unlock full password/TOTP functionality. Adding a new Solo as backup (or rolling over a keypair) is a batch operation that for each of the encrypted files adds decrypts the AES key and encrypts it against the new Solo (or other) backend.

Key properties:

I wouldn't hold my breath on this being implemented soon-ish unless a wonderful pull request comes in :) As it means developing, designing, maintaining a lot of middleware code, which we as SoloKeys-the-company don't have the resources for currently. I think it would be a great next step after our next hardware/firmware iteration. This could be an entire password/TOTP manager kind of side business, perhaps forking bitwarden-rs for the server....

A less nice (and much more insecure) design could be the following, it has the advantage of not needing any firmware changes and could be implemented by scripting around with solo-python:

returntrip commented 5 years ago

@nickray I understand the investment in creating and mantaiining code and infra around TOTP is non trivial and Solo cannot focus on that for the forseeable future. However, would it be possible for you guys to partner with a current (possibily FOSS) TOTP "provider" (AndOTP, FreeOTP, etc) and integrate Solo into their solution?

nickray commented 5 years ago

We are certainly open to such collaborations, yes. Will need someone to drive it.

returntrip commented 5 years ago

We are certainly open to such collaborations, yes. Will need someone to drive it.

I could spare some time but my knowledge in this field is limited. If you need a guy that can get people together, log issues and put together some documentation etc, I could try and help (with some technical hand holding).

nickray commented 5 years ago

Regarding the roadmap, out of nowhere, SSH is suddenly "done", thanks to @djmdjm's great work!

(It will of course take a while to land in Linux distributions)

sbrl commented 4 years ago

(a sneaky /cc @flocke?)

flocke commented 4 years ago

(a sneaky /cc @flocke?)

I would love to work on this to add support for Solo in andOTP. The problem is that I currently don't have a lot of time and I am starting a new job soon so I will have even less time in the future. But I will keep an eye on it and try to work on it at some point. If someone else wants to work on it I am always open for PRs ...

ncth commented 4 years ago

Are there plans to add an option to upgrade the bootloader on old keys to give them thinks like the downgrade protection? I think that would be quite important for the security of old keys.

sbrl commented 4 years ago

@ncth Use solo key update in the terminal to upgrade :D

(Note that you need to press and hold the button down for 2 seconds when first plugging in your sol to enter bootloader mode)

ncth commented 4 years ago

@sbrl

I think you misunderstood me. Using that method you described, you can upgrade the solo application on the key, which handles FIDO2 and U2F and probably openpgp in the future. I ment upgrading the solo bootloader, which handles updating and verifying the solo application and since version 3.0.0 also making sure that you can't downgrade your solo (on secure keys only). That bootloader is a critical security part that to my understanding right now isn't being updated at solo firmware upgrades. You can test that for yourself by booting solo into bootloader mode and than calling solo ls. That will show the version number of your bootloader, which will be older than your application (unless your device is brand new and hasn't seen firmware upgrades yet), because currently the bootloader is installed on the key when it is produced and than never touched again. That means that people with old keys don't get things like the bootloader downgrade protection.

Source: https://github.com/solokeys/solo/issues/221#issuecomment-516628541

sbrl commented 4 years ago

Oh, interesting @Zjemm! I thought that the bootloader was the same as the main firmware. Thanks for clearing that up!

So the solo is a bit like an Arduino, in that it has a bootloader and then the main program. Though with the AVR architecture you can skip the bootloader if you want and program it directly.

Kabbone commented 4 years ago

@ncth That doesn't seem to be true anymore. You can see the bootloader files at the release: https://github.com/solokeys/solo/releases

I even checked with my somu, which I recently updated: solo ls :: Solos xxxx: SoloKeys Solo 3.1.1

solo ls Not using FIDO2 interface. :: Solos xxxx: SoloKeys Solo Bootloader 3.1.1

conorpp commented 4 years ago

Bootloader and application are different, but if you update with the DFU process, it updates both bootloader and application. If you use the "normal" process (i.e. solo key update or web update), then this only updates the application.

Solo devices that have been locked (or "Solo Secure") cannot be updated via DFU process, and only allow signed application updates. So these devices cannot have their bootloader updated.

Regarding the recent version bypass in the Solo bootloader:

To disable firmware update process:

# Get latest version of solo-python (>= 0.0.24)
pip3 install solo-python --upgrade

# Get your last update.
solo key update

# Put your key in bootloader mode, then run:
solo key disable-updates
ncth commented 4 years ago

Ok thanks @conorpp for clearing that up :)

sbrl commented 4 years ago

How do I do this "DFU update" process?

conorpp commented 4 years ago

Relevant docs are here :).

https://docs.solokeys.io/solo/bootloader-mode/ https://docs.solokeys.io/solo/programming/

sbrl commented 4 years ago

So I enter DFU mode and then program it like this, @conorpp?

solo program aux enter-dfu
solo key update
yellowsquid commented 4 years ago

Is PKCS#11 still in the pipeline? I used to use my key with pam_u2f to login to my laptop. Since switching to using systemd-homed, either I'm back to typing a password, or using a pkcs token.

aozq commented 4 years ago

Simple static password is the most universal and therefore widely useful password function that really needs to be an option.. https://github.com/solokeys/solo/issues/348#issuecomment-651515798

Update: thank the good graces, there seems to be someone on it with a basic keyboard functionality in the hacker version! https://github.com/solokeys/solo/pull/446#issuecomment-644697425

DejayRezme commented 3 years ago

Re hardware password manager, is there a separate issue for this feature request?

Because I also would wish for that feature. I currently use a software password manager and looking to replace it, but I have more than 100 separate accounts stored in that and I would like them all to be on a hardware device. Most services in that list don't support these more advanced security features. The OnlyKey supports less than that. I also wouldn't want to use a separate software password manager.

Maybe this is too much to ask or the wrong use case for a small hardware token like this? E.g. I might need to write a given password that I can't change into the device. Or maybe I want to add additional info to it and want to be able to view it so maybe screen needed?

Will this be a feature for the V2?

My apologies if this is off topic.

michaelblyons commented 3 years ago

@DejayRezme I do not think this device has the storage for a generic password manager. You might be looking for something like Signet HC. (Disclaimer: I have not used one myself.)

If it's sufficient to have a software password manager that requires a hardware token to unlock, Solo may fulfill your needs. You can sync the password database over the network (syncthing, webdav, however) to devices that need it, but still use your hardware token to unlock it.