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 GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.