KDE Cryptography Module

[Thiago Macieira]

Alon Bar-Lev wrote:
>Provided:
>1. We have some kind of low level cryptography library, let's call
>this CRYTPO for now, so we don't argue whether it is QCA or anything
>else.

QCA isn't a low-level cryptography library. It's an abstraction layer upon 
those libraries.

Aside from that semantic distinction, we can take your CRYPTO proposal 
here.

>2. We have TLS/SSL socket implementation that uses CRYTPO in order to
>do private key operations, we will call this CRYPTO_TLS

Ok. This is what interests me. I have no idea how the rest works (I'm the 
socket guy, not the cryptography guy). This is also why QSslSocket is 
good enough for my purposes.

>We need to implement the following into KDE:
>1. Modify the KControl crypto section, to allow managing the CRYPTO
>attributes, including managing hardware devices.

Ok, this is important. We have some dialogs already for manipulating some 
settings and the certificate store, but we need to switch the backend. As 
for manipulating/configuring external devices, we have nothing yet. This 
would have to be written.

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

You're talking about obtaining a passphrase to unlock a private key, 
right?

>3. Modify the TLS/SSL provider in KDE to use the CRYPTO_TLS and the
>callbacks from (2), this will enable any TLS/SSL application to
>benefit from CRYPTO features, without any modification.

The current TLS/SSL provider is KSSL but its socket implementation simply 
must go. It's incompatible with QtNetwork. So, for all purposes, there is 
no TLS/SSL provider in KDE.

Now, this is where QSslSocket and QCA overlap: both provide sockets.

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

No comment on that. George knows what it is about.

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

Again, no idea.

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

Thankfully, we have close to none of other libraries. The only program I 
know of to be using cryptography of an external library is Kopete, but 
it's QCA that it is using. 

The rest of the programs must be using KSSL. That means the interface they 
are using will go away and they'll have to be ported. This is important, 
see below.

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

No idea about this one.

>What do you think?

Now we're getting somewhere. I call this productive now.

First things first: we're almost two months past the deadline for major 
frameworks in KDE 4.0. So the CRYPTO framework we're discussing now is a 
KDE 4.1 thing.

However, this has impacts on KDE 4.0: more specifically, on KSSL. As 
George said, he wants most of KSSL to be hidden and made private. Only 
the bare minimum should remain. I don't know how this public API would 
look like yet.

The way I see it, KDE 4.0 can't do without the secure sockets. All of the 
rest can reasonably wait for KDE 4.1 and a proper CRYPTO. As I said 
before (probably before we switched the thread to k-c-d), applications 
should not change certificates, policies or settings on the sockets. 
That's user configuration and/or KDE-wide policy.

We have a choice before us: either we use one of the existing socket 
classes or we don't. The latter choice means we'd write our own secure 
socket wrapper, descending from QTcpSocket.

Frankly, I'd rather avoid adding that class to KDE code, first because it 
would be something more to maintain until KDE 5.0. Second, because we 
already have two classes to choose from.

Whichever form we choose, we have to make the choice before KDE 4.0 is 
out, since the class we choose will be used by applications and we'll 
have to keep on supporting it (even if as a compatibility mode) until KDE 
5.0.

Right now, in code, the choice is QSslSocket. And Mailody is already using 
it.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/02441732/attachment.sig>