Other Parts Discussed in Thread: CC1310
Hello all,
I am working on a product that needs to receive WMBus measurements. We have a working prototype using the two processor solution where the main processor talks with the CC1310 running the image supplied by TI Serial_CC13xx_Collector_T2 from https://www.ti.com/tool/WMBUS.
We got a version to work that can communicate with the StackForce SATP commands by adding a meter to the internal meter list with its address and encryption key. Now we want to look into receiving the encrypted frames and doing decryption ourselves to meet a customer requirement. In SATP there is the command SATP_APL_COL_ATTRIBUTE_SET_PROPERTY, with this command we enable Enhanced installation mode. In this mode we receive the indication SATP_APL_COL_INDICATION_NEW_METER. We are receiving the SATP_APL_COL_INDICATION_NEW_METER at the same frequency we were receiving the SATP_APL_COL_INDICATION_RX before when we were doing decryption in the SATP stack with the expected meter addresses.
So far so good, the problem now is that we don't get enough bytes in the SATP_APL_COL_INDICATION_NEW_METER indication to use AES on. When we parse the TPL header received it seems a valid WMBus frame TPL header with an control information field of `0x7A`, an encryption mode of 5 and 4 encrypted blocks. 4 encrypted blocks should mean that the payload is 64 bytes, the amount of payload left in the SATP frame is 59 bytes. We have this problem for both meters we are testing with. The code that parses the header and tries to decrypt has been tested with the OMS example (https://oms-group.org/fileadmin/files/download4all/specification/Vol2/4.3.3/OMS-Spec_Vol2_AnnexN_D103.pdf) so we're confident that we did IV construction correctly and are using AES in the correct mode.
We padded the frame with zero bytes to see if AES could decrypt the first blocks but that was also unsuccessful. For the type of message we are using should the first 2 bytes of the plaintext of the encrypted payload be 0x2F2F and that isn't the case with the payloads we do receive.
Another problem we see is that we are not just missing the 5 bytes to complete the payload. When using decryption on the CC1310 the payload of one of our meters is usually 96 bytes decrypted while the encrytped payload in the TPL header is 64 bytes and in the SATP frame is 59 bytes. This can indicate that we aren't receiving the SND-NR frames we are expecting to receive there but Control field byte isn't part of the header send with the frame in the SATP_APL_COL_INDICATION_NEW_METER indication while it is part of the frame for the SATP_APL_COL_INDICATION_RX indication.
Our end goal is to be able to decrypt SND-NR frames ourselves to get to the measurement data while using an WMBus Serial T2 Collector image. Our questions to get there are:
- What are the bytes we are receiving in the payload of the SATP_APL_COL_INDICATION_NEW_METER indication after the ELL, AFL, TPL headers?
- Can you know what the C field value was for a frame received via SATP_APL_COL_INDICATION_NEW_METER?
- Can you receive all WMBus frames still encrypted using Enhanced installation mode, SATP_APL_COL_INDICATION_NEW_METER and the Serial Collector T2 image? And if not all can you receive the SND-NR frames? Can you do it by using another image?
I can supply more information or logic analyzer traces if the questions aren't clear.
Kind regards,
Harmjan