Bluetooth Mesh Key Refresh: Plan for Nodes That Miss a Phase
Plan Mesh Key Refresh around a per-node evidence ledger, not a single network-wide progress percentage. A node that missed new-key distribution is fundamentally different from one that has both keys but missed a phase signal. Advancing to revocation without distinguishing them can remove a device that was meant to remain.
Applicability: historical Bluetooth Mesh Protocol 1.1 Key Refresh and Zephyr 4.2.0 subnet/application-key implementation. The proposed matrix uses synthetic key-generation labels, never key values. No keys were generated, distributed or revoked, and no live mesh was modified.
1. Define the retained cohort before distribution
The Key Refresh procedure lets the Configuration Manager select which nodes receive the new NetKey and associated updated AppKeys. Nodes that do not receive them are effectively excluded when old keys are revoked.
Write an explicit retained-node set and an explicit excluded-node set for each affected NetKeyIndex. An unreachable required node belongs in an unresolved state, not silently in the excluded set. Decide who may approve exclusion when a device cannot be recovered.
Track NetKeyIndex, AppKeyIndex, bound relationship, logical key generation, node identity and observed phase. Use nonsecret administrative generation labels. A phase value of zero alone is ambiguous: it describes normal operation before refresh and normal operation after revocation with a different key generation.
Key Refresh is independent of IV Update. Changing an IV Index does not distribute a missing NetKey, and refreshing a NetKey does not repair unsafe IV/sequence state. Maintain separate procedure records even when both occur during the same maintenance window.
2. Distinguish transmit keys from receive keys
| Node state | Transmit | Receive messages |
|---|---|---|
| Normal before distribution | Old | Old only |
| Phase 1: new key stored | Old | Old or new |
| Phase 2 | New | Old or new |
| After Phase 3 revocation | New | New only |
This table describes key compatibility, not guaranteed end-to-end delivery. Model bindings, subscriptions, AppKey compatibility, relays and radio reception still matter. Beacon acceptance has additional phase-specific rules; do not apply the message column indiscriminately to every beacon.
A hypothetical old-only node can send an old-key message that a Phase-2 node can authenticate, while being unable to authenticate that node’s new-key reply. One-way observations therefore do not prove that the old-only node is ready for revocation.
NetKey and AppKey evidence must be separate. The specification preserves an AppKey that has not been assigned a new value when its NetKey is updated. That permitted behavior does not satisfy a security plan that explicitly requires that AppKey to rotate.
3. Make Phase 1 a distribution barrier
Send Config NetKey Update and required Config AppKey Update operations through the authorized Configuration Manager. Correlate status responses to the intended node and indices, and retain pending or failed results.
Do not treat a successful local send or a segmented-transport acknowledgment as proof that the sleeping target processed a key update. The specification calls out low-power-node latency and allows PollTimeout information from its Friend to guide retries after an on-behalf-of acknowledgment.
Before moving the retained cohort to Phase 2, establish that every selected node received its required material. Use bounded retries and a recovery decision for unresolved nodes. The deadline for a maintenance window is a product policy, not permission to skip the distribution barrier.
Zephyr 4.2.0 bt_mesh_subnet_update accepts a different key to start refresh from Normal and accepts repetition of the same new key in Phase 1. It rejects incompatible updates in later phases. Retry the intended operation under its state contract; do not generate a different replacement key on each timeout.
The AppKey update implementation also requires the associated subnet to be in Phase 1. Record this ordering so a delayed AppKey job cannot run after the coordinator has advanced the subnet.
4. Handle a node that missed a phase signal
A node that already has the new material can often follow a later authenticated transition. In Mesh 1.1, a Phase-1 node receiving a beacon secured with the new NetKey and Key Refresh Flag zero moves directly to Phase 3, skipping Phase 2.
This is a defined recovery path for a missed signal, not a way to recover a key it never received. An old-only node cannot authenticate that new-key beacon. Keep “material missing” and “phase signal missed” as different fault categories.
The exact Zephyr bt_mesh_kr_update returns without transitioning for old-key evidence. With new-key evidence, Phase 1 selects Phase 2 or revocation according to the flag, and Phase 2 can revoke when the flag clears. This distinction prevents a bare flag bit from becoming sufficient authority.
Before ending Phase 2, the Configuration Manager determines that the nodes which received new keys are in Phase 2. A node temporarily absent from observation needs explicit reconciliation; do not infer its state from another node’s beacon.
5. Treat revocation as a forward transition
Phase 3 removes old material and returns the Key Refresh state to zero. In the tagged subnet implementation, the new key slot replaces the old slot and the alternate slot is invalidated. Updated AppKeys follow the corresponding revocation event.
A manager crash must not restart distribution blindly or call phase zero a rollback. Reconcile the persisted operation ledger with queried node state and the intended generation. Preserve uncertainty when observations cannot distinguish pre-refresh Normal from completed Normal.
After revocation, an old-only device requires an authorized recovery or reprovisioning plan. Reintroducing the retired key to rescue it would undermine the exclusion objective. Protect backups and provisioning records under the same security policy.
6. Test interrupted refresh with a node-state matrix
- Lose one Phase-1 status response, then retry the same material: verify idempotent state-aware handling.
- Keep one required node offline during distribution: verify the coordinator does not silently declare the retained cohort ready.
- Give a node both keys, then let it miss Phase 2: verify the authenticated new-key flag-zero path.
- Leave a node old-only while others reach Phase 2: demonstrate directional compatibility without mislabeling it healthy.
- Restart the manager during each phase: verify ledger reconciliation and no accidental key-generation replacement.
- Refresh one subnet while another remains unchanged: verify per-NetKey isolation.
- Omit a required AppKey update: verify that network-layer communication does not falsely satisfy application readiness.
Acceptance requires retained nodes operating with the intended new material, excluded nodes unable to use retired credentials, and an auditable explanation for every unresolved node. Count demonstrated state, not commands sent.
