Nexting Devices · Security

How Nexting protects the connection

See exactly where encryption ends, where authorization lives, what reaches the device, and what production hardware must add.

See the trust boundary Return to Quickstart

Nexting security is an encrypted local device link + trusted Host isolation + minimum disclosure + revocable authorization. This page names the controls implemented by the public SDK and the limits a production device must address.

Trust boundary

Layer	Receives and decides	Does not receive or trust
Device	Bounded profile state and physical intent	No Agent credential or account/session route
Trusted Host	Authorization, freshness, risk policy, and Agent mapping	No unauthenticated accessory command
Agent	Only the Host-approved action	Never trusts accessory input directly

These controls are shared by every Agent integration:

Control	Implemented boundary
BLE LE Secure Connections	The local device link uses BLE LE Secure Connections and encrypted GATT permissions for control traffic.
opaque request ID	Agent credentials and internal account or session routes stay on the trusted Host; firmware receives bounded profile data such as an opaque request ID.
single consumption	The Host checks authorization, expiry, sequence/revision, duplicate or replay state, and single consumption.
state and partial-frame clearing on disconnect	Disconnect, reboot, a new bond, reset, or Host revocation clears the applicable volatile state and partial frames.
voice/1	voice/1 controls the Host microphone lifecycle and never carries audio bytes or transcripts.
Just Works	Developer Reference Just Works pairing encrypts the link but production needs authenticated application identity and signed firmware.

Data flow

The Host sends one bounded request. The authorized device answers with one choice; the Host validates and commits it before the Agent continues.

Host → devicejson

{"v":1,"t":"present","id":"r1","sum":"Allow git push?","opt":["allow","deny"],"ttl":30000}

device → Hostjson

{"v":1,"t":"answer","id":"r1","ch":"allow"}

Protected local link

The public Zephyr reference requires BLE LE Secure Connections, bonding, controller privacy, BT_SECURITY_L2, and encrypted GATT permissions for control traffic.

reference security evidencetext

CONFIG_BT_SMP_SC_ONLY=y
CONFIG_BT_BONDABLE=y
CONFIG_BT_BONDING_REQUIRED=y
CONFIG_BT_PRIVACY=y
BT_SECURITY_L2
BT_GATT_PERM_WRITE_ENCRYPT
BT_GATT_PERM_READ_ENCRYPT

Device Info can remain readable for compatibility discovery. A readable device name or capability list never authorizes control.

Authorization and freshness

The Host checks the authorized identity, declared Profile, request expiry, sequence or revision, duplicate and replay state, and single consumption. Unknown, stale, reordered, revoked, or undeclared input fails closed.

Check	Rejected example
Identity	A name-only match or a different bond
Freshness	An expired approval or old config revision
Ordering	A duplicate or replayed sequence
Capability	A key, slot, or Profile absent from Device Info

Minimum disclosure

Firmware receives bounded Profile data such as an opaque request ID, short summary, fixed choices, relative lifetime, label, or volatile state. It receives no Agent credential, internal account/session route, prompt history, or unrestricted tool payload.

voice/1 carries start, stop, and cancel control only. It never carries audio bytes or transcripts; the Host owns microphone permission, recording, and transcription.

State and revocation

Disconnect clears partial frames and volatile approval, status, text, usage, navigation, and voice state. Reboot, reset, a new bond, or Host revocation invalidates the applicable authorization and pending work. The user can forget a device from the Host and remove its bond.

Reference vs production

The Developer Reference uses Just Works pairing. It encrypts the local link but lacks authenticated active-MITM protection during pairing. Production hardware needs authenticated application identity, secure key storage, signed firmware, rollback policy, and a supported revocation path.

Passing the public protocol and firmware checks proves bounded framing and Profile behavior. It does not prove production identity, signed firmware, enclosure security, or a live Agent mapping.

Threats and non-goals

This is not end-to-end encryption between the accessory and Agent: the trusted Host must read, authorize, and map physical intent. The public contract does not claim protection for a compromised Host, physical extraction from an unprotected accessory, or supply-chain compromise.

Threat	Current boundary
Passive BLE capture	Encrypted bonded link protects control traffic
Replay or stale input	Host sequence, expiry, duplicate, and consumption checks
Active MITM at reference pairing	Not authenticated by Just Works; production must add identity
Compromised Host	Outside the accessory protocol trust boundary

Report a vulnerability

Do not open a public exploit issue. Use the private security-reporting path described in the public Nexting Devices SECURITY document and include the SDK version, board/Host versions, reproduction, and impact.

Open the public SECURITY document