Create support for knx data secure

[nanosonde]

KNX Data Secure is important for open media like RF or PL.

KNX Data Secure basically adds additional APCI type which signals secure data packets.
The secure data packets then contain the normal application layer packets (nested) with their well-known APCI types. The existing application layer can be reused.
See figure.

The Calimero project also added support for KNX data secure recently.

Latest KNX spec. (AN192?, not publicy available yet) also contains the specification of the so called "security proxy" which is supposed to be part of the KNX TP/RF coupler.
Is allows to translate between unsecure older existing devices and KNX-RF secure devices.

Example encryption steps: here
The proxy adds and removes the outer secure frame of the normal application layer payload.

[thelsing]

One of the main problem is to choose an aes implementation.

[thelsing]

Found https://github.com/kokke/tiny-AES-c .
Next step implement example encryption steps above with tiny-AES-c (or any other small c(++) aes lib)

[nanosonde]

@thelsing
Looks good.

I will try to implemented the encryption/decryption with tiny-AES based on the example.
The example shows an TP1 extended frame telegram:

• A_PropertyValueWrite() to object index 5, PID: 0x35(53)
• SRC: FF67, DST: FF00 (DST seems to be line coupler, because of 0x00)

ADATA is "associated data" and PDATA is "payload data". Terms used within AES-CCM.

[nanosonde]

KNX Data Secure also does NOT use a new mask version.
Instead the presence of the "Security Interface Object" indicates the support KNX Data Secure support. Also good news. :)

And also everything related to E-mode device (e.g. SeqNo sync for E-mode) could be left out for now. So only S-mode tool access SeqNo (sync service) handling would be ok for now if I understand it correctly.

[nanosonde]

Important note:
The draft spec does NOT contain the most recent information concerning data secure.

• the SCF field has changed the bits slightly (slide no. 10, see below)
• the block B0 also contains the APCI directly after the TPCI instead 0x00.

Details see here in this presentation.

[nanosonde]

Just some info.

The "Factory Default Setup Key" (FDSK) entered in ETS is just BASE32 encoded binary data which contains the KNX serial number and the 16 bytes of the toolkey (AES-128).

Example can be found here and here.

6 times 6 characters entered into the ETS lead to 36 chars where each char encodes 5 bit: 36*5=180Bit.
However:
(6bytes serial number +16 bytes toolkey) * 8 = 176 Bits.
What about the remaining 4 bit?
There also seems to be some simple checksum, when entering random characters, ETS will tell that the FDSK does not seem to be valid.
Last character (5bit) seems to contain the 4-bit checksum.

[nanosonde]

Another finding:
The S-A_Sync-service does not work exactly as described in the draft spec.
See page 13 on these slides.

[nanosonde]

Prerequite to support data secure:

• Fix broadcast/systembroadcast Properly handle SystemBroadcast communication on closed media #60
• Add function properties (PDT_FUNCTION) Add support for function properties #63
• Add FunctionsPropertyExtCommand (0x1D4), FunctionPropertyExtStateRead (0x1D5), FunctionPropertyExtStateResponse (0x1D6)
• Add PropertyValueExtWriteCon, PropertyValueExtWriteUnCon, PropertyValueExtWriteConResponse, PropertyValueExtRead, PropertyValueExtReadResponse

[nanosonde]

6 times 6 characters entered into the ETS lead to 36 chars where each char encodes 5 bit: 36*5=180Bit.
However:
(6bytes serial number +16 bytes toolkey) * 8 = 176 Bits.
What about the remaining 4 bit?
There also seems to be some simple checksum, when entering random characters, ETS will tell that the FDSK does not seem to be valid.
Last character (5bit) seems to contain the 4-bit checksum.

1. Build octet stream 6 bytes serial number + 16 bytes toolkey
2. calculate CRC-4 with polynom x^4+x+1 of the octet steam (176 bits = 22 bytes)
3. Attach the CRC-4 checksum (4 bits) to this octet stream at the end
4. calculate base32 representation of the octet stream to get the FDSK which is printed on the device.
5. Optionally, generate QR code version 2 (25x25) with ECC error correction level M

[thelsing]

Is there nothing in the spec about this?

[nanosonde]

It is, already implemented. 😀

https://github.com/thelsing/knx/pull/66/files#diff-00d45c6727ed3cf62043739242374959

[nanosonde]

#66

I think I have reached a state that should be merged.
My test setup:

• ETS 5.7.4
• hand-crafted knxprod with schema 20 (based on knx-demo). CreateKnxProd has to be modified: Empty "ReplaceVersions" cannot be parsed by ETS.
• bau57b0 (IP) code is used, but with a fake mask of 07b0 to simultate TP device connected over IP router.
• Assigning IA is working
• Programming application is working
• master reset is working
• Device starts to send out encrypted group communication (knx-linux demo code). For this the group address had to be set with enabled security.
• to get all this working, the following specifications had to be implemented (partly) too:
  • AN163 “Extended Interface Object Addressing”
  • AN177 “Extended Memory Services”
  • ANxxx “Master Reset”
• missing, although mandatory:
  • AN170 “Group Object Diagnostics”
  • AN192 “Access Policies” (no plan to implement this from my side for DIY devices)

[thelsing]

Already merged.