I'm working on writing a TokenD for a device with two applets on it.
The share the same PIN, however there is an oddity that I'm trying to
manage inside the TokenD.
Applets A and B
Select A, Verify PIN
Authenticated to A until reset (even if select B)
Select B, Verify PIN
Authenticated to B until reset, or select anything else, including A
I've tried using 2 PIN slots in the TokenD and assigning the relevant
Records and KeyHandles to use slot 1 for applet A's items and slot 2
for applet B's items... and it seems to "get it" when it needs to
authenticate for using applet B's items the first time... however when
it goes and checks for pinStatus the second time around after it had
authenticated once to B, it looks for the pinStatus on slot 1... not
the slot 2 that is assigned as the owner and the necessary ACL
authorizer for decrypt/sign...
Is there some other place that needs to be setup to deal with 2 PIN
slots properly?
the Token class adds the PWSubject and PromptPWSubject to its list of
pin types for both slot 1 and 2.
the Record and KeyHandle objects put the PinSubject entries for
sign/decrypt to slot 1 and 2 for the right handles/etc...
the Record and KeyHandle objects also return that the owner is the
relevant PinSubject (this wasn't required to get the 1st authorization
to use the right slot, but as added in an attempt to get it working
for subsequent auth)
I've also tried to use the PromptPWSubject, and that brings up a
prompt box, but passes an empty PIN back for authentication...... not
so useful.
Is there anything else I need to do? I've heard that Securityd does
tons of caching.. but if requests for pinStatus multiple times for
each authentication, so I'd expect that it should use the associated
pin number when trying to authenticate for key usage...
--
Thomas Harning Jr.