This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

This is a more specific counterpart to a question I posted on StackExchange. If you want to know more about the attack itself, check that out, but here, I'm asking for a specific behavior that the attack takes advantage of. I'm going to refer to Devices A and B, which are in an active unencrypted connection.

When the Link Layer of Device A receives an invalid packet, it transmits a reply with a non-incremented Next Expected Sequence Number, which signals to Device B's Link Layer that it should re-transmit the packet. Is there a limit from the perspective of Device B on how many times this can happen? If it's receiving valid packets, the channel is apparently usable, but none of the packets it's transmitting are apparently getting through.

Will Device B just keep trying to re-transmit the same packet as long as Device A keeps asking for it?

Parents
  • 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 ?

  • 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.

Reply Children
No Data
Related