PIN-Entry
Olaf.Schlueter@secartis.com
Olaf.Schlueter@secartis.com
Wed Oct 24 15:46:02 2001
I have the feeling (maybe wrong) that there is a misconception about th=
e
"Secure PIN entry" feature some more advanced readers do provide (Marku=
s
will probably agree here). Secure PIN entry is realized by having the
application issue a request to the reader to query the PIN from the use=
r
AND forward the PIN to the CARD, not to give it back to the application=
. In
fact it is an ISO PIN verify command with a special bit pattern where =
the
reader inserts the PIN code into before forwarding the command to the c=
ard.
The benefit gained is that the PIN never enters the PC. It is relevant =
for
use with smartcards only. Looking at the recently reported successful
trojan horse attacks on PIN entry to some (partly SigG-conformant)
smartcard based applications it is very relevant in that use case.
PKCS#11 does support "Secure PIN entry" in its login options. Markus is=
right, PC/SC which could provide a basic card reader API for a PKCS#11
implementation currently does not support "Secure PIN entry", one of it=
s
misfeatures. CT-API as an alternative to PC/SC does.
PKCS#11 support is a requirement for aegypten. Although the implementat=
ion
of a PKCS#11-module is maybe beyond the project scope, to be able to
utilize the PKCS#11 "Secure PIN entry" option in the PKCS#11 supporting=
code, with the given aegypten architecture the PIN entry module has to =
be
bypassed in that case.
Second comment: I think it is worth to be discussed, how the PIN module=
,
especially its communication path to the other modules, shall be protec=
ted
against trojan horse attacks.
Olaf Schl=FCter
SECARTIS AG
=
=20
Werner Koch =
=20
<wk@gnupg.org> To: gpa-dev@gnupg.org =
=20
Sent by: cc: =
=20
gpa-dev-admin@ Subject: Re: PIN-Entry =
=20
gnupg.org =
=20
=
=20
=
=20
24.10.01 09:34 =
=20
=
=20
=
=20
On Tue, 23 Oct 2001 23:07:30 +0100, Markus Montkowski said:
> 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).
cvs -d :pserver:anoncvs@cvs.gnupg.org:/cvs/aegypten checkout \
aegypten-specs/assuan-pinentry.txt
Login in first, password "anoncvs".
However there is no need to check it against other specs because it is
an internal protocol between GpgAgent and PINEntry which are both
programs to be written for Aegypten.
> 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)
We have not yet decided which API to use under GNU/Linux.
> 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.
Good to know, but it is nothing we have to care about now. Using an
external keypad to unlock a software held secret-key is a nice feature
but security-wise we gain nothing from it.
> The PIN should be queried direcly from within the Crypto function.
> In the crypto transaction with the card the crypto function should is=
sue
Have a look at the diagram on the web page. We exactly do that. A
reader requiring the host to retrieve the PIN from the keypad to send
it right back to the reader is not woththe money - any way to utilize
the keypad while a token is inserted is actually a security risk.
Werner
p.s.
Can please check your MUA setup, there is something wrong with your
line wrapping - I had to reformat it for quoting purposes.
--
Werner Koch Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions -- Augustinus
_______________________________________________
Gpa-dev mailing list
Gpa-dev@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gpa-dev
=