Why the Check Value, Not the Radio, Stops MITM

Why the Check Value, Not the Radio, Stops MITM

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

Why the Check Value, Not the Radio, Stops MITM

At the calculator’s default sliders — 10 attempts against 100 devices — Just Works surrenders essentially the whole fleet (about 100 devices, a 99.99990% per-device compromise), while Numeric Comparison’s 6-digit check leaves it at roughly 0.001 devices. The same attacker and the same attempts are separated by a factor near 100,000. This audit rebuilds both sides and asks whether that gap comes from the radio, the range, or the encryption — or entirely from the six-digit human check.

Companion to the chapter BLE Pairing Practice Checks — every number here comes from that chapter.

Try

At the calculator’s default sliders — 10 attempts against 100 devices — Just Works surrenders essentially the whole fleet (about 100 devices , a 99.99990% per-device compromise), while Numeric Comparison’s 6-digit check leaves it at roughly 0.001 devices . Calculate this case.

Observe

The same attacker and the same attempts are separated by a factor near 100,000 . Check shows this.

Explain

Dividing one by the other, 0.9999990463 / 0.000009999955 = 100,000.4: the same attacker, the same 10 attempts, and the same 100 devices, yet Just Works is roughly a hundred thousand times more likely to surrender a device than Numeric Comparison. The defence in that ratio comes entirely from the six-digit human check, not from the radio, the range, or the encryption, which is why Numeric Comparison changes the fleet outcome. Check confirms it.

See the relationship before changing it

The chapter figure below shows: Numeric Comparison Authentication Stage 1: Device A and Device B each choose a random nonce, Device B computes a confirmation value from both public keys and its own nonce and sends it first, the two nonces are exchanged next, Device A verifies the confirmation and aborts on mismatch, both devices then compute a six-digit value from the shared public keys and nonces, and the user compares the two displayed values before pairing proceeds.

Numeric Comparison Authentication Stage 1: Device A and Device B each choose a random nonce, Device B computes a confirmation value from both public keys and its own nonce and sends it first, the two nonces are exchanged next, Device A verifies the confirmation and aborts on mismatch, both devices then compute a six-digit value from the shared public keys and nonces, and the user compares the two displayed values before pairing proceeds.

Derive the baseline in four named moves

1. 1

   Name the input. The chapter baseline is 10 attempts.

2. 2

   Name the relationship. expected = 100 x (1 - (1 - 1/1,000,000)^attempts)

3. 3

   Substitute with units. 100 x chance over 10 tries = 0.001000 devices

4. 4

   Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.

Predict, then change pairing attempts

Try Predict how expected numeric comparison captures responds when pairing attempts moves. Calculate pairing attempts; compare expected numeric comparison captures with that prediction.

Pairing attempts

10 attempts

Chapter baseline

Expected Numeric Comparison captures

Observe Return to 10 attempts. Recheck expected numeric comparison captures with pairing attempts at its chapter value.

Explain The six-digit check keeps the expected fleet loss near zero.

Check yourself

What should you do before trusting a moved-slider result?

Answer: Predict its direction, apply the displayed relationship, keep the units, and compare the reset value with the chapter’s worked baseline.

What does this small model leave out?

Answer: Only pairing attempts moves here. The expected numeric comparison captures calculation excludes field effects listed below.

Honesty note. The expected numeric comparison captures result holds pairing attempts as the only changing input. It is not a field prediction.

Technical boundaries

The expected count fixes the fleet at 100 devices and uses independent guesses of a six-digit comparison value. Human confirmation errors, compromised displays, relay timing, biased randomness, and defects in the pairing exchange are outside the count.

Ada: The calculator above claims that over the same handful of attempts, Just Works exposes almost every device while Numeric Comparison exposes almost none. That gap is the entire argument for adding a check value, so let me reproduce it from the model’s own illustrative rates at its default sliders: 10 attempts, 100 devices.

Just Works treats each of the 10 setup attempts as an independent timing race the attacker wins with the model’s illustrative probability 0.75:

• Per-device escape from capture over 10 tries: (1 - 0.75)^10 = 0.25^10 = 0.0000009536743
• Per-device compromise probability: 1 - 0.0000009536743 = 0.9999990463, i.e. 99.99990%
• Expected devices compromised in the fleet: 100 x 0.9999990463 = 99.99990, which the panel rounds to 100 devices

Numeric Comparison instead forces the attacker to guess a 6-digit value, so each attempt succeeds with probability 1 / 1,000,000:

• Per-device compromise over 10 tries: 1 - (1 - 0.000001)^10 = 0.000009999955, i.e. about 0.001%
• Expected devices compromised: 100 x 0.000009999955 = 0.0009999955, about 0.001 devices

Dividing one by the other, 0.9999990463 / 0.000009999955 = 100,000.4: the same attacker, the same 10 attempts, and the same 100 devices, yet Just Works is roughly a hundred thousand times more likely to surrender a device than Numeric Comparison. The defence in that ratio comes entirely from the six-digit human check, not from the radio, the range, or the encryption, which is exactly why a displayless lock that can only fall back to Just Works needs an out-of-band channel or a physical setup action before it ships.

Every number above is taken from the chapter’s own material and re-derived step by step.