KDE and smartcard support

[Alon Bar-Lev]

On 5/23/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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.

If you choose QCA as the API it will.

> > 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")

True.
But this should wait for slot event, so it disappear once the right
token is detected.

> > 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.

True.

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

Wrong.
You like all data to be encrypted so that only the user with the
smartcard can decrypt this.

> > 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?

Because the effort is only worth if we understand the whole implications.

>
> > 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?

Wrong!
The gpgme->gpgsm->gpg-agent->scdaemon->pcsc-wrapper->pcscd
configuration is UNWORKABLE and NIGHTMARE to your users.

Alon.