android: Wear OS: TLS Client Authentication Support does not work
Home Assistant Android version: beta-2534-90a9a27e
Android version: Wear OS 2
Phone model: Fossil Gen 6
Home Assistant version: 2022.8.1
Last working Home Assistant release (if known):
Description of problem: Wear OS home assistant app does not ask which certificate to use like the regular android version does.
Traceback (if applicable, to get the logs you may refer to: https://companion.home-assistant.io/docs/troubleshooting/faqs/#android-crash-logs):
08-07 10:29:39.850 2250 4302 E WebSocketRepository: Websocket: onFailure
08-07 10:29:39.850 2250 4302 E WebSocketRepository: java.net.ProtocolException: Expected HTTP 101 response but was '400 Bad Request'
08-07 10:29:39.850 2250 4302 E WebSocketRepository: at okhttp3.internal.ws.RealWebSocket.checkUpgradeSuccess$okhttp(RealWebSocket.kt:224)
08-07 10:29:39.850 2250 4302 E WebSocketRepository: at okhttp3.internal.ws.RealWebSocket$connect$1.onResponse(RealWebSocket.kt:170)
08-07 10:29:39.850 2250 4302 E WebSocketRepository: at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
08-07 10:29:39.850 2250 4302 E WebSocketRepository: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
08-07 10:29:39.850 2250 4302 E WebSocketRepository: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
08-07 10:29:39.850 2250 4302 E WebSocketRepository: at java.lang.Thread.run(Thread.java:764)
08-07 10:29:39.852 2250 2250 E WebSocketRepository: Unable to authenticate
Screenshot of problem:
Additional information:
I am unsure if this is really a bug report or a feature request as I don’t know if the feature has been implemented in the Wear OS app yet. But unlike the regular android app, the Wear OS app does not seem to care about the client certificate I installed.
The certificate was installed on the watch using adb as follows:
$ adb push watchcert.p12 /data/local/tmp/
$ adb shell am start -n com.android.certinstaller/.CertInstallerMain -a android.intent.action.VIEW -t application/x-pkcs12 -d 'file:///data/local/tmp/watchcert.p12'
CertInstaller reports that installation was successful.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 15 (6 by maintainers)
I can think of two possible directions:
1.) Use the phone to pick the client certificate file(s) and transfer them to the HA app’s private storage folder on the watch. This can raise some security concerns, as the user can forget about the secret files and leave them in a public folder on the phone in plaintext. Also, I don’t know how secure and trustworthy the connection between the phone and the watch is, but it should be secure, right? This isn’t a far-fetched idea and has the clear advantage of being pretty straightforward for the user.
2.) There’s another potential option that nobody really raised so far, and it’s a pretty secure option. However, I didn’t yet have the time to validate it, but let me throw it in… We could take advantage of the
AndroidKeyStore’s hardware-backed crypto capabilities and generate an ECC or RSA keypair on the watch itself, and export a Certificate Signing Request (which doesn’t contain secret data), piped through the phone app. This CSR then should be signed with the proxy’s CA, and AFAIK then the signed result should be returned to the watch (through the phone app). Then the watch should use the key residing in theAndroidKeyStoreto perform mTLS authentication. It’s definitely more complicated, but it’s the most secure flow I could think of, that’s an advantage. However, there’s also a disadvantage besides being complicated: when the user uninstalls the app, the mTLS key will be lost. Please note that it’s more like a theory, and I haven’t done this before, but I think it should work.@m4k2k This issue is about TLS Client Certificate Authentication (CCA), not trusting additional CA certificates.
No, this is currently not supported in the Wear app so it’s a feature request 🙂
If you have to use ADB commands it is already a workaround and not something supposed to be supported, and when doing this on an emulator I get a message ‘The certificate is not installed’ with an error in the logs:
and
com.android.certinstaller D/CertInstaller: credential not saved, err: 0.As soon as you transfer the files to the HA app private storage, they could be loaded to the
AndroidKeyStoreimmediately (as the code already does) and then they could be deleted. Then, as in my test number 6 above, no files are necessary for the watch app to work.This doesn’t leave traces the user could forget.
I just wanted to share the complete process, instead of just posting the last results. It could be interesting to others, or at least I would rate as interesting (as I wasn’t able to find this info easily on the web).
OK but this is a lack of Wear OS and we don’t have any control on that. Yeah we could open ticket with the Google support, but either they won’t read or do anything for that. They simply don’t care at all!
The main app relies on the OS UI, so we don’t have that possibility until Wear OS ‘evolves’ (basically never). That’s why I asked if it was possible for the Wear OS APK to rely on the phone connection in case of errors, but you pointed out that this requires a complete rewrite and hard work so neither this option is available.
Maybe it’s possible to use the phone APK to just transfer the private keys to the watch APK, without relying on files… Similarly to setting up the template watchface. I don’t know what limitations are there, but the key data shouldn’t be so big.
Anyway, as I’ve written on paragraph 6, this “hard effort” is required only for the first installation. Then even deleting the keys or updating the app doesn’t touch the certificates.
Personally I use TLS Client Authentication to not expose the HA instance directly and think is a useful and safe feature… and losing the ability to update the data from the watch (when out of Wi-fi) is a big disadvantage for me. Maybe I’m one of the few who are interested… 😢
Wow, that is A LOT of hoops to jump through and hardcoded stuff. It was never a question of whether certificates would work, but more how you’d use them as watches don’t appear to have a user certificate store or UI for this. It should be relatively easy and secure, and preferably similar to the ‘main’ app. Integrating something into the app requires maintainable code and not this much effort to use. While this is great, I don’t see how this would work in production.
I think I have good news, as I think I’ve been able to use the TLS Client Certificate to establish a connection with my own server from Wear OS 3 (using a Galaxy Watch 4).
Unfortunately I’m just a hobbyist that doesn’t know Kotlin or Java: most of the tests I’ve done below have been made by trial & error and Googling. So I apologize in advance!
Actually it seems that the code by @mircoboschi works, at least to load the certificate from a file. Let me explain below.
Preparation and patching
I downloaded the ZIP code of commit 52bb4c7 from his repository. I added some logging to understand if the code that loads the certificate from a file works.
MTLSHelper.kt
Added the imports:
Changed the
tryImportKeysfunction:and near the end:
HomeAssistantApis.kt
Added the imports:
Added some code to the
configureOkHttpClientfunction to test if okHttp is really reading something useful from the server. I know, this is bad… but I’m not skilled enough edit the original code 😭strings.xml
Changed the
input_url_hintto avoid typing in the watch:AndroidManifest.xml
Added the permission to read files in the Public folders (this has to be changed due to Android 11):
wear/build.gradle.kts
Lowered the API to 28 to allow using the File reading APIs (I don’t know how to convert with Scoped Storage and Android 11):
Patch file for easier apply
Logging.patch
Testing
After doing the patching and compiling the APK with Android Studio (in
debugmode) I connected to the watch using ADB and installed the app.Then, before launching the app on the watch, I keep listening with
adb logcatwith this command:1) Run the APK without any certificate
When running the APK without any certificate file in the public Download folder of the watch, I get an exception.
2) Extract the certificate files from PKCS12
I use a PFX certificate file (
mycert.pfx) to connect to my nginx instance that exposes Home Assistant. So I first had to export the .KEY and .CER files from the .PFX file with:As I didn’t have a password, I just pressed the <kbd>Enter</kbd> key. Then I copied the files to the watch using ADB:
Then I run the app on the watch again, always by listening with
adb logcatand this time:3) Enabling permissions
The previous try failed due to permissions, so I went into the watch Settings > Applications > Permissions > Home Assistant > File and multimedia content and chose Allow.
After doing that, a new try:
New error, seems it doesn’t like the format of the .KEY file.
4) Fixing the KEY file
If I understand the code well, here it expects the Base64 only data. But my .KEY file was like so:
So I removed the first 3 lines from the .KEY file having it start with the
-----BEGIN PRIVATE KEY-----text, like so:Copied the file again:
and new try:
5) Fixing the CER file
According to this comment, that exception is raised when the format of the private key is not DER. So I exported the key again, using the correct format and pushed it again to the watch:
New try and…
Whoo hoo! Isn’t that the HTML code of the onboarding page (with login) of Home Assistant? I’m pretty sure it is! So it loaded the TLS Client certificate!
6) Trying to delete the key files
Then I terminated the app with the Galaxy Watch task switcher app and removed the certificate files from the Download folder (actually I moved them in the
oldsubfolder):And I tried relaunching the app to see if it really stores the keys into the
AndroidKeyStore(like the code seems to do).As you can see, it seems it does. The log in fact is missing the:
lines but it still loads the page content (and returns the status code 200).
7) Trying to load a wrong certificate
As a last test, I wanted to try a wrong certificate (actually an expired one). So I uninstalled the app (to clear the keystore), then I reinstalled the APK again, applied the permissions to read files and pushed a formally valid but expired
tls_client.keyandtls_client.crtfiles. Here the results:The certificate is loaded from file but I get a 400 status code, i.e. a “correct” Bad Request (the same that the browser on my PC shows if I use that certificate)!
Final thoughts
So, to me, it seems that the code works. It just have to be updated to have a way to load the certificate from the 2 files (using a file picker or something like that supported on Wear OS) due to the Android API 30 restrictions.
@jpelgrom what do you think about that? Could it be feasible? Hope this helps! 🤞
Hello @virtualdj,
I think for WEAR OS 2 it should be possible to sideload CA files using adb (source). I’m afraid in WEAR OS 3 it is currently not possible (at least for unrooted watches) to sideload CA files (source).
best regards Markus