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.

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to