305747 - PKCS#11, Pin change, and Pinpads (aka protected authentication path)

Status: RESOLVED DUPLICATE of bug 119500

(Core :: Security: PSM, defect)

Description

[Stefan Neis]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; de-AT; rv:1.7.11) Gecko/20050728
Build Identifier: any

We are a small company developping software for chipcard readers that do offer
the possibility to enter the card's PIN directly at the reader (so keyloggers or
other trojans won't be able to steal your PIN like they can do if you enter the
PIN via the keyboard). Particularly, we do developp a PKCS#11 module that can be
used with Netscape/Mozilla/Firefox/Thunderbird, and although "protected
authentication path" is a PKCS#11 feature that never was supported very well,
it's getting even worse as our work-arounds are just more and more sabotaged  by
"recent" software versions and I have no idea what else to do. 

Reproducible: Always

Steps to Reproduce:
Well, it's difficult to reproduce without suitable hardware, but I guess looking
 at the code is going to make things quite clear anyway. Anyway:

1. Install suitable hardware and our PKCS#11 module
2. Try some operation requiring to use a key from the protected chipcard
3. Try to change chipcard's PIN

Actual Results:  
For a start, our software is lying to the application and claiming that the
chipcard does not require a login at all (there's a suitable PKCS#11 flag for
this).
While this works reasonably well for Netscape-4 and Mozilla (they won't show a
password dialog and if needed, our software displays a window asking the user to
enter his PIN via the reader's PINpad), Thunderbird and Firefox both seem to
ignore this flag and unconditionally ask the user to enter a PIN - and they
don't even allow to enter an empty PIN which would be a possible workaround to
just call the function for secure PIN entry.
It's even worse for modifying PINs (expected behaviour: enter the old PIN via
the reader's PINpad, enter the new PIN twice and if the new PIN is the same
both times do change the PIN, otherwise give an error message). Old Netscape-4
has been giving a message box asking to change the PIN, with controls to enter
old and new PINs, you could simply click OK and proceed to the real change.
Mozilla doesn't allow the new PIN to be empty, so you have to enter some "magic"
string for the new PIN which is then recognized as triggering the secure, "real"
PIN change.



Expected Results:  
Well, ideally, it should handle PKCS#11 modules with protected authentication
path correctly, i.e. not display PIN entry dialogs but just tell the user
something along the lines of "Enter the PIN via the protected interface now".

Failing that, it should at least respect the claim of the token to not require a
login and not display PIN dialogs in this particular case. Also allowing empty
empty new PINs in the PIN change dialogs if a protected authentication path is
available would be helpful.

Comment 1

[Josh Birnbaum]

->Core:PSM.  See also bug 229023 (an NSS bug)

Comment 2

[Stefan Neis]

Sorry, I've been confused by a bug in our PKCS#11 module which erronuously
doesn't detect that a certain new hardware modell (the one I used for my last
series of tests) does in fact have a pinpad, so it's actively avoiding to use
the hack about "no login required for this token".
With that confusion on my part being cleared, what's actually left of my original
report is that short of really complete support for protected authentication
paths, is the aibility to just leave the dialog for changing the "master
password" empty, everything else was just an error on my part.
Sorry about that. :-(

Comment 3

[Frank Wein [:mcsmurf]]

Could you maybe modify the summary of this bug so it matches what is left (i
don't quite understand what's left of the bug, so better you do this)?

Comment 4

[Stefan Neis]

Well, just to clarify the problem after my initial confusion, here's a new
description:
- Mozilla and its derivatives don't handle the PKCS#11 feature of protected
authentication paths very well.
- However, you can work around most of the limitations by making your PKCS#11
module claim that it doesn't require a login and implicitly issuing calls to
your "protected authentication" routine as needed (however, this typically
implies that you want to display something on the screen to tell the user that
it's time to enter the pin/password - not that easy to do in a way that will
work across different platforms and with different applications - having the
applications take care of those dialogs would really simplify our lives).
- The one thing that currently is _really_ ugly is the attempt to change your 
pin/password. Mozilla and derivatives insist on always displaying a window
asking you to input the new password. To use the protected authentication path
for the password change, you need to fill in something here (it won't even
accept empty input fields), then make the PKCS#11 module ignore that input and
use the protected authentication path to have the user input the new password. 
Our current work-around is to ignore anything with at most 3 letters in this
way, but it's really confusing to the user and if he doesn't take extra care,
he'll typically end up _not_ using the protected authentication path for the
pin/password change, thus potentially telling all the world his newly choosen
pin/password, which is not very satisfying from the security point of view.

Comment 5

[Fabian Pache]

This is semantic duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=119500
PKCS#11 CKF_PROTECTED_AUTHENTICATION_PATH token flag not supported.

Comment 6

[Kai Engert [:KaiE:]]

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Unless I've misunderstood, this is a duplicate of bug 119500.