Zephyr: Add support for Open Supervised Device Protocol (OSDP)

[cbsiddharth]

Introduction

This is an RFC on adding support for OSDP in Zephyr upstream.

In many real world applications, certain devices are meant to be fully supervised by master devices. Lack of a proper standardization between such hardware has resulted in fragmentation and interoperability between such hardware made by different vendors. OSDP is an upcoming industry standard intended to improve interoperability between such products.

These supervised, peripheral devices are able to expose components they have, such as LED, Buzzer, keypad, etc., over OSDP to be controlled by a controlling unit.

Detailed RFC

OSDP describes the communication interface one or more Peripheral Devices (PD) to a Control Panel (CP). The specification describes the protocol implementation over a two-wire RS-485 multi-drop serial communication channel. Nevertheless, this protocol can be used to transfer secure byte stream over any physical channel in low memory embedded devices.

Although OSDP is steered towards the Access and Security industries, it can be used as a general communication protocol for devices in a secure way without too much resource requirements. The security is not top-notch (AES-128) but it is reasonable enough, given that the alternative is no security at all.

OSDP Supports the control of the following components on a PD:
- LED
- Buzzer
- Keypad
- Output (GPIOs)
- Input Control (GPIOs)
- Displays
- Device status (tamper, power, etc.,)
- Card Reader
- Fingerprint Reader

Apart from the registered commands/replies, vendors are allowed to add additional command specific for their hardware/application.

Features:
- Supports secure channel with AES-128
- Can expose multiple hardware components per PD over OSDP
- Supports up to 127 PDs in one bus

Proposed change (Detailed)

Initially, I would like to add support for PD mode of operation, as this the most common requirement from an embedded hardware perspective. I will work on CP mode soon after.

For the time being, I have added this change under drivers/osdp/ (here) and exposed the header at include/drivers/osdp.h (here). Based on comments received in this thread, I will re-work and raise PR for this change.

Things to be noted:

The OSDP specification document is available from SIA website for _purchase_ for $30. I got in touch with them after purchase to understand the nature of licensing of this protocol as the specification is not freely available. Apparently, they've chosen monetize the document but the protocol itself is fully free and open.

They've confirmed that, I'm free to share the document with any number of developers privately (over email) but said that they would prefer not making it available readily (by uploading it to some repository). I know this sounds a little off but, I guess they still want keep monetizing on the document. Let me know if anyone needs a copy of the OSDP specification.

[cbsiddharth]

CC - @galak, @erwango, @Mani-Sadhasivam

[Oanerer]

I will be following this development with great interest - in particular the CP implementation - and will try to contribute where possible.

[erwango]

I think that main point to be discussed is the following:

The OSDP specification document is available from SIA website for purchase for $30.

Tagging TSC and Licensing so this could be discussed at requested level.

[cbsiddharth]

@erwango, Yes that is a point of concern. Infact, I started this work sometime back and didn't raise a PR/Issue here due to this issue. Now that I have a go-ahead from SIA, thought it must be okay; but yes, we do need someone with Software Licensing experience to shed some light on this.

[cbsiddharth]

@Oanerer, https://github.com/cbsiddharth/libosdp has an implementation of CP if you are interested. This library is being designed to run on user space Linux so needs some re-work before getting in here.

[cbsiddharth]

@erwango, When can we expect something from TSC/Licensing?

[erwango]

@erwango, When can we expect something from TSC/Licensing?

@MaureenHelm ?

[cbsiddharth]

@MaureenHelm ?

[r2r0]

I also will follow this closely and I hope will be able to add some support in a few months.

[pfalcon]

I see that @d3zd3z, security matters contact for Zephyr, isn't in cc:, so mentioning him.

[pfalcon]

I have added this change under drivers/osdp/ (here) and exposed the header at include/drivers/osdp.h (here). Based on comments received in this thread, I will re-work and raise PR for this change.

For me, stuff like that doesn't seem like "driver". Example of a driver: LED driver for STM32, that directly drives hardware, and is hardware specific, compare that with the code you have there. For me, it looks more like a "subsystem" or "library" (because we can't have number of subsystems growing infinitely). But that's just 2 cents FYI, shouldn't be reworked unless ack'ed by somebody else.

[pfalcon]

When can we expect something from TSC/Licensing?

@cbsiddharth, note that you can (try to) bring the matter before TSC yourself. There may be a better procedure described somewhere, but following should work: post a request present this matter to https://lists.zephyrproject.org/g/tsc, then hopefully get an ack and join next online TSC meeting to speak it up. (Or maybe get a notice that agenda for next meeting is booked up, so it would one after next meeting.)

[Mani-Sadhasivam]

When can we expect something from TSC/Licensing?

@cbsiddharth, note that you can (try to) bring the matter before TSC yourself. There may be a better procedure described somewhere, but following should work: post a request present this matter to https://lists.zephyrproject.org/g/tsc, then hopefully get an ack and join next online TSC meeting to speak it up. (Or maybe get a notice that agenda for next meeting is booked up, so it would one after next meeting.)

It got approved by TSC I believe.

[cbsiddharth]

@pfalcon, this request did go through the TSC and I got a go ahead on the implementation. @d3zd3z is aware of this. See: https://lists.zephyrproject.org/g/tsc/message/427

[carlescufi]

@cbsiddharth are you still planning to submit this functionality?

[cbsiddharth]

@carlescufi, I've been a little occupied lately. But I plan on getting back to this ASAP.

As for this issue, you can either leave it open, or close it so I can re-open when I raise the PR. Thanks for keeping track of this.