search

goToMain / libosdp

Implementation of IEC 60839-11-5 OSDP (Open Supervised Device Protocol); provides a C library with support for C++, Rust and Python3
https://libosdp.sidcha.dev
Apache License 2.0
138 stars 71 forks source link

PD behaviour in secure mode for commands with no defined command structure #49

Closed prxvm closed 3 years ago

prxvm commented 3 years ago

Describe the bug The secure session gets discarded due to "failed" decryption upon receiving commands that have no command structure defined in the spec. Such commands are LSTAT, OSTAT, RSTAT, ISTAT. These simply instruct the PD to reply based on the command code.

Expected behavior Secure mode should not be discarded

Observed behavior It is observed that secure session gets discarded when PD receives CMD_LSTAT in secure mode, due to decrypt function osdp_decrypt_data returning 0.

Additional context Looking at the spec, the commands LSTAT, OSTAT, RSTAT, ISTAT have no command structure (i.e. no data to go along with the command), and could potentially have no decrypted data to work with. I think this is why returned length from osdp_decrypt_data is 0. Because the caller in osdp_phy_decode_packet considers 0 return value to be a failure scenario, this causes a secure session reset.

To be more specific, the decrypted data block for LSTAT looks like 80000000000000000000000000000000 which indicates that there is no data available, just the padding 0x80 to indicate end of message. So I don't think it is necessary to fail here.

I propose either removing the equality condition for all, or making an exception for just those four commands.

sidcha commented 3 years ago

To be more specific, the decrypted data block for LSTAT looks like 80000000000000000000000000000000 which indicates that there is no data available, just the padding 0x80 to indicate end of message. So I don't think it is necessary to fail here.

@prxvm, According to the specification (v2.1.6, section D.3.2.1 and D.3.2.2) if a command or reply has no data, it should use SCS_15/SCS_16 and not SCS_17/SCS_18. You can see that LibOSDP handles this correctly while sending and receiving.

Is this a commercially available PD that has this issue? If that is the case and it is widely used, we add a macro switch to allow this.

prxvm commented 3 years ago

@cbsiddharth this was observed a commercial panel. you are right this packet should not have been sent with SCS_17, but alas. Thank you.