Anatomy of a key management protocol

Overview

This page discribes the Hexabus key management protocol. As the name suggests, this protocol is used for the initial synchronization of a new device with a network (called pairing), and for resynchronization of devices that haven't been active in the network for a long time. The protocol further specifies how encryption keys for the network are generated, how key rollover takes place, and how devices may drop out of the network.

Key generation will be described first, then the initial key exchange protocol that runs in parallel with 6LoWPAN on the Hexabus network, and finally how key rollover works. Since encryption and authentication in a Hexabus network is implemented with IEEE 802.15.4 link layer security, crypto primitives are not described here; refer to the standards document (version 2011) for the relevant descriptions.

Key generation and use

In IEEE 802.15.4, encryption keys are also used for authentication, so this protocol concerns itself only with encryption key generation.

Encryption keys for the network are generated using two global properties of the network, and another local property of the device that generates the keys. To the network, we assign one global, constant master key from which all encryption keys are derived, and a global key epoch that describes the oldest key the network will consider valid. Each device MUST keep a copy of these two parameters. Additionally, each device maintains a local key epoch offset that indicates how many keys the device has skipped due to key rollover or other events.

Keys are described by a 64 bit number, the key index. The key epoch of the network is itself a key index, precisely: the key index of the oldest valid key in the network. For any network, the key epoch MUST NOT decrease to avoid key reuse. In any given network, up to 127 keys may be valid at once, where the lowest key index MUST be the key epoch of the network. If a network has multiple valid keys, these keys MUST have consecutive indices.

The key for a given key index is generated by zero-extending the key index to a 128 bit large unsigned integer and encrypting this 128 bit integer with the network master key. For a given key index n, the resulting key is called K(n). Each device MUST be able to receive frames encrypted with K(key epoch + o), where o ranges at least from 0 to 2. If the device has a non-zero key epoch offset, o ranges at least from 0 to (key epoch offset) + 2.

One device in the network (called the master) generates the master key and other network parameters. This device is responsible for distribution of the master key to devices that wish to join the network and may perform other network management duties as required.

Key exchange protocol

The purpose of the key exchange protocol is to distribute the master key among device that wish to join the network. The key exchange protocol must coexist with 6LoWPAN, and after key exchange has been completed, allow a device to send frames to the network, and to receive and successfully decrypt valid frames from the network.

6LoWPAN specifies the first byte of each frame to be the dispatch value that indicates how 6LoWPAN should process the frame (see RFC 4944). Values 0 to 63 indicate that the frame is not a 6LoWPAN frame, thus the protocol must use a value in this range as the first byte of every frame. The value 1 was chosen to identify a frame as a key exchange frame because the 1 key is easy to reach.

Key exchange is devided into two phases: query and response. In the query phase, a device that wishes to join a network sends an unencrypted request frame with the following format to the broadcast PAN ID:

struct request_frame {
  u8 tag = 1;
  u8 frame_type = 0;
};

If any master wishes to let the device joins its network, it responds to the requesting device with an unencrypted response frame:

struct response_frame {
  u8 tag = 1;
  u8 frame_type = 1;
  u16 pan_id;
  u8 key[16];
  u64 key_epoch;
};

In the response frames, the pan_id and key_epoch fields are encoded in big endian byte order. pan_id contains the PAN ID of the network the responding master device manages. key contains the master key of the network, key_epoch contains the key epoch of the network.

After a successful key exchange, the requesting device SHOULD store the received parameters in nonvolatile memory if the device wishes to join the advertised network. If it joins the network, it MUST cease sending unencrypted frames. The first key used by the devices SHOULD be K(key_epoch).

Key rollover

If at any point in time a device (including the master) decides that the key it currently uses to encrypt frames should be no longer valid, or because the frame counter associated with the key has reached 0xFFFFFFFF, they device MUST increment its key epoch offset and cease sending frames with earlier keys.

Upon reception of a frame, every device in the network SHOULD check whether the key used to encrypt the frame has a larger key index than the key the receiving devices uses to encrypt outgoing frames. If the incoming key has a larger index, the device SHOULD discontinue its current outgoing key and use the newer key instead, possibly skipping some valid key indices in the process. Once a device discontinues a key (for any reason) and switches to a key with a larger key index, the device MUST NOT reuse keys of lower key index than the key it switched to. (This is similar to the handling of frame counters in the network: a device MUST NOT reuse frame counters for outgoing frames, and similarly, it MUST NOT reuse key indices. To keep implementations simple, both the frame counters and the key indices are specified as monotonically increasing.)

Once every device in the network has proven that it can transmit and receive frames with a key with larger index than the key epoch, the key epoch SHOULD be increased to the smallest key index larger than the key epoch that is in use. From this point on, each device MUST also assume that the key epoch of the network has advanced accordingly, and reduce its local key epoch offset to match the increase.

A device MUST NOT increase its local key epoch offset beyond 127. If 127 keys are valid in the network, it is the master's responsibility to advance the key epoch accordingly. The master does this by deleting devices from the network that use only the oldest key (K(key epoch)) and advances the key epoch the the smallest key index that is otherwise in use in the network. If the master used a key that has been thus skipped, the master MUST use a key at or after the key epoch. Devices recognize that such an epoch modification has taken place (and that further rollovers are again allowed) by reception of frames that would otherwise cause the device to increase its key epoch offset beyond 127. The difference between the (projected) key epoch offset and 127 as the number of keys skipped by the epoch adjustment, and the device MUST also adjust its copy of the key epoch accordingly.