KDE and smartcard support
justin at affinix.com
Wed May 23 09:11:34 BST 2007
On Tuesday 22 May 2007 11:30 pm, Andreas Aardal Hanssen wrote:
> As for QSslSocket's part in all of this, if the incompatibility with QCA is
> at the certificate and key management level, I'm sure we can find some
> common ground.
In QCA, certificates and private keys (or really, just about any object) are
powered by a separate "provider" context object of some kind. For example,
the QCA::PrivateKey class is really just a thin wrapper around some
PKeyContext that exists behind the scenes and does the real work.
QCA does not care how the PKeyContext works internally, and so from this
design it should be easy to see how one can offer hardware private key
support. The approach to providing hardware supports ends up being no
different than software support (at this level).
Where things do become greatly different is how the private key is obtained.
Smartcard objects are retrieved through the KeyStore API. With this system,
the application can determine what devices are available (including signals
for device presence), and browse their contents. When a private key is
obtained through here, it will have been assigned a PKeyContext controlled by
a smartcard provider.
Ultimately, the application ends up with a PrivateKey object, obtained by
whatever means, and powered by some underlying provider implementation.
Hardware or software, it is used the same way.
(take deep breath)
The next step is to be able to use this PrivateKey for some high level
purpose, like SSL/TLS. In QCA's OpenSSL plugin, this is done by creating an
RSA_METHOD which allows overriding the functionality of an RSA* object. We
can make it so when someone (read: OpenSSL's own SSL support) tries to sign
something with the RSA* object (e.g. with RSA_sign()), rather than calling
OpenSSL's own software-based RSA signing algorithm, we can call QCA's
If you wanted to make it possible for QSslSocket to be similarly flexible,
probably what you would want to do is make QSslKey's functionality
overridable in the same way that OpenSSL's RSA* object is. In turn, you
would also need to do the above RSA_METHOD stuff, so that you can override
OpenSSL's RSA* object to call QSslKey's methods.
Then, a user could obtain a QCA::PrivateKey object and convert it to a QSslKey
object and pass it to QSslSocket. When your OpenSSL tries to sign with the
private key, it will ask the RSA*, which will ask QSslKey, which will ask
QCA::PrivateKey, and whatever happens after that doesn't matter. :)
Finally, I should mention that you have to thread the sign function, due to
the way the QCA card and PIN prompting interacts with the Qt main thread.
But you probably want this anyway or else the GUI would block (smart cards
More information about the kde-core-devel