TrustRide

• 

  Landing Page

• 

  Dashboard

• 

  AuditLeger

• 

  Vechiclesimulator

Inspiration

In July 2026, an app called BAT-BMS went viral in India for one reason: anyone within Bluetooth range could remotely cut power to a moving e-rickshaw. Cheap battery management systems accept unauthenticated BLE connections — no PIN, no pairing, no signature. The government banned the app within days.

But BAT-BMS wasn't built as an attack tool — it was a legitimate utility, used by NBFC financiers to remotely disable a vehicle over an unpaid loan. The ban fixed the exploit that made headlines. It didn't fix what made the exploit possible: even a fully legitimate remote shutdown has no authentication, no motion-safety check, and no accountability trail. That gap doesn't disappear when the news cycle does.

What it does

TrustRide replaces informal, unauthenticated remote shutdown with a decentralized, zero-trust cryptographic command verification pipeline:

• The backend is untrusted by design — it relays commands but cannot sign or execute them, even if fully compromised.
• Every command is signed with real ECDSA P-256 signatures and verified independently on the vehicle's ECU against a pre-provisioned trust store.
• A motion-safety interlock holds any command issued while the vehicle is moving — power is cut only once velocity reaches exactly 0 km/h.
• Every event is written to a SHA-256 hash-chained audit ledger — tamper-evident by design, not just by policy.

How we built it

Next.js/TypeScript frontend, Node/Express backend, Node's native crypto module for ECDSA signing and verification — no external crypto libraries. The verification engine runs five sequential checks in strict order: signature → expiry → replay/nonce → hash-chain anchoring → motion interlock. Any failure halts the pipeline immediately and logs a REJECTED event.

Challenges we ran into

Making the demo honestly represent what's simulated vs. real was harder than the crypto itself — it would have been easy to let the UI imply hardware security that doesn't exist yet. We chose to label every simulated component explicitly (the HSM banner, the architecture tab) rather than let a polished UI oversell the current build.

We also had to decide how "tamper recovery" should work on the audit log. Our first instinct — rewriting a tampered entry back to its original state — quietly contradicted the entire premise of a tamper-evident ledger. We changed it to append a new corrective block instead, leaving the tampered entry visibly flagged rather than erased.

Accomplishments that we're proud of

A fully working, not just described, verification pipeline: real signature checks, real replay/expiry rejection, a real hash-chained log that visibly breaks when tampered with and visibly recovers via an honest corrective mechanism — not a mocked demo.

What we learned

The deeper problem was never "Bluetooth is insecure." It's that no one — driver, financier, or regulator — currently has a safe, accountable way to remotely disable a vehicle. Fleet telematics already solved motion-safe shutdown for an owner disabling their own asset. Nobody has solved it for the adversarial case: a third party disabling someone else's vehicle, with proof of who authorized it and why.

What's next for TrustRide

• Physical Secure Element integration (moving from simulated to hardware-backed keys)
• A retrofit gateway pilot with a design-partner NBFC
• Extending the same governance layer beyond e-rickshaws to e-two-wheelers and fleet EVs

Built With

• cryptography
• ecdsa
• express.js
• framer-motion
• javascript
• lucide-react
• nextjs
• node.js
• react
• render
• rest-api
• sha-256
• tailwindcss
• typescript