Have seen a few posts about using FIDO2 + Nitro/Only/Yubi keys etc..

They have been covered well, especially in the context of those suggested implementations..

There is one that I have not seen though..
It's more than likely was an idea/concept at some previous point and possibly unfeasible/unrealistic then..
Maybe not now?

Essentially, using an actual keyfile/pair for the encryption, having it stored on 'modern' day Smart Cards/CCID..
Which in this era, are effectively a much smaller, significantly cheaper HSM variant
(compared with the rack mounted type)

Also just want to outline early on;
Looking at a Yubikey for example;
This notion of open and closed source as a 'deciding factor' is a bit out of context..
Yubico do have proprietary parts to their products, however that is not the case for all implementations that are possible, nor is it entirely relevant given just because something is proprietary doesn't automagically mean it's anything that can increase attack surface..

Encryption itself has countless variables - including real world scenario's.. eg;
It's unrealistic for a HSM/Smart Card manufacturer to intentionally implement any 'weaknesses'.
Due to the very nature of their use and their clients - they also undergo a level of scrutiny and auditing where there are no publicly published records..

Conversely, Any potentially feasible attack at that level is not a scenario where it would risk potential exposure through sharing it with a private company specialising in forensics..

Also;
The hardware key and its pin/passphrase at that level ..
..yeah.. That will be the least of your concerns..

Anyway,
Was more interested in the general thought around implementing the option of using a keyfile/pair stored on a Smart Card / using CCID protocol..

There's API's more developed towards it these days and still been improved on, eg; dmcrypts implementation of accessing the private key on the higher end Yubi's - though CCID is a standard that's been around quite a while..

Yubi's have made it far more realistic/viable to use the Smart Card approach / aspect for disk and file encryption..

Essentially using an external key which is only required at boot, eg for first unlock.
(having usb enabled before first boot in that case, wouldnt be an issue in this context)

The very nature of modern day CCID, means PIN/pass on the hardware device itself is established with the API given it's mandatory (in any decent implementation)..

A way to also look at the methodology around the real world use;

How many people restart their phone while they are out and about?
Meaning, you don't even have to carry the key itself.
One of the backup keys could also be hidden somewhere with ease..
Even the primary..
Or, not at all..

Just carry it on your keyring -

The ability for even people with a background in forensics, to attribute a security token device, as also a smart card required to decrypt at rest data in the context of a cell/mobile phone itself - is virtually nonexistent.

It's also something that can't be easily detected or discovered until the phone is in BFU state, and even then..
(Even with a certain extent of AFU consented access also..)

Just because an API is built in and an implementation is possible - doesn't mean it is actively utilised..

Which is exactly the point..

Any country/place/people where it 'would'..

Also means;
It will simply be 'assumed' from the start..
And be the absolute least of your concern's, given you wont be treated in any 'civilised' manner in that scenario.. heh.

Apologies if that is a bit direct, it's just the real world/practical implications of encryption itself, seem to be often overlooked.

There is a lot more to this, was just throwing it out there as a basic concept for increasing data at rest (including other user accounts..)

Thanks :)