KDE and smartcard support

[Justin Karneges]

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 
PrivateKey::signMessage() instead.

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 
aren't fast).

-Justin