Bug 981954 - A problem with PC/SC library with Athena ASEDrive IIIe USB Cardreader / JaCarta SmartCard (eToken GOST)
A problem with PC/SC library with Athena ASEDrive IIIe USB Cardreader / JaCar...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rdesktop (Show other bugs)
18
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Filak
Fedora Extras Quality Assurance
abrt_hash:e60d9ebcf244f943efce57aed88...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-07 05:17 EDT by Rostislav Suharev
Modified: 2016-11-30 19:44 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 21:09:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Messages log (256.33 KB, application/x-gzip)
2013-07-07 05:21 EDT, Rostislav Suharev
no flags Details
PCSCD --foreground --debug (17.61 KB, text/x-log)
2013-07-07 09:46 EDT, Rostislav Suharev
no flags Details
2400 Bytes received with extended APDU command, then rdesktop dies (78.14 KB, text/plain)
2013-07-29 23:58 EDT, Rostislav Suharev
no flags Details

  None (edit)
Description Rostislav Suharev 2013-07-07 05:17:54 EDT
Description of problem:
2XClient RDP failed to use SD\SC Card.

For repeat this BUG you need hardware:
1. Athena ASEDreive IIIe [Athena CCID] 00 00
2. Rutoken/eToken GOST/JaCarta (with GOST key conainer)

Software installed in terminal server:
1. Windows 2008 R2 (Microsoft RDP Server)
2. CryptoPro 3.6 R3
3. csScript
4. eToken GOST / JaCarta utilities
5. process monitor

Software used to communicate with terminal server:
1. 2XClient (with RDP session)
2. PCSCD 
3. CCID Drivers (CryptoPro 3.6 R3 for Linux contains it in package Rutoken/JaCarta)

In terminal session:
Windows Server logon see readers (ruToken and Athena with smartcard JaCarta) and smartcard but tells that cannot found correct certificates.
CryptoPro 3.6 R3 dosen't view containers in card.
When csScript try to communicate 2XClient RDP connection fails (but not drops until some time).
JaCarta utilities view smartcard and diag util reported that smartcard correct.
Process monitor tells that csScript at this connect try to estabilish direct connection with smartcard \\TSCLIENT\SCARD\2
	
Bug can be reproduced in Debian 7.0 \ Feodora (may be all *nix)

When trying to use Windows RDP Client on Windows XP/Windows 8 station all works fine (certificate found, usable, writable).
Windows XP/8 station conains same software that have terminal server.

Please connect me for additional information if required: desput[at*/]mail.ru

------------

In Linux PC/SC device scanner V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.7.4 reports that all correct (f.e. for RuToken):
0: Aktiv Co. Rutoken S 00 00

Sun Jul  7 03:54:55 2013
 Reader 0: Aktiv Co. Rutoken S 00 00
  Card state: Card inserted, 
  ATR: 3B 6F 00 FF 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00

ATR: 3B 6F 00 FF 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00
+ TS = 3B --> Direct Convention
+ T0 = 6F, Y(1): 0110, K: 15 (historical bytes)
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = FF --> Extra guard time: 255 (special value)
+ Historical bytes: 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00
  Category indicator byte: 00 (compact TLV data object)
    Tag: 5, len: 6 (card issuer's data)
      Card issuer data: 72 75 54 6F 6B 6E
    Tag: 7, len: 3 (card capabilities)
      Selection methods: 30
        - DF selection by path
        - DF selection by file identifier
      Data coding byte: 20
        - Behaviour of write functions: proprietary
        - Value 'FF' for the first byte of BER-TLV tag fields: invalid
        - Data unit in quartets: 1
      Command chaining, length fields and logical channels: 00
        - Logical channel number assignment: No logical channel
        - Maximum number of logical channels: 1
    Mandatory status indicator (3 last bytes)
      LCS (life card cycle): 00 (No information given)
      SW: 9000 (Normal processing.)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 6F 00 FF 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00
	ruToken-S (USB token)
	www.rutoken.ru/products/rutoken/rutoken-s/

*Example for Athena ASEDrive IIIe*:

Scanning present readers...
Waiting for the first reader...found one
Scanning present readers...
0: Athena ASE IIIe [ASEDrive CCID] 00 00

Sun Jul  7 04:09:23 2013
 Reader 0: Athena ASE IIIe [ASEDrive CCID] 00 00
  Card state: Card inserted, 
  ATR: 3B D5 18 00 81 31 FE 7D 80 73 C8 21 10 F4

ATR: 3B D5 18 00 81 31 FE 7D 80 73 C8 21 10 F4
+ TS = 3B --> Direct Convention
+ T0 = D5, Y(1): 1101, K: 5 (historical bytes)
  TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
    129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
  TC(1) = 00 --> Extra guard time: 0
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 
-----
  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 
-----
  TA(3) = FE --> IFSC: 254
  TB(3) = 7D --> Block Waiting Integer: 7 - Character Waiting Integer: 13
+ Historical bytes: 80 73 C8 21 10
  Category indicator byte: 80 (compact TLV data object)
    Tag: 7, len: 3 (card capabilities)
      Selection methods: C8
        - DF selection by full DF name
        - DF selection by partial DF name
        - Implicit DF selection
      Data coding byte: 21
        - Behaviour of write functions: proprietary
        - Value 'FF' for the first byte of BER-TLV tag fields: invalid
        - Data unit in quartets: 2
      Command chaining, length fields and logical channels: 10
        - Logical channel number assignment: by the card
        - Maximum number of logical channels: 1
+ TCK = F4 (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B D5 18 00 81 31 FE 7D 80 73 C8 21 10 F4
	Bank of Lithuania Identification card

	

Version-Release number of selected component:
gnome-abrt-0.2.12

Additional info:
kernel:         3.9.8-100.fc17.i686
type:           libreport
Comment 1 Rostislav Suharev 2013-07-07 05:21:28 EDT
Created attachment 769919 [details]
Messages log
Comment 2 Rostislav Suharev 2013-07-07 05:30:48 EDT
Same error occured with xfreerdp / rdesktop compiled with scard support.
Comment 3 Rostislav Suharev 2013-07-07 08:17:42 EDT
Trying with 'rdesktop' 1.7.1 :

compiled with --enable-smartcard, --with-debug-smartcard

with default settings Windows Terminal Server don't capture smartcard because size is limited in 'scard.c' to 448 bytes.  

Experimentally, i found that maximum length is 2012 bytes, but it was not enough! 4145 desired for JaCarta

SCARD:        Reader: "Athena ASE IIIe [ASEDrive CCID] 00 00"
SCARD:        ATR: 3b:d5:18:00:81:31:fe:7d:80:73:c8:21:10:f4 
SCARD: SCardStatus(hcard: 0x00000004 [0x000131b5], reader len: 128 bytes, atr len: 32 bytes)
SCARD: -> Success (state: 0x00000034, proto: 0x00000002)
SCARD:        Reader: "Athena ASE IIIe [ASEDrive CCID] 00 00"
SCARD:        ATR: 3b:d5:18:00:81:31:fe:7d:80:73:c8:21:10:f4 
SCARD: SCardTransmit(hcard: 0x00000004 [0x000131b5], send: 5 bytes, recv: 260 bytes)
SCARD: -> Success (44 bytes)
SCARD: SCardTransmit(hcard: 0x00000004 [0x000131b5], send: 8 bytes, recv: 18434 bytes)
SCARD: -> Success (345 bytes)
SCARD: SCardTransmit(hcard: 0x00000004 [0x000131b5], send: 8 bytes, recv: 18434 bytes)
WARNING: Card response limited from 4145 to 2012 bytes!
SCARD:    Truncated 4145 to 2012
SCARD: -> Success (2012 bytes)
SCARD: SCardEndTransaction(hcard: 0x00000004 [0x131b5], disposition: 0x00000000)
SCARD: -> Success
SCARD: SCardDisconnect(context: 0x00000003 [0x103e65d], hcard: 0x00000004 [0x131b5], disposition: 0x00000000)
SCARD: -> Success
SCARD: SCardReleaseContext(context: 0x00000003 [0x103e65d])
SCARD: -> Success
SCARD: SCardGetStatusChange(context: 0x00000001 [0x103faec], timeout: 0xffffffff, count: 2)
SCARD:    "\\?PnP?\Notification"
SCARD:        user: (nil), state: 0x00000001, event: 0x00000000
SCARD:    "Athena ASE IIIe [ASEDrive CCID] 00 00"
SCARD:        user: (nil), state: 0x00000022, event: 0x00000000
Comment 4 Rostislav Suharev 2013-07-07 08:30:18 EDT
But for ruToken It is enough! Bingo!!

To developers of pcsc-tools: how to find possible error?

----
Please help me as quite as it possible, it very need for a healthcare poject in Chuvash republic in Russian Federation.
Comment 5 Rostislav Suharev 2013-07-07 09:46:16 EDT
Created attachment 769987 [details]
PCSCD --foreground --debug

when rdesktop failed to connect
Comment 6 Rostislav Suharev 2013-07-07 10:56:19 EDT
Found one comment in early 2006
Today it works with 2012 bytes, but not more. Can anybody help with this magic 448 / 2012 ?

----------------------------------------------------------------------

Comment By: Alexi Volkov (alexi_volkov)
Date: 2006-06-26 07:52

Message:
Logged In: YES 
user_id=1357228

For now there is no way found to correctly transmit answer
of SCardTransmit function call to Windows if receive buffer
length is larger than 448 bytes. In this case Windows simply
stop Smart-Card service and you have to relogin.

I added check of buffer length and hard limit it on 448
bytes before SCardTransmit call. This is temporarily.

If your smart-card worked before this patch it should
continue to work as it uses short buffer lengths.

----------------------------------------------------------------------
Comment 7 Ludovic Rousseau 2013-07-29 16:36:18 EDT
It looks like a rdesktop (or TDP protocol) issue rather than a pcsc-lite issue.
Or even maybe a Windows limitation.

I have no idea where the message "WARNING: Card response limited from 4145 to 2012 bytes!" comes from. It does not come from pcsc-lite itself.
Comment 8 Rostislav Suharev 2013-07-29 23:50:40 EDT
It does not com from pcsc-lite itself, it comes from scard.c from rdesktop. I think that it is a windows limitation. Please look at more detailed log attached.
Comment 9 Rostislav Suharev 2013-07-29 23:58:29 EDT
Created attachment 780324 [details]
2400 Bytes received with extended APDU command, then rdesktop dies
Comment 10 Fedora End Of Life 2013-07-31 21:09:34 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.