Why Obfuscation Exists

Every Bluetooth Mesh network PDU carries a TTL (time-to-live), a sequence number (SEQ), and a source address (SRC) in its header. Without any protection, a passive sniffer sitting nearby can watch these fields and track which device sent which message — a simple privacy leak.

The spec’s answer is obfuscation: XOR those header fields with a pseudo-random pad derived from a Privacy Key, so an eavesdropper sees only scrambled bytes. Note that this is not encryption — it is designed only to stop passive tracking, not a determined attacker with the Privacy Key.

The Obfuscation Flow Step by Step

What the Network PDU Looks Like On-Air

How a Receiver Reverses Obfuscation

The receiver already knows the IV Index from the network and holds the Privacy Key. It just repeats the same steps (PrivacyRandom → Privacy Plaintext → PECB) and XORs the ObfuscatedData again to recover the original CTL, TTL, SEQ, and SRC. XOR is its own inverse.

Why the IV Index Is Part of This

If someone tries to break obfuscation by collecting lots of PDUs, they eventually succeed — but only until the IV Index changes. When the network increments the IV Index (a normal mesh event), every obfuscation attempt the attacker has built must restart from zero.

BlueZ Reference — Where Obfuscation Happens

In the BlueZ mesh stack, network layer obfuscation is implemented in mesh/net.c:

/* mesh/net.c  — BlueZ mesh stack (simplified) */

/* Build the Privacy Plaintext: 5 zero bytes + IV Index + PrivacyRandom */
static void build_privacy_plaintext(uint32_t iv_index,
                                    const uint8_t *privacy_random, /* 7 bytes */
                                    uint8_t *out)                  /* 16 bytes */
{
    memset(out, 0, 5);                           /* octets 0-4: zeros      */
    l_put_be32(iv_index, out + 5);               /* octets 5-8: IV Index   */
    memcpy(out + 9, privacy_random, 7);          /* octets 9-15: PrivRandom*/
}

/* Derive PECB using AES-128 with the Privacy Key */
static void derive_pecb(const uint8_t *privacy_key,   /* 16 bytes */
                         const uint8_t *plaintext,     /* 16 bytes */
                         uint8_t *pecb)                /* 16 bytes out */
{
    aes_ecb_one(privacy_key, plaintext, pecb);
}

/* XOR the 6-byte header with PECB[0..5] to produce ObfuscatedData */
static void obfuscate_header(const uint8_t *pecb,
                              uint8_t *hdr,   /* CTL|TTL|SEQ(3)|SRC(2) = 6 bytes */
                              uint8_t *out)
{
    int i;
    for (i = 0; i < 6; i++)
        out[i] = hdr[i] ^ pecb[i];
}

ℹ️ aes_ecb_one() is BlueZ’s thin wrapper around the kernel’s AES-128 ECB. The real production code also handles the PrivacyRandom extraction from the encrypted payload bytes.

What Is a Replay Attack?

Imagine Node A turns on a smart light by sending a “Light ON” message. A nearby attacker silently records this valid, properly encrypted packet. Later, after Node A has turned the light off, the attacker re-transmits the exact same captured packet. The light turns on again — the attacker never broke any crypto, they just replayed an old message.

The Solution: Sequence Numbers + IV Index Tracking

Every element (a logical endpoint inside a node) increments its sequence number for every new message. The receiver maintains a Replay Protection List — a simple table of (source address → last accepted SEQ, last accepted IV Index) pairs.

Segmented Message Replay — The Tricky Case

A large message gets split into numbered segments, each carrying its own SEQ value. The spec says: store the highest SEQ seen for that source. When the attacker re-injects an old segment, the node notices its SEQ is below the stored maximum and drops it. The diagram below maps to Figure 3.43 in the spec.

BlueZ — Replay Protection List Lookup

In BlueZ mesh/net.c, replay protection is checked before any access-layer processing:

/* mesh/net.c — BlueZ mesh (simplified illustration) */

struct replay_cache_entry {
    uint16_t src;       /* source element address             */
    uint32_t seq;       /* highest accepted sequence number   */
    uint32_t iv_index;  /* IV Index for the above seq         */
};

static bool replay_check(struct mesh_net *net,
                          uint16_t src,
                          uint32_t seq,
                          uint32_t iv_index)
{
    struct replay_cache_entry *entry = find_replay_entry(net, src);

    if (!entry) {
        /* First message from this source — always accept */
        add_replay_entry(net, src, seq, iv_index);
        return true;  /* not a replay */
    }

    /* Discard if IV Index is lower */
    if (iv_index < entry->iv_index)
        return false;

    /* New IV Index: accept and reset */
    if (iv_index > entry->iv_index) {
        entry->iv_index = iv_index;
        entry->seq = seq;
        return true;
    }

    /* Same IV Index: accept only strictly higher SEQ */
    if (seq <= entry->seq)
        return false;   /* replay detected — discard */

    entry->seq = seq;
    return true;
}

ℹ️ In a real device with limited RAM, this list has a fixed maximum size. If it is full and cannot track a new source address, the spec requires discarding the message rather than risking a replay vulnerability.

What Are Mesh Beacons?

Before two Bluetooth Mesh nodes can talk securely, they must find each other and exchange trust. Mesh beacons are small BLE advertising packets that nodes and unprovisioned devices broadcast periodically for this purpose. They are sent as non-connectable, non-scannable undirected advertising events — the receiver just passively listens; no connection is formed.

Beacon Packet Structure

The Two Beacon Types

Beacon Endianness

All multi-byte numeric fields inside mesh beacons are transmitted in big-endian order — the most significant byte first. This is consistent throughout the mesh spec.

BlueZ — Sending an Unprovisioned Device Beacon

In BlueZ mesh/prov.c, an unprovisioned node starts advertising its beacon like this:

/* mesh/prov.c — BlueZ (simplified) */

#define MESH_AD_TYPE_BEACON  0x2B

/* Build the Unprovisioned Device Beacon payload */
static void build_unprovisioned_beacon(struct mesh_node *node,
                                        uint8_t *buf,
                                        size_t *len)
{
    uint8_t *p = buf;

    *p++ = 0x00;                       /* Beacon Type: Unprovisioned (0x00) */

    /* Device UUID — 16 bytes, identifies this specific device */
    memcpy(p, node->uuid, 16);
    p += 16;

    /* OOB Information — 2 bytes big-endian */
    l_put_be16(node->oob_info, p);
    p += 2;

    /* URI Hash — 4 bytes, only present if the URI flag in OOB Info is set */
    if (node->oob_info & OOB_URI_FLAG) {
        l_put_be32(node->uri_hash, p);
        p += 4;
    }

    *len = p - buf;
}

/* Kick off advertising with this beacon */
static void start_unprovisioned_beacon(struct mesh_node *node)
{
    uint8_t buf[23];
    size_t len;

    build_unprovisioned_beacon(node, buf, &len);
    mesh_send_beacon(MESH_AD_TYPE_BEACON, buf, len);  /* BLE adv. non-connectable */
}

ℹ️ mesh_send_beacon() ultimately calls BlueZ’s btd_adapter_set_adv_data() with a non-connectable, non-scannable advertising type (ADV_NONCONN_IND).