A small database kept on a YubiKey, with no file on disk

[douzebis]

Following up on #13786.

The use case

@droidmonkey summarized it in #13786: "store a minimal subset of passwords that are needed in disconnected locations". Concretely:

• No file to lose or copy: the database exists only on the YubiKey, never in a laptop's backups, sync folders or disk images.
• Possession: opening it takes the YubiKey and the master password; changing it also takes the YubiKey's PIN.
• Portable, offline: any computer with a smart-card stack (PC/SC); no cloud, no network.
• In an organization: credentials handed to an employee (administration, break-glass) live on the employee's YubiKey.
• Fed from a main database: the subset could be a KeeShare export of a group of a larger database, kept on disk as usual, so that preparing it for air-gapped use is one step ("If you want partial databases then use keeshare", @droidmonkey in Partial backup #12146). The YubiKey then holds a copy of a subset, never the only copy.

It is not for a main database: a YubiKey 5 has about 50 KB of PIV data objects, so a database of about 20 KB is comfortable.

The concerns raised in #13786

• Size and atomic saves: the new copy is written beside the old one, which is removed only once the new copy is complete. A save that doesn't fit fails before writing anything, and a YubiKey pulled out mid-save keeps the previous version: nothing is truncated.
• Durability: I have no endurance figure from Yubico, so writes are kept to a minimum (see "Wear" below).
• Remote Sync: I tried it configured with yb commands. It works, but is not ideal for the use case: the air-gapped machine first needs a database of its own (an empty one, created by hand), which is cumbersome and leaves a file on disk. Its error messages also know nothing of the YubiKey (a wrong PIN, a touch it waits for). In practice, transferring the database directly with yb store and yb fetch is less fuss and more robust.

A proof of concept

KeePassYB is a fork of KeePassXC 2.8.0-beta1 built on [yb] https://github.com/douzebis/yb)'s C library, libyubiblob. It is named and installed apart from KeePassXC, so that it never passes for it.

• To try it (Linux): instructions, from a YubiKey 5 to a working build.
• Its design: the first comment below.

Questions

I'm not asking for a merge, but for your view:

1. Is a database that lives only on a hardware key in scope for KeePassXC?
2. If so, which path would you consider: an optional storage backend, like the proof of concept, or a narrow, generic storage interface, with the YubiKey code outside KeePassXC? Either would let KeeShare export to the YubiKey (not done yet in the proof of concept).
3. What would you need to see first: tests, endurance data, a smaller diff, someone committed to maintaining it?

Anyone with a similar need is welcome to comment too: how large your database is, what you would keep on the key. The fork goes on either way.

[douzebis]

The proof of concept's design: the problems we met, and how we solved them. Details in KEEPASSYB.md and yb's specs.

A vault on a YubiKey

• One entry point: a DeviceStorage class reads and writes a vault named by a location, yubikey:<serial>/<vault>.kdbx, wherever
  KeePassXC uses a file path. The bytes go between the YubiKey and memory, never to disk.
• The GUI: Open and Save As offer the YubiKey next to a file; the command line opens yubikey: locations too.

What protects a vault

• Stored in the clear, as it would be on disk: KDBX's own encryption protects it. Encrypting it again with the YubiKey would add nothing, and a locked YubiKey (blocked PIN) would then lock the user out.
• Writing needs the YubiKey's PIN, asked at the first save and kept until the vault is locked. Opening needs only the YubiKey and the master password.

YubiKey limitations

• Slow: a write takes a second, a post-quantum store asks for a touch, and reads add up. So a vault is read once when opened, YubiKey work runs off the GUI thread, and a dialog says what is going on, including when to touch.
• Wear: there is no endurance figure, so writes to the device are kept to a minimum. A burst of edits makes one write, and a change of presentation only (an expanded group, an entry moved) waits, as KeePassXC does for a file: it goes along with the next save, or is saved at lock, close or exit.
• Tiny: about 50 KB, with room needed for a second copy while saving. So the random padding KeePassXC adds against size side channels is left out unless the vault uses KeeShare (about 10% of a small vault), and a vault first saved to a YubiKey keeps no entry history by default.

Built on libyubiblob

libyubiblob, yb's C library, keeps small named files on a YubiKey 5, in its PIV data objects:

• Protected: writing needs the PIN, and every file is signed or sealed against tampering. Files can also be encrypted, to a key that never leaves the YubiKey (elliptic-curve) or, in a post-quantum store, with keys derived by its FIDO2 application (KeePassYB stores vaults unencrypted, see above).
• Safe writes: besides keeping the previous version, several programs using one YubiKey are serialized by the card's lock, and a write can be refused if someone else changed the file meanwhile (which KeePassYB turns into KeePassXC's merge question).
• Tested end to end: regression tests run the library against software emulations of the YubiKey's PIV and FIDO2 applications, in CI and a NixOS VM, so that each documented guarantee is checked on every change, without hardware.