• State Verified Answer
  • Replies 8 replies
  • Subscribers 73 subscribers
  • Views 3934 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 123482
Options
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"?

Elias

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

    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.

Reply
  • 0

    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.

Children
No Data
Related
Terms of service