RFC - one old and one new bluetooth device driver.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC - one old and one new bluetooth device driver.

James
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.


James.

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

hid_2061.patch (87K) Download Attachment
acr_3901.patch (49K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Godfrey Chung-3
Hi James

On Mon, Aug 14, 2017 at 8:53 PM, James <[hidden email]> wrote:

> 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?

You can load the key from Info.plist.

Regards

Godfrey

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

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

James
> You can load the key from Info.plist.

At least on my system, that's world readable

[james@meh ~]$ ls -lZ $(rpm -ql pcsc-lite-ccid | grep Info.plist)
-rw-r--r--. root root system_u:object_r:lib_t:s0       /usr/lib64/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist

and is installed from Makefile.am with

        cp Info.plist $(DESTDIR)$(usbdropdir)/$(CCID_BUNDLE)/Contents/

so takes whatever the distro's default umask is

If you have access to secret key, then it's possible without any special
hardware to capture from the air the BTLE exchange and extract the pin or
indeeed anything else.

An object with similar security properties is a bluetooth link key (for say a
keyboard). Bluetooth stacks either store these in the hardware themselves or in
root-only accessible locations.

J.

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

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

Martin Paljak-4
In reply to this post by James
Cool! Last time I asked OmniKey/HID for a specification of the transport layer, I received silence... The fact that it has simple plaintext communication is probably the reason why it is discontinued.

My only comment would be to make it clear in the patch that these features are  "HID/omnikey" which has nothing to do with HID as https://en.wikipedia.org/wiki/Human_interface_device (because devices like FIDO and Yubikey DO use HID and/or CCID for communication and this could create confusion)

I hope I did not trash the 2061 as a useless reader and can find it to test.

Best,
Martin

On Mon, 14 Aug 2017 at 16:20 James <[hidden email]> wrote:
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.


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

typos expected due to mobile device


_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

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

James
On Wed, Aug 16, 2017 at 06:50:37AM +0000, Martin Paljak wrote:
> Cool! Last time I asked OmniKey/HID for a specification of the transport
> layer, I received silence... The fact that it has simple plaintext
> communication is probably the reason why it is discontinued.
>
> My only comment would be to make it clear in the patch that these features
> are  "HID/omnikey" which has nothing to do with HID as
> https://en.wikipedia.org/wiki/Human_interface_device (because devices like
> FIDO and Yubikey DO use HID and/or CCID for communication and this could
> create confusion)

entirely fair :)

I forgot to mention that both drivers fake the get slot status command
when they can't reach the reader to say the slot is empty, so you can
hot-attach the reader and then pcscd just sees a card insertion.

The ACR3901U driver additionally remembers if the card was powered
and restores this state on reconnect, so things like ssh-agent + pkcs11
work seemlessly.

>
> I hope I did not trash the 2061 as a useless reader and can find it to test.

I may have a spare if you can't find it (i bought more than one), as I think
I'm going to use the ACR3901U-S1 as they're much ligher and smaller and
fallback to usb when the battery is flat.  (They're also cheaper at about $35 )

I didn't bother reverse engineering the windows tool that sets the PIN over
USB as that's a once only operation.


J.



_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

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

Ludovic Rousseau
In reply to this post by James
Hello,

2017-08-14 14:53 GMT+02:00 James <[hidden email]>:
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
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

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

Frank Morgner-2
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 <[hidden email]>:
Hello,

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


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