Open
Conversation
There was a problem hiding this comment.
Pull Request Overview
Implements the new TPAP (TP-Link Adaptive Protocol) encryption type with SPAKE2+ HTTPS transport for TP-Link devices. This is an initial implementation to test handshake functionality with new firmware that uses TPAP encryption.
- Added complete TPAP transport implementation using SPAKE2+ P-256 handshake and AEAD data channel
- Updated device factory to support TPAP encryption type routing
- Added ecdsa dependency for elliptic curve operations
Reviewed Changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| pyproject.toml | Added ecdsa dependency and mypy overrides for the new package |
| kasa/transports/tpaptransport.py | New TPAP transport implementation with SPAKE2+ handshake and secure channel |
| kasa/transports/init.py | Added TpapTransport to module exports |
| kasa/deviceconfig.py | Added Tpap enum value to DeviceEncryptionType |
| kasa/device_factory.py | Added SMART.TPAP.HTTPS protocol mapping and fixed typo |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1592 +/- ##
==========================================
+ Coverage 93.22% 93.73% +0.50%
==========================================
Files 157 158 +1
Lines 9815 10608 +793
Branches 1003 1105 +102
==========================================
+ Hits 9150 9943 +793
Misses 472 472
Partials 193 193 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Contributor
Author
|
@rytilahti Ok, I think this is a good first pass. I just need someone with a RV device to test it. The CodeQL Security flags, from my understanding, will always come up with md5 and sha1 hashing in the code, but it's required for the device communication, just like with the other transports. |
|
Sanitized discovery, logs, and TLS observations for the RV30 Max Plus(EU)-Firmware:1.3.0 Build 250909 Rel.135514 using TPAP. Personally identifying values are redacted. Hope this help.
uv run kasa --username '' --password '' --debug --host 192.168.68.63 discover config uv run kasa --username '' --password '' --debug --host 192.168.68.63 discover raw SSL: Wireshark: |
Contributor
Author
|
@danieyal Pull the latest commit and try giving it a shot again. |
|
unfortunately, still the same error. |
|
I think i have got the TLS working now but stuck on the authentication now.
The device is returning a JSON response with 'error_code': -2402 along with authentication failure details like failedAttempts and remainAttempts. The device is rejecting the authentication attempt at the pake_register stage returning error code -2402. My theory is the device is actively rejecting our credentials/authentication attempt before we even get to the SPAKE2+ cryptographic exchange. This suggests the device needs something we're not providing, most likely DAC support. |
Contributor
Author
|
I have been working on this today without much movement, still trying to figure out the authentication pieces. Looks like I will have to implement NOC but having issues getting the information and URLs for the certificate registration with the Tapo cloud. There is an API rate limit which causes problems as well. So, I'm still working on this, but nothing yet. |
Contributor
Author
|
@danieyal Are you able to use the Tapo app on your computer with Wireshark? I'm trying to reverse engineer the url for the certificates and the requests are not working. I am looking for something to do with: This is what points to where to apply for the certificates, but I can't get the communication to work correctly on my end. I'm trying to get the signature correct with the app to the cloud so I can pull the url, but I can't get that either. Until I have the URL to work with the serviceId: nbu.cvm-server-v2, then I can't get the library to handle the noc certificates. |
Contributor
Author
|
@danieyal try pulling again and let me know. I updated the ciphers like you found and I also corrected the last error you posted, it went to the stok field in the register parameters, it needed to be sessionId instead. Let me know what you get with this. |
|
@ZeliardM Thanks for the updates, and to clarify my side:
Re: NOC/
I also pulled the latest branch:
Frida Log for device commissioning, I reset my device to see if pake_register appear at all, but it seems like nope, it just communicates over cloud regardless, other Tapo devices (plug, bulb, hub, camera) that I own still communicates locally (so probably not local network issue), I can 'see' the local endpoint for other devices but only vacuum just straight to cloud endpoint. Sorry, if it takes too long, setting up Frida took longer than expected. |
Contributor
Author
|
@danieyal That's great, I do see something in your logs about nbu, that may help point me where I need to go. Yea, Frida is a pain. I've used it in the past but lost my devices to do so, so it's been rough lately. I appreciate your work so far. I am going through the encryption pieces again. Yea, the pake_register phase is essentially handshake1 and I still need to see what is going on. |
Contributor
Author
|
@danieyal Ok, I've spent most of the day going over things, and I think I'm at an impasse. I can't get the URLs to communicate with the cloud for the NOC certificates. I've gotten close, but what happens is that the APK uses a call, gets a cloud token, then pulls the URLs from the cloud. I can get the cloud token, but the I cannot get the signature matches for the calls out that have 'signature-required' set to true. I need to see if there is a way to reverse engineer these signatures so we can get them to match from my code based on how everything is supposed to be. I have some scripts and code that I've got for testing if you would be able to take it along with some of the Frida work you've done and possibly see if you can get the URL? I can send them via Discord if that works? |
|
@ZeliardM yeah sure, I will try but since I am working during the day, I might not have enough time to dedicate to it, but I'll try. Discord works for me. |
Contributor
Author
|
@danieyal All good, give it a shot and let me know and we will go from there. Thanks! |
Contributor
Author
|
@danieyal What I have been able to pull apart today is that the checkpassword call that is used in the frida logs you posted earlier, this has the same signature requirements that I am looking for. If you can get me some wireshark pulls of this actual communication so I can see the actual headers and packet information, then I might be able to reverse engineer this from there. If you want, we can keep going on Discord, my username is the same there. |
Contributor
Author
|
@danieyal nevermind, I finally got the matching signature and figured out how to get the right url for getting the certificates! |
Contributor
Author
|
Ok, now that I have all of this, my plan is as follows:
It's going to take quite some time for me to get through all of this, I want to put it together cleanly. I'm headed out of town with my family for the weekend so I may not work on it much right now, but will keep everyone updated as I keep working on it. |
Contributor
Author
|
I am still slowly working on this. I have the NOC capabilities set up, now I'm working on testing the code. Having issues with the CSR formatting so I'll keep plugging away at it and keep you in the loop. |
Contributor
Author
|
I am making some major changes to the TPAP Implementation. I would like anyone's help testing it. I need to make sure that it functions and works with all of the device types that currently support TPAP, plugs, vacuums, and cameras. I am finalizing the changes now and should be able to get something out later today, but I will need people to test and get me debug plain discover logs from the CLI of kasa to be specific in the handling. If you have any questions, let me know. |
|
|
||
| @staticmethod | ||
| def _md5_hex(value: str) -> str: | ||
| return hashlib.md5(value.encode()).hexdigest() # noqa: S324 |
Check failure
Code scanning / CodeQL
Use of a broken or weak cryptographic hashing algorithm on sensitive data High
|
|
||
| @staticmethod | ||
| def _sha1_hex(value: str) -> str: | ||
| return hashlib.sha1(value.encode()).hexdigest() # noqa: S324 |
Check failure
Code scanning / CodeQL
Use of a broken or weak cryptographic hashing algorithm on sensitive data High
| ) | ||
| return passcode | ||
| return hashlib.sha256( | ||
| (username_hint + decoded_salt + passcode).encode() |
Check failure
Code scanning / CodeQL
Use of a broken or weak cryptographic hashing algorithm on sensitive data High
Contributor
Author
|
Ok, I have pushed all my changes. I still have some clean up, but we should be pretty close now. I made a lot of changes and the first thing to do is see if the device connections for tpap still work at all. There are two paths:
If you have any questions about this, let me know. And thanks for testing. |
|
Device: L535E(EU) — SPAKE2+ handshake is being attempted over plain HTTP (no TLS, port 80). Device responds to This is a |
Contributor
Author
|
@Slaymish I appreciate this, one of the first bulbs I've seen with this now. I'm still working on additional changes here, so please be patient and I'll let you know when you can try and pull the code and try again. |
// Remove-Item Env:KASA_TEST_DISABLE_TPAP_TLS2_VERIFY -ErrorAction SilentlyContinue // $env:KASA_TEST_DISABLE_TPAP_TLS2_VERIFY="1" |
|
Hi @ZeliardM, great work on the TPAP/SPAKE2+ implementation! I've been working on a Node.js (ioBroker) adapter and successfully connected to a P100 (FW 1.4.3, HW 2.0, tls=0, pake:[2], HTTP port 80) using your code as reference. A few findings that might help: 1. Credential hashing for passwd_id=2 is double-hashed (tls=0 devices)For smartcam auth with The device expects # In _iter_spake_candidate_secrets, for pake:[2]:
candidates = [password, self._md5_hex(password), self._sha256_hex_upper(password)]2. Username "admin" works for all plugsP100/P110 plugs with 3. Missing extra_crypt type:
|
Contributor
Author
|
Thanks! I'll look through all of this. I've got a bigger PR that I'm working on right now for improving the discovery handling and implementing a lot of missing device types and transports. It's taking a lot right now so I'm not sure when all of this will actually make it out. |
|
|
||
| @staticmethod | ||
| def _sha256_hex_upper(value: str) -> str: | ||
| return hashlib.sha256(value.encode()).hexdigest().upper() # noqa: S324 |
Check failure
Code scanning / CodeQL
Use of a broken or weak cryptographic hashing algorithm on sensitive data High
Contributor
Author
|
@ZeliardM working fine here DEBUG Trying to connect with SmartProtocol discover.py:684 .................. DEBUG Device 192.168.68.63 with connection params True took 1.45 seconds to update device_factory.py:96 |
Contributor
Author
|
@danieyal That's great! Glad to hear it. |
|
I have a Tapo H110C(JP), a Smart IR & IoT Hub that I was hoping to add support for myself. I was able to discover the device with kasa discover normally, but in order to test the IR capabilities through the app I needed to upgrade the firmware. After upgrading to 1.4.4 it started using the TPAP protocol, and I needed to include code from this PR in order to authenticate. However, after updating to the latest changes I am getting an error: Reverting to the code that worked before (directly before the Complete re-write, using commit 18736c2) seems to authenticate correctly. (Ignoring the unknown child device, which is currently not supported) I would still like to work on adding support for the |
Contributor
Author
|
@tuck-ski Thaks for this feedback. I haven't had anyone test this path yet so it's good to see. I'll take this information and see if I can work on getting the issues resolved and let you know. Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Discovered with new firmware for devices, TP-Link is implementing a new Encryption Type, TPAP. This is an initial implementation to see if the coding works for the handshake. Testing of the code coverage still has to be worked on. The initial implementation includes the new transport, changes to the device_factory to allow devices to select the new transport, and a change to the project to include ecdsa as a new dependency along with cryptography for the new tpaptransport.py.