On 27.11.2006, at 17:35, Alon Bar-Lev wrote:
On 11/27/06, Ludovic Rousseau <[EMAIL PROTECTED]> wrote:
On 26/11/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> Hi,
Hello,
> the works of smart card software is confusing, so many open source
> project. what do you think: shall we start a wiki where we list
> each software, describe what it does, link to it etc?
That would be great.
I sometime discover new smart card applications/programs (like the
pkcs11-helper from Alon Bar-Lev) that could have helped me.
Thanks!
But before we do, I think we need to define what is smartcard
support...
There are quality criteria that should be listed for each application,
describing its level of support.
For example:
1. You don't expect application to require the user to store the PIN
hard coded in configuration file... This behavior was in *supplicant
projects which uses engine_pkcs11. I have an initial working patch
using pkcs11-helper that uses its management interface in order to
prompt user.
2. PIN should be requested from the user only when required, for
example NSS (Mozilla) asks for PIN to access token, even if it could
have read certificate without bothering user. When I tried to work
with NSS developers I got responses like "Your provider is bad, we are
OK", but it is not true.
This is a long known bug in Mozilla. See https://bugzilla.mozilla.org/
show_bug.cgi?id=201333
You can use modutil/javascript to overcome this, but i think we
should push mozilla more so that the 'friendly bit' would be always
set or at least exposed in the GUI.
3. If the user removes and inserts his card, the application should
reprompt for PIN when private object is accessed.
PIN should only be asked when needed. This is an extra addon
requirement for the applications that are built with the
understanding of 'PIN is like a password' and would not exist if the
application would have been built correctly from day 1. Read below.
4. If the user removes the card from one reader and insert it to
another reader, the application should detect that it is the same
card, and not prompt the user for credentials again.
Applications, the ones users are using, should not implement such low
level functionality. Applications should not know that such things as
smartcard readers exist at all (again - not all applications, but the
majority of *end-user* applications)
5. If the user opened a session/operation with object on a token, and
remove the token, the application should request this specific token
when it tries to perform private operations. For example NSS (Mozilla,
thunderbird) just fails SSL session, S/MIME operation. I tried to
raise this issue with NSS developers, but to solve this one their
interface should be modified...
6. Application should support gaining credentials from external
devices (Biometric, reader keyboard), if underline provider supports
this.
This is a generic error by 'application developers' who go with 'PIN
is like a password you ask with a username and then 'send
somewhere''. In fact, most applications need to do crypto operations
with a specific private key and the building logic should be 'I need
to sign something with this' rather than 'I need a username and a
password to send to the private key to sign this data'
7. If application uses persistence connection, such as VPN or SSL
session which initiated by smartcard operation, the session should be
disconnected (if requested by user) once the smartcard is removed.
8. Application should allow user to specify timeout after which the
user will be forced to re-enter PIN.
In this case means that the middleware (like opensc) should specify
how long to cache the pin. Applications themselves (with applications
i mean heavyweight end-user applications that either connect vpn,
sign e-mail or whatsoever, not stuff like pkcs15-crypt utility or
something similar.) should have almost zero knowledge of the
existance of a PIN (or a thumb attached to the user in that matter...)
9. If application supports a standard interface, such as PKCS#11, it
should allow to load more than one provider, so application can serve
different users with different devices.
90% of applications should now know about pkcs11 at all. 90% of
applications want to get access to the services provided by smart
cards and a certificate and trust management middleware to get the
operations done and do what it really has to do (VPN, send e-mails,
exchange digital signatures on the web etc)
pkcs11-helper... But most requirements are not PKCS#11 related.
Agreed.
Can't find it any more, but there was a good presentation about
certificates-smartcards-cdsa-openssl etc available on the net that
explained the point and a good target for application writers...
http://developer.apple.com/security/cdsaopenssl.html helps as well.
Basically operating systems should provide something that
applications can build upon (CDSA on mac, cryptoapi on windows,
upcoming QT thing on linux etc) and the only thing we should do is to
make sure that the given operating system services are good enough
and that opensc or other smartcard 'middleware' can integrate nicely
with the platform management system available (tokend on mac is a
good example :))
What I mean - we can't solve it all in applications, we only solve it
partially if we link all applications to a library, and in the end -
I still believe that pkcs#11 is a bad thing to expose to the random
joe out there. My father would never buy it.
Do you know about the 'pkcs11 directory' initiative by CAcert people?
http://wiki.cacert.org/wiki/Pkcs11TaskForce
will serve users best, and will provide a way for developers to
understand what is required from their side.
Application developers should get a new level of understanding of
what the heck are keys and certificates and how should you approach
the field so that things like smartcards and keypads and so on could
be introduced with no modifications in their software. When done
right, an application could use smartcards, PCI cyrpto accelerators
and software keys all the same way - even if the HSM interface is not
pkcs11....
Anyway... great work on the pkcs11-helper thing and welcome!
--
Martin Paljak / [EMAIL PROTECTED]
martin.paljak.pri.ee / ideelabor.ee
+372 515 64 95
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
