You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Security: AFK-surf/Hardware
Security
docs/security.md
Security
Pairing. Every board uses LE Secure Connections only (legacy pairing is refused) and requires an
encrypted link before any setup characteristic can be read or written. Screen boards show a random
six-digit passkey (MITM protection). The ESP32 DevKit has no display or keypad, so it pairs with
Just Works: the link is encrypted, but an attacker within Bluetooth range during setup can
intercept it. Physical access (holding BOOT) is required to reopen setup on a configured board, but
that is not cryptographic protection. Set up a DevKit where nobody else is in radio range.
Bluetooth is off on a configured board except in pairing mode, and never on during a call.
Stored credentials are not encrypted. These builds do not enable Secure Boot, flash encryption
or NVS encryption, so anyone holding the board can read its Wi-Fi password, Connector token and
voice key over USB. Both credentials are per device and are revoked when you remove the device in
the app; factory reset erases them.
The gateway is read-only until you allow it. The board itself enforces this: while device
operations are off, it refuses every LAN request without touching the network. Requests may only
go to addresses on the board's own subnet and private ranges, never to the board itself, loopback,
broadcast or multicast addresses.
Changing the workspace, group, backend URLs, Connector token or voice key resets operation
permission; allow operations again in the app. Changing only Wi-Fi or the device name preserves
permission. With compiled-in development credentials, permission lasts only until reboot.
The Bluetooth advertising data uses the test company ID 0xFFFF.