Arch Linux Installer Preparing FIDO2 Support For Handling Disk Encryption

[akuhtr]

Yubikeys are really cool (Linux friendly FIDO support, Smartcard support, HSM replacement, etc)... ...but I'm not sure if I trust myself to not lose it for my own systems. At the office, I'd just ask for a replacement. At home, it'd be a definite "@£$% how do I get back in now?" moment.

Don't know about Yubikeys, but some bitcoin HW wallet have support of FIDO2 (Trezor for example), so you can use that instead of Yubikey. In that case your backup si 12 or 24 words (seed) which you can write and hide. When you lost/destroy first Trezor, you can enter seed into new trezor and make new copy (or another hw wallet if they use same derivation path).
12 word for seed are enought , dictionary has 2048 words so 2048^12 combination...

[elatllat]

How many buttons need pushing to get ones ideal setup from Archinstall vs EndeavourOS, etc...

[anarki2]

Linux needs to COMPLETELY rethink encryption. FDE must be transparent and flexible. It's unacceptable that enabling FDE requires reformatting a drive, and usually involves a memorized single password. Pathetic and ridiculous.

[evert_mouw]

The arch community is something.. From No installer to one of the best installers in just over a year, all of this on a rolling base. Don't let debian know this.

"No installer" was a feature. I still don't trust this development. Soon, energy will be lost to people who don't RTFM.

[caligula]

The arch community is something.. From No installer to one of the best installers in just over a year, all of this on a rolling base. Don't let debian know this.

But they haven't snapified apps yet.

[pWe00Iri3e7Z9lHOX2Qx]

My last Arch install was before this was a thing. I've seen mentions of btrfs support. Is there also an option for something like a snapper setup with automatic snapshots created from pacman runs? Guess I need to go play in a VM...

[Torxed]

My last Arch install was before this was a thing. I've seen mentions of btrfs support. Is there also an option for something like a snapper setup with automatic snapshots created from pacman runs? Guess I need to go play in a VM...

Yepp timeshift works out of the gate. The different snapshot tools expect diffferent layouts and we haven't narrowed down them all yet.

[Torxed]

Linux needs to COMPLETELY rethink encryption. FDE must be transparent and flexible. It's unacceptable that enabling FDE requires reformatting a drive, and usually involves a memorized single password. Pathetic and ridiculous.

I agree that one of the most convoluted wiki structure are the disk encryption jungle.
Which is one of the major reason archinstall aim is to simplify it without sacrificing integrity. FIDO2 support was one such step, to make things easier and improve overall security.
We could have gone for TPM support too rather easily, but it would be less secure in terms of physical security over the FIDO2 route.
Passwords is easy to support because there literally the oldest standard for user credentials (kind of), whereas different hardware specs is harder to streamline, this is how I justified the existance of password protected anything ^^

[Slithery]

Thanks Torxed.

I can't wait until the next time I have a new machine, until then I have no need for the installer as my current Arch has been rock-solid for over a decade now and was done using the previous installer...

[polarathene]

One concern that came to mind while implementing this.
Was how quick the disk unlocks with a FIDO2-device.
I get that there's more trust here, but using something like a PCI/USB emulation tool to brute force, would this be possible?
I hope there's a mechanism that kicks in to prevent this

Even if there isn't, as long as the key/input required to unlock is of high entropy (which would be expected with a security device), it should be fine.

IIRC 128 bits of entropy would require enough energy to iterate through all possible values (roughly 340,000,000,000,000,000,000,000,000,000,000,000,00 0) to boil all of the oceans in the world (which is still the case for typical success rate at 50% of the keyspace, thus 2^127). My math might be off, but 2^127 would still take over 5 trillion years at a billion billion (1e9^2) attempts per second. Ultimately though, it's going to be cheaper/faster to just gain access via other means at that point.

Which is sort of the point of using hardware for securing access, rather than remembering our own passwords which tend to be more prone to lower entropy. I don't know much about FIDO2 specifically, but that's only relevant for unlocking/deriving the actual key used to encrypt/decrypt right? Which should be a random 128-bit (or greater) key.

So whatever has lower entropy to attack (the actual/master key, or the key(s) protecting the actual/master key - I'm not an expert, so apologies for lack of correct terminology :P ), will be where the security strength is.

If the concern was with user password protection enumeration with paired FIDO2-device already in possession, then key stretching (or key derivation function, such as PBKDF, scrypt, argon2id) is presumably in use to deter brute-force attempts on that. You've probably configured that in the feature implementation, or it's handled with some sane default involved. That will slow down brute-force attempts considerably, and is part of how traditional password-based auth for user accounts is managed. This step increases effectively pads/increases the entropy of an input (but not beyond the output entropy), which is quite useful for non-machine generated passwords.