Re: [opensc-devel] OpenSC SVN r5237 breaks support for Belgian eID
Le 29/05/2011 01:00, Martin Paljak a écrit : Hello, On May 29, 2011, at 00:35 , Viktor Tarasov wrote: Hello Jean-Pierre, Frank, Le 27/05/2011 17:27, JP Szikora a écrit : Hi Viktor, The change that you pushed in OpenSC SVN r5237 breaks completely the support for Belgian eID (eidenv, pkcs15-tool, opensc-pksc11.so usage with Firefox is not working anymore after this revision). Could you test the attached patch, please ? Just looking at the patch file itself does not make sense to me. Shouldn't the existing code behave exactly the same way, SC_TEST_RET should evaluate the error and return the same way, without the now added if? Am I missing something? The TEST_REST in this case is just the return with the message (the message can be changed) for the error that already happened -- SC_ERROR_CORRUPTED_DATA. The other errors are ignored, because there are the data that has been successfully read . (The errors are ignored for the embedded READ_BINARY, not for the first one.) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 29/05/2011 01:13, Martin Paljak a écrit : Hello, On May 28, 2011, at 22:47 , Viktor Tarasov wrote: Le 28/05/2011 22:26, Martin Paljak a écrit : Hello, On May 28, 2011, at 22:07 , Viktor Tarasov wrote: I would like to link statically the PKCS#11 module for Windows, or at least to include the static version of this module into the MSI . Why? It's a question of using of the different versions of opensc on the same platform. For standard distribution (AKA the OpenSC WindowsInstaller) there should not be such option. It is the same on Linux or OS X: only one instance (version) of a package can be installed. I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Adding a separate build step to the default makefiles for *building* static binaries in parallel with current ones would be nice and OK. Ok. But the MSI script of the installer should be tailored for most appropriate delivery method for 80% use cases/users where the current dependency on a central libopensc.dll seems justified to me at least. Afaiu, for the customer of PKCS#11 module there is no (beside the size) difference if this module is static or not . The other dependent libraries are actually statically linked -- OpenSSL, zlib, ... But it's not so important -- the second static version of PKCS#11 module included into MSI will be sufficient. Cheers, Martin Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
Le 27/05/2011 20:38, Douglas E. Engert a écrit : Could be a problem with short serial numbers 16 bytes. Looking at the KO trace, I see line 157: serial number r=0 len1=8 len2=32 --- 00F159CC:16 0C075480 51091619 08090A0B 0C0D0E0F expanded to 16 bytes (with the additional 08090a0b... from the empty_cardid) and then converted to printable as 32 bytes. See line 1943, as the file_cardid is 16 bytes. Line 193: return cardid --- 00F15AB8:26 30433037 35343830 35313039 31363139 It looks like the serial number for the card is 8 bytes note the last bytes are all 0x00. The file_cardid is size 16 bytes, and in the associate_card code at line 1943 copies in the empty_cardid, with 16 bytes. The code at lines 770 says it is returning the cardid, but it is really returning the serial number! But it is not expanded with the 08090a0b... from the empty_cardid. So we may have a problem with short serial numbers, or the BaseCSP has a problem with a x00 in the cardid. and why is the code at 770 not using the file_cardid that is expaned? My cards have 16 byte serial numbers so this has not an issue. Agree, the actual implementation of the 'cardid' content, as it returned when reading 'cardid' file do not correspond to specification (in it's size, at least). If the real 'cardid' content would be returned, there would be no '00' bytes -- short serial is padded with the 'empty-serial' value. I'll do the necessary change. Kind regards, Viktor. On 5/26/2011 1:38 PM, Viktor TARASOV wrote: Le 26/05/2011 20:14, Douglas E. Engert a écrit : On 5/26/2011 10:02 AM, HOURY William wrote: The kb909520 was already installed and i'm not using roaming profile :( OK. I installed OpenSC-12.1 on my XP box, made sure the certificate was not registered rebooted, and was able to login using a PIV card to AD. (But I don't think this has anything to do with the different cards.) The cert does show up in the cert store as expected. So I am not seeing your problem. No roaming profiles either. I have recompiled the minidriver and activated the debugs logs in case it brings some interesting info. I put them attached. That should be helpful. As expected the code path is different. In the OK case, these never change, as a single context can be used. pCardData-hSCardCtx:0xCD010002 hScard:0xEA010001 In the KO case, after reading the serial number, at line 137 a CardDeleteContext is done, and the Opens SC context is released. (I assume this means because it did not find the cert in the cert store.) But at line 144, the same process and thread does a CardReadFile and a new OpenSC context has to be done. The cardcf returned is then all zero, indicating we may have missed something here. But it goes on, and does 2 sign operations against the card, then at line 291 CardDeauthenticateuser and appears to be done. With your log file, was it set to be writable by everyone? If not we could be missing some data in the log. Maybe someone else in OpenSC can see something? I'm also actually looking into this logs and it seems strange the after releasing of context it starts to read the cardcf . In any case the 'zero' cardcf can be disturbing for baseCSP. Actually the cardcf is emulated by rand() or get_challenge(). Probably it would be better to implement the 'hard' cardcf and to read it every time from the card. The same, probably, for the other minidriver/CSP specific files. As far as I know the cards of different producers have the minidriver dedicated files that are not covered by pkcs#15 descriptors. We can do it also like this or to implement it like the public 'DATA' objects. Kind regards, Viktor. Thanks for your help. William -Message d'origine- De : Douglas E. Engert [mailto:deeng...@anl.gov] Envoyé : jeudi 26 mai 2011 16:34 À : HOURY William Cc : opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1 On 5/26/2011 3:07 AM, HOURY William wrote: Is this a login to AD, or just to the XP machine locally? == This is a login to AD It may have to do with the CA certificates. Did you add the CA cert to the machine before hand? == the machine is part of the domain, yes the CA cert is in the IE store You say it is the first login after the card was personalized. If you use a working card on a machine that has never seen that card, does it work? i.e. is this a card first time issue or an issue using a working card on a new system? == It is an issue using a working card on a new system You say you have to reboot. If you don't I assume it does not work until you do. == correct If you get a failure, but before rebooting, can you login using a password and look at the certstore using certutil or Control Panel-Internet Options-Content-Certificates and see if the cert for the card is
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
Hello William,
Le 26/05/2011 20:38, Viktor TARASOV a écrit :
I'm also actually looking into this logs and it seems strange the after
releasing of context it starts to read the cardcf .
In any case the 'zero' cardcf can be disturbing for baseCSP.
Another 'feature' is when the 'HANDLES CHANGED' event happens, the
disassociate/associate card procedures pair called,
and 'cardcf' content is cleaned but not re-initialized. That's where from there
is 'zero' content.
Could you please try the following test patch .
With this patch the cardcf content is deduced from the 'last_update' attribute
of the token info data,
and not from the minidriver internal data. So that we'll avoid a 'zero' content
of cardcf.
Also the initialization of 'cardcf' content is moved from CardAcquireContext()
to the associate_card() procedure .
Kind regards,
Viktor.
Index: src/minidriver/minidriver.c
===
--- src/minidriver/minidriver.c (révision 5514)
+++ src/minidriver/minidriver.c (copie de travail)
@@ -95,7 +95,7 @@
{
va_list arg;
VENDOR_SPECIFIC *vs;
-/* #define CARDMOD_LOW_LEVEL_DEBUG 1 */
+#define CARDMOD_LOW_LEVEL_DEBUG 1
#ifdef CARDMOD_LOW_LEVEL_DEBUG
/* Use a simplied log to get all messages including messages
* before opensc is loaded. The file must be modifiable by all
@@ -378,6 +378,35 @@
}
+static void set_cardcf(PCARD_CACHE_FILE_FORMAT pcardcf, char *last_update)
+{
+ WORD cf = 0, ff = 0;
+
+ if (!pcardcf)
+ return;
+
+ if (!last_update || strlen(last_update) 4*sizeof(WORD)) {
+ cf = rand()%0x7FFF;
+ ff = rand()%0x7FFF;
+ }
+ else {
+ int ii;
+
+ if (strlen(last_update) 4*sizeof(WORD))
+ last_update += strlen(last_update) - 4*sizeof(WORD) - 1;
+
+ for (ii=0; ii 2*sizeof(WORD); ii++) {
+ cf += (WORD)(*(last_update + ii)0x0F) (4*ii);
+ ff += (WORD)(*(last_update + ii + 2*sizeof(WORD))0x0F)
(4*ii);
+ }
+ }
+
+ pcardcf-wContainersFreshness = cf;
+ pcardcf-wFilesFreshness = ff;
+ pcardcf-bVersion = CARD_CACHE_FILE_CURRENT_VERSION;
+}
+
+
DWORD WINAPI CardDeleteContext(__inout PCARD_DATA pCardData)
{
VENDOR_SPECIFIC *vs = NULL;
@@ -787,9 +816,7 @@
*pcbData = sizeof(vs-cardFiles.file_cardcf);
*ppbData = pCardData-pfnCspAlloc(*pcbData);
if(!*ppbData)
- {
return SCARD_E_NO_MEMORY;
- }
memcpy(*ppbData, (vs-cardFiles.file_cardcf),
*pcbData);
@@ -1887,17 +1914,6 @@
logprintf(pCardData, 1, OpenSC init done.\n);
- if(sc_get_challenge(vs-p15card-card, challenge, sizeof(challenge)))
- {
- vs-cardFiles.file_cardcf.wContainersFreshness = rand()%3;
- vs-cardFiles.file_cardcf.wFilesFreshness = rand()%3;
- }
- else
- {
- vs-cardFiles.file_cardcf.wContainersFreshness =
challenge[0]*256+challenge[1];
- vs-cardFiles.file_cardcf.wFilesFreshness =
challenge[3]*256+challenge[4];
- }
-
if (suppliedVersion 4) {
pCardData-pfnCardDeriveKey = CardDeriveKey;
pCardData-pfnCardDestroyDHAgreement = CardDestroyDHAgreement;
@@ -1964,11 +1980,14 @@
}
}
- if(vs-card == NULL || vs-p15card == NULL)
- {
+ if(vs-card == NULL || vs-p15card == NULL) {
logprintf(pCardData, 0, Card unknow.\n);
return SCARD_E_UNKNOWN_CARD;
}
+ else if (vs-p15card-tokeninfo == NULL) {
+ logprintf(pCardData, 0, Invalid PKCS#15 card: no token info
data\n);
+ return SCARD_E_UNKNOWN_CARD;
+ }
/*
* We want a 16 byte unique serial number
@@ -1980,7 +1999,7 @@
* TODO needs to be looked at closer
*/
- if (vs-p15card-tokeninfo vs-p15card-tokeninfo-serial_number) {
+ if (vs-p15card-tokeninfo-serial_number) {
size_t len1, len2;
char * cserial;
@@ -1997,9 +2016,9 @@
loghex(pCardData, 7, vs-cardFiles.file_cardid,
sizeof(vs-cardFiles.file_cardid));
}
+ set_cardcf((vs-cardFiles.file_cardcf),
vs-p15card-tokeninfo-last_update);
- r = sc_pkcs15_get_objects(vs-p15card, SC_PKCS15_TYPE_CERT_X509, \
- vs-cert_objs, 32);
+ r = sc_pkcs15_get_objects(vs-p15card, SC_PKCS15_TYPE_CERT_X509,
vs-cert_objs, 32);
if (r 0)
{
logprintf(pCardData, 0, Certificate enumeration failed: %s\n,
\
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
