KDE and smartcard support

Justin Karneges justin at affinix.com
Wed May 23 19:44:05 BST 2007

On Wednesday 23 May 2007 5:45 am, Andreas Aardal Hanssen wrote:
> On Wednesday 23 May 2007 13:18, Justin Karneges wrote:
> > And yes, an SSL socket is orthogonal to the whole key handling stuff. 
> > Even QCA::TLS is pretty well independent from the rest of QCA.  I think
> > it would be quite reasonable (from a technical perspective) to be able to
> > use a completely different SSL/TLS API, such as QSslSocket, with a
> > private key obtained through QCA.
> > Let me know if you have any questions or alternate suggestions.
> Hm, if QCA can import and export DER or PEM ASN1 encoding, I actually think
> _that_ glue is already in place...

Hi Andreas,

For software-based private keys, serializing to DER/PEM is enough to transport 
between the two key containers.  However, hardware-based keys are generally 
not exportable.  When you sign using a private key on a smart card, you don't 
pull the key off of the card.  Instead, you ask the card to perform a 
signature and it gives you back the computed answer.  Transferring a key like 
this between containers is a bit more tricky, as you can expect.

This is why I suggested having a hook for signing.  Here is an example:

class QSslKeyImplementation
  virtual ~QSslKeyImplementation() {}
  virtual bool sign(int signAlgo, const QByteArray &in, QByteArray *out) = 0;

class QCASslKey : public QSslKeyImplementation
  QCA::PrivateKey key;

  QCASslKey(const QCA::PrivateKey &_key) : key(_key) {}

  bool sign(int signAlgo, const QByteArray &in, QByteArray *out)
    QCA::SecureArray sig = key.signMessage(in, qtAlgoToQCAAlgo(signAlgo));
      return false;
    *out = sig.toByteArray();
    return true;

QCA::PrivateKey pkey = ... // get from somewhere
QSslKey skey;
skey.setImplementation(new QCASslKey(pkey));

// Now you can use skey with QSslSocket


More information about the kde-core-devel mailing list