PaperlayerView exact revision on arXiv

Source-linked AI summary

Federated Trust for Embodied Robot Capability Marketplaces

Xue Qin, Simin Luan, Cong Yang, Zhijun Li

arXiv:2609.00404v1cs.CRcs.ROcs.SE

TL;DR

Embodied robot fleets span heterogeneous trust contexts, including air-gapped deployments where certificate-authority round trips are unsuitable. The paper presents bridge-local federated trust and evaluates its verification costs against established approaches, while acknowledging that it lacks a transparency log for post-hoc detection.

  • Problem

    Embodied deployments require different acceptable-publisher sets, and air-gapped operators cannot rely on network round trips to a certificate authority.

  • Method

    Federated trust assigns install-time verification to each bridge using detached Ed25519 signatures and a local directory of trusted signer public keys.

  • Results

    Federated trust’s per-verify median is lower than Sigstore-Cosign’s offline verify on the same hardware: 204 µs versus 860 µs at p50.

  • Takeaways & Limitations

    Separating the immutable registry from bridge-local verification lets one registry serve bridges with disjoint trust sets and supports offline registry replacement without changing gate semantics.

  • Takeaways & Limitations

    The design lacks an append-only Merkle log, so it cannot provide post-hoc detection that a trusted publisher signed a malicious package.

Abstract

from arXiv · show

Robot capability marketplaces, the "app store for robot skills," are emerging as the deployment vector for LLM-driven robot fleets. The default cloud-native answer to "is this package safe to install?" is centralised PKI: one certificate authority, one transparency log, one root of trust. We argue this is the wrong model for embodied robot fleets, where operators face heterogeneous regulatory regimes, air-gapped deployments, tiny operator headcounts, and physical-world consequences for trusting the wrong publisher. We present federated trust: each deployed bridge maintains its own local trust directory of acceptable signers; signers identify themselves with a public key embedded in a detached Ed25519 signature envelope; install-time verification is a local set-membership check rather than a network round trip to a certificate authority. The cryptographic primitives are deliberately standard (Ed25519 detached signatures and SSH-style trust files); the contribution is the architectural commitment that this composition fits embodied robot fleets specifically. We implement the model in a runtime governance layer with a five-subcommand CLI, a registry server, a per-bridge install gate, and 80 tests. A multi-deployment evaluation shows the same registry stream producing divergent install verdicts on bridges with different trust directories, the load-bearing design property. Across 5000 adversarial trials, the strict-mode gate rejects 100% of rogue-publisher, tampered, forged, and revoked-signer attacks, and 96.6% of downgrade attempts under a minimum-version pin extension. A same-hardware comparison against Sigstore-Cosign and python-TUF locates federated trust's per-verify cost between the two and its per-publisher storage footprint below both.

1. Introduction

Embodied robot fleets need deployment-specific trust rather than a single centralised PKI because regulatory, connectivity, staffing, and physical-risk conditions vary. The paper presents federated trust, implemented and evaluated as a bridge-local governance model.

  • Four deployment contexts require different acceptable-publisher sets, from regulator-cleared hospital publishers to household marketplace packages.
  • Air-gapped deployments make certificate-authority network round trips unsuitable, while small operator teams require filesystem-level trust management.
  • Federated trust embeds signer public keys in detached Ed25519 envelopes and assigns trust decisions to each bridge’s local directory.
  • The implementation provides a runtime governance layer, five CLI subcommands, a registry server, a bridge-side gate, and 80 integration tests.
  • The same registry stream produces divergent install verdicts on bridges with different trust directories, demonstrating per-deployment trust decisions.
  • The model addresses install-time threats but excludes malicious code signed by a valid trusted key and runtime or hardware compromise.

Out of scope.

The security model defines install-time games for rogue, tampered, forged, revoked, and downgraded packages, then distinguishes exact claims from empirical and informal arguments.

  • Strict mode rejects rogue-publisher, tampered, forged, and revoked-signer attacks with probability 1, while downgrade rejection reaches 96.6%.
  • Tamper and forge arguments rely on Ed25519 security and SHA-256 collision resistance, whereas rogue and revoke arguments rely on trust-directory membership.
  • The formal presentation is an informal security argument, with theorem-grade verification left for future work.
  • The model assumes a trusted operator controls each bridge filesystem and applies revocation across every bridge.
  • The downgrade guarantee is implementation-level rather than cryptographic because residual escapes arise from version-string normalisation.

Composition over the quorum extension.

The quorum extension composes independent signer checks so acceptance requires at least k trusted valid signatures, increasing resistance to single-insider compromise.

  • Under quorum, winning an attack requires winning k independent instances of the underlying security reduction.
  • Defeating quorum requires k −1 additional valid trusted-signer signatures beyond the compromised signer.
  • The extension leaves in-scope probability-zero bounds unchanged but tightens the Cinsider-1 bound from 1 to a k-dependent bound.
  • The quorum composition and five security arguments are empirically checked with N = 1000 adversarial trials per game.

3. The Federated Trust Model

Federated trust separates cryptographic verification from local trust resolution and keeps the registry as an immutable byte-distribution service. Bridges can therefore apply different install postures to the same published artefact.

  • A signed archive pairs the original .aecm file with a sibling .sig JSON envelope containing algorithm, digest, signature, public key, timestamp, and optional signer label.
  • The signature covers SHA256 of archive bytes, while the embedded public key permits cryptographic verification before trust-directory lookup.
  • Operators manage bridge trust by copying or removing PEM-encoded Ed25519 public-key files in a local trusted_keys directory.
  • Trust resolution compares the verified raw public key with the directory set, producing valid-trusted, valid-untrusted, or invalid verdicts.
  • Install posture supports warn-and-continue, strict rejection of unsigned or untrusted packages, and a one-install unsigned override; tampering always rejects.
  • The registry stores and streams immutable artefacts without verifying signatures, leaving verification to each bridge.

4. Implementation

The implementation wraps standard Ed25519 and trust-directory primitives in a CLI, registry, and bridge install gate, with broad automated coverage and measured verification costs.

  • Signing and trust management: The signing module provides key lifecycle, SHA-256 digest, Ed25519 signing and verification, signature-envelope composition, and trust-directory parsing.Private keys use PKCS8 PEM with 0600 permissions, while trusted public keys are loaded from *.pub PEM files.
  • CLI and install gate: The aeros ecm CLI exposes five core subcommands for key management, signing, verification, and registry publication or retrieval, plus installation enforcement.The install gate is invoked before the legacy unpack-and-register path and distinguishes accepted, malformed, and refused outcomes with exit codes 0, 2, and 3.
  • Testing: 80 marketplace tests cover cryptography, CLI behavior, registry serving, and live registry integration within a 1674-test suite.The full suite passes on Python 3.11, 3.12, and 3.13 with mypy --strict and ruff checks.
  • Verification cost: Approximately 80 µs is required for one verify_aecm call on a typical 5 KB archive, with file I/O and SHA-256 dominating the roughly 30 µs Ed25519 primitive.Across 1000 iterations, the reported mean is 77 µs, with p50 = 73 µs, p95 = 82 µs, and p99 = 174 µs.
  • Trust-directory caching: Caching a parsed single-signer trust directory reduces a 1000-package batch from approximately 74 ms to 64 ms, a 1.16× speedup.At 1000 signers, parsing grows to approximately 7.7 ms per call and caching provides a roughly 100× speedup.

Bulk verify throughput.

The evaluation compares federated trust with cloud-native alternatives across deployment-specific verdicts, latency, bootstrap, storage, and threat outcomes. Results show divergent bridge decisions from one registry, low storage overhead, faster cold bootstrap than TUF, and an explicitly qualified steady-state latency trade-off.

  • Multi-deployment evaluation: Three bridges pointed at one registry produce different strict-mode install profiles because their trust directories contain {A, B}, {A, C}, and {C}.The experiment uses five packages signed by three publisher keys and requires no coordination between bridges.
  • Threat evaluation: An operator-controlled trust directory bounds a compromised publisher’s blast radius: adding rogue signer R to bridge-2 makes only bridge-2 accept R’s package.Bridges 1 and 3 continue rejecting the package, so one operator’s key compromise does not cascade to peer bridges.
  • Latency comparison: 204 µs versus 860 µs at p50: federated trust is lower than Sigstore-Cosign on this hardware, but the paper avoids promoting a specific speedup multiplier.Cosign measurements are CLI-startup-corrected and use a CLI path rather than an in-process library, limiting the comparison’s interpretation.
  • Bootstrap comparison: 88× faster is federated trust’s cold-start trust bootstrap than python-TUF’s first Updater.refresh(), at 124 µs versus 10,946 µs.TUF walks and verifies a four-role metadata chain, whereas federated trust scans one PEM-encoded public key per signer.
  • Latency comparison: 204 µs versus 27.7 µs at p50: federated trust is slower than python-TUF in steady-state offline verification because TUF amortises verification across in-memory metadata.Federated trust recomputes verification on every install call to close the time-of-check-to-time-of-use gap.
  • Storage comparison: 511 bytes is federated trust’s per-publisher envelope-plus-trust-entry footprint, versus 3,879 bytes for Sigstore-Cosign and 5,151 bytes for python-TUF.The resulting footprint is 6.8–7.6× smaller than Sigstore and 9.0–10.1× smaller than TUF, depending on envelope serialization.
  • Hypothesis results: H1, H3, and H4 pass at 0.24×, 88.3×, and 0.13× respectively, while H2 was not measured in the comparison harness.The paper treats the inferred bulk comparison for H2 as an implicit argument rather than a measured pass.

Independent-measurement caveat.

The evaluation uses deterministic, single-workstation harnesses and reports both adversarial detection and quorum-extension costs. Baseline comparisons should be read as cross-scheme ratios rather than absolute calibrations.

  • Measurement caveat: Cross-scheme baseline numbers should be interpreted as consistent-hardware ratios, not absolute calibrations.The canonical standalone federated-trust measurements remain those reported in Sections 5.1–5.4.
  • Adversarial evaluation: 1000 trials per adversary game evaluate the strict-mode install gate, with results summarised in Table 4.Each trial submits an attack-generated envelope to the gate and records whether installation is refused.
  • Adversarial evaluation: 96.6% of downgrade attempts are detected with the minimum-version pin, compared with 0% without the pin.The pin is not enabled by default in V1.
  • Quorum extension: 15,000 quorum-policy trials show identical detection rates for 1-of-1, 2-of-3, and 3-of-3 policies across all five games.Downgradepin is 0.976 under every policy, while the other four games are 1.000.
  • Quorum extension: The 3-of-3 envelope grows from 457 bytes to 1200 bytes and bulk verification is 2.46× slower than 1-of-1.The slowdown reflects sequential verification of three signatures.
  • Reproducibility: The artefact includes deterministic harnesses, raw per-run data, replication instructions, and supplementary material of approximately 3 MB.The reported evaluations were generated at commit 8df4344 on a single workstation.

6. Threat Analysis and Comparison

Federated trust detects the in-scope threats through cryptographic verification, trust-directory membership, registry immutability, and version pins. Its operational advantages come with inherited limits around filesystem control, rotation, and attack-detection machinery.

  • Threat outcomes: Rogue publishers, tampered packages, forged signatures, and revoked publishers are refused under strict mode through trust resolution or cryptographic checks.Revocation requires removing the publisher key from each bridge’s trust directory.
  • Threat outcomes: 96.6% of downgrade attempts are detected with the minimum-version pin; the 34 residual escapes involve non-canonical version-string normalisation.The residual cases involve whitespace or pre-release suffixes.
  • Comparison: Federated trust has a smaller per-publisher storage footprint and lower per-verify median than Sigstore-Cosign, while cold bootstrap is roughly two orders faster than python-TUF metadata refresh.These quantitative comparisons are reported alongside qualitative differences in offline support and deployment granularity.
  • Operational limits: An attacker controlling the trust directory can add a malicious public key and authorise packages, so this boundary requires host-side write auditing.The install gate provides no cryptographic defence against filesystem writes already controlled by the attacker.
  • Operational limits: The gate mitigates verify-install races by reading archive bytes once, reusing the buffer, and opening archives with O_NOFOLLOW.These measures do not protect against concurrent writes to the same inode.
  • Operational limits: During key-rotation windows, exposure depends on operator action across bridges and includes fresh malicious publications signed by the compromised key.Registry immutability blocks retroactive reuse of previous version identifiers, while minimum-version pins block downgrade replays.
  • Design trade-off: The design trades transparency logs, CRLs, and rotation primitives for offline, per-deployment, filesystem-operable trust.The paper frames this trade as suitable for embodied fleets rather than cloud workloads.

7. Case Studies: Mapping Real-World Supply-Chain Compromises

The case studies map XZ Utils and SolarWinds to compromises involving trusted signing identities, placing both outside the baseline single-signer gate’s in-scope adversary classes. The analysis presents quorum signing as a way to raise attacker effort, while limiting the claim to a design analysis rather than an incident reconstruction.

  • Scope: The case studies are illustrative and do not claim that federated trust would have prevented either incident outright.They instead examine how the required attacker effort changes under single-signer and quorum policies.
  • XZ Utils: XZ Utils involved a trusted maintainer whose genuine private key would have signed the malicious release.The paper classifies this as Cinsider-all and outside any single-signer scheme without external attestation.
  • XZ Utils: No in-scope game fires for XZ Utils because the malicious release carries a genuine signature from a trusted key.The gate therefore has no cryptographic refusal signal in this case.
  • Quorum extension: Under a 2-of-3 quorum, an XZ-style attack would require compromising two signing identities or obtaining demonstrable approval from the other signers.This application is a paper analysis of a design option, not an evaluated reconstruction of the incident.

Gate verdict, quorum extension.

The quorum extension addresses multi-party approval scenarios that the single-signer baseline cannot satisfy, but its security benefit depends on independent signers performing substantive review. SolarWinds shows that quorum raises attack cost without guaranteeing prevention against capable attackers.

  • Quorum policy: A quorum requires multiple signatures and lets the bridge accept only when at least k trusted signers approve.The paper’s extension applies this policy to multi-party release approval.
  • Operational condition: Quorum sign-off must involve actual code review by each signer rather than rubberstamp approval.The security value depends on the independence and diligence of the participating parties.
  • SolarWinds: SolarWinds attackers compromised the build pipeline and produced legitimate updates signed by SolarWinds’ production certificate.The incident affected approximately 18,000 customers and reached federal agencies and Fortune-500 enterprises.
  • SolarWinds: A 2-of-3 policy involving SolarWinds, an external attestor, and the enterprise customer would require compromising two or all three parties’ build pipelines.The paper states that state-level attackers are not casually deflected, although operational cost rises substantially.
  • Boundary: Federated trust does not detect build-pipeline compromise; that responsibility belongs to reproducible builds, SBOMs, and provenance attestation.Its install-time role after disclosure is per-deployment signer removal rather than prevention.

What federated trust adds and does not add.

Federated trust adds local, per-deployment control and optional quorum approval, while leaving several supply-chain threats and operational burdens unresolved. The paper positions it as complementary to upstream attestation and transparency mechanisms.

  • Does not add: A Merkle transparency log is absent, so post-hoc detection of a publisher-signed malicious package is not provided.The paper proposes an optional future log for high-assurance deployments while preserving offline operation by default.
  • Operational limits: Revocation is manual, requiring operators to visit each bridge and remove its .pub file.The paper identifies this as adequate for a household robot but inadequate for a 1000-robot warehouse.
  • Operational limits: Key rotation is also manual because the CLI lacks an aeros ecm key rotate command.The process requires generating a key, resigning packages, distributing the new public key, and removing the old one.
  • Extensions: The single-signer envelope does not support multi-party packages without the proposed multi-signer extension.The extension preserves the trust-directory model.

X.509 and traditional PKI.

Traditional PKI and related systems provide mature attack-detection and update-integrity mechanisms but assume greater operational capacity and connectivity than many embodied fleets provide. Federated trust instead emphasizes local operator control and complements upstream attestation and runtime protections.

  • X.509 and traditional PKI: X.509 PKI offers CRLs, OCSP, hierarchical CAs, and certificate transparency, but its operational weight can exceed small fleet operators’ staffing capacity.The paper links this mismatch to a thinner trust-rooting approach for small-operator deployments.
  • Historical precedent: The PGP Web of Trust allows per-user assignments and detached signatures without a CA, whereas federated trust omits transitive trust relationships.Each signer is either present in the trust directory or absent.
  • Update systems: TUF provides role-separated metadata integrity for disciplined update operations, while federated trust trades some machinery for lower operational cost.The comparison is framed around the differing needs of embodied fleets and software update teams.
  • Closest prior art: Uptane similarly pushes verification to the edge and rejects a single global CA, but assumes an OEM-rooted hierarchy unlike robot fleets spanning vendors and regulators.The distinction is domain-specific rather than a rejection of Uptane’s fleet-oriented design.
  • Complementarity: SCITT-style transparency services can sit upstream, while the install-time decision remains with the operator’s filesystem.This preserves local decision-making alongside supply-chain statements and attestations.
  • Scope: The paper secures capability distribution rather than robot-node communication, inference-layer attacks, or runtime misuse.Runtime governance and communication-security tools address those orthogonal layers.
  • Paper contribution: The implementation includes a runtime governance layer with 80 tests, and experiments demonstrate divergent per-bridge verdicts without trust-directory compromise cascading to peers.These results support the paper’s claimed per-deployment trust property.
Loading 2609.00404v1…