Solo: TOTP Support

[sbrl]

It's probably rather complicated, but I've noticed since obtaining my solo yesterday that not all websites support U2F / FIDO2. To this end, is it possible to use my Solo to do TOTP as an interim until these websites add support?

[Zjemm]

There is no official roadmap as far as I can tell.
But totp and static passwords would be nice
But I thing they are working on pgp/ssh keys first.

Maybe next?

[sbrl]

Ah, I see @Zjemm. I'd love SSH key support too - so many great features are made possible by open-source! :D

[0x0ece]

FYI, there's a discussion in #199 (I just added slides/presentation).

In this comment I sort of explained the complexities of OTP
https://github.com/solokeys/solo/issues/199#issuecomment-497048803

[sbrl]

Ah right @0x0ece. Looks like it's probably going to be a better idea to install an extension to Keepass & setup my Solo to lock my password database.

[My1]

TOTP would be awesome. I have an Idea how it could work but no experience at all in firmware writing etc. basically one would need 3 things:

1) a device that has a clock that can interact with solo that has a clock (generally a computer)
2) a way to interact with solo (like a commandline application would be a way)
3) a proper firmware for that which basically knows how to hmac-SHA1 and register/delete keys

Idea is basically as follows

1) a register command sends the Seed plus a name to use to the solo along with a "TOTP-Timestamp, generally floor(unixtime/30) which then stores the name and secret while outputting the current OTP which is used to confirm the key on the service.

2) a command to get the otp for any given name, along with the current TOTP-timestamp which basically does precisely what it says on the tin.

3) one could add authentication by presence (aka push the button to do stuff) to prevent malware from doing bad things

4) one could even add a rollback protection because time generally doesnt go backwards but then again the question is whether the past OTPs mean a lot and it has potential for a malicious entity to lock your otp generator by sending a very high timestamp)

5) depending on how much is possible one could even make a fun command to ex/import an encrypted list (the importing solo would create a keypair and output the pub key, the exporting solo would get a request to output the list encrypted with that key which, on a locked key could (if the firmware has readaccess to the bootloader) be signed with the update key, so exports can only be done by the one who can do anything critical on that solo anyway and the importing key would just take the list, decrypt it and store it.

I could probably write something up in PHP which would work similar to the fw as a mockup but I probably can't do it directly for solo

[vwbusguy]

As far as I understand, for YubiKey, only the TOTP secret is kept on the key and an app (yubico authenticator) takes that token and generates a code based on the clock of where the software is running. This means the hardware requirements are actually pretty simple.

As far as software goes, once the secret is retrieved from the key, you can generate a code with oathtool like oathtool --totop -b <TOTP secret> .

[My1]

I am pretty sure the app does not get the secret as that would be fairly bad from a security perspective as the point of a device like the yubi or solo is to have a key you can NOT copy. I THINK (I do know actually know) that is just pushes either the current time or the TOTP "counter" (unixtime divided by your OTP duration, rounded down) , e.g. I pulled up 1570210279 while writing this comment, on standard 30 sec OTPs the resulting TOTP counter would be 52340342, and basically if you just say "give me the TOTP for timestamp 52340342 on account 1" the device would have all to create the TOTP, spit it out and no one has got any secrets

[vwbusguy]

Of course the app gets the secret. It can't generate a code without it. Google authenticator and others store the secret directly in the app (and last pass auth, and authy). The difference is yubico auth reads it from the security key and can require tap.

[sbrl]

Rough short summary of the TOTP algorithm:

Registration

1. Server generates a new secret
2. Client obtains copy of secret
3. Client generates auth code and sends it to the server
4. Server verifies auth code

Auth code generation

1. Client: totp_code = hash(secret || round(unix_timestamp(), 30 seconds))
2. Client sends totp code to server
3. Server verifies totp code

[My1]

@sbrl actualls they use HMAC, but otherwise it is pretty accurate

[My1]

Of course the app gets the secret. It can't generate a code without it

well who said that the app does the code generation?

the yubikey as well as the solo are NOT your average USB sticks, but essentially small crypto-computers. how do you think the Yubikeys can run HOTP without ANY application at all?

in software based generators sure the app gets the token obviously, but the yubi is not software based but its own crypto device

same with U2F and whatnot, the Private keys dont leave the device, the device takes the inputs from the calculation, and gives back the result (except TOTP doesnt use private/public keys but a shared secret with an HMAC, basically like a symmetric signature).

to use a metaphor (but rather using private/public key analogies because they are easier to explain):

Let's say you have a very special typewriter (private key) which has some properties (public key)
which reflect on the documents it creates (signatures) but are essentially not possible to fake
due to being very specific (algorithm) unless you get hand of the typewriter itself and build a copy.

when you want to sign something you have to get obtain a document from your typewriter so the question is how you can have your typewriter lying around:

1) just lying around somewhere where anyone who gets close enough can take a look and make a copy (aka most software based solutions)
2) behind a locked door but you have to take it out, make your document and then well sux. (both encrypted software solutions as well as your "send secret to the app" thing)
3) you hire a super awesome, impossible to bribe security guard, rivet down the typewriter to that Locked room, include a interlock to make sure only that security guard can pass and the security guy only goes into the room writes you the document and exits with said document (provided you have convinced him [PIN, button press, whatever] to do this in the first place)

basically your yubi is a blackbox, time in, code out and the yubi keeps your secret.

or as a different metaphor, lets take a fast food restaurant, you order and give your money, you get food, no need to know the recipe or have any ingredients

[vwbusguy]

@My1 You seem to be conflating the YubiKey and Yubico Authenticator. The former is the hardware that stores the secret, the latter is what generates the code. The YubiKey passes the secret to Yubico Auth, which then computes the code. The secrets are not stored in the Yubico Auth data as a result.
YubiKey is incapable of generating the codes, actually, since they are time-based. It would need some kind of battery and ntp sync capability.

[My1]

self quote:

basically if you just say "give me the TOTP for timestamp 52340342 on account 1" the device would have all to create the TOTP, spit it out and no one has got any secrets

you dont need a battery if you tell the yubi the time at code generation

or do you have any source for saying that the yubico authenticator can actually pull the secret?
have you ever extracted a secret from one using the authenticator?

yubico even has a picture for that

[vwbusguy]

Cool. Most TOTP apps (Authy, LastPass Auth, Google Authenticator, etc.) store the actual secret in the app data itself. Authy goes a step further and can encrypt and store the secrets to synchronize across your Authy installations.

In any case, we would still need some kind of app integration for SoloKey to be able to differentiate between provider/account, but otherwise it would be a nice-to-have for SoloKey to be able to generate the TOTP codes, but I'm not sure it would be worth delaying this feature, given the current industry standards. Currently, TOTP storage is a certain advantage of YubiKey over Solo.

Also, you mentioned HOTP. HOTP is different than TOTP in that the latter has a time-based requirement that HOTP does not. HOTP is what you normally use when you get a text or email from a web service. TOTP tokens are only generally valid for 30 seconds, which means that even if the stick had a battery and it's own processor, if the time got out of sync with NTP, the codes generated would be invalid.

[sbrl]

I think if Solo did the TOTP generation, you could perhaps have a subcommand of the solo cli that passes the current time to the solo device itself.

[vwbusguy]

It would also be helpful to have a means of retrieving the codes by mobile app, especially since mobile apps are the most common method for TOTP. If we knew how to fetch it via nfc, it shouldn't be too hard to make one for Android.

[vwbusguy]

@sbrl Since the cli is python, would should be able to just use datetime.now() https://docs.python.org/3/library/datetime.html#datetime.datetime.now

[My1]

Cool. Most TOTP apps (Authy, LastPass Auth, Google Authenticator, etc.) store the actual secret in the app data itself

yeah but there you have no yubikey or anything. so of couraw the app must store the secret somewhere

Also, you mentioned HOTP. HOTP is different than TOTP in that the latter has a time-based requirement that HOTP does not

I know. HOTP is fundamentally the same algo except obviously that TOTP instead of the counter uses the unixtime divided by x seconds (usually 30)

HOTP is what you normally use when you get a text or email from a web service.

This is something I actually did not expect, I mean if the other side doesnt even have an OTP generator I would not go for using fun algos but rather just generate a fresh completely random code.

TOTP tokens are only generally valid for 30 seconds, which means that even if the stick had a battery and it's own processor, if the time got out of sync with NTP, the codes generated would be invalid.

which is why the app just tells the time to the yubi at the time of code generation, basically saying

"hey it's 2019-10-05 08:00:00 UTC, give me some codes" and the app just shows the codes the yubi throws out.

@sbrl I personally wouldnt actually use a second command, but rather just bring the time along with the code generation command.

[ptman]

Further from yubico documentation: "When using OATH with a YubiKey, the shared secrets are stored and processed in the YubiKey’s secure element" - https://developers.yubico.com/OATH/

"The OATH application can store up to 32 OATH credentials, either OATH-TOTP (time based) or OATH-HOTP (counter based)." - https://support.yubico.com/support/solutions/articles/15000014219-yubikey-5-series-technical-manual (there's limited storage available on the yubikey)

[riedel]

OATH TOTP is actually superseeded by FIDO2 hmac-secret (which is supported by the solo). I guess clarification is needed here: the original yubikey TOTP was emulating a keyboard. You would need a companion app for the clocksource if the browser supports no TOTP. If you need to have a companion anyway that could actually do the conversion to keyboard event, thus it wouldn't need to be in the firmware. The limiting factor seems to be that FIDO2 mandate the use of SHA-256 which "MAY" be used according to https://tools.ietf.org/html/rfc6238 (it depends on the use case if this is feasible, most websites want SHA1). The issue should be clarified i terms of specs.

[My1]

yubikey TOTP emulated the keyboard?

I highly doubt that. Yubi basic went HOTP (counter) because no battery and stuff, with the Yubico authenticator you have a piece of software which gives the yubi the time and then displays the TOTP.

a browser doesnt "support" totp, it's just a bunch of numbers.

[riedel]

Sorry, Yubico OTP generated keystrokes.

I just wanted to make clear, that what people want here is probably HMAC-SHA1. The rest (TOTP) would need to be implemented by a companion app (like an authenticator)

BTW: I reread the FIDO2 spec and it seem it seems that i was wrong and that the HMAC SHA-256 cannot be used a classical TOTP/HOTP since the key is generated on the device and never seems to leave it. You can only pass a timestamp a challenge, but that you never will be able to verify it on the server :(

However if one can implement HMAC-SHA1 based keys for e.g. keepassXC then this could store the TOTP secret at decent security risks. As I mentioned, the companion app is needed in any case...

[My1]

Sorry, Yubico OTP generated keystrokes.

well you werent that far off Yubi also supports HOTP (which is basically same as TOTP but counter instead of time) and only uses keyboard for that.

BTW: I reread the FIDO2 spec and it seem it seems that i was wrong and that the HMAC SHA-256 cannot be used a classical TOTP/HOTP since the key is generated on the device and never seems to leave it. You can only pass a timestamp a challenge, but that you never will be able to verify it on the server :(

and the secret is probably generated at random on the device I guess? (using "key" gets a bit ugly here for obvious reasons)
because if the secret can be passed into the device (e.g. by encrpyting with the public key (known to the server) the device could decrypt it using the private key it can pull out either from RK or the credential ID, and therefore challenge-response with HMAC would work, but that would require FIDO2 to work already, therefore beyond the point.

but solo could allow TOTP or whatever as a seperate thing from FIDO2, similar to the Yubikeys being able to do more than just Fido2.

[Beagon]

Is this still being considered? I remember that this was on the roadmap when I funded the project via Kickstarter. Not a lot of services have support for FIDO2 yet and I would like to use my SoloKeys for more than just some services/applications.

My workplace has been considering providing security keys to our clients as a thank you gift but if the key can only be used for FIDO2 compliant applications this would be of little use for our clients outside of our own application.

[nickray]

Not sure this was ever on a roadmap, what I know is I was long opposed to it out of principle ;)

That said, I recently had an idea how to pipe TOTP over FIDO2 (instead of using a separate/proprietary device app the way Yubico does). Will explore this in the ongoing Rust rewrite for v2 key; if it works (which mostly depends on how platforms implement CTAP in practice) - should be portable to current C code base for v1 key. In any case, this functionality also depends on some kind of companion client app (perhaps we can convince keys.pub) to pipe in the timestamp (and to be useful, browser plugins on multiple platforms).

The argument that FIDO2 is onlyy slowwwly gaining support is understood 😔

[Zjemm]

it really has some added value.
So it would be great if this gets on the roadmap

also static paswords, so i can have a password in my memory + the static password = the complete password. makes life a bit easier.

[sbrl]

also static paswords, so i can have a password in my memory + the static password = the complete password. makes life a bit easier.

That's probably a separate issue :-)

[cmueller-tp]

The argument that FIDO2 is onlyy slowwwly gaining support is understood pensive

I'd need HOTP for my coreboot->heads->tpm<->nitrokey setup and as far as I know HOTP/TOTP is the only way for this kind of tamper detection.
I think HOTP/TOTP will be a valid part of security systems for a long time to come - with different use cases than FIDO2 or PGP.

Is there any news regarding HOTP/TOTP support in solo keys?

[nickray]

Yeah, understood there are a lot of "legacy" use cases of OATH - a bit sad, but legitimate. Planning to implement for v2 key (both via CCID, "like Yubico", and as FIDO2 extension, "like bending the rules a bit"); the functionality/logic is pretty simple when the firmware framework around it is flexible. Regarding backport/implementing in v1 key, time will tell; most likely would be a community contribution.

[cmueller-tp]

Cook, thanks!
We'll probably buy the v2 anyways so at least for us it's perfectly fine this way.

[sbrl]

We'll probably buy the v2 anyways

Does the v2 use this firmware, or some new firmware elsewhere?

[cmueller-tp]

As far as I understand they're working on a second version of their keys (new hardware + new soft-/firmware).

[sbrl]

Ah, I see. So this firmware is unlikely to be updated without community support.

[vwbusguy]

@sbrl No idea. NitroKey supports TOTP and as I understand it, that was a fork on this firmware. It's possible that the NitroKey stuff could get backported here.

[My1]

@vwbusguy nitro key is not the same as nitrokey. Which one has totp. Pretty sure not the fido2 one

In addition solo v2 has an entirely new firmware compared to the v1 and totp is a stretch goal it's pretty well on track for.

[szszszsz]

@vwbusguy @My1 That's right - Nitrokey FIDO2 does not have the TOTP support at the moment (but Nitrokey Pro and Nitrokey Storage do).