01 / The mechanism and its boundary
What the technique establishes
Sovereignty Certificates are a draft industry specification for proving where a computing workload runs. An agent inside a trusted execution environment exchanges signed messages with anchor servers at known locations and times the replies. Signals cannot travel faster than light, so each reply time caps the distance to that anchor. A verifier checks the hardware attestation and the timings, computes a feasible region and issues a certificate that expires after a few minutes. The specification is hosted by Lucid Computing and attributed to a working group. As of September 2026 it is still draft 0.1.0, dated October 2025, with no public implementation or measured results. It trusts the hardware root of trust and the TEE, and leaves sophisticated physical attacks as a residual risk. Known attacks on delay-based location, such as faster network paths and compromised anchors, also apply.
- Threat model
- Semi-trusted prover
- Adversarial evaluation
- Published analysis
- Hardware needed
- Existing hardware features
- Prover cooperation
- Required
- Confidentiality
- Preserving
- Category
- Accounting & provenance
Technical detail and cited results
The specification follows the IETF RATS architecture (RFC 9334) and the Entity Attestation Token format (RFC 9711) S-1404. Its roles are an Attester (a workload with a sidecar agent), a Verifier, an Anchor Fleet at fixed locations, an Endorser that publishes a signed directory of anchors with their public keys and coordinates, and a Relying Party S-1404. The Attester generates an ephemeral key pair each cycle. A hash binding that key and the verifier's nonce goes into a register included in the hardware root of trust's signed quote S-1404. The Attester may probe anchors directly or query a local trusted proxy S-1404. The anchors probed must be chosen to minimize geometric dilution of precision (GDOP) S-1404.
Anchor receipts carry a high-precision timestamp of the probe's arrival, the probe's nonce and the anchor's identifier, and are signed S-1404. The normative text has the Verifier derive round-trip times from the receipts' timestamps; in the Annex B example, the Attester sends a UDP probe to each of eight anchors and records the local arrival time of each reply S-1404. Anchors must be synchronized to a precise time source, preferably UTC S-1404. The Verifier must reject evidence whose distance bounds have no common intersection S-1404.
The EAT profile defines private claims for the platform quote, the ephemeral public key, the location receipts, a location claim with latitude, longitude, radius in metres and confidence, and the policies passed S-1404. In the Annex B example the certificate expires after 10 minutes and is renewed about every five. If a certificate expires, the workload must fail closed S-1404. Long-lived anchor, verifier and endorser keys must sit in hardware security modules, and signatures should use ECDSA with P-256 or stronger S-1404.
Claims and scope
A direct link identifies the intended claim. A supporting link supplies part of the evidence. Neither establishes that a complete verification system has been demonstrated.
Chips are where they are declared to be
Certifies a bounded region in which an attested workload's platform was running at a given time.
Readiness for a stated use
Assessed use: certifying the region where an attested workload ran at a given time
medium confidence · current · assessed 2026-09-25 · rubric 1.1
This is the source map’s editorial assessment. Production use is not evidence of resistance to every adversary.
A public draft states the claim and threat model, but nothing has been built or measured in public.
- R1 met: the draft states what the certificate is meant to prove, the protocol, the threat model and its trust assumptions S-1404.
- R2 not met: as of September 2026 the repository holds only the specification, with no reference implementation, code or measured location results S-1404. The only location figures are an illustrative example in an annex S-1404. Lucid's homepage states that each of its clusters can prove where it is, but neither the homepage nor the developer documentation publishes how location is determined or any results S-1406 S-1407. The working group gave January 2026 as the target for a final version, and the draft is still version 0.1.0 S-1405 S-1404.
Evidence needed for the next level
A public reference implementation, or reproducible results with a real anchor fleet and realistic network paths.
Published location accuracy and false-rejection rates.
An independent security review of the protocol and its trust assumptions.
Limitations, flaws, and blockers
These are attributed assessments from the source map. Absence of a listed flaw is not a security guarantee.
significant / open / theoretical argument
Physical attacks on the trusted hardware are out of scope
The specification places the hardware root of trust and the TEE in the trusted computing base. It assumes they resist software attacks, notes that the attacker may have physical access, and leaves sophisticated physical attacks, such as bus probing and side-channel analysis, as a residual risk S-1404. It says that future revisions may add requirements for physical tamper evidence S-1404.
significant / open / theoretical argument
On-chip keys may be extractable
Tee and Happel argue that ping-based location protocols backed by keys stored on the chip can be compromised if an adversary with physical access extracts those keys S-1403. In this specification, the evidence chain rests on the hardware root of trust's signed quote, whose signing key must be protected by the hardware S-1404.
significant / open / theoretical argument
General delay and landmark attacks apply
Attacks on delay-based location verification in general also apply. Brass and Aarne discuss adding delay, using faster paths such as dark fibre, and compromising landmarks S-1400. The specification counters anchor impersonation with a signed anchor directory. Against collusion it recommends anchors in diverse places run by several independent operators, and peer monitoring that temporarily removes anchors whose timings deviate S-1404.
What still blocks use or stronger assurance
Connections in the research map
Depends on
- TEE remote attestation for AI workloads
Location evidence is bound to a hardware-rooted TEE attestation quote.
Mechanisms implemented
Organizations and developers
The Consortium’s case files
Related editorial reviews use the Consortium’s own descriptive scores and review dates. Their scores are separate from the atlas readiness rubric.
LV-01 / LocationGeography by ping timeRead case file ↗Sources and provenance
- S-1404 / Tier B
Sovereignty Certificates: draft specification, version 0.1.0 ↗
Sovereignty Certificates Working Group · 2025 · GitHub (Lucid-Computing/sovereignty-certificate-specification)
Supports: status, version, scope, roles, protocol, binding, timing, claims, threat model, security considerations, worked example
Locator: title block; §0-0.3, §3, §4.1-4.2, §5.1-5.6, §6.2-6.5, §7.1, §8.1-8.4; Annexes A-B
Version and catalogue details - S-1405 / Tier B
Sovereignty Certificates Working Group ↗
· 2026 · sovcert.org
Supports: working-group description; target date for a final version
Locator: homepage
Version and catalogue details - S-1406 / Tier B
Lucid Computing: Verifiable AI. Proven in hardware. ↗
· 2026 · Lucid Computing
Supports: Lucid's confidential-computing offering, its statement that clusters can prove their location, and link to Sovereignty Certificates
Locator: homepage
Version and catalogue details - S-1407 / Tier B
Lucid Developer Platform documentation ↗
· 2026 · Lucid Computing
Supports: sovereignty-related auditor listed without method details
Locator: reference/auditor-catalog.html; concepts/architecture.html
Version and catalogue details - S-1403 / Tier B
GPU Fingerprinting for Location Verification ↗
W. Tee, J. Happel · 2026 · arXiv
Supports: key-extraction weakness of ping-based protocols
Locator: Abstract
Version and catalogue details - S-1400 / Tier B
Location Verification for AI Chips ↗
A. Brass, O. Aarne · 2024 · Institute for AI Policy and Strategy
Supports: general attacks on delay-based location verification; typical precision of delay-based methods
Locator: Delay-based methods sections; brief survey of location verification methods
Version and catalogue details
- Source review date
- 2026-09-25
- Drafted by (source map)
- ai
- Review handles (source map)
- codex-review