Hi all.
Part of the overall evolution-kolab project is to make it possible for
Evolution (as a Kolab client) to use TPM [1] infrastructure. In short, it's
all about certificate based client authentication, where clients can be forced
to authenticate themselves against a server when establishing an SSL
connection. It's the SSL server certificate based auth the other way around -
first, the server will identify itself by sending a signed (and therefore,
hopefully, trusted server certificate), then, the client will authenticate
itself to the server by sending a signed client certificate. Only after the
client sent a known, signed and trusted certificate, the server will ask for
service authentication (username/password). If the client cannot authenticate,
the server will terminate the SSL connection.
Using a TPM means that the client certificate is stored within a hardware
crypto token, the Trusted Platform Module. To open and use the crypto token,
the user needs to supply a user PIN (much like a password). Then only the
crypto token will be accessible and will reveal the client certificate (or
other data) it was asked for.
Via the PKCS#11 stack (implemented through opencryptoki [2] and trousers [3]),
it is possible to use this under Linux. It is working for Camel (via NSS)
already. Given the proper setup, the Evolution frontend will pop up a PIN
requester where the user can enter his/her crypto token PIN, and the crypto
token reveals the client certificate to NSS for use in certificate-based
client auth. This means that Camel can also use it. It works for us, there is
a draft installation and setup guide available in the evolution-kolab project
on SourceForge [4], namely
Usage_of_software_security_devices_for_client_authentication.pdf (check out
the Files section). We can secure e.g. an Evo IMAP connection that way.
Now, we're using Camel (to be more specific: IMAPX) in our evolution-kolab
backend, since all Kolab PIM data is stored in emails accessible via IMAP. We
would like to use the TPM crypto device there as well, but we're lacking a
possibility how we can request a user PIN from within the backend process
through the frontend, since there is no API which would allow us to open a
requester in the frontend (like, displaying some explanatory text, and having
a field to enter some text, and an ok/cancel button, the entered text being
handed back to the backend). This lack is there at least in 2.30, for which
evolution-kolab is currently being developed (porting to newer versions is in
the plannings, once we're done with the initial 2.30 release).
Maybe this is a more general thing than just having a backend requesting a
user PIN. I can imagine other scenarios where a backend might need to request
any user interaction, input, whatsoever, which is specific to this backend and
cannot be taken care of in the existing general EDS API (which is limited to
the typical things all backends need to do).
I'd like to know your thoughts on this, and maybe other backend implementors
already had a similar need to request some user data which is not readily
available through the standard EDS backend API.
Kind regards,
Christian
[1] http://en.wikipedia.org/wiki/Trusted_Platform_Module
[2] http://sourceforge.net/projects/opencryptoki/
[3] http://trousers.sourceforge.net/
[4] https://sourceforge.net/projects/evolution-kolab/
--
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
