Won't work on iOS. An app cannot simply get the local MAC address on iOS. Privacy reasons. And trying all the (2^8)^3 options will also not work - for power reasons you'll be quickly throttled.
Could the 256^3 presets not be pre-calculated? It's not like the intent for these keys is to make them private and secure, so reusing the same key material except for the MAC address itself shouldn't be a problem, should it?
Also, 16777216 possibilities really aren't that many these days. With six cores at approximately 3.5GHz, assuming verification costs about 1000 instructions per key, brute-forcing every possibility will take between 4 and 5 seconds at most (half that on average). With appropriate rainbow tables, I think that should be feasible?
The problem is not pre-calculation. The problem is that because you don’t know your MAC address, you need to broadcast all of those things, since you don’t know which one will be valid. Either at once or sequentially. Either way, iOS will not let you set up that much broadcasting.
You don't need MAC address - you just need the iPhone to broadcast specific BLE advertising packet/payload.
Using Core Bluetooth API it is trivial, but you need to either:
a) create an app that does it and user has to download it
b) modify SDKs existing in apps (e.g. Ad SDKs)
Also turning app/phone into a "BLE beacon" is only possible when app running in the foreground (on iOS).
Knowing the MAC makes the attack reasonable - let's say 5 hours compute for 3080Ti.
Not knowing the MAC makes it exponentially harder. You can still "guess" it, but the search-space is vast and that would take bazillion-years.
So to attack iOS device:
- user has to download the app
- app has to broadcast fake BLE
- some other devices (e.g. Android/RasPi would need to pickup that MAC and pass it to you
Could the 256^3 presets not be pre-calculated? It's not like the intent for these keys is to make them private and secure, so reusing the same key material except for the MAC address itself shouldn't be a problem, should it?
Also, 16777216 possibilities really aren't that many these days. With six cores at approximately 3.5GHz, assuming verification costs about 1000 instructions per key, brute-forcing every possibility will take between 4 and 5 seconds at most (half that on average). With appropriate rainbow tables, I think that should be feasible?
The problem is not pre-calculation. The problem is that because you don’t know your MAC address, you need to broadcast all of those things, since you don’t know which one will be valid. Either at once or sequentially. Either way, iOS will not let you set up that much broadcasting.
You don't need MAC address - you just need the iPhone to broadcast specific BLE advertising packet/payload.
Using Core Bluetooth API it is trivial, but you need to either: a) create an app that does it and user has to download it b) modify SDKs existing in apps (e.g. Ad SDKs)
Also turning app/phone into a "BLE beacon" is only possible when app running in the foreground (on iOS).
Please read the original source again. You need to KNOW (or guess) own mac address as it becomes a part of the key.
Yes, you are correct!
Knowing the MAC makes the attack reasonable - let's say 5 hours compute for 3080Ti.
Not knowing the MAC makes it exponentially harder. You can still "guess" it, but the search-space is vast and that would take bazillion-years.
So to attack iOS device: - user has to download the app - app has to broadcast fake BLE - some other devices (e.g. Android/RasPi would need to pickup that MAC and pass it to you