BLE Link Layer behavior for "barge-in attack"?

RE: BLE Link Layer behavior for "barge-in attack"?

Elias — Mon, 17 Jul 2017 20:13:30 GMT

The purpose is that the device not being jammed will be tricked into dropping its end of the connection via passing its Supervision Timeout. The jammer can then take the place of that device in the connection.

RE: BLE Link Layer behavior for "barge-in attack"?

Elias — Fri, 14 Jul 2017 22:24:51 GMT

A quote from the Core Spec is pretty much exactly what I was hoping for.

RE: BLE Link Layer behavior for "barge-in attack"?

Ulrich Myhre — Fri, 14 Jul 2017 14:35:26 GMT

If you know all the parameters of the connection, it is indeed possible to impersonate a peer over an unencrypted connection. Constantly sending NACKs will not normally kill a connection, but if timed correctly they can introduce protocol timeouts, which effectively disables most of the communication. Impersonation can also be executed on encrypted connections, but no data can be sent. This is because empty PDUs are not encrypted in the same way as data PDUs, so you can keep sending empty NACKs to keep the connection alive.

The existence of such an attack is one of the reasons why the LE Ping feature was introduced for encrypted connections. It makes sure that some data packet is sent every now and then, not only empty PDUs. If the peer does not respond to it, the connection dies. If the peer does not know the session or long-term key it will lead to a MIC failure and the connection dies.

Using encryption is recommended for sensitive information, and pairing methods using Out Of Band-data are usually the most secure in that regard. LE Secure Connections with Passkey Entry is also quite hard to MITM, as you need to guess each individual bit in the PIN. Failing a single bit check aborts the procedure, and application-specific back-off algorithms can lead to exponential lock-outs for repeated attempts.

RE: BLE Link Layer behavior for "barge-in attack"?

Hung Bui — Fri, 14 Jul 2017 07:53:49 GMT

As far as I understand, the connection will not be timed out as long as the peer still receive "valid packet" , so it doesn't mater if it's a NACK or and ACK, it's still a valid packet. Quoted here:

To be able to detect link loss, both the master and the slave shall use a Link Layer connection supervision timer, T_LLconnSupervision. Upon reception of a valid packet, the timer shall be reset.

Core spec 4.2 , Vol 6 Part B section 4.5.2 .

B will continue transmitting , there is no time out for this except if it's in a procedure that has a timeout, such as encrypting (30s timeout).

I don't understand purpose, what is the next step of jamming a device and then let other device transmitting ?

RE: BLE Link Layer behavior for "barge-in attack"?

endnode — Thu, 13 Jul 2017 11:53:17 GMT

I've also read your attack scenario several times again and I believe it is not applicable. Once any timeout kicks-in then device terminates the link so you cannot force one peer by jamming the packets to disconnect from legitimate target and then stay connected to "attacker". Or maybe I haven't understood how exactly this attack should work. From my 4-year experience and several security analysis there is just relay/MITM attack possible (you really need to "block" packets from one peer and mimic it by sending your own packets towards second peer + vice versa for the other direction) or dumb DoS (jamming whole spectrum or just particular channel + time to disturb either Tx or Rx windows). Both are pretty easy to execute (basic BLE knowledge and any dev kit will do the job).

RE: BLE Link Layer behavior for "barge-in attack"?

endnode — Thu, 13 Jul 2017 07:07:53 GMT

Indeed, not advancing LL counters mean that packet is invalid (or at least this is how I understand BT SIG Core spec and expect all BLE stacks to be validated during qualification, haven't verified myself). If the LL PDU is invalid in this sense it should be completely ignored by LL and should not be propagated to higher layers so it is effectively equal to receiving packet with wrong integrity/security or not receiving the packet at all.

RE: BLE Link Layer behavior for "barge-in attack"?

Elias — Thu, 13 Jul 2017 06:49:23 GMT

Yes, I know about the Supervision Timeout, but as far as Device B is concerned, no jamming is happening. Do you mean to say that valid PDUs with a non-incremented NESN still count against the Timeout?

As for the bit about channel re-map, you're right, it would depend on the first part of the question, so I've removed it, since it was a bit distracting.

RE: BLE Link Layer behavior for "barge-in attack"?

endnode — Thu, 13 Jul 2017 06:44:58 GMT

There is parameter called Supervision Timeout which guards "lost" connections. It's typically in 1-32s range so if you keep jamming or blocking Link Layer PDU in one or both directions for 30~1000 connection intervals in the row it's treated by BLE controllers (stacks) on both sides as if they would lost the link and they will terminate it internally. This interval has some relation to other connection parameters but in general it is managed by upper layers of the stack if they have intention to do it.

To channel re-mapping: you mean changing channel map of the connection? That cannot happen without correctly received LL packet, can it? I believe that if you are loosing all LL packets in a row you won't change any parameter of the connection (however normal "hardcoded" properties like channel hopping for every interval will be exercised).