4.0: Certificate import tool needed for Windows 7 (32 and 64 bit)

[GoogleCodeExporter]

Hi,

In all Belgian communes eID cards have to be delivered.
For this to function properly the certificate propagation has to be disabled in 
Windows because:

- it interferes with the activation of the new eID cards 

- it imports the certificates of all eID's that are delivered or read in the 
application (and other applications)

The next Belpic version will use the Fedict middle-ware (3.5.6 at the moment).
As soon as version 4.0 is used, it will be impossible to import the  
certificates needed for use in other eID-enabled applications without 
re-enabling the certificate propagation and after the import disabling it again.

My suggestion is for the middle-ware 4.0 to provide a tool that:

- can enable and disable the certificate propagation

- can manually import the certificates from an eID card

The certificate import is not needed (nor desired) in Belpic because the PKCS11 
API is used for signing. But other applications on the same PC that use the 
Windows CSP (browsers other than Firefox, and applications that use the eID for 
securing communications) will have to import certificates.

Danny Heijl

Original issue reported on code.google.com by Danny.He...@gmail.com on 25 Oct 2011 at 1:27

[GoogleCodeExporter]

I should have added that I'm talking about Windows 7 of course...

Original comment by Danny.He...@gmail.com on 25 Oct 2011 at 2:38

[GoogleCodeExporter]

That's ok, its in the title ;)

I'll bring this up in the team-meeting tomorrow

Original comment by frederik...@gmail.com on 25 Oct 2011 at 2:47

[GoogleCodeExporter]

Thanks!

Original comment by Danny.He...@gmail.com on 25 Oct 2011 at 6:19

[GoogleCodeExporter]

Hi Danny,

You are referring to interferences between the Certificate Propagation 
Service and the activation of new eID cards. 
Can you specify which are the problems you encounter?

Thanks,

Koen

Original comment by koe...@gmail.com on 26 Oct 2011 at 11:36

[GoogleCodeExporter]

Hello Koen,

I have no personal experience (as I'm not allowed to deliver cards) but 
according to Belpic users on Windows 7 it is almost impossible to activate 
cards when the middleware 3.5 is installed. On a good day, about 1 in 10 
activations will succeed I'm told.
If the middleware is installed it helps somewhat to disable the eID GUI, but 
the only solution that really helps is to disable the certificate propagation, 
a tip we got from Cipal.

The problems is worse with slow readers like the ETS Beid pinpad (Arrow-up), 
the Giesecke STTx00 seems to suffer less (it's a really fast high-quality 
reader).

I can only assume that as soon as the card is activated, the certificate 
propagation kicks in to import the certificates (totally unwanted, as the 
citizen will almost certainly never be seen again on this PC), while at the 
same moment the Belpic application tries to test the success of the activation 
by signing (using PKCS11, *NOT* the CSP) with both the AUTH and NONREP 
certificates. For historical (read political) reasons the Belgacom (now 
Certipost) java GESP library (IAIK based, JDK 1.3) had to be used for signing, 
and we have no impact on this. The problem is that the GESP library reports 
that it can not get at the certificates, the signing operation fails, and the 
card can not be delivered. The next release of Belpic will use the Fedict 
middleware (we're testing with 3.5.6 at the moment), using the standard JDK1.6 
PKCS11 for signing. In lab conditions activation seems to work, but there are 
not enough test cards available to say anything more, we'll have to wait for 
the first pilots.

For the moment, the general consensus with the users is: no middleware = no 
problems.

But not having the middleware on the Belpic PC is unacceptable as it makes the 
PC unusable for other applications that (unfortunately) use the eID with the 
Windows CSP, because the National Registry enforces the use of the eID.

<personal opinion(rant)>
Personally I feel that the Windows CSP really ought to be a second class 
citizen for the middleware (i.e. you can use it if you have to), but the RSA 
PKCS11 standard should be the first choice for signing, as it is much better 
designed, flexible, and portable across operating systems. It would be nice if 
the PKCS11 signatures were exposed in the SDK and the runtime with a very 
simple and easy to use wrapper (available for Java, C, C++, COM), with one or 
two method calls. We would never have to import certificates when dealing with 
citizens this way.
</personal opinion(rant)>

Best regards

Danny

Original comment by Danny.He...@gmail.com on 27 Oct 2011 at 7:15

[GoogleCodeExporter]

Hello Danny,

Thank you for the explanation.
Do I understand it correct that this issue was seen only on life (belpic users) 
situations with the Belpic software that used the java GESP library?
And that the Belpic software that uses JDK1.6 pkcs11 performs correct in the 
test environment (as did the java GESP version before), but has not been tested 
life (belpic users) yet?

We do indeed enable the certificate propagation service during install of the 
eid middleware, but if I understand correctly, the only certificates wanted to 
be imported, are those from the PC user.
So once the (or all of the) users have their certificates registered, they 
would never need the certificate propagation service again. (meaning it could 
remain disabled, as the certificates remain stored in the certificate store)

We are interested in the underlying issue (could it be a concurrency issue 
between the java GESP library and other software that accesses the card 
(cert.prop, eidgui,..)?)
1) Does the java GESP library require exclusive access, and how does it respond 
if it doesn't immediately gets it? 
2) Can other software mess something up by accessing the card(i.e. trying to 
read its certificates) in between java GESP library transactions?
3) Is there card access in the Belpic software outside of the java GESP library?

The certificate propagation service starts reading the card as soon as it is 
inserted, this might be why you see it more often with slow readers: perhaps 
with fast readers the certificate propagation service has already finished 
reading the card before belpic starts the card activation.

With kind regards,
 Frederik

Original comment by frederik...@gmail.com on 28 Oct 2011 at 10:06

[GoogleCodeExporter]

Hello Frederik,

As only "live" Belpic PC's can activate new cards, that is the only place you 
are ever going to see it. All current Belpic PC's *have* to use the Java GESP 
library.
During the tests in the development environment in the RR, when using the new 
version where the GESP has been replaced with JDK1.6 PKCS11, we have not seen 
any problems, but this can not be used as a reference because you can activate 
a card only once, and new test cards are expensive and hard to come by.

As long as a card has not been activated, you can not access any files on it 
(except tokeninfo).
After activation all files become accessible, and I think that it is at this 
point that the certificate propagation kicks in.

1. I can not tell what you the GESP does, it is closed source owned by 
Belgacom/Certipost, with their own native code PKCS11 wrapper underneath. All I 
know is that you have to extend their "tokenlistener" class to monitor the 
cards, and once the tokenlistener has "seen" a card you can access it through 
the IAIK security provider (keystore, SSL, signatures).

2. Experience tells us that the GESP probably does not use exclusive access, 
but that interference by the eID GUI or other processes can prevent it from 
functioning properly. So what I think is that as soon as a card has been 
activated, everyone (certificate propagation, eid GUI, Belpic) starts to access 
it simultaneously, and depending on timings and reader speed you run into 
trouble (or not).

3. The Belpic application access the card directly via the PCSC API (for 
activation, resetting PIN, changing PIN, address modification, rekeying, 
reading files), but never concurrently with the Java security functions. This 
has never caused any problems.

The old Zetes middleware (PKCS11 only) that is used by the RAPC could not 
access the card immediately after activation, one has to remove and reinsert 
the card again so that the card gets detected by the Zetes PKCS11. So this is 
standard procedure when activating cards. I do not know if the Fedict PKCS11 
has the same limitation. For getting significant test results with the Fedict 
PKCS11 we would need enough unactivated test cards with their PUK1/PUK2/PUK3 
codes, and execute a number of tests on all supported reader types.

Kind regards,

Danny

Original comment by Danny.He...@gmail.com on 31 Oct 2011 at 8:54

[GoogleCodeExporter]

Hi Danny, 

Thanks again, it is pretty clear now.

With the current BELPIC release:
After the card activation, the test that checks if card activation was 
succesfull fails due to concurency, time-out, ..

With the new BELPIC software this situation this situation could not be tested 
thoroughly yet, but should it occur here as well, the workaround of manually 
registering certificates will be gone (not in the viewer anymore)

I'll have a look if we could provide this as an SDK example, but it will 
probably not be part of the eidmw installation.

With kind regards,
 Frederik

Original comment by frederik...@gmail.com on 4 Nov 2011 at 2:28

[GoogleCodeExporter]

Thanks Frederik. Even if it's only a sample in the SDK it would be
enough to help us out.

Best regarrds,

Danny

Original comment by Danny.He...@gmail.com on 6 Nov 2011 at 2:26

[GoogleCodeExporter]

Hi Danny,

You can find the example at 
http://code.google.com/p/eid-mw/source/browse/trunk/sdk/Examples/C/SDK_CertRegis
tration.vcxproj

With kind regards,
 Frederik

Original comment by frederik...@gmail.com on 22 Dec 2011 at 1:12

• Changed state: Fixed

[GoogleCodeExporter]

Thanks Frederik.

Original comment by Danny.He...@gmail.com on 23 Dec 2011 at 10:07