Bluetooth Mesh Private Beacons: Balance Discoverability with Tracking Resistance

Mesh privacy has several independent controls. Changing the Bluetooth advertiser address does not automatically replace clear network discovery information, enable private proxy discovery or restrict how long a proxy remains discoverable. Qualify those behaviors as separate states.

Applicability: historical Bluetooth Mesh Protocol 1.1 private-beacon and proxy procedures, with Zephyr 4.2.0 solicitation receive behavior identified explicitly. The lab configuration and observations below are proposed, not executed. Use synthetic lab identities and authorized devices; this is not a procedure for tracking people.

Mesh private beacon random updates are separate from private proxy advertising; an authenticated replay-checked solicitation opens a bounded discovery window, distinct from private node identity.
Original privacy-state diagram. The 20-second and 30-second cases are hypothetical configurations, not measured behavior or privacy guarantees.

1. Inventory the observable message types

Start with a capture inventory grouped by message type and subnet. A Mesh Private beacon, a connectable Private Network Identity advertisement and a Private Node Identity advertisement serve different purposes. A product can support one while leaving another disabled.

Section 3.10.4 defines a Mesh Private beacon with a 13-octet Random field, five octets of obfuscated flags/IV Index and an eight-octet authentication tag. Unlike the Secure Network beacon format, it does not carry a clear Network ID field.

Known subnet key material lets the receiver authenticate and interpret the private beacon. This remains network-state signaling; it is not itself an invitation to connect to the Mesh Proxy Service.

Private Network Identity instead uses Mesh Proxy Service Data identification type 0x02 with an eight-octet Hash and eight-octet Random. Private Node Identity uses type 0x03. Record the service-data type rather than treating every changing byte string as the same privacy mechanism.

2. Build a configuration matrix before testing roaming

Control Engineering question Important interaction
Private Beacon Are private network-state beacons enabled? Random-update cadence is a separate state
Private GATT Proxy Is ongoing private proxy discovery enabled? Ordinary GATT Proxy must be disabled to enable it
Private Node Identity Is a particular subnet’s node-discovery window active? Ordinary Node Identity must be disabled on all subnets
On-Demand Private GATT Proxy Can valid solicitation open a discovery window? Zero disables the trigger; nonzero specifies seconds

Read actual supported states before setting policy. “Not Supported” is distinct from “Disabled.” A configuration manager must not repeatedly request a prohibited transition and then display its desired value as effective state.

The binding rules in sections 4.2.45–4.2.47 matter during migration. Enabling ordinary GATT Proxy forces Private GATT Proxy disabled. Enabling ordinary Node Identity on any subnet forces Private Node Identity disabled for every known subnet.

Define the intended mode for a stationary node, a mobile maintenance client and a physical identify interaction. Roaming does not require abandoning private discovery; it requires the client to recognize authorized subnet advertisements and handle a new connection lifecycle.

3. Separate random rotation from advertisement cadence

Random Update Interval Steps controls the Random field of Mesh Private beacons. Zero means regenerate for every private beacon. Values 1 through 255 express ten-second units; the specified default is 60, or ten minutes.

A hypothetical value of two therefore represents a 20-second random-update interval. It does not command one beacon every 20 seconds. Private-beacon transmission has its own traffic-observation and interval behavior.

Flags or IV Index changes also require a new private-beacon Random value, and each private beacon sent to a Proxy Client requires regeneration. When advertised, AdvA must be a resolvable or non-resolvable private address and change whenever that beacon Random changes; addresses differ per subnet.

Private Network Identity has its own Random field and update guidance. Do not copy the private-beacon step value into a proxy-advertising timer and assume the standard couples them. Capture message type, Random and AdvA separately.

4. Make on-demand discovery an authenticated transition

Section 6.9.2 requires the applicable proxy modes to be disabled, a nonzero On-Demand Private GATT Proxy state and a Solicitation PDU authenticated with a known network key. Solicitation replay protection checks source and sequence state before accepting the trigger.

The Zephyr 4.2.0 receive path returns early when ordinary GATT Proxy is enabled, Private GATT Proxy is enabled or the on-demand state is zero. It then validates the advertisement structure, authenticates against subnet keys and checks the solicitation replay list before marking the subnet solicited.

These gates prevent a product controller from treating arbitrary visible solicitation-shaped data as permission to open discovery. Keep the replay state under the stack’s supported persistence policy; clearing it to make a repeated lab packet work invalidates the replay test.

For a hypothetical on-demand value of 30, a valid solicitation opens the specified 30-second discovery interval. The response advertises Private Network Identity for the subnet that authenticated the solicitation. It stops upon GATT connection, or after the interval without a connection while Private Proxy functionality remains disabled.

Do not confuse that window with Private Node Identity’s separately specified 60-second timer. An identify interaction and a solicitation are different triggers, even if both eventually produce a GATT connection.

5. Treat connection privacy as connection-scoped state

Section 6.7 establishes a Proxy Privacy parameter when the connection is made and retains it for that connection’s lifetime. A mid-connection policy change is therefore not evidence that the existing connection has switched every privacy behavior.

Use a controlled disconnect/reconnect boundary when qualifying a new advertised mode. After reconnection, verify bearer readiness and required destination filtering independently. Discoverability proves only that a suitable server could be found, not that application messages are now deliverable.

Inspect the rest of the advertising payload too. A permanent product serial or unique label can support correlation even when the Mesh fields and AdvA rotate correctly. Field rotation is measurable; anonymity against every observer is not a justified product claim.

6. Run a privacy-and-discovery observation fixture

  1. Record supported states and read back the intended ordinary/private proxy settings.
  2. Enable private beacons with the hypothetical two-step interval. Observe Random and AdvA transitions without interpreting the interval as packet cadence.
  3. With both proxy modes disabled and on-demand value 30, send an authorized fresh solicitation and observe only the authenticated subnet’s discovery response.
  4. Replay that solicitation and try an invalid authenticator; verify neither creates a fresh accepted trigger.
  5. Repeat with on-demand zero and with ordinary proxy enabled; verify the selected mode’s different behavior.
  6. Connect during the window, then repeat with no connection. Verify the respective stop conditions.
  7. Move the authorized client between lab nodes and verify discovery, new connection setup and application readiness separately.

Keep nonsecret state transitions, temporary test identifiers and bounded captures. Acceptance requires correct configuration bindings, authenticated trigger handling, explainable rotation and a usable discovery path, without claiming that one privacy setting eliminates every correlation channel.

Similar Posts