Thomas Harning Jr. wrote:
On Thu, 2006-10-26 at 11:05 -0500, Douglas E. Engert wrote:
I would hope you would never try to cache a pin especially with
a card like the one you describe:
* If the card was issued such that you had to enter the pin
before every signature, then you are violating the policy
that the card is trying to enforce and you leave the yourself
open to misuse of the card.
* Newer card readers have a PIN pad so that the host/application
will never see the PIN, and therefore the application can not
cache it. These readers help avoid keyboard sniffers, and
applications like yours that try and cache (i.e. misuse the PIN).
* The user is expecting that every time the card is required
to do a signature, they will be notified and can make the choice
of signing or not.
Maybe Thunderbird needs to make some changes too, to abide by
the policies that the card issuer and user are expecting.
Hello, I've taken over the work that Justin Eylander was doing and was
wondering if there's a flag that can be set in OpenSC to have it ask for
the PIN for operations requiring user-consent.
The first thing to look at would be to run the OpenSC pkcs11-tool to
look at the objects as listed on the card along with their atributes.
The OpenSC driver for your card may be making some assumptions that
the PIN is needed every time, when it is actually only needed once.
It could also be that Thunderbird/FireFox is closeing the session to the
card, or reseting the card in some way which forces a new session and the PIN
again.
In Thunderbird/Firefox, it seems that it will ask you to enter your PIN
once to list certificates
Most cards should let you list the certificates without having to give
a PIN. So this might be a T/F issue in not looking at the pkcs#11 attributes.
and then again when it does the actual
signing. With a JavaScript test I found that behavior... haven't had a
chance to test email... but I assume it will be the same.
There IS an option that allows you to 'Log in' to the card permanently,
and it gets rid of the certificate listing PIN entry.
Ok, so is this option caching the PIN internally, or keeping the pkcs11
session open? pkcs11-spy would show what was going on.
If you can get the OpenSC pkcs11-spy working it would answer a lot of
the questions as to what T/F is actually doing, and if they are looking
at attributes of the objects on the card. A USB trace to the reader would
also show when the PIN was sent.
As it stands now... I have to cache the PIN since there seems to be no
way to initiate a user-consent PIN request properly...
As to how Thunderbird/Firefox might need to change... I see that it
should be honoring any PKCS11 attributes that exist for the user-consent
policy.. but I am not sure if there exists any such attribute.
What I was implying about policy was that eventially (maybe years?) all
readers would have a pin pad, so if the problems are in T/F implementaion
or its management of sesions to the card any amount of pin caching you
attempt to do will have no effect.
Can you determine using some simple C program to issue two sign operations
back to back against you card are allowed? Like a hacked pkcs11-tool?
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
