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

Ludovic Rousseau <[email protected]> Thu, 17 Aug 2017 11:01:44 +0200
Newsgroups gmane.comp.lib.muscle
Message-ID <CAGstE8AkqBjU5tqXXdm4k+sK-Y=gV5G9kJ2m0YhXOA2appDqyA@mail.gmail.com>
--===============8759206592686537120==
Content-Type: multipart/alternative; boundary="94eb2c1af9f8e8689a0556ef43f0"

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

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

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

<div dir=3D"ltr">Hello,<br><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2017-08-14 14:53 GMT+02:00 James <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank">pcsclite@madingley=
.org</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 support 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/<wb=
r>serial/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/<wb=
r>serial/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>Nice job.<br><br></div><div>I am a bit perplex about what to do wi=
th these 2 patches.<br></div><div>I do not like to add/merge code that dive=
rge too much from the CCID specification. And in this case I do not even ha=
ve the devices to test/debug/support the new code.<br></div><div><br>Also m=
anaging shared secrets by pcscd drivers is a new task that should be though=
t about. Using a hard coded (default) key value is not a real solution.<br>=
<br>It is also a problem of free time and motivation :-)<br clear=3D"all"><=
/div></div><br></div><div class=3D"gmail_extra">I propose you to create a f=
ork of my CCID driver at github (or somewhere else) so you can maintain you=
r patches and documentation.<br><br></div><div class=3D"gmail_extra">Bye,<b=
r><br></div><div class=3D"gmail_extra">-- <br><div class=3D"gmail_signature=
" data-smartmail=3D"gmail_signature">=C2=A0Dr. Ludovic Rousseau</div>
</div></div></div>

--94eb2c1af9f8e8689a0556ef43f0--


--===============8759206592686537120==
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
--===============8759206592686537120==--