Kleidos
EN ES
Menu

Roadmap

Three things, in this order: where each part of the project stands and what shows it, what is left and why it has to happen in the order shown, and what I decided against.

There are no dates on this page. I announce none, because a date is the first thing on a roadmap to stop being true, and because I work on this alone, which would make any date I gave you a guess in a nice font.

Where the project is

The whole of it, honestly: what works, what is being built, and what has not been started. Each row names what makes it true.

  1. Working

    One firmware, nine boards

    Every board registers its own hardware (its screen, its power controller, its buttons or keyboard) into the same firmware, and the drawings in “The devices” are generated from the same measured boards (src/boards/).

  2. Working

    The encrypted vault on the device

    Entries are stored as encrypted, authenticated records, with separate keys for encryption, authentication and the unlock check, and the host test suite covers the round trip and the refusals (src/vault/).

  3. Working

    Unlocking, on every kind of input

    The two-button boards take a PIN dialed on the timing arc, the boards with a keyboard take a passphrase, and the touch boards offer either (src/ui/entry/).

  4. Working

    Typing over Bluetooth

    The device becomes a Bluetooth keyboard for the session it is told to start, types over a bonded and authenticated link, and shuts the radio down again when the session ends (src/ble/).

  5. Working

    Firmware updates from the browser

    On the boards with room for two app partitions, firmware is uploaded from the admin panel; an image built for another board, or an older version, is refused, and an update that boots but never confirms itself rolls back on its own (src/platform/ota.cpp).

  6. Being built

    The admin panel

    In development. It is already where entries are added, imported from another manager and exported as an encrypted backup, and it is still changing (src/web/).

  7. Being built

    The hardened build

    In development. Secure Boot, flash encryption and encrypted settings are configured for the 8 MB boards; on the ESP32-S3 ones the per-chip key is burned by a step that exists now and that I have not run on a board yet (docs/security/secure-provisioning-checklist.md).

  8. Not started

    The power figures, measured at the cell

    The awake figures are read off each board's own power controller and published on the measurements page; every sleep figure is still an estimate. I have not made the bench measurements that would replace those estimates with readings from a meter (docs/testing/production-sleep-checklist.md).

  9. Not started

    The long end-to-end run

    The release criteria ask for 50 end-to-end cycles (boot, unlock, browse, type, sleep) with no crash. I have not run them, and I have ticked no other box on that list either (docs/QA_CHECKLIST.md).

  10. Not started

    The first release

    There is nothing to install yet: the firmware is at version 0.1.0, no release is published, and the Overview page says “Coming soon” because that is what it is (version.txt).

  11. Not started

    Flashing a board from the browser

    The page that would install the firmware over USB from a browser is written and parked: it has no release to offer, so this site publishes nothing at the page's address, and its own manifest lists no build (web/).

  12. Not started

    A review by somebody else

    I have not had the firmware or the cryptography reviewed by anybody outside the project. The dossier an auditor would start from is written and waiting (docs/security/audit-dossier.md).

I put no dates on this list. It names only work that exists in the repository, and a step that nothing there can show is listed as not started.

What comes next, and why in that order

There are eight steps left. The order is the part worth disagreeing with: each one names what cannot start until it is done.

  1. Step 1. Finish the admin panel

    The browser panel is how a vault gets filled. Of the nine boards, only three have a keyboard, so on the other six, typing a password into the device by hand is not a realistic way to add one. The panel works; it is not finished.

    Waiting on it

    Anything anybody would call a first release. There is no point shipping a vault that is hard to put anything into.

    src/web/

  2. Step 2. Make the hardened build able to create a vault

    The hardened build is the one with verified boot, encrypted flash, and the key derived from the PIN mixed with a secret only that device holds, which is what makes guessing a PIN offline pointless. On the classic ESP32 boards that secret is a random value in the encrypted settings; on the ESP32-S3 boards it is a key in the chip's fuses, burned from the computer in a separate step before the first hardened boot, and the upload refuses to go ahead without it. The step exists, but no board has been through it yet.

    Waiting on it

    Everything the security page says the hardened build does. Right now the strongest build is the one I cannot hand to anybody.

    docs/security/secure-provisioning-checklist.md

  3. Step 3. Open the repository

    It is private while I prepare the first release. A pass over the history has to come first, and so does deciding how an incoming contribution is licensed: that has to be settled before the first one is merged, not after.

    Waiting on it

    The security page, which asks you to believe twenty threats and forty-five controls you cannot read. And the review at the end of this list, because nobody audits what they cannot open.

    CONTRIBUTING.md

  4. Step 4. Measure the current at the cell

    Every sleep figure the project publishes is an estimate. The awake ones are real: they come off the board's own power controller, on its own battery. But the device cannot measure its own sleep in any useful time, so this needs a meter, a bench and an afternoon.

    Waiting on it

    A battery-life figure of any kind. Today the measurements page gives none and says why on every row.

    docs/testing/production-sleep-checklist.md

  5. Step 5. Run the fifty cycles

    Fifty unlock-and-type cycles end to end, on each board, without a crash. Parts of it are automated; I have never run the whole of it.

    Waiting on it

    The release. Firmware that has not been left running for a day is firmware whose first long day happens on somebody else's desk.

    docs/QA_CHECKLIST.md

  6. Step 6. Cut the first release

    A version, a tag, and one image per board. Nothing to download exists today, which is the first line of the limits list on the overview.

    Waiting on it

    The installer below, which has nothing to serve until this exists.

    version.txt

  7. Step 7. Publish the browser installer

    A page that flashes a board over USB from a browser, with no toolchain to install. It is written, and parked in the repository, pointed at a release that is not there.

    Waiting on it

    Somebody using this who is not me. That is the whole purpose of it.

    web/

  8. Step 8. Have somebody outside the project read it

    The threat model, the control matrix and the dependency register were written here, by the person who wrote the code they describe. That is worth something, and it is not a review.

    Waiting on it

    Nothing, and it is last on purpose: an audit of a moving target is an audit of nothing, so it waits until the steps above have stopped moving the target.

    docs/security/audit-dossier.md

None of this is a commitment about when. The list above is where a step changes state, and the feed publishes the change on the day I type it.

What I decided against

A list of everything somebody would like is not a plan: a plan is partly the shape of what it leaves out. These are nine things this project will not do, each with the reason written down where you could check it, and four of them settled by a measurement rather than by taste.

Any of these could be reopened by a better argument than the one that closed it. That is what the reasons are for.