Skip to content

Attacks on multi-link Wi-Fi key handling: none accepted by the lab's rule, all accepted by a naive one

Of 755 probes, the lab's multi-link key rule accepted none; a naive control accepts all 755, which shows the probes do reach the surface they aim at.

The newest Wi-Fi generation lets one device use several radio links at once, called multi-link operation (MLO). Each link needs its own keys, and a device must refuse keys that belong to another link or to an older set of links. The lab aimed a batch of attack probes at the parts of this key handling that its earlier models did not cover, and ran each through its checker.

What it shows

In multi-link operation one device holds keys for several links at once, and the set of links can change. A key that is valid on one link, or for an earlier set of links, must not be accepted on another. Mistakes here let an attacker replay or reuse key material where it does not belong.

The probes and the control

The lab listed surfaces of this key handling that its earlier models had not covered, and generated attack probes aimed at them. Each probe was judged by the lab's checker, fixed before the run. The lab's rule, which ties each key to its link and to the current set of links, accepted none of them.

A zero on its own could mean the probes never touched anything. So the lab also ran a naive control, a version without that rule, and the control accepted every probe. That is what makes the zero meaningful: the probes reach the surface, and the rule is what stops them.

Why it matters, and to whom

This is for Wi-Fi chip and access-point makers adding multi-link operation, and for test labs that check their key handling. Key-installation bugs in Wi-Fi have a long public history, and multi-link operation adds new state to get wrong. A probe battery with a control that fails is the kind of test a design team can run on its own rule before it ships.

How it was checked

The evidence file names the command that runs the probes and the control, and records its run on a clean copy of the code.

Testing the check

The lab tested the check by breaking it on purpose. In one test the key check stopped tying keys to the current set of links, and a replay from an older set was accepted, so the check failed. In another, the probes were driven over fewer links, the probe count fell, and the check failed again. The evidence file also records a correction: an earlier test that shortened the probe schedule did not change the count at all, so it shows nothing, and the lab says so.

What it does not claim

  • It does not claim that no attack on multi-link key handling exists. The search covers the dimensions the lab encoded, within a logged budget; the lab's limits say a dimension nobody encoded is still untested.
  • It does not claim anything over the air. The probes ran against the lab's models in software, judged by its own checker, and no third party graded them.
  • It does not claim that the test method is new. Per-link key management is part of the standard's multi-link design, as Arista's white paper describes, and probing key handling with attack tools is standard practice; Vanhoef's public tools test real clients and access points for key reinstallation and fragmentation attacks. What the lab adds is a measured result for its own rule, with a control that shows the probes can succeed.

How to reproduce it

The evidence file names the command and the commit of the lab's code. A stronger test would run the same probes against a real multi-link access point and client, or add attack dimensions the generator does not yet encode and see whether the rule still holds.

Prior art

Evidence

Related results across the group

All results from OrbitalProof · The OrbitalProof home page

How we show numbers

Every result figure links to the file it comes from. See our published files