PaperlayerView exact revision on arXiv

Source-linked AI summary

CA-less Mutual Co-Signing of Documents over a Unidirectional Visual Channel with Transported Hardware Attestation

Dmytro Diikun

arXiv:2608.25144v1cs.CR

TL;DR

The paper addresses mutual document co-signing between mobile devices when signing is offline, serverless, certificate-less, and limited to a lossy one-way visual channel. It proposes hash anchoring, signature chaining, transported hardware attestation, and rateless framing, and reports a working offline-verification instantiation under standard cryptographic assumptions. The main scope boundaries are that trust is rooted in the hardware manufacturer and attestation binds keys to devices rather than people.

  • Problem

    Mutual offline co-signing lacks a way to resolve circular signing and establish public-key trust without a network, server, or certificate authority.

  • Method

    The protocol uses a two-stage hash anchor, chained role-separated signatures, rateless transport of full hardware-attestation tokens, and offline anchor and signature verification.

  • Results

    The four stated security properties reduce to collision resistance of H and EUF-CMA security of the signature scheme, while an independent verifier reproduces every anchor and both signatures offline.

  • Takeaways & Limitations

    The construction maps the verifiability retained when network, server, and CA infrastructure are removed, without replacing PKI.

  • Takeaways & Limitations

    Key trust rests on the hardware manufacturer’s attestation root, and attestation establishes per-device rather than per-person provenance.

Abstract

from arXiv · show

We describe and analyze a protocol for mutual co-signing of a document by two mobile devices that (i) communicate only over a one-way, lossy, low-bandwidth optical channel (an animated on-screen code read by the counterparty's camera), (ii) use no intermediary server on the trust path, and (iii) use no certificate authority. Trust in each party's public key is instead grounded in a hardware attestation token produced by the platform secure element, transported in full over the visual channel by a rateless (fountain) code and cryptographically bound into the co-signature. The core technical contribution is a two-stage hash anchor that removes the circular signing dependency inherent to interactive co-signing: the first party commits to the document before the identity of the second party is known, and the second party's identity is later bound to that commitment without invalidating the first signature. We give a threat model, define four security properties (anchor binding, co-signature inseparability, attestation-bound key provenance, and post-signing tamper evidence) and reduce them to standard assumptions (collision resistance of H and EUF-CMA security of the underlying signature scheme), with the secure element modeled as an ideal signing oracle. We report a working instantiation on iOS/Android using ECDSA P-256 in the Secure Enclave/StrongBox, SHA-256, Apple App Attest / Play Integrity, and an LT-style fountain code, together with an independent third-party verifier that recomputes all anchors and checks both signatures fully offline.

1 Introduction

The paper targets offline mutual document co-signing between phones under one-way optical communication, without servers or certificate authorities. It addresses circular signing and CA-less key trust through hash anchoring, signature chaining, transported hardware attestation, and rateless framing.

  • The protocol enables two people to co-sign a document offline over a lossy, capacity-limited one-way optical channel without a server or CA.
  • A two-stage hash anchor resolves the circular dependency between signing the document and learning the counterparty’s identity.
  • The protocol transports a full hardware-attestation token over the optical channel and binds its hash into the signed anchor for CA-less key provenance.
  • Signature chaining makes the second signature inseparable from the specific first signature, preventing transplantation across documents or signatures.
  • The paper reports an engineering instantiation and standalone verifier that reproduces all anchors and both signatures without network access.
  • The protocol does not claim legal validity, PKI equivalence, or binding a hardware-backed key to a natural person.

2 Related Work

The paper combines established work on multi-signatures, certificate-less cryptography, hardware attestation, visual fountain channels, and content provenance. Its claimed novelty is their offline composition for mutual co-signing with transported attestation and inseparable signatures.

  • The contribution is the composition of five research areas rather than a single new ingredient.
  • Multi-signatures and co-signing: Unlike multi-signature schemes, the protocol produces two distinct role-separated signatures whose chaining supports mutual co-signing without aggregation.
  • Certificate-less and identity-based public-key cryptography: Unlike certificate-less public-key cryptography using a key-generation centre, trust here derives from a hardware manufacturer’s attestation root checked without network access at signing time.
  • Remote and hardware attestation: The paper transports the full hardware-attestation token peer-to-peer over a visual channel, enabling third-party provenance assessment offline under supported attestation conditions.
  • Rateless codes and animated visual channels: Rateless framing is used because the full attestation token exceeds a single optical code’s capacity, while no optimality claim is made for the chosen degree rule.
  • Content provenance and capture-time signing: Unlike one-sided content-provenance systems, the protocol mutually co-signs and anchors canonical textual content rather than display-file bytes.
  • The combination: The claimed novelty combines offline mutual co-signing, certificate-less hardware provenance, rateless visual transport, two-stage anchoring, and signature chaining.

3 Preliminaries and Notation

The protocol uses collision-resistant hashing, secure-element signatures, and hardware attestation as its cryptographic primitives. Production-versus-development attestation and secure-element availability define important assurance boundaries.

  • H is a collision-resistant hash instantiated as SHA-256, with UTF-8 encoding and record- and unit-separator delimiters used before hashing.
  • The signature scheme uses secure-element-generated ECDSA P-256 keys that never leave hardware, with signing gated by biometric user presence.
  • The attestation scheme produces a token that binds a public key and challenge to generation inside genuine platform hardware.
  • The hardware soundness assumption applies only to production attestation, while development tokens must not receive the full hardware guarantee.
  • Devices without a secure element emit a visible reduced-assurance marker rather than a hardware-origin guarantee.

4 System Model and Threat Model

The system consists of two secure-element-equipped phones exchanging signed data optically in opposite directions, with optional relaying outside the trust path. The threat model covers channel attacks, signature repasting, key-provenance forgery, and post-signing tampering under explicit cryptographic and deployment assumptions.

  • System model: Two devices exchange animated optical codes in opposite directions, with no server carrying signed data and no CA contacted.
  • System model: An optional relay may forward already committed and signed frames, but a malicious relay can at most cause denial of service rather than alter accepted content.
  • Threat model: The threat model analyzes four adversaries separately: hostile relay or channel, signature repaster, key-provenance forger, and post-signing tamperer.
  • Threat model: The hostile-channel adversary can drop, reorder, replay, or inject frames to alter content or induce acceptance of an unsigned document.
  • Threat model: The repaster attempts to transplant observed signatures onto a different document or first signature.
  • Threat model: The key-provenance forger targets acceptance of software-generated keys as hardware-backed or replay of another device’s attestation token.
  • Threat model: The post-signing tamperer changes signed fields such as amount, party, time, geolocation, or evidence without detection.
  • Assumptions and scope: Security assumes collision-resistant H, EUF-CMA signatures, non-leaking secure elements, and authentic verifier-pinned manufacturer roots; coercion, rooted-device biometric control, and legal weight are out of scope.

5 Construction

The construction combines injective canonical encoding, two-stage hash anchors, chained signatures, transported attestation, and rateless framing for offline co-signing over lossy optical turns.

  • Canonical field encoding: Injective, domain-separated canonical serialization prevents distinct field vectors from producing the same byte string.The paper uses escaped control-byte and length-prefixed forms, with the latter injective unconditionally.
  • Two-stage hash anchor: The first anchor commits to A’s content before B is known, while the second deterministically binds B without requiring A to re-sign.This reduces the exchange from three rounds to two optical turns.
  • Signatures and chaining: Signature chaining makes σB inseparable from the specific σA by including pkA and σA in mB.The signed messages use role-separated A: and B: prefixes.
  • Attestation transport: The transfer carries the full hardware attestation token alongside content, anchors, keys, and signatures, while only its context-separated digest enters the signed anchor set.The attestation binds pkA to secure-element key generation and supports offline verification modes.
  • Rateless framing: Rateless framing splits the transfer into base and XOR fountain frames, allowing peeling decode without a back-channel for lost-frame requests.The deployed LCG-XOR degree rule is presented as an engineering choice rather than an optimized rateless construction.
  • Verification and archival: A composite finalHash covers an ordered 39-field record, while rendering bytes remain outside the cryptographic anchor and may be regenerated.The canonical record includes both parties’ keys and signatures, h1, device-token hashes, and other committed fields.

6 Security Analysis

The security analysis formalizes verification and proves anchor binding, co-signature inseparability, attestation-bound provenance, and tamper evidence under collision resistance, EUF-CMA security, and attestation soundness assumptions.

  • Security model: The verifier accepts exactly when both role-separated signatures verify, while attestation checks are handled separately.The accepted record contains the document identifier, both identities, both public keys, and both signatures.
  • 6.1 Encoding injectivity and anchor binding: Canonical encoding is injective through fixed schemas and escaping, while length-prefixed TLV serialization removes the escaped form’s domain restriction.The admissible domain excludes raw control bytes that could forge subboundaries; TLV is injective unconditionally.
  • 6.1 Encoding injectivity and anchor binding: Anchor binding reduces to collision resistance of H when canonical encoding is injective on the admissible domain.The proof treats either a content collision or a second-party identity-binding collision as a hash collision.
  • 6.2 Co-signature inseparability: Co-signature inseparability reduces to EUF-CMA security because the second signature commits to the identifier, second anchor, first public key, and first signature.Removing pkA or σA from the second message would permit reuse under a different first signature.
  • 6.3 Attestation-bound key provenance: Attestation-bound provenance relies on attestation soundness, collision resistance of H, and fresh single-use challenges to prevent non-genuine keys and replay.The trust root remains the hardware manufacturer’s attestation root, and attestation binds keys to genuine hardware rather than natural persons.
  • 6.4 Post-signing tamper evidence: Post-signing tamper evidence follows from EUF-CMA security and collision resistance: altered content cannot retain a valid first signature except through a forgery or hash collision.The content vector and identifier determine the signed first-side message through the anchor h1.

7 Implementation

The implementation combines hardware-gated signing, platform attestation, fountain-coded optical transport, and an independent offline verifier across iOS and Android.

  • Primitives: ECDSA P-256 and SHA-256 run through Apple Secure Enclave or Android StrongBox-Keystore, with no software-key fallback.The signing path aborts when the hardware backing requirement is not met, and strict DER and low-S validation are enforced.
  • Attestation: Apple App Attest and Google Play Integrity provide production attestation, with iOS supporting offline chain verification and Android using manufacturer-service verification.The reference deployment also verifies attestation server-side at onboarding and records a re-checkable server-signed result.
  • Transport: An LT-style fountain code transports the protocol over animated optical codes, while NFC, BLE, ultrasound, and embedded files remain supported alternatives.The optical channel is the reference transport rather than the only supported channel.
  • Verifier: The standalone verifier recomputes h1, h2, and finalHash and checks both signatures without network access.Independent Dart and Python implementations agreed byte-for-byte on all digests.

8 Limitations and Trade-offs

The design trades CA independence for manufacturer-root dependence, with provenance limited to genuine device hardware and assurance varying across platforms and deployments.

  • Trust root: Key trust rests on the hardware-manufacturer attestation root, so a compromise of that root breaks provenance.Removing a CA relocates rather than eliminates the trusted party.
  • Identity scope: Attestation binds a key to genuine hardware, not a natural person; real-world identity binding remains outside the offline core.The protocol therefore does not provide a cryptographic guarantee of the signer’s personal identity.
  • Platform scope: Assurance is platform-dependent because StrongBox, TEE, and software backings differ, and Android is fragmented.Production-versus-development attestation is also a relevant boundary.
  • Formal scope: Lemma 1’s injectivity guarantee is restricted to the admissible domain unless TLV encoding is used for an unconditional statement.This constrains the formal claim rather than the overall protocol goal.
  • Engineering scope: The custom fountain-code degree rule is an engineering choice, with no optimality claim.The transport construction is presented as practical rather than optimally parameterized.
  • Threat scope: Duress, coercion, rooted-device malware driving biometric prompts, and integrity protection for duressFlag are out of scope.These conditions are excluded from the protocol’s analyzed threat surface.
  • Assurance: The implementation has not received an independent third-party security audit, which the authors require for high-assurance deployment.The absence of an audit is an explicit deployment boundary.

9 Conclusion

The paper shows that mutual co-signing can operate without network, trust-path server, or CA infrastructure by combining hash anchoring, signature chaining, and transported hardware attestation.

  • Security result: The four security properties reduce to collision resistance of H and EUF-CMA security of the signature scheme.The secure element is modeled as an ideal signing oracle.
  • Verification: An independent verifier reproduces every anchor and checks both signatures fully offline.The conclusion frames the construction as mapping the remaining verifiability after standard infrastructure is removed, not replacing PKI.

A Worked Example (redacted)

The worked example uses length-prefixed content serialization and records hashes and secure-element signatures for a synthetic document.

  • Serialization: The content anchor serializes each field as a byte length, value, and newline after the PAKTO-v82 tag and domain label.The example uses synthetic, non-personal inputs that can be recomputed with the reference verifier.
  • Preimage: The example exposes a serialized preimage containing the protocol tag, contentHash, document identifier, category, signer label, and version.The displayed preimage is a concrete head fragment of the anchor input.
  • Hashes: contentHash is 8271868f458a447f70bd54eda563b7347c0ea330fd1a77e24535fd719332384e, while contentHashFull is 7ca362ee0b7663f64480b746d4835044f815c2be7e2abed681ed0de84cb4120b.These are the two reported digest values for the worked example.
  • Signatures: σA and σB are generated in the respective secure elements, while only device-token hashes enter the composite record.The full attestation tokens travel separately in the transfer structure.

B Composite finalHash field order (escaped record)

The composite record uses escaped field serialization with a scheme tag, while signed anchors use TLV serialization. Its field order includes conditional B-block fields, always-present trailing fields, and verifier recomputation of finalHash.

  • Conditional fields: The B-block at indices 28–35 appears only when σB ≠ ε, while indices 36–38 always follow.The conditional block carries second-party key, signature, hardware, token, email, and identity fields; the trailing fields carry contentHash and profiles.
  • Serialization: The composite record uses control-byte-escaped serialization and carries its scheme tag in field 0, while h1 and h2 use length-prefixed TLV serialization.The example fixes field order rather than reproducing a numeric artifact.
  • Field order: The abbreviated field table defines the record's ordered fields and fallback encodings, including empty-value defaults such as zero bytes or sentinel strings.Fields include identifiers, document metadata, timestamps, public-key material, signature data, and device-related values.
  • Verification: For a complete document, the reference verifier recomputes finalHash from the serialized fields and compares it with the stored value.This check validates the final record against its stored hash.
Loading 2608.25144v1…