On 21.12.2006, at 0:25, Faidon Liambotis wrote:
[please Cc me on replies]
This brings us back to the biggest problem in trying to 'instantly
support' pinpad readers: applications (in this case pam modules)
think that smart cards evolved like this:
* We have a username and a password
* Now we invented RSA keys and certificates. We have a certificate
file with a key and a password for the key ("hey, you do want to keep
the key encrypted with a password, don't you?").
* developer enables the PKI part in his application and replaces
"username" with "path to certificate/key" and "password" with
"private key password". Some cases still use the username for
identification and PKI capabilities for authentication only. (you
specify a username, a path to a private key, and optionally (if
you're smart and security oriented) a password to decrypt the private
key file)
* Now we invent smart cards. The "best" applications just don't
support this ("how come you can't specify a file from where to read
the private key?"). Others support it somewhat better and do allow
'key references' and do a search-replace on the codebase: "password" -
> "pin". The idea is 'hmm, well, our application already supports
all asymmetric crypto and stuff. Thus - yes we do support smartcards,
smartcards are like hardware based private key files, right? So we
rename the password to PIN, block for asking a username + a password
pair and then send them both 'down to the libraries dealing with
smartcards' like we used to send them 'down to openssl' before to get
the response'
* Now we invent pinpad readers (or WPKI alias keys that live on your
SIM card and inside your GSM phone for example) All the historical
knowledge is useless, as the only abstraction the application should
be using is 'we have a key pair somewhere and we want to do some
crypto operations with them. We only have references to the keys, and
we REALLY don't know how the access to the key is authorized or how
and where the signature operations happens. We only know that calling
this API we get a signed hash back'.
I thought about making a 'test pkcs11 module' for testing. Which, if
it finds an enabled pinpad, rejects all software pins. That would be
a great software compatibility testing utility.
The point here is: whenever you REQUIRE a PIN in your application,
you're probably doing something wrong. Or you must have a really,
really good reason for it. PIN is not like a password you should pass
around. Your application, if smartcard enabled, should not in ideal
case even have GUI elements with 'PIN' in it. The best way to
approach 'hardware tokens' such as smart cards is to think about
issues as pinpads as early as possible.
Somebody proposed a 'smart card compatibility checklist for
'certificated' applications. I think this text deserves a permanent
position in the 'How to enable smart cards in your application stack'
guide.
--
Martin Paljak
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
