tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
fidocrypt(1): `storing' cgd keys on U2F/FIDO keys
[bcc tech-crypto@ tech-security@, followups to tech-userlevel@]
I would like to import the fidocrypt(1) utility into base:
https://github.com/riastradh/fidocrypt/
fidocrypt(1) is a small program that lets you `store' a secret on
U2F/FIDO keys, with a little state on disk that enables you to
register or unregister keys without changing the secret, so that any
one of the registered keys can be used to open the secret. Example:
$ export FIDOCRYPT_RPID=fidocrypt.example.com
$ fidocrypt enroll -N Falken -u falken -n yubi5nano example.crypt
tap key to enroll; waiting...
tap key again to verify; waiting...
$ fidocrypt enroll -N Falken -u falken -n redsolokey example.crypt
tap a key that's already enrolled; waiting...
tap key to enroll; waiting...
tap key again to verify; waiting...
$ fidocrypt list example.crypt
2 redsolokey
1 yubi5nano
$ fidocrypt get -F base64 example.crypt
tap key; waiting...
yTpyXp1Hk3F48Wx3Mp7B2gNOChPyPW0VOH3C7l5AM9A=
The secret might be, for instance, a cgd(4) disk encryption key --
fidocrypt(1) can be used in a shell_cmd keygen block of a cgdconfig(8)
parameters file. For this to work, fidocrypt(1) has to be available
early at boot time before any file systems on cgd(4) volumes have been
mounted -- this is why I suggest putting it in base and not just, say,
in pkgsrc.
The fidocrypt(1) program and associated libfidocrypt.so library are
reasonably small, a couple hundred kilobytes on amd64, although having
/bin/fidocrypt would require us to move libfido2.so and libsqlite3.so
into /lib, adding a megabyte or two in total to / (not counting
/rescue where it might also be worthwhile to add fidocrypt):
text data bss dec hex filename
52160 2042 1864 56066 db02 fidocrypt
69332 1544 0 70876 114dc libfidocrypt.so
144480 2048 32 146560 23c80 libfido2.so
1136213 22504 1368 1160085 11b395 libsqlite3.so
(Of course, sqlite3 in /lib might be useful for other purposes too!)
Thoughts?
(The `-N Falken -u falken' names, and the FIDOCRYPT_RPID relying party
id, are required by the FIDO protocol, but have no significance to
fidocrypt(1) itself -- other than that the relying party id can't be
changed without creating a new fidocrypt file to encapsulate the same
secret. The `-n yubi5nano' just gives a nickname to each registered
key in case you want to revoke it later.)
Home |
Main Index |
Thread Index |
Old Index