Add support for transparent mode

[sidcha]

No description provided.

[mistial-dev]

For this issue, are you looking to add the HID-specific things, or Extended Packet Mode?

It's been a while, but I purchased the v2.1.7 spec (back when it was $30), which IIRC had removed transparent mode and moved it to an appendix. I had requested the appendix but never heard anything back. I ended up finding a 2.1.5 spec somewhere and implementing it from that in the .NET solution I put together.

I'm working on an Open Source Control Panel in Python 3 at the moment, and transparent mode is on the "needs to be done" feature list. It is required in order to do PIV certificate/private key authentication. I remembered libOSDP, and it looks like it will save a lot of development time. No point in reinventing the wheel.

Between the spec I have and the HID OSDP SDK, I could likely add the HID-style transparent mode to libOSDP if that's useful.

[sidcha]

Hey @mistial-dev, I'm looking at v2.2 (or the IEC v1.0) specification when I think about TRS mode. I'm not familiar with the HID-style transparent more nor it's acceptance in industry. Since the official specification has a flavour, I'm guessing that is more authoritative. What is your take on this matter?

That said, any contributions towards this goal is always welcome. :)

PS. please be informed that the python library that comes with this project is a binding to the C library (not native); this may not be the best thing to do in some cases.

[mistial-dev]

I don't have the 2.2 spec, so I can't comment on it.

The earlier versions had a transparent mode that was covered by HID patents.

As I understand it, the Extended Packet Mode was built specifically to avoid the HID patents. The standard I have has the following notice:

The OSDP Specification Appendix E, contains the Behavior Profile 1: Transparent Smartcard Interface 
Support Operations. The profile, located in Appendix E of the specification summarizes a means to 
interact with a reader device. SIA is not responsible for rights clearance and recommends that all 
users of the OSDP Specification consider any applicable third party intellectual property rights in 
connection with implementations that wish to utilize messaging with third party reader devices.
Specifically, the OSDP Specifications address a mechanism for passing messages (APDUs) between 
authentication software and a smartcard transparently, without reader support. This mechanism is 
intended to support FICAM compliant authentication, which may be subject to the following U.S. 
patents, among other intellectual property rights.
1. United States, 6575360, Device and method for personalizing chip cards; and
2. United States, 7853789, Method and system for establishing a communications pipe between 
a personal security device and a remote computer system

PS. please be informed that the python library that comes with this project is a binding to the C library (not native); this may not be the best thing to do in some cases.

That's fine. I'm going to be packaging this as binaries anyway, and the CP software already has autoconf, automake, etc. No worries on that front.

[sidcha]

Okay, now it all comes back to me. I was looped to a discussion with some folks from SIA and they confirmed in that mail thread that the in-spec (v2.2) TRS mode was free from any patent related issues (now I know what they meant). Given that the targeted users are trying to build products out of this, we should try to add support for the royalty free version. I have the specification with me; but just lack the time to get to it. :(

…

On Mon 14. Jun 2021 at 22:29, Mistial Developer ***@***.***> wrote: I don't have the 2.2 spec, so I can't comment on it. The earlier versions had a transparent mode that was covered by HID patents. [image: image] <https://user-images.githubusercontent.com/69981049/121954699-ac68d400-cd24-11eb-92db-1171b3e0cf8f.png> As I understand it, the Extended Packet Mode was built specifically to avoid the HID patents. The standard I have has the following notice: The OSDP Specification Appendix E, contains the Behavior Profile 1: Transparent Smartcard Interface Support Operations. The profile, located in Appendix E of the specification summarizes a means to interact with a reader device. SIA is not responsible for rights clearance and recommends that all users of the OSDP Specification consider any applicable third party intellectual property rights in connection with implementations that wish to utilize messaging with third party reader devices. Specifically, the OSDP Specifications address a mechanism for passing messages (APDUs) between authentication software and a smartcard transparently, without reader support. This mechanism is intended to support FICAM compliant authentication, which may be subject to the following U.S. patents, among other intellectual property rights. 1. United States, 6575360, Device and method for personalizing chip cards; and 2. United States, 7853789, Method and system for establishing a communications pipe between a personal security device and a remote computer system PS. please be informed that the python library that comes with this project is a binding to the C library (not native); this may not be the best thing to do in some cases. That's fine. I'm going to be packaging this as binaries anyway, and the CP software already has autoconf, automake, etc. No worries on that front. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW3LGLTFWAVPXZC6W5ECEDTSZRA3ANCNFSM4RAM7SEA> .

[edgecase14]

I have a project which requires reading PIV fobs in a Linux environment, and may be able to contribute some work on this. If anyone is aware of commercially available door readers which support the standard transparent mode, that might be used for interoperability testing of this feature, please speak up!

[sidcha]

@edgecase14, I'm aware of two commercially available readers manufacturers that support Transparent Mode; most notably HID readers and I can arrange for interoperability testing if we have a PR with an acceptable design.

Commit e8db7e1 on branch trs_dev should be a good starting point if you wish to work on this feature. The idea is that TRS mode should be a plugin feature that has all changes confined to src/osdp_trs.c (much like how file transfer support is added in src/osdp_file.c) and would not impact the rest of the library if CONFIG_OSDP_TRS is not enabled.

As it stands, our testing story is a bit lagging and I'll be focusing my free time on that until it reaches some point of sustenance. Once I'm able to take this up, and no one has already claimed it, I'll remove the "Needs Help" label and work on it myself.

[mistial-dev]

Given that the targeted users are trying to build products out of this, we should try to add support for the royalty free version.

I'm part of a group that's forming (Open Physical Working Group) that's trying to put together reference implementations for PACS manufacturers and integrators to use. We're using PIV as the basis of these reference implementations, and we're going to be relying pretty heavily on transparent mode.