Praecise Furcate
Menu

Security

Hardware-rooted, from the sensor up

Trust that starts in the silicon.

Every machine in a Furcate site, from a rack server to a Furcate leaf, names itself with a key its own hardware produced and holds. Authority is a key the operator holds. The system grades what each machine can prove, refuses what it cannot, and keeps the record either way. All of it is open source, because a claim nobody can read is not a claim.

Talk to PraeciseRead the code
Identity
a public key produced by the machine and sealed to it
Roots
TPM 2.0 · firmware TPM · TEE · secure element · leaf hardware keys
Authority
the operator's signing key, never a token
Code
Apache-2.0 for every trust claim

The story

Security that does not ask anyone to take a claim on trust.

Most systems describe their security in a document and ask to be believed. Furcate's position is that a claim nobody can read is not a claim, so every component that makes one, from identity and attestation to the ledger and the kill switch, is open source and enforced by the build.

The second position is that a machine should only claim what its hardware can prove. A server with a TPM can quote its boot state. A board with firmware-held keys can sign but not quote. A Furcate leaf can sign with a key it can never read. A Modbus meter can prove nothing at all. Furcate grades each of them for what it is and lets policy, placement and evidence depend on the grade, rather than flattening them into one notion of trusted.

The third is that authority belongs to the operator. Halting, cutting power, isolating and erasing are signed orders from the operator's own key, honoured by nodes and leaves with no network present, and reachable by no vendor, including Praecise.

01

Identity from the machine(6)

No registry issued it. None can revoke it.

A machine's name is a key it made and cannot give away.

Furcate asks each machine's own root of trust for its identity rather than issuing one. A server's TPM, an embedded module's firmware TPM, a board's firmware-held keys and a Furcate Node's hardware key all produce a key that never leaves the hardware. Nothing is generated at random in software, and nothing is written to a file that could be copied to another machine.

ClassHeld inCan quote its boot stateTypical machine
TpmTPM 2.0, discrete or firmwareyesservers, embedded modules with fused secure boot
Dicelayered derivation from a hardware secretyesboards that bind their key to measured firmware
Teetrusted execution environmentnoembedded modules without fused secure boot
SecureElementdedicated secure elementnoboards with an attached element
Devicehardware-held key, signed bootnoFurcate leaf nodes, boards with firmware-held keys
Softreadable characteristics onlynocontinuity, never custody

Honest by construction

A class is a property of the hardware, not a setting. A machine that cannot hold a key unreadably is never admitted to custody of sealed data, never asked for a quote, and never placed where attestation is required.

02

Measured boot and attestation

Never claims a property the hardware does not support.

A node says what booted, and the verifier checks it.

Nodes with a TPM extend each boot stage into measurement registers and quote them on request. The verifier is open source and grades each machine unmanaged, pinned, imaged or measured, with each level naming its own next step. Placement, custody and evidence exports can require a level.

Updates as images

An update replaces a signed image and never edits a machine. Identity, sealed keys and configuration live outside anything an update carries, and the previous image is kept.

Leaves boot only what is signed

A locked leaf runs only firmware the operator's release keys signed, and reports its assurance class as it is, so a board that cannot prove as much is graded for what it can.

03

Custody and the kill switch

Four things nothing may do.

Nothing outside the building can stop a machine inside it.

Halting, cutting power, isolating and erasing keys require the operator's own signing key. No network, no vendor and no code path reaches it. The operator key lives as hardware-sealed ciphertext on a node that is not the site controller, and leaves honour the same signed orders with no network at all.

  1. 01

    Sealed custody

    Keys, proofs and data encrypted to the local root of trust, so a disk pulled out of a machine is inert.

  2. 02

    Signed orders

    halt, power_off, isolate and crypto_erase, each signed and counted, each refusable by nothing.

  3. 03

    Breakglass with accountability

    Emergency access that works when the control plane does not, recorded so it can be checked afterwards.

  4. 04

    Session records

    What somebody did while they held authority, chained so it cannot be edited later.

04

Transport and segments

Signed envelopes between machines, isolation for devices.

Every message between Furcate machines is signed; every device is behind its node.

Nodes talk over an operator-owned overlay with signed envelopes, short-lived credentials and replay defence; a peer joins on a signature from a key held off the coordinator. Devices sit on segments only their node or leaf can reach, so a protocol with no authentication still has a gatekeeper.

Policy as a file

Deny by default, deny beats allow regardless of order, and delegation that cannot outlive its parent. Policy is data the operator holds, not a service someone else runs.

The ledger

Every decision is chained, whether permitted or refused, so what a machine declined is as auditable as what it did.

05

Devices without identities

Most of the installed world.

Trust is graded, never assumed.

A Modbus meter or a plain RTSP camera has no key at all. Furcate does not pretend otherwise: readings state whether the device signed them, a Furcate leaf signed them at capture, an attested bridge vouched for the channel, or a node only heard them on the wire.

How the ladder worksCompliance evidence

06

One way in

Nothing calls a device. Devices call out.

A device that listens for nothing cannot be reached by anything.

Furcate leaves open no port and run no service. A leaf dials out, only to parents the operator has authorised, and only after the parent proves both who it is and that the operator allowed it. Every message travels inside that channel and is checked against the grant, and every change to the leaf is signed on its own, so a compromised parent can pass a change along but never forge one.

  1. 01

    Operator-authorised

    A grant names the parent, the devices and what it may do: read, command, load a model, configure, update. The operator signs it with a passkey, and the leaf checks it against a set of operator keys pinned at enrolment, so one lost passkey locks nothing.

  2. 02

    No shared secret

    The leaf pins the operator's public keys and holds its own private key. Nothing secret is shared, so there is nothing to copy.

  3. 03

    Revocable without a clock

    Grants are counted in generations, not hours, so revoking a parent works on a leaf that has never known the time.

  4. 04

    Physical access, the last resort

    With a locked leaf in hand, an attacker can break it. Reading its key or turning it to other work is not on the list.