Re: fidocrypt(1): `storing' cgd keys on U2F/FIDO keys

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sat, 6 Aug 2022 18:47:47 -0400
> From: Gabriel Rosenkoetter <gr%eclipsed.net@localhost>
> 
> I mostly use macOS at home and Windows at work in that "desktop" context 
> these days, so I threw up my hands a few years ago and wrote my own 
> credential manager whose datastore is a USB mass storage device attached 
> to my keychain, and is largely a UI wrapper around a PGP-encrypted file 
> in a specific format. (I prefer USB devices that either have hardware 
> encryption or are formatted with an encrypted file system, but whatever.)

To be clear, fidocrypt(1) is not a general-purpose credential manager.
A fidocrypt file on disk stores a _single_ secret, which can be opened
by any one of the U2F/FIDO devices registered with the file.

That secret might be used to unlock a general-purpose credential
manager, or a cgd(4) volume (e.g., your USB mass storage device), so
that when they're locked you need the U2F/FIDO device (or some other
backup of the secret) to unlock them.

> But that's a bunch of home-rolled garbage, whereas I think what you're 
> proposing to add to base is an interface to a standards-compliant (and 
> somewhat-open) device specification. Right?

The _file format_ used by fidocrypt(1) is bespoke, based on sqlite3.

The _protocol_ fidocrypt(1) uses to talk to U2F/FIDO devices is
standard, and is the same as you can use with web browsers in webauthn
for securing things like Twitter and Gmail accounts against phishing.
The same U2F/FIDO device can be safely reused for both purposes.

> I guess my follow-up Devil's advocacy question would be: why does this 
> need to be in base, rather than provided via ports?

cgdconfig runs early at boot before most file systems are mounted --
often before the file systems on which any packages are installed are
mounted.  The cgdroot ramdisk, for instance, has a very minimal NetBSD
userland in a ramdisk just to configure cgd(4) volumes before mounting
the `real' root from them and chrooting into it.  fidocrypt could be
baked into this ramdisk.