Create support for knx data secure about knx HOT 13 CLOSED

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

from knx.

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)

from knx.

@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.

from knx.

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.

from knx.

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.

from knx.

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.

from knx.

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

from knx.

Prerequite to support data secure:

• Fix broadcast/systembroadcast #60
• Add function properties (PDT_FUNCTION) #63
• Add FunctionsPropertyExtCommand (0x1D4), FunctionPropertyExtStateRead (0x1D5), FunctionPropertyExtStateResponse (0x1D6)
• Add PropertyValueExtWriteCon, PropertyValueExtWriteUnCon, PropertyValueExtWriteConResponse, PropertyValueExtRead, PropertyValueExtReadResponse

from knx.

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

from knx.

Is there nothing in the spec about this?

from knx.

It is, already implemented. 😀

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

from knx.

#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)

from knx.

Already merged.

from knx.