Skip to content
This repository was archived by the owner on Sep 4, 2026. It is now read-only.

Latest commit

 

History

History
84 lines (70 loc) · 5.67 KB

File metadata and controls

84 lines (70 loc) · 5.67 KB

Data Collection Methodology

The Fundamental Claim

ZWISERFIT node data is different from all other "behavioral data" because it is collected at a physical access gate, not from a phone sensor. This single architectural difference makes the data unforgeable at scale.

Collection Pipeline

┌─────────────────────────────────────────────────────────────┐
│                    PHYSICAL LAYER                            │
│  Member arrives → Face recognition gate                     │
│                  → Liveness check (blink/movement detection) │
│                  → Match against DID-registered biometric    │
│                  → Turnstile opens (physical gate event)     │
└─────────────────────────┬───────────────────────────────────┘
                          │ "gate open" event
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                    SENSOR LAYER                               │
│  15-sensor array tracks exercise session:                    │
│  → Weight × Reps × Sets (resistance equipment)              │
│  → Heart rate (wearable or contact)                         │
│  → Duration (gate-in to gate-out)                           │
│  → Movement velocity (optical tracking)                     │
│  → Rest intervals between sets                              │
│  → Calorie expenditure (computed from sensor fusion)        │
└─────────────────────────┬───────────────────────────────────┘
                          │ raw session data
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                    ATTESTATION LAYER                          │
│  Session data bundled → SHA-256 hash                        │
│  Hash timestamped → Attested to ZWF-20 protocol             │
│  Hash chain provides tamper-evident audit trail              │
└─────────────────────────┬───────────────────────────────────┘
                          │ attested data
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                    AGGREGATION LAYER                          │
│  Raw data → MPC enclave → Aggregate statistics computed     │
│  Only aggregates leave the enclave                          │
│  Raw data stays encrypted in local storage                  │
└─────────────────────────────────────────────────────────────┘

Anti-Spoofing Mechanisms

Attack Vector Mitigation Verification Method
Video replay on face gate Liveness detection (3D depth + micro-expression) Real-time on device
Device ID emulation Multi-sensor cross-validation across 15 channels Session coherence check
Session fabrication Gate event + device event + hash chain must all align Hash inconsistency = rejection
Member collusion DID-signed authorization per session; dual biometric for new registrations DID signature verification
Data tampering after capture Hash chain provides tamper-evident history Full chain re-computation on audit

Why This Is Hard to Fake

To forge a single fake session, an attacker would need to:

  1. Bypass a biometric face gate (liveness detection active)
  2. Physically pass through a turnstile (logged by independent hardware)
  3. Operate exercise equipment to generate sensor patterns that match a real session
  4. Generate a valid DID signature for the purported member
  5. Ensure the hash chain for this fabricated session is consistent with all other sessions

To forge sessions at scale, the attacker would need to repeat this process for every fake session — no "factory reset and replay" attack works because each session is tied to a unique physical event at a unique timestamp.

Result: ZWISERFIT data achieves a level of verifiability that no phone-sensor-based system can match. This is the hardware attestation moat.

Data Completeness

Since the hardware attestation system was deployed (2020), the capture rate has been 100% — every member who passed through the gate is recorded. There is no opt-in/opt-out bias because the gate is the only entry point. The only missing data would be from a complete system outage (gate offline), and those periods are documented in node-health records.

Node Specification

Component Detail
Location 惠鑫万江新村店, Dongguan, Guangdong
Deployment 2020 (hardware attestation layer installed)
Total members served 192+ (cumulative, 2019-2026)
Active members 105 (2026)
Sensor array 15 independent channels
Hash protocol ZWF-20 v0.1
Node status Live — see node-health.json