Skip to content

Collaboration document for PSK Identity 02

Jump to bottom Edit New page
Colin Kuebler edited this page Aug 14, 2020 · 279 revisions

Here we will share and organize our findings and data from #483

Findings

  • firmware OS SDK version did not change, but the hash and build time did
    • OS SDK ver: 2.0.0(e8c5810) compiled @ Jan 25 2019 14:26:04
    • OS SDK ver: 2.0.0(29f7e05) compiled @ Sep 30 2019 11:19:12
      • interesting that this build date corresponds with the release of tuya-convert 2.0, coincidence?
  • psk begins with 02 rather than 01
    • guessing this will tell us the psk algorithm version
  • disabled most of the serial debugging output
    • unfortunate as this was a useful reverse engineering resource
  • did not respond to our smartconfig procedure
    • it may use a new mechanism or additional restrictions have been imposed
  • MAC address in flash appears to be compared with actual device MAC
    • likely to foil reverse engineering attempts by running firmware on a dev board
  • new factory written key found in flash, "pskKey"
    • this may mean the encryption key will no longer be derived deterministically, big bummer
    • only found in @rsbob's backup, looks like @Farfar's was updated to this firmware and thus lacks this factory written key
      • this may mean there is still hope for devices that came with a lower firmware, since updating to this firmware would require fetching the key
      • this is a very interesting new endpoint: tuya.device.uuid.pskkey.get

It appears a unique preshared key is programmed into each device at the factory. Unlike before where the key could be derived from the TLS identity, now the identity is a hash of the device's id and MAC address. For those following along, the new identity derivation is:

'\x02' + 'BAohbmd6aG91IFR1' + sha256(prod_idx + mac_addr)

where prod_idx is the ASCII of the 8 digit product ID, and mac_addr is the MAC address of the device in hex, all lowercase, no punctuation. These parameters are all stored in the flash in a JSON blob at 0xfb000.

Procedures

I'll take a closer look when I have some more time but is that all we need to flash the firmware?

No, it's a bit more complicated than that. The missing part is how to compute the PSK from the PSK identity, if that is possible with the information we have.

As @iracigt has said, the prod_idx is used to compute the PSK identity. This is handed to the server by the client during the handshake, so it is not secret information.

prod_idx is not secret information either, it is the first part of the gwId as you have noticed, @CHAZICLE. In fact the gwId is what is being hashed here, which is prod_idx + mac.

The point is that the previous implementation did leak secret information through the PSK identity, which we could use to compute the PSK. Now that it does not, our job is harder.

In order to solve this, we will need samples of actual communications between the client (smart device) and the server (Tuya cloud), along with a copy of that device's firmware. If anyone is able to provide both we may be able to crack this.

One possible procedure to accomplish this would be:

  1. Start with a new device
  2. Create a bridged hotspot using create_ap
  3. Start recording the network interface with tcpdump or WireShark
  4. Connect smart phone
  5. Use the vendor app to connect the smart device to the hotspot
  6. Disconnect and stop recording
  7. Open the device and read the firmware over serial using esptool.py

Data

Known Affected Devices

  • BSD34 smart socket
  • BSD29
  • Deltaco SH-P01E
  • Bakibo TB95
  • Bakibo TP22Y
  • MoesHouse Smart Downlight

Firmware

Network Captures

Strings

Add a custom footer
Add a custom sidebar

Clone this wiki locally