First of all, thanks everybody for the prompt help.
Maybe I should first notice that we ran a test with >2 million
signatures befre going into production but with different cards: we
could not test the customer's cards because we don't have them. The
family is InCard but cards families are so... crowded...
On 09/08/2014 10:02 AM, helpcrypto helpcrypto wrote:
On Mon, Sep 8, 2014 at 9:30 AM, Umberto Rustichelli <
[email protected]> wrote:
...a few millions consecutive signatures for each card (what you wouldn't
do to meet the absurd customers' demand!)...
To make it short, does anybody know of any predictable limit that can
cause failures (after "many" signatures the *cards disconnect*, one by one)
among the following:
- cards cannot reliably work for more than N signatures
If it's a chip-writing limit issue, the card shouldnt be able to write
after reconnect. Have you tried that?
- some counters in the PCSC / CCID code
You can try stopping pcscd service and powering off devices each x-million
operations to discard this.
- any known issue with smart card drivers,
I dont know how you doing, but I suggest doing independent operations (ie:
use establishContext/releaseContext)
Mmmm... this I cannot do because I'm relying on the proprietary driver
for PKCS#11 operations, and I think that there is no reliable
open-source driver for those smart cards, sorry!
Whats the current operation limit?
Perhaps the amount of operations done is much more clarifying for us.
Consider, for example, PCSC dwCurrenStatus has a limit of bits to notify
card changes (including card resets).
_______________________________________________
Pcsclite-muscle mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
