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
#199 (comment)

[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 obviously doesnt have a clock itself (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