The power theory is silly IMO; Bluetooth IDs are only generated 144 times a day, the battery savings would be negligible.
-
Show this thread
-
Broadcasting the transmit power level of the bluetooth assists the app in assessing distance. The receiving phone stores the observed signal strength on its end, and later when everything can be decrypted, it allows the system to est. the distance between the sender and receiver.
1 reply 0 retweets 4 likesShow this thread -
Anyway, let's get into some cryptography details! Basically every time the bluetooth MAC changes, the device produces a new identifier which an AES ECB (!!) encrypted version of the current time-internal number. Don't panic: ECB is ok here, time-intervals won't repeat.
1 reply 0 retweets 4 likesShow this thread -
That 16-byte encrypted blob is broadcast on the wire, but it also the IV for an AES-CTR encrypted 4 byte section of metadata. What's in the metadata? Here's the list from the Bluetooth spec.pic.twitter.com/HWGhfcc6ou
1 reply 0 retweets 3 likesShow this thread -
On the surface of it, this doesn't look safe. If the power level changes, then byte 1 will change, but get encrypted using the same key, IV pair, and broadcast. This leaks one byte of ciphertext. Since there's no MAC of any kind, it also means these values can be forged.
1 reply 0 retweets 2 likesShow this thread -
Like I could grab your broadcast bluetooth ID, change that byte, and rebroadcast it .. and it would decrypt and register just fine. Hard to think of a useful attack though. I can't predict the decrypted value, just corrupt it.
1 reply 0 retweets 2 likesShow this thread -
If I re-broadcast all 256 potential values, some would be bound to register as within the "proximity radius of danger", but it'd be an easy attack to detect.
1 reply 0 retweets 1 likeShow this thread -
And Apple | Google are careful not to leak the ciphertext byte. The bluetooth paper makes clear that you have to change the metadata at the same time as the key used to encrypt it (which is valid for a time interval).pic.twitter.com/nen8STOZx0
1 reply 0 retweets 1 likeShow this thread -
On the whole, it looks ok to me if a bit precarious. If the Bluetooth MAC address changes and the key-rotations get out of phase, things go bad. If the app re-generates an ID when the power level changes, that's worse, though not the end of the world.
1 reply 0 retweets 2 likesShow this thread -
This all reads like a well-integrated effort by professionals working across cryptographic, radio, and epidemiological boundaries to make smart trade-offs.
1 reply 1 retweet 8 likesShow this thread
Addendum: maybe the power theory isn't so silly. I forgot that the app also has to re-generate the IDs of every infected person to determine matches. AES will save a lot of power in that case.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.