[Pcsclite-muscle] RFC - one old and one new bluetooth device driver.

[Frank Morgner]

James, you said that regarding the CCID side, the driver is plug and play
(and indeed the common code in ccid.c/ccid.h is almost untouched). So maybe
you can put the bluetooth boiler plate into a seperate driver, linking
against libccid at compile time? This would mean that libccid only needs to
export the some library functions. Alternatively, you could pull the
libccid sources from a submodule at compile time.

Have you also tested the contact-less bluetooth readers from ACS?

2017-08-17 11:01 GMT+02:00 Ludovic Rousseau <ludovic.rousseau at gmail.com>:

> Hello,
>
> 2017-08-14 14:53 GMT+02:00 James <pcsclite at madingley.org>:
>
>> Attached are patches to support the HID Omnikey 2061, and
>> the ACR3901U-S1 bluetooth card readers.
>>
>> ---
>>
>> The HID Omnikey 2061, is end of life but is readily
>> available on eBay. I reverse engineered the protocol
>> from observing the windows drivers. It uses CCID over
>> serial over Bluetooth RFCOMM. As such the pin is not
>> particularly well protected.
>>
>> To use the HID driver, first pair the reader with the
>> computer using your favourite bluetooth stack then create
>> a file in /etc/reader.conf.d/ containing (edit the path
>> and set the DEVICENAME to be the MAC address of the reader)
>>
>> DEVICENAME        00:80:25:33:44:55
>> FRIENDLYNAME      "My HID 2061"
>> LIBPATH           /usr/lib64/pcsc/drivers/serial/libccidhid.so
>>
>> ---
>>
>> The ACR3901U-S1 is in current production and communicates
>> using a stripped down version of CCID over Bluetooth
>> Low-Energy GATT, or CCID over USB. The over-the-air
>> interface is protected by mutual authentication, and
>> encrypted using 128 bit AES CBC using a random session
>> key. The driver implements support for both interfaces.
>>
>> The device requires a 16 byte secret key to be known by
>> the connecting computer, at the moment pcscd doesn't
>> provide a simple way to insert this - (in this patch it's
>> hard coded to the default value). What would be the
>> preffered method of getting this into the driver?
>>
>> To use the ACR driver find the MAC address of the device
>> (use hcitool lescan) on linux
>>
>> and create a file in /etc/reader.conf.d/ containing (edit
>> the path and set the DEVICENAME to be the MAC address of
>> the reader)
>>
>> DEVICENAME        11:22:33:44:55:66
>> FRIENDLYNAME      "My ACR3901U-S1"
>> LIBPATH           /usr/lib64/pcsc/drivers/serial/libccidacr.so
>>
>> For USB operation the drive is plug and play.
>>
>> The ACR driver still outputs some debug output to stderr
>> which should be fixed.
>>
>> The HID driver patch contains support for multiple serial
>> devices, which is used by the ACR driver patch.
>>
>
> Nice job.
>
> I am a bit perplex about what to do with these 2 patches.
> I do not like to add/merge code that diverge too much from the CCID
> specification. And in this case I do not even have the devices to
> test/debug/support the new code.
>
> Also managing shared secrets by pcscd drivers is a new task that should be
> thought about. Using a hard coded (default) key value is not a real
> solution.
>
> It is also a problem of free time and motivation :-)
>
> I propose you to create a fork of my CCID driver at github (or somewhere
> else) so you can maintain your patches and documentation.
>
> Bye,
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> Pcsclite-muscle mailing list
> Pcsclite-muscle at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/attachments/20170817/3669ee0e/attachment.html>