-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nonce reuse #154
Comments
1 byte of 'random' nonce ??? |
# mac dev_id cnt
nonce = b"".join([data[9:15], data[6:8], data[8:9]]) what changes there? |
As a local test I looked at 3 broadcasts using the same
|
Your question is not clear to me. |
The above broadcasts are many minutes apart. I was looking to enable crypto and from an initial glance of the code it appears to me like it's very weak. I was just looking to confirm that I'm not missing something. I'm guessing enabling crypto has at least some effect on battery usage, so if it's not providing much more than some obfuscation I'll use that to inform my decision. If the crypto using a nonce that's repeated every 42 minutes then the crypto is broken for anyone that can capture over 42 minutes of sensor data. I get that it's just temperature data, as probably not particularly sensitive. If I haven't missed anything though I would suggest the extreme weakness of the crypto be at least noted somewhere in the documentation. (from the bytes I provided before we can see that the upper 8 bites of both temp and humidity stayed the same over the time, as did the trigger value. We can't yet be sure what those values are, but by watching how they change over time we should be able to figure them out) |
What is the point in pointing out the weakness of cryptography if all Xiaomi-Mijia devices are not better? The BLE advertisement transmission scheme is unidirectional. There is no return channel. The loss of energy for the transfer of an additional byte is commensurate with the level of protection of the cipher. For Zigbee, energy losses quadruple ... |
Give a working example of a BLE scanner that cracks a key to this ad packet format. |
BLE/MESH/Zigbee may also use the same algo, but I doubt they suffer from nonce-reuse.
There's no need to crack the key. Reuse of a nonce exposes the plaintext. As a working example you can use the data I provided above. If you xor two of them together the encryption falls off and you end up with the xor of the data. Looking at the AES-CCM spec. In section 2.1 it says:
All that I was asking was to confirm that there is indeed nonce-reuse. If there is nonce-reuse then the crypto is broken. This isn't just theoretical, It's how the playstation 3 was cracked.
Sorry, I don't know what you mean by this. Using the binding key is probably fine. It's only the lack of nonce that is the issue. |
Write it to Xiaomi Mijia :) |
Are you hacked? Or stories from bloggers? :) |
Looking at
I understand you're trying to shrink the amount of data that needs to be sent, but it's misleading to call it encrypted when it's at best obfuscated. Which part is it that you doubt, that a nonce is reused, or that it matters that a nonce is reused? |
Where is your bind-key decoder program? |
According to source codes from mijia: Saved at most once out of 512 changes.
nonce: mac[6] + head[4] + cnt[1] = 88 bis :P PS: Failure to provide a working example of calculating the bind-code is proof that for this transmission scheme, the applied encryption is already redundant. |
As I've said before, this is not about key recovery, this is about plaintext recovery. The values for the sensor can be derived due to the reuse of nonce values.
Good, well that's something at least. Reducing the vulnerable time for their algo to at most 512 values after a power cycle.
Yes, but which values change? The static bytes don't help prevent reuse. I feel we're going around in circles here, so I'll try asking the previous question once more in a different way: In the xxx_encrypt_beacon how long until a nonce is reused? |
Depends on user preferences. Changed in TelinkMiFlasher.html. |
Where can I see the finished program with the recovery of the transferred data from any real thermometer?
Vulnerabilities from what? Choose a simpler option (with which the protection level is compared):
I see no reason to analyze your reasoning without the numerical values necessary to assess the level of protection comparable to existing thermometers. I have not come across devices that cannot be opened programmatically for entertainment or other needs. And in the case of thermometers, the level of protection against advertising is sufficient for the average man in the street. So far, this is indicated by all your messages and the absence of a real decoder. |
I'm afraid I can't expend any more time on this issue. It appears you're either unable or unwilling to understand this nonce reuse vulnerability; or maybe you don't care that your choice of counter length is insecure. Either way, I've provided information about the vulnerability, and I've provided data captures that show the nonce-reuse disclosing information about the plaintext. That's all I can do. For others that might come across this issue: If you are concerned about the transmitted values being secure against passive eavesdropping, I suggest using the mi encryption and avoiding both atc and pvvx. While mi will use more battery, the crypto is much more secure. Assuming a counter update of 10 seconds you should expect atc/pvvx temperature/humidity/battery/trigger values to start leaking in just under ¾ of an hour. Using the mi version the same would only happen after 1,361 years. |
The estimate is given taking into account the simultaneous receipt of real-time data on temperature, humidity and battery level from sensors of the discovered device. :) Reason for closure: The first answer and the readme indicate that the format was created for: Feature request question: Very energy efficient encrypted custom format? |
I'm not sure if i understand this correctly (english is not my native...) , but if i do: i wonder, why is it a problem if someone sees my temperature and humidity values? There's no personal data in these messages, they are just numbers and "hacker" can't even tell for which room these values are (i have 8 of them now), so i really can't see any need for encryption at all. Ok, someone can "camp" in front of my house and see my room temperatures... so what..? They are no "nasa top secret"... If he rings the bell i'll gladly show him all my HA data, not just xiaomi temps. I have nothing to hide there. I gladly show my HA to anyone who's interested. I'm very gratefull to pvvx and atc1441 for making this FW, since it's way more responsive than original. Another thing would be if hacking this could lead to break into HA or home network, which i kinda doubt... ? or am i missing something? |
@Protoncek And the discussed thermometers have a lot of vulnerabilities. This is with the specifics of current BLE implementations, hardware limitations, closed libraries from Telink, complete absence of control over the received readings in third-party software, poor implementations of internal BT adapter drivers and much more. Old adapters, lengthy and incomplete implementation of parsing ad packages in a third-party software... |
@Protoncek: That's orthogonal to this issue. There's lots of reason a person might not want their temperature/humidity/relay values to be read. There's also lots of reasons that someone might want protect against values being replayed. If someone makes the choice that they want encryption then they will likely expect that the encryption provides the above protection. Both atc and pvvx format do not provide this protection. That other products contain their own vulnerabilities is also irrelevant to the vulnerable crypto added in this one.
As am I, which is why I created this issue to begin with.
No. Data can be replayed if using either vulnerable algo though, so other processes shouldn't rely on that data. |
At the moment, this is an unfounded statement. All factors are not taken into account. |
From the looks of things there's only 1 byte of 'random' nonce, leading to frequent reuse. Am I missing something?
The text was updated successfully, but these errors were encountered: