KDE and smartcard support

[Alon Bar-Lev]

On 5/23/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> let's take a step back and try to see if there is common ground here (i think
> there is).

I also think there is... If we look at the problem as "cryptography in
KDE" and not only TLS/SSL issue. But every time we come back to this
specific issue, which of-course should be solved in view of the
greater goal.

Currently KDE components use OpenSSL in order to do cryptography. A
pin-point solution for abstracting TLS/SSL is provided by Trolltech
now, but Trolltech does not provide a complete cryptography usage,
required by modern applications.

For my understanding, QCA was developed in order to bridge this gap,
and provide Qt (KDE) applications Qt friendly cryptographic
interfaces.

Justin will correct me if I wrong here... But there is intention to
reinvent the wheel. The functionality developed in QCA was designed as
closer it could to Qt best practices. In the future, if Trolltech will
provide some functionality, there is no reason not to use Trolltech
implementation, provided it meets requirements (QtSslSocket is bad
example for this one, it does not provide external key usage, it ties
TLS/SSL with sockets, which are unrelated for example: S/MIME
STARTTLS, and it implements PKI objects as TLS/SSL only).

The first advantage of using QCA throughout KDE applications is to
have common cryptographic API, programmers can stop mess up with
OpenSSL or any other cryptic API.

The second advantage of using QCA is its modular approach. It was
designed in a way that any cryptography element (TLS, private key
operations, hashing, smartcards) is actually an optional provider, so
the actual implementation is hidden from the application, and can be
replaced in future, for example using the Qt native engines.

The third advantage of using QCA or any common API is that the user
has a consistent environment, having one place to select trusted
certification authorities, add his software based keys, specify
hardware cryptography providers and select TLS/SMIME/whatever
cryptography policy.

The forth advantage of using QCA is enabling applications to handle
software based and hardware based cryptography in the same manner,
thus providing hardware cryptography in any application.

> first, everyone would agree that having smartcard support in kde would be a
> Good Thing. so let's find a way to do that.

Great!
But in order to achieve this, we should improve the whole
cryptographic framework KDE is using.

> George, Thiago and others have an issue with a hard dependency on QCA for this
> because Qt may provide for this in the future. Qt is the preferred solution
> since we already depend on it; if Qt provides the required features in the
> future, using it will mean a smaller footprint which is nice for our users
> and fewer dependencies which is nice for people working with (building,
> developing, packaging) kde source code.

I agree with this, and I am sure QCA implementation follows the same approach.

> Alon points out that Qt doesn't have what is needed right now, but QCA. fair
> enough. George provides a possible solution to that in one of his emails:
>
>                 STEP 1: create an API for smartcard usage.
>
> the API is what the rest of the world sees and is the part that musn't change
> in the future (binary and source compatibility for 4.x). the API should be
> written so that it doesn't rely on the quirks or characteristics of the real
> solution behind the scenes (e.g. QCA), much as how we mask the complexities
> of X11, gstreamer, HAL, etc... with step 1 done, then we can move to:

I am looking at QCA as a candidate for this API.
If Trolltech will provide cryptography functionality, QCA will use these.
Please remember that QCA, unlike OpenSSL, is Qt friendly implementation.

So instead of inventing one more API, just look at the QCA abstraction
as STEP 1.

One more *IMPORTANT* note, using this API is not for smartcard
implementation, but the whole cryptographic code in KDE. There is no
point to treat smartcards in a special way, since the application that
does cryptography should not care where the cryptographic operation
are performed.

>
>                 STEP 2: provide a means to switch implementations
>
> this could be as simple as a "backend" class that is optionally compiled in
> if, say, QCA is available. add a "null" backend so if there is no smartcard
> capable API available at build time, then at least the library "works" even
> if it just returns failures. the backends could even be made to be loaded at
> runtime, but that seems overkill to me. conditional compilation should
> probably be enough.

Switching implementation is simple in QCA architecture, you just
create qca-qt provider that use Trolltech when available, and drop
qca-openssl and even maybe qca-pkcs11.

So we are already ready for this one, in the "overkill" option.

Once Trolltech will provide a full replacement for QCA (including
asynchronously, smartcards, stores), at about KDE 8, we can drop QCA
intermediate API.

>                 STEP 3: write an implementation that works

This is great, but we need help from you, KDE developers.

> you could use QCA for this if that is the Best Option right now.
>
> this way everyone gets what everyone wants:
>
>  - smartcard support in kde today
>  - the ability to change the implementation in the future, e.g. if Qt one day
> has the needed features
>
> reading the thread the above seems to me like it would satisfy all parties. if
> not, please correct me.

Before I started this thread, I believed that we are currently on "STEP 3"... :)
I wish to emphasize again... We are not talking about smartcard as a
standalone feature, we are talking about making KDE cryptography to be
implemented as a single component and be flexible enough to be able to
support smartcards.

QCA was introduced exactly to this purpose.

Best Regards,
Alon Bar-Lev.