Solution for password protection in Apple HomeKit homes?

[drumdum]

Hi philippe44,

first of all I want to thank you for this great application that I have been using on a daily basis for years.

After getting more and more iPads and other Apple devices, Airplay gets more important. Until now I used the Airplay (SONOS) devices solely with LMS-Raop. This works very stable. Now they may be also used with the apple devices directly. With kids this imposes situations where sound is played on these devices, when it should not be done. Apple HomeKit has the solution for this, as you can add the Airplay devices to a home in HomeKit and password protect it. This works flawlessly.

There is just one thing, LMS-Raop is not capable of playing on password protected Airplay devices. It would be great if that could implemented. Well it is already mostly implemented in a fork of libraop (https://github.com/Schlaubischlump/RAOP-Player-bindings). I changed the players python code in that repo a bit and could verify that it is possible to play sound on password protected Airplay devices, that are added to a HomeKit home, using the libraop. Based on that repo I changed the latest libraop code already and could provide the changes as a pull request. It is not needed to implement Airplay2 as I first thought.

What is still missing is the LMS-Raop part. For me it would be sufficient to have a -tag within the config.xml. I already tried to implement it, but unfortunately my C-knowledge is too rusted to get it done on my own. As I don't know how long the password might be, I think it is best to have a dynamic length, although the passwords from HomeKit are always 6 digits long. But this pointer arithmetic is what I cannot manage.

I would greatly appreaciate some help in this topic to be able to use this application with an even bigger feature set.

[philippe44]

Can you point me where the protocol of when using a password is detailed? I saw the changes in the fork you linked, but I'd like to not just copy code w/o making sure it is covering all aspects of the protocol.

[drumdum]

As you surely know it is not that easy to get information on the Apple protocols. I stumbled upon the owntone-server as there the password authentication was implemented in version 28.6 in March 2023 (https://github.com/owntone/owntone-server/commit/e437e418701785b8bd27614e389130cfe2d98cca). This and the changes made by Schlaubischlump for your libraop are the only real solutions that I could find using password protected Airplay.

[philippe44]

I guess that this https://nto.github.io/AirPlay.html#passwordprotection

[drumdum]

Yes I would guess as well.

[philippe44]

I've added a preliminary version in the dev repository (see LMS forum to know how to access it). The password is set in the LMS interface, once you selected the player you want to protect. Let me know if it works for you.

[drumdum]

Thank you for your very quick response. Unfortunately it does not yet work. I attached a full log of the password protected Airplay device starting a playback in LMS.

If there is anything else that you need, I will provide it as long as I can.

raopbridge.log

[philippe44]

What device is that? I tested successfully on an old AirPort Express.

[philippe44]

Can you also set a password using LMS and send your bridge xml config and tell me the password so I can verify it decrypts properly?

[drumdum]

Okay, I now tested it with the Schlaubischlump python player and took the logs from that. This plays sound on the password protected airplay device. It is a IKEA Table Lamp (SONOS).

raop_play.txt

One difference is, that the second attempt in the WWW-Authenticication sends an empty realm, but I could not verify that this is the right point to start from. Maybe this is not from interest.

The passwords was set in LMS and is 940261. The corresponding config.xml is this raopbridge.xml.txt

[philippe44]

I think the issue is with the password calculation in the plugin. Something is wrong there. According to the RFC, the realm must be indicated in further RTSP sending. I don't know why it's not sent in the @Schlaubischlump version, it feels like a parsing issue with the initial response. BTW, can you try my original cliraop? It should work with password now as well (see command line options)

[drumdum]

Yes, with your cliraop it works just like with my previous solution.

[philippe44]

So that proves this is an issue with password storage on the Perl plugin

[philippe44]

oh well, should work better now. You might have to uninstall the current version

[drumdum]

Perfect, now it works like a charm. Thank you for the quick implementation.