Trust and Security Model

This chapter separates the guarantees that follow from the protocol — which hold today and can be checked — from those that depend on how an engine is placed on hardware.

The two mechanisms

Almost everything below rests on one of two mechanisms, and they protect against different things.

Mechanism	Protects	Against
Byzantine fault-tolerant replication	Integrity — data cannot be altered, results cannot be faked	An adversary controlling up to f of 3f + 1 nodes
Memory encryption (SEV-SNP)	Confidentiality — data cannot be read	The operator of the machine the workload runs on

Replication is in production and is a property of the protocol. Memory encryption is in production on engines that occupy a whole node, and is not yet available where several engines share one. Which case an engine falls into decides whether its node’s operator can read its state.

Integrity and verifiability

Every response from an engine is threshold-signed: the nodes jointly produce a single signature that a client verifies against one public key. No individual node holds the signing key, and a client does not have to trust the node it happened to talk to.

A response that does not verify is discarded by the client, so a compromised node cannot serve a false result to a caller that performs the check. This holds while no more than f nodes are compromised; see Past the limit.

The guarantee holds only where the client performs the check. Client libraries do this by default; a hand-rolled HTTP integration that ignores the signature gives it up. See Integration Patterns.

Confidentiality

AMD SEV-SNP encrypts a virtual machine’s memory so that the hypervisor and the machine’s operator cannot read it, produces a measurement of how the VM was launched, and can issue an attestation report proving to a remote party what is running inside. A node runs its engine as a guest VM, so this is the mechanism that determines whether a node provider can read the state of the canisters they host.

Whether an engine has it depends on how many engines share the node:

Engine placement	Memory encryption	Node provider can read engine state
Alone on the node	Enabled	No
Sharing a node with other engines	Work in progress	Yes

An engine alone on its node runs with memory encryption today. Its memory is unreadable to the host, and so to the machine’s operator, and the guest is launched under a measurement that can be attested.

Several engines on one node do not. SEV support for that configuration is being implemented at the DFINITY Foundation, so the date is not Swiss Subnet’s to give.

A node provider operating a shared node can read the state of the canisters running on it. Integrity is protected — they cannot alter state or forge results — but on a shared node confidentiality against the machine’s operator is not enforced by hardware.

Where hardware does not enforce it, the contractual and jurisdictional layer stands in its place: node providers are identified, vetted, contractually bound under Swiss law, and subject to the data protection obligations described in Data Storage and Locations.

A client who requires memory encryption today should specify an engine that occupies whole nodes. Engines sharing a node will be migrated once SEV support for that configuration lands; it is not restricted to newly created engines, so an engine deployed today does not have to be rebuilt to gain it.

Threat model

Adversary	Assumed capability	Covered
Network attacker	Observes and modifies traffic between client and engine	Yes — responses are threshold-signed and verified client-side
Single malicious node operator, integrity	Root on their own machine	Yes — cannot alter state or forge results while f ≥ 1
Single malicious node operator, confidentiality	Root on their own machine	Yes on a dedicated node; no on a shared node — see above
f colluding operators	Control of f of 3f + 1 machines	Integrity holds; availability holds
More than f colluding operators	Control of more than f of 3f + 1 machines	No — see Past the limit
Swiss Subnet AG as coordinator	Selects node providers; can request node redeployment	Integrity holds — redeployment installs a vetted GuestOS
Data centre or hosting provider	Physical access, hardware substitution	Integrity holds while f ≥ 1; confidentiality as the row above
Legal compulsion against an operator	Court order in Switzerland	Legal assessment, out of scope — see Scope

The coordinator role

Swiss Subnet AG assembles the engine and can, under the Node Provider Agreement, request that a node be redeployed within 24 hours.

Redeployment means the node provider reinstalls the node from an elected GuestOS image — the same image every node runs — on hardware the provider operates. It gives Swiss Subnet no path to read engine state, alter it, or install different software.

Which images are eligible is not Swiss Subnet’s choice. A GuestOS version becomes installable only by an on-chain governance proposal that names it by Git revision and image checksum, the build is reproducible from public source, and the registry records the image hash and launch measurement. Redeployment therefore installs a version that was elected on chain and can be rebuilt and checked against that hash independently.

Swiss Subnet does not control the node providers. It contracts them to supply hardware and a level of uptime; each provider operates their own machine. The confidentiality gap above is a node provider’s capability, not Swiss Subnet’s.

Node compromise

Scenario	Attacker can read	Attacker can alter	Engine behaviour
1 of 4 nodes compromised	That node’s full state, if it is a shared node	Nothing — a result needs three of the four nodes	Continues normally
2 of 4 nodes compromised	As above, for two nodes	Correctness is no longer guaranteed	Stops, or returns a wrong result that verifies

At the minimum engine size of four nodes, f = 1. A larger engine raises f proportionally: seven nodes tolerate two faults, ten tolerate three.

Past the limit

Nodes that stop. Every result needs three of the four nodes to agree on it. With two nodes gone, the engine produces nothing: no calls are executed, no state changes. It returns no results rather than wrong ones, the state on the remaining nodes is intact, and the engine resumes when they come back.

Nodes that collude. Two compromised nodes cannot sign a result on their own, but they can tell the two honest nodes different things and get each of them to sign a different result. A wrong result then carries a valid signature, and a client that checks the signature accepts it. This is the boundary of the guarantee: past f, verification no longer separates a correct result from an agreed-upon wrong one.

Detection

Each node computes a hash of its own state and signs it, and a result is only produced when three of the four nodes signed the same hash. A node that disagrees cannot get its version of the state accepted. When it notices that the accepted state differs from what it computed, it shuts itself down, keeps the divergent state on disk for inspection, and reloads the accepted state from its peers on restart. This appears in the node’s logs and metrics within a round.

Two things this does not catch:

• A node provider reading state off their own machine. A passive read leaves no trace.
• A wrong result agreed by more than f colluding nodes. It verifies against the engine’s public key, so a single client cannot tell. Detecting it means comparing what different clients were served.

What this model does not cover

The model does not cover:

• Application-level vulnerabilities. The platform guarantees that deployed code runs as written. It does not make the code correct. A canister with an authorisation flaw is exactly as exploitable here as anywhere else.
• Compromise of client credentials. An attacker holding a valid identity acts with that identity’s rights. See Interfaces.
• Deployment control. Whoever controls a canister can upgrade it, and an upgrade can change any behaviour. Deployment control is the real administrative boundary; see Operations.
• Availability under denial of service at the network edge.
• Correctness of client-side verification. An integration that does not check signatures forfeits the integrity guarantee.

Audits and certifications

The protocol the platform runs on has been audited by third parties — Trail of Bits and NCC Group, covering consensus, canister sandboxing, threshold cryptography and the governance canisters — and the reports are public. DFINITY maintains the list at Third-party security audits.

Those audits cover the protocol, not Swiss Subnet AG as an operator.