Patela v2: From Certificates to Hardware - Osservatorio Nessuno

A year ago, Osservatorio Nessuno introduced Patela v1, a system designed to orchestrate diskless Tor exit nodes running on System Transparency's stboot. The initial concept was straightforward: nodes would boot from read-only images, generate their own keys, and then encrypt and back up those keys on a server. This approach aimed to maintain node persistence without relying on local storage. However, the team has now unveiled Patela v2, which fundamentally shifts the architecture to anchor trust in hardware, specifically Trusted Platform Modules (TPMs), thereby removing the operational complexity of backups and strengthening the security model.

Evolving the Architecture: From Certificates to TPMs

In Patela v1, node identity was established through mTLS certificate digests. Client certificates were embedded at compile time, and the SHA-256 hash of a certificate served as the node's unique identifier in the database. The authentication flow involved the client presenting a certificate, which the server would validate against its Certificate Authority (CA), and then use the certificate's digest as a database key. While functional for early testing, this method was cumbersome and not the team's ultimate vision. The goal was always to have keys residing directly within the TPM, bound to the hardware itself, making diskless operation truly stateless and secure.

Patela v2 achieves this by making the TPM the definitive source of truth for node identity. Instead of a certificate hash, a node's identity is now defined by a triplet: (EK_public, AK_public, AK_name).

• Endorsement Key (EK): This is a unique key burned into every TPM chip during manufacturing. It cannot be changed, extracted, or cloned, providing a hardware-rooted unique identifier.
• Attestation Key (AK): Generated at runtime, the AK serves as proof that the holder controls the specific EK. The EK certifies this key.
• AK Name: A cryptographic digest of the AK's public parameters, computed by the TPM itself.

The server stores this triplet in the database, creating a unique index to ensure each node is tied to its specific hardware. This change means that authentication to the configuration server now requires physical possession of the corresponding TPM chip, fundamentally altering the trust model from a software-based credential to a hardware-bound one.

Trust on First Use (TOFU)

With this hardware-centric approach, the team had to consider how to handle new nodes joining the network. Currently, they do not validate EK certificates against TPM manufacturer CAs. When a node first connects, the server lacks cryptographic proof that the EK originates from genuine hardware versus a software emulator. To mitigate this, Patela v2 implements a Trust on First Use (TOFU) model. New nodes are created in a disabled state (enabled=0). An administrator, knowing when a new node is expected to register, must explicitly enable it using a command like patela node enable <node_id>. This prevents unauthorized or random devices from automatically joining the network while keeping the overall process largely automated.

The End of Backups: Hardware-Bound Persistence

Patela v1 relied on a backup mechanism to ensure Tor relay identity persistence. The process involved the client generating an AES key inside the TPM, using it to encrypt Tor relay keys, and uploading the encrypted blobs to the server. On boot, the client would download and decrypt these blobs. This allowed diskless relays to maintain a stable identity, which is crucial for building reputation and trust within the Tor network.

Patela v2 eliminates this entire backup flow. The actual relay keys now live exclusively in the TPM's persistent storage. The philosophy here is that hardware failures, while possible, are rare enough to make this hardware-binding a viable trade-off for the simplicity and security gained by removing backups. There is a current caveat: as the TPM standard does not support operations for Ed25519, the key is stored as a byte string in non-volatile storage, meaning it is still technically exportable. The team acknowledges this is suboptimal but sees no short-term solution given the current TPM specifications.

A More Flexible Configuration Cascade

The original Patela used a single, hardcoded torrc template for every relay. This worked initially but became a bottleneck for customization. Different nodes required unique ExitPolicy rules, bandwidth limits based on upstream providers, or custom ports. Any change necessitated code modification, recompilation, and redeployment of the entire system.

Patela v2 introduces a hierarchical configuration cascade that resolves settings from the most general to the most specific. The structure is:

1. Default Config: Global settings for all relays.
2. Per-machine Config: Overrides for a specific node.
3. Per-instance Config: Overrides for a specific relay instance on that node.

This is implemented directly in the database schema with tables for global defaults and columns for node and relay-specific overrides. When a client boots, the server resolves the configuration by merging these levels, with more specific settings overriding more general ones. To handle this, the team wrote a custom torrc parser (server/src/tor_config.rs) that validates against known Tor options and intelligently merges the configurations. This new workflow allows operators to manage settings at different scales without touching the core codebase, using simple commands to import configuration files for global, node, or relay-level application.

Authentication via Partial Attestation

The authentication protocol itself is a sophisticated use of TPM2 features. It employs a make_credential / activate_credential challenge-response flow:

1. The client sends its EK_public, AK_public, and AK_name to the server.
2. The server uses make_credential to encrypt a session token with the client's EK_public and AK_name.
3. The client receives the encrypted token and uses its TPM's activate_credential function to decrypt it, proving it possesses the physical hardware.
4. The client then uses the decrypted session token (a Biscuit bearer token) for subsequent authenticated requests.

This process provides cryptographic proof that the client controls the specific TPM hardware, securing the authentication channel.

Future Goals: Towards a Complete Hardware Root of Trust

The team has ambitious plans for the future. The ultimate goal is to integrate measured boot to seal TPM secrets, combining Patela with System Transparency and coreboot. This would create a complete chain of trust: the hardware root of trust measures the coreboot, which in turn measures stboot. The TPM would only unseal its secrets if the measurements are correct, ensuring that only properly signed and publicly auditable images can run. This would make the system resistant to physical compromise; even if a server were seized and a different firmware were run, the keys would remain unrecoverable.

Getting Involved

The Patela v2 code is open source and available on GitHub at osservatorionessuno/patela. The team provides instructions for setting up a development environment, which includes running a server and a client with a TPM2 emulator. The project, at around 6,000 lines of Rust, is a testament to the power of focused, volunteer-driven development. It stands on the shoulders of projects like System Transparency and the Rust TPM library tss-esapi.