KDE and smartcard support

[Aaron J. Seigo]

On Wednesday 23 May 2007, Alon Bar-Lev wrote:
> We need to implement the following into KDE:
> 1. Modify the KControl crypto section, to allow managing the CRYPTO
> attributes, including managing hardware devices.

this should be part of the API we've already discussed. then kcontrol isn't 
working directly with CRYPTO library, but via an API that abstracts the 
concepts into a sensible API.

> 2. Introduce KDE dialogs for "token prompt" and "passphrase prompt" to
> be used as callbacks of CRYPTO, when token is needed or when
> passphrase is needed (software and hardware).

we already have the passphrase prompt: KPasswordDialog. this could be extended 
to also be a token prompt (by which i suppose you mean things like "swipe 
your smartcard")

> 4. Modify KWallet implementation so that it use CRYPTO in order to
> encrypt/decrypt sensitive data. This will enable all application that
> store sensitive data to automatically be smartcard enabled.

i believe right now that kwallet has it's own implementation for the 
cryptography it uses in kdelibs/kwallet/blowfish.cc. of course, kwallet needs 
to be backwards compatible with old data files. this should be easy as there 
is a version # in the header of the file format.

perhaps it is also possible to only modify the password authentication part of 
kwallet so that it uses a smartcard enabled system.

> 5. Write kdm greeter that uses CRYPTO and handle smartcard logon, this
> is optional dynamic loaded component.

would this be better served as a PAM module? (just thinking out loud here)

> 6. Scan all KDE code base and migrate any OpenSSL/GnuTLS/whatever
> crypto code into CRYPTO.

i don't think this is necessary and is just going to make things a whole lot 
harder as we're now going to have to deal with each and every crypto 
application. it could be doable, but changing for change's sake isn't useful. 
you keep going back to this, and that's where you are getting pushback. so 
let's just not go there right now, ok?

> 7. Approach kmail to use CRYPTO_SMIME, so that gnupg**5 processes will
> not be required for S/MIME configuration.

i assume CRYPTO_SMIME uses gpg as its backend?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070523/596054e2/attachment.sig>