Harden BLE pairing and actually revoke removed phones
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 34/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- embedded-iot, security
Research direction
Read boards/esp/src/lib.rs:80 and the bond management and disconnect handling in ble/transport.rs, especially around line 521; trace how BondStore and the controller lists are updated. The issue identifies several separate security behaviors, including phone revocation, normal disconnect handling, and bond limits. Done means removed phones can no longer connect and ordinary disconnects do not erase bonds; pairing limits and the separate issue linked for Just Works pairing also need review.
Written by the indexing model from the issue text.
Description
- Revocation doesn't work. On ESP,
RemovePairedPhone/ClearPairedPhones
(boards/esp/src/lib.rs:80) only edit the in-memoryPAIRED_PHONESlist,
which nothing on ESP uses for authorization. The real credentials (LTKs in
BondStoreflash plus the controller filter-accept/resolving lists) are
untouched, so a removed phone still connects. Remove the bond via
stack.remove_bond_information,BondStore::remove_bondand
remove_bond_from_controller(all exist inble/transport.rs), and drop the
separate registry or make it the source of truth. - Just Works pairing and the boot-time window on buttonless boards: https://github.com/OpenCarControls/firmware/issues/18.
- Auto-heal is too aggressive.
ble/transport.rs:521treats
REMOTE_USER_TERMINATED_CONN(a normal phone disconnect) as a security
failure, so any disconnect during the pairing window wipes that phone's bond. max_bonded_phonesisn't enforced on BLE bonds (the store is hard-capped at 8).- Later: LTKs are stored unencrypted in flash (flash encryption).
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- Avg merge
- 13h 37m
- Merged PRs (30d)
- 8
Getting set up
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenCarControls/firmware
-
Refresh stale docsOpen
Difficulty 1/5 1-3 hours Newbie friendliness 67/100
OpenCarControls/firmware#35 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
OpenCarControls/firmware#34 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
OpenCarControls/firmware#31 ·
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
OpenCarControls/firmware#30 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 68/100
OpenCarControls/firmware#57 ·
Maintainers usually reply within 1 day
All issues in OpenCarControls/firmware
Similar issues
-
state:triage-needed
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
bug P2
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
pedrovgs/UseCaseCoverage#23 ·
-
area: library data-loss tier: p0 type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
llm translation
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Maintainers usually reply within 1 day