Re: RFC - one old and one new bluetooth device driver.

--===============1161992062552205015==
Content-Type: multipart/alternative; boundary="94eb2c048cb4ed12cc0556f8e6db"

--94eb2c048cb4ed12cc0556f8e6db
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]>:

> Hello,
>
> 2017-08-14 14:53 GMT+02:00 James <[email protected]>:
>
>> 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
> [email protected]
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>

--94eb2c048cb4ed12cc0556f8e6db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">James, you said that regarding the CCID side, the driver i=
s plug and play (and indeed the common code in ccid.c/ccid.h is almost unto=
uched). So maybe you can put the bluetooth boiler plate into a seperate dri=
ver, linking against libccid at compile time? This would mean that libccid =
only needs to export the some library functions. Alternatively, you could p=
ull the libccid sources from a submodule at compile time.<div><br></div><di=
v>Have you also tested the contact-less bluetooth readers from ACS?</div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-08-17 11=
:01 GMT+02:00 Ludovic Rousseau <span dir=3D"ltr">&lt;<a href=3D"mailto:ludo=
[email protected]" target=3D"_blank">[email protected]</a>&gt=
;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">2017-08-14 14:53 GMT+02:00 James <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:[email protected]" target=3D"_blank">[email protected]</a>&=
gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Attached are patches to suppo=
rt the HID Omnikey 2061, and<br>
the ACR3901U-S1 bluetooth card readers.<br>
<br>
---<br>
<br>
The HID Omnikey 2061, is end of life but is readily<br>
available on eBay. I reverse engineered the protocol<br>
from observing the windows drivers. It uses CCID over<br>
serial over Bluetooth RFCOMM. As such the pin is not<br>
particularly well protected.<br>
<br>
To use the HID driver, first pair the reader with the<br>
computer using your favourite bluetooth stack then create<br>
a file in /etc/reader.conf.d/ containing (edit the path<br>
and set the DEVICENAME to be the MAC address of the reader)<br>
<br>
DEVICENAME=C2=A0 =C2=A0 =C2=A0 =C2=A0 00:80:25:33:44:55<br>
FRIENDLYNAME=C2=A0 =C2=A0 =C2=A0 &quot;My HID 2061&quot;<br>
LIBPATH=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/lib64/pcsc/drivers/ser=
ia<wbr>l/libccidhid.so<br>
<br>
---<br>
<br>
The ACR3901U-S1 is in current production and communicates<br>
using a stripped down version of CCID over Bluetooth<br>
Low-Energy GATT, or CCID over USB. The over-the-air<br>
interface is protected by mutual authentication, and<br>
encrypted using 128 bit AES CBC using a random session<br>
key. The driver implements support for both interfaces.<br>
<br>
The device requires a 16 byte secret key to be known by<br>
the connecting computer, at the moment pcscd doesn&#39;t<br>
provide a simple way to insert this - (in this patch it&#39;s<br>
hard coded to the default value). What would be the<br>
preffered method of getting this into the driver?<br>
<br>
To use the ACR driver find the MAC address of the device<br>
(use hcitool lescan) on linux<br>
<br>
and create a file in /etc/reader.conf.d/ containing (edit<br>
the path and set the DEVICENAME to be the MAC address of<br>
the reader)<br>
<br>
DEVICENAME=C2=A0 =C2=A0 =C2=A0 =C2=A0 11:22:33:44:55:66<br>
FRIENDLYNAME=C2=A0 =C2=A0 =C2=A0 &quot;My ACR3901U-S1&quot;<br>
LIBPATH=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/lib64/pcsc/drivers/ser=
ia<wbr>l/libccidacr.so<br>
<br>
For USB operation the drive is plug and play.<br>
<br>
The ACR driver still outputs some debug output to stderr<br>
which should be fixed.<br>
<br>
The HID driver patch contains support for multiple serial<br>
devices, which is used by the ACR driver patch.<br></blockquote><div><br></=
div></div></div><div>Nice job.<br><br></div><div>I am a bit perplex about w=
hat to do with these 2 patches.<br></div><div>I do not like to add/merge co=
de 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.<br></div><di=
v><br>Also managing shared secrets by pcscd drivers is a new task that shou=
ld be thought about. Using a hard coded (default) key value is not a real s=
olution.<br><br>It is also a problem of free time and motivation :-)<br cle=
ar=3D"all"></div></div><br></div><div class=3D"gmail_extra">I propose you t=
o create a fork of my CCID driver at github (or somewhere else) so you can =
maintain your patches and documentation.<br><br></div><div class=3D"gmail_e=
xtra">Bye,<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></s=
pan></div><span class=3D"HOEnZb"><font color=3D"#888888"><div class=3D"gmai=
l_extra">-- <br><div class=3D"m_-1958395027410864029gmail_signature" data-s=
martmail=3D"gmail_signature">=C2=A0Dr. Ludovic Rousseau</div>
</div></font></span></div></div>
<br>______________________________<wbr>_________________<br>
Pcsclite-muscle mailing list<br>
<a href=3D"mailto:[email protected]">Pcsclite-muscle@=
lists.alioth.<wbr>debian.org</a><br>
<a href=3D"http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite=
-muscle" rel=3D"noreferrer" target=3D"_blank">http://lists.alioth.debian.<w=
br>org/cgi-bin/mailman/listinfo/<wbr>pcsclite-muscle</a><br></blockquote></=
div><br></div>

--94eb2c048cb4ed12cc0556f8e6db--


--===============1161992062552205015==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pcsclite-muscle mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
--===============1161992062552205015==--