Nonce reuse

[KenMacD]

From the looks of things there's only 1 byte of 'random' nonce, leading to frequent reuse. Am I missing something?

[pvvx]

1 byte of 'random' nonce ???
Mijia:
https://github.com/pvvx/ATC_MiThermometer/blob/master/test_adv_key.py
Mijia test
Custom format

[KenMacD]

Yes, looking at:

	#                     mac      dev_id       cnt
	nonce = b"".join([data[9:15], data[6:8], data[8:9]])

what changes there?

[KenMacD]

As a local test I looked at 3 broadcasts using the same cnt from the pvvx format. The data bytes were:

<2-byte temp><2-byte humi><1-byte batt><1-byte trig>
d7d6 5307 f5 e6
d2d6 3c07 f2 e6
a8d6 0707 f2 e6

[pvvx]

Your question is not clear to me.
The repetition of the broadcast with the same counter with a step of 10 seconds is equal to 42 minutes. The data does not change per step either.
Are you interested in this or something else?
Or a question about the strength of the AES.CCM crypto used by Xiaomi-Mijia?

[KenMacD]

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)

[pvvx]

What is the point in pointing out the weakness of cryptography if all Xiaomi-Mijia devices are not better?
Basically, this is the level of all BLE, MESH, Zigbee, ...

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

[pvvx]

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.

Give a working example of a BLE scanner that cracks a key to this ad packet format.
Then the conversation will make sense.
A lot of people want an easy way to get the binding key from Xiaomi devices.

[KenMacD]

BLE/MESH/Zigbee may also use the same algo, but I doubt they suffer from nonce-reuse.

Give a working example of a BLE scanner that cracks a key to this ad packet format.

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:

A nonce N of 15-L octets. Within the scope of any encryption key
K, the nonce value MUST be unique. That is, the set of nonce
values used with any given key MUST NOT contain any duplicate
values. Using the same nonce for two different messages
encrypted with the same key destroys the security properties of
this mode.

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.

A lot of people want an easy way to get the binding key from Xiaomi devices.

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.

[pvvx]

Write it to Xiaomi Mijia :)
I've seen the AES-CCM spec.
That is, you cannot provide a working example of calculating the encryption key from the available full description...
Hence the conversation is about nothing.
Following the theory, any cipher is opened and there are no protection options :P
Any BLE module can duplicate a package... This completely destroys the security properties of the control system operating on the received data from the thermometer.
For custom fw, for compatibility with Xiaomi-Mijia encryption, a similar encryption method and similar variables are used.
This allows you to use one library with CCM that is available in all BLEs and a small ad package size.
Can you suggest a better encryption method with a shorter packet size, AES.CCM function, and bind-key usage?

[pvvx]

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.

Are you hacked? Or stories from bloggers? :)
Based on the experience of hacking hundreds of devices, I believe that the method used in the ad package is sufficient in terms of optimal cost and level of protection.

[KenMacD]

Looking at mi_beacon.c I see this:

• mi_encrypt_beacon: appears to use 32 bits for the counter. This is probably fine provided the counter is being stored somewhere that survives disconnecting power, which I haven't validated.
• atc_encrypt_beacon: uses an 8 bit nonce. This is broken.
• pvvx_encrypt_beacon: uses an 8 bit nonce. Also broken.

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?

[pvvx]

Where is your bind-key decoder program?

[pvvx]

• mi_encrypt_beacon: appears to use 32 bits for the counter. This is probably fine provided the counter is being stored somewhere that survives disconnecting power, which I hav

According to source codes from mijia: Saved at most once out of 512 changes.
https://github.com/MiEcosystem/mijia_ble_common/blob/master/mible_beacon.c#L238

xxx_encrypt_beacon: uses an 8 bit nonce.

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.
PS2: Patients with Persecutory delusion have been provided with the source code to write their own encoding.

[KenMacD]

Where is your bind-key decoder program?

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.

According to source codes from mijia: Saved at most once out of 512 changes.

Good, well that's something at least. Reducing the vulnerable time for their algo to at most 512 values after a power cycle.

nonce: mac[6] + head[4] + cnt[1] = 88 bis :P

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?

[pvvx]

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.

[pvvx]

As I've said before, this is not about key recovery, this is about plaintext recovery.

Where can I see the finished program with the recovery of the transferred data from any real thermometer?

Good, well that's something at least. Reducing the vulnerable time for their algo to at most 512 values after a power cycle.

Vulnerabilities from what?

Choose a simpler option (with which the protection level is compared):

• From completely rewriting fw in a thermometer by any pioneer?
• From forgery of previous read data to crash the rest of the system by any sniffer?
• Discharge the thermometer's battery in a couple of tens of minutes by making connections with the wrong pin code. Or by changing the PIN several times. Or by creating a connection with minimal connection time and ignoring requests to change them

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.

[KenMacD]

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.

[pvvx]

Предполагая, что обновление счетчика составляет 10 секунд, вы должны ожидать, что значения температуры / влажности / заряда батареи / триггера atc / pvvx начнут просачиваться чуть менее чем через часа. При использовании версии mi то же самое произойдет только через 1361 год.

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?

[Protoncek]

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?

[pvvx]

@Protoncek
I don't speak English either.
The question is different. Data encryption and energy efficiency. Moreover, the firmware has several formats to choose from, differing in the combination of these qualities. A minimum but energy efficient level is sufficient. And this is due to the fact that for any option, alternative options are possible in order to spoil the work of the НA or read the readings ... And they are easier to implement.
KenMacD wanted to demonstrate his knowledge, but he could not, choosing a banal comparison of several bits from the cipher code. But this was already taken into account when creating the additional format. And it is described in the topic about it. It was hoped that he would represent a better option, but ...

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

[KenMacD]

why is it a problem if someone sees my temperature and humidity values?

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

I'm very gratefull to pvvx and atc1441 for making this FW, since it's way more responsive than original.

As am I, which is why I created this issue to begin with.

Another thing would be if hacking this could lead to break into HA or home network, which i kinda doubt... ?

No. Data can be replayed if using either vulnerable algo though, so other processes shouldn't rely on that data.

[pvvx]

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.

At the moment, this is an unfounded statement. All factors are not taken into account.