Hello,
I've started playing with an Aladdin eToken PRO using latest releases of
openct and opensc on FreeBSD, but I'm encountering strange behaviours on
concurrent accesses. I'd like to understand how locking works in opensc
and if these are expected behaviours or real bugs. Single access works
like a charm, no problems.
First scenario: PKCS#11 lib with lock_login = true
1) start thunderbird
2) read an encrypted message (it asks user pin and decrypt the message)
3) start pkcs11-tool -I (correctly it fails)
pkcs15.c:676:sc_pkcs15_bind: sc_lock() failed: Generic reader error
pkcs15.c:678:sc_pkcs15_bind: returning with: Generic reader error
Cryptoki version 2.11
Manufacturer OpenSC Project (www.opensc-proje
Library smart card PKCS#11 API (ver 1.0)
pkcs15.c:676:sc_pkcs15_bind: sc_lock() failed: Generic reader error
pkcs15.c:678:sc_pkcs15_bind: returning with: Generic reader error
pkcs15.c:676:sc_pkcs15_bind: sc_lock() failed: Generic reader error
pkcs15.c:678:sc_pkcs15_bind: returning with: Generic reader error
4) now thunderbird cannot use the token anymore, it fails using the
PKCS#11 lib and cannot decrypt the same previous message (and this
doesn't seem correct to me, locking the card should avoid any
compromissions from other tools trying to access it)
Second scenario: PKCS#11 lib with lock_login = false
1) start thunderbird
2) read an encrypted message (it asks user pin, but fails to decrypt the
message, the PKCS#11 lib is unusable)
3) pkcs11-tool works correctly and displays all the info requested
After these tests on PKCS#11 lib, I tried concurrent accesses directly
with pkcs15-tool. Single call to 'pkcs15-tool -D' correctly identify the
card and shows the objects stored in the token, but launching two
processes has the following effect:
One process (correctly) fails with:
%pkcs15-tool -D
Failed to lock card: Generic reader error
and the other with:
%pkcs15-tool -D
card-cardos.c:225:cardos_check_sw: p1/p2 invalid
iso7816.c:129:iso7816_read_binary: returning with: Incorrect parameters
in APDU
card.c:439:sc_read_binary: returning with: Incorrect parameters in APDU
card.c:424:sc_read_binary: sc_read_binary() failed: Incorrect parameters
in APDU
card-cardos.c:225:cardos_check_sw: file not found
iso7816.c:458:iso7816_select_file: returning with: File not found
card-cardos.c:401:cardos_select_file: returning with: File not found
card.c:563:sc_select_file: returning with: File not found
pkcs15-postecert.c:336:sc_pkcs15emu_postecert_init: Failed to initialize
Postecert and Cnipa emulation: Unsupported card
card-cardos.c:225:cardos_check_sw: file not found
iso7816.c:458:iso7816_select_file: returning with: File not found
card-cardos.c:401:cardos_select_file: returning with: File not found
card.c:563:sc_select_file: returning with: File not found
card-cardos.c:225:cardos_check_sw: file not found
iso7816.c:463:iso7816_select_file: returning with: File not found
card-cardos.c:401:cardos_select_file: returning with: File not found
card.c:563:sc_select_file: returning with: File not found
pkcs15.c:711:sc_pkcs15_bind: returning with: Unsupported card
PKCS#15 initialization failed: Unsupported card
Again, this doesn't seem right to me. From what I could see, locking the
card avoid other applications from using the card, but when they try to
do it, even the application owning the lock begins to fails. The second
scenario spotted another problem, since the single thunderbird
application fails.
--
Alessandro
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
