roadmap

[Zjemm]

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]

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

[conorpp]

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]

Nice, and what about otp? And static passwords?

[0x0ece]

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]

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]

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

[Zjemm]

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

Solokeys could expand 😄

[deepsweet]

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]

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]

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]

@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):

• Cryptoki 3.0 just recently reached public review & comment stage: https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/csprd01/pkcs11-curr-v3.0-csprd01.html
• SoftHSM does indeed implement Ed25519, I added support to RFC 8410 (Ed25519 and friends) pyauth/python-pkcs11#50

[hardfalcon]

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

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

[0x0ece]

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]

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]

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

• there needs to be a companion "app" that injects time
• each site has its own TOTP seed, storing and managing these on-device is a non-trivial API (similar to RK handling)
• "less likely to lose/break/reset/... key" is not a good strategy, so this "direct" implementation of storing TOTP seeds on device needs additional backup management, meaning exposing seeds to malicious extraction

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:

• passwords and TOTP seeds are stored, individually encrypted, on users disk; can be backed up on Dropbox or whatever the FLOSS solution de jour is ;) Basically what passwordstore.org does, using GPG as backend
• encryption meaning encryption against multiple public keys, basically tuple (file encrypted with AES, pubkey1, AES key encrypted against pubkey1, pubkey2, ... pubkeyN, AES key encrypted against pubkeyN)
• the CLI tool or browser extension or mobile app ("client') receives "TOTP pubkey" from Solo, sends corresponding triple (encrypted password/TOTP seed, timestamp, appropriate encrypted AES key) to Solo, Solo decrypts password or generates TOTP code by first decrypting the AES key, then decrypting the file; returns output to client, which then uses it

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:

• TOTP seed never on host
• passwords only on host on demand
• clean backup solution, with disposable individual "unlockers"

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:

• generate yourself a key with the hmac-secret trick https://github.com/solokeys/solo-python/#challenge-response (and a backup on a different Solo, and a paper key,... enough backups ^^)
• store passwords/TOTP seeds as above
• using a password or TOTP proceeds by getting the key from Solo, decrypting on the client, and proceeding from there.
  This does mean that all the secrets are in host RAM, at least temporarily, which is why it's less nice :)

[returntrip]

@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]

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

[returntrip]

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]

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

• announcement/instructions: https://marc.info/?l=openssh-unix-dev&m=157259802529972&w=2
• proof-of-concept: https://asciinema.org/a/278411
• retweet: https://twitter.com/SoloKeysSec/status/1190257586664288256 🤗

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

[sbrl]

(a sneaky /cc @flocke?)

[flocke]

(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]

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]

@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]

@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: #221 (comment)

[sbrl]

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]

@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]

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:

• This version check in the bootloader is a recent change, and not all Solo devices have them anyways. All devices made in recent months certainly do (and now any new devices have the version bypass fix as well).
• If you have an older Solo "secure" with older bootloader, and have concern with it being downgraded, you can disable the firmware update process (note this is permanent).

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]

Ok thanks @conorpp for clearing that up :)

[sbrl]

How do I do this "DFU update" process?

[conorpp]

Relevant docs are here :).

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

[sbrl]

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

solo program aux enter-dfu
solo key update

[yellowsquid]

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]

Simple static password is the most universal and therefore widely useful password function that really needs to be an option..
#348 (comment)

Update: thank the good graces, there seems to be someone on it with a basic keyboard functionality in the hacker version! #446 (comment)

[DejayRezme]

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]

@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.