RFC support for HID Omnikey 2061 Bluetooth reader

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

RFC support for HID Omnikey 2061 Bluetooth reader

James
This is a usb/bluetooth card reader, easily available from ebay &c.

https://www.hidglobal.com/products/readers/omnikey/2061

It has a single bluetooth SPP

Service Name: SPP
Service RecHandle: 0x10000
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100


The protocol (for which i was unable to find any documentation)
is quite simple, after the connexion is set up, CCID packets are sent
with

0xA5 <ccid packet> CHK

CHK is the XOR of all the bytes in the ccid picket, replies are sent
similarly.

With this driver I'm able to use a J3A081 running isoapplet, but
attempts to use cardcontact's smartcard-hsm failed (I think due
to the lack of extended APDUs)

Snooping the communication with the windows software there are a few
reader escapes the purpose of which I've not discovered.

a5 6b 02 00 00 00 00 77 00 00 00 02 00 1c
a5 6b 02 00 00 00 00 78 00 00 00 0c 23 3e
a5 6b 02 00 00 00 00 7b 00 00 00 0c 26 38
a5 6b 06 00 00 00 00 86 00 00 00 2d 00 00 00 00 00 c6
a5 6b 0c 00 00 00 00 87 00 00 00 1a 00 40 07 80 58 00 00 00 00 00 9f fa
a5 6b 06 00 00 00 00 88 00 00 00 2d 01 fe fe 80 00 49
a5 6b 06 00 00 00 00 98 00 00 00 2d 00 00 00 00 00 d8
a5 6b 0c 00 00 00 00 99 00 00 00 1a 00 40 07 80 58 00 00 00 00 00 9f e4

&c.

The patch renames the twin driver file and symbols to include twin in the name.

Ideally I think the rfcomm functionality needs to be in the driver
and it needs to be able to handle bluetooth connect/disconnect without
the need to restart pcscd.

PINs are encrypted only by the bluetooth transport layer, more modern
bluetooth card readers wrap the communication in another layer of AES.

I'm intending to write patches to support one of more popular models of those
as well.

James.





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

0001-Add-support-for-the-HID-OmniKey-2061-bluetooth.patch (87K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC support for HID Omnikey 2061 Bluetooth reader

James
On Mon, Feb 06, 2017 at 10:19:49AM +0000, James wrote:
> This is a usb/bluetooth card reader, easily available from ebay &c.
>
> https://www.hidglobal.com/products/readers/omnikey/2061

This version automatically sets up the rfcomm connexion:

/etc/reader.conf.d/hid2061 might contain

DEVICENAME   00:80:25:XX:XX;XX
FRIENDLYNAME "hid2061"
LIBPATH     /usr/lib64/pcsc/drivers/serial/libccidhid.so

It handles automatic connexion and disconnexion as the
bluetooth device is available or not.

If the bluetooth device is not reachable, it fakes
the replies to GetSlotStatus, so that pcscd is able
to start up.

James.

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

0002-Add-support-for-the-HID-OmniKey-2061-bluetooth.patch (86K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC support for HID Omnikey 2061 Bluetooth reader

Ludovic Rousseau
In reply to this post by James
Hello,

2017-02-06 11:19 GMT+01:00 James <[hidden email]>:
This is a usb/bluetooth card reader, easily available from ebay &c.

https://www.hidglobal.com/products/readers/omnikey/2061

It has a single bluetooth SPP

Service Name: SPP
Service RecHandle: 0x10000
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100


The protocol (for which i was unable to find any documentation)
is quite simple, after the connexion is set up, CCID packets are sent
with

0xA5 <ccid packet> CHK

CHK is the XOR of all the bytes in the ccid picket, replies are sent
similarly.

With this driver I'm able to use a J3A081 running isoapplet, but
attempts to use cardcontact's smartcard-hsm failed (I think due
to the lack of extended APDUs)

Snooping the communication with the windows software there are a few
reader escapes the purpose of which I've not discovered.

a5 6b 02 00 00 00 00 77 00 00 00 02 00 1c
a5 6b 02 00 00 00 00 78 00 00 00 0c 23 3e
a5 6b 02 00 00 00 00 7b 00 00 00 0c 26 38
a5 6b 06 00 00 00 00 86 00 00 00 2d 00 00 00 00 00 c6
a5 6b 0c 00 00 00 00 87 00 00 00 1a 00 40 07 80 58 00 00 00 00 00 9f fa
a5 6b 06 00 00 00 00 88 00 00 00 2d 01 fe fe 80 00 49
a5 6b 06 00 00 00 00 98 00 00 00 2d 00 00 00 00 00 d8
a5 6b 0c 00 00 00 00 99 00 00 00 1a 00 40 07 80 58 00 00 00 00 00 9f e4

6b is PC_to_RDR_Escape
It is used to send a proprietary command to the reader. So without a documentation is will be difficult to know what the commands are doing.
But that is the goal of reverse engineering :-)


&c.

The patch renames the twin driver file and symbols to include twin in the name.

Ideally I think the rfcomm functionality needs to be in the driver
and it needs to be able to handle bluetooth connect/disconnect without
the need to restart pcscd.

PINs are encrypted only by the bluetooth transport layer, more modern
bluetooth card readers wrap the communication in another layer of AES.

I'm intending to write patches to support one of more popular models of those
as well.

Good luck

Bye

--
 Dr. Ludovic Rousseau

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