Inverting Chaum’s Wallet with Observers: Hardware Identity vs. Software Authority in DSM
Why Physical Silicon Should Never Be Trusted as a Double-Spend Prevention Register
The historical literature on secure offline electronic cash has been split into two core paradigms:
1.
Detection-Based Offline Cash, pioneered by David Chaum, Amos Fiat, and Moni Naor in 1988 and given an elegant, efficient construction by Stefan Brands in 1993. In this family, a coin can be spent offline. Offline double spending is not prevented but detected: a coin spent once remains anonymous, while spending it twice reveals the spender’s identity when the coins are later deposited with an issuer. This paradigm is poorly suited to general-purpose state execution or non-monetary coordination because it defers enforcement to a post-facto deposit step.
2.
Hardware-Prevented Offline Cash, famously proposed by David Chaum and Torben Pedersen in their 1992 paper
“Wallet Databases with Observers”, and also situated within Brands’ work. In this model, a tamper-resistant physical chip—the
Observer—participates in signing each payment and refuses to authorize the same value twice. This design makes the hardware part of the transaction authority, placing the no-double-spend rule inside tamper-resistant silicon.
DSM completely rejects this historical assignment. By analyzing the limitations of the Observer model, DSM introduces a clean separation of concerns: hardware is demoted to a pure identity witness, while double-spend prevention is isolated entirely within the software authority.
You can view the full development workspace and related papers here:
GitHub Repository: https://github.com/deterministicstatemachine/dsmSoftware Authority & Hardware Identity Paper: DSM Software Authority & Hardware IdentityTechnical Paper: https://eprint.iacr.org/2025/592.pdfTelegram Group: Join the DSM Telegram Group
1. The Vulnerability of the Observer ParadigmRelying on hardware to enforce double spend rules makes the hardware's physical attack surface the entire protocol's attack surface. If an attacker can successfully mount a physical attack, such as clock glitching, voltage manipulation, or laser assisted fault injection, they can bypass the double signing check inside the silicon. Once that physical barrier is broken, the security of the entire ledger collapses.
Furthermore, historical implementations often derived transient session keys from chip state machines. For example, cryptographic slot states, such as MAC based or PIN verification slots, are often host restorable by replaying known inputs, as demonstrated by vendor reference PIN flows that restore consumed slots by replaying a derived input. Such slot states carry no true forward only, non rewindable lineage.
2. DSM's Separation: Software Authority, Hardware IdentityDSM resolves these issues by decomposing trust. The central claim is a strict separation:
o Software enforces correctness and uniqueness of state transitions.
o Hardware, the Anchor, serves strictly to verify the uniqueness of the physical device instance.
In DSM, the hardware is semantics blind and never acts as a transaction authority. The receiver's offline acceptance predicate reads no live chip state, no active host registers, and no raw hardware counters. Instead, double spend prevention is a pure mathematical property of whole state consumption in software.
The entire device state is committed inside a sparse Merkle tree, or SMT. A parent state root is consumed as a whole, admitting exactly one accepted and executed successor. If an attacker attempts to clone the software state chain and run it on another device, the software remains internally consistent but lacks the physical hardware bound to the account. The hardware's only job is to prove that the transaction was executed on the one, uniquely enrolled physical device, rather than a software clone.
3. The Three Factor Release WitnessTo achieve this without letting the hardware dictate state validity, DSM binds offline bearer transfers to a three factor identity fusion over a single root advance message. A complete release proves the live cooperation of the phone, the chip, and the host over the exact transition, the exact recipient, and the exact challenge:
o Factor 1, User Entropy: A signature under seed derived keys proving user intent, using the DSM device signature scheme.
o Factor 2, Silicon Identity: An Ed25519 signature executed inside a TROPIC01 secure element under a resident key pair generated in slot at birth. The private half is non exportable and protected at rest by the silicon's Physically Unclonable Function, or PUF.
o Factor 3, Host Firmware: A signature generated inside the secure partition of the RP2350 microcontroller.
During the offline enrollment ceremony, or birth, the public keys pk_chip and pk_host are exported and bound into an immutable Anchor Bundle. Receivers of offline transfers do not verify live chip registers; they simply verify the signatures against the public keys pinned in the bundle.
4. Measurement Gating and Firmware IsolationIn a traditional secure element setup, the chip cannot verify if the host software has been compromised; it signs whatever raw payload is sent over the communication bus. Any attacker with root access on the host could theoretically bypass the local state checks and force the secure element to sign multiple conflicting transitions.
DSM blocks this through measurement gating. At appliance birth, the RP2350 host partition key is generated under a partition seal p0. The unsealing gate is the enrolled firmware measurement. Only firmware whose measurement matches the enrolled policy hash may obtain the host signing service.
If an attacker modifies the host operating system or flashes rogue firmware to bypass the software's state uniqueness checks, the firmware measurement changes. The RP2350 secure monitor instantly returns an unsealing failure and refuses to sign. Because offline receivers verify both the chip signature and the host signature, the transaction fails acceptance immediately, with no live network query required.
5. The Physical Counter as a Tripwire, Not an AuthorityDSM does include a monotonic counter, but its placement is radically different from the Observer literature:
o The SMT State Counter in Software: The authoritative register is a monotone counter committed directly as a leaf in the device's sparse Merkle tree. Position is explicit inside the state root itself, and advancing the state index is part of the single atomic root replacement that consumes the state.
o The TROPIC01 Counter in Hardware: The physical monotonic counter is not an acceptance authority. It merely tracks the SMT counter one to one where the anchor counter coordinate ui equals H0 minus H.
If an attacker restores a cloned software image with an older state root to attempt a double spend, the local SMT counter will show an older coordinate. The hardware appliance detects this desynchronization and permanently refuses offline operations, failing closed.
6. Commit Discipline and Single Appliance EmissionTo prevent a malicious host from executing prepare abort cycles to harvest multiple signed certificates for a single state origin, DSM enforces a strict Commit Discipline:
o Prepare Phase: The appliance checks the parent root and counter synchronization but mints no signatures. Prepare stores only the staged fields, producing no signed release certificates.
o Commit Phase: The appliance stores the committed candidate, re pins the counter, executes exactly one physical raw counter update, and only then mints the chip and host signatures over the root advance message.
Because witnesses come into existence only after the irreversible physical counter step, single use of the host witness is a physical timing property of the hardware counter, rather than a confidentiality property of host storage. Under enrolled firmware, a single physical appliance cannot mathematically or physically emit two distinct valid offline releases from the same origin, ensuring that disconnected first contact receivers are completely protected against double spending.
