Expand description

store presents a combined interface to three littlefs2 filesystems: internal flash, external flash, volatile/RAM.

It covers two usecases:

  • cryptographic key storage (for trussed itself)
  • somewhat namespaced key-value storage for client apps

The cryptographic keys are stored with a random filename (which is used as “handle” for the key).

The key-value storage has keys aka filenames choosable by the client.

The guiding example for client apps is fido-authenticator, which stores:

  • it basic state and config, and
  • the metadata for its resident keys as a serialized struct Both include references to cryptographic keys (via their handle)

Currently, the backend (internal/external/volatile) is determined via an enum parameter, which is translated to the corresponding generic type. I think it would be nice to “mount” the three in a unified filesystem, e.g. internal under /, external under /mnt (it’s not available when powered via NFC), volatile under /tmp.

If this is done, it would be great to abstract over the three backends, and just take some array with associated “mount points”. But KISS it ofc…

This store needs to enforce namespacing by apps, ensuring they can’t escape by loading some file ../../<other app>/keys/... or similar. This is orthogonal to the three backends split, I’m not quite sure yet how to expose this and how to map this to paths.

Here’s my current thinking:

/ |– data/ |– / |–dir.1/ +– file.1 +– file.2 |– dir.2 +– file.1 +– file.2 +– file.1 +– file.2 |– keys/

NOTE !!! ==> ideally can filter out CredentialProtectionPolicy in ReadDirFiles (via attribute)

(fido) : |– data/ <– the KeyValue portion : |– rk/ |– / + rk.1 + rk.2 : |– / + config +

Why? This:

  • typical use-case is one RK per RP (I’d assume!)
  • allows easy lookup in this case!
  • allows easy “count RKs” (possibly filtered) for GetAssertion
  • allows easy “count RPs” (for CredMgmt)
  • CON: this is already two directories deep (not just “one namespace’)
  • Alternative: subdirectory <==> RP hash, everything else in flat files
  • In any case need to “list dirs excluding . and ..” or similar

Modules

Structs

Traits

Functions

Reads contents from path in location of store.

Creates parent directory if necessary, then writes.

Writes contents to path in location of store.