Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Require authenticated pairing before security-sensitive commands

Open
  • Is something wrong?
#74 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
authentication, embedded-iot, security

Research direction

Start by reading docs/ble.md and checking the pairing and command handling entry points in the firmware, then investigate what trouble-host supports for authenticated pairing. The issue leaves the sensitive command list, pairing method, and existing bond behavior open, so those decisions need to be resolved with the related app and contracts work. Done means Just Works bonds cannot run sensitive commands and the chosen method is documented in docs/ble.md.

Written by the indexing model from the issue text.

Description

enhancement

Part of the prerequisites for real commands (tracking issue to follow). Related: #54, #9, mobile-app#25, contracts#8.

Problem

BLE bonding is Just Works, which has no protection against a stranger. While a pairing window is open (60 s with a button, or the first-setup window on a buttonless board), any phone in range can bond. #46 and #53 shrank the window, but they don't authenticate the phone. A bonded phone can later send any BLE command, including ones that unlock the car or open the trunk.

That is acceptable for harmless commands such as flashing the lights or climate control. It is not for door unlock, trunk or frunk.

Proposal

  • Classify commands as security-sensitive somewhere both sides read (a proto option or meta.toml; this overlaps with the delivery kind in contracts#7 and availability in contracts#13). This is a contracts change.
  • The firmware rejects security-sensitive commands unless the phone's bond was made with MITM protection (LE Secure Connections with passkey entry, numeric comparison or out-of-band data).
  • The WiCAN has no display or buttons, so the options are limited. Candidates: a passkey provisioned at setup and shown to the owner; out-of-band data carried in a QR code scanned by the app; or confirming a new phone with a pattern on the LED. The same applies to the way the window is reopened in #54, so decide them together.
  • Check what trouble-host supports before choosing.

Open questions

  • Which commands count as security-sensitive?
  • What happens to phones already bonded with Just Works (re-pair, or limited to non-sensitive commands)?
  • Does the app need a state for "paired, but not authenticated"?

Done when

A bond made with Just Works can't run security-sensitive commands, the chosen pairing method is documented in docs/ble.md, and a stranger who bonds during a window can't unlock the car.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
12h 49m
Merged PRs (30d)
19

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenCarControls/firmware

All issues in OpenCarControls/firmware

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.