[knx] Allow decoding of KNX Data Secure frames

[holgerfriedrich]

• add passive (listening only) access for KNX Data Secure frames, [knx] support for KNX secure #8872
• add config options for KNX keyring file and password
• ease setup if IP Secure, as required parameters can be read from keyring
• add tests for security functions
• update user documentation

Signed-off-by: Holger Friedrich [email protected]

[holgerfriedrich]

This PR brings support to KNX IP secure, and partial support for KNX data secure (listening only). See previous discussions in #8872.

What has been tested:

• Secure tunneling, seems to work fine for a few days

What is to be tested by someone else:

• Secure routing (don't have a secure router at hand)

[holgerfriedrich]

@kaikreuzer I followed your advise and have only included the passive support for data secure. Outgoing writes and poll requests for secure group adresses are dropped at lowest level.

Though, when I change a switch connected to a secure GA, the event log still shows the "Item ... predicted to become ..." (which of course will not happen as I drop the write). Is there a clean way to signal a failed write to the upper layer? Throwing an exception is probably too much, as it gets logged with a full stack trace.

[J-N-K]

Wouldn't it make sense to add that directly to the JSON database (i.e. add the file content directly here instead of a filename).

[holgerfriedrich]

@J-N-K thanks for looking into this. I am not sure. At least there are a few practical reasons to keep it as a separate file:

• keyring files need to be replaced everytime you add devices or secure group adresses, this is much easier if you can copy it over using scp
• Calimero Keyring expects an URI for a file location, and does not provide other constructors besides Keyring::load()
• Keyring files contain a signature, which might be invalid if we use a copy-paste approach here....

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/knx-secure-initial-implementation/134133/1

[holgerfriedrich]

@slueder
During the last days, I tried to factor out everything which was not related to the feature itself. Give me a few days until I have a "release candidate" to test.

Not sure about the problem with Keyring files you mentioned in #8872. I have added several keyrings to the tests in this PR, all working fine. Spaces may be a problem, the code uses trim() to strip whitespace (maybe I will remove that).
Overall, for the first merge it might be way to remove the whole keyring stuff and go for the password parameters. If we cannot find out why keyrings are not working for you, this will be the way. Though, for me the keyring is working fine and gives the additional benefit that openHAB can listen to and decode data secure GAs as well....

Which branch did you use for your testing?

[slueder]

@holgerfriedrich

I retested the keyring approach with the latest version of ETS (6.0.4) and reasonably strong keyring export passwords (8 characters, consisting of upper & lower letters, digits and a limited set of special chars :#,;) and it worked now.

I am using commit ID holgerfriedrich@c7114f5

Happy to re-test as soon as you let me know.

[lsiepel]

TLDR: It would allow an attacker to have full access to the bus IF he has physical (wired or radio frequency) or network-based (breach a firewall, create a VPN tunnel …) access. This keyring only stores keys required for de- and encrypting secured KNX telegrams.

Thanks for the extensive outline. My concerns are not toward the KNX bus, adding this security is an imrovement eitherway, totally agree. You confirmed the thoughts i had.
My concern are that this keyring would also be a store to other secrets. But as you confirmed it is exclusive to KNX, i'm fine and let's move forward.

[florian-h05]

Just FYI you program KNX using a program called ETS and the keyring required here is exported from the ETS, it’s the same keyring that allows the ETS full access to the KNX bus.

[lsiepel]

@holgerfriedrich did this PR get some test mileage on different installations ?

[holgerfriedrich]

@lsiepel unfortunately not yet, at least not after the rebase and latest modifications.

I typically deploy to RPI, and I am using Enertex IP interface (connected via IP, with IP secure), Weinzierl 730 (IP w/o IP secure), or Weinzierl kBerry (RPI hat, using serial connection).

Give me some time to double check that data secure (decoding incoming encrypted frames) still works as expected.....

[lsiepel]

Left two comments. LGTM, but ift would also be nice of @J-N-K and @florian-h05 to confirm.

[florian-h05]

I am currently busy till beginning of October, but then should be able to review.

[lsiepel]

LGTM, let's wait for @florian-h05's review before merge.

[holgerfriedrich]

Accidentally pushed to this PR when working on a followup PR, rolled back, rebased to current main as a force push was anyway necessary.
Sorry for the noise.

[florian-h05]

Code LGTM, thanks! Just one minor comment:

I would have loved to give it a try, but I don't have KNX Data nor IP Secure devices.
I have of course tested it against my system - everything still works as expected.

[florian-h05]

@lsiepel You can merge now 🚀