[Idea] Using U2F dongle as 2nd factor authentication for LUKS based containers #155

Would it not be better to implement the yubikey since they have an open API? That would be a much more universal solution for one time passwords and we would not a) have to rely on google, and b) not have to use chrome. Also, as an added bonus yubikey supports PAM so you can use it for OTPs for logging on your system as well. https://www.yubico.com/products/yubikey-hardware/yubikey-2/

(I already use my yubikey for tomb by using the second slot for a static 64 bit string that I combine with a passphrase to get something I know + something I have. And yes, I have a second yubikey with a copy of the string in slot 2 squirreled away just in case it dies. Though OTPs would be even nicer.)

Would it not be better to implement the yubikey since they have an open API? That would be a much more universal solution for one time passwords and we would not a) have to rely on google, and b) not have to use chrome.

Yubikey isn't an open API, it's a proprietary one that a single company runs. U2F doesn't rely on Google. It doesn't even require use of any central, hosted service by any vendor. Unlike Yubikey, FIDO U2F actually is an open standard. Support is also not going to be limited to Chrome; Microsoft has committed to support U2F in Internet Explorer.

This is all aside from how multiple vendors sell U2F hardware for 10ドル-20, which makes it among the cheapest secure hardware tokens.

Yubikey most certainly is an open API. You can use their own libraries published under BSD, third party libraries or even write your own for that matter. And no, you don't require the use of a central hosted server. You can run your own, based on the above mentioned libraries, use third party validation server, or based on their own BSD licensed validation server software. Or even do everything completely offline, without the need for a network or a browser (Can FIDO U2F do that? Why would I want to have to use a browser for OTP with a command-line tool?). And both the transport protocol, the OTP protocoll and the algorithms are fully documented on their developer site.
See these pages for example:
https://www.yubico.com/develop/open-source-software/low-level-library/
https://developers.yubico.com/yubikey-val/

Yubikey most certainly is an open API.

FOSS-licensed clients do not make something an open API. Amazon AWS has plenty of FOSS clients but is definitely proprietary. The service YubiKey provides for the keys -- configured as they ship -- is not open. It is just no-cost.

And no, you don't require the use of a central hosted server. You can run your own, based on the above mentioned libraries, use third party validation server, or based on their own BSD licensed validation server software.

These options are available only if you don't use the YubiKeys as shipped. You have to initialize them in a custom way, generally one-by-one unless you negotiate otherwise with Yubico. Even then, your only vendor can be Yubico. Multiple vendors make FIDO U2F-compatible tokens.

Can FIDO U2F do that?

Yes. FIDO U2F doesn't require any special server or network connection at all. It's based on registering the token's public key, not keeping something secret on both the key and the authentication server. The token can then sign data that is validated using the public key.

Why would I want to have to use a browser for OTP with a command-line tool?

You don't. U2F is an open standard with multiple library implementations. It should work fine from CLI applications.

FOSS-licensed clients do not make something an open API. Amazon AWS has plenty of FOSS clients but is definitely proprietary. The service YubiKey provides for the keys -- configured as they ship -- is not open. It is just no-cost.

I wasn't talking about the clients talking to yubikeys cloud servers here, but the server/offline implementation, since the previous is of no interest for this case (in my opinion). Basically what you are saying here is really doesn't make any difference since a) there actually isn't a definition of an open API, and that yubikey is well within the most commonly used definitions of an open API, including for example the p2p foundation. Also note that very few definitions go as far as defining an open API in the same terms as open data. I really would have liked to find the FSFs take on this, but I didn't find anything. Anyhow, this is completely moote, since it's all down to what you or I personally want, and only by following a FSF-isc definition would one consider this service not to be an open API.

Even then, your only vendor can be Yubico. Multiple vendors make FIDO U2F-compatible tokens.
This I agree can be seen as an issue. On the otherhand I'm skeptical of all of the random absurdly cheap devices I'm seeing here there and everywhere.

You don't. U2F is an open standard with multiple library implementations. It should work fine from CLI applications.

This is cool. When I saw the first press releases I looked into FIDO U2F and was under the impression that the only available implementation was in chrome. This has obviously changed, or I was mistaken, so I guess I'll get that combined yubikey+FIDO U2F device after all.

Yes. FIDO U2F doesn't require any special server or network connection at all. It's based on registering the token's public key, not keeping something secret on both the key and the authentication server. The token can then sign data that is validated using the public key.

You seem to know a lot about this. How is the key actually stored (I find it strange that you can use things as voice commands instead of a dongle and I can't quite see how a voice command or fingerprint can replace a private key stored on a dongle. Perhaps I'm missing something here?

Finally I'm not quite sure that this needs to be a one or the other kind of thing. Looking at the available libraries, I think implementing one will lead to a very short road to implementing the other as well, which of course is the absolute best sollution (we all want freedom of choice here I'm guessing?)

No matter how open, closed or hilarious those things are, I don't see them being supported in Tomb anytime soon (if ever). They'd add extra dependencies to tomb, while providing no real security gains.

If you want to have two factor "authentication" (there is no authentication in tomb, you open the lock with a key, no matter who you are) you just have to split the key file and store the halves separately.

I don't see them being supported in Tomb anytime soon (if ever). They'd add extra dependencies to tomb, while providing no real security gains.

Not necessarily. Something like this would have to be added by creating an external application for it. One would have to be insane to try to implement something like this in bash, hence one could simply check if the external application is available, and if so offer two factor «auth».

On the other hand, that probably means it would be better to mirror the functionality of tomb in the external application and make it standalone. So yeah, I can see this never happening.

If you want to have two factor "authentication" (there is no authentication in tomb, you open the lock with a key, no matter who you are) you just have to split the key file and store the halves separately.

Or as I do split the pass phrase. I currently use a manually typed passphrase in combination with a 64 byte string stored in slot 2 of a yubikey.

I don't see them being supported in Tomb anytime soon (if ever). They'd add extra dependencies to tomb, while providing no real security gains.

[...] one could simply check if the external application is available, and if so offer two factor «auth».

Well, yeah, it could be an optional dependency.

Or as I do split the pass phrase.

Bear in mind that the pass phrase doesn't protect the tomb itself, but the key file. It's like chaining a key to your pants so that nobody can pick it from your pocket; they can still use a bump-key on the lock.

Bear in mind that the pass phrase doesn't protect the tomb itself, but the key file. It's like chaining a key to your pants so that nobody can pick it from your pocket; they can still use a bump-key on the lock.

Indeed. But in my daily life I'm fairly sure that the highest risk is losing control of the keys.

Thanks for this interesting debate! its well informative.

Some of us at dyne.org have passion for yubikeys https://www.dyne.org/software/yubiswitch/ but I'm not really one of them :^P My thoughts on the matter:

The idea of having keys separated from tombs is already a sort DIY yubikey/U2F setup customizable with simple scripts to retrieve the key from usb keys or phones (over bt) or remote hosts (over ssh).
Of course yuby/U2F schemes do that for passwords, which is an extra layer of decentralization...

To implement them in Tomb would certainly mean to make an application in extras/ which can be compiled and deployed by users if they want. Tomb will always stay as a minimum viable product (MVP) with a set of extras users are free to choose, this is actually part of its security model.

I'm not sure if I or anyone else will find the tools and time to implement such an extra, but rest assured I will include it as soon as its there and it has been tested, as I have nothing really against the freedom to choose from many options as long as the MVP rest untouched without any more dependencies.

just a quick level-set yubico is a founding (i believe) member of fido, and one of the key contributors to the u2f spec. the yubikey neo was one of the first u2f devices. so if you like yubikey, use a neo with u2f

Time passed... anyone has a working setup with u2f, perhaps yubikey based? Folks at yubikey donated some neo models to make this possible, I can test anything already existing, or will hack on a solution soonish.

It looks like U2F can't be used for encryption: https://crypto.stackexchange.com/questions/44717/can-an-u2f-public-private-key-pair-for-signatures-be-used-for-encryption

If U2F uses ECDSA keys there is no way to do encryption with it.

However, since Tomb 2.4, you don't need to use a U2F protocol to have a two factor authentication system. You only need to use Tomb with a GPG key in a smart card (including Yubikey like card).

Wow in some months this discussion will become 10yrs old <3

PS. I'm here cause I just searched online "tomb, dyne, yubico, yubikey"