PIN-Entry

[Markus Montkowski]

> I have just defined the protocol used to communicate with the
> PIN-Entry - pretty simple indeed (assuan-pinentry.txt in the
> aegypten-specs module).
>
> Because the PIn-Entry is a small GUI utility we can just fork and exec
> it whenever we need some interaction.  This makes the communication
> pretty easy, as we only need to use 2 pipes for it - actually this
> will be stdin and stdout of course.
>
> I have thought again about the issue of passphrase caching and came to
> the result that it is better to let the gpg-agent (who invoked the
> PIN-Entry) do that.  For various reasons, the gpg-agent has to stay in
> memory anyway and is therefore the best place to keep some sensitive
> sesion data.
>
> It might be best to write it as a standalone QT utility without a need
> for any KDE libs - it has to grab keyboard and mouse anyway, so it
> does not matter whether it has all the nice KDE standard features.  In
> fact it should not have them and cut+paste should not be possible.

Where can I get the doc, I would like to check if it is flexible enought
to handle
Different Reader classes (With and without PINpad and/or Display).
The biggest Problem I can see with readers is that there is no direct
support
in PC/SC for readers with thie features (Apparently thats planed for PC/SC
2.0)
So all Reader vendors who support this use vendor spec. commands to do it.

The only API I know that covers PIN entry, Displays and even Biometrics is
CT-API.
So even on windows with PC/SC you have to use CT_API to use these
features.
As far as I have looked at the PC/SC implementation for Linux (and others)
no reader
so far does support PIN Pads.
The PIN should be queried direcly from within the Crypto function.
In the crypto transaction with the card the crypto function should issue
an CT_DATA
with PERFORM VERIFACTION (see CT-BCS (MKT spec. Part 4 page12) to the
reader.
The code handling the reader should check for that command and react
accoring to the
featues supportd by the reader.
- Reader has no FUs
  Query the user for the PIN (get PIN size, type etc outof the command)
and constuct
  the card APDU accordingly and send this to the card.
- Reader has PIN-Pad-FU, No Display
   Show dialog with entryfield and no buttons
   Directly send the command to the reader.
   End Dialog when the reader command returns.
   Remark:    These type of readers are mostly linked into the keybard
cable or build into
     a keyboard and issue * chars when the user presses a digit. Enter and
Backspace are also
     passed though to the system. So the dialog can work as a display
device. If the user presses Abort
     an ESC char is normaly send.
- Reader has a Display-FU and PIN-Pad-FU
   Simply show a dialog asking the user to enter the PIN at the reader.
   Directly send the command to the reader.
   End Dialog when the reader command returns.
   Remark:  These type of readers normaly don't return any chars all
visual feedback is done at the reader.

Markus
PS: Looks like working 4 years writing reader and card stuff for windows
finaly pays of.