How a house is protected
On a machine that core.blue runs, you trust core.blue. Whoever controls a machine and its
account at the data centre can read its disk, and for a house on a machine of ours that is
core.blue. We do not claim otherwise. What we do is keep that trust narrow, visible and in one
person's hands, and guard the house against everyone else. If you must exclude core.blue as
well, run the house on your own hardware: the size on-premise. Houses of your own on our
machines are not yet available; this topic describes how they are built. The gate, keys and
signed updates below were run on a test machine.
Who could read a house
| Who | Could read it? | Why |
|---|---|---|
| core.blue's owner | yes, and visibly | the general key below, or the account at the data centre |
| anyone else at core.blue, and our agents | no | no shell on a house, no key of a person; maintenance runs fixed commands that read no data |
| core.blue's public server | no | it reads two operations routes of a house and holds no key of a person |
| the data centre (Hetzner) | as for any machine there | a processor under contract |
| other customers | no | each house is its own machine; there is no shared database |
| anyone on the internet | only with a key you gave out | the gate in front of the house |
One gap we name: the account at the data centre is held by core.blue's operations today, not yet by a separate build service that would hold it alone (planned). Whoever broke into those operations could reach a house through that account.
The general key
One key opens root on every house: core.blue's general key. It lies in cold storage, offline and encrypted, with a passphrase, never on a machine where an agent works, and with a sealed copy for the case that its holder is gone. It is planned never to be used. If it is used, to repair a house that cannot be repaired otherwise, that is an administrative act with you: the owner of the house hears of it first, every login as root writes a line with the key's fingerprint into the house's log, which everyone in the house reads, and the owner gets a written account afterwards.
The same key signs the one way back into a house whose owner lost every key: an invitation that works only after a day, which everyone in the house sees and any remaining owner can withdraw.
How a house is guarded against everyone else
- Its own machine. One house, one VM; only the ports for SSH and HTTPS are open.
- A gate in front. Every request carries a key; the gate keeps keys only as hashes. Each key opens the doors it carries, and the owner's key opens the management door and nothing of the house. There are no passwords.
- The owner decides who comes in. Only the owner's key invites and gives keys to others; core.blue makes one first invitation when the house is built, or none if the buyer brings a public key.
- No shell for core.blue. SSH takes keys only, root only with the general key. The maintenance account runs a fixed list of commands: install a signed update, restart, read health, hand over a signed recovery.
- Signed updates. Every bundle a house runs is signed with core.blue's release key, kept offline like the general key. A house refuses an unsigned bundle, one signed by another key, and an older version; a bundle that does not come up healthy is rolled back, and every update is logged.
- Least privilege inside. The house, the gate and the web server run as their own users, none as root.
- Backups. Daily on the machine, each one restore-tested; the owner downloads a full export of the house.
What core.blue's server sees
Of a house: its name, version and size, which model is plugged in, the way back its owner named, and how many keys there are. Never content. With core.blue's model delivery (planned), prompts pass through our gateway; we neither store nor read them. Plug in a provider of your own to avoid that.
What is not protected
Nothing in a house is encrypted at rest. A key you hand to an agent is as safe as that agent; retract it when you are done. The sandbox runs on core.blue's own server and is none of the above.
Go deeper
- Your data stays yours: the eight questions, answered in order
- Connecting to your house: keys, doors and the first sign-in
- Plugging in a model: where prompts go
- The sandbox: the one house that is not on a machine of its own
- What does not exist yet